Hi MJ,
LAM keeps the LDAP session for a page load (this can be multiple
operations). This is a restriction of PHP. This means when you click
somewhere on the page a new LDAP session will be opened.
Session stickiness makes absolute sense in such a scenario to avoid
inconsistencies.
Best regards
Roland
Am 30.11.20 um 14:46 schrieb mj:
Hi!
We were connecting lam to our samba, through haproxy configured with our
backend samba servers.
My colleague used LAM to move a user from one OU to another, and after
that we started seeing replication errors. The change was done on DC4,
and never replicated to DC3/DC2.
We hired sernet to look into this, and the only reason they could find
is our config of LAM through haproxy. In it's default configuration
HAProxy load balances using round-robin between the different backend
servers.
That spreads the load very nicely, but in the case of ldap changes that
need to replicated it does not work very nicely. As in:
- lam writes to haproxied samba ldap
- haproxy changes backend ldap server but:
- replication has not yet replicated the change
- lam reads back different (old) contents provided by a different
backend samba ldap (so what LAM receives is not what LAM has just written)
Not sure what LAM will do in that case. Is there any logic in LAM that
gets triggered at that point? (attempt again to write the same contents,
perhaps..?)
We have now changed HAProxy config, to make client sessions STICK to the
same backend server, for as long as the backendserver is available,
called "source". That should make sure this cannot happen again.
(of course we should have configured haproxy that ANYWAYS, as that is a
much better way to handle ldap edits, so yes I was stupid, but... it
never resulted in replication issues before)
However, the feedback we got from sernet was: perhaps it would be good
for LAM to keep a session open, and RE-use that session for multiple
actions, so not close the connection after each operation.
Just wanted to pass-on that suggestion to you. Feel free to ignore it if
you want. :-)
Anyway, sernet solved the replication issue nicely, haproxy config is
adjusted, and so far we're happy again. :-)
All the best and thanks for reading!
MJ
_______________________________________________
Lam-public mailing list
Lam-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lam-public
_______________________________________________
Lam-public mailing list
Lam-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lam-public
