If you’ve been an AIX systems administrator for a while, you know that when you've finished building a server and installing an OS, you haven't really finished building the server. Developers or application owners might think that because a system is up and pingable they can go ahead and load all their stuff onto it, but there’s still a lot of other work that must be done to make the system usable. In this fifth and final article in my "Secrets of an AIX Administrator" series, we’ll walk through the steps admins should take immediately after building an AIX server from scratch for the first time—the tasks you need to perform to complete the server-building process.
Step 1: Lock Down Root
The very first step you should take after your server reboots following the installation of AIX is to change the root file system password. This is when the server is most vulnerable to problems, and the key to the kingdom must be secured.
Step 2: Mirror the OS
If you’re using internal drives, I recommend that at this time you mirror the root volume group (rootvg) because there will be next to no I/O going on with the server. Although mirroring should typically fall later on the priority list, it’s worth your while to take 20 minutes now to have the system mirror the rootvg, instead of later on, when you'll be contending against users logging in and doing their initial configuration.
Step 3: Patch the Server
Similar to mirroring the OS, if you patch your server with the proper technology level (TL) and service pack (SP) at this point in the process, you’ll also avoid the hassle later on of trying to find a window of time in which to reboot the server. Patching the server now provides the additional benefit of letting you establish an expectation for the OS deployment, which will prevent users from complaining about future patching interfering with their installations and software.
Step 4: Set the Date and Time Zone
Although your server will likely have the correct time by this point, check the TZ variable in the /etc/environment file. Make sure that the system's time zone is in the correct locale, or set the time zone if your project requires doing so. You want to avoid the painful future scenario of discovering that a database or web page has been logging time in GMT when the system should have been in PST, requiring records to be backlogged or skipped forward by hours to correct the discrepancy. Also, by this point in the process, you shouldn’t have to reboot your server from now on for any further initial OS work.
Step 5: Disable Unnecessary Network Services; Install and Use SSH
The /etc/inetd.conf file is chock-full of various network services, from telnet and ftp to rsh and fingerd. Pretty much every service running either poses a security risk in today's world or is unnecessary. Thus, you should comment out the entire file and refresh the inetd daemon and instead use more secure communication protocols such as Secure Shell (SSH) for your communications to and from the server.
Step 6: Set Up IPs
Now that your system is secure from both a login and network perspective, this is the time to set up the IP addresses that you’ll need for communicating with the world.
Step 7: Grow and Develop rootvg File Systems
Depending on physical partition sizes, when an AIX server is built from scratch, the process will typically create the file systems on the server with the minimum amount of necessary space possible. This space limitation will become a hazard as soon as the server is put into use, so as a starting point, I recommend growing the file systems to at least the sizes listed in Table 1.
Step 1: Lock Down Root
The very first step you should take after your server reboots following the installation of AIX is to change the root file system password. This is when the server is most vulnerable to problems, and the key to the kingdom must be secured.
Step 2: Mirror the OS
If you’re using internal drives, I recommend that at this time you mirror the root volume group (rootvg) because there will be next to no I/O going on with the server. Although mirroring should typically fall later on the priority list, it’s worth your while to take 20 minutes now to have the system mirror the rootvg, instead of later on, when you'll be contending against users logging in and doing their initial configuration.
Step 3: Patch the Server
Similar to mirroring the OS, if you patch your server with the proper technology level (TL) and service pack (SP) at this point in the process, you’ll also avoid the hassle later on of trying to find a window of time in which to reboot the server. Patching the server now provides the additional benefit of letting you establish an expectation for the OS deployment, which will prevent users from complaining about future patching interfering with their installations and software.
Step 4: Set the Date and Time Zone
Although your server will likely have the correct time by this point, check the TZ variable in the /etc/environment file. Make sure that the system's time zone is in the correct locale, or set the time zone if your project requires doing so. You want to avoid the painful future scenario of discovering that a database or web page has been logging time in GMT when the system should have been in PST, requiring records to be backlogged or skipped forward by hours to correct the discrepancy. Also, by this point in the process, you shouldn’t have to reboot your server from now on for any further initial OS work.
Step 5: Disable Unnecessary Network Services; Install and Use SSH
The /etc/inetd.conf file is chock-full of various network services, from telnet and ftp to rsh and fingerd. Pretty much every service running either poses a security risk in today's world or is unnecessary. Thus, you should comment out the entire file and refresh the inetd daemon and instead use more secure communication protocols such as Secure Shell (SSH) for your communications to and from the server.
Step 6: Set Up IPs
Now that your system is secure from both a login and network perspective, this is the time to set up the IP addresses that you’ll need for communicating with the world.
Step 7: Grow and Develop rootvg File Systems
Depending on physical partition sizes, when an AIX server is built from scratch, the process will typically create the file systems on the server with the minimum amount of necessary space possible. This space limitation will become a hazard as soon as the server is put into use, so as a starting point, I recommend growing the file systems to at least the sizes listed in Table 1.
I’ll also do two other things at this time. First, I’ll break out /var/tmp into its own file system, sized at about 1GB. I’ll do this because many applications will use this space as a temporary area for files, and separating /var/tmp in this way will offset some of the risk of a user maxing out /var by doing something like using vi on a mammoth-sized file. The second thing I'll do is grow the paging space and dump devices to sizes that will work for application owners and enable the capture the data from any crashes that might happen.
Step 8: Define User IDs and Groups
Usually, I would recommend hooking users up with access (including sudo) as one of the last things to do on a server, because the users could prematurely hop onto the box and start doing work before everything is completed. But there’s one good reason I put this action here in the list of things to do: Defining user IDs makes it easier to perform the next step.
Step 9: Establish External Volume Groups
Rather than coming back around after disk space has been appropriated, logical volumes are defined, and file systems have been mounted to set ownership and permissions on all applicable directories and files, I typically prefer that user IDs (or at least the local application-specific user IDs) already exist, to make establishing external volume groups a job that can be done in one fell swoop.
Step 10: Create a mksysb image
If you haven't had a chance to do so, create a mksysb image of the server and store it away. There’s nothing more frustrating than having to redo all your work, and a mksysb image will save you time and energy in case you have to go to backups for a restore. And speaking of mksysb images…
Step 11: Create a "Golden" Image Using NIM
Ideally, you’ll only ever have to set up a server from scratch once. After you do this, the mksysb image that you created can be used as a "gold standard" from which all future AIX builds can be done, facilitated by Network Installation Manager (NIM). This golden image can be rapidly distributed to new servers, which reduces your time investment in creating AIX builds. Plus, if there are any components such as tunables, additional user IDs, or system configurations that you need to mass-distribute in the future, it's much easier to do so using a single administrative source rather than having to go out to each and every server individually.
Shorten Your AIX Learning Curve
Becoming a skilled AIX systems admin is no easy task. It will take years to develop and hone your skills and to become familiar with your servers and customers. Most professional admins I know will agree that it typically takes at least six months to become proficient with an individual component of new technology, such as when LPARs and Virtual I/O Servers came on the scene, and at least nine months of understanding your employer's business before your learning curve takes you from being dangerous to knowing the basics of how their business works.
In this five-article series, I’ve shared a number of tips and tricks I've learned along the way—sometimes painfully—that have helped me whenever I go into new environments and lay hands on keys for the first time in different industries. Integrating these ideas and concepts into your own skill set will better your chances of avoiding mistakes, improve your work, and help you develop as an AIX systems admin.
No comments:
Post a Comment