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

Handle system configuration files #7

Open
metov opened this issue Sep 6, 2021 · 1 comment
Open

Handle system configuration files #7

metov opened this issue Sep 6, 2021 · 1 comment

Comments

@metov
Copy link
Owner

metov commented Sep 6, 2021

Versioning system configuration files (such as those under /etc) has additional caveats:

  • They must be owned by a certain user (usually root). With git, it is not possible to track this - the files are all owned by whoever called git clone.
  • Symlinking has security implications. These files are behind sudo for good reason, and symlinking them to the home directory creates a backdoor to this.
  • They often require machine-specific tweaking, even though the user might want to track the overall structure of the file.

So using symlinks to specify these is not practical. One pattern is to have an install script such as

$DEST=/etc/foo/config.conf
cat config.template.conf | envsubst > $DEST
chown root:root $DEST
chmod 644 $DEST

Of course, then we have to make sure we backup the existing config in case the new one is broken, copy it back to record changes, write a check script to compare it... And this must be repeated for each spec, hence it's quite laborious.

It would be nice if there was a better way, but I'm not sure what that would be.

@metov
Copy link
Owner Author

metov commented Sep 6, 2021

Technically, this sort of thing is out of scope for dotstree. Dotstree handles two use cases:

  • Soft symlinking configs
  • Running install/check commands

If we added "deploying /etc configs" to the list it would inflate scope, and technically this can be done already with the install command; though perhaps not conveniently.

It might be better to attack that point directly by providing a separate application (similar to the shell script above) that deals with /etc files. The install command can then call that separate application. There is already etckeeper for example, although it isn't exactly what I'm thinking of.

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

No branches or pull requests

1 participant