Steve Holdoway wrote:
> I think that you're falling into the all too common trap that sysadmin > work is really tedious, so the top priority is to use the solution that > takes the minimum time to implement, regardless of it's inherent quality. > I reckon that package management is *NOT* the solution for a production > server. I would modify what you've said only in that, internally generated packages are good time savers and consistency builders for a sysadmin. But, by that, I mean "you build the software from source, and then build the pkg/rpm yourself, and distribute the package to yourservers yourself". That means you put into production the same package, built exactly the way you need it, built exactly the way you built on your dev machines, and tested on your test machines. But, for a professional sysadmin, dealing with mission critical servers, blindly depending upon other people's packages isn't such a great idea. > Obviously this is just my opinion, and I know it's not that popular - > but it's the distillation of what I have learnt the hard way over more > than 23 years ( just checked my CV! ) of relevant experience. Yeah, one of the worst aspects of the open source community at large is "upgrade upgrade upgrade upgrade". "Just because you can, and it's free, you should". "upgrade early, and upgrade often". A good sysadmin knows that that's the path of fools. Introduce new versions into your dev environment. Make sure it functions the way you want, does what you want, etc. Then package it up and install it on your test machines. Let your test machines run with it for a good solid long time (weeks). Enough to _prove_ it does what you want/need it to when under load, etc.. Then you have to wait for a window when you can make a change to your production service environment without it undermining your service. For me, that window happens at the end of each academic quarter (after finals, after grades are due the following Tuesday, THEN I can make changes). So, if a new version of software comes out in September, I wont be deploying it until December. Chances are, if a new version comes out in late November or early December, I wont put it into production until late March (spring break) ... because late November isn't enough time for me to put it through its paces and deploy it in mid/late December. (as a non-strict rule of thumb, I would estimate that for me to deploy in December, it would have to be released no later than October) So, I see people who upgrade production mission critical systems to new versions of a software package within 2 days as just being quite a bit insane and reckless. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
