On Fri, 2005-09-09 at 00:30 -0400, David Johnston wrote:
> Les,
> I think this discussion has gotten lost in the weeds. What you want to
> do is easy to accomplish using Yum, but you have to use Yum the way it
> was intended to be used. First, you must have your own repository
> server, which will host as many repositories as your change control
> policies require (eg, untested, test, qa, production). Using the Centos
> repositories directly means that you're rolling out on Centos' change-
> control schedule, not yours. Set up your own repository and you can
> control it.
>
>
> The rest of this message is just a summary of things that others on this
> list have already said.
>
> 1. You need your own repository server. This machine needs good
> Internet connectivity, Apache, and about 100GB of disk space.
>
> 2. On your repository server, you need to host three repositories.
> #1 is a copy of the Centos repositories you use, call it "untested"
> #2 is a subset of #1, call it "qa"
> #3 is a subset of #2, call it "production"
>
> 3. #1 gets updated nightly with a simple yum update. In other words, it
> just copies the binary packages from the Centos repositories.
>
> 4. Keep in mind that #2 and #3 won't take up much disk space because the
> files in these repositories are actually just links to the real files in
> #1.
>
> 5. "createrepo" will create the Yum headers for all of the packages in a
> given directory.
>
> 6. If you want to promote a set of packages from #1 to #2, you first add
> links
> (eg, "ln -s /var/spool/repo/untested/somepkg.rpm /var/spool/repo/qa/").
> As you do this, any machine attempting to run "yum update" against the
> qa repository will see no change.
>
> 7. Here's where the repo gets its atomicity: once all of the packages
> are linked, you re-run createrepo. Until createrepo finishes, the repo
> will appear unchanged.
>
> 8. All of your QA machines use your "qa" repository, and run yum update
> nightly.
>
> 9. All of your production machines use your "production" repository and
> run yum update nightly.
>
> 10. YOU control when createrepo is run on your QA and Production
> repositories, thus controlling when things roll out.
>
I agree with most of this ... except that I would (and do) use rsync to
do updates of the repo from the CentOS trees.
You can make rsync only pull down the directories you need (ie, nothing
but centos-3 i386 and x86_64 if that is what you care about, etc.)
Understand that CentOS already has more "repos" than just about anyone
else out there already (contrib, extras, centosplus, addons, testing,
updates, os). We do this to give the users almost unprecedented control
on what they want to take.
The bottom line is ... if you want to QA control your own updates, and
not rely on CentOS (or the upstream provider) to maintain an up2date and
secure set of packages, then you need to do it yourself.
This is not a unique requirement ... I am a CentOS developer, and I
personally QA almost every single package that gets released from the
main CentOS-4 repos for i386 and x86_64. I still maintain a separate,
local repo at my work that has tested and QA'ed packages required for my
production machines to maintain configuration management. Not because I
don't trust the updates ... but because I need a specific set of
packages for specific requirements.
Having a configuration date/time feature in yum ... whereby anything
after a specific point in time would not be considered in the resolution
process might be a good thing (from the standpoint of configuration
management). But that would not really do anything to verify that
certain packages were stable, nor would it give you the flexibility to
take certain packages newer than that date which you want while testing
others.
You can use tools (like RHN) to register machines and pick certain
updates to push across those machines ... but to be honest, I create
local yum repos even for upstream supported machines too. I then point
to those repos and use up2date to control my supported machines updates.
There is an open source project called "current" that is an open-source
implementation of an up2date server. It might do some of the things you
want. I haven't really looked at this in depth, but here is a link:
http://current.tigris.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20050909/290e1fa6/attachment.bin
