I would create a custom define to add/edit limits.conf and sysctl.conf
lines into some "base" module, then call that define in a simple module.
I don't know much about your internal processes but it shouldn't really
be that much work - you'll probably spend more time documenting it than
writing it ;-) If you make the limits.conf and sysctl.conf defines
reusable enough you can avoid problems down the track with a dozen
different admins editing these files a dozen different ways (exec sed vs
augeas vs file resource, etc). Personally I've used augeas for something
only to find out someone using sed to change the same field a few weeks
later - makes for interesting debugging.
Also, even though it might be 8 nodes now, you have the added bonus that
if you lost those servers in a disaster you know how to rebuild at least
this part of them. What starts as 8 now may be more in 6 months time -
though I'm pretty sure I don't need to tell you of the quadruple digit
infrastructure this phenomenon ;-)
On 18/11/11 15:26, 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).
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?
Thanks!
Jake
--
Luke Bigum
Information Systems
+44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way.
If you are not a named recipient please notify the sender immediately and
delete any copies of this message. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any view or
opinions presented are solely those of the author and do not necessarily
represent those of the company.
--
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.
