Linux Czar

The bossman got chewed out in a meeting last week. The administration demanding that we come running to every problem that may happen. No budget, no positions for a help desk team or person. It doesn’t matter that other colleges have under staffed IT groups that are 4 to 8 times our man power. Oh yeah, and we don’t have infinite resources to back up the administrations multiple gigabytes of email per person.

As budgets have been cut repeatedly at the university things have gotten less fun, that’s for sure. However, I can only take so much flack for not providing adequate service when the administration cannot be convinced that resources are required to provide those services. Especially since there is no chance of a promotion or raise. I can see the burning bush. Its time.

So, the Linux Czar is looking for a new job. Preferably in the Raleigh, NC area but willing to talk about other adventures. My Resume (PS) is on my website. My interests are in working with Red Hat Products, centralized management and administration of large numbers of workstations and servers, and disaster recovery planning.

Also, I’m sure only Google will notice that I did do some changing in the layout of my website. Mostly to better handle multiple domains better. So older links may need updating.

I’ve always wonderd if using XMLRPC over Jabber wouldn’t be the way to go while implementing a systems administration tool like StateEngine. It gives you several bennifits such as presence and dellayed receiving. However, I think there are about 2 people on the internet that actually use it. The examples that exist for JEP-0009 are for unmaintained jabber libraries. (Talking Python, of course.) To make matters more interesting the current jabber libraries for Python seem to only work with certain servers and server versions.

This boils down to Jabberd2 apperently sucks. At least that’s where I’m at today. The ejabberd server seems to work well with my hackings.

The latest release of Japperpy, which is unmaintained, has a very basic example of making Jabber-RPC go. However, the script is a bit broken and needed some TLC. (Don’t you love learning a new language or protocol with broken examples?) I fixed it up and stuck my version of jrpc.py on my web site. This code makes a Jabber-RPC request, bottles it up, sends it to itself via your jabber server, and decodes the method call request.

Next step is go get this example working with XMPPPY, a supported library. From there we’ll see if the Jabber RPC thing is actually worth the time.

I’ve been growing ever dissatisfied with managing RHEL with up2date of late. It doesn’t understand the XML Metadata repository format without actually having Yum installed and its feature set is horribly far behind any other updating program. But I think these limitations are already well known.

I’ve been working on some Yum plugins for kernel modules and seriously considering taking a look at what it would take to make Yum understand the RHN repository format. For those of you that might have heard similar rumors in the past, yes I am the person that randomly talks about Yum and RHN. This is not my first time trying to make this happen.

However, Yum was never designed to handle multiple repository formats. Much of Yum works directly with the XML metadata objects rather than abstract APIs. Its a difficult problem to tackle with the current state of Yum. If anyone has a bright idea I’d love to hear it.

There are sevral ways to go about integrating RHN support. What has been discussed in the past is creating an abstract MetaSack to contain many PackageSacks so you could have one per repository type. The PackageSack object serves as an interface to your caching layer and a single interface to query the entire package set from all repositories. This requires some major changes to Yum and I feel is not something I am capable of doing without active work from folks that are more involved with the project.

Another way I’ve looked at integrating RHN support is to be able to transmute information from the RHN protocol into the XML metadata. This idea fails because the RHN protocol doesn’t provide enough information to generate the XML metadata. A lot of the information needed to resolve dependencies must be gathered after downloading the RPM header from RHN or using the up2date.solveDependencies() RPC call. This method ends up requiring that all the headers be downloaded before any dependency resolving can happen.

I have looked at directly inserting the additional available packages from RHN directly into the PackageSack. This method requires you to hand the SQLitePackageSack an SQLite database object. I can’t abstract that. There is much SQL in the PackageSack code. Which goes back to being able to generate the metadata format from the RHN protocol.

I have also looked at creating a Yum Plugin and trying to go around the metadata. In this case it looks like I would be inserting packages into the TransactionData (tsInfo) object. This method would require that I re-implement much of the code in Yum as I need to add the packages as Available, Install, or Update. So I’ve got to figure out what packages are to be upgraded with that particular invocation of Yum.

Alas, it looks like no RHN support for Yum for a while. Hopefully the MetaSack implementation wont be too far in coming.