Migrating user files to a fresh install

Well, you can probably replace the new system's /etc/cups directory with the old one, which contains your printer setup. I would just oopy /etc to somewhere, then judiciously replace things as needed. You'll need to insure that you have the relevant printer drivers available, if they aren't included by default.

Lately, local configurations are put in files that end with .local so that is some help. At least for some packages. rkhunter does this as "rkhunter.conf.local".

That's the sort of manual configuration I was hoping to avoid, but maybe there's no choice. Replacing directories isn't too bad, but knowing which directories to replace and files to edit is likely to provoke some hair pulling.

To my surprise, I looked in /usr/local/etc and found it empty. Thank you for the warning!

bob prohaska

This is exactly why some of us keep the config files we've edited in one of our user directories, and make a copy of the file each time its modified and working the way we want. Example: supposed I have a host named babel and I've just edited /etc/profile.d/less.sh and like the result, I'll copy it to ~/babel/etc/profile.d/less.sh - this way I not only have a record of my changes but I also know exactly where to put my copy after I've done a clean install and retrieved the /home directory structure from the latest backup.

/usr/local/etc is AFAIK never used by distro packages. Just as you should put programs you write in /usr/local/bin rather than /usr/bin, so you should put their config files, if any, in /usr/local/etc

Similarly, if you download and compile source for a FOSS program you should change its install tools to put the program in /usr/local/bin, any new libraries in /usr/local/lib and its config file(s) in /usr/local/etc because that makes sure that you, if the program should become part of a standard package, your local version can't interfere with the package version and vice versa. Note that I said "change its install tools" because you'll find that all too many FOSS tarballs will try to install stuff in /usr/bin, /usr/lib and /etc There's another useful trick as well: run these two commands as root:

mv /usr/local /home/local ln -s /home/local /usr/local

so that the /usr/local structure is now in /home/local and you've set up a symlink called /usr/local that links to it. Why? Because this means that everything you put in /usr/local is now backed up along with all your stuff in /home *and will survive a clean install* because all you need to do after a clean install and recovering /home from a backup is to run as root:

rm -rf /usr/local ln -s /home/local /usr/local

and all your locally developed and manually installed FOSS stuff will be ready to use immediately.

And another point:

There is one special case for configuration files: its getting more common for utility programs with configurations that are often heavily modified to have a master configuration file that holds the main configuration statements and then references a directory which is where you are expected to put site-specific tweaks instead of editing the master config file.

The iconic example is /etc/profile, which configures the bash shell. You'll probably never need to modify /etc/profile because after its contents have been applied it looks in /etc/profile.d and also applies the contents of all the config files in that directory. In the case of bash, this means setting up environment variables that affect the screen display and modify the behavior of common commandline utilities, e.g. less and tidy.

Its a common pattern: the linked directory is in the same place as the configuration file and shares the same name but with a '.d' suffix. The names of files in the linked directory generally don't matter unless the order they are applied in is important - if this is the case their names usually start with two digits.