[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Openldap in container advice, how have you done it?
- To: openldap-technical <openldap-technical@openldap.org>
- Subject: RE: Openldap in container advice, how have you done it?
- From: "Marc Roos" <M.Roos@f1-outsourcing.eu>
- Date: Sat, 10 Aug 2019 14:07:12 +0200
- Content-disposition: inline
- In-reply-to: <"H00000710014b844.1565393021.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]
-----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?