|Sam Varshavchik||Sep 20, 2004 6:32 pm|
|Jim Horner||Sep 20, 2004 8:02 pm|
|Arturo "Buanzo" Busleiman||Sep 20, 2004 8:07 pm|
|Mitch (WebCob)||Sep 20, 2004 11:20 pm|
|Scott Sharkey||Sep 21, 2004 6:22 am|
|MikeM||Sep 21, 2004 7:59 am|
|Randy Smith||Sep 21, 2004 9:50 am|
|Alexei Batyr'||Sep 21, 2004 11:14 am|
|Alessandro Vesely||Sep 21, 2004 6:15 pm|
|Sam Varshavchik||Sep 21, 2004 7:07 pm|
|Sam Varshavchik||Sep 22, 2004 3:41 pm|
|Michael Carmack||Sep 22, 2004 6:34 pm|
|Johannes Erdfelt||Sep 22, 2004 8:46 pm|
|Stefan Hornburg||Sep 23, 2004 1:20 am|
|Alessandro Vesely||Sep 23, 2004 8:11 am|
|Subject:||[courier-users] Planned changes to Courier's authentication library.|
|From:||Sam Varshavchik (mrs...@courier-mta.com)|
|Date:||Sep 20, 2004 6:32:01 pm|
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.