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
The database readonly property 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.
Fixes #207
Fixes #358
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
<!--
Thank you for contributing to this project!
-->
Pull Request (PR) description
I encountered an LDAP error 80 (LDAP_OTHER) whilst adding SSL certificates:
class { 'openldap::server':
ssl_cert => '/etc/ssl/certs/foo.com.crt',
ssl_key => '/etc/ssl/private/foo.com.key',
ssl_ca => '/etc/ssl/certs/foo.com.ca-bundle',
}
This Pull Request (PR) fixes the following issues
Doesn't delete temporary files before they're used
Rehash of #397
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, and that makes sense. However, it means the service happens before the whole defined resource Openldap::Server::Database ... and there is more going on in the defined resource of manifests/server/database.pp than just the openldap_database creation: there is also the creation of File[$manage_directory]. In most folks' cases, using a vendor-made package, this directory will be something like /var/lib/ldap, which happens to be installed by the RPM/dpkg package, so "you get it for free" / it already exists. Thus the file creation doesn't need to be done by puppet and ordering doesn't matter. 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's 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 folks to use subdirectories which puts this into the realm of needing to make a directory upon install, particularly when you want a second database.
In openldap::server::config, if redhat 8-or-newer, there's a systemd::dropin_file that makes a startup file so you can tune the user /usr/sbin/slapd runs as.
The problem is, there's a subtle assumption here that your binary is actually /usr/sbin/slapd. Ever since RHEL7.4, the openldap-servers has been deprecated, so some of us have pivoted over to using Symas' packages, which installs everything in /opt. That is, Puppet says to use /usr/sbin/slapd "because you're on RHEL8" (wrong), instead of "because you're using a RHEL-styled package". So this makes it more explicit why you're using this file, and takes it away when you use a different package.
"Why not just symlink slapd?" Tried, didn't work. systemd was not pleased by this.
"Why not just make the fully-pathed slapd executable be a parameter which defaults to /usr/sbin/slapd". Thought about it. But for the most part I'm thinking "this file adds unnecessary noise" so I went for the path of least surprise and removed it.
