Re: modules bug with pre-scanning for a user

[Ted Zlatanov]

Mark.Burgess@iu.hio.no writes:

> This is expected behaviour if the JoeFound class is defined. There have
> been bugs related to class definition, but I'm not sure what is the
> problem in your case. My tip would be to use your orginal idea, but like
> this to remove the output
> 
> groups:
>  JoeFound = ( "/bin/grep joe /etc/passwd >/dev/null  2>&1" )

I forgot to mention that I had tried that already:

groups:
  JoeFound = ( "/bin/grep joe /etc/passwd >/dev/null" )

But I get the error:

grep: can't open >/dev/null

So you are interpreting the > yourself, rather than passing it to the
shell.  I'm not sure where to look in the source code to dig further.

The original problem that I had was that, even if a files: command is
conditional upon an AddInstallable class defined by a module (thus, in
an unknown state at first), it will be checked for username validity
regardless of whether the conditional class is really defined or not.
I hope that explains it better.

In C lingo it might be clearer:

char JoeFound; /* the class */
AddInstallable(JoeFound);

JoeFound = ask_module_if_Joe_Found();

if (JoeFound) check_files("/home/joe", "owner=joe");

The problem is that the owner=joe parameter to check_files is getting
checked for validity against /etc/passwd regardless of whether
JoeFound was true or not.

It's not a critical bug for me, but I'd like to use modules in
conjunction with a database to download dynamic rules applicable to
certain machines.  If module-defined classes have funny evaluation
rules vs. hard-coded classes, I may have to rewrite the cf.classes
file dynamically instead - not a worse solution, but I'd rather have
clean integration between cfengine and my software.

Thanks
Ted