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 different. > 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, though. > > 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 direction. 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 behavior. 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 -- Michael D. Stenner mstenner@xxxxxxxxxxxxxxx ECE Department, the University of Arizona 520-626-1619 1230 E. Speedway Blvd., Tucson, AZ 85721-0104 ECE 524G
