Rework default database lifecycle on Debian #372
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smortex
force-pushed
the
366
branch
5 times, most recently
from
3accf34
to
588c271
Compare
smortex
force-pushed
the
366
branch
7 times, most recently
from
bb4c275
to
c8242dd
Compare
smortex
changed the title
smortex
force-pushed
the
366
branch
9 times, most recently
from
289f553
to
f6bc04c
Compare
smortex
changed the title
This can spot some inconsistence issues where OpenLDAP is working correctly but a dump is not restorable, as spotted in #366.
When Debian install slapd, it configure it by default with a database that match the hostname unless overriden by a preseed file as we did before. This however has consequences on the database created by the module that prevent it from being restored after being dumped. Remove this custom database name and request no_configuration from the preseed file. This requires us to bootstrap the cn=config database, but also prevent the package from installing correctly ([709472]). Systemd presets files unfortunately do not help here, so rely on invoke-rc.d(8) to skip service management completly. Fixes #366 [709472]:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709472
The RedHat cleanup is still required but at least on RedHat we do not have the dump/restore issues we had on Debian. Adjust slightly the RedHad config that seems to have a few missing bits.
Unfortunately, we can't count on a better system than `policy-rc.d(8)` on Debian for preventing the service from starting on package installation. Some systems administrators might have system-wide configuration to never start any service, and they will not want to have this file managed in an uncontrolled way by the module. We assume that these administrators already have a `file` resource to manage this script, and that the default configuration will cause conflicts and the catalog will not be built. By disabling this script management in the module, administrators will revert to their previous behavior, after having a chance to adjust their own script if needed.
bastelfreak
approved these changes
Apr 13, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When Debian install slapd, it configure it by default with a database that match the hostname unless overridden by a preseed file as we did before. We did remove this database, however this has consequences on the first database created by the module and prevent it from being restored after being dumped (#366).
This PR remove database name customization and request
no_configurationfrom the preseed file. This requires us to bootstrap thecn=configdatabase, but also prevent the package from installing correctly (709472). To workaround this new issue, setup apolicy-rc.dso that the service is not started at the post-install stage. Becausepolicy-rc.dis a system-wide script, we hope to cause conflicts with infrastructures which have a custom one. We therefore provide a new flag to opt-out from managing this file from the repo.Existing databases which cannot be dumped/restored are not fixed, but new deployment should not have this issue.
Fixes #366