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.
Continue reading »