[Spacewalk-list] Why does FAQ claim Spacewalk cannot manage RedHat entitlements?

[Nico Kadel-Garcia]

Jesus M. Rodriguez wrote:
> On Wed, Nov 19, 2008 at 8:00 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>   
>> The FAQ asks:
>>
>>     
>>> Can I use Spacewalk to sync my entitlements for Red Hat Enterprise Linux
>>> and other Red Hat software products?
>>>       
>> And says 'no'. Whyever not? It's straightforward to set up an internal
>>     
>
>
> Read the answer again carefully.
>
> "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."
>
> It states you need the Satellite product in order to "connect to
> rhn.redhat.com and
> satellite-sync Red Hat software content". Spacewalk can't connect to
> rhn.rdhat.com like
> Satellite can.
>   
There are two distinct parts of the management issue. One is the RHN 
published errata and RedHat Network service. That's understandably 
unavailable? Yes, that makes sense for a freeware product, even if it 
requires an Oracle database to run on (and the Oracle database was a 
prohibitive cost of my last review of using the RedHat Satellite tool 
for a 50 machine deployment).

But if it can handle CentOS and Fedora style local or distributed yum 
repositories, it should be able to handle an internal RHEL mirror. And 
the internal RHEL mirror remains the only graceful way, other than 
investing in a pretty expensive full-blown Satellite or one heck of a 
lot of bandwidth, to do kickstart redeploys of large numbers of servers 
or their updates simultaneously. By using a 64-bit environment and 
potentially a 32-bit chroot cage or virtualized OS on it, the same 
HTTP/FTP server can be fully populated with daily RHEL synchronizations. 
For many systems managers, they neither need nor want the integral 
reporting back to the mothership built into the Satellite tool: 
something like Spacewalk that remains potentially independent and can 
deal with Fedora and CentOS seems much preferable. The announced updates 
from upstream will be slower to generate notifications to your 
sys-admin, but for a large environment and any bulky updates (such as 
the switch from 5.1 to 5.2), it will certainly be faster than the normal 
'pull patches through yum-rhn-plugin directly from Red Hat's servers'.

It seems from the specs that Spacewalk and Satellite provide flexibility 
in individual host package management that I achieve by using plain yum 
and a local mirror (with proper GPG cheking, for verifying updates, of 
course!!!). GUI's are useful, and the other features of Spacewalk and 
Satellite are desirable, but it seems possible to use Spacewalk to 
provide nearly as effective management as the Satellite for registered 
systems.

>> repository mirror with 'reposync', sync it daily, and configure tools like
>> yum (without yum-rhn-plugin) and kickstart and mock to point to that
>> repository instead of using the up2date in granny's nightgown that is the
>> yum-rhn-plugin utility. This allows you to use the full yum configuration to
>> exclude individual components from the RHN repositories, and enormously
>> speeds update performance in the UK where I am right now. This is
>> particularly true with large deloyments, where a corporate externel network
>> connection may be sucked dry by a server room doing an update from RHEL 5.0
>> to RHEL 5.2 and sucking down hundreds of updates per machine.
>>     
>
> Certainly, if your connection to RHN from the UK is slow, you may
> consider Satellite or
> a RHN Proxy which are supported products. http://www.redhat.com/red_hat_network/
>   
Yes, I reviewed it. I couldn't justify that much money for a modest 
deployment, even though I thought it would be useful and make the 
Windows personnel used to their particular GUI's a lot happier. I've 
also been through virtualization environments a lot lately, where 
registering the RHEL keys in an environment where the clients did not 
have external network access made getting updates at install time 
impossible without a local mirror. Spacewalk or Satellite would have 
solved that: I had to do it the cheap way.

There are big advantages to the cheap local mirror: the ability to use 
'mock' to do chroot package building is very, very handy indeed. I've 
got configuration files for that matched to the CentOS 5 version of 
mock, by the way, if anyone wants them.

>> Is it really forced to use an off-site repository such as the yum-rhn-plugin
>> managed one? Or, if it can do CentOS, why not RHEL off of a local
>> repository?
>>     
>
> Even if you use Spacewalk to manage your CentOS content, you will be using
> the yum-rhn-plugin to connect to Spacewalk.
>   
Can you run Spacewalk on CentOS or on Fedora? Then it would seem not to 
be strictly necessary, unless it's been deliberately crippled.

> I hope this answers your questions.
>
> Sincerely,
> jesus rodriguez
>   
It does provide answers matching the FAQ: I hope you don't mind 
following up further, I'm confused about what seems to be absolutely 
necessary support for Fedora and CentOS, and should in theory be 
functionally available for RHEL. If the tracking of Red Hat errata 
notificatons and upstream communications aren't available with 
Spacewalk, of course that makes sense. They're serious questions, by the 
way: I've done deployments of hundreds and even thousands of RedHat 
machines at a time (including a 13,000 server deployment of Red Hat 6.2, 
which was a wile ago!), and like to see better tools be flexible.