We now have puppet-lint-checkunsafeinterpolations and it detect some
issues. Fix them.
Pull Request (PR) description
The database 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 olcMirrorMode for
olcReadOnly.
This Pull Request (PR) fixes the following issues
n/a
Pull Request (PR) description
In my opinion, it would be logical to grant access to the RootDN if it is set and not to the abstract admin.
This Pull Request (PR) fixes the following issues
Pull Request (PR) description
Hi,
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 :)
br
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.
Pull Request (PR) description
There is an ordering in manifests/server/database.pp:
puppet
Class['openldap::server::service']
-> Openldap::Server::Database[$title]
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.
Pull Request (PR) description
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
around them).
This Pull Request (PR) fixes the following issues
n/a
