>>> 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.
You will be amazed at what templating can do for you here. The generate function and content attribute has alot of interesting possibilities to help with this. Assuming you have more or less standard setting but need to do small tweaks, you use generate function to call a server side script to create the file data on the fly from facts and policy scripts. also I see no one has pointed that if you have a large number of nodes you will probably want to use and LDAP tree for your node declarations. It is a bit more versatile than in manifest node definitions and is easier to parse for security audit tools. >> 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. The key here is learning to think like puppet. That is the absolute hardest part of the equation. Only suggestion I have to help here is to go back through the examples in Pulling Strings and understand who the approach there differs from the procedural or "SSH" approach. >> 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 :). >> >> 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 :). >> Not sure about any other books, but James is on the list and really good at tossing those useful tidbits of knowledge in an understandable way. I don't have near the setup some of the guys on here do, but I can say that puppet paired with version control for the manifests has really helped here by forcing a minimum level of documentation to all system changes and configurations. Evan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
