I am 100% for this! I've been trying to do something similar (separate out the authdaemon from the rest for some time, precisely so I don't have two sets of identical code running when combining sqwebmail and courier-imap. And I don't think it's a "small minority" of people running this combination -- almost everyone I know using postfix uses courier-imap and sqwebmail...
-Scott On Mon, 2004-09-20 at 21:29, Sam Varshavchik wrote: > I'm planning to make the following structural changes. This is the only > chance for someone to talk me out of it. > > Right now, the authentication library, the authlib subdirectory, is present > in the courier, courier-imap, and sqwebmail source tarballs. It gets > separately compiled by all three packages. The authlib subdirectory > contains code to verify login ids and passwords using the configured > authentication module - be it system accounts, or virtual accounts using the > userdb, MySQL, PostgreSQL, or LDAP authentication module. > > I'm planning on spinning off the entire authentication library into a > separate, standalone package. The new build procedure will be, as follows: > > 1. Download, compile, and install the courier-authlib tarball. > 2. Configure the authentication library. Use the diagnostic tools > (authinfo, authtest) to verify that everything is working correctly. > 3. Download Courier, Courier-IMAP, and SqWebMail, and proceed to install > the package in the usual fashion. > > I believe that the new approach offers the following benefits: > > â Smaller Courier, Courier-IMAP, and SqWebMail packages, going on forwards. > > â Consolidated documentation. Instructions for setting up MySQL, > PostgreSQL, and the rest, are currently duplicated twice, making it a > maintenance pain. After consolidation documentation can be easily improved, > and overhauled. There will be an initial hump to ride over, to reconcile > the minor differences in the authentication documentation in Courier, > Courier-IMAP, and SqWebMail. Going forward, though, everything will be in > one place. > > â The authentication API appears to be fairly stable and robust. It will > not be necessary to update the courier-authlib package with every upgrade. > Updates to courier-authlib are expected to be very rare. > > â There is a small minority of established systems that use the standalone > SqWebMail and Courier-IMAP packages. The consolidated courier-authlib > library will, as a bonus, provide an official way to use only one set of > config files, in this configuration. > > I can only see one possible drawback. Only the daemonized configuration will > now be possible. The non-daemonized version of the authentication library > will be removed. It is clear that the daemonized configuration is proven to > be more flexible, and is the only way to go. The daemonized configuration > has been the default configuration for several years. > > I can only see the following minuses from losing the non-daemonized > configuration. I believe the minuses are greatly outranked by the pluses. > > â There are some third party configuration libraries that only work in a > non-daemonized configuration. I'm aware of one such library, vmailmgr. > Unless it's been updated to work in daemonized mode, it will no longer work. > > â There are also some other third-party hacks that also only work in a > non-daemonized configuration. There's at least one relay-after-imap or > relay-after-pop hack for qmail, that only works in a daemonized > configuration. I believe that relay-after-X hacks have been obsolete for > several years now. Every mail client worth mentioning these days > implemented authenticated SMTP, and the relay-after-X hacks need to go. > > â Currently, there are also some borderline configurations possible in a > non-daemonized configuration, such as using different authentication modules > completely for imap and pop3, or different authentication modules for > non-encrypted and encrypted connections. This will no longer be possible, > but I doubt that there's any valid reason to use such a strange setup. > > Overview of the planned courier-authlib package: > > 1. Uses the existing configure options. > 2. Uses standard FHS install paths. > 3. Installs: > A) Various authdaemond builds, and the authdaemond startup script > B) Configuration files > C) Test binaries > D) A small devel library that contains the authdaemon client code. > Courier, Courier-IMAP, and SqWebMail will link against this lib. > E) A migration script > > The migration script will look for any existing configuration files in any > known directory used by older versions of Courier and SqWebMail. Presently > I know of the following directories that could possibly hold old > configuration files, on known platforms: > > /etc/courier > /usr/lib/courier/etc > /usr/lib/courier-imap/etc > /usr/local/etc/courier > /usr/local/lib/courier/etc > /usr/local/lib/courier-imap/etc > /usr/local/share/sqwebmail > > If there are some existing ports of Courier that dump the configuration > files somewhere else, I need to know. > > The migration script searches this directory list, looking for configuration > files, and installs them in the new courier-authlib configuration directory, > unless courier-authlib's directory already contains working configuration > files. > > 4. A new make target, 'make upgrade', runs the migration script. > Therefore, the process for installing courier-authlib will be: > > configure > make > make install > make upgrade > make install-configure > > make install-configure, as always, runs sysconftool to build configuration > files from their templates. 'make upgrade' must be executed before 'make > install-configure', because 'make install-configure' installs default > configuration files, and 'make upgrade' will not pull old configuration > files if courier-authlib's configuration directory already has configuration > files installed. > > The migration script is a separate script, and is not a part of the > Makefile, so that the migration script can be executed by Courier ports, as > part of the upgrade process (followed by sysconftool). I believe that the > upgrade process will be trouble-free. > > > ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
