Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable modifications of auth.conf to persist #218

Open
stahnma opened this issue Apr 21, 2020 · 2 comments
Open

Enable modifications of auth.conf to persist #218

stahnma opened this issue Apr 21, 2020 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@stahnma
Copy link
Contributor

stahnma commented Apr 21, 2020

Use Case

I wanted to tell Puppet to re-read the files on disk for an environment, but to do that i have to modify auth.conf. First, I think oh, here's auth.conf right in /var/lib/docker/volumes/pupperware_puppetserver-config/_data/, but after some chatting with Charlie and Morgan, seems like that file isn't actually used (so maybe it should go away) and that we need the auth.conf that would mount into puppetserver's conf.d directory.

Describe the Solution You Would Like

Have a way to modify auth.conf rules (the one that is used) that persists across container restarts. This could a volume mounted, it could be ENV vars set and read in or something.

Describe Alternatives You've Considered

  • Not using puppet?
  • Trying to use the older (easier to use) auth.conf.
  • Lie down, try not to cry, cry a lot

Additional Context

Probably should make the files either expose via volumes or values available in ENV vars.

@stahnma stahnma added the enhancement New feature or request label Apr 21, 2020
@stahnma
Copy link
Contributor Author

stahnma commented Apr 21, 2020

Another option here would be to just have an allow rule for the puppetserver container's cert to refresh envs int he default auth.conf setup.

@underscorgan underscorgan self-assigned this Apr 23, 2020
@Iristyle
Copy link
Contributor

For the auth.conf issue specifically, ENV vars are immutable once the container launches, so if it's something you think you want to change for a running container (rather than tearing down the container and starting up a new one), then the disk based solution is better. That said, a lot of the config is fairly opinionated at this point and not really designed to be modified by end users (partly b/c of a desire to interface with config in the Docker way and because we don't know all the additional things users really need to modify w/out feedback to tell us what those things are). I think your allow rule idea sounds like the right approach at the moment.

Related - I've been meaning to rework the VOLUME definitions in puppetserver to match the 4 volume setup in pe-puppetserver (or at least the first 3)

# generated certs, logs, restartcounter, filesync, reports, filebucket, facts.d
VOLUME /opt/puppetlabs/server/data/puppetserver \
# pe_repo packages
      /opt/puppetlabs/server/data/packages \
# code manager data, code-manager / filesync environment / staging, master code dir
      /opt/puppetlabs/server/data/code-manager \
# users should volume map in their id-control_repo.rsa. See 30-configure-ssh.sh
      /etc/puppetlabs/puppetserver/ssh

This is to make it easier to just swap in pe-puppetserver and point it to the same volumes as the open source version to "upgrade" and also because we figured out what config to tweak to make sure all the "data" lives in external volumes. This container has more of a legacy setup at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants