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