Ziele Untersuchung
mit Columbo Integrität von
Datenbanken Interaktion und
Portierbarkeit Ergonomie der
Schnittstellen

Angebot Produkte Projekt Beratung

Mittel Analytik Modellierung Sprachen Algebra Logik Hardware Denken Kreativität

Zusammenhänge Gesellschaft Wirtschaft Branche Firma

Benutzer


products/Sources/formale Sprachen/C/Postfix/proto/ (Postfix Mailserver Version 3.11^©) Datei vom 10.2.2026 mit Größe 28 kB

Quelle NON_BERKELEYDB_README.html

Sprache: HTML

products/Sources/formale Sprachen/C/Postfix/proto/NON_BERKELEYDB_README.html

<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
 "https://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>Postfix Non-Berkeley-DB migration</title>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>

</head>

<body>

<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
Non-Berkeley-DB migration</h1>

<hr>

<h2> Table of contents </h2>

 Note: be sure to visit the on-line version of this text at
https://www.postfix.org/NON_BERKELEYDB_README.html, as support for
different Postfix versions may be added over time. 

<ul>

<li> <a href="#intro">Introduction </a>

<li> <a href="#background">Background </a>

<li> <a href="#build-conf">Skip this if not building Postfix from
source, or if your system still supports Berkeley DB </a>

<li> <a href="#level-overview"> Migration support level overview </a>

<li> <a href="#disable"> Level 'disable': manual migration </a>

<li> <a href="#enable-redirect"> Level 'enable-redirect': database
aliasing </a>

<li> <a href="#enable-reindex"> Level 'enable-reindex': redirect
and automatically generate non-Berkeley-DB indexed files </a>

<li> <a href="#addr-errors">Addressing errors with automatic indexed
file generation </a>

<li> <a href="#mailman">Appendix: Mailman integration </a>

</ul>

