Thursday, September 20, 2007

The trouble with packages and auto-pilot

I stumbled into a very interesting problem and resolution this morning which I think deserves some attention. I didn't work on the diagnosis and research, so I'm summarizing from an email thread. We use a Citrix server to share out GNOME environments from our development server. It's particularly nice when you're working from home and the VPN kicks you out, or if you're using public wifi and your connection is spotty.

At some point a week or two ago people began to notice that they couldn't connect to GNOME. This took a little while to unfold because some people keep sessions opened for extended periods of time, but eventually we discovered that it was dead for everyone. After eliminating license server issues there was only one thing we could come up with that had been done to the server.

A colleague had installed a current version of FireFox on the server because Sun's desktop environment is often very slow to integrate application software updates. He used the packages from Note that I say packages: a plural word. Indeed, FireFox turned out to be more than twenty packages when delivered by Blastwave.

The foundation of Blastwave is their packaging system, pkg-get. If you have any stick time in the Linux world you're probably familiar with something like Yum, apt-get, or up2date. These tools know how to connect to software servers through http, https, ftp, firewalls, proxies, etc. They also know how to resolve package dependencies. This can be very convenient on a Linux system where a single source handles the OS packaging and application packaging.

In contrast, Solaris provides pkgadd. Pkgadd can not resolve dependencies. It only knows how to retrieve packages from a specified URL, but does not have any ability to retrieve packages from a Sun resource. Pkgadd is a bit antiquated by modern UNIX standards unless coupled with the Sun Connection which is not quite the same thing. This huge gap between Linux packaging systems and Sun's pkgadd inspired Blastwave's packaging system and repository.

Blastwave provides many packages that are provided by the Solaris OS. The difference is that they provide more frequent and convenient updates. If you need bleeding edge features in the tools you install, Sun's usr/sfw/* and /opt/sfw/* packages will probably not help. I tend to think that it's more the exception than the norm to require updates that frequently. I know there are exceptions here and there, but overall, how often do you really need a new version of wget, or gtar? Although I love having latest and greatest "stuff", I even use the old Mozilla browser in Solaris and rarely have any problems.

When my colleague innocently asked Blastwave to install the latest FireFox package, it installed a fairly significant list of packages. One of them was fam, the file alteration monitor. For those who may not be familiar with FAM, it is described as follows (from the FAM web site):

GUI tools should not mislead the user; they should display the current state of the system, even when changes to the system originate from outside of the tools themselves. FAM helps make GUI tools more usable by notifying them when the files they're interested in are created, modified, executed, and removed.

We eventually discovered that fam installs an inetd service. I don't know, or care what that service is doing. What I do know is that I did not want a new service running. As a result of installing the Blastwave FireFox package and its slew of dependencies we ended up with a new service running and had absolutely no warning that it was happening. That service somehow conflicts with, and breaks GNOME. It turns out that there is an OpenSolaris bug describing the same symptoms.

Ignoring the obvious concerns about a simple desktop web browser requiring 20 package dependencies and breaking GNOME, I have a much larger concern. Turning up an inetd service creates a new attack vector for a server. Whether or not that is acceptable is a question of risk management. In many cases it doesn't matter. In our data center, servers must pass an external probe scan to be in production and adding services requires change requests. So for our purposes, the changes are not acceptable, and we will need to back them out. We are also imposing a ban on blastwave within our data center servers. It's simply not an acceptable framework for a mission critical server environment.

Whether or not you deem it reasonable to install an inetd service to run FireFox, it's hard to justify the intuitive nature of a web browser requiring the inetd service. Note that fam is NOT a FireFox dependency in other distribution channels. Of course, this kind of thing can be caught with good change management using a promote-to-production path, which is how we found this issue on our development server.

While Solaris' pkgadd facility is not as convenient as some of the Limux systems, it forces you to make conscious changes to a system rather than hitting auto-pilot and hoping for the best. I would love to see Solaris' packaging facility evolve into a tool with the capabilities of its Linux counterparts, but only for the freeware / OSS packages that are built and distributed by Sun (of which there are quite a few). I'd also like to see the ability to configure additional repositories (such as a local server for custom packages), as long as it's not set that way out of the box. I guess its time for me to start exploring Update Connection's capabilities.

