<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 1) 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.. 2) 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. 3) 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) 1) make a tarball of the current working dovecot executables dir (/usr/local/dovecot) 2) extract the tarball there as before on the testbed machine and everything is fine. 2) 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 at 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 at 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 > 1) 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.. > 2) 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. > 3) 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) > 1) make a tarball of the current working dovecot executables dir > (/usr/local/dovecot) > 2) extract the tarball there as before on the testbed machine and > everything is fine. > 2) 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 at bard.edu voice: 845-758-7475, fax: 845-758-7035 > >
if you run configure --help, you will see this (and more):> Installation directories: > --prefix=PREFIX install architecture-independent files in PREFIX > [/usr/local] > --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX > [PREFIX] > > By default, `make install' will install all the files in > `/usr/local/bin', `/usr/local/lib' etc. You can specify > an installation prefix other than `/usr/local' using `--prefix', > for instance `--prefix=$HOME'. > > For better control, use the options below. > > Fine tuning of the installation directories: > --bindir=DIR user executables [EPREFIX/bin] > --sbindir=DIR system admin executables [EPREFIX/sbin] > --libexecdir=DIR program executables [EPREFIX/libexec] > --datadir=DIR read-only architecture-independent data [PREFIX/share] > --sysconfdir=DIR read-only single-machine data [PREFIX/etc] > --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] > --localstatedir=DIR modifiable single-machine data [PREFIX/var] > --libdir=DIR object code libraries [EPREFIX/lib] > --includedir=DIR C header files [PREFIX/include] > --oldincludedir=DIR C header files for non-gcc [/usr/include] > --infodir=DIR info documentation [PREFIX/info] > --mandir=DIR man documentation [PREFIX/man]I see now I missed something so I will redefine my request. If I invoke configure with: --prefix=/usr/local/dovecot-bld/<timestamp> --eprefix=/usr/local/dovecot-bld/<timestamp> where /usr/local/dovecot-bld/<timestamp> is a directory Q1: Will I have everything in that one directory so that by tar'ing and untar'ing that one directory I can tar up everything necessary to run dovecot on another machine with the same OSlevel/patches/OpenSSL. Will dovecot be able to reference everything it needs? I notice that --oldincludedir=DIR C header files for non-gcc [/usr/include] will not be there. Will that be a problem? Q2: Will dovecot not be able to find system resources it needs? Tar'ing up a directory is doable. RPM'ing hundreds of files scattered here and there, perhaps referenced by others, perhaps with new additions/deletions you don't know about sounds like an heroic task. Does anybody see how simple it is to upgrade UWImap with its one binary? Lior Okman wrote:> Looking at the debianized version, the bulk of the files are placed in > ? > or under /usr/lib/dovecot, with all of the configuration files in > ? > /etc/dovecot, and relevant binaries under /usr/bin and /usr/sbin. > ? > > ? > However, reading from the comment in the begining of the default > ? > dovecot.conf file, you can probably compile your own version of > ? > dovecot where you specify the following parameters to configure: > ? > "--prefix=/usr --sysconfdir=/etc --localstatedir=/var > ? > --with-ssldir=/etc/ssl". > ? > Just make sure to replace all the paths with where you want to install > ? > this version of dovecot. > ? > > ? > Lior > ? > > ? > On 3/7/06, Stewart Dean <sdean at bard.edu> 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. >> > ? > > ? > >> 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 at bard.edu voice: 845-758-7475, fax: 845-758-7035 >> > ? > > ? > > ? >-- ===Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035
On 3/7/06, Stewart Dean <sdean at bard.edu> wrote:> if you run configure --help, you will see this (and more): > > Installation directories: > > --prefix=PREFIX install architecture-independent files in PREFIX > > [/usr/local] > > --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX > > [PREFIX] > > > > By default, `make install' will install all the files in > > `/usr/local/bin', `/usr/local/lib' etc. You can specify > > an installation prefix other than `/usr/local' using `--prefix', > > for instance `--prefix=$HOME'. > > > I see now I missed something so I will redefine my request. If I invoke > configure with: > --prefix=/usr/local/dovecot-bld/<timestamp> > --eprefix=/usr/local/dovecot-bld/<timestamp> > where /usr/local/dovecot-bld/<timestamp> is a directory > Q1: Will I have everything in that one directory so that by tar'ing and > untar'ing that one directory I can tar up everything necessary to run > dovecot on another machine with the same OSlevel/patches/OpenSSL. Will > dovecot be able to reference everything it needs?Assuming all the external shared objects on both systems are in the same place, I don't see why not.> I notice that > > --oldincludedir=DIR C header files for non-gcc [/usr/include] > > will not be there. Will that be a problem?I'm not sure, but I think this setting is used for compile time - it's where dovecot expects to find include files, it doesn't mean that anything will be installed there. If you're really concerned, then use "make -n install", and go over the commands that make would have run, you will be able to see exactly where everything goes. Or you could run "make install" inside a chroot jail. I also seem to recall that I saw a script somewhere that could trace the "make install" procedure and print exactly where it puts everything. It was being used for converting .tar.gz "make-based-installations" to rpms.> Q2: Will dovecot not be able to find system resources it needs?Dovecot should be able to find everything it needs, assuming the configuration files are ok.> Tar'ing up a directory is doable. RPM'ing hundreds of files scattered > here and there, perhaps referenced by others, perhaps with new > additions/deletions you don't know about sounds like an heroic task.Tar`ing a directory is doable, but doesn't lend itself well to reusing components and sane system management. When you use RPM/DPKG for manging your configuration, each package you install is responsible for its own files and nothing more. The packaging system makes sure that nothing conflicts or overwrites existing files. If you accidently untar a file with bad configuration files in it, they will probably overwrite your existing configuration. RPM/DPKG will save your old configuration files. Tar can't help you verify that what you installed is what is actually running. RPM -verify can make sure that no trojan has been installed instead of a file provided in an RPM file. And the list goes on and on.> Does anybody see how simple it is to upgrade UWImap with its one binary?Just as long as there is only one binary. AFAIK, UWImap doesn't support configuration files, on the assumption that the sysadmin probably doesn't know enough to create a valid configuration. The downshot of that is that there is a limit to what you can do with UWImap's one binary :-) Lior> > Lior Okman wrote: > > Looking at the debianized version, the bulk of the files are placed in > > ? > > or under /usr/lib/dovecot, with all of the configuration files in > > ? > > /etc/dovecot, and relevant binaries under /usr/bin and /usr/sbin. > > ? > > > > ? > > However, reading from the comment in the begining of the default > > ? > > dovecot.conf file, you can probably compile your own version of > > ? > > dovecot where you specify the following parameters to configure: > > ? > > "--prefix=/usr --sysconfdir=/etc --localstatedir=/var > > ? > > --with-ssldir=/etc/ssl". > > ? > > Just make sure to replace all the paths with where you want to install > > ? > > this version of dovecot. > > ? > > > > ? > > Lior > > ? > > > > ? > > On 3/7/06, Stewart Dean <sdean at bard.edu> 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. > >> > > ? > > > > ? > > > >> 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 at bard.edu voice: 845-758-7475, fax: 845-758-7035 > >> > > ? > > > > ? > > > > ? > > > > -- > ===> Stewart Dean, Unix System Admin, Henderson Computer Resources > Center of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 > >