> On Jan 19, 2021, at 10:00 AM, Viktor Dukhovni <postfix-us...@dukhovni.org>
> wrote:
>
> On Tue, Jan 19, 2021 at 03:03:49PM +0100, Ganael Laplanche wrote:
>
>>> http://www.postfix.org/memcache_table.5.html
>>
>> Maybe memcache with a *very* long TTL could be used here, but I was looking
>> for a pseudo-dictionay such as unionmap (maybe something like 'noretrymap')
>> that would ignore DICT_ERR_RETRY from failing backends and get the first
>> useable result from child dicts.
>>
>> Would there be another option ?
>
> The only solution that comes to mind is "socketmap". You can write your
> own (for reasonable performance, not single-threaded) server that keeps
> track of whether LDAP is producing acceptable answers, and if not, falls
> back to stale local sources).
>
> You'll need an LDAP connection pool, and some way to determine whether
> the LDAP replies are acceptable (that's the hard part).
>
> --
> Viktor.
I’ve been watching this thread and all the contortions you are truung to do to
get postfix to do something it’s not designed to do. You can change postfix
parameters on the fly. Please pardon me if you think this might be a stupid
question, but LDAP has excellent replication capabilities. How about multiple
LDAP servers in a high availability setup? instead of continual replication,
replicate once per week. If you’re virtualized, make sure the LDAP guests
reside on different hosts. See Linux heartbeat setups. that doesn’t satisfy
your needing to read from backup data, though.
another idea would be to script it. write a daemon ( if you need it to check
more than once per minute) that checks the ldap server periodically to see that
it’s returning correct information. if it is not, the script can issue a
postconf command to change ldap servers on the fly.
by that matter a script could simply repopulate that section of its database
from the dump file you created and that can also be done on the fly. importing
the ldif file doesn’t take much time, even for large files. alternatively, you
could get the ldap server to reverse its replication direction and simply
repopulate the master from the backup server. the reconciliation will only
take a few seconds.
you could also build a quick webapp for your team that could restore a single
or multiple accounts from the slave server back to the master with the
accidental deletion.
there are ways to automate this in such a way that downtime or rejected mail
time is minimal. there is also the matter of restoring the mailbox, too.
Ther is also btrfs or zfs with snapshot capabilities. stop the ldap server,
restore the database from the snapshot, start the server. that can also be
automated and have it happen in seconds.
—Curtis
Sent from my iPhone
