[ale] enterprise rhel/centos management

Brian MacLeod nym.bnm at gmail.com
Wed Aug 11 14:04:49 EDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 8/11/10 10:50 AM, Joey Rutledge wrote:
> Hey all,
> 
> A co-worker and I are currently in the process of trying to determine
> the best method to manage a handful of RHEL 5 based systems.  We are
> looking at deploying over time at least 100 or more RHEL systems and
> are trying to determine the best method to manage security updates,
> package versions, entitlements, etc.


Stopping here, this sounds exactly what RHN Satellite is for, up until
you hit the etc.  The devil is in those details.


> So far we have come up with the following
> 
> RHN Redhat Satellite Spacewalk in-house yum repository
> 
> For those using RHEL/CentOS in a corporate environment, what are you
> using to keep up with the systems?  I'm looking for ideas and
> opinions around the choices above and open to any other means of
> management that you might be using currently.


I have a major installation utilizing RHN Satellite tied with a set of
servers to run cfengine to a mixed RHEL/Solaris environment.  I have
been building/rebuilding lots of the initial boot stuff so that we can
kick machines off with the least fuss.

In addition to those components we have a yum repository, and we are
experimenting with mrepo [1], which allows you to create your own
repositories of software.  Yes, RHN Satellite can do this (as long as
you are using RHEL), but it is harder, plus, we can shift the
distribution of updates from RHN to the mrepo stuff as needed and still
have RHN probably recognize the state of the system.  Not only that,
since there are various units of IT scattered around, we're trying to
encourage cooperation and using mrepo smooths some of the issues out
(since it was actually their idea, but it works great, despite being
older code). And finally, mrepo can manage many different instances of
distro-centric repositories (Fedora, RHEL, CentOS, SuSE).

Our cfengine environment picks up the machines right after
kick/jumpstart, and manages their conditions from there.  It takes a lot
of time to develop this, but it can be well worth it.  Puppet admittedly
appears to have a less severe learning curve, but, I use what I know.

Brian

[1] http://dag.wieers.com/home-made/mrepo/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iQE4BAEBCAAiBQJMYuZBGxhoa3A6Ly9rZXlzZXJ2ZXIudWJ1bnR1LmNvbQAKCRD5
XCJY/q4Y6OADCACJVEo82CW8azKgI6qAsEkYtZN4/3DpLrKFE7SOvzbyBwiBphfT
jgjCis+iLvEodcX8x000LJzP0HExKV3NuFo6H1y+z2LRK/OVmg/Cx6Xh44q/PDeu
sDQadz876F0yLtyT5d0f+yFkxUdkwCKeIN23I0e/mzGHDu8cr32SYAUoX9+Gf69j
aMX8HtLUVeXoiNpXT6+FoeXWxxs35B/+QQRM+aTy6Y6W2pQyJSDhEkUoQPJ7Ive5
JjmE2E0///3D+BYmxILYEOL1Z1JNkbc2FNV7U4bjzpGktJ4MZxT2KqcjfGUGMnM5
8+VdGWnuy+djZOI6raIV8MwFuId/uQNDxCVD
=7v+P
-----END PGP SIGNATURE-----


More information about the Ale mailing list