Hmmm ... this sounds more complicated than ours, but only because you are starting out. My apologies if this e-mail get's alittle long, but I tend to explain things in too much detail and let the reader figure out how much they really want to read. :) Erik Williamson wrote: > Hi all, > > It's looking like our department may start running the systems for the > whole faculty of science (and the university?!?), and I'm faced with > providing a way to patch 'em all. > > We've been sucessfully using yum (& a whack of scripts) for a year now > for just the Comp. Sci. machines, but now... We're wondering what ways > you have come up with to have different repositories for different > departments (Seth, looking at you...). > > I'm currently working on a script for setting symlinks from our mirrors, > but I think my mind just exploded when taking into account different > redhat releases, architectures, and departmental needs. > > Any suggestions out there? Thanks! > Erik. > So we currently have 4 main distributions we have a repositories, though really they are only 2 distributions, with a stable and a non-stable repository for each. We also have 25 of what we call 'workgroups', which you could consider departments. Ours are mainly for experiments, or groups within an experiment. Or even one or two are for just a certain type of machine. Each of these workgroups has a maintainer, and they get to stick whatever RPM's they want in their own personal repository. The only rules are that the rpm's are distributable, and that they don't whine at us if their rpm breaks their own machines. So, how do we handle this, and can this be transfered to some other place. (Yes, I think this idea can be transfered quite easily) First - getting the client machine to point at the right repositories. We build our yum.conf when the rpm get's installed instead of using a static yum.conf file. Our yum.cron also builds it's own yum.conf files on the fly (3 of them in fact) So to build these yum.cron files we have to find out 2 things. 1, which distribution do a 'cat /etc/fermi-release' and then do a little cut and triming. You could do the same with a 'cat /etc/redhat-release' 2, which workgroup we just do a 'cat /etc/workgroups', which is already formatted right which sounds like all you would need as well, though it might have to be a little more complicated than ours, or maybe not. Second - getting the main repositories setup and maintained Well, this is rather easy since we have controll over that. Third - getting the workgroup repositories setup so that the maintainers don't mess things up, yet are able to add and remove repositories. We have a CVS repository that the workgroup maintainers are able to check things in and out of. We then have a script on the distribution repositories that runs every 15 minutes. If there is something new in the CVS repository it updates it's local repository, then runs a yum-arch on that workgroup repository, then sends an e-mail to us and the workgroup maintainer saying that it's been updated. We didn't think all of this up at once, it's been several years that evolved into this format, but it works quite well. If you need any scripts, from how we build the yum.conf, to how we do the cvs checkup and stuff, let me know. Troy -- __________________________________________________ Troy Dawson dawson@xxxxxxxx (630)840-6468 Fermilab ComputingDivision/OSS CSI Group __________________________________________________
