[Yum] yum and indirect downgrades

[yum at schlomo.schapiro.org]

Hi,

Am 20.08.2010 16:55, schrieb seth vidal:
> On Fri, 2010-08-20 at 16:39 +0200, yum at schlomo.schapiro.org wrote:
> 
>> What we are trying to do is manage a server farm through RPMs *only*,
>> delivering all software and all config files to the server farm through
>> RPMs which are automatically built from a SVN repository with all the
>> neccessary information. Each server is personalized through a dedicated
>> (per host) is24-config-$hostname RPM which contains all config files and
>> dependencies to the software RPMs that should be installed on the
>> server. In the end we use RPM dependencies to model our server farm and
>> have a transactional representation of all our servers and their
>> functions within the context of RPM.
> 
> 
> This is most likely not a good idea. Rpm is just not instrumented to be
> used this way and most rpms are not built to deal with configuration
> like this.

We found out that for a typical web server there is a handful of things
we need to do during kickstart to be able to use RPMs for this purpose.
Of course we build our own custom tomcat RPM etc. because for us a
software RPM should not ship with configuration files (we ship them
through the config RPM).

> You're much better off taking yum and combining it with a good config
> management system: puppet, bcfg2 to name just a couple of them.

I know that this is a common choice, but I really like to have one tool
that knows all about a server. AFAIKT all these tools don't really think
within RPM even if they can instrument yum to install or update packages.

But a simple thing as beeing able to do "rpm -qf <file>" for *any* file
on a server seems to be a worthwhile benefit for RPM-only deployment
(IMHO) and so far we managed to optimize our own software and the system
to be RPM-deployment-friendly.

I don't believe that only because distros did not think that users might
want to use RPM for their own purposes this is not a valid way of doing
system administration. IMHO in any case the total complexity of the
problem stays approximately the same and one can only choose in which
tool to place the complexity. The effort we spent on building "good"
RPMs was IMHO actually less than achieving the same level of
reproducability with bcfg2 (which has been considered here as well).

On the positive side we have a thick layer of protection agains human
error because our RPMs will refuse to install if not all requirements
have been met (e.g. appropriate software configurations, incompatible
versions, conflicting services on same machine etc.).

> If you're looking at push-oriented tools then you might want to take a
> look at func and something I've recently been working on func-yum.

I have seen it but did not yet have time to play with it.

Anyway, I am looking for people who would like to think more about doing
everything with RPM and exchange ideas and experiences with them...

Kind Regards,
Schlomo