On Mon, May 18, 2009 at 12:29, Antonio Radici <anto...@dyne.org> wrote: > Petru Ratiu wrote:
>> Hello, sorry for the delay. >> >> I haven't yet tested the patch, but I find it not quite right, because >> I still want to be able to parse and syntax-check the configs (I have >> a svn hook that does syntax checking and this will cause it to neglect >> real syntax errors for rules not meant for the machine doing the >> check). >> >> I'll try to test the package as soon as I can, but I need to say that >> I won't use this fix in production and would prefer the current >> behavior. >> > > Probably there was a misunderstanding, having two addresses separated by a > space is not a syntax error, the only reason why this is reported as syntax > error is because of this bug; the patch is not removing any syntax check. > > The patch is solving the problem of wrong syntax check failures when the > class does not exist and admit/grant directives are separated by one space; > if the same directives are included in an existing class no syntax error > will be reported. > > I hope this clarifies the context. > Ok, maybe I am missing something: I understand that your patch makes cfservd not read at all whatever rules are not appliable for the defined classes. My use case is as follow: I have a specific set of rules for the policymasters and a global rule (allowing cfagent remote execution) for all hosts. The current behaviour is that in case of a rule with a specific syntax (multiple rules separated by spaces - documented as valid) on one of the policymaster sections, cfservd breaks on all the other machines. For now this means for me that I need to avoid that syntax and either use commas or one rule per line. If I understood correctly, the patch will make any rule parsable only on the host it's meant for (or if the classes are manually defined on the command line). This prevents me running automated syntax checks to catch some other (valid) syntax errors, because (at least in my setup) it's more difficult to set up the parser to include all rules than to exclude all rules. I'd rather have false positives than false negatives :) -- Petru Ratiu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
