Is it a good idea to replace files in etc with symlinks?

Question

I don't switch machines that often, but I don't want to be bound to 1 machine. Often the reason I'm not upgrading my hardware is because I don't want to be setting up a new machine.

So far I've made efforts into concentrating most of my stuff in the home directory so that will be easy to backup and deploy on a new machine.

Biggest issue are those, possibly hundreds, of config files that live in etc to which I've done some, often miniscule, changes but nothing would work without them on a new machine.

I had an idea of making a script that snatches files from etc, puts them in my home directory and replaces the original with a symlink. Then I would have another script that on the new machine will go over snatched files and replace the originals with symlinks.

I'm not sure how confusing that sounded so here's a quick example.

#!/bin/bash

FILE=$(realpath $1)
TARGET=$(realpath ~/snatched)$FILE

mkdir -p $TARGET
mv $FILE $TARGET
ln -s $TARGET $FILE

Then running

snatch /etc/hosts

Will put /etc/hosts into ~/snatched/etc/hosts and create a symlink at the original location.

I'm worried for underwater stones, anything that's gonna make me regret this in the future and essentially advice from more experienced users.

Thanks!

Answer 1

No!

1. You'll have a non-standard system. Future system updates to files in /etc will break the symlinks.
2. Many security and authentication programs regard their configuration files in /etc not being files as the sign of an attack, and won't work.
3. You'll have a non-standard configuration. Will Future You remember, every time? What about Replacement You or Assistant You?
4. There are tools (etckeeper, tar, ...) to help.

And finally, it's Against the Rules (violates the standard) !

See the Filesystem Hierarcy Standard at https://refspecs.linuxfoundation.org/fhs.shtml, or read man hier.

It explains where things go.

Answer 2

If you have your home directory within the root filesystem, it might work. Mostly. With some pretty important caveats.

Some security-sensitive files, like /etc/sudoers, may become ineffective if replaced with a symbolic link. This is because the subsystem or tool that uses the file will specifically verify the actual path of the file. If it finds a symbolic link, it will typically assume that some kind of security exploit attempt is in progress, and will usually completely ignore the contents of the symlinked file and fall back to defaults or just reject everything, just to err on the safe (secure) side.

But if you have /home as a separate filesystem (which is generally the recommended way), then consider what will happen at boot time, when /home is not yet mounted. Each of those "snatched" files will be unreadable (because of a broken symlink) until the boot has proceeded to the point where /home is mounted. If any of the earlier steps of the boot process requires those files, that step will most likely fail.

An extreme example would be if you "snatched" /etc/fstab: with the /home filesystem not yet mounted, the system would be unable to read /etc/fstab, and so would have no clue that it will need to mount a particular filesystem to /home. The system would start with only the root filesystem mounted, and any services that depend on /home being available might fail.

Answer 3

If the files you're modifying are considered "configuration files" by your package management system so they won't get overwritten then what you're proposing might work under certain circumstances.

For example if your home directory is NFS mounted then you should expect failure 'cos /etc/hosts won't resolve and the NFS mount might fail. Even if you use IP addresses in fstab there's likely to be a dependency issue where things break.

And if your home directory isn't NFS then you've got the "keep in sync" problem to deal with.

A better solution might be to use a configuration management system, such as ansible, where you can apply a "playbook" (or script, or whatever) to all your machines. So instead of modifying /etc/hosts directly you modify the playbook config and then apply that to all your machines.

Or have a local "/etc/myconfig" type directory and rsync from an authoritative source the contents (similar to the config solution but less structured).

Answer 4

You need to backup the modified files on /etc. Whether they are in your home or not is orthogonal.

Your backup strategy for etc files could involve having a copy (or original) of those inside your home and getting them included in your (hopefully automated) $HOME backup, as you seem to have planned. But you could as well setup you backup program to also backup /etc as a separate location. You could list the modified files and hold a copy inside your home (while not changing the original to a symlink). You could hold a copy of all files in etc (such as a tar), since they will be small anyway. Another relatively common approach is to have a git repository storing the contents of /etc.

Other people have already mentioned as potential shortcomings:

