<permit me my perhaps foolish preference...an explanation> I run mail service for a small college. I've long joked that if someone stole the mail server, the phone would ring before the alarm (which has a 1 minute delay) did, that the user base expected 25x8x367 coverage. Making updates/upgrades to the mail server feels like a tightrope walk with no net. I always appreciated UofWIMAP because there is one binary. Doing and upgrade or backing it out is simplicity itself. I could compile the single binary on my compile machine, test the same binary on my testbed, and then drop it in my production machine and it would work with a minimum of surprises. So portable, so predictable, no security risk of a compiler on a production machine. Of course, /most/ of open source software has all these bits and pieces scattered everywhere. Oh, it may install initially just dandy, but come the day when It's Time For The Upgrade.... 1) can I do it quick and clean and 2) can I recover to what I had before quickly and correctly if the upgrade flops??????
Alas, Dovecot is sprinkled in many, many pieces...but at least, I think (right?) that they are all in the prefix-dir. Gulp. So. I am hoping I can do this: Build/Test Install
- build/install in /usr/local/dovecot_bld/ Build### in the expectation that everything will be stuck down there. I don't want to put it into /usr/local/ because it will be in there with everything else....no way to get just the dovecot stuff..
- tar up the contents of my prefix directory and extract it over on my testbed under /usr/local/dovecot. Notice that the path to dovecot's "stuff" has changed from /usr/local/dovecot_bld/ Build### to /usr/local/dovecot I'm hoping that this won't be a problem. I will point the line in inetd at it and Everything Will Work.
- Assuming I don't change anything and everything tests out (flawlessly!), I.............
Introduction to Production (assuming that all the mailboxes, homedirs and the like have been sorted out)
- make a tarball of the current working dovecot executables dir (/usr/local/dovecot)
- extract the tarball there as before on the testbed machine and everything is fine.
- if the update flops, I can bring back the tarball of the previous Dovecot incarnation
My Questions: A) Will this work or are there dependencies I'm not aware of? B) Is there Some Better Way or.....
I have this ongoing <ahem> discussion with the Open Source wonks that delight in many, many modules, libraries, etc. I /know/ the reasons a developer would want to do things that way, but, for those of use fielding the application, it's /so/ much easier and success/failure recovery is /so/ much more likely if....there are only one or two or three chunks that we can drop in or quickly back out. I realize that the developer is coding in large part for the utter joy of creating a wondrous, living, breathing edifice of code, that works, that works cleanly, that works as none has before. Yes. But I would think (IMHO) that the developer would receive a greater portion of the ego rush (also a big part of the developer stimulus) of overwhelming application acceptance (and thunderous applause), if he or she made it easy to support and upgrade! You see a sysadmin is so often an utter coward (I confess), who doesn't like unpleasant surprises, whose managment Really Doesn't Like Unpleasant Surprises. When I do my job really well, nobody knows I've done anything.
OK...let me have it.
--
Stewart Dean, Unix System Admin, Henderson Computer Resources
Center of Bard College, Annandale-on-Hudson, New York 12504
sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035