Justin Kinney wrote: >> I'm new with Puppet and as far as I have searched I couldn't find a >> very good solution for updating some machines over the network. I >> > > I think that many on the list feel that you should use the correct > tool for the job here, which in your case sounds like an apt-get or > equivalent via cron. I do the same here on sles boxes via zypper and > rug. > > >> could use Puppet to do a cron job for that but I don't have so much >> control over the updates and I want to have a more flexible option for >> > > Here's how I handle this: > > Updates are mirrored from Novell and stored in a sandbox repository. > The sandbox hosts apply updates every Friday via a cron job. This > includes updates that require a reboot. > > The sandbox repo is mirrored up to the test layer every two weeks, > which gives us a chance to catch anything that really breaks our > environment. > > Once we are comfortable with the patches in test, we mirror the repo > up to the production layer. Updates are not automatic here. Instead, > a cron job runs a script that generates a report that details all of > the updates ready to be applied, including the category of update, and > whether a reboot is required. It sends this report to our ticketing > system and cc's it to an admin mailbox. Based on that ticket, an > administrator creates a change control request to apply the updates > listed. > > >> starting those updates other than a cron job and I don't want to >> distrub the people who are using those machines for updates. >> > > The obvious thing to do here would be to schedule the updates for off > hours. In my case, the production updates are done by hand by an > administrator. > > >> Have you done something like that or do you have some ideas? By the >> way, the machines which I want to update are installed with Ubuntu. >> > > The reporting tool I mentioned is available here - you may be able to > adapt this for Ubuntu: > > http://blog.barfoo.org/2008/08/16/zypper-update-report-was-patch2mail-for-sles10/ > > --Justin > > > > Justin's definitely laid out the enterprise way of doing this. If you don't have rigorous testing like this, you can run the updates via a capistrano task. (This is what I do) I have tasks for each site that is named aptup_${sitename} then I also have an aptup task that takes an argument (server name) in case I need to do a one off. This way you get the output of the upgrade, but for something silly or trivial you can upgrade whole sites without much to worry about.
-- Joe McDonagh Operations Engineer www.colonfail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
