Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Process for Decommissioning Unix Servers 1
- Thread starter mohmin
- Start date
-
1
- #2
- Thread starter
- #3
Decommissioning a Machine
There are lots of things to remember when decommissioning a machine. Not all of these will apply in every case. Help with many of them can be obtained from Operations.
General
On the Machine Itself
The intent is recover anything of value, and then make what's left safe to "surplus". That means that someone, possibly from outside your comapny, may take possession of the machine.
An alternative involves keeping the machine, typically for non-production use, e.g. testing. In that case, make sure that the machine is prominently labelled as such, and that it isn't put on the "surplus" inventory, so that it isn't unintentionally surplused.
* notify users
o check usage logs and (typically) e-mail the users to be affected, telling them why the service change is happening, and what they have to do (if anything) to use the replacement services.
* move services provided by this machine, e.g.
o move mailing lists to wherever the name is MX'd to. Both majordomo and simple include files are common implementations.
o printers being driven directly by the machine
o time service (NTP)
o o mail reading services (POP and IMAP)
o mail sending services
* remove private or sensitive files
o licensed software (including the operating system)
o user data (home directories)
o any other private or sensitive files
Maybe simply scrubbing the disks is best and easiest.
* remove the PROM password so whoever buys the machine can stand a chance at reinstalling it
Elsewhere
* cancel maintenance contracts. This usually requires notification in advance of the retirement.
* Notify tech support that the machine is being decommissioned so they can stop charging the owner, update our equipment database, prepare forms for sending the machine to surplus, etc.
* notify someone to cease backups.
* notify tech support to cease account creation on the machine.
* update the DNS.
o remove the address record.
o keep e-mail addresses working. Add an appropriate MX record, in order to keep mail working, and to prevent the name from being reused for a while. If for some reason an MX can't be added, find some other way to reserve the name for a while (on the order of a year).
* preserve URLs. It's not practical to change all of the references in the world to a URL. So if it ran a preserve its URL if possible.
* update NFS configuration on NFS servers and clients of the machine. This can include related files like /etc/netgroup (on UNIX systems).
* redeploy software licenses from the machine being decommissioned and update documentation for licenses. And there's an online list of licensed software as well.
* delete e-mail entries that refer to the machine, as in theory they'll reappear properly if needed.
* update that refer to the machine.
* check hosts that have privileged access to the machine for any dependency, e.g. in configuration. On UNIX systems, ~root/.[rs]hosts should be examined.
* configuration that directs machines to services provided by the decommissioned machine, e.g. /software/ntp-config/data/ntp-servers.dat on UNIX systems.
UNIX Specific
On Related Machines
* remove from configuration on the admin master for the machine. In theory, that's anything in /.software/admin/*, but in practice we'd hope that /.software/admin/*/config/* would be enough. Examples of packages that are known to have hostnames in admin specific files are:
o console
o lpr
o setpw
o xhier
* remove from configuration on the regional master for the machine. In theory, that's anything in /.software/regional/*, but in practice we'd hope that /.software/regional/*/config/* would be enough. Examples of packages that are known to have hostnames in regional files are:
o hostselect
o sendmail
o x11-mfcfenv
o xhier
However, this doesn't mean removal is always appropriate. For example, when a retired host was a sendmail client of a server, and you create an MX record as described above, you need to leave the retired host included as a sendmail client.
* remove from access-rights file(s) on machines that supply it with software (including those in other administrations).
* remove from /etc/hosts.equiv file(s).
* remove from packages that know about the name for other reasons. /software/*/export/hosts/* often contains such information, that is almost always gathered in /software/.admin/hosts/*. Look for packages that provide configuration for other machines, so that they no longer attempt to configure an absent host.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."
There are lots of things to remember when decommissioning a machine. Not all of these will apply in every case. Help with many of them can be obtained from Operations.
General
On the Machine Itself
The intent is recover anything of value, and then make what's left safe to "surplus". That means that someone, possibly from outside your comapny, may take possession of the machine.
An alternative involves keeping the machine, typically for non-production use, e.g. testing. In that case, make sure that the machine is prominently labelled as such, and that it isn't put on the "surplus" inventory, so that it isn't unintentionally surplused.
* notify users
o check usage logs and (typically) e-mail the users to be affected, telling them why the service change is happening, and what they have to do (if anything) to use the replacement services.
* move services provided by this machine, e.g.
o move mailing lists to wherever the name is MX'd to. Both majordomo and simple include files are common implementations.
o printers being driven directly by the machine
o time service (NTP)
o o mail reading services (POP and IMAP)
o mail sending services
* remove private or sensitive files
o licensed software (including the operating system)
o user data (home directories)
o any other private or sensitive files
Maybe simply scrubbing the disks is best and easiest.
* remove the PROM password so whoever buys the machine can stand a chance at reinstalling it
Elsewhere
* cancel maintenance contracts. This usually requires notification in advance of the retirement.
* Notify tech support that the machine is being decommissioned so they can stop charging the owner, update our equipment database, prepare forms for sending the machine to surplus, etc.
* notify someone to cease backups.
* notify tech support to cease account creation on the machine.
* update the DNS.
o remove the address record.
o keep e-mail addresses working. Add an appropriate MX record, in order to keep mail working, and to prevent the name from being reused for a while. If for some reason an MX can't be added, find some other way to reserve the name for a while (on the order of a year).
* preserve URLs. It's not practical to change all of the references in the world to a URL. So if it ran a preserve its URL if possible.
* update NFS configuration on NFS servers and clients of the machine. This can include related files like /etc/netgroup (on UNIX systems).
* redeploy software licenses from the machine being decommissioned and update documentation for licenses. And there's an online list of licensed software as well.
* delete e-mail entries that refer to the machine, as in theory they'll reappear properly if needed.
* update that refer to the machine.
* check hosts that have privileged access to the machine for any dependency, e.g. in configuration. On UNIX systems, ~root/.[rs]hosts should be examined.
* configuration that directs machines to services provided by the decommissioned machine, e.g. /software/ntp-config/data/ntp-servers.dat on UNIX systems.
UNIX Specific
On Related Machines
* remove from configuration on the admin master for the machine. In theory, that's anything in /.software/admin/*, but in practice we'd hope that /.software/admin/*/config/* would be enough. Examples of packages that are known to have hostnames in admin specific files are:
o console
o lpr
o setpw
o xhier
* remove from configuration on the regional master for the machine. In theory, that's anything in /.software/regional/*, but in practice we'd hope that /.software/regional/*/config/* would be enough. Examples of packages that are known to have hostnames in regional files are:
o hostselect
o sendmail
o x11-mfcfenv
o xhier
However, this doesn't mean removal is always appropriate. For example, when a retired host was a sendmail client of a server, and you create an MX record as described above, you need to leave the retired host included as a sendmail client.
* remove from access-rights file(s) on machines that supply it with software (including those in other administrations).
* remove from /etc/hosts.equiv file(s).
* remove from packages that know about the name for other reasons. /software/*/export/hosts/* often contains such information, that is almost always gathered in /software/.admin/hosts/*. Look for packages that provide configuration for other machines, so that they no longer attempt to configure an absent host.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."
- Status