Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Red Hat Software Businesses Linux Business Software Linux

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."
This discussion has been archived. No new comments can be posted.

Red Hat Open-Sources RHN As "Spacewalk"

Comments Filter:
  • by bwhaley ( 410361 ) <<spam4ben> <at> <>> on Friday June 20, 2008 @12:06PM (#23874323)

    I'm currently working towards on RHCA, which requires a series of 5 exams, one of which covers "systems management." In the Red Hat world, this means RHN Satellite, Xen, and a few other misc tricks of the trade (packaging RPMs, RHN proxy, etc). The rub is that I'm trying to do this without taking the courses associated with each exam. This is a huge challenge since there is very little official material to study from. I'm currently signed up for EX401, the systems management text, next week.

    I obtained an evaluation satellite license (they quoted around $13k/year as a retail cost) and a bunch of management, provisioning, and virtualization entitlements. I only have the course outline and the exam "prep guide", which is really just 20 or so bullets on what you need to know. I've done all my studying using Red Hat's Satellite documentation and the varoius Xen materials that are publicly available.

    Satellite is a really useful technology for large enterprises with a bunch of Red Hat/CentOS/Fedora servers. It's exactly like the interface. You can create kickstart profiles, provision new systems, manage Xen guests, run system commands, deploy configuration files (centralized syslog.conf, anyone? common /etc/motd? hosts.allow/.deny? very useful.), run commands on a lot of hosts at once, and carefully control patches.

    I've got some beef with it. First, it's currently supported only on RHEL 4, not 5. RHEL5 has been out for about 15 months - what gives? Getting it set up and configured correctly has been very finicky. I still don't understand all the behind-the-scenes services. The jabber service that runs OSAD is a huge mystery to me. And God save you if you try to change your hostname - getting that SSL cert to match again has been a nightmare.

    Some of this is certainly my own lack of knowledge. There's a useful, active mailing list that I see the developers participate in. I'm sure support is excellent as well. I've been mostly impressed with the documentation, but I don't need to see screenshots of every piece of the web interface. Tell me WTF that jabber process does! How can I get OSAD working properly? Plus, the docs can be pretty spread out and tough to find. I wasn't even aware of the mailing list until I read the README that's buried in the Satellite ISO.

    All-in-all, a cool product, but perhaps not useful for organizations with 50 servers or so.

  • by foobat ( 954034 ) on Friday June 20, 2008 @12:07PM (#23874339)
    it's planned to tie in with freeIPA []
  • by EvilAlphonso ( 809413 ) <> on Friday June 20, 2008 @12:32PM (#23874697) Journal

    After 4 years of satellite management, I can say the following:

    The configuration channels suck so much in practice that we are developing our own internal solution to replace it.

    The RHEL5 support is a mystery to me as well, it might be related to the issues encountered running the Sat inside a xen guest. I need to check with my TAM, but the last official message I had was "not supported".

    I'm in the process of migrating from Sat 5.0 to Sat 5.1, to take advantage of the sub-org delegation. That was one of the biggest pains in the previous versions as my customer is split into 20-ish independent entities and I get to manage the satellite that maintains them all. After the migration, I fully intend to just maintain the channel staging, the common custom packages and the kickstart templates. I will delegate the actual kickstart part to the sysadmins without having to give them complete control over all the machines of the site.

    I am also very excited by the new RHN API, maybe I will finally be able to fully automate the errata management with automated regression testing for our supported use cases. As it stands now, the errata staging consumes most of my work week...

    Hint: OSAD is used to push updates or commands to the client from the satellite. The clients subscribe to a jabber channel and do what the satellite tells them to. Chances are the old hostname is still in the jabber configuration file... happened to me during the Sat5 upgrade.

  • by nologin ( 256407 ) on Friday June 20, 2008 @12:39PM (#23874797) Homepage

    Hmm, I've worked with RHN satellite quite a bit, and it does have some nice features. My biggest complaint about it is that the interface isn't intuitive as it should be; if you need to find things, some of them are hidden well enough so you have to memorize stuff...

    But to answer your question about OSAD, the RHN satellite server uses this to automatically push instructions to its clients. Without OSAD, the only way that the client verifies that it has tasks to do is through a script called rhn-check. That runs periodically via crontab on the managed system; it initiates a connection to the satellite server and executes any tasks that are listed in its scheduled tasks. If you want to change how often the system checks in with the satellite server, just change the timing on rhn-check in the crontab.

    The OSAD service is a tool that allows you to automatically push changes from the satellite server to the managed systems immediately. You run the osad service on the managed system and the osa-dispatcher service on the satellite server and once you use the webUI on the satellite server to do something (like upgrade a package for example), the managed system will update immediately, rather than wait for the next check in (rhn-check) to run on the managed system. A gross simplification of what OSAD does is that it performs actions in real time, rather than on a regular scheduled check-in basis.

  • Re:RHN? Yum? (Score:2, Informative)

    by Anonymous Coward on Friday June 20, 2008 @12:53PM (#23875039)

    Because YUM doesn't track assets such as activation keys (for RHEL Products) nor does YUM by itself allow you to install a package on multiple systems at the same time without some type of frontend (like Spacewalk for instance).

    I realize this is slashdot, where no one RTFAs before spouting off with an uninformed troll such as yours, but damn, even just a cursory glance of the wiki at the provided link would have answered your question.

  • Re:Caveats (Score:3, Informative)

    by mattmarlowe ( 694498 ) on Friday June 20, 2008 @01:03PM (#23875193) Homepage

    Also from the website:

        Can I use Spacewalk to sync my entitlements for Red Hat Enterprise Linux and other Red Hat software products?

        No. At this time, in order to be able to connect to and satellite-sync Red Hat software content, you will need the Satellite product with an active Satellite certificate.

        Now that Spacewalk is available, does this affect Satellite pricing?

        Basing the Satellite product on a free & open source project will not affect the product's pricing. However, we are currently considering alternative ways of packaging the product based on studies we have done on the usage of the product as well as feedback from our valued customers.
        These considerations are unrelated to the product becoming free & open source, though. If you have feedback on this please contact your Red Hat sales representative or if applicable your Technical Account Manager.

    If you look at the table/figures on the FAQ page, you'll also see that RedHat is discouraging use of spacewalk for RHEL.

    Furthermore, if you look at the roadmap, you'll see support for various Fedora and CentOS versions listed but nothing for RHEL.

  • by Anonymous Coward on Friday June 20, 2008 @03:47PM (#23877627)

    Red Hat Network (RHN) and Red Hat Network Satellite Server (RHN SS) are dramatically different products. RHN is a hosted solution that only lets you manage updating your systems, RHN SS lets you do provisioning via kickstart, system updating, configuration file management (with multiple levels of overriding configuration channels, including system-only channels), custom package channels and child channels, system grouping, creation and management of multiple organizations, etc. etc..

    Apt/update/yum/emerge/etc have nothing to do with this discussion. They are all functionally equivalent for the most part today anyway. RHN SS and SpaceWalk and applications that allow large organizations to manage a very large number of systems, easily. As far as I know, there isn't anything even comparable around that is open source. This is a pretty major release for the community.

  • by Anonymous Coward on Friday June 20, 2008 @04:34PM (#23878535)

    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.

    I've never used the GUI stuff, but I've been using the command line for years and never had a problem (supporting 40 or so servers) with it until RHEL5 stupidly adopted yum. What, exactly, is it that you can't do from the command line?
  • by Anonymous Coward on Friday June 20, 2008 @05:52PM (#23879691)

    Satellite requires an embedded oracle database. That database is only supported on RHEL 4. As for config management I would recommend puppet,

    The greatest value of Satellite is the ability to control which updates will be applied to which server. With yum it is very difficult to do this.

  • by bwhaley ( 410361 ) <<spam4ben> <at> <>> on Friday June 20, 2008 @10:07PM (#23881685)

    False. Satellite supports an external database as well. I suspect the lack of RHEL5 support is due to package incompatibilities.

  • by Midnight Warrior ( 32619 ) on Friday June 20, 2008 @11:18PM (#23881989) Homepage

    We've been using it for a couple of years now, and I've even taken the class on it. Everyone's gripes here are quite true. I've got three gripes with it. One: the Monitoring module [], uses an internal package RedHat bought called NOCPulse. I've got auditing running on our machine and I found that, a piece of NOCPulse, opens /etc/shadow in read/write mode hundreds of times a day. The kicker, is that it's non-obvious from the source code where or how it's doing this, or even why. We've threatened to un-pay for Monitoring unless it gets fixed and now. Since we're using ZenOSS, we'll probably un-pay for it anyway since ZenOSS does all this stuff anyways.

    Two: Oracle is their choice for a backend RDBMS. Oracle charges a very fine penny. Now, as RedHat open sources it, folks will hopefully change out the database package. RedHat has already indicated that they will keep the price the same, so my guess is that the expected profit increase will come from goading the OSS community to dump Oracle, thereby relieving them of licensing costs, and putting the new leftovers straight onto the bottom line. If Satellite Server was comparable in cost to Microsoft's SMS, I don't think folks would mind so much.

    Three: Incremental updates are impossible for disconnected networks without moving all XX Gigabytes of RPMs. I've heard that under the new version, this might be possible, but I'm not holding my breath. In a world that expects you to maintain patch compliance, it's not so easy to deploy those patches. Where this matters most is isolated U.S. Government networks. Getting patches is non-trivial. Yes, it's the admin's job to sneaker-net the updates which is fine, but importing is not as trivial as you might think it should be.

    Usability is something that is really lacking with this product. Notably, in configuration channels (which are a nice idea) while I'm looking at a configuration file, I should have the choice right then and there to deploy it to one or more hosts. Nope. I have to go to the system group and tell them to go get it. And even that is buried unless you've been trained on where it's hiding.

    So, can the community do this? Sure. But I think most folks would rather just rewrite it around yum. The best thing Satellite offers is the automation of kickstarting and joining to the Satellite server. Sure, you go over DHCP, TFTP, and kickstart files in class, but Satellite does most of the work for you. I kinda wish mass deployment and patch monitoring was the default way to do RedHat, and the manual method is only meant for your first couple of installs - especially since RedHat has declared that they aren't interested in focusing on a general-user desktop [].

  • by Anonymous Coward on Saturday June 21, 2008 @03:22AM (#23882931)

    Your experiences seems old.

    You used only RHN Hosted and not RHN Satellite. TFA is about RHN Satellite. Also, you do not 'Buy RHN' when using RHN Hosted, as it comes FoC with your Red Hat subscription.

    RHN satellite can run completely disconnected from any network. You can stay like this or open maintenance windows to temporary connect to RHN Hosted to sync updates. If you choose to stay completely disconnected from the internet, Red Hat will send you updates on optical media, you can still patch your servers.

    The ability to redeploy machines across from 32 to 64bit, preserve files on redeployment, define a kickstart file in 3 clicks, deploy all kinds of configuration files, diff machines configs and packages, create custom repos with your own software ... The day where you are admining 200+ boxes, you will love the ability to schedule a command on all those boxes from a central point, and up to 4 years in advance.

    There is so much more to it that it will require a longer post ... but in short, this is why people buy RHN Satellite, because it makes Windows level admins able to manage linux after a small learning curve while keeping everything within their LAN. Sure creating repos and custom scripts can work too, but the convenience to have it all under a roof, under a week, with no problem of scalability, weeks of testing and fine tuning is again priceless to new organization coming to Linux. Also, what do you think is quicker to learn for the average Windows admin nowadays: command line creations of repos and sh / perl scripting or learning a web interface ?

    Finally RHN provides an API that uses XML over RPC, standard compliant and usable by majority of languages that will let you do things without touching the web interface.

The primary function of the design engineer is to make things difficult for the fabricator and impossible for the serviceman.