<h2> <a name="intro">Introduction </a> </h2>

 (With Postfix 3.10 and earlier, please skip to the "<a
href="#manual">Manual Migration Process"</a>.) 

 (Please see the <a href="#mailman">Appendix</a> for Mailman
integration tips.) 

 After running the same Postfix configuration for a decade or
more, there is a rude awakening when you update the OS to a newer
version that has deleted its support for Berkeley DB. Postfix
programs fail to open all hash: and btree: tables with messages
like this: 

<blockquote>
<pre>
Berkeley DB support for 'hash:/etc/postfix/virtual' is not available
for this build; see https://www.postfix.org/NON_BERKELEYDB_README.html
for alternatives
</pre>
</blockquote>

 This document comes to the rescue, with strategies to migrate
an existing Postfix configuration that uses Berkeley DB hash: and
btree: database files, to an OS distribution that has removed
Berkeley DB support, with a Postfix configuration that uses lmdb: (or
a combination of cdb: and lmdb:). 

 By the way, you don't have to wait until Berkeley DB support
is removed; your can proactively use the steps described here on a
system that still has Berkeley DB, to migrate a Postfix configuration
from Berkeley DB to lmdb: (or a combination of cdb: and lmdb:).

<h2> <a name="background">Background </a> </h2>

 Historically, Postfix has used Berkeley DB hash: and btree: for
key-value stores, as indicated in the "With Berkeley DB" table
column below. In a world without Berkeley DB, good replacements are
cdb: and lmdb: as indicated in the "No Berkeley DB" column. 

<blockquote>

<table border="1">

<tr> <th> Purpose </th> <th> With Berkeley DB </th> <th> No Berkeley
DB </th> </tr>

<tr> <td> Mostly-static data such as aliases, transport_maps,
access tables </td> <td> default_database_type=hash </td> <td>
default_database_type=lmdb or default_database_type=cdb </td>
</tr>

<tr> <td> Dynamic caches maintained by postscreen(8), verify(8),
tlsmgr(8) </td> <td> default_cache_db_type=btree </td> <td>
default_cache_db_type=lmdb </td> </tr>

</table>

</blockquote>

 The default values for default_database_type and default_cache_db_type
may be specified at build time (see the <a href="#build-conf">section
below</a>, and they may be changed later by editing main.cf, for
example with the postconf(1) command.) 

 The sections that follow present three migration strategies
with different levels of assistance by tooling that was developed
for Postfix 3.11 and later. 

<h2> <a name="build-conf"> Skip this if not building Postfix from
source, or if your system still supports Berkeley DB. </a> </h2>

 <a href="#level-overview">Click here to skip to the next section</a>.

 On systems that have removed Berkeley DB support, run "<tt>make
makefiles</tt>" with a CCARGS value that (also) contains "-DNO_DB",
and specify appropriate values for default_database_type (lmdb or cdb)
and default_cache_db_type (lmdb). 

 In the examples below, the "<tt>...</tt>" are place holders any
dependencies that you build Postfix with, such as CDB, LDAP, LMDB,
MySQL/MariaDB, OpenSSL, SASL, and so on.

<ul>

<li> Example 1: use lmdb: for both default_database_type (read-mostly
lookup tables) and default_cache_db_type (read-write caches). Terminal
input is bold, output is <tt>normal</tt> font. 

<blockquote> <pre>
$ make makefiles CCARGS="-DNO_DB ..." \
 default_database_type=lmdb \
 default_cache_db_type=lmdb ... \
 AUXLIBS...
</pre>
</blockquote>

 See LMDB_README for LMDB-specific instructions. 

<li> Example 2: alternative form that produces the same result.


<blockquote>
<pre>
$ export CCARGS="-DNO_DB ..."
$ export default_database_type=lmdb
$ export default_cache_db_type=lmdb
$ export AUXLIBS...
...
$ make makefiles
</pre>
</blockquote>

 See LMDB_README for LMDB-specific instructions. 

<li> Another alternative is to use cdb for default_database_type
(read-mostly lookup tables) and lmdb for default_cache_db_type
(read-write caches). See CDB_README for CDB-specific instructions. 

</ul>

<h2> <a name="level-overview"> Migration support level overview </a> </h2>

 The goal of the migration is clear: stop using hash: and btree:,
and use lmdb: or cdb: instead. If your configuration is simple or
if you are familiar with Postfix configuration, a few "<tt>grep</tt>"
commands will find all the problems, and a few edits will be easy
to make. 

 If, on the other hand, you are not familiar with the details of your
Postfix configuration, then this document provides options where Postfix
can help. 

 Postfix 3.11 introduces multiple levels of migration support.
You can use the command "<tt>postfix non-bdb status</tt>" to view
the migration support level. This is what the default should look
like (terminal input is <tt>bold</tt>, output is <tt>normal</tt>
font): 

<blockquote>
<pre>
# postfix non-bdb status
disable
</pre>
</blockquote>

 In increasing order, the support levels are: 

<dl>

<dt> <a href="#disable">disable</a> (manual migration) </dt>

<dd> You start up Postfix, watch the <a
href="DEBUG_README.html#logging">logging</a> when Postfix programs
fail to open a hash: or btree: table, edit Postfix configuration
files to use lmdb: or cdb:, then run postmap(1) or postalias(1)
commands to create lmdb: or cdb: indexed database files. Use this
option if you are familiar with Postfix configuration. 

 This will not fix the integration with Mailman versions from
before <a
href="https://gitlab.com/mailman/mailman/-/commit/8fa56b72dccd318c171b7f373c13214f43c7d32d">gitlab
commit 8fa56b72</a> (May 2025) and other software that are broken
when they want to use "<tt>postmap hash:/path/to/file</tt>".
Mailman uses this to maintain a table with mailing list contact
addresses. For that, you need to use the next-up level. </dd>

<dt> <a href="#enable-redirect">enable-redirect</a> (database
aliasing) </dt>

<dd> This level implicitly redirects a request to access
hash:/path/to/file to $default_database_type:/path/to/file,
and redirects a request to access a btree:/path/to/file to
$default_cache_db_type:/path/to/file. 

 This still requires manually running postmap(1) or postalias(1)
commands, but "fixes" the integration with Mailman versions from
before <a
href="https://gitlab.com/mailman/mailman/-/commit/8fa56b72dccd318c171b7f373c13214f43c7d32d">gitlab
commit 8fa56b72</a> (May 2025) and other software when they want
to use "<tt>postmap hash:/path/to/file"</tt>, and Berkeley
DB support is not available. Such commands will implicitly create
a new lmdb: or cdb: indexed database file, depending on the
default_database_type value. </dd>

<dt> <a href="#enable-reindex"> enable-reindex </a> (aliasing, plus
running postmap(1) or postalias(1))</dt>

<dd> This level implements "<tt>enable-redirect</tt> (database
aliasing)", and also runs the postmap(1) or postalias(1) command to create
a new lmdb or cdb indexed database file. This uses the nbdb_reindexd(8)
daemon. 

