[SOLVED] Keep configs when updating

Wed · 03-11-2016, 03:58 AM

Every time I update with slackpkg, I am offered to update one, some, or many of my config files.

While I like those configs to get updated, there are lots of values that I want to keep.

I do not want to have my ntp servers erased.
I do want to have modules enabled in httpd.conf
I want to keep my v-host entries in httpd-vhosts.conf
and so on.

Is there something I have missed reading about maintenance?

willysr · 03-11-2016, 04:17 AM

You can choose to keep the old config during upgrading using slackpkg

Wed · 03-11-2016, 04:49 AM

I should have been more complete in my original post.

I do make my choices after updates as I see fit. On some machines, it is easy to just (k)eep some files and (o)verwrite others. On servers I want to keep most of the things and occasionally (m)erge, just to make sure I don't lose an important update.

But I have to say that while merging, the lines are often cut off and won't let me see the crucial bit. So choosing left or right is a bit of a tossup. With several machines, this soon become tedious.

I don't remember if it has happened to me before, but stepping through a very long config file and keeping alert all the way, is a great challenge. Come the end and you just entered "overwrite" or something. Well, maybe it needs something more than just enter ... I try my best to not get to that situation.

ntp.conf is a simple one to always just keep. And short as well. But always popping up. PHP and httpd though, while only occasionally begging for attention, are longer and more important to get right (yes I keep backups).

I'd like to see manually changed values to be persistent, while other things matters less and can be summarily updated. Some files should just stay edited and shut up. I believe OpenBSD handles this part brilliantly.

ponce · 03-11-2016, 04:53 AM

slackpkg asks you also if you want to see a diff between the old and the new files so that you can evaluate what changes in the defaults: sometimes new values are preferred/mandatory so you should watch the diffs carefully.
it's up to you then, as the system administrator of your installation, the decision on overwriting them, throwing away the new ones or porting your modification to the new files: there's no general best practice between the three choices, it depends on the various softwares and on the specific update.
if the paged diff is not comfortable to read because too long you can also keep the old and new files and diff them manually later.

Wed · 03-11-2016, 05:03 AM

Yes, I do look at diff as well. And then remember important differences. I respect the work I have to put in as the admin of my own systems.

I just had to ask if I was the only one to deal with all the tediousness of the repeated tasks, or if I missed something fundamental in system administration.

GazL · 03-11-2016, 05:21 AM

The first rule of Lazy System Administrator Club is: Script the tedious stuff!

Code:

cd ${ROOT:-/} || exit 1

while read file
do
  case "$file" in
    etc/passwd.new|etc/group.new|etc/shadow.new|etc/gshadow.new)
      # System password/group files
      echo "New password/group files will need handling manually!"
      ;;
    etc/hosts.new|etc/HOSTNAME.new)
      echo "removing: $file"
      rm "$file"
      ;;
    etc/httpd/httpd.new)
      echo "Saving: $file"
      mv "$file" "${file%.new}.slackware"
      ;;
    *.new)
      # Catch-all
      echo "Applying: $file"
      mv "$file" "${file%.new}"
      ;;
  esac
done < <( find etc -name "*.new" )

That's just a quick and dirty, but you get the point. Some .new files you care about, and some you don't. Whenever you change a config file, decide how you'd like .new versions to be handled and modify the case statement accordingly.

Personally, I find the Apache package replacing my /srv/httpd with a symlink far more annoying than any of the .new files.

Wed · 03-11-2016, 05:28 AM

Quote:

Originally Posted by GazL

The first rule of Lazy System Administrator Club is: Script the tedious stuff!

Touché

As solved as it gets.

allend · 03-11-2016, 05:36 AM

For me, vimdiff is my friend when dealing with .new config files.
For any that contain custom configurations or that I want to inspect more closely, I choose the Keep option in slackpkg, then run vimdiff on the original and new files to bring them into line. I often find myself running 'slackpkg new-config' multiple times to then update the config files and/or get the next filename that I want to process.

Wed · 03-11-2016, 05:40 AM

For me, anything beginning with, or containing "vi" is a LOT more problematic than keeping on my toes merging new configs. But that's me.

At least my initial question is answered. And I am contemplating scripting or tools that can help me.

blancamolinos · 03-11-2016, 05:55 AM

Wed, if slackpkg does not what you want, forget about it. All it does slackpkg you can do with upgradepkg. The rest is up to you. This is the slack way of doing things (and for this reason slackware is great, because you can do almost anything you want without relying on automatic tools that can never cover all possible needs).

allend · 03-11-2016, 06:13 AM

Quote:

For me, anything beginning with, or containing "vi" is a LOT more problematic than keeping on my toes merging new configs.

That was me. I wasted a lot of time fighting against vi.
My advice is to learn to love 'vi/m'. So many basic tasks are easier and less error prone when you use the right tool e.g. vigr, vipw, visudo, 'crontab -e'.

sysfce2 · 03-11-2016, 09:48 AM

I hate console based diffs so I use Kompare to look at them.

Here is the script I use: I call it newconfig and put it in /usr/local/bin (with root write properties). Use "kdesu newconfig" to run it.

Code:

#!/usr/bin/bash
if [[ $(id -u) -eq 0 ]]; then
	(cd /etc; find -type f -name "*.new" -printf '%P\0' | while IFS= read -r -d '' filename; do
		kompare "$filename" "${filename%\.new}";
		kdialog --yesno "Do you want to delete \"$filename\"?" --yes-label Keep --no-label Delete;
		if [ $? = 1 ]; then
			rm "$filename";
		fi
	done)
else
	echo "Please run using kdesu!";
fi

bassmadrigal · 03-12-2016, 07:23 AM

Quote:

Originally Posted by allend

That was me. I wasted a lot of time fighting against vi.
My advice is to learn to love 'vi/m'. So many basic tasks are easier and less error prone when you use the right tool e.g. vigr, vipw, visudo, 'crontab -e'.

I totally intend to someday relearn vi/m (I learned it almost 20 years ago and then subsequently forgot just about all of it except for switching to input and exiting with or without saving), but I just don't want to devote the time and frustration right now. I've simply solved that by setting the EDITOR/VISUAL environment variables to pico in /etc/profile/ (this is my home system, so other users won't run into issues -- if this was a production machine at the office with multiple sysadmins, I'd have to do something different). Now, vigr, vipw, visudo, 'crontab -e' all open pico

allend · 03-12-2016, 08:57 AM

Quote:

I've simply solved that by setting the EDITOR/VISUAL environment variables to pico in /etc/profile/

I used to do that too, until I get frustrated with dealing with long lines that were being broken and not having a comparison display.
In the context of this thread, when using vimdiff, you only need to learn three extra vim commands:
do for diff obtain
dp for diff put
Ctrl-w w for switch windows (Ctrl-w Ctrl-w does the same)

Quote:

I hate console based diffs so I use Kompare to look at them.

Sorry, not for me. I always do my upgrades from run level 3. I have had problems when upgrading X in run level 4.

Wiser Slacker · 03-12-2016, 11:22 PM

Hi,

one may copy it's own "old" configs somewhere below "/root/" as i do ...
then you could use meld - give it a try

i am old and (google translate "... faul und bequem" -> "lazy and comfortable") so i use somethink helpful ...
Slacker