AIX Tools: SUMA and Inventory Scout
Paul GuglielminoKeeping systems up to date may be one of the most hated and mundane tasks of systems administrators, but it's also extremely important. Luckily, many tools have been created to help keep systems current in regard to security and other patches. Along these lines, IBM supplies two helpful tools with their AIX operating system. The first is the Service Update Management Assistant (SUMA), which aids in downloading fixes as they become available. The second is Inventory Scout, which reports on firmware that needs updating. And, if I may borrow a tag-line, "they are two great tastes that taste great together!"
In this article, I will describe the overall functionality of the software and show examples of how you can use the tools in your environment. Also, I will include some simple scripts that automate some of these tasks.
SUMA
Service Update Management Assistant (SUMA) automates the download of maintenance fixes from the IBM fix distribution Web site. SUMA [1] is included with AIX version 5.3 and with a couple of Perl updates, can run on versions 5.2 and 5.1. (AIX 5.1 is no longer supported by IBM, however.) Also, it is important to note that SUMA is not a complete one-stop shop, because it does not apply the maintenance for you. SUMA has an extensive array of filtering, scheduling, and downloading capabilities to fit almost any need, and understanding the different ways to utilize SUMA requires some knowledge of the AIX maintenance strategy. Here are some brief definitions:
-
Fileset -- An AIX package of software.
PMR (Problem Management Record) -- A tracking record for customer-reported problems.
APAR (Authorized Program Analysis Report) -- Associates a fix to a PMR.
PTF (Program Temporary Fix) -- A temporary fix; the fix disappears when it is incorporated into the next release of the product.
ML (Maintenance Level) -- A collection of fixes that have been tested together. (IBM has recently renamed this as a technology level.)
Note that smit has a fastpath to SUMA "smit suma", and the screens are self-explanatory if you understand the concepts. In this article, I will focus on the command-line utilities and their uses.
To begin, you should tell SUMA what action to perform by setting the 'Action' field item. You can choose any one of the following three. The first is 'Preview', which will show you what would be downloaded without actually downloading it. The next is 'Download', which will download the selected software based on your filtering options. The last is 'Clean', which will download software based on your filtering options and then clean the download directory of unneeded updates. This option uses the lppmgr command to remove conflicting updates, duplicate levels, and superseded updates.
So, how do you know what to download? SUMA allows you to download any of these fix types: APAR, PTF, Fileset, Maintenance Level, latest, Critical, Security, and I/O Sever. The I/O Server type is used for patches to IBM's VIO server software, which allows many LPARs (IBM's virtual server technology) to share the same network and disk connections. These options are set on the 'RqType' field option.
To limit what SUMA will download, it supports numerous filtering options. There are too many to list here but the man page has a complete list. The main options you'll probably be using are RqName, DLTarget, FilterSysFile, and FilterML. RqName is the specific name of the fix, fileset, or ML that you are requesting. The DLTarget is where SUMA will place your downloads. If FilterDir is left blank, then this will be used. SUMA will use this to filter against so it does not download duplicate files.
The FilterML option will be the AIX level at which SUMA will look for updates. FilterSysFile takes a file name that contains a software listing in the form of "lslpp -Lc". If /dev/null is specified, filtering will be turned off. As a first step, SUMA will scan the localhost to use as a baseline filter. After that, any filtering options you provide will take precedence. The filtering options can become complex because SUMA takes into account what is installed on the localhost, what you have set for task defaults, and what you have specified on the command line.
Before starting to use SUMA, you may need to configure some of the global variables. Most can be left at the defaults, but you may want to review the Web and ftp settings in case your network requires the use of a proxy to access the Internet. To see all the global options run suma -c. Here is an example of how to change a global option (in this case a Web proxy):
suma -c -a HTTP_PROXY=http://proxy.yourcompany.com:8001Next let us check the default settings for each task. These can be seen be executing suma -D. For instance, SUMA will extend your file systems automatically if it needs more room for downloads. This is one option you may wish to shut off by default. You can make changes in a similar fashion to global variables:
suma -D -a Extend=nWhen defining a download task, you can have SUMA run immediately, save a task for later, or schedule a task to run at a future time. Its scheduling mechanism is based on Unix cron, so it supports any of the timing features of cron. Use the -x option to run immediately, the -s option to save and schedule and the -w option to save without scheduling. Up to this point, I've described the building blocks of SUMA. Sometimes it is easier to understand something when you see it in action, though. So, here are some examples that you can try. The following will preview downloading the entire maintenance level 5 for AIX 5.3 to update your system:
# suma -x -a Action=Preview -a RqType=ML -a RqName=5300-05Unless your system is already at ML5, you will see a message similar to this:
****************************************
Performing preview download.
****************************************
Download SUCCEEDED: /usr/sys/inst.images/installp/ppc/ \
X11.base.lib.5.3.0.50.bff
Download SUCCEEDED: /usr/sys/inst.images/installp/ppc/ \
X11.base.rte.5.3.0.50.bff
....
Download SUCCEEDED: /usr/sys/inst.images/installp/ppc/ \
rsct.opt.storagerm.2.4.5.0.bff
Summary:
179 downloaded
0 failed
0 skipped
The following command will attempt to download a specific APAR. If you are waiting for the APAR to be released to the public, you can set this as a scheduled job, and you will get an email notification when it is finally released and downloaded to your system. When downloading specific APARs, SUMA will automatically delete the saved task and scheduled task on successful completion.
# suma -x -a Action=Download -a # RqType=APAR -a RqName=IY68463 -a FilterML=5300-02 -a FilterSysFile=/dev/null \ -a [email protected] This will download all the security updates for AIX 5.3ML3 into /nim/suma/5.3 and delete anything unneeded afterwards: # suma -x -a Action=Clean -a RqType=Security -a DLTarget=/nim/suma/5.3 \ -a FilterML=5300-03 -a FilterSysFile=/dev/nullThis command will schedule a download of all the latest fixes for your system from IBM at 4am each day and put them into /nim/suma/updates:
# suma -s "0 4 * * *" -a Action=Download -a RqType=Latest -a \ DLTarget=/nim/suma/updates Task ID 4 created.As you can see, a task ID is assigned to your new job. You can then view the contents of that job. The following listing shows the blend of task defaults and the specified filter options.
# suma -l 4
4:
DisplayName=
Action=Download
RqType=Latest
RqName=
RqLevel=
PreCoreqs=y
Ifreqs=y
Supersedes=n
ResolvePE=IfAvailable
Repeats=y
DLTarget=/nim/updates
NotifyEmail=root
FilterDir=/usr/sys/inst.images
FilterML=5300-04
FilterSysFile=localhost
MaxDLSize=-1
Extend=y
MaxFSSize=-1
Root's crontab will now have an entry that looks like this:
0 4 * * * _SUMA=cron /usr/suma/bin/suma -x 4In this cron entry, SUMA is executing saved task number 4. You could also do the same on the command line if you wanted to run this task or any other saved task on demand. Finally, when you want to delete the task:
# suma -d 4
Inventory Scout
The Inventory Scout tool surveys the host system for currently installed microcode or Vital Product Data (VPD). The microcode survey includes all hardware firmware from the system frame down to the individual disk drives and Fibre adapters. Vital product data is a list of information, such as part numbers and serial numbers for all the hardware components of a server. The two components to Inventory Scout are the command line, invscout, and the daemon, invscoutd. Running the daemon version allows you to query the Inventory Scout information from over the network; it is not needed when using the command line.
When running Inventory Scout without any options, it will perform a microcode survey. To complete this, Inventory Scout requires a file called catalog.mic, which is a master database of all hardware from IBM and the latest firmware levels for it. Inventory Scout looks in /var/adm/invscout/microcode for catalog.mic but you can point it to any location with the -catl command-line option. Running a microcode survey will produce two files, hostname.mup (where hostname is your host's name) and invs.mrp. The invs.mrp file is a summary report of system information and the installed microcode levels on the hardware. The hostname.mup is the detailed result file.
As a complement to the microcode survey result, IBM provides a Web site [2] that takes the hostname.mup file and generates a nice HTML report page (see Figure 1 ). The page includes all of the microcode installed on the server, the most recent revisions of that microcode, and links to download and see the READMEs of each. See Figure 1 for an example of the HTML page.
Another side note -- one of the things I find great about the hostname.mup file is that it includes all the important information, and it is easy to parse with a Perl script. You can use a regex such as this, /(\S+)=\"(.*?)\"/g, to capture each field in the hardware record. The Perl variable $1 will be set to the field name and the $2 variable to the value.
I have written scripts to collect Inventory Scout data every night and generate the Web page mentioned above. Listing 1 , dl_mcatalog.sh, is a simple shell script to download the newest catalog.mic file every night. It downloads the latest version, compares it to what we already have available, and either deletes the new file, or makes it the new default based on the results. Since the microcode levels do not change very often, it would be wasteful to keep many copies of the same file around. Lastly, it deletes files older than 180 days from the download directory.
Listing 2 , combined_invscout.sh, runs Inventory Scout across my current environment and concatenates all the results into one file. Parsh is just a local Perl script that does a ssh out to all our servers and runs a command. You could easily create your own version of our parsh or make a simple shell loop to ssh into all your servers. In this case, we are copying the local invscout results into a NFS-mounted directory so we can create a combined file to send to IBM. It then uses Curl [3] to submit the file to IBM from their Web form and save the resulting HTML file to a NFS share. Whenever we are preparing to do maintenance, we can reference the file to see if any microcode needs updating.
Summary
I hope this article has given you some ideas to make your maintenance strategy a bit easier. In good Unix fashion, IBM has given you some small tools that you can use as building blocks to build something powerful. Even though the tools I have described are made for AIX, the concepts are important for any operating system. Know your systems, know the latest code, and have plans to keep them all up to date!
References and Further Reading
1. Service Update Management Assistant (SUMA) on AIX 5L --
http://www-03.ibm.com/servers/aix/whitepapers/suma.html
2. MDS: File Upload -- http://www14.software.ibm.com/webapp/set2/mds/ \
fetch?page=mdsUpload.html
3. Curl Web site -- http://curl.haxx.se/
Paul Guglielmino is a consultant in the Boston area. A former Solaris admin, he's now an AIX junkie. Please send comments or AIX tips to him at: [email protected].
