[Yum] Re: mirror maintenance

Michael Stenner mstenner at ece.arizona.edu
Tue Sep 7 23:32:13 UTC 2004

On Tue, Sep 07, 2004 at 03:39:43PM -0700, Rick Graves wrote:
> The chance that there will be a show-stopping glitch
> in a security patch is extrememly small.  But this is
> still too big a risk for live servers in some
> contexts.  

Yes.  I really do understand this point.  I promise :)

> I did not think that a new box being completely up to
> date was a huge problem.  As I understand it, the
> concern is that a glitch in an update will bring down
> a live server.  You are not taking this risk with a
> new install.  After all, it is a new install, and if a
> glitch stops it from running, you can troubleshoot the
> problem before you go live.  

I think the idea of having your boxes running different versions of
the same software gets confusing and awkward.  It's not so much the
absolute version on any given box, but the fact that they may be

> I have never maintained a mirror.

It's trivial.  Of course, the "smart mirror" that I'm proposing would
require some code, but not nearly as much as what you're proposing for
yum to handle internally.

> > What I'm proposing solves the same problem, but
> > doesn't introduce these NEW problems.  Maintain a
> > mirror that only folds in new packages after they've
> > been available for N days.  
> How do you implement folding in new packages after N
> days?  Do you manually track every new package that
> comes out?

No.  A program would have to be written to maintain this mirror.  Code
would have to be written in either case.

> It seems to me the YUM option that I am proposing would help you
> maintain your mirror with a lot less manual, tedious stuff.

Maintaining a mirror is currently far outside yum's domain.  The
mirror code would likely use some of the yum code to analyze packages,

> > You're talking like yours is the only possible solution.  
> I disagree with you on that.
> For the sake of analysis, let's agree that maintaining
> your own mirror is the ultimate solution.  However, it
> requires more hardware, and a lot more time and
> effort, than the solution to the security patch
> problem that I have proposed.  

I don't really buy the time and effort argument.  Maintaining a mirror
is SO easy, and one like I'm describing would still be simple to
maintain.  As far as hardware is concerned, the FC2 updates directory
is currently < 1 GB for i386.  If you can't find a machine laying
around with 1 GB on it, there's a serious problem.

Furthermore, there's no reason that every admin would have to do this
themselves.  If a few people do it and make their mirrors public, then
everybody gets the benefit.

> The reality out there is that some administrators deal with the
> security patch problem by never applying them.  (Try telling them
> they must maintain their own mirror!)  I believe the solution that I
> have proposed would be a best compromise for many administrators.

If they choose to never apply security patches because they won't risk
a bad package in the updates directory, we're no longer talking about
competent administrators, and the whole conversation turned in a new

Here's the thing.  Maintaining a stable and secure computing
environment requires resources: time and hardware.  If admins are not
willing to put in either, then they're adding a fifth lock to the
front door while the back door is sitting wide open.  I think it's a
bad idea to add nasty confusing code to yum simply to enable this

I haven't talked with Seth about this yet, but I'm pretty confident
your proposal isn't going to get into yum for the reasons I've just
described.  It's already hard enough to manage dependancies over
multiple repos.  Throwing in intentional delays on the client,
possibly with a secondary database (the rpmdb being the primary), just
makes things even more nuts.

I recognize the desire to not apply changes immediately.  I even agree
that there are situations where that's appropriate.  I just don't
think it should be (or will be) done in the way you describe.

  Michael D. Stenner                            mstenner at ece.arizona.edu
  ECE Department, the University of Arizona                 520-626-1619
  1230 E. Speedway Blvd., Tucson, AZ 85721-0104                 ECE 524G

More information about the Yum mailing list