[Dovecot] Can I install in the following fashion?
<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
The problem you are describing is solved with tools like RPM and DEB.
You can install/remove an entire package with a single command, you can verify the installation with a single command, you can safetly upgrade with a single command, and safetly revert to an older version with a single command.
These tools allow you to find out exactly which file belongs to what package, and they prevent conflicting files from two different packages from being installed. Not to mention (almost) automatic (at least on debian) dependency resolving for packages.
If you're using Debian, you can just "apt-get install dovecot-imap dovecot-pop", and have the dpkg handle all of the issues you mentioned. If you're using an RPM based distro- try yum or apt-rpm.
Lior
On 3/6/06, Stewart Dean sdean@bard.edu wrote:
<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
If you're using Debian, you can just "apt-get install dovecot-imap dovecot-pop", and have the dpkg handle all of the issues you mentioned. If you're using an RPM based distro- try yum or apt-rpm.
And there is nothing stopping you making a deb package, from a newer version of dovecot, that Debian has, AND, duplicating the server, so you can do a test upgrade... Of course, with any upgrade, someone will notice something ;-)
Tim
Linux Counter user #273956
Hmmm, hadn't thought of RPM. But I would like a direct answer to my question, which was: Can I just tar up everything in a dovecot-only prefix directory (defined in the invocation of configure) when the make and make install is done, and then untar/extract it in a directory of the same name over on another machine with the same OS, patches and OpenSSL? Are there Dovecot dependencies outside prefix directory.
My OS is AIXV5.3 maintenance/tech level 4. There is no distro RPMs for same, so I am building it myself.
Lior wrote:
The problem you are describing is solved with tools like RPM and DEB.
You can install/remove an entire package with a single command, you can verify the installation with a single command, you can safetly upgrade with a single command, and safetly revert to an older version with a single command.
These tools allow you to find out exactly which file belongs to what package, and they prevent conflicting files from two different packages from being installed. Not to mention (almost) automatic (at least on debian) dependency resolving for packages.
If you're using Debian, you can just "apt-get install dovecot-imap dovecot-pop", and have the dpkg handle all of the issues you mentioned. If you're using an RPM based distro- try yum or apt-rpm.
Lior
Timothy White wrote:
If you're using Debian, you can just "apt-get install dovecot-imap dovecot-pop", and have the dpkg handle all of the issues you mentioned. If you're using an RPM based distro- try yum or apt-rpm.
And there is nothing stopping you making a deb package, from a newer version of dovecot, that Debian has, AND, duplicating the server, so you can do a test upgrade... Of course, with any upgrade, someone will notice something ;-)
Tim
Linux Counter user #273956
--
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
I believe so. I routinely just copy the imap, imap-login (and optionally pop3, pop3-login) dovecot-auth and dovecot binaries (all but the last in the libexec directory, the last in the sbin directory) and dovecot.conf (in the etc directory).
You'll also need ssl_build_param (hardcoded to be in the libexec directory, I think, all the other paths can be specified in the conf file) if you use SSL/TLS.
Dovecot is probably better run as a standalone daemon rather than under inetd (the latter has been broken in the past, but I think I remember seeing somewhere that it has been fixed in the latest betas).
Best Wishes, Chris
Stewart Dean wrote:
Hmmm, hadn't thought of RPM. But I would like a direct answer to my question, which was: Can I just tar up everything in a dovecot-only prefix directory (defined in the invocation of configure) when the make and make install is done, and then untar/extract it in a directory of the same name over on another machine with the same OS, patches and OpenSSL? Are there Dovecot dependencies outside prefix directory.
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
I think this is more of what I'd prefer (moving a few executables, vs. trying to bring everything over from the original build environment...which I was only doing because I assumed that....if make install installed it, most of it must be necessary). But some questions:
- will dovecot look for dovecot.conf always in /etc? That is, if I run configure with:
--eprefix=/usr/local/dovecot-bld/<timestamp> --prefix=/usr/local/dovecot-bld/<timestamp>
will the executables look to
/usr/local/dovecot-bld/<timestamp>/etc/dovecot.conf
or to /etc/dovecot.conf?
Similarly, will ssl_build_param refer to the IBM OPenSSL idiosyncratic locations passed through CPPFLAGS and LDFLAGS or will it have dovecot looking for stuff in /usr/local/dovecot-bld/<timestamp>
Is the location and packaging of dovecot pretty much stable at this point? By this I mean, will the things I have to update as Dovecot updates pretty much be constrained to just the files you mentioned?
My thanks for everyone's patience and help.... S.
Chris Wakelin wrote:
I believe so. I routinely just copy the imap, imap-login (and optionally pop3, pop3-login) dovecot-auth and dovecot binaries (all but the last in the libexec directory, the last in the sbin directory) and dovecot.conf (in the etc directory).
You'll also need ssl_build_param (hardcoded to be in the libexec directory, I think, all the other paths can be specified in the conf file) if you use SSL/TLS.
Dovecot is probably better run as a standalone daemon rather than under inetd (the latter has been broken in the past, but I think I remember seeing somewhere that it has been fixed in the latest betas).
Best Wishes, Chris
Stewart Dean wrote:
Hmmm, hadn't thought of RPM. But I would like a direct answer to my question, which was: Can I just tar up everything in a dovecot-only prefix directory (defined in the invocation of configure) when the make and make install is done, and then untar/extract it in a directory of the same name over on another machine with the same OS, patches and OpenSSL? Are there Dovecot dependencies outside prefix directory.
--
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
On Mar 7, 2006, at 8:55 PM, Stewart Dean wrote:
I think this is more of what I'd prefer (moving a few executables,
vs. trying to bring everything over from the original build
environment...which I was only doing because I assumed that....if
make install installed it, most of it must be necessary). But some
questions:
- will dovecot look for dovecot.conf always in /etc? That is, if
I run configure with:--eprefix=/usr/local/dovecot-bld/<timestamp> --prefix=/usr/local/dovecot-bld/<timestamp>
I guess --eprefix means --exec-prefix? In any case that's not needed,
it defaults to --prefix.
will the executables look to
/usr/local/dovecot-bld/<timestamp>/etc/dovecot.conf
Yes.
- Similarly, will ssl_build_param refer to the IBM OPenSSL
idiosyncratic locations passed through CPPFLAGS and LDFLAGS or will
it have dovecot looking for stuff in /usr/local/dovecot-bld/ <timestamp>
CPPFLAGs and LDFLAGS shouldn't affect anything at runtime (except
maybe -R parameter with some linkers to specify library lookup paths).
- Is the location and packaging of dovecot pretty much stable at
this point? By this I mean, will the things I have to update as
Dovecot updates pretty much be constrained to just the files you
mentioned?
Dovecot 2.0 has some new binaries, but before that nothing should
really change.
On Monday 06 March 2006 21:27, Lior Okman wrote:
The problem you are describing is solved with tools like RPM and DEB.
Or if you're using Gentoo, you can compile it on your test machine, then generate a binary package with emerge --quickpkg and install that on the new one, making a binary package there first as a backup.
Cheers,
Casey Allen Shobe | cshobe@seattleserver.com | 206-381-2800 SeattleServer.com, Inc. | http://www.seattleserver.com
participants (6)
-
Casey Allen Shobe
-
Chris Wakelin
-
Lior Okman
-
Stewart Dean
-
Timo Sirainen
-
Timothy White