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.
