parsing bug in hobbit-clients.cfg
list Elmar Heeb
Hi
Suppose you have the following entry in hobbit-clients.cfg:
HOST=blog.example.com,example.com
PROC apache
then the PROC test will be ignored for example.com. If the two hosts are reversed, i.e.
HOST=example.com,blog.example.com
PROC apache
then the PROC test will be done for both hosts. I tried with a few variations on this and it appears that any later string in the comma separated list will be ignored if it is a substring of a string that appeared earlier. The same goes for EXHOSTS and probably most other selectors.
This bug is present in at least versions 4.3.0 beta2 (from Debian lenny-backports) and 4.2.0 (from Debian lenny).
-- Elmar
--
Dr. Elmar S. Heeb <user-49eb29db847d@xymon.invalid> support: +41 44 633 26 68
IT Services Group, HPT D 19 voice: +41 44 633 25 91
Department of Physics, ETH Zurich mobile: +XX XX XXX XX XX
CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Please consider the environment before printing this e-mail
list Elmar Heeb
▸
On 11/19/2010 12:53 PM, Elmar Heeb wrote:
Suppose you have the following entry in hobbit-clients.cfg: HOST=blog.example.com,example.com PROC apache then the PROC test will be ignored for example.com. If the two hosts are reversed, i.e. HOST=example.com,blog.example.com PROC apache then the PROC test will be done for both hosts. I tried with a few variations on this and it appears that any later string in the comma separated list will be ignored if it is a substring of a string that appeared earlier. The same goes for EXHOSTS and probably most other selectors. This bug is present in at least versions 4.3.0 beta2 (from Debian lenny-backports) and 4.2.0 (from Debian lenny).
I have narrowed down the bug to the namematch subroutine in lib/matching.c and attached a patch. The old code (which is the same in 4.2.0 and the svn trunk version) indeed explains the wrong behaviour. Lacking a preceeding comma as a guard character essentially made any non-comma character a negating match and not just an '!'. The patch explicitly tests for ",%s," and ",!%s," and thus makes sure that a partial match cannot prevent a later full match.
▸
-- Elmar -- Dr. Elmar S. Heeb <user-49eb29db847d@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +XX XX XXX XX XX CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ Please consider the environment before printing this e-mail
list Elmar Heeb
▸
On 11/19/2010 05:40 PM, Elmar Heeb wrote:
I have narrowed down the bug to the namematch subroutine in lib/matching.c and attached a patch.
The last post had the wrong patch file (no idea how the spurious hunk got in). Anyway this is the patch that worked for me.
▸
-- Elmar -- Dr. Elmar S. Heeb <user-49eb29db847d@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +XX XX XXX XX XX CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ Please consider the environment before printing this e-mail
list Henrik Størner
▸
In <user-00d3d129a26d@xymon.invalid> Elmar Heeb <user-49eb29db847d@xymon.invalid> writes:
On 11/19/2010 12:53 PM, Elmar Heeb wrote:Suppose you have the following entry in hobbit-clients.cfg: HOST=blog.example.com,example.com PROC apache then the PROC test will be ignored for example.com. If the two hosts are reversed, i.e. HOST=example.com,blog.example.com PROC apache then the PROC test will be done for both hosts. I tried with a few variations on this and it appears that any later string in the comma separated list will be ignored if it is a substring of a string that appeared earlier. The same goes for EXHOSTS and probably most other selectors. This bug is present in at least versions 4.3.0 beta2 (from Debian lenny-backports) and 4.2.0 (from Debian lenny).
I have narrowed down the bug to the namematch subroutine in lib/matching.c and attached a patch.
The old code (which is the same in 4.2.0 and the svn trunk version) indeed explains the wrong behaviour. Lacking a preceeding comma as a guard character essentially made any non-comma character a negating match and not just an '!'. The patch explicitly tests for ",%s," and ",!%s," and thus makes sure that a partial match cannot prevent a later full match.
Thank You for a very detailed bug-report. Providing a simple testcase
was especially helpful. I considered using your suggested patch, but
instead decided to rewrite the routine since this turned out to be a
cleaner/simpler solution. So fixed in rev 6598.
Regards,
Henrik