My suggestions are as follows: First, beware the autopilot. Second, keep Blastwave on the workstations, and as far away as possible from the critical servers.


Tom Buskey said...

Nice article. As a long time Solaris and Linux admin, I feel your pain.

Right now there are several Solaris pkg repositories:
Sun (/)
Sun Companion CD SFW (/opt/sfw)
Sunfreeware (/usr/local)
Blastwave (/opt/csw)
Homegrown (/usr/local, ??)

If I want specific packages I might end up installing 3 or 4 gcc packages!

This is reminiscent of issues Linux users have had with RPM based distributions. Debian standardized an apt wrapper around the .deb packages early on and has a very coherent repository.

Fedora and other Red Hat type distributions have been converging with yum.

I'd also like something where I could take a CD as a source. I have systems with no internet access to update.

Bad Wombat said...

I have a few minor notes about this story. Just my 2 cents.

1. I am sorry, but I have a difficulty believing that any system administrator of any UNIX type systems doesn't know what inetd does.
2. So, some shcmuck installed a whole load of packages from an untrusted source using some dependence resolution tool he was not familiar with. This is such an obvious human screw up that I don't see how this is fault of Blastware or dependency checkers.
3. Lets imagine for a second, that you have to deal with the dependencies on your own, pkgadd style. In that case, your roadtrip would probably be much shorter. Install firefox package. Doesn't work. Try for 3 days to figure out dependencies and give up.
4. Yes, installing a net service without a warning is not a good thing. On the other hand whoever did the install should have ran a dry run, noted all the dependencies it was going to install and figured out what exactly those are. Isn't that how you do it with pkgadd? Or do you just download the next package in the list and install it without looking at the description?
5. There are a lot of ways to compile firefox. I guess Blastwave decided to compile with all the bells and whistles.
6. In the view of the statements above, I would replace "beware autopilot" with "figure out how to use the administration tools before using them" and "keep Blastware away from critical servers" with "don't let incompetent people install software on your critical servers".

Christopher Hubbell said...

No need to apologize, but I have no idea what you are making reference to when you say, "I have difficulty believing that any system adminstrator ... doesn't know what inetd does." We all know intimately what inetd does.

The issue at hand, which perhaps I didn't make clearly enough, is that I believe intuitive design leads to more reliable services. There is nothing intuitive about a web browser requiring an inetd service to monitor file status.

I can see it for Nautilus, but not for FireFox. I'm sure there's just a feature I don't know about (probably many, as I have so little ineterest in desktop environments). Some plugin that makes it critical that my browser immediately knows when a file is updated. It's probably related to monitoring the bookmarks file. Cute, I guess. I like Firefox (well, actually, Camino), but I don't need to have my hand held if I throw vim at bookmarks.html.

I don't think familiarity with the dependency checker is the issue, although I do agree human error is the root cause here. A root cause which I believe was exasserbated by a counter-inuitive configuration which requires an inordinate number of packages for a web browser.

I also agree that trying to do this with pkgadd would be as fun a ripping off hangnails. However, the article is not intended to debate the merits of pkg-get vs. pkgadd. In that context, I believe I shed a favorable light on pkg-get's capabilities while illustrating pkgadd's limitations. I'd like to see Solaris adopt more advanced functionality from a tool like pkg-get, or apt-get.

My issue is not with the pkg-get tool; It's with the decisions made by the packager of the Blastwave FireFox distribution, and perhaps the entire philosophy of the Blastwave environment. I think the complexity is not justified by the end result. A dilligent screening of the dependencies and their effects would be a significant undertaking just to get a web browser.

I appreciate your thoughts, but I'm going to stand by my recommendation. I view Blastwave as being best suited to a desktop or non-critical development environment. Not the best path for a server.