</dl>

 The levels <a href="#enable-redirect">enable-redirect</a> and
<a href="#enable-reindex"> enable-reindex </a> leave some technical
debt: configurations that still say hash: or btree: (even if
they use lmdb: or cdb: behind the scene). 

<ul>

<li> Using these levels gives you extra time to prepare for a
long-term configuration change that replaces hard-coded instances of hash:
with the value of default_database_type, and that replaces btree: with
the value of default_cache_db_type. 

<li> Depending on your use of other software that wants to use
postmap(1) or postalias(1) commands, you may have to permanently
the leave the <a href="#enable-redirect">enable-redirect</a> level
active. 

</ul>

 After this overview, the sections that follow will go into more
detail. 

<h2> <a name="disable"> Level 'disable': manual migration </a> </h2>

 (With Postfix 3.10 and earlier please skip to "<a href="#manual">Manual
Migration Process"</a> below.) 

 On Postfix 3.11 and later, to disable all non-Berkeley-DB
migration features use the "<tt>postfix non-bdb</tt>" command:

<blockquote>
<pre>
# postfix non-bdb disable
# postfix reload
</pre>
</blockquote>

 This will edit main.cf to remove a non_bdb_migration_level setting
and the level revert to its implicit default (disable), and will edit
master.cf to remove an entry for the <tt>reindex</tt> service. 

 This setting will cause problems with Mailman versions from
before <a
href="https://gitlab.com/mailman/mailman/-/commit/8fa56b72dccd318c171b7f373c13214f43c7d32d">gitlab
commit 8fa56b72</a> (May 2025) and other software that wants to use
"<tt>postmap hash:/path/to/file</tt>" (or similar postalias
commands), and Berkeley DB support is no longer available. In that
case, you will need the "<tt><a
href="#enable-redirect">enable-redirect</a></tt>" migration support
level.

 <a name="manual">The manual migration process</a> goes like this: 

<table border=1>

<tr> <th> Manual Migration Process (all Postfix versions) </th> </tr>

<tr> <td>

<ul>

<li> Stop Postfix. 

<li> Make lmdb the default for both default_database_type
(read-mostly lookup tables) and default_cache_db_type (read-write
caches): 

<pre>
# postconf default_database_type=lmdb default_cache_db_type=lmdb
</pre>

<li> Alternatively, make cdb the default for default_database_type
(read-mostly lookup tables). 

<li> Look for hash: and btree: references in Postfix
configuration files. Instead of <tt>/etc/postfix</tt> use the pathname
in the output from "<tt>postconf -x config_directory</tt>". 

<pre>
# grep -E -r '(hash|btree):/' /etc/postfix
</pre>

 (Use "egrep" on systems that do not support "grep -E".) 

<li> For each instance in the "<tt>grep</tt>" output : 

<ol>

<li> Edit the configuration file and replace "hash" with "lmdb"
or "cdb" (use the same value as the output from "<tt>postconf
-hx default_database_type</tt>") and replace "btree" with "lmdb".


<li> If this instance has no source file (only the ".db" file
exists), proceed with the next instance of "<tt>grep</tt>" output.


<li> Postfix 3.11 and later: if this instance appears in the
output from "<tt>postconf -hPPx '*/*/alias_maps' | sort -u</tt>",
run the postalias(1) command. If this instance is like
"lmdb:/path/to/source": 

<pre>
# postalias lmdb:/path/to/source
</pre>

 Instead of "lmdb:" use "cdb:" if the instance is like
"<tt>cdb:/path/to/source</tt>". 

<li> Postfix 3.10 and earlier: if this instance appears in the
output from "<tt>postconf -hx alias_maps</tt>", run the
postalias(1) command. If this instance is like "lmdb:/path/to/source":


<pre>
# postalias lmdb:/path/to/source
</pre>

 Instead of "lmdb:" use "cdb:" if the instance is like
"<tt>cdb:/path/to/source</tt>". 

<li> Otherwise, run the postmap(1) command. If this instance
is like "<tt>lmdb:/path/to/source</tt>": 

<pre>
# postmap lmdb:/path/to/source
</pre>

 Instead of "lmdb:" use "cdb:" if this instance is like
"<tt>cdb:/path/to/source</tt>". 

</ol>

<li> Disable inbound network mail, start Postfix, and
send a test message using the Postfix sendmail(1) command. 

<pre>
# postconf master_service_disable = inet
# postfix start
# sendmail -bv postmaster
</pre>

<li> Watch the <a href="DEBUG_README.html#logging">log</a> for
warnings about files that cannot be opened, find the configuration
file that still uses "hash" or "btree", and repeat steps 1-5 above.


<li> Enable inbound network mail, reload Postfix, and connect
to the Postfix SMTP network port. 

<pre>
# postconf -X master_service_disable
# postfix reload
# telnet hostname 25
</pre>

<li> Watch the <a href="DEBUG_README.html#logging">log</a> for
warnings about files that cannot be opened, find the configuration
file that still uses "hash" or "btree", and repeat steps 1-5 above.


</ul>

</td> </tr> </table>

<h2> <a name="enable-redirect"> Level 'enable-redirect': database
aliasing (Postfix 3.11 and later)</a> </h2>

 This level is enabled with: 

<blockquote>
<pre>
# postfix non-bdb enable-redirect
# postfix reload
</pre>
</blockquote>

 But you should probably wait and review the "Migration Process"
below first. 

 This <tt>postfix non-bdb</tt>" command edits main.cf to enable
redirection (aliasing) from Berkeley DB types "hash" and "btree"
to the non-Berkeley-DB types specified with $default_database_type
and $default_cache_db_type. Custom redirection may be configured
with non_bdb_custom_mapping. This command also edits master.cf to
remove an unused <tt>nbdb_reindex</tt> service entry. 

 The redirection activity is <a
href="DEBUG_README.html#logging">logged</a> by default, to help
discovering obsolete configuration. Example: 

<blockquote>
<pre>
redirecting hash:/etc/postfix/transport to lmdb:/etc/postfix/transport
</pre>
</blockquote>

 This logging may be disabled by setting "non_bdb_migration_log_redirect
= no". 

 This migration support level will not automatically create
non-Berkeley-DB indexed database files; if you need that, see "<a
href="#enable-redirect">enable-redirect</a> below. Instead, Postfix
programs will log an error as they fail to open an indexed database
file, and will leave it to the system administrator to run postmap(1)
or postalias(1) to create that file. 

<table border=1>

<tr> <th> Migration Process with 'enable-redirect' (Postfix 3.11
and later) </th> </tr>

<tr> <td>

 Suspend inbound mail with: 

<blockquote>
<pre>
# postconf master_service_disable = inet
</pre>
</blockquote>

 Enable database redirection: 

<blockquote>
<pre>
# postfix non-bdb enable-redirect
</pre>
</blockquote>

 Start (or reload) Postfix, and send a test message using the
Postfix sendmail(1) command. 

<blockquote>
<pre>
# postfix start (or postfix reload)
# sendmail -bv postmaster
</pre>
</blockquote>

 Scan the <a href="DEBUG_README.html#logging">logging</a> for
failure to open database files. For each instance of
"<tt>hash:/path/to/source</tt>" or "<tt>btree:/path/to/source</tt>"
that requires manually running postmap(1) or postalias(1): 

<ul>

<li> If this instance appears in the output from "<tt>postconf
-hPPx '*/*/alias_maps' | sort -u</tt>", run the postalias(1)
command. If this instance is like "<tt>lmdb:/path/to/source</tt>":


<pre>
# postalias lmdb:/path/to/source
</pre>

 Instead of "lmdb:" use "cdb:" if the instance is like
"<tt>cdb:/path/to/source</tt>". 

<li> Otherwise, run the postmap(1) command. If this instance
is like "<tt>lmdb:/path/to/source</tt>": 

<pre>
# postmap lmdb:/path/to/source
</pre>

 Instead of "lmdb:" use "cdb:" if this instance is like
"<tt>cdb:/path/to/source</tt>". 

</ul>

 Resume inbound mail, reload Postfix, and connect to the Postfix
SMTP network port: 

<blockquote>
<pre>
# postconf -X master_service_disable
# postfix reload
# telnet hostname 25
</pre>
</blockquote>

 This may reveal a few more problems. Once there are no more
errors with opening database files for about 24 hours, scan the <a
href="DEBUG_README.html#logging">log</a> for messages similar to:


<blockquote>
<pre>
redirecting xxx:/path/to/file to yyy:/path/to/file
</pre>
</blockquote>

 and update the obsolete Postfix configuration settings, replacing
"xxx:/path/to/file" with "yyy:/path/to/file. 

 Once there is no more "redirect" logging, and there are no other
programs (such as Mailman, see <a href="#mailman">Appendix</a>
below) that want to use "postmap hash:/path/to/file", then
you can turn off non-Berkeley-DB migration support (see "<a
href="#disable">disable</a>" above). 

</td> </tr> </table>

 This migration support level will fix problems with Mailman
versions from before May 2025 and other software that wants to use
"<tt>postmap hash:/path/to/file</tt>". With database
redirection, such commands will implicitly create an indexed file
for $default_database_type:/path/to/file (similar aliasing
happens for postalias commands). 

 The command "<tt>postfix non-bdb enable-redirect</tt>" will
refuse to make any changes when default_database_type or
default_cache_db_type specify a hash: or btree: type.

<h2> <a name="enable-reindex"> Level 'enable-reindex': redirect and
automatically generate non-Berkeley-DB indexed files (Postfix 3.11
and later)</a> </h2>

 NOTE: this level should be used only temporarily to generate
most of the non-Berkeley-DB indexed files that Postfix needs.
Leaving this enabled may expose the system to privilege-escalation
attacks. There are no security concerns for using enable-redirect.
 

 This level is enabled with: 

<blockquote>
<pre>
# postfix non-bdb enable-reindex
</pre>
</blockquote>

 But you should probably wait and review the "Migration Process"
below first. 

This postfix non-bdb command edits main.cf to set the non-Berkeley-DB
migration support level, and master.cf to add or replace an
<tt>nbdb-reindex</tt> service entry. 

 The resulting configuration implements not only the functionality
of <a href="#enable-redirect"> enable-redirect</a>, but also tries
to automatically create a non-Berkeley-DB indexed database file
when a daemon program wants to access a file that does not exist.
This uses the nbdb_reindexd(8) daemon to run postmap(1) or postalias(1)
commands for databases that satisfy basic requirements to block
privilege-escalation attacks. The number of requirements is large,
but mainly, database files and their parent directory must not allow
write access for group or other users, and their pathnames must
match a list of trusted directory prefixes. The complete list of
requirements is documented in nbdb_reindexd(8). 

This command immediately generates non-Berkeley-DB indexed files
for command-line programs that lack privileges to send requests to
the nbdb_reindexd(8) indexing server. This applies to "hash:" and
"btree:" tables that are used by postqueue(1) and sendmail(1) as
configured with authorized_flush_users and authorized_mailq_users,
and used by sendmail(1) and postdrop(1) as configured with
authorized_submit_users and local_login_sender_maps. 

 The command "<tt>postfix non-bdb enable-reindex</tt>" will
refuse to make any changes when default_database_type or
default_cache_db_type specify a hash: or btree: type.

<table border=1>

<tr> <th> Migration Process with 'enable-reindex' (Postfix 3.11
and later) </th> </tr>

<tr> <td>

 Suspend inbound mail with: 

<blockquote>
<pre>
# postconf master_service_disable = inet
</pre>
</blockquote>

 Enable automatic re-indexing: 

<blockquote>
<pre>
# postfix non-bdb enable-reindex
</pre>
</blockquote>

 Start (or reload) Postfix, and send a test message using the
Postfix sendmail(1) command. 

<blockquote>
<pre>
# postfix start (or postfix reload)
# sendmail -bv postmaster
</pre>
</blockquote>

 The nbdb_reindexd(8) daemon will <a
href="DEBUG_README.html#logging">log</a> when it successfully runs
a postmap(1) or postalias(1) command. Examples, for a system with
"<tt>default_database_type = lmdb</tt>": 

<blockquote>
<pre>
successfully executed 'postmap lmdb:/etc/postfix/transport' as uid 0
successfully executed 'postalias lmdb:/etc/aliases' as uid 0
</pre>
</blockquote>

 If Postfix programs <a href="DEBUG_README.html#logging">logs</a>
error messages like: 

<blockquote>
<pre>
could not execute command xxx...
</pre>
</blockquote>

 see the section "<a href="addr-errors">Addressing errors
with automatic indexed file generation</a>" for the most likely
errors that Postfix programs may log. 

 Once there are no more errors from Postfix programs, resume
inbound mail, reload Postfix, and connect to the Postfix SMTP network
port: 

<blockquote>
<pre>
# postconf -X master_service_disable
# postfix reload
# telnet hostname 25
</pre>
</blockquote>

 This may reveal a few more problems. Once there are no more
errors from Postfix programs for about 24 hours, turn off automatic
index generation by reducing the support level to <tt>enable-redirect</tt>
with: 

<blockquote>
<pre>
# postfix non-bdb enable-redirect
# postfix reload
</pre>
</blockquote>

 Then, scan the <a href="DEBUG_README.html#logging">log</a> for
instances similar to: 

<blockquote>
<pre>
redirecting xxx:/path/to/file to yyy:/path/to/file
</pre>
</blockquote>

 and update the obsolete Postfix configuration settings, replacing
"xxx:/path/to/file" with "yyy:/path/to/file. 

 Once there is no more "redirect" logging, and there are no other
programs (such as Mailman, see <a href="#mailman">Appendix</a>
below) that want to use "postmap hash:/path/to/file", then
you can turn off non-Berkeley-DB migration support (see "<a
href="#disable">disable</a>" above). You will have keep Postfix
configured with "<tt>enable-redirect</tt>" until Mailman can be
updated to a version that supports other Postfix database types.


</td> </tr> </table>

<h2> <a name="addr-errors">Addressing errors with automatic
indexed file generation </a> </h2>

<h3> Unexpected pathname errors </h3>

 Depending on the location of your Postfix lookup tables, Postfix
programs may <a href="DEBUG_README.html#logging">log</a> a request
to add a trusted directory to the directories listed with
non_bdb_migration_allow_root_prefixes or
non_bdb_migration_allow_user_prefixes. 

 Example, with line breaks added for readability: 

<blockquote>
<pre>
could not execute command 'postmap lmdb:/path/to/file': table
/path/to/file has an unexpected pathname;

to allow automatic indexing as root, append its parent directory
to the non_bdb_migration_allow_root_prefixes setting (current setting
is: "/etc /usr/local/etc");

alternatively, execute the failed command by hand
</pre>
</blockquote>

 You have two options: 

<ol>

<li> If you think that the suggested change is safe, update the
setting as proposed and execute "<tt>postfix reload</tt>". 

<li> Alternatively, you can execute the failed postmap(1) or
postalias(1) command by hand, and Postfix will not log the same error
again. 

</ol>

 A similar request may be logged when a file needs to be indexed as
a non-root user. 

<h3> Unexpected file or directory owner or permissions </h3>

 Other errors may be <a href="DEBUG_README.html#logging">logged</a>
when a database file or directory has an unexpected owner, or when
it is writable by group or by other users. 

 Example with line breaks added for readability: 

<blockquote>
<pre>
could not execute command 'postmap lmdb:/path/to/file': legacy
indexed file '/path/to/file.db' is owned by uid '0', but parent
directory '/path/to' is owned or writable by other user;

to allow automatic indexing, correct the ownership or permissions;

alternatively, execute the failed command by hand
</pre>
</blockquote>

 Again, you have two options: 

<ol>

<li> Fix the ownership or permission error. 

<li> Execute the failed postmap(1) or postalias(1) command by
hand, and Postfix will not log the same error again. 

</ol>

<h2> <a name="mailman">Appendix: Mailman integration </a> </h2>

 This section has instructions to migrate an existing Mailman
configuration that wants to use commands like "postmap
hash:/path/to/file". Mailman uses such commands to maintain
tables with mailing list contact addresses and domain names. This
will break on systems that no longer have Berkeley DB support. 

 Solutions: 

<ul>

<li> (Not recommended) Upgrade to a Mailman version that contains
<a
href="https://gitlab.com/mailman/mailman/-/commit/8fa56b72dccd318c171b7f373c1321
4f43c7d32d">gitlab commit 8fa56b72</a> (May 2025). Unfortunately,
this has not yet been widely adopted by OS distributions. 

<li> Avoid Mailman changes, and use Postfix migration support
described below. In a nutshell, the postmap command will execute
the command "postmap hash:/path/to/file" as if the command
specifies lmdb:/path/to/file (or cdb:, depending on Postfix
configuration). 

</ul>

 With Mailman3 the integration with Postfix using LMTP may look
like: 

<blockquote>
<pre>
/var/lib/mailman3/data/postfix_domains (domain names)
/var/lib/mailman3/data/postfix_domains.db (Berkeley DB hash file)
/var/lib/mailman3/data/postfix_lmtp (transport map)
/var/lib/mailman3/data/postfix_lmtp.db (Berkeley DB hash file)
</pre>
</blockquote>

<blockquote> Caution: the data directory may contain other files
with names ending in "<tt>.db</tt>" that are not part of the
Mailman-Postfix integration. Do not tamper with the other files. 
</blockquote>

 The relevant Postfix migration levels are: 

<dl> <dt> <a href="#enable-redirect">enable-redirect</a> (redirect hash:
to lmdb: or cdb:) </dt>

<dd> Command: <tt> # postfix non-bdb enable-redirect</tt> 

 This will fix the problem that Mailman wants to use commands like
"<tt>postmap hash:/path/to/postfix_domains</tt>" and "<tt>postmap
hash:/path/to/postfix_lmtp</tt>". 

 Instead of complaining about an unsupported database type, these
postmap commands will implicitly create "<tt>.lmdb</tt>" indexed
files like (lmdb:/path/to/postfix_domains or
lmdb:/path/to/postfix_lmtp, or their cdb: versions depending
on the Postfix default_database_type setting). 

 This will not fix the problem that Postfix wants to
use databases like hash:/path/to/postfix_domains
and hash::/path/to/postfix_lmtp. With <a
href="#enable-redirect">enable-redirect</a>, these will redirect to
"<tt>.lmdb</tt>" indexed files (good) but those files do not yet exist
(bad). You will need to create them by hand with commands like: 

<pre>
# postmap lmdb:/path/to/postfix_domains
# postmap lmdb:/path/to/postfix_lmtp
</pre>

 After this, no further human action will be needed. When Mailman
needs to update these files, it will invoke postmap commands that
will work as promised above. Leave the Postfix migration level at <a
href="#enable-reindex">enable-reindex</a> until you can upgrade to a
newer Mailman version that supports Postfix with non-Berkeley
databases. 

</dd>

<dt><a href="#enable-reindex">enable-reindex</a> (also automatically
run postmap commands)</dt>

<dd> Command: <tt> # postfix non-bdb enable-redirect</tt> 

 In addition to "<a href="#enable-redirect">enable-redirect</a>",
Postfix will also try to run commands like "<tt>postmap
lmdb:/path/to/postfix_domains</tt>" and "<tt>postmap
lmdb:/path/to/postfix_lmtp</tt>". There will be some delay
depending on the amount of mailing list traffic; you may want to post
a test message to make the postmap commands happen sooner. 

 Postfix will <a href="DEBUG_README.html#logging">log</a> the
postmap commands (or will log a request to make some configuration
changes; see "<a href="addr-errors">Addressing errors with automatic
indexed file generation</a>" above). 

 Note: once these "postmap" commands have completed,
you should reduce the migration support level with the command
"postfix non-bdb enable-redirect". For security reasons the <a
href="#enable-reindex">enable-reindex</a> level should not be permanently
enabled. 

</dl>

</body>

</html>

Messung V0.5 in Prozent

¤ Dauer der Verarbeitung: 0.17 Sekunden (vorverarbeitet am 2026-08-08) ¤

Wurzel

Suchen

PVS Prover

Isabelle Prover

NIST Cobol Testsuite

Cephes Mathematical Library

Vienna Development Method

Haftungshinweis

Die Informationen auf dieser Webseite wurden nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit, noch Qualität der bereit gestellten Informationen zugesichert.