yum@xxxxxxxxxxxxxxxxxxxx writes: > Hi, > > Am 20.08.2010 16:55, schrieb seth vidal: >> 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 This usually works now (with %ghost in packages), although "rpm -V" doesn't. We've done some work, and I hope to complete it soon, so that "yum verify" will work. Part of that work (that's already done) allows things like puppet to "add" their own files to yum-verify without having to actually create/install packages (although "rpm -qf" won't work). > 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. Well, IMNSHO, if you are doing something different to the distros. you should have a really good reason. Certainly yum features which go against what a distribution will do, will get less priority. And you are relying on a few things that distributions don't do: 1. Split packages into "foo" and "foo-config", this is work for you as I assume you need to repackage a lot of distribution packages but isn't too far from "normal" from yum's POV. 2. You want to upgrade and downgrade, as a normal operation. This is different from "normal". Downgrade / history undo is meant more as a recovery in exceptional cases, where you've had a test package or you use some other way to "remove the updates" (at least from yum's view). One reason for this is that most distro. package installation QA is only done for the upgrade path ... in practice it seems to work whenever I've tried it, but that's not the same thing. The depsolver may get better "requires" downgrade support, but it's not high on the TODO (esp. now we have history undo). 3. You want to create "super packages" where the box will always have the latest super package(s), and everything else will flow down from there. This is vastly different from "normal", you could write a plugin which would do what you want (basically re-implement "update" / "check-update" / etc. -- this is non-trivial) ... but I'm not sure I'd recommend that over just changing what you are doing. The way I'd probably do this is to have one repo. for each type of machine, and then use distro-sync ... or, if it's possible, remove the feature that machines can be "downgraded" normal and just use upgrade. Another way that might work is using groups, and different repos. for dev/test/rel-1/rel-2/etc. So a stable webserver would install @conf-webserver which the rel-1 repos. enabled ... a test mysql server would install @conf-mysql with the rel-1 and test repos. enabled. ...doing #1 is an interesting experiment, and it might well have advantages over puppet/etc. Doing #1, #2 and #3 seems like a bad idea, to me. -- James Antill -- james@xxxxxxxxxxxxxxxxx http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
