Is It Clear?
No! It never is, it is all about what your environment looks like and what you are trying to achieve. Both solutions provide configuration management, both have a paid for and a free version, although you’d be forgiven for not realising you can get RHN Satellite (or close to it) for free, At the end of the day they are different tools aimed at different audiences and it is important that you, yes you the sysadmin, works out what your environment is, not what it might be, not what think it is, but actually what it is.
Step 1
Before we even consider the features and the pro’s and con’s of each solution we (and I mean you) have to work out what the solution needs to provide, and more importantly the skill set of those managing it. There’s a quick way to do this and a slightly more laborious one, lets look at what technology is used to run each solution.
It’s worth noting the following skills are what I would say is needed to produce an effective system, that is not to say that you could do it with less or that you shouldn’t have more skills….
RHN Satellite required skills
That’s it, it is designed to be easy to use, the installation and configuration is not overly easy, if you know what you are doing / As good as the RH Consultants, You’re looking at 3 days, if you have no idea what you’re doing, allow 2 weeks. Personally I would get Red Hat in to set it up and train you at the same time you’ll be in a better position for it.
Puppet
A slightly higher set of skills, but achievable by most, it is not going to be difficult to install and get working, I’d think if you had an RHCE you’d have a working puppet server in a matter of mins (you would need to add a yum repo and install a package, done)
Who’s running the service?
Okay so you, the super dooper sysadmin, manage to convince yourself that you are the right person to run puppet, You get it installed set up and configured, write a few basic modules and then pass it off to some other team to “run with it”, their skill set is closer in line to those needed for RHN Satellite. In short, Bad sysadmin!
You have to consider who will be using the system, the skill set and the aptitude to learn and progress, just because you want to do puppet doesn’t make it the right solution. You could always go with the more simple RHN Satellite server to start with and as skills develop look back at something like puppet in a couple of years.
Step 2
What features do you need? Not what features you want… So, what does that mean… Do you need to have dynamic configuration files, files where depending on what the state of the node or configuration around the node change their configuration using if statements, loops, case statements etc?
Do you want to easily be able to build and deploy servers from “bare metal”?
Hopefully by this point you will have a good understanding of the skill set to support it and what the business actually needs, now you’ve done this I can happily tell you that either solution is able to do what ever you are thinking of (in reason) but it was important to get a fuller understanding of what was needed.
Puppet Features, a totally non-exhaustive list
I did say it was non-exhaustive, for a full list look here but be warned, just because it say’s it can do something doesn’t mean it can do it as well as you might think, Doubly true of RHN Satellite server!
The important thing for puppet is the community behind it and the fact it is extensible, you can do anything with it. You can create your own providers, resource types, facter variables etc etc there’s always new developments so you really do need to subscribe to their Blogs
You can get an Enterprise version, which comes with support, a fancy gui and all that warm fuzzy stuff, you can even get the “bare metal” build by using something like Foreman
Enough of Puppet what about the RHN Satellite!
RHN Satellite Features
A few more features can be found here, But the real benefit with the RHN satellite system is the ease of use, if the people running the service are more RHCT than RHCE then it’s worth considering.
I will say it’s easier to manage your patch release cycle, although in reality it isn’t; the RHN Satellite does allow anyone to manage the flow, move systems between different channels etc etc.
One of the features I liked the most was the ability to group servers together and apply patches to those groups and manage a group of servers as single server, and migrate them from dev to staging etc etc.
The ups and the downs
So we’ve looked at what you need and what you want and who should be looking after it and even touched on a few features. With all this in mind I never once mentioned the downsides of either.
The biggest downside with puppet is its flexibility and its pure focus on configuration management, as a result it doesn’t fire up a PXE boot service or easily integrate OS install to configuration with out additional tools, it just does configuration. As a result you have to provide all of these ancillary services in addition to the configuration management to achieve the same completeness of service that you get from the RHN Satellite. It is for this reason that you need the additional skills and experience to cope with it or Foreman
So what about the RHN Satellite server? The biggest let down with this is the configuration management, if you want to push a static file out it’s really straight forward, and when I was looking at this a few years back you could put variables into the files but from memory the set of options were limited, like you could add the local IP address or the hostname of the server, but you couldn’t pass in custom settings.
The biggest benefit of puppet is the combination of generic modules and well written template files, the principles behind it is that you may very well have a complicated module, but you should be able to switch the configuration at a moments notice. This provides a very flexible approach to delivering the configuration. For example You can have a simple apache module which you can add additional complexity to through inheritance, parameters and defines. With RHN Satellite you just won’t get that unless you re-package your apache into its own RPM, for each type of web service.
With the RHN Satellite the biggest advantage is purely the easy of use, it is a jack of all trades and a master of none, but if your aims are simple and your staff not quite up there on the pillars of excellence it is a good solution that you will be able to do most of what you want with.
Summary
For me I’d boil it down to the simple way of determining this.
If your company is predominately Microsoft Windows, or the sysadmin’s are not dedicated (and yes that’s plural sysadmin’s…) to Linux then I would recommend RHN Satellite, unless you have a very specific use case that can not be solved by the RHN satellite it is worth giving up some flexibility. For example, if you need to manage Red Hat and Debian, rule out the RHN Satellite, or if you know that you are going to be growing a team (know not think…) skills and numbers to be dedicated Linux sysadmins.
If you are an open source company, or have dedicated Linux Sysadmins who have been there, done that, brought the T-shirt, ruined the T-shirt redecorating the house and know the difference between nc -z -t and nc -z -w 10. Then I would consider puppet your first choice, it is young and upcoming, it’s easy to forget that it has not been around 5 years. It has some rough edges but they are getting better, and with support from puppet it makes total sense.
It’s worth touching on the training and availability of skills, Good Luck RHN satellite skills are not well-known and mainly retained within Red Hat. Puppet skills are in very high demand and people claiming the experience and understanding may be pulling your leg (a lot in some cases). However training is available for both the RHN Satellite and Puppet
These are not two products to compare evenly, both can be done for free, both can be very complicated, the only recommendation is to not choose either one based on their technical merit alone but more so on which one fits best with the aims of the project, the hearts and minds of those using the system and good ol’fashioned gut-feel.
For me, having used both, I would lean more towards Puppet, but I’m lucky, Where I am we have a lot of very technical people who are able to understand and work with puppet.
soimasysadmin 
Reblogged this on Runwinged's Blog.
I think you’re selling RHN a little short. The main difference over puppet is that RHN gives you a very good way of managing deployments(Bespoke application RPMS) and patch management. If you have thousands of servers and you want to deploy specific errata or packages either under a schedule or by region/group etc, RHN is very good at this and you can off load this work to non-technical staff. The user management does allow users with different access rights too. I think the best thing is to use these two in conjunction with each other – not on there own. This way you get the best of both worlds, puppet enforces configuration policies and RHN for deployments/patching. You can also use multiple satellite servers and with the ability to channel sync you can have a global network of RHN server in specific regions with common channel content – this allow management within those regions of there own RHN servers.
Get both and use there stengths.
Hi Dan,
I agree, RHN is a good product. In larger environments where there is the luxury of money to invest on having a $40k satellite system managing and distributing RPM’s and managing bare metal builds of servers it is a very good tool for that. It is even simple enough that the most basic of sysadmins can get it working in a way that is useful and they could use that interface to manage the patching of the systems quite successfully.
However in smaller organisations where the choice is between buying RHN to do it all because it’s easier or hiring a sysadmin to set up Puppet and Cobbler or Foreman then it comes down to what you have and need, do you have the skill set to maintain Yum, Puppet, Foreman, Cobbler et al or RHN.
It is like being asked if you would like to get to the point of building systems quickly and then struggle to manage them in a week or spend more time setting up the infrastructure and invest in staff to make managing the servers easier, swings and round abouts, and largely determined by the current direction of the business and current skill set employed.
But to get back on point, yes I did sell it a little short on the configuration management side because it is not as powerful as puppet, but it is far easier to maintain a RHN satellite and proxies than it is to set up yum, cobbler and puppet especially when you consider the ongoing management. If you have the money to buy RHN Satellite it makes life really easy for install and deployment, you could even put your configuration files into RPMS and take an RPM based approach to config management which would then wrok really well the RHN satellite and remove the need for two tools to do the same thing (I’m not suggesting that as an approach, as I think it is very timely and only suitable on really large scale where as puppet is suitable on 1 -10000).
Thanks for the comment, it was the first on one of my blogs :)
Matt.
You could always implement Spacewalk instead of RHN, although this doesn’t give you the proper Red Hat Channels, you can still replicate a similar environment. I’d still use puppet in conjunction with this to get the best of both worlds.
I also see that Katello, the new RHN, uses puppet….
[…] RHN Satellite vs Puppet, A clear victory? – 200+ views […]
Hi, so I was looking to get a better understanding about Puppet and how it compares to RHNS. First of all, thanks for giving the detailed information that you have provided. Second, I wanted to know if you have any knowledge of RHNS being used as a monitoring tool? My company has been looking into either getting RHNS or Puppet as a solution for monitoring and patching method. Please let me know if you can come upwith anything, Thanks!
Hi, thanks for the comment. When I was playing with RHNS the monitoring was just being introduced but it didn’t seem to involved at the time, not when it was compared to a proper monitoring tool like Nagios. Puppet will never do monitoring, the closest it come sis with the enterprise product which just reports on how the puppet runs were going, The question I have is why not use tools that are specifically targeted at the job in hand, and I guess that’s where you are. You can use RHNS to achieve a ‘okay’ job of configuration management, monitoring and patch management (I’d say it was very good at this!) or you can use things that are more specific, Puppet and Chef are better configuration management tools but they are harder, Nagios / newrelic are better monitoring tools because they are specific to the tasks in hand.
Bear in mind if you end up going down the puppet route you can use the configuration management and the modules puppet have to help build out and manage your patching solution and your monitoring. For example There are Puppet modules for Opsview which is a good monitoring (Nagios based) tool and that will automatically add nodes into it and is fairly hassle free once the leg work is done, and to be honest a simple yum server is easy to run and it will be harder to get the RPM’s from RHN than set up a Yum server.
Hope that helped
Matt
Thank you for your input Matt. I think that those two paragraphs just helped me find exactly what I was looking for. BTW the system I am working on is at an enterprise level. Let me know if that changes your opinion at all. You rock dude. Cool blog.
Thanks, I’m UK based just outside London which is why it show’s up as a late night post. I’d say if it’s at an enterprise level and there are a couple of sysadmins that aren’t afraid of bash / ruby / perl type scripting or programming it makes sense to look at puppet or chef for the configuration management and a dedicated monitoring tool, RHNS is really good at managing your Packages and you can use it to build bear metal boxes to a known good level so as a build / patch management solution it is good if you have the money to spend on it, but To be honest save the $20k and invest it in training on puppet/chef (one off cost unlike RHNS). I’ve got a lot more blog posts on how to write pupet modules and bespoke stuff for puppet that may be worth reading through.
btw where are you at dude? it says that I posted this comment at 1033pm lol. Its 0434pm here.
[…] of my articles rhn satellite vs puppet, a clear victory? has almost managed 200 views by it’s self. but there’s a few others in there doing […]
I am glad that at least someone is really accessing Puppet to the roots of what the objective of management is in real sense and in complex environments.
Just because Puppet says, it does patch management, it is hardly different from simple software deploy, if you yourself have to set up repos, downloading the rpms and stuff and updating the repo catalog.
This is a quite a fair article I have come across after a lot of reading and usage of Puppet and other CM tools.
“I’d think if you had an RHCE you’d have a working puppet server in a matter of mins (you would need to add a yum repo and install a package, done)”
Your kidding right? I’ve used Puppet for years now. I’ve installed the free version of the servers many times now, vers. 2.x not 3 on rhel and suse/centos. I’ve even installed the commercial pay version, on rhel, centos and Suse. Even the commercial installs failed to work as well, complaining about either an incorrect ruby gem or something, can’t remember. Can you imaging paying big $$ for this stuff, and it doesn’t even install?
I’m sorry, puppet servers do not install in a minute. If it does, you wouldn’t have a working dashboard, foreman or puppet dashboard, reporting, functional manifests. I could go on.. and on.
Puppet agents do install in a minute. And might even work if you have the correct versions of ruby / gems that don’t conflict with what’s on your master. All that aside, when puppet is up and running, it does great work.
Aside from my strong opinion on install times, nice article.
Cheerio
You are right, when setting up foreman, puppet commander or the dashboard it will take longer. However puppet server will install on redhat in seconds, followed by mins (less than an hour for clarity) of config changes to get the same server talking to it’s self. There’s not really a lot to change, and if you are changing a lot the question has to be why?