Automating TLs and service pack deployments with SUMA

 TL upgrade deployment schedule
When should you actually perform a TL upgrade? There are generally three scenarios where you will make this choice:

• When your TL is going out of the available support period.
• You want to test a new distribution level that will be going into production and need to get the longest period of fix support.
• You want to use the new features and functionality of the TL.

The short answer is that there really is no right or wrong time to perform an upgrade. Some clients need an environment that requires maximum uptime and stability. These clients typically wait until new TLs are out for at least six months to a year before applying them. Other folks will wait for several TL's to be put into place prior to upgrading to ensure maximum reliability. For clients that like to take advantage of new features and ensure that they have the latest security patches, they typically install new service packs shortly after they come out. From a vendor-support perspective, IBM would prefer if you upgraded your TLs (and service packs, for that matter) as soon as they come out. The reason is that it's just easier to support systems that are always at current levels. I like to upgrade at least once a year to a new TL. In doing so, I will also usually wait until at least service pack number two has been released. If you really want to err on the side of caution, wait until service pack number three. That way, you will know that your release is really rock solid.



                 The IBM Service Update Management Assistance (SUMA) allows you to automate the retrieval of TL and service pack deployments. In this section, you're going to use SUMA to retrieve TLs. SUMA was first released with AIX V5.3. More than anything, SUMA helps the system administrator automate the retrieval of AIX updates, allowing the administrator to get away from the mundane tasks of manually retrieving updates from the Web. Furthermore, it allows you to configure policies to automatically download either entire TL upgrades, service packs, or even interim fixes. The primary objective of the utility is to allow systems administrators to spend more time on proactive systems administration and less time on redundant or tedious work such as downloading updates.

So, how do SUMAs work? Essentially, they use a scheduling module that allows policies to be run at predefined intervals, which conform to your maintenance window. The policies can be configured easily without any extensive configuration. You even have the option to manually run SUMA (either from smit or the command line) to bring in whatever updates you require. To configure SUMA, you need to know the fix type. There are eight different kinds of fix types. They include APAR, PTF, Critical, Security, I/O Server, Latest (all fixes), Filesets (specific types), and Maintenance Levels. In addition, there are three types of actions you can perform on a policy. These include preview, download, and download and clean. Preview mode does not really do anything; it just generates a preview of what would be downloaded. The "download only" action downloads the actual data, while the "download and clean" action removes filesets no longer necessary after a new fix level has been brought down. This limits the size of the data that you'll need to keep.
You can run the suma command from either smit or the command line. In the first example, use smit to download an entire TL: # smit suma.

When the smit screen comes up, choose Download Updates Now (easy) and click Enter.
From this screen, scroll down to Download Maintenance Level or Technology Level and click Enter (see Figure 2).
  At the window in Figure 3, click F4 and choose the appropriate TL level.
In this case, it is 6100-01, as shown in Figure 4.

Figure 4. TL level of 6100-01

Click Enter and let it run. When it completes, you'll see a summary, as shown in Figure 5. This provides you with the following summary:

• 59 downloaded
• 0 failed
• 36 skipped

Now try it from the command line. In this case, you're going to download TL Two for AIX V6.1. Do this by running the suma -x command
After about 30 minutes, it completes successfully
The files get installed in /usr/sys/inst.images, which is where you would also manually put them if you were to retrieve them using different processes.
Why is SUMA important? Perhaps most importantly, it helps to ensure that your systems have the latest patches that it needs. Current fixes are important. Secondly, it downloads the patches without intervention, which allows the systems administrator to focus on more important tasks.
Fix Central
This section reviews Fix Central and discusses how to use it to download TL and service pack deployments. Fix Central is the central repository for all TLs and service packs for AIX. Among other things, you'll see how to log into Fix Central and retrieve service packs. Completely revamped in October of 2007, it provides fixes and updates for all your software, hardware, and operating systems. This includes the Hardware Management Console (HMC). Using Fix Central, you can download using the following options: by APAR, Fix ID, or Test. In addition, there are three download options, IBM Download Director, HTTP, and FTP.
Download a service pack from the exact TL that you downloaded previously during the work with suma from the command line -- 6100-02. First go to Fix Central for System p®, as shown in Figure 8 (see Resources  for a link to Fix Central).
From here, in the drop-down menu, choose your version. Another drop-down menu pops up, which is where you can select from one of the following: fix packs, fix recommendations, fix search, managing updates, and security advisories. Choose fix pack. Click Continue (see Figure 9).
  From here, select the TL: 6100-02. At this time, you can either download the latest service pack or the entire TL. Choose the entire TL (see Figure 10).
