Re-configuring a Server
By Erik Rodriguez
This article provides the proper way to re-configure, migrate, or backup a server. While it may seem obvious to the normal tech buff, this process will ensure you don't "forget anything."
Like everything in the I.T. world, network servers need to be upgraded. It may be something as simple as a seldomly used application or something as large as a new kernel. However, everyone system admin has done it before. You made some changes to a machine, minutes, hours, or days later you realize you forgot something. This usually means going back and spending twice the time it took you do perform the initial system changes. How can you prevent this situation from happening? It's simple, follow the four steps listed below.
Think carefully! Evaluate the type of changes you need to make. Are you doing or a routine security patch or package upgrade? Maybe your re-tuning the kernel of a Linux box or some other task that requires taking down or rebooting the server? If do need to bring the machine down, consider an appropriate time. Let the users know what is going on and plan accordingly. Letting the users know a week in advance provides enough leeway so they don't blame I.T. for not being able to complete their work. There are times when you may need to make changes or immediately because of a hardware failure or security issue. For information in that issue click here.
Make A List
This is where most mistakes are made. As tedious as it may seem, making a list is the best way to assure you don't forget something. What type of list should you make? Depending on your project, you may need an array of lists. Don't try to remember things in your head. Yes it works most of the time, but there will be a time you forget something. For example, if you are migrating a server from Windows to Linux, you may want to make the following lists:
- Running Services (DHCP, DNS, etc)
- IP addresses, Computer Names, OS version
- Exact numerical value of backed-up data (ex. 75,532,674 bytes)
- List of User Accounts
Always test your changes. Never assume that they will work. Think of it like locking a door. How many times have you locked a door and immediately checked to see if it was locked? You're always better safe than sorry. Nothing is worse than getting a phone call because things didn't work right, and now people can't access the server to perform their work.