On Jan 9, 2008 3:01 PM, Jo Rhett <[EMAIL PROTECTED]> wrote: > On Jan 9, 2008, at 11:16 AM, Jesse Becker wrote: > > 1) Will --debug include the same information as reported by -- > > verbose? Is there any information in --verbose that is not > > reported in --debug? > > I believe that debug implicitly sets verbose but I may be wrong. > I'll check that when I have a chance to crack open the code again.
I don't think that it does: # cfagent -q -v | egrep -c 'Main.+pass' 16 # cfagent -q -d 1 | egrep 'Main.+pass' 0 > > 2) I've found that when troubleshooting my rules (usually of the > > "why didn't this run?" type), the output from --verbose is > > insufficient. Usually because I'm trying figure out why a class or > > variable has been set (or not). If there's a clean way of > > reporting these two things in --verbose mode, that would be > > wonderful. (maybe a -vv sort of option?) > > Well, why not provide an explicit example of how it works today, how > you think it should work. Examples of both below. I'm not tied to the formatting, just that the information is easily readable. Here is -d 1 output for assigning a variable. <----snip----> NEW CLASS PREDICATE:: any:: (No actions pending in Control Defintions:) InitializeAction() HandleClass(any) (No actions pending in Control Defintions:) Simple class = (any) LVALUE LogServer HandleLVALUE(LogServer) in action Control Defintions: RecordMacroId(LogServer) EQUALS = LEFTBRACK RVAL-QSTRING "logserver.example.com" ExpandVarstring( logserver.example.com ) Add |logserver.example.com| to str, waiting at || Returning varstring (logserver.example.com) IsInstallable(any) - true Assign variable [LogServer=logserver.example.com] when any) AddMacroValue(main.LogServer=logserver.example.com) ExpandVarstring( logserver.example.com ) Add |logserver.example.com| to str, waiting at || Returning varstring (logserver.example.com) Added Macro at hash address 2919 to object main with value LogServer=logserver.example.com RIGHTBRACK <---snip---> This is great for debugging the expression parser, but not quite so useful as something like: cf.logging:12: Class [any::] assigned LogServer=logserver.example.com Running under -d2 is less wordy, but the line "Added Macro at hash address 2919 to object main with value LogServer=logserver.example.com" is still buried in with lots of other declarations, making it hard to find. >From the same cf. file, I have a variable set from a call to ExecShellResult(/bin/date "+%Y%m%d"). The -d1 output is: <---snip---> LVALUE SyslogDate HandleLVALUE(SyslogDate) in action Control Defintions: RecordMacroId(SyslogDate) EQUALS = LEFTBRACK RVAL-FUNCTION ExecShellResult(/bin/date "+%Y%m%d") HandleFunctionObject(ExecShellResult(/bin/date "+%Y%m%d")) IsBuiltinFunction(ExecShellResult(/bin/date "+%Y%m%d")) IsBuiltinFunction: ExecShellResult(/bin/date "+%Y%m%d") HandleFunction: ExecShellResult(/bin/date "+%Y%m%d") FunctionStringToCode(ExecShellResult) ListArg[0]=(/bin/date +%Y%m%d) Check ListLen ExpandVarstring( /bin/date +%Y%m%d ) Add |/bin/date +%Y%m%d| to str, waiting at || Returning varstring (/bin/date +%Y%m%d) ARG[0] /bin/date +%Y%m%d GetExecOutput(/bin/date +%Y%m%d,) cfpopen(/bin/date +%Y%m%d) GetExecOutput got: [20080109] cfpclose(pp) cfpopen - Waiting for process 11937 ExpandVarstring( 20080109 ) Add |20080109| to str, waiting at || Returning varstring (20080109) IsInstallable(any) - true Assign variable [SyslogDate=20080109] when any) AddMacroValue(main.SyslogDate=20080109) ExpandVarstring( 20080109 ) Add |20080109| to str, waiting at || Returning varstring (20080109) Added Macro at hash address 27 to object main with value SyslogDate=20080109 RIGHTBRACK <---snip---> The -d 2 output is similarly loquacious. I'd suggest reducing this to something like: cf.logging:15: Class [LoggingServer::] assigned LogServer=logserver.example.com (from ExecShellResult) Classes are a bit better, but only just: <----snip----> LVALUE HasNTP HandleLVALUE(HasNTP) in action Groups: EQUALS = LEFTBRACK RVAL-QSTRING "/usr/bin/test -f /usr/sbin/ntpd" HandleGroupRvalue(/usr/bin/test -f /usr/sbin/ntpd) ExpandVarstring( /usr/bin/test -f /usr/sbin/ntpd ) Add |/usr/bin/test -f /usr/sbin/ntpd| to str, waiting at || Returning varstring (/usr/bin/test -f /usr/sbin/ntpd) HandleGroupRVal(/usr/bin/test -f /usr/sbin/ntpd) group (HasNTP), type=2 with fqname=host.example.com,uqname=host cfpopen(/usr/bin/test -f /usr/sbin/ntpd) cfpclose_def(pp) cfpopen_def - Waiting for process 11933 AddMultipleClasses(HasNTP) AddClassToHeap(HasNTP) RIGHTBRACK <----snip----> A more general logging item would be that, for any new class definition in any action, have something like: cf.logging:54 action files: Class [any] matches. cf.logging:54 action files: Class [LoggingServer] matches. cf.logging:62 action files: Class [LoggingServer.freebsd] does not match What I've found as the rulesets for cfengine have grown is that it becomes difficult to track when and where and why things are being defined. There have been several cases where it was not at clear if a variable was being interpolated within a string (or editfiles:), or if it was ever defined in the first place. This information is present in the various debug outputs, but plowing through 100,000 lines (seriously) of debugging output is not much fun. My basic take on the various logging is: 1) cfagent should be quiet under normal circumstances, unless there is an error (can't connect to policy host, syntax error, etc), or told to be noisy (inform/alert, etc) 2) The current --verbose output is fine for most things, but not enough for certain troubleshooting. 3) The debugging output is too wordy (although I would rather have it, than none at all). I think that one question that I wish I could more easily answer when looking at the logging output is "why did this happen?" Such as: What class combination matched that added this rule? Where was this variable set, and how? Hope this helps clarify a bit. -- Jesse Becker GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 _______________________________________________ Bug-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/bug-cfengine
