Red Hat Spacewalk
I’m excited to hear about the latest Red Hat OSS contribution – the Spacewalk, open source RH Satellite server. I’ve managed a medium sized RH Sat server environment and I liked a lot of the features in it.
For the uninitiated -
Paid RH users get their OS updates/patches through the Red Hat Network (RHN), which is similar to Microsoft windows update website but with more management features that allows admins to manage various package channels on multiple systems. (Windows update is only designed to patch the system directly connected to it and nothing else, unless you implement your own SMS/SCCM services).
In a way, Satellite server is pretty similar to SCCM, both are installed locally on your own network, and you synchronize the patch contents with the upstream provider; both polls hardware inventory and uses some sorts of database backend to store all the client/patch dependency information(Oracle for Sat srv, MSSQL for sCCM). Up until now, they were both closed source.
One thing that irritated me the most during my prior experience with Sat server was its closed source-ness.
The backend database was oracle and a lot of magic happens in there. After knowing about the database, I immediately set out to write scripts that can pull machine information out of the database. After talking to RH support a few times, I was told they would not give out specifics of the schema and they’re likely to change frequently and advised me not to interact directly with the backend db. That was a major bummer. The Sat server was basically a hugely expensive black box. You know it’s running but you can’t see inside it.
After I figured out how to centrally admin all the kickstart scripts in Satellite server, I migrated all the previously hand maintained ks files into it. Everything was fine for a while, until one day, the anaconda (redhat installer) was updated to support more commands such as a flag to suppress HBA driver from loading. It was very imporant feature because it prevents anaconda from prodding SAN devices when you don’t want it to. (For example, re-imaging a GFS cluster node without having to disconnect the FC cable or temporarily re-zone the SAN). Unfortunately the Satellite server did not support that particular flag and I was told the only way to do it in Sat server would require going into the oracle db and add things in the schema. (I was also given the warning that once I do that, I’d void the support ..eeeeek!)
Needless to say, I gave up on that idea and moved all the GFS cluster kickstart off the satellite server into where it came from, so I can do hands-free cluster node reimaging. (back to square one)
The opening of the satellite server code is a very good thing for RH. It lets CentOS users experience what paid users get and may convince those who depends heavily on CentOS to migrate to a pay model, it also allows industrious SA/System engineers to see what’s in the black box and grant them the ability to do more amazing things with it.
Good job, RH!
(And btw, I’ve been told the oracle server will be replaced by Postgres soon… back in FOSS 2006! Now that you’ve done opening the code, perhaps the OSS community can help RH speed up the divorcing process with oracle 
)