RPJD said: > but (and i'm guessing here) i would think that the majority > of folks who > are introduced to yum for the first time are going to want to know, > quickly and concisely, how to run it as a *client*. (from > what i've seen > in the survey results, the majority of people on this list can be > considered fairly "elite" in that many of them have set up their own > repositories. but that doesn't fairly represent the beginners.) I sent my survey privately to Seth (before I saw the flood of public responses) so I'll rehash a little bit of what we're doing at TruePosition. We're a very rapidly growing company with a very small MIS department. The use of Linux has been exploding here. Since we're entirely self supporting, and RH's up2date model doesn't allow for a reasonably priced site proxy for up2date and RHN, I started looking at alternatives. Also, even with close to 1,000 users at peak times, we get by with a very small pipe to the Internet. Having hundreds of machines running up2date against RH's servers would be unacceptable. Some of the TriLUG folks were speaking highly of yum, so I gave it a look. While we all know that the documentation is having a hard time catching up with the brisk pace of development, I was able to piece together what I was after with the help of Google and the online list archives. Now I have an apache server in-house that is carrying three Yum repositories (mirrors of base & updates from ftp.redhat.com plus custom packages for TP). As we assimilate systems one by one into the MIS collective, we're having them hit the in house yum repository once a day for updates. I'm also using Yum during the RH install process, via a Kickstart post-install script. This way a system goes out of my office already patched and already loaded with our custom RPM's. Between Kickstart & Yum it takes me from 5-10 minutes of actual work to set up a new Linux machine. I'm anticipating cutting that figure in half when I'm done setting up my yum groups, and will cut it down in half again when I have a PHP script generating my kickstart config file to set up the host-specific bits. That said, my interest from the beginning was in hosting a local repository, and using the repository to automate a lot of my daily work. I'm very happy with what has been accomplished so far, and once I settle on a group configuration and get some more of our custom bits packaged in RPM's I anticipate I'll have a lot more (needed) time to maintain the less automated Windows environment. What order should it be addressed in when it's doc'd? Frankly I don't care, as long as it gets doc'd. :-) --Magnus
