Using RPM to install SarCheck
In our infrastructure, where I work, we use configuration management to manage our software installs. Since we’re using OpenSUSE, that means (by default) using RPM. I’ve got a YUM repository that I maintain our packages in, and that source is added to zypper as a part of the system tweaks at install time, and then cfengine uses zypper to do installs. It’s actually not half bad at all — now that I’ve learned to love the spec file. (At the outset, I admit, I thought I was doing my usual over-engineering of the solution, rather than merely Doing the Right Thing. Now that it works, though: obviously I was right all along!)
We recently bought licenses for SarCheck, which is a package designed to take your collected system statistics and translate them into plain English, so you can go from looking at statistics like X% blocked read i/o on device D to being told “You should split /var/foo off onto a new disk so it’s not fighting /var/bar for I/O bandwidth.” It’s actually pretty slick. At a previous employer, I used it on several Solaris machines. Now, I use it on Linux. Normally, I would just deploy the software — since there’s no way I want to go and hand-install it on 50 hosts — by dropping the RPM into the friendly local yum repository and rebuilding my indices, then tell cfengine to drop it where I want it to go. The only problem with this plan is that it’s not distributed as an RPM — you’re given a compressed tarball, which installs into /opt/sarcheck.
I really don’t like that part. :)
I’m not normally an enormous stomper and shouter about The Rules and The Standards. I like things to be orderly, but the strength of UNIX is flexibility, after all, right? But. Let’s not be all crazy here. The flexibility is the chocolate inside the delicious candy coating of history and tradition, and yes, standards. The Filesystem Hierarchy Standard is a nice, short one, which most of us already know: /bin is where you put your binaries, /var is for data, and /opt is for add-on packages. Coming back to the original topic, part of the deal with SarCheck is that, in the tarball as distributed, it writes data files within /opt/sarcheck — it stores information on the stuff it gets out of /proc to analyze, and it optionally can also store ps output for analysis. This is, I think, data that should not be living on /opt — especially since most of my systems have /opt on /, and I don’t want data living there. (Rest assured that any criticism you’d like to level at my site after that revelation has already been made.)
So now, not only do I need to get this tarball into an RPM — oh, I didn’t mention the part where it’s not open source, did I? It’s not open source. — but I also need to go mucking around in its innards.
Before reading any documentation, I was a little worried that in order to get the datafiles over onto /var, where they so clearly belong, I’d have set up a bunch of symlinks and deal with it that way. Luckily, the nice folks from Aptitune do make it possible to move /opt/sarcheck/procstat and /opt/sarcheck/ps to other locations and have them set as runtime options. Unfortunately, it doesn’t seem to be totally done. I wound up patching both bin/prst1 and bin/sarcheck (both shell scripts) to support a new option for the sarcheck_parms config file, which is undocumented but does exist in the stock ps2 script (as I discovered after making up my own parameter and patching and distributing the RPM to a few hosts as a test — oh well. I should have known better than to screw the case back on all the way before test firing it up, anyways).
Once I had the patches, I had to build a spec file. Now fortunately, since I don’t have to actually build the software (the nice thing about getting a bundled, compiled package!) working through building a spec file is pretty easy, since I don’t have to attempt, fail, fix, attempt again, fail, fix again, etc. 800 times at 10 minutes a pop, unlike *certain* other packages I could name. And also, the spec file is pretty easy since most of the heavy lifting is done — basically, I just have to apply patches and then start using install to copy files around.
So here’s the spec file. (Link) Let’s break it down:
Header, blah blah…
Summary: SarCheck system performance analysis package
Name: sarcheck
Version: 6.01.03
Release: 4.myc
Epoch: 0
License: Commercial
Group: Applications/System
URL: http://www.sarcheck.com/
Source0: sclin.taz
Patch0: prst1.patch
Patch1: sarcheck.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Autoreq: 0
The only particularly interesting bit there is the “Autoreq: 0,” which disables RPM’s automatic determination of the requisites for this package. Since I’m distributing a pre-compiled binary that I can plonk down pretty much anywhere I have a 2.6 kernel, I don’t care about things like libc versions, etc., so I turned that off. (Also, I always encode a string into the release number of the packages that I build locally, ‘myc’ to represent MyCompany, so that I can easily tell just by looking if an installed package is mine or from an external source.)
Note the references to the two patches.
Here’s the description — swiped wholesale from the web site. (Sorry.)
%description
SarCheck is a Linux & UNIX performance analysis and performance tuning tool.
It is designed to help you with performance management on most Solaris,
Linux, AIX, and HP-UX systems by making recommendations and explaining them
with Plain English text, supporting graphs, and tables.
%prep
%setup -c
cd %{_builddir}/%{name}-%{version}/opt/sarcheck/bin
%patch0 -p3
%patch1 -p3
So there’s the patch application, via the Patch0: and Patch1: directives in the header with the corresponding %patch0 and %patch1.
Now let’s “build” the software. Heh.
%build
cat << EOM > %{_builddir}/%{name}-%{version}/opt/sarcheck/etc/sarcheck_parms
PRSTDIR /var/sarcheck/procstat
PSELFDIR /var/sarcheck/ps
NOMP
EOM
Shortest Compile Ever! All it does here is create a little config file, sarcheck_parms, which overrides the default locations for the data directories to /var/sarcheck (from /opt/sarcheck).
Now, rather than %makeinstall, we just have %install to go copy files around:
%install
install -m 0755 -d $RPM_BUILD_ROOT/opt/sarcheck
install -m 0755 -d $RPM_BUILD_ROOT/opt/sarcheck/bin
install -m 0755 %{_builddir}/%{name}-%{version}/opt/sarcheck/bin/analyze $RPM_BUILD_ROOT/opt/sarcheck/bin/analyze
install -m 0755 %{_builddir}/%{name}-%{version}/opt/sarcheck/bin/prst1 $RPM_BUILD_ROOT/opt/sarcheck/bin/prst1
. . . blah blah install blah . . .
install -m 0755 -d $RPM_BUILD_ROOT/var/sarcheck/ps
install -m 0755 %{_builddir}/%{name}-%{version}/opt/sarcheck/ps/readme $RPM_BUILD_ROOT/var/sarcheck/ps/readme
Since SarCheck ships with a temporary license key, but you must activate it individually on each host you install, by running a program and submitting the output back to Aptitune, I just do that in the RPM in the post-install phase. (You may prefer to skip this part. YMMV.)
%post
/opt/sarcheck/bin/analyze -o | mailx -s “Please register `uname -n` sarcheck info” mygroupsaddress@mycompany.com
And the rest is just uninteresting bits. At least on this one, since I don’t have to compile anything, creating the %files list is easy!
So the spec file was actually pretty easy. The patches were even easier — they were, in fact, so easy it’s not even really worth posting them inline. It’s basically just a matter of “if variable X is declared, use it; otherwise, default to Y,” or referring to a variable rather than a static string, in a couple of places. The patches are: prst1.patch (Link), and sarcheck.patch (Link).
So from this point, it’s a simple “rpmbuild –sign -ba sarcheck.spec” away from being integrated in my cfengine configs, where I then just create a “sarcheck_clients” class that has all the hosts I want to install SarCheck on, and then put the package declaration in there for that class. Once that’s done, I collect all the email messages, and forward them off to Aptitune for license processing.
This spec file isn’t perfect, of course. For one (obvious) thing, it likes to build the package for i586, which is where I’m building it, despite the fact that it’s the same tarball distribution for i[3456]86 or x86_64. Next time I build it, I’m definitely going to use “BuildArch: noarch.” I’m contemplating splitting the license-notification bit out into a sub-package, calling it something like sarcheck-license, and making it version-mostly-independent, so if I need to rev the sarcheck package I don’t have to generate a spate of 50 emails telling me to (re-)register my licenses. But, even imperfect, this is much nicer than having to go around and untar a bunch of stuff into /opt, and then go manually push it all around so I don’t risk filling up my / with sarcheck data analysis.
Software management: it ain’t pretty, but sometimes it’s possible to put a wig and a dress on it so it can at least be seen in public.
Trackback | del.icio.us | Top of page
