Jesus M. Rodriguez wrote:
On Wed, Nov 19, 2008 at 8:00 PM, Nico Kadel-Garcia <[EMAIL PROTECTED]> 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.
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
