inline On Fri, Nov 18, 2011 at 07:26:45AM -0800, Jake - USPS wrote: > We have an environment of thousands of servers. Up to this point we > have been using puppet to manage resources common to all systems (ntp, > ssh, etc) which are managed automatically (without manually assigning > class/module to a system) and also resources for applications that > make up a majority of our environment (Oracle DB, WebSphere, etc) > which are assigned via ENC to specific systems (foreman hostgroups). > > What I am now running into are requests to modify a small amount of > systems for a few resources. Just recently a small new app needs 2 > limits.conf entries on like 8 systems. It seems like a waste of time > to me to craft and manage a recipe for this app to manage these > resources. But, it would still be nice to have this managed by puppet > somehow for all the benefits puppet brings (standardization, > documentation, etc). Also, I see lag time between crafting a recipe > after a request and then pushing the recipe out to the environments > before it would be applied to a system so that the app can then run/ > install (although I know we can add it manually in the meantime, but > then your sort of doubling up on work).
If you put the effort into revision-controlling and puppetizing any specific configuration item, then in two years when somebody wonders what is configured on a system they will be able to dig into your manifests and know. It's well worth the initial wait. You can always, depending on your config, "puppet kick" the hosts which need changing right now. Or somehow orchestrate that these reapply the current config right now. If you aren't able to orchestrate, then the cheap cousin might be uploading the puppet manifest to the hosts and having puppet configure that. When the regular run comes around it'll do nothing since limits.conf is already the new one. (This option is vastly less preferable to orchestration.) More specifically, there's an example for modifying limits.conf with the augeas type: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Augeas#/etc/security/limits.conf > How do other people handle managing 'one offs' like this? I'm > wondering if there is a way to create a generic limits.conf module > that could take parameters from an ENC somehow and then manage the > resources? That way I do not need to make new modules for app that > maybe just modify limits.conf or sysctl.conf with a couple of lines, > and then I have the changes documented and managed. Or do people just > create a new module for every little app that comes along? node "specialserver.mine.com" { # everything that a generic host needs in our environment # snmp, ssh, ldap auth, puppet, apt/yum sources, etc. class { 'standardhost': } # special shiny thing that only this subset of hosts does # inside this module would be your lookups, I suppose class { 'limits': } } This doesn't scale way, way up without automagic manifest generation, but it's useful at our scale and number of special servers. It's also fairly easy to see in the puppet tree which nodes get the limits class/module. On the other hand, your limits class could go everywhere and check if it's supposed to apply the new limits.conf file. That might mean puppet cycles everywhere for only eight servers and perhaps not worth the cost. (I take it by your domain that you scale way, way, way up. I'm not sure of your values for "might" and "perhaps".) To arrange networking on the initial server powerup I use a magic variable in the node definition which the networking class applies. It's a bit horrible, but then some hosts have fairly twisty networking. > Thanks! > Jake > > -- > 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 > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- 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 puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
