Red Hat Open-Sources RHN As "Spacewalk" 54
deadearth writes "At their annual summit, Red Hat announced they are open-sourcing the Red Hat Network Satellite product, calling it Spacewalk. This will be the new upstream for the Satellite system management solution. Here is the Wiki."
Caveats (Score:2, Interesting)
Note that their blog entry states that they still expect all real redhat customers to continue purchasing the satellite service from RedHat rather than using this newly released software which is targeted for Fedora primarily with some support for centos. That's a little painful as I know several small businesses that pay for direct redhat updates/support and could use a local satellite install, but just can't afford the pricing and must continue to deal with the clunky/slow rhn web interface.
GPLv2 (Score:2, Interesting)
Re:My experience with RHN Satellite (Score:5, Interesting)
This is part of the Red Hat enterprise experience, which in my humble opinion is not that great of an experience. I have used the RHN in the past, and I have been completely underwhelmed by the outdated up2date style gui's (which tend to freeze) and lack of really comprehensive command line support.
On top of that, your not really getting what you pay for over all. Sure, in corporate world you have a blame line and someone to go back to at least as far as distribution and configuration goes, but RHN is not "far superior" to current 'apt' and 'yum' type solutions that are available to the rest of the "free world". Any given day, I would trade off RHN interface for package management for those managers available on a (brace yourself) Ubuntu desktop.
Also, if your concerned about the "security' aspect of updating your enteprise from a public source (which is ridiculous in this day and age, just keep off the cutting edge and your fine) you can always create your own "yum" and "apt" repositories for a fraction of the price (price only implies hardware, bandwidth, and maintenance) of RHN.
On a "btw" I have never been in an environment where I needed to run the "same command" at exactly the "same time" on a variety of different servers. Of course... nothing says lovin like writing a perl script that has a "central server with distributed SSH key" that can "fork" processes off to the background and do a routine on multiple boxes for sans fee....
So why buy RHN again?
Re:My experience with RHN Satellite (Score:3, Interesting)
Kudos! (Score:5, Interesting)
I used to be a red hat satellite administrator. There were quite a few bugs in the system that prevented me from doing the things with the network that I would have liked (centralized configuration file management, custom package deployment issues). It took Red Hat about a year and a half to solve each of the bugs, from the time I submitted them to the bug tracker to the time that a patch came out. I'm somewhat competent with Java, and do believe that I could have fixed the problems myself. I was beginning to get a bit frustrated with Red Hat due to the little bugs that cropped up in the server, and the slowness to respond. I understand that software development and testing cycles are tough, but I kind of felt like, for the money (about $15k per year), a quicker fix was in order.
I also recognize that it's a tough decision for them to open source this thing which raises a lot of money for them. No doubt this will spawn some real service competition for Red Hat, as other companies will able to easily implement their own RedHat-derived operating system complete with a centralized management system. It does fix my "using open source software to sell a closed source service" gripe. It's definitely a brave move, so kudos to them.
Re:Automatic Updates (Score:3, Interesting)
True story. It wasn't anyones fault, it was just a disastrous intersection of code bases. Also, Johnny Hughes of the CentOS team, and a regular slashdotter, was nothing short of amazing for email support. I think I heard back from him within the hour and we shot back and fourth emails until the problem was found and put in the bugtraq. Give this guys credit, BTW, they've earned my respect.
But yeah, these things happen when you have automatic updates. They make maintaining a farm easier, but don't be fooled in to thinking that they're the Silver Bullet. At work I use CentOS, and home I use Slackware; two completely different worlds. On my Slackware boxes, I can usually tell you what version of each major program is running, its patch level and its dependencies (and whether they're compiled as static or shared libraries) within a respectable margin of error.
On the server we have at work, I've kind of given up and yum does its thing. I've fallen in to the "I'll put it out when it catches on fire" mode of thinking due to poor management decisions that are in direct opposition to my advice. Both methods work, depending on how important your boxes and what they do are to you. By hand takes more time, but leaves you with exactly the system you demand. The other is "fire and forget" until you need to know what you fired where.
Oracle? Doh! (Score:4, Interesting)
Too bad it requires Oracle. Im already jumping from RHEL to CentOS to cut operations costs given my broke higher-ed shop. Hopefully the project's codebase will mature to allow for a db backend which doesnt require me to pump a lot of cash I dont have to Papa Ellison in Redwood City.
Landscape (Score:3, Interesting)
Good Points (Score:3, Interesting)
At home, I'm a distro hopper on the desktop; Fedora-9 now, Sabayon a few months ago. But both my servers are Slackware (well, BlueWhite64 on the 64 bit side). I don't mind the package management, I compile and roll my own packages that I keep in a svn repo. I've even packaged my own PAM because it makes my life easier. On the desktop though, it's just too much work. But when I want a stable, rock solid, lean-and-mean-compiles-it-all-machine, it's Slackware all the way.
Re:My experience with RHN Satellite (Score:2, Interesting)
In my organisation, we also have multiple environments (dev, test, prod) and need to migrate config channels between them. I also had to hack together a way to automatically upload config files to the override channel for individual systems, because the API lacks support for this.
I eagerly look forward to being able to simply send patches upstream, instead of having to submit my patches via bugzilla and wait for them to filter through their support network.
In addition, fine-grained access control based on various criteria (such as IP addresses and arbitrary LDAP/other searches) for regulatory compliance or other purposes. Right now, I've implemented limited access control for kickstarts and up2date requests using mod_python handlers parsing URLs, but it's very hackish.. hopefully I can now add the appropriate hooks to Satellite itself!