Description Mirac Erdemiroglu 2023-03-10 13:39:20 CET

I can specify additional UCS LDAP servers on a UCS Replica system via the variable "ldap/server/addition", which are used by the LDAP-dependent services and mechanisms as fallback

if the local LDAP server fails. Unfortunately this is quite ineffective if the local LDAP server is irreparably damaged and has to be reinitialized by the listener module

"replication" has to be reinitialized. Since the LDAP server is of course already running again during the initialization and is filled with data, it is already used again preferentially by

by all local services. As long as the replication is not finished, this leads to massive service failures and errors, because e.g. not all user accounts have been replicated yet.

user accounts have been replicated. In my specific scenario (see below), all UCR variables set via LDAP policies were also removed, which caused additional damage.

additional damage.


My wish would therefore be that the LDAP service would be unavailable for queries until the end of its initialization. Possibly this could be solved quite simply, by

let slapd listen only on localhost during initialization. The listener connects to 127.0.0.1, while all LDAP clients actually connect to the server FQDN for SSL reasons.

exclusively handle the server FQDN for SSL reasons.


Background:

Unfortunately, I managed to completely fill the root volume of our UCS mail server once for a very short period of time. The listener has a protection for such a case that it stops working.

protection that it stops working if the free space falls below a certain value (ucr get listener/freespace). The default 10 MB of free space in UCS was not sufficient.

of free space set by default in UCS was gone many times faster than the listener could notice it, so the state was corrupted and the listener (when it was restarted) had to stop working.

and the listener then (when memory was available again) automatically reinitialized the replication module and thus rebuilt the local LDAP. It was of course my

failure to set the listener/freespace variable to a higher value from the start - I have now done that domain-wide for next time.