Jake,
thank you for your comments. Cfengine community edition contains all the
tools you need to construct what you want. Nova just makes it all easier
and more "out of the box" and value-adds analysis.
Perhaps flaming the product is a strategy for getting a response, but I
don't recommend it. I suggest reading the special topics guides if you
want to use Cfengine. The core technology in Community edition allows
you to make logs of pretty much anything, but you'll have to put in the
work, or pay for the privilege of getting it for "free". As a business
man, I'm sure you will understand this.
Mark
On 03/06/2011 04:15 PM, Jake wrote:
> On 03/05/11 09:33, Mike Svoboda wrote:
>> Hey Jake
>>
>> I think you're missing the point here. If you are trying to figure
>> out what Cfengine is doing, by looking at the output of cf-agent -I,
>> then you're going too deep.
>>
>> Here's an example of what Neil was suggesting....
>>
>> "/root/.ssh/authorized_keys"
>> perms => mog("0400","root","root"),
>> copy_from =>
>> backup_cp_md5_compare("/var/cfengine/inputs/root_ssh_key"),
>> classes => if_repaired("root_ssh_key_modified");
>>
>> reports:
>> root_ssh_key_modified::
>> "cf3: The root ssh key on $(sys.host) has been modified";
>>
>>
>> So, if an action is taken to replace the file, the class
>> “root_ssh_key_modified” gets raised. The report under the class
>> “root_ssh_key_modified” gets printed to stdout / injected into syslog.
>>
>
>
> thanks for making neil's suggestion about reports concrete, i could not
> find a useful example anywhere in the documentation. this method of
> having a repair set a class should be more prominently documented based
> on how useful it is, the same thing came up when i had asked about
> conditional command execution.
>
>
>> This is what you should focus your logging around. If you want to see
>> specific things happening, then raise classes and print reports when
>> they do. When you start administrating tens / hundreds / thousands of
>> machines, you are really only interested in what is happening on a
>> high level. I personally use Splunk to watch syslog, and then use
>> Splunk to fire off alerts / notifications when it sees these actions.
>> I think this is where you’re missing the point. This software /
>> infrastructure was designed to support the maintenance of thousands of
>> machines. If you had detailed log data from so many machines, you end
>> up being swamped with data. Instead, only report on things you want
>> to be notified on. This reduces information overload.
>>
>> Since Cfengine uses syslog, use either a product like Splunk or
>> syslog-ng to centrally collect this data for reporting.
>>
>
>
> i administrate several dozen machines and, initially, i am interested in
> getting all changes made by cfengine logged. having to make a separate
> class that is triggered by each repair which then feeds into a report is
> not exactly simple or elegant. having a single setting that would do
> this for all repairs is more along the lines of what i was looking for.
>
> i do understand your point about the maintenance of large numbers of
> machines but my own experiences with logging dictate that it is always
> better to log too much than too little. you can throw out data but you
> cannot recreate it after not logging it. once i get all the data logging
> i will surely dial back the amount of data logged at some point.
>
>
>> If you’re interested in the lower level details of what is going on,
>> there are 2 log files that you can take a look at. In the $workdir,
>> there’s a cf3.<hostname>.runlog which shows the decisions made on
>> every execution of every policy. There’s also a promise_summary.log
>> which describes from a high level what was / wasn’t able to be
>> accomplished on that specific run.
>>
>> Anyways, don’t flame the product. If you want to go use something
>> else, then go do so. The tools are available in the community edition
>> for you to build an extremely scalable / distributed configuration
>> management infrastructure.
>>
>
>
> i flamed the product in hopes that i was wrong and someone would give
> more information than is in the documentation. i support a number of
> open source projects and find the documentation to be lacking relative
> to those projects, so maybe my standards are too high.
>
>
>> Thanks
>> Mike
>>
>>
>>
>>
>> On 3/5/11 10:03 AM, "Jake" <behindt...@gmail.com> wrote:
>>
>> > On 03/04/11 07:53, no-re...@cfengine.com wrote:
>> >> Forum: Cfengine Help
>> >> Subject: Re: proper logging for cfengine processes
>> >> Author: neilhwatson
>> >> Link to topic:
>> https://cfengine.com/forum/read.php?3,20915,20955#msg-20955
>> >>
>> >> Nova has the best logging built in. For community you have to do
>> more work.
>> >> I use report promises extensively. When the agent is run from the
>> executor
>> >> these reports go to syslog.
>> >>
>> >
>> >
>> > thanks for this info, there is very little info to go on.
>> >
>> > after searching for further information on this topic (logging) i am
>> > left to conclude i am pretty much screwed with cfengine 3 community. i
>> > cannot speak on cfengine nova. i would like to think that i am wrong but
>> > your comment suggests to me that "if you want real logging, you must
>> > pay" which is, imo, ridiculous.
>> >
>> > the various cf-* daemons work great in the foreground with verbose or
>> > debug outputs. unless i am really missing something it seems that it has
>> > been made intentionally difficult to get this same information to write
>> > to a log. this is unbelievably stupid and could easily be fixed with an
>> > hour or two of developer work, but i would be willing to bet a patch
>> > would not be accepted. this seems like a *really* poor choice of
>> > features to intentionally remove from the unpaid version of the software.
>> >
>> > without proper logs one really cannot gauge how well the community
>> > solution works for their application. removal of the basic features
>> > required to test the real world utility of the software make a potential
>> > purchaser (me) unlikely to proceed with any purchase because the quality
>> > of the goods on display is questionable.
>> >
>> > there should be a couple simple settings for logging in each daemon's
>> > config file e.g.
>> >
>> > syslog = yes
>> > log_level = 3
>> >
>> > the apparent lack of any such settings or any accompanying documentation
>> > is pretty shocking.
>> > _______________________________________________
>> > Help-cfengine mailing list
>> > Help-cfengine@cfengine.org
>> > https://cfengine.org/mailman/listinfo/help-cfengine
>
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
