The ip address is known when I start the container that would mean I need to sed some ready ldif and import it into the slapd at runtime. That would also require the the availability of some secret to be able to import it.

Although I have prepared the container for ldif fetching. Nicer would be if I could specify something like an environment variable in olcSyncrepl

-----Original Message----- From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de] Sent: maandag 12 augustus 2019 8:56 To: Marc Roos Subject: Antw: RE: Openldap in container advice, how have you done it?

...

...

"Marc Roos" M.Roos@f1-outsourcing.eu schrieb am 10.08.2019 um

14:07 in Nachricht <"H00000710014b895.1565438831.sx.f1-outsourcing.eu*"@MHS>:

Ok so long rep id is not going to work modifying entry "olcDatabase={2}hdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: Error: parse_syncrepl_line: syncrepl id 1911533132 is out of range [0..999]

Why not derive the ID from some container ID or from the container's IP address?

‑‑‑‑‑Original Message‑‑‑‑‑ From: Marc Roos Sent: zaterdag 10 augustus 2019 1:24 To: openldap‑technical@openldap.org Subject: Openldap in container advice, how have you done it?

I was thinking of putting read‑only slapd('s) in a container environment so other tasks can query their data. Up until now I have had replication only between vm's.

To be more flexible I thought of using stateless containers. Things that could be caveats

‑ replication id's say I spawn another instance, I need to have a new replication id to get updates from the master. But what if the tasks is killed, should I

keep this replication id? Or better just always use a random unique replication id whenever a slapd container is launched? Maybe use launch date/time (date +'%g%H%M%S%2N') as repid? Is this giving issues

with the master? What if I test with launching instances and the master will think there are a hundred slaves that are not connecting

anymore?

‑ updating of a newly spawned slapd instance When the new task is launched, it is not up to date with its database, can I prevent connections to the slapd until it is fully synced? Say I have user id's in slapd, it could be that when launching a new instance, this user is not available yet. When clients are requesting this data, they do not get it, and this user could be 'offline' until that specific instance of slapd is fully updated.

‑ to prevent lots of records syncing Can I just copy the data of /var/lib/ldap of any running instance to the container default image? Or does it have some unique id's that will prevent this data to be run multiple times? Is there some advice on how to do this?

‑ doing some /var/lib/ldap cleanup I am cleaning with db_checkpoint ‑1 ‑h /var/lib/ldap, and db_archive

‑d.

Is there an option slapd can initiate this?

‑ keep uniform configuration environment, or better a few different slapd instances? In my current environment vm slave slapd's only sync data from the master that the masters acls allow access to. That results in that on some vm's the ldap database is quite small and on other it is larger. I think for the container slapd instances to have all data, and just limit client access via the acls. But this means a lot more indexes on

the slapd

What else am I missing?