dovecot - Feb 2023 - Redundant Database, Pgsql ?

I don't even get what the advatages are of doing this with sql. If you use
local replicated ldap and use local credential caching then your master ldap can
go down without issues, even the local caching handle some local slapd issues.
I guess the local caching is also faster. Afaik were databases not designed for
this purpose and a better fit is ldap.
> 
> If I understand open source Postgres correctly, though, this setup
> basically requires that the application be read-only, or at least be
> intelligent enough not to attempt to write to a host if it has failed
> over to it, right? Don't you have to have human intervention to
actually
> fail the master / primary over for write purposes?
> 
> Sent with Proton Mail secure email.
> 
> ------- Original Message -------
> On Tuesday, February 21st, 2023 at 10:28 PM, Marcus Jodorf
> <bofh at killfile.de> wrote:
> 
> 
> > On 2/21/23 18:04, Lars Schotte wrote:
> >
> 
> > > Yes, that looks nice, I am going to try that too.
> > >
> 
> > > Because every other option is based on some other software,
> > > like relayd or nginx, it is all possible, but adds complexity.
> > >
> 
> > > The best would be to have it inside connection string.
> >
> 
> >
> 
> > /etc/dovecot/dovecot-sql.conf.ext:
> >
> 
> > ...
> > connect= host=host1 host=host2 dbname=<db> user=<user>
password=<pwd>
> >
> 
> >
> 
> >
> 
> > I'm using that since pretty much 2006 - if I'm not mistaken -
on my
> > little servers. Simply works.
> >
> 
> > If one server is not reachable you just get an error log entry in
> > mail.err that connect failed to the database that is down.
> > But that is all - dovecot keeps working as normal.
> >
> 
> > BTW: Same with postfix. Simply list an additional fallback and it just
> > works.
> >
> 
> > Best,
> >
> 
> > Marcus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, 2023-02-22 at 11:08 +0000, Marc wrote:
> I don't even get what the advatages are of doing this with sql. If you
> use local replicated ldap and use local credential caching then your
> master ldap can go down without issues, even the local caching handle
> some local slapd issues.
Going to have to +1 this. LDAP also does multi-master replication, which
can make failover easier via DNS (like with a round robin for
ldap.mydomain), or multiple LDAP dictionaries for dovecot. The [big]
problem with OSS Postgres is that it only does master/slave replication,
with no plans to add multi-master replication to the code base (there is
Percona and 2ndQuadrant, but for small outfits, and individual there is
a price barrier there). Personally I love PGSQL as a DB, but for SSO I
use LDAP - because that's what it's designed for (i.e. read more than
written).

 
> I guess the local caching is also faster. Afaik were databases not
> designed for this purpose and a better fit is ldap.
This is totally true. RDBMS were not designed with this kind of use in
mind, LDAP was - it is, after all, a directory service. So unless your
auth stuff is part of some larger DB "thing" the directory type
solutions are not suitable for (how many table joins, or other extensive
SQL actions are taking place on that DB) then LDAP is the better way to
go, and extending LDAP with custom schemas is simple - just grab an IANA
number for you, or your organisation, so that you don't trample on any
other schema out there. I have a custom schema that I use for
postfix/dovecot - it's simple, quick, and efficient without the DB
overhead ... and I get the multi-master replication in OpenLDAP.

- -- 
Nikolai Lusan
Email: nikolai at lusan.id.au
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmP2/+4ACgkQ4ZaDRV2V
L6RRHxAAnSpKmYdg2+51CuSgxdQ8fHY65CRwflqQQzIEGIpApmgzh4fl5YkB8+qw
utLe5ao6Qd8dIbWmENsLVEZIHeHr9fsmENXXhgF1DIcHwSH12rZHC5pt0zjKWh3j
+dmmQ8/tlg/A3HbeEpMuFiVX02Zk3pddMW3D/ja7aAWXjecNmDHqxbghdhJrEzNy
3LiZQsGLQ0RvPiqULtk4ObSmjvuqZ9yJmnmV0IZTY1nRqJ74rHghwQOVK9HTTiMG
MizBLqCzbA3suV+TyYxEGE02EtTOGAcWyTcJWY5EGDs1K9GHNML6ZhimZepMmBxL
Bb4wr3rohNchdBiXyrACF0eNPJKMdMMWGAzySbWYiiXLRyyyM+KWjzvz6HDLmpXK
gCAwY4l8oPRf7Uw3XD1yVyZY6yPrkWV3AZoLL+UYc9N48sApQMG1xh1PcgsfU3+0
Y3FkFy8iltxENh2diLZo5ikfVmQ+YxAZEr5Epl/xmuj30u8tHqpbANKEcvJkhXNG
4bUZ2d+6zxj25vEQq+RkVVRnsfyXNlCaD+E8yyegqRNFnTJAlUlcFWCQ60TcnWqX
JKDDOTQj3rbfDZQMeTjbGfW5Fa8PJg5uRbnulXrK7RCizInoDIF8OpmXW4Hg4Ob9
1DiOJeQoefxIIkqs8Mlfj8t4mNy1/iZqs52DcTXRQVqogDesBWw=ZyC3
-----END PGP SIGNATURE-----