[Novalug] Red Hat Network (RHN) technical information -- WAS: The "value" proposition of Red Hat

Peter Larsen plarsen@famlarsen.homelinux.com
Tue May 11 21:11:44 EDT 2010


Since I kinda got dragged into this, I'll give a reply (final one I
hope) in this thread.

On Tue, 2010-05-11 at 12:15 -0400, James Ewing Cottrell 3rd wrote:

> Once again, MONEY is THE most scarce resource in most of the 
> organizations I work for.

Hopefully not enough to not pay you?  There's a cost to business and as
IT resources go, the subscription price still beats the cost of a
commercial installation. 

What the organization has to ask itself is how much will they loose if
the IT infrastructure fails. Once you have that number, $500-1500/year
isn't really significant.

> And please, gimme a break! As I have said before, for all *Practical* 
> intents and purposes, CentOS *is* RHEL. In fact, to quote YOU ...

Software wise, yes. Service wise, no. Remember, you're NOT paying for
the software - it's FREE (as in no charge). 

> How many instances have you seen where the two act differently?

All the time. Try to find a phone number for CentOS if a component
fails; let me know how that turns out for you.

> Certification is just an Artificial Barrier erected to gain preferential 
> treatment for Vendors. And provide Artificial Security for Customers.

In this case, it's OS certifications mandated by the government. We're
not talking RHCE or the other types of professional certifications that
Redhat provides.

I'm definitely not pro the commercial certification systems, but they do
have some value. Since our educational systems doesn't provide the same
level and details of IT technology, the certification is key to prove
that inexperienced people, or people you don't know, has a known level
of knowledge of a particular product offering. Its not just a comfort
blanket. But it's not a guarantee either. I would like to hear your idea
on how to provide a framework for qualified workers that didn't include
certifications?

> I foresee an entire thread on that, so anyone, please change the subject 
> if you feel the need to discuss that.
> 
> >      > The License Key is a PITA to administer.
> > 
> > I have NEVER used a License Key. Ever. Not once in the 10+ years I have 
> > install RHEL or previous versions.
> 
> Then why are they distributed? Why do they have a kickstart directive?

You're confusing terminology. Technically redhat doesn't use a license
key. They use entitlements. It's NOT the same as Brian wrote pages and
pages about earlier. Again, remember the software is free - Redhat
doesn't own the software and cannot prevent you from using it. But they
can stop providing you the subscription service if the subscription runs
out. 

That doesn't prevent the software from working. And it doesn't prevent
you from finding another source to get updates from. What Greg/Brian's
points are here, and I think they are important for the FOSS community
as a whole - is that providing a robust enterprise platform is costly.
As professionals we benefit from that work, so it's in all our interest
to make sure it's funded. Without it, we would have very fluent and
rappidly changing distributions that wouldn't be supported by anyone.

> Peter Larsen said:
> "once you have your RHEL it doesn't stop working
> just because the entitlement expires. But upgrades does stop working -
> and so does the ability to add additional packages."
> 
> Hmmm, that sounds like "enforcement" to me!

Not at all. That's the deal here. If you can find another source for
updates, go ahead. Or let's say you rent a TV from RentACenter - and
after 6 months your rental contract runs out and you don't renew it. It
won't be long before you have a truck come to your home, and no more TV.
So you pay Redhat to provide you TESTED updates that won't kill your
system. When you stop paying for that, you don't get them. I hope you
understand the value here.

When you look at distributions like Fedora and Ubuntu they're not as
ruggedly tested. As anyone using those distributions here can tell you,
things often break with them. You pay to get the updates tested and
verified by redhat before they're applied. 

I do understand Bryan's notion that CentOS is smooching on Redhat's work
and as such you're getting something for free. But while you do get the
updates with Centos (a  little later than with Redhat) you don't get the
ability to call/write and get a solution to a problem you're having. And
a company that stand behind the solution they provided. 

> >     You can with RHN.  You can generate Activation Keys and name it
> >     whatever you want.  It then tracks what entitlements are utilized by
> >     systems, so organizations can know exactly what they are using,
> >     the SLAs on the systems, etc...
> 
> OK, but these are just aggregates of single License Keys. So if you have 
> 100 servers in a Data Center, you generate one Activation Key, and 
> associate it with all your Single License Keys.

Again, entitlements ;)  Basically, with a RHN account you see the list
of entitlements you have available, and the systems using existing
entitlements. This is basic RHN. For larger installations, RHN has a ton
of features to quickly deploy and synchronize multiple servers (RHN is a
sort of "satelite").

> So now you have 1 kickstart file instead of 100. OK, that's a real 
> improvement. But still worse than No Key at all.

No keys. It's a bad terminology here; the "key" is purely needed to
identify the type of installation and to make the connection to the
entitlement. It's definitely possible to install from the CD without it
so it's not a locked door you need a key to open.

> OK, maybe I can live with that. Perhaps I can live with that. Perhaps my 
> only objection to RHEL vs CentOS really is Free as in Beer.

I think some at NovaLug would call it "something for nothing". The value
it brings is the stability available for people to "evaluate" what an
enterprise platform is all about; and that would be the point that I
have with Redhat's approach. Granted, they are funding Fedora but
something to showcase an enterprise platform they don't provide without
a subscription. 

> As for posting information that is "over 7 years old", well, it's seven 
> years to YOU, because you LIVE this stuff day in and day out.

Just because I just learned about XXX today, doesn't mean it's a new
product. You're missing the critique - your statements were true 7 years
ago, not today. But I think part of the argument here is words - and not
context. Yes, you cannot download a RHEL without a valid subscription
(just need one - you can download as many you want after that). And yes,
when your paid update/support subscription runs out you loose that
ability. But your system is NOT hosed - it doesn't stop functioning as
an expired key usually will do.

For instance, one of the systems we integrate with at work is a
radar/AIS system. It has a hardware key to be operational. If that key
is removed, or expires - it stops working. You cannot get the
application running without it.  That's the association people get when
we talk about keys. And that's NOT THE CASE with Redhat.

> But I've spent more time with CentOS than RHEL, and even the companies 
> that use RHEL don't always use RHN fully or even at all.

RHN isn't really necessary. I personally don't like the interface for
managing the boxes but it has some features once you have 50, 100, 150
boxes to make your life easier. I've never had more than 20 active
servers so RHN didn't provide that much value. It was easier for me to
just schedule cron jobs with up2date/yum calls. 

> A certain subsidy of a certain cable company which as hundreds of 
> servers kickstarts its RHEL distros from its own server and never even 
> calls RHN. Whatever comes on the RHEL CD/DVD is what the server runs for 
> its lifetime.

There are many many reasons why you may want to run your own repository
and configuration management system like Satelite. RHN isn't mandatory.

-- 
Best Regards
  Peter Larsen

Wise words of the day:
 The real value of KDE is that they inspired and push the
          development of GNOME :-)
	-- #Debian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.firemountain.net/pipermail/novalug/attachments/20100511/3d7dcbf2/attachment.asc>


More information about the Novalug mailing list