2013-11-24

Backup & update of a Strato virtual server

Finally I'm going to upgrade my vserver to CentOS 6, so let's do a full backup to a local disk first.
Strato does a "time machine"-style online backup, which is nice, but I want a fresh start and integrate my old configs piece-by-piece, so while it is nice to work with a safety net, it's not really what I'm looking for.
Apparently you can download system backups via FTP from a dedicated server, but there seems to be no security whatsoever, neither for the account's master password, nor for the actual data. Not on my watch.
So, there is this directory /private-backup on the server with a README.txt in it (the dir is also mentioned in the management web interface somewhere).
Apparently this dir is left alone on system re-installs, so
  • Move any backup files/directories that may lie littered around the filesystem into /private-backup
  • Clean up log files (there was one I had never heard of, which was >2GB)
  • yum clean all
  • Clear temporary directories
  • Become root, chdir into /private-backup, start a screen session (long-running command in a remote session...) and do this

tar --exclude='/private-backup' --one-file-system --sparse -cjvf backup.tar.bz2 /

Next the tarball can be replicated into safety by rsync over ssh (single colon between hostname and path). No need to wait until tar is done, provided you pass -c to rsync which allows continuing in case the transfer exceeds the end of the growing file on the server. Finish up by comparing the md5sum of the replica.

2013-11-01

Troubleshooting gnome's dreaded "Oh no! Something has gone wrong." screen

Since upgrading from Fedora 18 to Fedora 19, my laptop has been haunted by this manifestation whenever I tried to log into a regular gnome 3 session. Fortunately, I could always log in in fallback mode, and sometimes even a regular session or what seemed like a blend of regular gnome and fallback appeared, so there was not too much pressure to sort this out.

Several times I tried googling the error, but to no avail. There is about a gazillion possible things that could cause this screen. There are some log files to look at and and debug switches to throw, but nothing led to a conclusion.

So on the night of halloween I decided to upgrade the machine to Fedora 20 (almost beta at the time) using Fedup, reckoning that this might either cure it or bog things up so badly I'd be forced to reinstall.

Anyhow, after the update the exact same problem prevails, uhg.

So I get the idea that it might be just something to do with user settings, after all, most of the system files have just been replaced and nothing changed.

For starters, I create a dummy user on the machine to see if clean settings would cure the issue.

They do!

So where does gnome keep its settings these days...in ~/.config, alright.
Next I narrow it down to the dconf subdirectory by trial-and-error (moving suspicious files/dirs out at a time).
Just a single file in ~/.config/dconf by the name user, binary junk, probably that's the database of all the dconf stuff.

The first thing I figure out is that I can view it in text format using
dconf dump /
There are some apparent suspects like gnome shell extensions and stuff I tweaked over the years to make the gui useable that I reset back to default and try out by logging into a fallback session, making the change, logging out, attempt log in to regular session, crash, log into fallback, lather, rinse, repeat.

By this method I narrow it down to the /org/gnome/desktop hierarchy, because
dconf reset -f /org/gnome/desktop/
allowed me to log into a regular session with no other changes.
Note that this works only if the trailing slash is included.

But that is no small hierarchy. At this point dconf-editor proves useful as it highlights settings that differ from the default, further narrowing down the suspects.

After some more failed attempts, I finally discover the magic spell:
dconf reset -f /org/gnome/desktop/session/
After finding that needle in the haystack, I'm curious if someone else had the same issue by googling a final time, this time adding session and dconf to the query, and promptly I find this.
Apparently the session-name key in this dconf path pointed to gnome-fallback, which seems to have been a file present in older gnome versions, but no more.
Unless the key is reset to gnome, gnome tries to locate a now non-existing file and bails.
So that halloween story ended on a cheerful note, how unfitting!