You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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.
Versioning system configuration files (such as those under
/etc
) has additional caveats:root
). With git, it is not possible to track this - the files are all owned by whoever calledgit clone
.So using
symlinks
to specify these is not practical. One pattern is to have an install script such asOf 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.
The text was updated successfully, but these errors were encountered: