CFEngine Report on Configuration Drift

[Jeremy Finn]

I'm curious to know if anyone has used CFEngine to report on configuration drift. As in take a server "A" and baseline it, and compare it to server "B", and make a report telling where things are different. 

Ultimately we would review said report and decide where to negate any differences with CFEngine policy. Can CFEngine be used in such a way? Does anyone know of other tools that might work better for this?

Thank you,

Jeremy

[Nick Anderson]

You can do that with the Inventory Reporting interface in the Enterprise
editions Mission Portal.

This screenshot shows comparing a sysctl directive

https://github.com/nickanderson/cfengine-sysctl/blob/master/images/2014-08-28-Selection_001.jpg

[Marco Marongiu]

I'm not a user yet, but maybe Delta Reporting can help?
http://evolvethinking.com/products/delta-reporting/

[Neil Watson]

If the goal is for the servers to converge to the same state I don't see
much value is getting a report first. And getting the report can be
expensive. I would focus on the make actual changes instead.

However, you could use Serverspec to test against a known configuration.
You can dump a hosts configuration with a tool like cfg2html. I have
script that dumps general configuration for a build book and I'm happy
to post it if there is interest.

Can you do this with CFEngine? Yes, but it's hard. CFEngine is designed
to action and not offer passive reports.

--
Neil H Watson
Sr. Partner, Architecture and Infrastructure
CFEngine reporting: https://github.com/evolvethinking/delta_reporting
CFEngine policy: https://github.com/evolvethinking/evolve_cfengine_freelib
CFEngine and vim: https://github.com/neilhwatson/vim_cf3
CFEngine support: http://evolvethinking.com

[Neil Watson]

On Wed, May 27, 2015 at 10:28:51PM +0200, Marco Marongiu wrote:
>I'm not a user yet, but maybe Delta Reporting can help?
>http://evolvethinking.com/products/delta-reporting/

Delta reporting reports on the state of policy promises and host class
membership. It doesn't do configuration dumps. Think of DR as an audit
log for CFEngine.

[Jeremy Finn]

Thank you all. I agree with Neil in that our efforts would be better spent writing the policy to enforce the configuration we are concerned with. I haven't explored the Inventory Reporting interface yet, sounds like now would be a good time to do just that. I'll take a look at Serverspec and cfg2html while I'm at it.

Thanks again,
Jeremy

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Aleksey Tsalolikhin]

On Wed, May 27, 2015 at 1:23 PM, Jeremy Finn <jerem...@gmail.com> wrote:

I'm curious to know if anyone has used CFEngine to report on configuration drift. As in take a server "A" and baseline it, and compare it to server "B", and make a report telling where things are different.

Hi, Jeremy.  While I appreciate the desire for consistency (and share it), comparing existing servers is the hard way to go about it. Believe me, that's how I got into configuration management - we had 8 mid-range Sun Enterprise Ultra whatever servers (I forget the model number but they took up about a third of a rack) handling the email relay for EarthLink's users back in 2000 or so, the server farm handling outgoing email, and we noticed one of the servers had 20% better performance than the average, and a couple of servers had like 10% or 15% worse than the average.  

Naturally we wanted to take the servers with the below-par performance and get them (and all the other servers) configured like the rock star server that was doing 20% better than the average.  

I took it upon myself to analyze their configuration to find the magic sauce.  The longer I look, the more differences I found: sendmail version, sendmail config settings, OS version, patch sets, kernel tunables -- basically every server was unique, even though we had a (manual) build procedure.

We ended up moving from sendmail to exim and consolidating from 8 to 6 servers (with better performance) but that's another story.

Bottom line -- it takes live judgement to decide which configuration details are important.  Those are the ones you want in your configuration management policy.

The CFEngine Way is to model the desired configuration in policy, and then audit and repair your servers to help them converge to the desired state.  

You will need to analyze your configuration first to figure out what's important to your business in the configuration.

That said, to answer your original question, bcfg2 has the ability to "snapshot" a current servers configuration and compare it to other servers but I don't know the details of how it works.  The CFEngine Way makes sense to me and I've found it highly workable.

Recently I've been enjoying CFEngine Enterprise (free for up to 25 nodes) at scale, the reporting features are really handy.  You just tag whatever configuration aspect you care about, and the policy hub will poll the servers to inventory them and will consolidate and summarize the results for you.  For example, you can report your sendmail version, and you can see in the results that 98% of your infrastructure has version X.Y but 1% have X.Z and 1% have X.X (configuration drift).   It's quite handy!

[Neil Watson]

coss: Gather host information for build books
https://github.com/neilhwatson/nustuff/blob/master/utils/coss