facti.net

Backing up is one of the most important things to be done with a computer. Failure will happen, it is only a question of when, and information loss can be quite painful. Unfortunately the amount of information available now makes it more difficult to effectively manage backups and archives.

Even though my main backup medium of choice (external hard drives) is getting cheaper and bigger about as fast as my information growth, the pipe the information must flow through (USB or FireWire, or DVD for archives) is not keeping up. This makes it slower and more laborious to keep backups up-to-date as more information is added.

If you have a good strategy leave me a comment and let me know what it is, I would love to hear about it. My current strategy is to have a current view and a historical view of important data. I don't backup the OS and installed applications since I always ensure I can rebuild the OS and applications from my install media.

Quite a few ebooks are starting to show up as chm (Microsoft help) files. If you don't use Windows as your main platform that can be a nuisance. Luckily there is a nice simple library to convert chm files to html files under Linux: chmlib. Unfortunately the Fedora packages do not include the example binaries needed to convert the files. To convert these files, download the source chmlib package from http://www.jedrea.com/chmlib/ then

tar xvzf chmlib-0.39.tar.gz 
cd chmlib-0.39
./configure --enable-examples
make
sudo make install
cd src/

then

./extract_chmLib <chmfile> <outdir>

where <chmfile> is the name of the chm file and <outdir> is the name of the folder to put the extracted files. Within the extracted files will be a folder that contains all the html files.

Sometimes the failsafes on a system can get in the way of reconstructing things after a boo boo. For example, if you try and re-install a package over itself after accidentally removing a file -- yum won't let you. However it is relatively easy to recover if you know how.

The first step of course is determining which packages may have been damaged. To verify a package use rpm -V, and possibly --nomtime to avoid showing when files were modified, e.g.

rpm -V --nomtime packageName

Where packageName is the name of the package. To verify all packages on your system use something like this:

rpm -qa | xargs -t -n1 -ipName rpm -V --nomtime pName

Or, if you're looking for any damaged packages in a set of related packages you can do something like this:

rpm -qa | grep partOfPackageName | \

xargs -n1 -i pName rpm -V --nomtime pName

Where partOfPackageName is part of the package name.

Installation of the vserver packages is simple in F8:

yum install util-vserver util-vserver-build

However, for anything to actually work you need to build a custom kernel. Once the custom kernel is installed you also need to update the distributions to include F8:

1. cd /usr/lib64/util-vserver/distributions/
2. svn export http://svn.linux-vserver.org/svn/util-vserver/trunk/distrib/f8 f8

Once the distribution is installed you can build the new vserver using the vserver build command, e.g.:

vserver myvserver build -m yum --interface eth0 --interface lo -- -d f8

Where myvserver is the name of your new vserver. Once the build completes you can start your vserver with "vserver myvserver start".

To install additional software packages use vyum:

vyum myvserver -- install packagename

where packagename is the name of the package to install.

Information on getting linux-vserver working on Fedora 8 (F8) seems a bit lacking. While the packages are available (util-vserver), a custom kernel with the appropriate vserver patches must be built or a cryptic "Function not implemented" error will show up when trying to build the vserver guest.

To build the custom kernel, obtain the kernel and corresponding patch from the links provided at the linux-vserver web site. Then bunzip2 and untar the kernel to some appropriate location (I use /usr/src/kernels), e.g.:

1. cd /usr/src/kernels
2. bunzip2 linux-2.6.22.14.tar.bz2
3. tar xvf linux-2.6.22.14.tar
4. cd xvf linux-2.6.22.14
5. patch -p1 ../patch-2.6.22.10-vs2.2.0.5.diff

The patch will give you an initial error, but that can be ignored since it corresponds to a mismatch in the kernel version (...14 vs the expected ...10). Edit the Makefile to change the EXTRAVERSION so it has your own string, I used ".14-vs" to remember it was for vserver.