[Dovecot] a <blush> build/install question
This is probably an idiot (and certainly so basic as to be non-Dovecot) question, but I have been chasing my tail for a day or so on it, so I will, with humiliation, ask for guidance on it.
Some time back I had asked if dovecot had to have a whole build tree of stuff to run or if any upgrade could be limited to just the executable and some libraries. I was told the latter, and given this list: dovecot (the executable) dovecot.conf libexec/imap libexec/imap-login libexec/dovecot-auth
I had wanted to structure my build and install work so that, when update came out, I could build into a directory that was stamped with the time and version and ssl inclusion status. Every time I built I would create a new directory, and I would be able to everything to fall back with, in the old directories. Being that this is production, I wanted to be able to uplevel (or fall back) quickly. I should say I build on a build machine, since I don't want to have a compiler on the production machines; I specified the stamped unique name of this build directory du jour using the --prefix confiigure parm
The configure, make and make install steps all go fine. Now I have to transfer those five files over to the target production machine, where I had planned to reference these essential DC files, dovecot itself, dovecot.conf, etc through links, like this: (while resident in the build directory which has been NFS imported onto the production target machine)
cp -p ./sbin/dovecot /usr/sbin/$buildver.dovecot ln -sf /usr/sbin/$buildver.dovecot /usr/sbin/dovecot
cp -p ./etc/dovecot-example.conf /etc/dovecot-example.$buildver.conf
cp -p ./libexec/dovecot/imap /usr/libexec/$buildver.imap ln -sf /usr/libexec/$buildver.imap /usr/libexec/imap
cp -p ./libexec/dovecot/imap-login /usr/libexec/$buildver.imap-login ln -sf /usr/libexec/$buildver.imap-login /usr/libexec/imap-login
cp -p ./libexec/dovecot/dovecot-auth /usr/libexec/$buildver.dovecot-auth ln -sf /usr/libexec/$buildver.dovecot-au
Alas, when I actually tried to run dovecot, it was asking for its resource /in the original build tree/ location, which wasn't there. Is there some way I can do what I want?
It seems like I could run the configure without the --prefix parm and have these five files end up in the standard place, but then you would always be building in the same place. I would rather have them in a sheaf of unique build trees so there was never any confusion as to where an edition of them came from...one could always reference back to the unique build tree and do a sum on them.
--
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
Stewart Dean wrote:
Alas, when I actually tried to run dovecot, it was asking for its resource /in the original build tree/ location, which wasn't there. Is there some way I can do what I want?
While I haven't done this specifically with Dovecot, you should be able to manage everything in a simple manner like you want; I currently do this with Exim and Courier-IMAP on the old production server solely with switches to ./configure. Here's how it basically works, maybe it'll help you get dovecot working:
Source: /opt/build/courer-imap-1.2.3
$ ./configure --prefix=/opt/courier-imap-1.2.3 --with-authchangepwdir=${exec_prefix}/libexec/authlib --with-makedatprog=${exec_prefix}/libexec/makedatprog (more and more switches that don't matter for this)
After building, a simple "make install" places everything in /opt/courier-1.2.3. Then there's a symlink like so:
/opt/courier-imap -> /opt/courier-1.2.3
...and finally the /etc/init.d/ script loads the actual courier processes using /opt/courier-imap, not the "standard" /usr based things (so you'll need to customize to fit the default dovecot init.d script).
When I upgrade (or downgrade) it's as simple as running the same scenario on the new code (which means a new make install does not overwrite the old), migrate the config files as needed, stop the old daemon, switch the symlink, then start the new daemon up. Users don't see interruption in their email experience and I'm confident of a backup plan in an emergency.
This has been working great for many years upgrading Courier and Exim on the same machine; rarely do I have to fall back but when it does happen it's been as simple as pie.
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
Thanks, Troy...... but it looks to me like you're compiling on your production machine, no? Which I have decided not to do, since leaving a compiler on them means that people that manage to break in can do nastier things....
Troy Engel wrote:
Stewart Dean wrote:
Alas, when I actually tried to run dovecot, it was asking for its resource /in the original build tree/ location, which wasn't there.
Is there some way I can do what I want?While I haven't done this specifically with Dovecot, you should be able to manage everything in a simple manner like you want; I currently do this with Exim and Courier-IMAP on the old production server solely with switches to ./configure. Here's how it basically works, maybe it'll help you get dovecot working:
Source: /opt/build/courer-imap-1.2.3
$ ./configure --prefix=/opt/courier-imap-1.2.3 --with-authchangepwdir=${exec_prefix}/libexec/authlib --with-makedatprog=${exec_prefix}/libexec/makedatprog (more and more switches that don't matter for this)
After building, a simple "make install" places everything in /opt/courier-1.2.3. Then there's a symlink like so:
/opt/courier-imap -> /opt/courier-1.2.3
...and finally the /etc/init.d/ script loads the actual courier processes using /opt/courier-imap, not the "standard" /usr based things (so you'll need to customize to fit the default dovecot init.d script).
When I upgrade (or downgrade) it's as simple as running the same scenario on the new code (which means a new make install does not overwrite the old), migrate the config files as needed, stop the old daemon, switch the symlink, then start the new daemon up. Users don't see interruption in their email experience and I'm confident of a backup plan in an emergency.
This has been working great for many years upgrading Courier and Exim on the same machine; rarely do I have to fall back but when it does happen it's been as simple as pie.
-te
--
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 2007 Mar 20 (Tue) at 13:04:05 -0400 (-0400), Stewart Dean wrote: :Thanks, Troy...... :but it looks to me like you're compiling on your production machine, :no? Which I have decided not to do, since leaving a compiler on them :means that people that manage to break in can do nastier things....
Because its so difficult to install a compiler? Or even to install your own binaries? This "defense" does not actually gain you anything, but makes it harder for you to defend against attacks.
-- "I'd love to go out with you, but my favorite commercial is on TV."
On Tue, 2007-03-20 at 13:04 -0400, Stewart Dean wrote:
but it looks to me like you're compiling on your production machine, no? Which I have decided not to do, since leaving a compiler on them means that people that manage to break in can do nastier things....
I didn't read your original mail completely, but it's also possible to do something like this:
./configure --prefix=/opt/dovecot-<version> make make DESTDIR=/tmp/dovecot install cd /tmp/dovecot tar cf dovecot.tar dovecot*
Then untar it in production machine's /
Thanks Timo, that should do it. As always, (as us boorish Americans might say), you da man! Your patience and help are always the best.
Timo Sirainen wrote:
On Tue, 2007-03-20 at 13:04 -0400, Stewart Dean wrote:
but it looks to me like you're compiling on your production machine, no? Which I have decided not to do, since leaving a compiler on them means that people that manage to break in can do nastier things....
I didn't read your original mail completely, but it's also possible to do something like this:
./configure --prefix=/opt/dovecot-<version> make make DESTDIR=/tmp/dovecot install cd /tmp/dovecot tar cf dovecot.tar dovecot*
Then untar it in production machine's /
--
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
Stewart Dean wrote:
Thanks Timo, that should do it. As always, (as us boorish Americans might say), you da man! Your patience and help are always the best.
BTW: my instructions work just the same -- compile on a dev machine, tar and untar on a production machine. It doesn't matter where you compile as long as the OSes are compatible (glibc, etc.). What matters is developing a logical symlink infrastructure to accomplish your needs.
I kind of thought that would have been obvious, sorry.
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
On Tuesday March 20, 2007 at 01:04:05 (PM) Stewart Dean wrote:
Thanks, Troy...... but it looks to me like you're compiling on your production machine, no? Which I have decided not to do, since leaving a compiler on them means that people that manage to break in can do nastier things....
If you have unauthorized users on your system, then you have a lot more to worry about than a compiler laying around.
-- Gerard
"Friends come and go but enemies accumulate."
Anonymous
participants (5)
-
Gerard
-
Peter Hessler
-
Stewart Dean
-
Timo Sirainen
-
Troy Engel