We now have puppet-lint-checkunsafeinterpolations and it detect some
issues. Fix them.
readonly properly expects a boolean, but the olc
provider doesn't take care to parse the existing value into a boolean,
thus leading to issues.
Simply applies the same logic applied to
In my opinion, it would be logical to grant access to the RootDN if it is set and not to the abstract admin.
Debian 12 uses libldap-2.5.0 instead of 2.4.2.
root@deg-debian12:/$ apt-cache search libldap-2
libldap-2.5-0 - OpenLDAP libraries
So i set the new Debian default to 2.5.0 and created seperate hiera yamls for the supported 10 and 11 release.
Tested it here and works now as expected :)
In order to avoid forgetting to remove deprecated code in the next major release, this PR track all pending removals and will get merged when a new major release is ready to be cut.
There is an ordering in
This is subtly bad. The service (slapd) must be spun up before a database can be created. That makes sense. However, it means the service happens before
Openldap::Server::Database ... and there is more going on in
manifests/server/database.pp than just the
openldap_database creation: there is also the creation of
File[$manage_directory]. In most folks' cases, this directory will be
/var/lib/ldap, which happens to be installed by the RPM/dpkg package, so "you get it for free" / it already exists and the file creation doesn't need to be done by puppet. However, if you set the directory to something else (that doesn't exist), you have a circular dependency problem.
slapd (the service) needs the database directory to exist before slapd starts up -> slapd is ordered before the database manifest -> the database manifest creates the database directory -> the database directory has to happen before the service.
Ultimately, the ordering is in error. The service has to happen before
openldap_database BUT NOT all of the ridealong items in
openldap::server::database. That breaks out of the dependency loop, and allows the directory creation to be marked as required before the Service is started.
Very likely, most folks are running one-DB-only in
/var/lib/ldap (which matches most examples) and haven't tickled this issue. That said, OpenLDAP maintainers are advising you to use subdirectories which puts this into the realm of needing to make a directory upon install.
Since it's entirely possible to have a distinguished name of style
o=My Cool Organization
even for the root of the database, we really need to respect the proper
handling of spacey arguments to olcAccess (with the relevant quotes