So I seem to remember an old discussion here where people here were reasonably consistent in thinking they didn''t want to have puppet update packages automatically, either through a total "yum update" or through individual services being set that way. What *do* you do? Say I''ve got 6 systems I want to keep in sync. Let''s say I upgrade one system manually and test a bit, and then want to make that upgrade general. Do you do that through puppet, or what? --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Right now, that''s still one of the few things we do "by hand"
on our
systems. Upgrade/patch the test system sometime during the day; then
upgrade/patch half the production one night, then upgrade/patch the
other half of production another night.
I''ve considered having puppet do it, but I noticed 2 problems with
that plan:
1) There doesn''t seem to be any way to use the package type to run
something like "yum -y update" or "up2date -fu". I did an
experiment
with "Package { ensure => latest }" and that only works for
packages
already being managed (which really can''t be scaled up to work for
this problem). And there''s nothing like "package {
''*'': ensure =>
latest }" either. (it''s important that this do the right thing
with
kernels (install new; leave old alone) and that I can still force it
to skip some packages if I need to...
2) The schedules aren''t flexible enough for our business
requirements. I really need something like "between 5:30pm and 8:00pm
on November 19, 2008" in order to match specific planned maintenance
windows for specific systems. Not just any wednesday, but only that
specific time window on that specific date.
On Nov 25, 2008, at 3:27 PM, dd-b wrote:
>
> So I seem to remember an old discussion here where people here were
> reasonably consistent in thinking they didn''t want to have puppet
> update packages automatically, either through a total "yum
update" or
> through individual services being set that way.
>
> What *do* you do? Say I''ve got 6 systems I want to keep in sync.
> Let''s say I upgrade one system manually and test a bit, and then
want
> to make that upgrade general. Do you do that through puppet, or what?
> >
>
--
Eric Eisenhart <eric.eisenhart@sonoma.edu>
Lead Unix/Linux System Administrator
1.707.664.3099
Sonoma State University, Information Technology
Jabber/XMPP: eisenhae@jabber.sonoma.edu
AIM: ericeisenhart
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
I have always been on the fence with this issue.
There are certain things you are able to mange with puppet with the
use of "ensure => latest" (at least it has always worked for me)
Some people say, puppet is meant to maintain a stable build of your
system not update it.
And some people say, puppet is meant to deploy new configurations and
update packages where need be.
As you can see it is all what is in the end user''s best interest.
There is such a thing as schedules,
http://reductivelabs.com/trac/puppet/wiki/TypeReference#id191
Off that page the most useful example would be:
schedule { daily:
period => daily,
range => [2, 4]
}
exec { "/usr/bin/apt-get update":
schedule => daily
}
However, it seems that it doesn''t exactly fit what you are looking
for.
Maybe use puppet to manage a cron job that stops puppet for the
duration of your time-frame?
As I see it, upgrading packages can be very dangerous, especially if
it is done "automagically".
Imagine you are using a redhat based distro, and you have your own yum
repo which is managed internally, it has two parts:
1, base pristine copy of the default install packages for whatever
your flavor is.
2, internal rpm repo, all of your "custom" built rpms for apache,
ruby, php, kernel etc.
Some of those "custom" rpms are fairly trivial but all of them can
potentially break your entire server/site.
It''s really hard to say what is the best route for it, I can''t
answer
it myself, I just go with what fits for my team and my situation.
Most packages I have are handled by puppet, there are a few packages
that I will not ever let puppet manage, Kernel etc..
So, my next question is, would you really want to do a "yum upgrade"
on a system? (glibc would suck)
It seems like a lengthy process for something that could be done
simply by re-kickstarting and running puppet against a new distro
version.
(from kickstart to ready for code is 7.8minutes, something ridiculous
like 5 minutes for a Xen VM)
To get around a lot of the issues of upgrading packages, I came up
with an interesting solution, use puppet to manage a cron job.
The cron job will run on a nightly schedule and pretty much to a
"puppet --dry-run --no-background --tags rpm_install" on a config set
that is labeled "testing" in SVN, then I ship off the logs and see
what would happen if that testing branch were put into production.
Of course there is a little more to it, but when you have thousands of
servers with about 15 different build types, all you need to do is run
one test job on one of each build type.
For managing 6 systems, performing a maintenance by hand shouldn''t be
hard, look into cap shell, or even cssh.
Hope that all makes some sense, that is a half-nut-shell of what my
standard practice is.
-Jason
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jrojas wrote:> I have always been on the fence with this issue. > There are certain things you are able to mange with puppet with the > use of "ensure => latest" (at least it has always worked for me) > Some people say, puppet is meant to maintain a stable build of your > system not update it. > And some people say, puppet is meant to deploy new configurations and > update packages where need be. > As you can see it is all what is in the end user''s best interest.I think this issue can be divided into: * Knowing which boxes needs an upgrade * Running the upgrades To know which boxes needs an upgrade, I''ve added: cron { "yumcheck": command =>"/usr/bin/yum check-update > /var/run/yum.check-update", user => root, hour => [2,15, 22] } I then use a script from [1] combined with snmpd to have nagios check if the box needs an upgrade. I usually run the upgrades by hand, but I''m thinking that a tool like func[2] is what should be used for this kind of thing. 1. http://www.logix.cz/michal/devel/nagios/ 2. https://fedorahosted.org/func/ Tarjei> > There is such a thing as schedules, > http://reductivelabs.com/trac/puppet/wiki/TypeReference#id191 > Off that page the most useful example would be: > > schedule { daily: > period => daily, > range => [2, 4] > } > > exec { "/usr/bin/apt-get update": > schedule => daily > } > > However, it seems that it doesn''t exactly fit what you are looking > for. > Maybe use puppet to manage a cron job that stops puppet for the > duration of your time-frame? > > As I see it, upgrading packages can be very dangerous, especially if > it is done "automagically". > Imagine you are using a redhat based distro, and you have your own yum > repo which is managed internally, it has two parts: > 1, base pristine copy of the default install packages for whatever > your flavor is. > 2, internal rpm repo, all of your "custom" built rpms for apache, > ruby, php, kernel etc. > > Some of those "custom" rpms are fairly trivial but all of them can > potentially break your entire server/site. > It''s really hard to say what is the best route for it, I can''t answer > it myself, I just go with what fits for my team and my situation. > Most packages I have are handled by puppet, there are a few packages > that I will not ever let puppet manage, Kernel etc.. > > So, my next question is, would you really want to do a "yum upgrade" > on a system? (glibc would suck) > It seems like a lengthy process for something that could be done > simply by re-kickstarting and running puppet against a new distro > version. > (from kickstart to ready for code is 7.8minutes, something ridiculous > like 5 minutes for a Xen VM) > > To get around a lot of the issues of upgrading packages, I came up > with an interesting solution, use puppet to manage a cron job. > The cron job will run on a nightly schedule and pretty much to a > "puppet --dry-run --no-background --tags rpm_install" on a config set > that is labeled "testing" in SVN, then I ship off the logs and see > what would happen if that testing branch were put into production. > Of course there is a little more to it, but when you have thousands of > servers with about 15 different build types, all you need to do is run > one test job on one of each build type. > > For managing 6 systems, performing a maintenance by hand shouldn''t be > hard, look into cap shell, or even cssh. > Hope that all makes some sense, that is a half-nut-shell of what my > standard practice is. > > -Jason > > >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLQmRYVRKCnSvzfIRAg81AJ4tMqX1kpV2dhb/Tu5LChAK5+wBxgCgn8Yp inA4hObpDdHk23YuVWFeFOk=nS1j -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> Subject: [Puppet Users] Yum update > > What *do* you do? Say I''ve got 6 systems I want to keep in sync. > Let''s say I upgrade one system manually and test a bit, and then want > to make that upgrade general. Do you do that through puppet, or what?I take a pragmatic approach: if the package comes from our custom repository I have ensure => latest - the reason being that we control what goes into that repo and we are all aware that adding a new version of a package into the repo will also deploy it: simply saves a few steps. However I don''t think puppet is the correct tool to _directly_ update your entire system. We prefer to use a combination of yum versionlock, yum updatesd and other yum plugins which gives us quite fine grained control of updates. We then control the configs & deployment of those plugins via puppet - so puppet does our "meta package management"... -ross --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---