Thanks to the advice I got from "stretch vs jessie" thread I decided to
do a clean install on a new (larger) microSD card. That leaves the old
filesystem unmolested and usable as a backup.
Are there any tools akin to Apple's Migration Assistant to automate,
or at least assist, the process of configuring the new system to
replace the old one? IIRC some things, like setting up the printer,
were fairly tedious.
Thanks for reading, and any ideas.
On Thu, 29 Mar 2018 18:41:58 +0000 (UTC),
bob prohaska , > Thanks to the advice I got from "stretch vs jessie" thread I decided to
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
Consulting Minister for Consultants, DNRC
I can please only one person per day. Today is not your day. Tomorrow
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
To my surprise, I looked in /usr/local/etc and found it empty. Thank you
for the warning!
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.