Did a POC of it at my current company. I've also had the RedHat Enterprise Deployment and Virtualization class.
This product was originally envisioned began development before RedHat even had an IPO. The reason I mention this is that the mindset around systems management at that time is what you're getting with this product. Which means it was designed for management types to be able to say that everything is up to date and secure all the time. I don't think they ever really fleshed it out as a systems management platform in the first place. I have also seen RedHat Sales Techs that couldn't get the product installed and required my assistance to get it running. The process of adding your own content to Satellite is one of the most convoluted and time-intensive that I've seen. If you wish to add your own packages, you must GPG all the packages and then find some way to distribute your keys, which Satellite cannot do for you (this is because the only way that would work through Satellite is if you packaged your gpg key and had a post script to run the rpm --import, but you can't do that because all your packages must be signed and can't be installed if your gpg key hasn't already been imported. The program claims support for Solaris, but it is woefully inadequate in a multitude of ways (esp. now with zones and containers) It was recently open-sourced, but they charge for the working version because it is completely dependent on Oracle to run and the license is for the embedded Oracle database that comes with it. I haven't seen any progress making Satellite work on another RDBMS yet. The monitoring portion of the product is a joke and completely an afterthought. It severely lacks any configurability or extensibility. The licensing scheme is insane. You need an "entitlement" to track the box and manage packages. You need another to do automated installs, and another to do monitoring. All of these are PER MACHINE. When I asked about scalability, I was told there were Satellite Proxy servers, but they were really only to span physical locations, not really to distribute load. When I asked if the product could be built out in such a way as to manage 10K+ machines, they told me we should pay them to maintain such a system for them. Even their instructors have been known to make veiled references to the poor conception and implementation of the product. I was told there would be some major changes in a newer version, but I believe we used 5.? in the class I took a little over a year ago. I'm guessing the major changes they were talking about were making it open source. On Mar 9, 11:50 am, Stephen John Smoogen <smo...@gmail.com> wrote: > On Sun, Mar 8, 2009 at 11:37 PM, Russ Allbery <r...@stanford.edu> wrote: > > > PeterBurkholder <pburkhol...@gmail.com> writes: > > >> My boss has RedHat coming in on Tuesday to give a spiel on RHN > >> Satellite. I'm dubious, as it seems mostly like a web UI wrapped around > >> a Yum repository system and a half-baked configuration management > >> system. I'm of the opinion that our time and money would be better > >> spent getting off of RHN for package distribution, setting up our own > >> Yum repositories, getting a good start on Puppet, and bringing in Luke > >> Kanies for a week to bring the Puppet installation to up to snuff. > >> FWIW, we'll be looking about 50 systems that need to be managed, and we > >> may not have to pay for server itself ($13.5K) just for the system > >> subscriptions ($200 each). > > > After spending a completely unproductive six months trying to get the > > Satellite to work for us, we did pretty much exactly what you said above > > and had considerably more success. In our experience, the Satellite is > > buggy, limited, and opaque, and basically unsupported by Red Hat in any > > meaningful way. (I think the icing on that cake was when the Red Hat > > on-site engineer proved incapable of installing his own product.) > > All I can say is that I have had a 180 degree different viewpoint on > it.. but this isn't the list to go over that. The configuration > management system is not is strong point though. I would go with > puppet in it instead. > > > I do, however, know other people who have had considerably better luck > > with it and swear by it. > > > -- > > Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> > > -- > Stephen J Smoogen. -- BSD/GNU/Linux > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