The options for download include Download Director, bulk FTP, or CD. In this case, use Download Director. I recommend this method because it has a friendly interface and there is also flexibility to pause downloads.
  The length of time is dependent on your Internet connection. For me, on broadband, this took roughly an hour.
As a systems administrator, the Fix Central URL should definitely be one of your browser favorites. Fix Central helps you keep your systems up to date and is the best method of manually retrieving data for your upgrades. You really can't be an effective AIX systems administrator without knowing how to use this tool.
Upgrading a TL
Now review the procedures to upgrade your system to the next TL.
First log in as root: # su - root. Make sure you back up your system. If you prefer, you can also use alt_disk_install or multibios; the bottom line is that you need to have a plan B if you must go back to your prior level. You should also commit them, because they can't be rejected and they also make it easier to track and reject PTFs.
Do a backup using the following command: # mksysb. When the backup is completed, you're set!
Installation
Create a .toc file. This is done by running the inutoc command (see Figure 12). You run this in the directory where your filesets reside. If you don't have the .toc file, your update will not work.


Figure 12. Running the inutoc command

 
When this is completed, you are ready to start the upgrade. Move to the directory where your .toc file resides. If you do this, you will not have to specify a path name during your upgrade: # smit update_all.


On the screen in Figure 13, you will be making several changes.

Figure 13. Update software screen

  For Input device/directory for software, put in the dot (.). If you remembered to cd to the directory that has the .toc file, you don't need to specify the full path name. In this case, you did not commit the software, though as a practical matter because you can't back out of a TL upgrade, you really should say yes to limit the amount of filesets stored on your system -- a real disk hog. In this case, you first previewed the data to ensure that there would not be any problems. This is the third option on this smit menu (shown in Figure 13). The preview option does nothing except validate whether something might be missing as a prerequisite of the upgrade. This is good to do to avoid surprises. You don't want to find out something is missing during your two-hour maintenance window of the month. You can run a preview at any time without any impact to the system.

 
In our case, as you can see in Figure 14, the preview is successful and there are no failures. So you are ready to move on.

Figure 14. Output of the preview

  When you are ready to run the upgrade, change the preview to no. You will also have to change the default field that relates to << Accept new license agreement >>. For some reason, AIX defaults to no. Change it to yes.


 
After you click Enter, it will prompt you to make sure you want to do this. Click Enter to continue to start the process (see Figure 15).

Figure 15. Start the upgrade process

  This can run for up to an hour, depending on the speed of your system and the type of upgrade you are performing. When the process is complete, you can scroll down to the summary section to see if you've been successful, which in this case is yes. (see Figure 16).

Figure 16. Success

 
Your final step is to reboot the box. Make sure you perform this step before bringing your applications back and going live. After I rebooted the box, I ran the oslevel command to confirm the new system level (see Listing 1).

Listing 1. Confirming the new system level
 

lpar46ml16fd_pub > # oslevel -s 6100-02-01-0847

  What does this information signify? It tells that you are running AIX V6 TL2, service pack 1, released in 2008 in the 47th week. The forth field, 0847, indicates the year and week. Finally, it is highly recommended that you apply the latest service pack when moving to the new TL. In our case we did not have to, because the latest pack was already a part of the TL upgrade.