 SolarisTM
Patch Levels
Thomas Knox
Keeping the latest Solaris patches installed is a big step towards
securing your machine, and to that end, I have written a couple
of scripts to help automate the patching process. These scripts
have been tested on Solaris 2.6, 2.7, and 2.8. Furthermore, (http://www.sans.org/)
and CERT (http://www.cert.org/) are useful in keeping on
top of any new security holes that are discovered.
The Automation Setup
The first thing to do is to install the Sun patchdiag tool
onto your servers. I like to install it into /usr/local/patchdiag
so I always know where it is, no matter what system I might be on.
The patchdiag tool can be found at:
http://sunsolve.Sun.COM/private-cgi/show.pl?target=resources/patchdiag
and the most recent version (as of this writing) is 1.0.4.
Please substitute the URL for your local SunSolve mirror in place
of sunsolve.sun.com. See:
http://sunsolve.Sun.COM/private-cgi/show.pl?target=link
for the list of mirrors.
After you have downloaded the patchdiag tool, install it
into a uniform place. All of my scripts assume /usr/local/patchdiag;
change yours accordingly:
cd /usr/local
zcat patchdiag-1.0.4.tar.Z | tar -xvf -
ln -s patchdiag-1.0.4 patchdiag
cd patchdiag
./patchdiag_setup
I also make a user (called "patches") who owns the patchdiag
directory on each machine. This account is used to automate pushing
the patchdiag.xref file to all of the servers:
cd /usr/local
chown -R patches patchdiag-1.0.4
chmod 700 patchdiag-1.0.4
The Automation Process
The first script (Listing 1) will go out to the SunSolve FTP site
and download the current patchdiag.xref file for system analysis.
After downloading it, it will push it to all of your other servers.
Replace host1 login_id password ... hostX login_id password
with your server names and the login information (i.e., sunbox1
patches patchpw /usr/local/patchdiag). Since this script will
have live account information, it is a good idea to keep it owned
by root with permissions 700, and in a private directory.
I initially used ncftpget to FTP the patchdiag.xref
file, but Sun changed how the file was stored (it is now listed
as a 0 byte file), and ncftpget will no longer retrieve this
file, even with command-line arguments to "force" a RETR.
This script was designed to run as a cron entry. How frequently
you check your patch levels should help you determine how often
to run this script. Running it at off-peak hours will endear you
to the Sun administrators.
The next phase of automation involves determining which patches
need to be downloaded, retrieving them, and prepping them for installation.
This script (Listing 2) uses wget, available from:
http://www.gnu.org/software/wget/wget.html
or precompiled from:
http://www.sunfreeware.com/
Follow the instructions provided by your download of wget and
install it.
Replace my_login_id with your SunSolve login ID, and my_passwd
with your SunSolve password. Again, because Listing 2 contains live
passwords, keep it in a private directory with permissions 700.
patch.ignore is a list of patch IDs that you do not want
to get. For example, if you're running a headless Solaris 8
server, you probably do not want patch 108576 to support Expert3D
IFB Graphics. List the patches without revision numbers. A patch.ignore
file that contained the following:
108569
108576
108864
would not download patches 108569, 108576, or 108864.
If your server is behind a proxy, add the flags:
--proxy=on
--proxy-user=my_id
--proxy-passwd=my_passwd
to the wget statement above, thus supplying your correct proxy
user id and password. Be sure to add the line:
http_proxy = http://my.company.proxy:port/
to your ~/.wgetrc file, or define the environment variable
http_proxy in the script (e.g., http_proxy=http://proxy.company.com:
\ 8080/; export http_proxy)
This script will get all current patches for your system that
were not explicitly excluded by the patch.ignore file, and their
associated readme files. It will also expand the patches for easy
installation. This script can also be run from cron, preferably
after the first one runs.
Conclusion
Now that the patches have been placed on your systems, it is up
to you to determine system applicability and install them by hand.
It would be easy to also automate the patch installation. A simple
i='ls -d 1*-*'; for j in $i;do;patchadd $j;done
would work well. However, it is highly recommended not to do so.
Rather review each patch's .readme and PATCH-ID/README
files to determine applicability, special requirements, and whether
a specific order is needed for installation.
Using these scripts on a regular basis on my servers has enabled
me to be much more proactive in keeping my systems up to date and
preventing problems before they become major issues. It has also
reduced the usual hassle in finding new patches and retrieving them,
thus saving my time for other tasks.
Thomas Knox has been programming for 19 years and working as
a UNIX adminfor 6. He can be reached at : tom@vushta.com.
| 
