I run quite a few Opensuse (mostly 11.1 at the time of this writing) servers in what you might call “pseudo-production” mode. For some of those servers, and especially for my test lab servers, I like to have them as up-to-date as possible by using some type of call to zypper in a cron job (either direct, or scripted).
And, even though I have the utmost confidence in the creators and maintainers of Opensuse, I still like to keep track of the packages that get updated, just in case some individual packages need to be reverted back to the original versions. And of course, just running zipper up alone will not give you any tracking of those changes.
So, I wrote a handy-dandy little script (link below) that will run a comparison against what is about-to-be-updated and what-currently-exists. The output of the script can be handled in various ways: either direct out to STDERR if running it interactively; output to a file; or if it is in a cron job, emailed out to the root user.
If there are no packages to update, you get a result that looks like this:
Number of patches found: 0
No updates this time, exiting!
If there are one or more packages to update, the output looks like this example:
Number of patches found: 2
Comparing existing packages and updates...
Existing version: package libx264-78 is not installed
Updating version: libx264-78-0.0svn20091023-0.pm.1.1
Existing version: MPlayer-1.0rc2_r29116-2.pm.29.8
Updating version: MPlayer-1.0rc2_r29796-2.pm.2.1
…and so on. The above two packages were updated on my laptop on the day of this writing.
The script itself can be found at the link below:
…and I will update it as I make changes and improve the version, or change for the behavior of zypper, etc…
Okay, time for a few caveats: Believe me, I know it can be better, but “better” was not my purpose here. I just wanted a tracking history, and I tossed this together, and am posting it for you here *at your own risk*. And I left the stuff in there to convert the output to a log file, so you can just un-comment it if you want. If you have other errors like DNS failures and such, the script may not respond in a timely fashion. Hmm… I probably should have written it in Perl too, and dumped the values to an array instead of running zypper twice, but there you go. Quick, dirty and effective. Also, please note that the script only works with the versions of zypper that includes the XML capability; I know that this does NOT include SLES10, but I’m not sure about others.
If you have any better tweaks to it, make sure to post them, and I’ll update it as we go along…
Thanks, and I hope it helps!
😉