• Some specially security conscious programs refusing to follow symlinks
• The package manager failing to respect them. This should not happen as if it's modified, a well-behaved package manager should leave them alone, but I se how that might be a concern. I think it would be more likely that it could end up changed back from a symlink to a regular file under some circumstances where the package considers it is empowered to upgrade them.
• /home being on a separate partition, or even on NFS

I would like to point out another issue, which is that other users are not supposed to access your home. Thus /home/php_nub_qq should only be readable by php_nub_qq itself, and that includes /home/php_nub_qq/snatched.

You may be the only human user of your system, but even in that case there will (probably) be services running under other accounts!

Let's suppose you snatched /etc/resolv.conf (replacing it with a symlink to /home/php_nub_qq/snatched/resolv.conf) because you configured it with your preferred nameservers. Everything will probably work for php_nub_qq, and also for root. But you will find that freshclam (the updater of the ClamAV database) is unable to fresh new packages, as it runs under a separate account and won't be able to read resolv.conf. Even the package manager may be (trying to) dropping privileges to a limited user for download and facing issues.

You could grant everyone read access to /home/php_nub_qq but (1) it kinda misses the point, as other accounts should not need access there, your snatched approach had artificially added it, and (2) there may still be errors due to AppArmor, snap, etc. blocking access to /home in their profiles (/etc would be allowed, but your changes deviated from the defaults enough that some programs might no longer work out of the box).

You could make it work, eventually, with enough tweaks, but it's not worth the effort. It is much easier to use a slightly different approach, from having your snatched folder hold copies (a cron can ensure it is kept up to date), which would be the most similar to your original idea, to the others mentioned.

/etc holds configuration global to the machine, and it is no error that it is a separate directory, while per user configuration goes to ~/.config (plus still too many dotfiles for programs not following the XDG Base Directory Specification). Do note that, when the target is a user program, in many cases it is possible to override a global /etc configuration inside the $HOME of the local user, even if not always properly documented (e.g. you can use ~/.config/git/config instead of /etc/gitconfig)

Do remember that in addition to your home and /etc there are also other pieces of data stored elsewhere you will probably need to backup, such as the list of installed packages, the user crontab or even the mail spool.

Finally, let me congratulate you for preparing for a scenario where you may need to configure a new system. Those coming here from HNQ, how many of you would be able to quickly go back from your backups (you do have recent backups, right?) to a working system configured as you like, if the hard disk of your primary workstation crashed tomorrow?

Answer 5

Others have said emphatically that this is a bad idea – they're right – and there will be reasons beyond the ones folk have thought of.

To be more positive, here's what I do to head towards this perfectly reasonable goal.

1. Learn to love the defaults. They're defaults because someone who cared thought carefully about them and decided they were best. I actively resist being too quick to second guess that person, because over the decades and multiple machines, I've learned that's the lowest friction way. I use a fairly large variety of machines during the work-day, some much less personalised than others, and my being OK with defaults, or with a minimally configured vi, means that this doesn't have to be a hassle.

2. Put personal dot-files – the ~/.* rc files – in a repository, and clone them to your new machine. My ~/.zshrc and ~/.bashrc files (I have a preference, but I'm deliberately not too fussed about which one I use on a particular machine) consist of setting a few environment variables and then source $HOME/checkouts/.../bashrc, where the bashrc file is conditionalised to match the shell that's actually being used. My init.el, at 900+ lines, is way bigger than it should be, but a lot of it is long-redundant cruft from the decades when I was less rigorous about point 1, and it could probably be halved in size without me noticing.

3. For a subset of things where my fingers cannot remember the defaults, I have a string which I can paste into a remote shell, which does unalias -a, and defines a couple of functions and environment variables.

4. I have a text checklist of configuration adjustments that I actually, genuinely, bearing in mind point 1, do positively want to adjust on a new box.

5. One of the other answers mentioned Nix. Nixpkgs is great.

6. If you're genuinely doing this on a lot of machines (...really?! OK...), then Ansible might be worth investigating.

7. Focusing instead on whole-system configurations rather than shell ones, I do put the contents of /etc into version control, and make a point of committing the result of any local changes. That doesn't help with replicating anything on another machine (don't even think about copying that to another box!), but it does let me see what I've changed on a particular machine, along with a note of when and why.