FIX: Unbreak on OpenBSD #233
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
_underscore, as well as such groups, therefore on OpenBSD, the user:group is _puppetdb:_puppetdb Because of that, instead of the single default in params.pp, move the definition of puppetdb_user and puppetdb_group into one of the OS specific case statement.
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.
Seems since end of April/beginning of May, with the
permission changes of puppetdb config ini files,
it is broken on OpenBSD.
This fixes is by setting the $puppetdb_user, and
$puppetdb_group in OS specific case statements:
Some more info:
underprivileged users from packages start with
_underscore, as well as such groups, therefore on OpenBSD, the
user:group is _puppetdb:_puppetdb
Because of that, instead of the single default in params.pp,
move the definition of puppetdb_user and puppetdb_group into
one of the OS specific case statement.
As a side node not 100% related:
I wonder why the config files have to be owned by
the puppetdb user/group?
From a security point of view, wouldn't it make more sense,
to have the config files owned by root:$puppetdb_group, and
permissions like 640? IIRC, puppetdb doesn't need to fiddle
with the files, only read access should be fine?
puppetdb is java, so the JIT requires memory regions being
writable AND executable at the same time, so being a potentially
valuable target for attackers.
cheers,
Sebastian