×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

54 comments

Automatic Updates (4, Funny)

suck_burners_rice (1258684) | more than 5 years ago | (#23874045)

It's about time! Now every kind of GPLed software, from operating systems to yet another version of colorizing "ls" can provide a nifty "automatic updates" feature without too much extra work on the part of the developers.

Re:Automatic Updates (2, Insightful)

donaldm (919619) | more than 5 years ago | (#23874545)

Automatic updates may be ok for the novice or the person who has no interest in knowing what is being updated until it is actually updated.

The problem you have in the enterprise is the IT mangers need to know what is being updated and talk to the appropriate application people so they can get approval to do the actual update. In the majority of cases you are going to find a vendor who is not willing to support a particular update so you end up with a political mess on your hands.

From the Redhat, Fedora or Centos side it is very easy to setup and maintain an in-house yum server so that you can "lock-in" a specific set of updates from which acceptance tests can be run and once accepted the same updates are then requested by each client. This may take a few months between testing, final acceptance and eventual update roll-out, in the meantime no new updates are are accepted. Then the cycle repeats.

Sounds silly but large corporations insist on this and the Redhat Satellite server was one of the best ways of doing this, however it was not a cheap solution. Since Redhat decided to use yum (RHEL5 on) the Satellite solution can now be replaced by a yum server although some companies with huge amounts of Linux machines could still benefit from the Satellite solution.

I am not quite sure if Redhat supports yum on RHEl4 but the packages can be got from Redhat and they do work. Using yum (not that much different to using apt-get or yast) is very easy and you can vet what you are going to update as well as preventing some applications from being updated such as "Java" and "MySQL" which can result in embarrassing moments if these are updated and the MySQL application does not support the later release.

Re:Automatic Updates (2, Interesting)

Gazzonyx (982402) | more than 5 years ago | (#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.

Re:Automatic Updates (1)

Bandman (86149) | more than 5 years ago | (#23876751)

You sound a lot like me, and my justification for moving away from Slack in the enterprise. We're almost all CentOS now, with some RHEL.

The only difference is that, on my desktop, I use Ubuntu now. I can't get past Slack's (lack of good) package management. It was really frustrating, because I've used it since 1997 and I really liked it. No support for PAM and no networked package management did me in.

Good Points (2, Interesting)

Gazzonyx (982402) | more than 5 years ago | (#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.

Re:Good Points (1)

Bandman (86149) | more than 5 years ago | (#23879741)

64bit machines was another sticking point. The servers we started getting needed a derivative Slack source because there wasn't a native Patrick-released version.

In related news... (0, Redundant)

morgan_greywolf (835522) | more than 5 years ago | (#23874059)

Michael Jackson is suing Red Hat for trademark infringement, stating that the name 'Spacewalk' is just too similar to his trademark, 'Moonwalk'. ;)

Re:In related news... (4, Funny)

kiehlster (844523) | more than 5 years ago | (#23874149)

Why do you think that the Red Hat mascot looks strikingly like MJ from the 80s? If it was a full body representation, he'd be doing the moonwalk.

Re:In related news... (0)

Anonymous Coward | more than 5 years ago | (#23876827)

Funny +1. Insightful WTF?!

Caveats (2, Interesting)

mattmarlowe (694498) | more than 5 years ago | (#23874195)

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.

Re:Caveats (1)

foobat (954034) | more than 5 years ago | (#23874373)

From the spacewalk website

"Spacewalk manages software content updates for Red Hat Enterprise Linux and other Linux distributions such as Fedora, CentOS, and Scientific Linux, within your firewall." http://www.redhat.com/spacewalk/ [redhat.com]

Re:Caveats (3, Informative)

mattmarlowe (694498) | more than 5 years ago | (#23875193)

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 rhn.redhat.com 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.

GPLv2 (2, Interesting)

dk90406 (797452) | more than 5 years ago | (#23874239)

Interesting that the chose GPLv2 over the GPLv3. Does anyone have a educated guess to why?

Re:GPLv2 (1)

bsDaemon (87307) | more than 5 years ago | (#23876171)

because they felt like it? because the gpl 3 is even more of a political statement than v2 and they didn't want to be a part of it?

Re:GPLv2 (2, Insightful)

fsmunoz (267297) | more than 5 years ago | (#23876545)

Because they felt like it is a good answer.

The "political statement" part and the "didn't want to be a part of it" are however conspiracy theories - or more likely a reflection of your own views, given your username - that seem to forget that RedHat welcomed the GPLv3 and contributed to the process:

We want to congratulate the Free Software Foundation, the Software Freedom Law Center, and the many companies and individuals, who have all worked so diligently, for their efforts in developing version 3 of the GNU General Public License. Their work is to be commended. Red Hat believes our end user customers will benefit from several of the new provisions in GPLv3, including the patent license provisions. Red Hat will continue to contribute to projects that migrate from GPLv2 or other licenses to GPLv3, and we will look to include GPLv3-licensed projects in our future distributions. GPLv3 will also be added to the list of approved open source licenses under Red Hatâ(TM)s Patent Promise. [redhat.com]

Which means that they'll use both and see no problem in either - just like the vast majority of projects and developers that like the GPL in the first place.

Re:GPLv2 (1)

bsDaemon (87307) | more than 5 years ago | (#23876613)

Of course, given your email address, one could say that you might be slightly biased in the opposite direction :-p but yes, thanks for the info there afterwords. quite educational.

Re:GPLv2 (1)

fsmunoz (267297) | more than 5 years ago | (#23876839)

Of course, I'm also an interested party and so a bit more that slightly biased, quite true.

In any event there *are* companies that would probably avoid the GPLv3 for the reasons you mentioned, I was just pointing out that RedHat is not one of them - partially because of their business model I suppose.

Will it support LDAP and Kerberos? (1)

Zombie Ryushu (803103) | more than 5 years ago | (#23874273)

Does it support LDAP and Kerberos? I used LDAP and Kerberos to replicate my updates using urpmi on Mandriva to keep all my updates syncronized on all my boxen for Application development. Kerberos is a must.

Re:Will it support LDAP and Kerberos? (2, Informative)

foobat (954034) | more than 5 years ago | (#23874339)

it's planned to tie in with freeIPA https://fedorahosted.org/spacewalk/wiki/TheRoadmap [fedorahosted.org]

Re:Will it support LDAP and Kerberos? (0)

Anonymous Coward | more than 5 years ago | (#23875037)

have you tried freeipa? if so what are your impressions?

Re:Will it support LDAP and Kerberos? (1)

Zombie Ryushu (803103) | more than 5 years ago | (#23875619)

No I have not, it is not considered ready for primetime yet, I do have a functional Linux Directory service and Single Sign on solution.

Re:Will it support LDAP and Kerberos? (0)

Anonymous Coward | more than 5 years ago | (#23880869)

You can use LDAP or Kerberos for authentication with Spacewalk using pam.

My experience with RHN Satellite (5, Informative)

bwhaley (410361) | more than 5 years ago | (#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 rhn.redhat.com 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.

Re:My experience with RHN Satellite (4, Interesting)

antirelic (1030688) | more than 5 years ago | (#23874679)

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 (1, Informative)

Anonymous Coward | more than 5 years ago | (#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.

Re:My experience with RHN Satellite (1, Informative)

Anonymous Coward | more than 5 years ago | (#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?

Re:My experience with RHN Satellite (2, Informative)

Anonymous Coward | more than 5 years ago | (#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.

Re:My experience with RHN Satellite (5, Informative)

EvilAlphonso (809413) | more than 5 years ago | (#23874697)

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.

Re:My experience with RHN Satellite (2, Interesting)

bwhaley (410361) | more than 5 years ago | (#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.

Re:My experience with RHN Satellite (2, Interesting)

sirrmt (971078) | more than 5 years ago | (#23878733)

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!

Re:My experience with RHN Satellite (3, Informative)

nologin (256407) | more than 5 years ago | (#23874797)

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:My experience with RHN Satellite (1)

gladish (982899) | more than 5 years ago | (#23875053)

I've seen more and more of this "provisioning" talk lately, and when you really get down to it people mean they want one image (same kernel/config files, etc) on all machines. My first question is "Whatever happened to net booting?

Re:My experience with RHN Satellite (2, Insightful)

Wdomburg (141264) | more than 5 years ago | (#23875803)

Net booting is only one aspect of provisioning. What about tracking (servers, virtual machines, assets, images, configs, etc)? Or adding hosts to DNS and DHCP configs? Or keeping machines synced after the initial install? Or password and user management?

Re:My experience with RHN Satellite (1)

Anarke_Incarnate (733529) | more than 5 years ago | (#23875139)

Novell's Zenworks Linux Management pisses on RHN from a lofty perch. The cost of it also makes RHN look bad.

Re:My experience with RHN Satellite (1, Informative)

Anonymous Coward | more than 5 years ago | (#23879691)

Satellite requires an embedded oracle database. That database is only supported on RHEL 4. As for config management I would recommend puppet, http://reductivelabs.com/trac/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.

Re:My experience with RHN Satellite (2, Informative)

bwhaley (410361) | more than 5 years ago | (#23881685)

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

Re:My experience with RHN Satellite (2, Informative)

Midnight Warrior (32619) | more than 5 years ago | (#23881989)

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 [redhat.com], uses an internal package RedHat bought called NOCPulse. I've got auditing running on our machine and I found that gogo.pl, 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 [slashdot.org].

Re:My experience with RHN Satellite (1)

xsuchy (963813) | more than 5 years ago | (#23900915)

I've got auditing running on our machine and I found that gogo.pl, 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.
I searched the code and there is really no obvious point where /etc/passwd is open for writing. But I neither can find any reported Bugzilla. Did you report it? Can you point me to Bugzilla number, where I can find additional information about this? Then I can probably fix it.

RHN? Yum? (1)

QuoteMstr (55051) | more than 5 years ago | (#23874689)

Why use RHN when yum works very well?

Re:RHN? Yum? (2, Informative)

Anonymous Coward | more than 5 years ago | (#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:RHN? Yum? (1)

kiehlster (844523) | more than 5 years ago | (#23875509)

This is also where no one RTFMs before building or installing anything, so everyone lives on a "Oh, I didn't know that could do that" basis or a "What does this button do" basis.

Kudos! (4, Interesting)

giminy (94188) | more than 5 years ago | (#23875351)

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.

Oracle? Doh! (3, Interesting)

nfsilkey (652484) | more than 5 years ago | (#23875709)

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.

Re:Oracle? Doh! (1)

Rob_Bryerton (606093) | more than 5 years ago | (#23878739)

You do understand that anyone can download, install and use that version of Oracle free of charge, right? Oracle XE, aka *Express Edition*.

modN up (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23875791)

when done playing to this. For To be about doing in a hEad spinning EFNet, and apply downward spiral. In Preferrably with an FreeBSD at about 80

Landscape (2, Interesting)

sciurus0 (894908) | more than 5 years ago | (#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.

Re:Landscape (0)

Anonymous Coward | more than 5 years ago | (#23884107)

Unlikely, Ubuntu & Canonical don't care about free software.

Re:Landscape (1)

Ashcrow (469400) | more than 5 years ago | (#23886703)

Hopefully. I'm sure it will put pressure on them to do so ... if they do the right thing or not is up to them. I personally think in this specific space it has been easy for open source companies to keep this software closed. Now that one of the bigger FLOSS companies decided enough was enough it would be great to see some competition with other FLOSS software.

Though honestly I don't think it will make Canonical release a FLOSS version of Landscape, at least not any time soon. Take a look at https://bugs.launchpad.net/launchpad/+bug/50699 [launchpad.net]. While I think launchpad is one of the best bug/code/etc.. systems out there, it's not FLOSS. The reasons for that seems to be:

1. Mark doesn't have a revenue model for launchpad and this open sourcing the code would put his developers out of work (at least that is what it seems he is saying).
2. It's a 'hosted solution' so it doesn't need to be open source.

My assumption is that the same views would be extended to Landscape and other hosted applications.

Full circle!! (0)

Anonymous Coward | more than 5 years ago | (#23878417)

To those in the know, RHN was originally NocPulse a Silicon Valley startup bought by Redhat. That was based on NetSaint, an open source project. So, now they are open sourcing part of a project that was based on an open source project!!

Re:Full circle!! (0)

Anonymous Coward | more than 5 years ago | (#23881677)

RHN was not originally nocpulse, RHN integrated nocpulse into it a few years ago for a monitoring solution. They are open sourcing everything, not just the nocpulse part.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...