Can any one clarify this, is auto updating at all production servers recommended or not? need to know your opinion, how do you manage the update? -mu
madunix wrote:> Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update?I guess that depends on your situation. For me, if it's a package that I know isn't going to mess with users being logged on, or something of the like, then I don't see it as a problem. But if it's a package update like samba, or httpd, or something similar, you might want to hold off on auto updates until you can do them manually and restart any services that are needed with it. I know this doesn't answer your question directly, but I think it's dependent on the packages being updated. Personally I like to restart immediately any services associated with the updates, then you know any and all files that are changed with the update are applied. Regards, Max
madunix wrote:> Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update? >I don't, but I watch the centos-announce list to see when important updates are released. Our operations dept schedules all changes on a shared calendar so no one is surprised, although I can't recall a centos update ever causing a problem. After doing a minor update on a non-production machine, I might just 'ssh servername yum -y update' to a list of production servers. For larger sets or point releases, I would first have done a 'yum install yum-downloadonly' on each server so I can 'ssh servername yum -y --downloadonly update' which can run unattended ahead of time, then when it is convenient to babysit the box, complete the update and reboot. For point releases, be sure to read the release notes - there may be special instructions like the need to update glibc\* separately for 5.3. -- Les Mikesell lesmikesell at gmail.com
madunix ha scritto:> Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update? > > -muI'm a very lazy sysadmin, and, although I know that is better to have full control over updates... I let yum-cron do the updates for me. I administer very few server, I always have a good backup handy, and wen I'm on vacation I disable the auto-updates... For now (about 3 years of doing this) I never had real issues. The worse thing that happened was the updates not working for some dependency issue, which needed to be sorted manually. Again, I guess it really depends on what you are administering and if/how you can handle a server outage, so you have to carefully make your own decision based on your environment. -- Regards Lorenzo Quatrini
On 8/13/09, madunix <madunix at gmail.com> wrote:> Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update?The NSA Guide to the Secure Configuration of RHEL 5 indicates this is OK, but not with updatesd which they believe is not mature enough for an enterprise environment and may introduce unnecessary overhead. They suggest a cron job that calls yum to do this. Lanny http://lowcostmagazines.com
On Thu, Aug 13, 2009 at 7:59 AM, madunix<madunix at gmail.com> wrote:> Can any one clarify this, is auto updating at all production servers > recommended or not? > need to know your opinion, how do you manage the update?For a production server, I don't auto-update. There are too many variables involved that may negatively affect the server's functions. When implementing updates, I prefer to plan ahead, test on a non-critical server, create a change plan that includes a roll-back plan, and then schedule an outage window that allows enough time to revert to the original version if necessary. If it's a minor update that should not in any way negatively affect a production system, I might skip scheduling an outage window, but I'll still have a roll-back plan. This may be an overly cautious approach, but it's the one that I use for production systems. HTH, M