Hi, Am 20.08.2010 16:55, schrieb seth vidal: > On Fri, 2010-08-20 at 16:39 +0200, yum@xxxxxxxxxxxxxxxxxxxx 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 _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
