Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Red Hat Open-Sources RHN As "Spacewalk"

Comments Filter:
  • Caveats (Score:2, Interesting)

    by mattmarlowe (694498) on Friday June 20, 2008 @11:55AM (#23874195) Homepage

    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)

    by dk90406 (797452) on Friday June 20, 2008 @11:59AM (#23874239)
    Interesting that the chose GPLv2 over the GPLv3. Does anyone have a educated guess to why?
  • by antirelic (1030688) on Friday June 20, 2008 @12:31PM (#23874679) Journal

    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?

  • by bwhaley (410361) <spam4ben@gmaiMOSCOWl.com minus city> on Friday June 20, 2008 @12:41PM (#23874835)

    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.
    Thanks. I get the purpose of OSAD, but all I see is errors in the client and server OSAD logs that are completely useless, even with debugging set to high values. I'm pretty sure it's an SSL cert error.

  • Kudos! (Score:5, Interesting)

    by giminy (94188) on Friday June 20, 2008 @01:13PM (#23875351) Homepage Journal

    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)

    by Gazzonyx (982402) on Friday June 20, 2008 @01:22PM (#23875531)
    Yeah, it sounds silly until yum updates on a Thursday night, samba jumps up ten patch versions and twenty RHEL security patches and users can't access shares because your config has a setting that didn't cause any harm in the past, while blowing up the new samba version.

    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)

    by nfsilkey (652484) on Friday June 20, 2008 @01:34PM (#23875709) Homepage

    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)

    by sciurus0 (894908) on Friday June 20, 2008 @02:07PM (#23876253)
    I wonder if this will push Canonical to release a version of Landscape [canonical.com], their equivalent service for Ubuntu, as free software. Currently Landscape is hosted by Canonical and costs $150 per node.
  • Good Points (Score:3, Interesting)

    by Gazzonyx (982402) on Friday June 20, 2008 @02:57PM (#23877019)
    Actually, I pushed for Slack at work, but it made my (MSCE trained) boss nervous; I had to give something up as compromise for them allowing me to run Linux... CentOS being RHEL was enough leverage to get it through. Ironically, I prototyped the Samba server using Slack because all I could get together, hardware wise, to mock something up was an old EMachine 600 MHz clunker with a 20Gb 5.25" Quantum Fireball drive. Slack is the only thing (other than BSD) that would run on it.

    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.
  • by sirrmt (971078) on Friday June 20, 2008 @04:47PM (#23878733) Homepage
    I quite like the configuration channels, but I tend to find that their tools are lacking. The official API is not feature complete, and I've been forced to hack together my own clients for configuration file management to allow nice, orderly, uploading and centralised revision control..

    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!

Our informal mission is to improve the love life of operators worldwide. -- Peter Behrendt, president of Exabyte

Working...