And another ... Thanks, I am done now :)
A On Wed, Nov 12, 2008 at 2:15 PM, Aaron Lippold <[EMAIL PROTECTED]> wrote: > On Wed, Nov 12, 2008 at 8:58 AM, paul matthews > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Being a recent convert and having recently gone through the kickstart >> process I may be able to offer a couple of pointers while it's fresh in my >> mind. The postinstall can just be used to pull in the puppet packages and >> start script leaving puppet to do the rest. Most of the work in my case >> seemed to get done as modules as these required pulling in associated files >> and seemed large enough pieces to justify package style treatment >> >> My layout was like this:- >> >> /etc/puppet/templates #holds .erb files >> /etc/puppet/manifests #holds nodes.pp site.pp >> /etc/puppet/manifests/classes #holds smaller .pp files that do not >> justify full module treatment e.g. motd change >> /etc/puppet/manifests/os # holds os specific classes .eg satellite >> registration >> /etc/puppet/modules # holds all the slightly bigger pieces that tend to >> pull in other files >> /etc/puppet/modules/automount >> /etc/puppet/modules/automount/files # contains auto_master etc >> /etc/puppet/modules/automount/manifests # contains site.pp with the >> automount class containing file and service resources >> /etc/puppet/modules/sshkeys >> /etc/puppet/modules/sshkeys/files >> /etc/puppet/modules/sshkeys/manifests >> /etc/puppet/modules/ldap >> /etc/puppet/modules/ldap/files >> /etc/puppet/modules/ldap/manifests >> /etc/puppet/modules/apache >> /etc/puppet/modules/apache/files >> /etc/puppet/modules/apache/templates >> /etc/puppet/modules/apache/manifests >> /etc/puppet/modules/postfix >> /etc/puppet/modules/postfix/files >> /etc/puppet/modules/postfix/manifests >> /etc/puppet/modules/mysql >> /etc/puppet/modules/mysql/files >> /etc/puppet/modules/mysql/manifests >> >> To build up the kickstart I would focus on peforming the initial >> post-install on your kickstart client. Then, on the puppet server complete a >> module and test back on the client (without kickstarting) by running puppetd >> in tag mode pointing to the newly configured module:- >> puppetd --server <server_name> --test --tags automount > > I used this type of workflow with I did similar work with the Solaris > SST for our org. Thanks for the tip. > >> >> Doing it this way may save lots of repeated kickstarts. Otherwise you will >> waste 30mins each time waiting for the os to be rebuild >> >> Having briefly looked at your kickstart file which seems largely about file >> tweaks to comply with your security guidelines I guess a lot of it could go >> in the classes directory with names such as GEN006520.pp which could >> contain a file resource to do the chmods. > > I was hoping to organize the workload into logical units of > management, such as compliant SSHd setup, banner managment, user / pam > requirements, man page requirments, etc. Then I was hoping that I > could create a map saying "Class X covers GEN1, Gen2, ..., GenN" So > that if the mapping changes or someone wants to use my classes, > modules etc but uses a different coding system to track compliance > then it could be just a matter of remapping. > > Compliance to "GENX" is almost more a reporting than it is real CM > since CM is a collection of best practices in my mind. > >> Unfortunately, in-situ file editing does not seem to be one of puppet's >> strong points at the moment so you may find yourself copying in lots of >> files or using workarounds involving exec. > > I think I only do that a few times but was hoping there were some easy > ways to manage: > > * User Setting Requirements > - MAX, MIN days etc. > - Password Complexity > - etc. etc. > * PAM Settings > * AUDITD > - setting etc. > > I guess each of these could use the file copy/module method but that > is just a step above cat > EOF which hopefully we can all get away > from at some point :). It adds an upkeep layer that I was hoping > puppet would allow me to avoid. > > Following that same naming scheme >> you could create modules in the same way eg /etc/puppet/modules/GEN006255 >> which would contain subdirs files/ manifests/ templates. The possible >> advantage of using that is that your tags would reflect the compliance >> points. The downside is that you'll probably need a look up sheet to remind >> yourself what each bit is doing > > Agreed. But again, I want to try to keep the coding a level above, > like separating implementation from interface as it were. I want to > try and make my classes, templates and facts reuseable to other users > if I can. > > One goal here would be the ability to create an appliance ( apache, > mysql, postgresql, postfix, etc. ) That can easily grab all my orgs > requirements and push them to the OS layer, App layer etc. Only > pulling the pieces of interest to the installed baseline. > > Another goal is to remove the hard tie to organization specific > mappings and help generalize to the best practice. At least that is my > goal :). > >> >> I would strongly advise btw, reading the Understanding Puppet book and all >> the references in the right hand bar of the wiki (e.g resources ref, types >> ref, style guides etc) but it sounds like in such a security conscious >> environment as yours puppet definitely fits the bill as once your systems >> are built to that spec puppet will keep them that way > > Totally agree. I have read the Pulling Strings book. Is there another > book. Google doesn't seem to think so. I want to make this CM and IA > stuff easy :) because I am a good lazy SA :). > >> >> Good luck >> Paul >> >> 2008/11/11 Aaron Lippold <[EMAIL PROTECTED]> >>> >>> Hello Puppet List, >>> >>> I was hoping to get some help starting looking at moving my current >>> kickstart baseline to using puppet. I have been reading up on puppet >>> and really think it would be a great. >>> >>> I am looking to start by making the right classes in puppet to manage >>> the configuration details in the %post section of this ks. >>> >>> There are some CM items that look fairly strait forward to implement ( >>> chmods, killing services, users etc.), however some things like pam.d >>> management, login management, sshd banner/noroot login, nosuid in >>> fstab mounts, auditd configuration management, etc. I could use a >>> little discussion on where to use modules, templates, recipes. >>> >>> I have attached a ks file with a good portion of what type of CM items >>> I need to work with so folks can get an idea of what I am trying to >>> sort out. >>> >>> Also, I would like to also like to 'tag' my CM items with specific >>> codes to match them with tracking numbers used in other systems. So, >>> "ITEM001 -> Boot loader with use a password" etc. I am hoping that >>> puppet can handle this and if necessary remap the 'tags' if I go from >>> Coding X to Coding Y. >>> >>> Any thoughts, suggestions etc. would be appreciated. >>> >>> Yours, >>> >>> Aaron >>> >>> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
