Home | Comics | Gallery | (Amazon| ThinkGeek) wishlist | Donations | Impressum | The Book of Postfix | Postfix - Einrichtung, Betrieb und Wartung | Blog
Here you find Victor Duchovni's patches and other files for Postfix. All these patches come without a warranty, so use them in your own risk. They apply cleanly to the postfix version they were made against.
If you don't know how to patch the source, then you probably shouldn't be doing this :)
Victor can be reached at Victor dot Duchovni at morganstanley dot com
The files below are the compressed histories for all changes since 1.0 with each log entry annotated by the release or snapshot that introduced the change.
These may be useful for folks who want to ask When did Postfix first...?" (as long as the feature postdates version 1.0).
Enclosed are Victor's annotations to each patch:
The "barecr" patch has not been adopted, and perhaps never will be. I think Wietse is interested in a more general character sanitizer for "cleanup" that would be more configurable (other control chars and a settable replacement char). I have not implemented such a general feature, but still consider the barecr hack worthwhile at least for my own private use.
The new "install" (really multi-instance support) patch combines the functionality of the old "install" and "start" patches. In addition to the old multi-instance install/upgrade/start/stop support it moves the sample tables from the configuration directory to the sample directory, so these are updated with every install and don't need to be replicated into each instance's configuration directory.
This is a summary of the changes. For details see the new post-install(1) manpage and the updated postfix(1) manpage.
- The "post-install" script has been replaced (OK encapsulated) by the "post-install" sub-command of the postfix(1) command. This abstracts away the script location, and makes it unnecessary to tell the script where the command_directory is, when it is not on the user's path.
- The postfix(1) man page has been expanded to document the new "stop-instance", "start-instance", "enable", "disable" and "post-install" sub-commands. The multi-instance behaviour of "start" and "stop" have been documented.
- The new post-install(1) manpage documents how to create and upgrade multiple Postix instances.
- When creating instances, or after installing the stock "disabled" main.cf, a warning is issued alerting the administrator to the need to run "postfix enable" after editing main.cf.
- The "readme_directory" is no longer optional, README files are always installed. By default in /etc/postfix/readme.
- The "sample_directory" now defaults to /etc/postfix/sample (previously /etc/postfix). Sample files may not be placed in the configuration directory, since the sample maps might overwrite site-specific data.
- The "postfix-files", "postfix-script" and "post-install" files have been moved from /etc/postfix into $daemon_directory. This reduces the clutter in the configuration directory and avoids the need to duplicate these files into each Postfix instance.
- The symlink code in postfix-install now generates the minimal number of "../" prefixes, avoiding a complete traversal to the root directory. This fixes potential problems with AFS installations, where one installs file into writable shadows of read-only volumes, and the symbolic links should not record the full path of the writable volume.
- The main.cf and master.cf files included in the source distribution are no longer lost when upgrading. They are saved in the sample directory as sample-main.cf and sample-master.cf. These are used to create new instances, and also when doing a first install.
- The new "enabled" configuration parameter (boolean yes/no) controlls whether "postfix start" actually starts the mail system. This parameter is explicitly set to "no" in the stock main.cf file, but defaults to "yes", so that existing main.cf are automatically enabled. *ONLY NEW* unedited main.cf files are disabled. This prevents accidents when a newly built and unconfigured system is booted, and might accidentally start processing email with an incorrect configuration. The "postfix enable" command enables an instance. The "postfix disable" command disables it.
- The "post-install" command now allows (and encourages) the setting of the syslog_name configuration parameter. This allows one to distinguish output from distinct Postfix instances the mail log.
- The set-permissions code in "post-install" no longer attempts to update files whose permissions don't need changing. This works in AFS environments where the binaries are typically in shared read-only storage.
- The postfix(1) "start" and "stop sub-commands now stop or start all enabled instances listed in the "alternate_config_directories" of the default Postfix instance. If the default instance is disabled, no instances are started or stopped. The "start-instance" and "stop-instance" commands are available for starting and stopping a single Postfix instance. With this change "/usr/lib/sendmail -bd" starts all Postfix instances, one may not need to change the system start scripts to start a multi-instance Postfix installation.
That's it! Enjoy. I am hoping that the cleaner integration and more complete documentation finally move this patch closer to being adopted...
The "map_config" patch which allows compile-time control over the available maps and default map type has been improved to work correctly on systems where aliases default to "netinfo:/aliases" and to suppress compiler warnings on systems with native Berkeley DB support.
The multi_server_lifetime patch is new (early snapshots are in the list archive). This implements lifetime management for the trivial-rewrite and proxymap daemons. After serving a configurable number of requests the *oldest* instance of each daemon stops accepting new connections and exits once all connections close. Only one non-listening daemon can exist at any one time (and only if the process limit != 1) so it is not possible for all available daemons to be refusing new connections at the same time. This patch ensures that "trivial-rewrite" and "proxymap" don't run forever on busy systems, thereby avoiding any problems due to potential memory leaks in system or optional database (mysql, ldap, pgsql, ...) libraries.
This file was last modified 25. Apr 2007 by root