I couldn't agree more. Updating your desktop without vetting the updates might be one thing, but doing so on a production server is nothing short of reckless.
The problem is rarely going to manifest itself in the server itself, but rather on some application that you just broke due to an incompatibility with a library that you just updated. I always snapshot before updates these days. I don't have the luxury of a full test/QA environment, so snapshots at least allow you to roll back from the inevitable "bad update." It's not a matter of if, but when. On Sat, Oct 24, 2015 at 1:33 PM, Andrew Farnsworth <[email protected]> wrote: > John, > Depending on the application involved it could be safe to upgrade > regularly without preparing an update impact document, or it could be > disastrous. Some steps you can take that will drastically reduce the risk > involved are: > > 1) Backup your system regularly (nightly? more often? Depends on the > system and your business needs) > 2) Have a non-production system that is identical to your production > system and update it first and test it. > This is standard best practice for updating enterprise > systems. > 3) In hand with #1 above, if you are running virtual machines (which you > should be these days) take a snapshot prior to the update, then run the > update. If something in the update trashes your system, revert to the > snapshot and then instigate a full investigation into what in the update is > causing the problem. > > This last will let you run in almost the same fashion you currently are > (it adds one or two simple steps) but will provide you with the protection > you need. > > Andy F > > On Sat, Oct 24, 2015 at 12:54 PM, xor <[email protected]> wrote: > >> I have a contract where as part of my duties involve maintaining 5 >> different Linux servers (both Ubuntu and CentOS). An unwritten aspect of >> my duties is to periodically educate some people there about certain >> technical topics. This month's topic has to do with the updating of their >> Linux servers. For over two years I've been quietly updating the servers >> almost on a daily basis. As these servers are remote, I'd ssh in and do >> what I needed to do. >> >> Now all of a sudden, someone there is wanting me to document the updates >> and how the updates might affect our software before I apply them, etc >> etc. Tell me if I am wrong, but I have explained to them this is not a >> reasonable request. However, one person in particular with a big business >> mainframe mentality can be very stubborn about things such as this. So I >> could use a little help. >> >> If someone can direct me to a document or article explaining in non >> technical terms what the common practices are for updating and/or >> maintaining a Linux server I would greatly appreciate it. (If only a >> technical document is available, I'll take it.) I was hoping to find a >> "Linux Journal" type of article, but have been unsuccessful in finding such >> a thing. My goal is to have a reference that I can pass to my contract >> that can be read and understood by someone with very limited Linux systems >> knowledge. >> >> John >> >> -- >> -- >> You received this message because you are subscribed to the Google Groups >> "NLUG" 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/nlug-talk?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "NLUG" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > You received this message because you are subscribed to the Google Groups > "NLUG" 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/nlug-talk?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Allen Minix / KM4DCZ Check out my blog! - http://thefatpenguin.blogspot.com -- -- You received this message because you are subscribed to the Google Groups "NLUG" 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/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
