snippets (was RE: [help-cfengine] Re: time for a CFEngine 4)

[Moore, Joe]

Don't get me wrong, I'm not proposing replacing any of the frameworks with these snippets... I'm thinking of them as a benefit for the sysadmin who reads the "Getting Started" guide (or the Zamboni book) and thinks "ok, I think I understand enough to be dangerous, now what?"

At the moment, the next step is either "Pick one of the 3 frameworks[1] and commit to it 100%, giving up everything else"[2], or "reinvent a wheel to make sure that all the systems' root passwords are the same"

Here, the next step could be "copy snippets/policy/set_root_password.cf into $masterfiles/services/autorun/ and edit it to have your desired hash value". Poof, instant value delivered to the sysadmin.

See for example: https://github.com/jpvlsmv/cfengine-snippets/blob/master/policy/set_root_password.cf and others in that directory. Suggestions and pull requests welcome :)

They would also serve as fully-functional documentation of "how does that work" or as a quick cookbook-style "What does a mustache template look like in practical use"

--Joe
[1] NCF, EFL, Design Center.
[2] And read documentation on "Getting Started" with any of these frameworks.

-----Original Message-----
From: help-c...@googlegroups.com [mailto:help-c...@googlegroups.com] On Behalf Of Neil Watson
Sent: Tuesday, December 16, 2014 10:51 AM
To: help-c...@googlegroups.com
Subject: Re: [help-cfengine] Re: time for a CFEngine 4

On Tue, Dec 16, 2014 at 03:31:55PM +0000, Moore, Joe wrote:
>I would be willing to share some standalone snippets, ones that can be
>dropped into the stock autoruns directory to accomplish common "getting
>started" tasks that are a little more straightforward than using copbl
>or design center.

This is where Nick Anderson's work to integrate frameworks like EFL and
NCF into masterfiles will really pay off. A big attraction to Chef and
Puppet is ready to use code. EFL and NCF offer this. EFL even has 100+
hardening promises ready to go. No theoretical or trivial snippets, but
production quality policy and data.

--
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

--
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.

[Klaus Kaempf]

* Moore, Joe <joe....@siemens.com> [Dec 17. 2014 18:34]:

>
> See for example: https://github.com/jpvlsmv/cfengine-snippets/blob/master/policy/set_root_password.cf and others in that directory. Suggestions and pull requests welcome :)

This is just wonderful, thank you Joe !

A small, to-the-point example, with comments - just perfect.

Now how would people find this snippet ?

How do we make this snippet come out on top when you google for "cfengine
set root password" ? The current Google results are not paticularly
helpful.


Klaus
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

[Neil Watson]

On Thu, Dec 18, 2014 at 09:57:21AM +0100, Klaus Kaempf wrote:
>* Moore, Joe <joe....@siemens.com> [Dec 17. 2014 18:34]:
>>
>> See for example:
>> https://github.com/jpvlsmv/cfengine-snippets/blob/master/policy/set_root_password.cf
>> and others in that directory. Suggestions and pull requests welcome
>> :)
>
>This is just wonderful, thank you Joe !

I prefer that we do not encourage such policy. That example, while
helpful as a tutorial, encourages single use policies, and results in
policy sprawl. Better to point people to reusable production code. In
this example the bundle should accept parameters.

Untested and needs more thought, but I hope my intent is clear:

bundle agent main
{
vars:
"passwords" data => parsejson( '
[
{
"user" : "root",
"hash" : "******",
"promisee" : "syadmin team"
},
{
"user" : "oracle",
"comment" : "Some DBA's like shared accounts!?",
"hash" : "*****",
"promisee" : "DBA team"
}
]
');

methods:
"set passwords" usebundle => set_password( "main.passwords" );
}
bundle agent set_passwords( passwords )
{
vars:
"i" slist => getindices( "${passwords}" );

users:
!windows:: # root is not normally found on Windows systems
"${${passwords}[${i}][user]}" -> { "${${passwords}[${i}][promisee]}" }
policy => "present",
# If the root account is not present, I
# expect bad things would have already
# happened.

password => password( "${${passwords}[${i}][hash]}" );
}

body password password_root ( hash )
{
format => hash;
# or format => plaintext; -- Not recommended.
data => "$(hash)";

[Klaus Kaempf]

* Neil Watson <cfen...@watson-wilson.ca> [Dec 18. 2014 14:31]:

> On Thu, Dec 18, 2014 at 09:57:21AM +0100, Klaus Kaempf wrote:
> >* Moore, Joe <joe....@siemens.com> [Dec 17. 2014 18:34]:
> >>
> >>See for example:
> >>https://github.com/jpvlsmv/cfengine-snippets/blob/master/policy/set_root_password.cf
> >>and others in that directory. Suggestions and pull requests welcome
> >>:)
> >
> >This is just wonderful, thank you Joe !
>
> I prefer that we do not encourage such policy. That example, while
> helpful as a tutorial, encourages single use policies, and results in
> policy sprawl. Better to point people to reusable production code. In
> this example the bundle should accept parameters.

Both examples, your's and Joe's should be published.

Joe's because it's well documented and easy to understood. And your's,
while more complex, shows better 'style'.

Maybe accompanied with an in-between example, highlighting problems in
the simple one.

Just a thought ...