On 05/01/2026 11:47, Wietse Venema via Postfix-users wrote:
The removal of Berkeley DB from Linux systems will affect a large
number of Postfix installations. Some (smaller) Linux distributions
have already removed Berkeley DB support, and RedHat will remove
it in Enterprise Linux version 10.
*Has* removed it, RHEL10 has been out for nearly a year now. That said,
BDB has been piocked up by the EPEL repository for EL10 so it is
available on that platform, but the stock postfix for EL10 does not have
BDB support compiled in. I should mention that the GhettoForge packages
do have BDB support enabled for postfix in EL10 so that is an option for
those who want it.
The goal: a Postfix configuration that uses 'hash' or 'btree' can
be migrated to a configuration that does not use Berkeley DB support.
This would require automatic transformation of configuration files
(and automatic database re-indexing), or emulation where a request
for an obsolete database type is automatically serviced with a
supported type.
I have considered, and rejected, automatic transformation of
configuration files. The problem is that database types (such as
hash or btree) and database pathnames may be the result of $name
expansion; to do a proper job one has to parse configuration files
like Postfix programs do, replace each legacy database type, unparse
the result, and then write an updated setting back to a Postfix
configuration file.
I agree that Postfix should not do this itself or automatically, but it
wouldn't be a bad idea to include a separate helper script that parses
and translates db types in the various Postfix configuration files for
you, with the appropriate caveat that it's really up to the admin to
verify that the resulting config files are valid and what they really want.
That leaves an implementation based on emulation; I opted for a
variant with on-demand database re-indexing in the background. This
does not require that configuration files are updated, though making
such updates would save a few CPU cycles later.
The basic idea:
<snip>
What about allowing db type aliases? We already have dynamic map
support and it likely wouldn't be a huge stretch to add functionality to
that which can alias db type names to other types probably with a bit of
syntax right in the dynamicmaps.cf file (or one of the files in the
dynamicmaps.cf.d directory) itself.
Nitty-gritty details:
- This does not re-index cache files (verify, postscreen) because
there is no table source file. One would need Berkeley DB support
to list the entries in the obsolete file, and that is not possible
on systems without Berkeley DB support. But it might be feasible
if the migration is done on a system that still supports Berkeley
DB.
Just to re-iterate it is possible to have BDB support in EL10 by simply
installing the appropriate package from the EPEL repository, this does
not, however, magically add the support to Postfix when the stock
postfix packages were not compiled with it to begin with.
- The helper service will run 'postalias' if a database matches
$alias_maps or $alias_database,
I would think it should only check $alias_database since it's possible
to have tables listed in $alias_maps that aren't in $alias_database and
those tables would use 'postmap' to create the db file, not 'postalias'.
This should require very little new code; if we do not count the
boilerplater code, likely less than the size of this message. It
will definitely be in Postfix 3.11. If people think this will be
useful, then I will consider back porting.
Just a bit more to consider before going down this rabbit hole, while I
can't speak for other distros I do know a bit about how RHEL and
RHEL-derived distributions work in this regard. Red Hat opted not to
include BDB support in their latest major release, it was not, nor is it
very likely to be, removed from older releases so RHEL 8 will continue
to carry BDB support until it's EOL in 2029 and RHEL9 until 2034 (I
think?). Therefore only people who run some sort of (usually
unsupported) utility to upgrade RHEL between major versions and then
attempt to run postfix without doing proper testing will get bitten by
this. It's not something that will happen just from a normal "dnf
update" command.
Peter
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
