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 <heeb at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +41 79 628 75 24 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Please consider the environment before printing this e-mail
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 <heeb at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +41 79 628 75 24 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Please consider the environment before printing this e-mail
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 <heeb at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT D 19 voice: +41 44 633 25 91 Department of Physics, ETH Zurich mobile: +41 79 628 75 24 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Please consider the environment before printing this e-mail
In <4CE6A88E.3010004 at phys.ethz.ch> Elmar Heeb <heeb at phys.ethz.ch> 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
participants (2)
-
heeb＠phys.ethz.ch
-
henrik＠hswn.dk