Unix tip: Putting old systems to sleep

I had to pull the plug on some really old systems recently, yet leave them in a state from which they could be easily booted at some later time if needed. The process turned out to be a bit more complex than I had imagined. For one thing, these systems were of various “vintages”. The oldest were still running SunOS 5.6 (Solaris 6). For another, the systems were mounting an assortment of file systems from other systems and binding to several NIS servers. I realized that there are a lot of things that I needed to think about when shutting down a system that has been working in close association with other systems and that just might have to be rebooted some time in the future — maybe as far out as in another year or two.

When putting to sleep a system that might be needed in the future, you want to make sure that it can be rebooted independently of other systems, just in case the systems that it depends on for services today are no longer operational when the time comes to bring the old system back to life. Minimal documentation of the system’s configuration can also come in handy if only to remind you in another year or so what exactly it is you’re rebooting.

The first thing to think about is the root login. Someone deciding to resuscitate one of these systems years from today could always jumpstart the box or boot it off installation media but, if the point of putting the system to sleep was to preserve an old environment in case it’s ever needed again, you should probably leave the system in a state from which it can be brought back to life in basically the same condition it was in when it was shut down.

You might consider giving the system an obvious root password or even tagging it with the root login. This depends, of course, on what’s on the system and whether anything of value would be at risk. You might consider having a standard root password just for systems that are shut down for later use.

It’s also a good idea to record the system’s IP address, default router and the like. If one of these systems is left shut down for a long time, there’s a good likelihood that its IP address will be reused for another server. In this case, you won’t be able to simply connect it to the network and turn it on. Knowing that you need to reconfigure it first could simplify planning for its recovery.

If you tag the system with its current configuration, you’ll at least know what you might need to change to put it back in service. I have been recording a system’s IP address, default router, netmask and OS revision along with a general description of how the system was used. This way, should we ever need it again or decide to sell it on eBay, we know without rebooting it what we have to do to get it ready.

Before you shut down a system for possible reuse later, you should make sure that it doesn’t hard mount file systems from other servers. This has generally been true of systems since automounting first came into being, but it’s worth checking.

NIS clients will hang at boot time if they cannot bind to the appropriate NIS server, so I copy the /etc/nsswitch.files to /etc/nsswitch.conf and move /var/yp to /var/yp- to make sure no one will run into this problem. It’s easy enough to reverse these changes if needed.

Before shutting one of these old systems down, I make sure we have:

• the root password
• the ability to log in remotely as root (in case access to the console is a challenge)
• some local user accounts with clearly documented logins
• that no hard mounts from other systems are configured
• that naming services will not hang the system at boot time
• that services requiring that other systems be available (e.g., if sshd is on a file system mounted from another server) are turned off (e.g., moving S99sshd to s99sshd)
• that we’ve recorded the basic configuration of the system to ease its eventual reuse

In all likelihood, most of these systems will never be turned on again. It’s good to know, however, that if someone needs to bring one of these very old systems back online, we can reboot it and get in back into place on the network without a lot of stress.