Sunday, January 18, 2009

Create .deb or .rpm from .tar.gz with checkinstall


tar logoCheckinstall is extremely useful utility to create .deb packages for Debian, Ubuntu (or .rpm packages for Fedora, RedHat, CentOs) from .tar.gz (or .tgz) source tarball after it’s compiled at your Linux box. In other words you can prepare binary package for later usage without need to compile software from sources every time you need to get it installed on certain Linux box.

Another application of checkinstall is software deinstallation that was compiled and installed from sources. As you might already noticed, not every programmer adds “uninstall” rule to Makefile and thus command “make uninstall” would fail. The nice solution is to use checkinstall to prepare binary package from sources and then install or uninstall it with dpkg command (or rpm in RedHat based distributions).

Here is the short algorithm on how to prepare .deb package from clamav source tarball:

1. Install checkinstall:
sudo aptitude -y install checkinstall (Ubuntu, Debian and related distributions)
or
sudo yum install -y checkinstall
(for rpm based distributions, please note that checkinstall usually isn’t included to standard Fedora/RedHat repositories, so you will need to link up third party repo like DAG)
or
compile checkinstall from sources

2. Get clamav sources:
wget http://mesh.dl.sourceforge.net/sourceforge/clamav/clamav-0.81.tar.gz (as an example)

3. Install libraries that might be necessary for clamav compilation:
sudo aptitude install libgmp3 libgmp3-dev
(this command is applicable for Debian and certainly will be different for Fedora or RedHat)

4. Compile clamav:
tar xvfz clamav-0.81.tar.gz
cd clamav-0.81/
./configure --sysconfdir=/etc
make

5. Run checkinstall and follow its intuitive instructions (enter package description etc.):
sudo checkinstall -D make install

6. When finished you’ll get clamav-0.81_0.81-1_i386.deb (or rpm package if you use Fedora/RedHat/CentOs) you may want to install with sudo dpkg -i clamav-0.81_0.81-1_i386.deb (or sudo rpm -i ...) or move to another PC for later installation.

Thursday, January 15, 2009

How To Compile A Kernel - The CentOS Way


Version 1.0
Author: Falko Timme
Last edited 11/23/2006

Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on CentOS systems. It describes how to build a custom kernel using the latest unmodified kernel sources from www.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.

I have tested this on CentOS 4.4.

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Preliminary Note

In this article I will describe two ways of building a kernel for CentOS systems. The first one will get you a kernel rpm package that you can install or share with others. The second way is the same for all Linux distributions, but you don't end up with an rpm package.

2 Building A Kernel rpm Package

This chapter shows how to build a kernel and end up with an rpm package that you can install and share with others.

2.1 Download The Kernel Sources

First we download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.18.3.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.3.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.18.3.tar.bz2
ln -s linux-2.6.18.3 linux
cd /usr/src/linux

2.2 Modify /etc/modprobe.conf

Now we must comment out the mptscsi module in /etc/modprobe.conf because otherwise we will get an error like this:

No module mptscsi found for kernel 2.6.18.3-default, aborting.

when we try to create a ramdisk for our new kernel.

vi /etc/modprobe.conf

alias eth0 pcnet32
alias scsi_hostadapter mptbase
# alias scsi_hostadapter1 mptscsi
alias scsi_hostadapter2 mptfc
alias scsi_hostadapter3 mptspi
alias scsi_hostadapter4 mptsas
alias scsi_hostadapter5 mptscsih

2.3 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn't supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn't made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available...).

Now let's assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn't show errors, you can run the second command which actually applies the patch. Don't do it if the first command shows errors!

If your patches are compressed with gzip (.gz) instead of bzip2 (.bz2), then you patch your kernel as follows:

gunzip -c /usr/src/patch.gz | patch -p1 --dry-run
gunzip -c /usr/src/patch.gz | patch -p1

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.19-rc6, but the full sources haven't been released yet for this kernel. Instead, a patch-2.6.19-rc6.bz2 is available. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or 2.6.18.2 or 2.6.18.3, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.19-rc6 kernel, you must download the 2.6.18 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2) in step 2.1 instead of kernel 2.6.18.3!

This is how you apply the 2.6.19-rc6 patch to kernel 2.6.18:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc6.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.19-rc6.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch-2.6.19-rc6.bz2 | patch -p1

2.4 Configure The Kernel

It's a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make clean && make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. Make sure you specify a kernel version identification string under General Setup ---> () Local version - append to kernel release. I use -default so our kernel rpm package will be named kernel-2.6.18.3default-1.i386.rpm. You can leave the string empty or specify a different one which helps you identify the kernel (e.g. -custom or whatever you like).

Please note: After you have installed kernel-2.6.18.3default-1.i386.rpm and decide to compile another 2.6.18.3 kernel rpm package, it is important to use a different version string, e.g. -default1, -default2, etc., because otherwise you can't install your new kernel because rpm complains that kernel-2.6.18.3default-1.i386.rpm is already installed!

When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

2.5 Build The Kernel

To build the kernel, simply execute this command:

make rpm

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed.

2.6 Install The New Kernel

After the successful kernel build, a src.rpm and an rpm package have been created. The src.rpm package can be found in the /usr/src/redhat/SRPMS/ directory, you can find out about its name by running

ls -l /usr/src/redhat/SRPMS/

On my system it was called kernel-2.6.18.3default-1.src.rpm.

The rpm package can be found in /usr/src/redhat/RPMS/i386/, /usr/src/redhat/RPMS/i586/, /usr/src/redhat/RPMS/i686/, /usr/src/redhat/RPMS/x86_64/, etc., depending on your architecture. On my system it was located in /usr/src/redhat/RPMS/i386/, and by running

ls -l /usr/src/redhat/RPMS/i386/

I found out that its name was kernel-2.6.18.3default-1.i386.rpm.

Now we can install our kernel rpm package like this:

cd /usr/src/redhat/RPMS/i386/
rpm -ivh --nodeps kernel-2.6.18.3default-1.i386.rpm

Please note the --nodeps switch: if you don't use it, you will see an error like this:

error: Failed dependencies:
kernel >= 2.6.10 conflicts with lksctp-tools-1.0.2-6.4E.1.i386

I found that ignoring this dependency didn't cause any problems on my system.

You can now even transfer the kernel rpm package to other CentOS systems and install it there exactly the same way, which means you don't have to compile the kernel there again.

Next we create a ramdisk for our new kernel, because otherwise the system will most likely not boot our new kernel:

mkinitrd /boot/initrd-2.6.18.3-default.img 2.6.18.3-default

2.7 Configure The GRUB Boot Loader

Now we must configure our GRUB boot loader so that our new kernels gets booted when we restart the system.

Run

ls -l /boot

to find out about your new kernel (typically begins with vmlinuz, e.g. vmlinuz-2.6.18.3-default) and ramdisk (typically begins with initrd, e.g. initrd-2.6.18.3-default.img).

Then edit /boot/grub/menu.lst. Have a look at your existing (working) kernel stanzas there and take one of them as a sample for your new stanza and replace the kernel and ramdisk, then add the stanza above all other stanzas.

vi /boot/grub/menu.lst

For example, my menu.lst looks like this before I add the new stanza:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.9-42.0.3.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.0.3.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.0.3.EL.img
title CentOS-4 i386 (2.6.9-42.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.EL.img

and like this afterwards:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18.3-default)
root (hd0,0)
kernel /vmlinuz-2.6.18.3-default ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18.3-default.img
title CentOS (2.6.9-42.0.3.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.0.3.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.0.3.EL.img
title CentOS-4 i386 (2.6.9-42.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.EL.img

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it's really using your new kernel by running

uname -r

This should display something like

2.6.18.3-default

If the system doesn't start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don't forget to remove the stanza of the not-working kernel from /boot/grub/menu.lst.

3 Building A Kernel The Traditional Way

This chapter describes a different approach that can be used on any Linux system. As there's nothing CentOS-specific in this, of course you will not end up with a kernel rpm package.

3.1 Download The Kernel Sources

We download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.18.3.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.3.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.18.3.tar.bz2
ln -s linux-2.6.18.3 linux
cd /usr/src/linux

3.2 Modify /etc/modprobe.conf

Now we must comment out the mptscsi module in /etc/modprobe.conf because otherwise we will get a warning like this:

WARNING: No module mptscsi found for kernel 2.6.18.3, continuing anyway

when we build our new kernel.

vi /etc/modprobe.conf

alias eth0 pcnet32
alias scsi_hostadapter mptbase
# alias scsi_hostadapter1 mptscsi
alias scsi_hostadapter2 mptfc
alias scsi_hostadapter3 mptspi
alias scsi_hostadapter4 mptsas
alias scsi_hostadapter5 mptscsih

3.3 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn't supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn't made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available...).

Now let's assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn't show errors, you can run the second command which actually applies the patch. Don't do it if the first command shows errors!

If your patches are compressed with gzip (.gz) instead of bzip2 (.bz2), then you patch your kernel as follows:

gunzip -c /usr/src/patch.gz | patch -p1 --dry-run
gunzip -c /usr/src/patch.gz | patch -p1

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.19-rc6, but the full sources haven't been released yet for this kernel. Instead, a patch-2.6.19-rc6.bz2 is available. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or 2.6.18.2 or 2.6.18.3, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.19-rc6 kernel, you must download the 2.6.18 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2) in step 3.1 instead of kernel 2.6.18.3!

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc6.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.19-rc6.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch-2.6.19-rc6.bz2 | patch -p1

3.4 Configure The Kernel

It's a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make clean && make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

3.5 Build And Install The Kernel

To build and install the kernel, execute these three commands:

make all
make modules_install
make install

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed. The last command will also automatically create a ramdisk for you as well as configure /boot/grub/menu.lst.

Now edit /boot/grub/menu.lst. You should find a stanza for your new kernel at the top of the list, but to make sure that the new kernel gets booted instead of your old one, you must set the value of default to 0.

vi /boot/grub/menu.lst

My menu.lst looks like this:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18.3)
root (hd0,0)
kernel /vmlinuz-2.6.18.3 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18.3.img
title CentOS (2.6.9-42.0.3.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.0.3.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.0.3.EL.img
title CentOS-4 i386 (2.6.9-42.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.9-42.EL.img

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it's really using your new kernel by running

uname -r

This should display something like

2.6.18.3

If the system doesn't start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don't forget to remove the stanza of the not-working kernel from /boot/grub/menu.lst.

4 Links

How To Compile A Kernel - The Fedora Way


Version 1.0
Author: Falko Timme
Last edited 11/10/2006

Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on Fedora systems. It describes how to build a custom kernel using the latest unmodified kernel sources from www.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.

I have tested this on Fedora Core 6.

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Preliminary Note

In this article I will describe two ways of building a kernel for Fedora systems. The first one is Fedora-specific, and in the end you will have a kernel rpm package that you can install or share with others. The second way is the same for all Linux distributions, but you don't end up with an rpm package.

I prefer to do all the steps here as the root user. However, it's possible to run most commands as a non-privileged user (e.g. user tom). Some commands such as yum or rpm still require root privileges, so you should add tom (or whatever your username is) to /etc/sudoers by running

visudo

Add this line:

tom  ALL=(ALL) ALL

Now whenever you run a command that requires root privileges, such as

yum install fedora-rpmdevtools unifdef

the command will tell you so, and you must run

sudo yum install fedora-rpmdevtools unifdef

instead. Remember: you can forget about sudo if you run all commands as root. It's up to you which way you prefer.

2 Building A Kernel rpm Package

This chapter shows how to build a kernel and end up with an rpm package that you can install and share with others.

2.1 Create Your rpmbuild Directory

Create your rpmbuild directory as follows:

cd ~
cp -a /usr/src/redhat/ rpmbuild
echo '%_topdir %(echo $HOME)/rpmbuild' >> .rpmmacros

Then install the required packages for building rpm packages

yum install fedora-rpmdevtools unifdef

and run

fedora-buildrpmtree

2.2 Download And Install A Fedora Kernel src.rpm

Next we download the latest kernel src.rpm for our Fedora version. For Fedora Core 6, the src.rpm packages are located in http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/, for Fedora Core 5 it's http://download.fedora.redhat.com/pub/fedora/linux/core/5/source/SRPMS/, and so on.

The latest Fedora Core 6 kernel src.rpm is kernel-2.6.18-1.2798.fc6.src.rpm, so we download and install it now:

cd /usr/src
wget http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/kernel-2.6.18-1.2798.fc6.src.rpm
rpm -ivh kernel-2.6.18-1.2798.fc6.src.rpm

If you see these warnings:

warning: user brewbuilder does not exist - using root
warning: group brewbuilder does not exist - using root

you can ignore them.

We have just installed the kernel sources for the 2.6.18 kernel together with lots of Fedora patches and a patch for kernel 2.6.18.1, so if we continued to build a kernel from this src.rpm we'd end up with kernel 2.6.18.1.

2.3 Patch The Kernel

Instead of kernel 2.6.18.1 I want to install kernel 2.6.18.2. The src.rpm we installed came with kernel 2.6.18 plus a patch for kernel 2.6.18.1. We will now replace that patch with the patch for kernel 2.6.18.2.

cd ~/rpmbuild/SOURCES/
wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.18.2.bz2

You could also use the http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc5.bz2 prepatch if you want to end up with kernel 2.6.19-rc5. Please note that this works only for prepatches, i.e. patches for kernels that aren't available in a final version yet, such as the 2.6.19 kernel. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or 2.6.18.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

Now we must modify the kernel-2.6.spec file so that it knows about our new kernel patch:

cd ~/rpmbuild/SPECS/

vi kernel-2.6.spec

Search for the line

Patch1: patch-2.6.18.1.bz2

and replace it with this one:

Patch1: patch-2.6.18.2.bz2

(or whatever patch you downloaded before).

Then run

rpmbuild -bp kernel-2.6.spec

(If you want to build the kernel for a specific architecture such as i386, i586, i686, or x86_64, you can do it like this:

rpmbuild -bp --target=i686 kernel-2.6.spec

I don't specify it in this example and end up with a i386 kernel here. Your system might build a kernel for a different architecture instead if you don't specify it, so keep this in mind when you follow this tutorial.)

Now comes the tricky part. The src.rpm comes with a lot of Fedora-specific patches. Some of them don't work with our 2.6.18.2 patch, so if you see something like this in the rpmbuild output:

+ echo 'Patch #300 (linux-2.6-ppc-dac960-ipr-clash.patch):'
Patch #300 (linux-2.6-ppc-dac960-ipr-clash.patch):
+ patch -p1 -s
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
1 out of 1 hunk ignored -- saving rejects to file drivers/block/DAC960.c.rej
error: Bad exit status from /var/tmp/rpm-tmp.46287 (%prep)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.46287 (%prep)

you must edit kernel-2.6.spec again and comment out the patch #300:

vi kernel-2.6.spec

[...]
#Patch300: linux-2.6-ppc-dac960-ipr-clash.patch
[...]
#%patch300 -p1
[...]

Then run your rpmbuild command again, e.g.

rpmbuild -bp kernel-2.6.spec

You must repeat this over and over until there are no more patches that fail to be applied.

2.4 Specify A Kernel Identification String

Now we should specify a string that allows us to identify our kernel later on. Therefore we do this:

cd ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.i386
vi Makefile

In the EXTRAVERSION line, you can put the kernel identification. I think it's good to append the kernel version to that string, so something like this is ok:

EXTRAVERSION = -custom-2.6.18.2

2.5 Configure The Kernel

Now we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

2.6 Build The Kernel

Now we build our kernel rpm package by simply running

make rpm

Afterwards you will find a new src.rpm package in the ~/rpmbuild/SRPMS/ directory, e.g. ~/rpmbuild/SRPMS/kernel-2.6.18custom2.6.18.2-1.src.rpm, and the kernel rpm package in ~/rpmbuild/RPMS/i386/ (or ~/rpmbuild/RPMS/i586/, ~/rpmbuild/RPMS/i686/, etc. depending on your architecture), e.g. ~/rpmbuild/RPMS/i386/kernel-2.6.18custom2.6.18.2-1.i386.rpm. As you see your kernel identification has been added to the package name.

2.7 Install The New Kernel

Now go the directory where your new kernel rpm package has been created (depending on your architecture, e.g. ~/rpmbuild/RPMS/i386/), and install the rpm package:

cd ~/rpmbuild/RPMS/i386
rpm -ivh kernel-2.6.18custom2.6.18.2-1.i386.rpm

(You can now even transfer the rpm package to other Fedora systems and install them there exactly the same way, which means you don't have to compile the kernel there again.)

Next we create a ramdisk for our new kernel, because otherwise the system will most likely not boot our new kernel:

mkinitrd /boot/initrd-2.6.18-custom-2.6.18.2.img 2.6.18-custom-2.6.18.2

Then edit /boot/grub/menu.lst. Have a look at your existing (working) kernel stanzas there and take one of them as a sample for your new stanza and replace the kernel and ramdisk, then add the stanza above all other stanzas.

vi /boot/grub/menu.lst

For example, my menu.lst looks like this before I add the new stanza:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

and like this afterwards:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18-custom-2.6.18.2)
root (hd0,0)
kernel /vmlinuz-2.6.18-custom-2.6.18.2 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-custom-2.6.18.2.img

title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

(You can find out about the right vmlinuz and initrd files by running

ls -l /boot

)

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it's really using your new kernel by running

uname -r

This should display something like

2.6.18-custom-2.6.18.2

If the system doesn't start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don't forget to remove the stanza of the not-working kernel from /boot/grub/menu.lst.

3 Building A Kernel The Traditional Way

This chapter describes a different approach that can be used on any Linux system. As there's nothing Fedora-specific in this, of course you will not end up with a kernel rpm package.

3.1 Download The Kernel Sources

We download our desired kernel to /usr/src. Go to www.kernel.org and select the kernel you want to install, e.g. linux-2.6.18.2.tar.bz2 (you can find all 2.6 kernels here: http://www.kernel.org/pub/linux/kernel/v2.6/). Then you can download it to /usr/src like this:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.2.tar.bz2

Then we unpack the kernel sources and create a symlink linux to the kernel sources directory:

tar xjf linux-2.6.18.2.tar.bz2
ln -s linux-2.6.18.2 linux
cd /usr/src/linux

3.2 Apply Patches To The Kernel Sources (Optional)

Sometimes you need drivers for hardware that isn't supported by the new kernel by default, or you need support for virtualization techniques or some other bleeding-edge technology that hasn't made it to the kernel yet. In all these cases you have to patch the kernel sources (provided there is a patch available...).

Now let's assume you have downloaded the needed patch (I call it patch.bz2 in this example) to /usr/src. This is how you apply it to your kernel sources (you must still be in the /usr/src/linux directory):

bzip2 -dc /usr/src/patch.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is just a test, it does nothing to your sources. If it doesn't show errors, you can run the second command which actually applies the patch. Don't do it if the first command shows errors!

You can also apply kernel prepatches to your kernel sources. For example, if you need a feature that is available only in kernel 2.6.19-rc5, but the full sources haven't been released yet for this kernel. Instead, a patch-2.6.19-rc5.bz2 is available. You can apply that patch to the 2.6.18 kernel sources, but not to kernel 2.6.18.1 or 2.6.18.2, etc. This is explained on http://kernel.org/patchtypes/pre.html:

Prepatches are the equivalent to alpha releases for Linux; they live in the testing directories in the archives. They should be applied using the patch(1) utility to the source code of the previous full release with a 3-part version number (for example, the 2.6.12-rc4 prepatch should be applied to the 2.6.11 kernel sources, not, for example, 2.6.11.10.)

So if you want to compile a 2.6.19-rc5 kernel, you must download the 2.6.18 kernel sources (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2) in step 3.1 instead of kernel 2.6.18.2!

This is how you apply the 2.6.19-rc5 patch to kernel 2.6.18:

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19-rc5.bz2
cd /usr/src/linux
bzip2 -dc /usr/src/patch-2.6.19-rc5.bz2 | patch -p1 --dry-run
bzip2 -dc /usr/src/patch-2.6.19-rc5.bz2 | patch -p1

3.3 Configure The Kernel

It's a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:

make mrproper
cp /boot/config-`uname -r` ./.config

Then we run

make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file:

Then browse through the kernel configuration menu and make your choices. When you are finished and select Exit, answer the following question (Do you wish to save your new kernel configuration?) with Yes:

3.4 Build And Install The Kernel

To build and install the kernel, execute these three commands:

make all
make modules_install
make install

Now be patient, the kernel compilation can take some hours, depending on your kernel configuration and your processor speed. The last command will also automatically create a ramdisk for you as well as configure /boot/grub/menu.lst.

Now edit /boot/grub/menu.lst. You should find a stanza for your new kernel at the top of the list, but to make sure that the new kernel gets booted instead of your old one, you must set the value of default to 0.

vi /boot/grub/menu.lst

My menu.lst looks like this:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.18.2)
root (hd0,0)
kernel /vmlinuz-2.6.18.2 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18.2.img

title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

Now reboot the system:

shutdown -r now

If everything goes well, it should come up with the new kernel. You can check if it's really using your new kernel by running

uname -r

This should display something like

2.6.18.2

If the system doesn't start, restart it, and when you see this:

press any key to enter the GRUB menu:

Select your old kernel and start the system. You can now try again to compile a working kernel. Don't forget to remove the stanza of the not-working kernel from /boot/grub/menu.lst.

Sunday, January 11, 2009

Set Up Virus and Spam Scanning on Ubuntu 8.10

Set Up Virus and Spam Scanning on Ubuntu 8.10

Install of Amavisd-New on Ubuntu 8.10

One of the most frustrating problems with setting up any mail server is the configuration required for anti-virus protection and Spam checking. Amavisd-new provides an excellent tool to help in setting that up. This is a step-by-step process in providing your mail server, the example is Ubuntu 8.10, with the ability to scan all incoming mail for viruses and Spam.

apt-get install amavisd-new

Starting Amavisd-New
In order to get amavisd-new running, execute the command below to view content in debug mode so you can see what it is doing. One thing you will notice is that by default there is no virus program attached nor any scanning for Spam as it is disabled by default. The point to note here is the modules that it is using, the ports, and the general look and fell of the program.

/etc/init.d/amavis debug
Trying to run amavisd-new in debug mode…

Jan 9 12:46:47.927 nag.example.com /usr/sbin/amavisd-new[4384]: starting. /usr/sbin/amavisd-new at nag.example.com amavisd-new-2.6.1 (20080629), Unicode aware, LANG=”en_US.UTF-8″
Jan 9 12:46:47.928 nag.example.com /usr/sbin/amavisd-new[4384]: user=, EUID: 112 (112); group=, EGID: 123 123 (123 123)
Jan 9 12:46:47.928 nag.example.com /usr/sbin/amavisd-new[4384]: Perl version 5.010000
Jan 9 12:46:47.980 nag.example.com /usr/sbin/amavisd-new[4384]: INFO: no optional modules: IO::Socket::INET6
Jan 9 12:46:47.982 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: 2009/01/09-12:46:47 Amavis (type Net::Server::PreForkSimple) starting! pid(4384)
Jan 9 12:46:47.987 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: Binding to UNIX socket file /var/lib/amavis/amavisd.sock using SOCK_STREAM
Jan 9 12:46:47.988 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: Binding to TCP port 10024 on host 127.0.0.1
Jan 9 12:46:47.989 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: Group Not Defined. Defaulting to EGID ‘123 123′
Jan 9 12:46:47.989 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: User Not Defined. Defaulting to EUID ‘112′
Jan 9 12:46:47.989 nag.example.com /usr/sbin/amavisd-new[4384]: Net::Server: Setting up serialization via flock
Jan 9 12:46:47.990 nag.example.com /usr/sbin/amavisd-new[4384]: after_chroot_init: EUID: 112 (112); EGID: 123 123 (123 123)
Jan 9 12:46:47.990 nag.example.com /usr/sbin/amavisd-new[4384]: config files read: /usr/share/amavis/conf.d/10-debian_scripts, /usr/share/amavis/conf.d/20-package, /etc/amavis/conf.d/01-debian, /etc/amavis/conf.d/05-domain_id, for .tar tried: pax
Jan 9 12:46:48.037 nag.example.com /usr/sbin/amavisd-new[4384]: Found decoder for .tar at /bin/cpio
Jan 9 12:46:48.038 nag.example.com /usr/sbin/amavisd-new[4384]: Found decoder for .deb at /usr/bin/ar
—cut—

Enable Virus Checks and Spam Checks

Verify that clamav is running .

sudo /etc/init.d/clamav-daemon start

Modify this line in /etc/default/spamassassin

ENABLED=1

It is 0 by default so you must enable Spamassassin to be able to run, now start it.

sudo /etc/init.d/spamassassin start

To enable amavisd-new to work with Spamassassin and clamav you need to modify the /etc/amavis/conf.d/15-content_filter_mode. Uncomment the lines as the root user so they now look like the example and restart amavisd-new in debug mode to view the activity. Now you will see that clamav and Spamassassin are now working with amavisd-new.

15-content_filter_mode

@bypass_virus_checks_maps = (
\%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
\%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

Jan 9 12:54:47.978 nag.example.com /usr/sbin/amavisd-new[4563]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan
Jan 9 12:54:47.979 nag.example.com /usr/sbin/amavisd-new[4563]: No secondary av scanner: FRISK F-Prot Antivirus
Jan 9 12:54:47.979 nag.example.com /usr/sbin/amavisd-new[4563]: No secondary av scanner: Trend Micro FileScanner
Jan 9 12:54:47.979 nag.example.com /usr/sbin/amavisd-new[4563]: No secondary av scanner: drweb - DrWeb Antivirus
Jan 9 12:54:47.980 nag.example.com /usr/sbin/amavisd-new[4563]: No secondary av scanner: KasperskyLab kavscanner

Jan 9 12:54:48.003 nag.example.com /usr/sbin/amavisd-new[4563]: SpamControl: initializing Mail::SpamAssassin
Jan 9 12:54:48.004 nag.example.com /usr/sbin/amavisd-new[4563]: SpamAssassin debug facilities: info
Jan 9 12:54:49.559 nag.example.com /usr/sbin/amavisd-new[4563]: SpamControl: init_pre_fork on SpamAssassin done

Jan 9 12:54:49.576 nag.example.com /usr/sbin/amavisd-new[4573]: SpamControl: init_child on SpamAssassin done

Finish the Amavisd-New Configuration

Create Necessary users and folders as root.
# useradd vscan

# mkdir /var/vscan
# mkdir /var/vscan/tmp
# mkdir /var/vscan/var
# mkdir /var/vscan/db
# mkdir /var/vscan/home
# chown -R vscan:vscan /var/vscan
# chmod -R 750 /var/vscan

Creating a Reinjection Port
The process that you see below shows how mail arrives at the server and is then sent to a content_filter on port 10024, on to the qmgr and then to amavisd-new which then executes the scanning with both Spamassassin and clamav. When the scanning is complete you do not want to send the scanned mail back to port 10024 because you will create a loop. So you need to create a reinjection port so that the mail that has been scanned will be recognized as complete. The reinjection port that is used is port 10025. This section will now show you how to set up those two ports and activate Spamassassin and clamav.

Edit main.cf and Add Content Filter

#Amavisd SetUp
content_filter=amavisd-new:[127.0.0.1]:10024

Edit master.cf and Add Reinjection

amavisd-new unix - - n - 2 smtp
-o smtp_data_done_timeout=1200s
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes

Add clamav to the group amavis

amavis:x:123:clamav

Send an email and watch the system as it runs in debug mode.

sendmail -f mike@example.com tom@example.com

Review File Contents for Amavisd-New
cd /etc/amavis/conf.d

Once you have install amavisd-new you will find a number of files that make up the configuration for amaavisd-new and how it interacts with Spamassassin and clamav. These files, at least the important parts, are listed here with a brief description.

01-debian
These are the various ways of compressing files. Do not modify.

# SETTINGS RARELY MODIFIED BY THE LOCAL ADMIN

$ENV{PATH} = $path = ‘/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin’;
$file = ‘file’;
$gzip = ‘gzip’;
$bzip2 = ‘bzip2′;
$lzop = ‘lzop’;
$rpm2cpio = ['rpm2cpio.pl','rpm2cpio'];
$cabextract = ‘cabextract’;
$uncompress = ['uncompress', 'gzip -d', 'zcat'];
#$unfreeze = ['unfreeze', 'freeze -d', 'melt', 'fcat']; #disabled (non-free, no security support)
$unfreeze = undef;
$arc = ['nomarch', 'arc'];
$unarj = ['arj', 'unarj'];
#$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
$unrar = ['unrar-free'];
$zoo = ‘zoo’;
#$lha = ‘lha’; #disabled (non-free, no security support)
$lha = undef;
$pax = ‘pax’;
$cpio = ‘cpio’;
$ar = ‘ar’;
$ripole = ‘ripole’;
$dspam = ‘dspam’;

1; # ensure a defined return

05-domain_id
# amavisd-new needs to know which email domains are to be considered local
# to the administrative domain. Only emails to “local” domains are subject
# to certain functionality, such as the addition of spam tags.
#
# Default local domains to $mydomain and all subdomains. Remember to
# override or redefine this if $mydomain is changed later in the config
# sequence.

@local_domains_acl = ( “.$mydomain” );

1; # ensure a defined return

05-node_id
If you have problems with your FQDN you can alter that manually here.

# $myhostname is used by amavisd-new for node identification, and it is
# important to get it right (e.g. for ESMTP EHLO, loop detection, and so on).

chomp($myhostname = `hostname –fqdn`);

15-av_scanners
This file holds the information required for amavisd to locate the virus scanners you may have installed on your box.

15-content_filter_mode
This file turns off by default the ability of amavisd-new to scan for virus activity or check for spam.
use strict;

# You can modify this file to re-enable SPAM checking through spamassassin
# and to re-enable antivirus checking.

#
# Default antivirus checking mode
# Uncomment the two lines below to enable it back
#

#@bypass_virus_checks_maps = (
# \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

#
# Default SPAM checking mode
# Uncomment the two lines below to enable it back
#

#@bypass_spam_checks_maps = (
# \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

1; # ensure a defined return

21-ubuntu_defaults
There are settings here that you can modify to determine the action your machine should take when it discovers either a virus email or spam.

use strict;

#
# These are Ubuntu specific defaults for amavisd-new configuration
#
# DOMAIN KEYS IDENTIFIED MAIL (DKIM)
$enable_dkim_verification = 1;
# Don’t be verbose about sending mail:
@whitelist_sender_acl = qw( .$mydomain );
$final_virus_destiny = D_DISCARD; # (defaults to D_BOUNCE)
$final_banned_destiny = D_BOUNCE; # (defaults to D_BOUNCE)
$final_spam_destiny = D_DISCARD; # (defaults to D_REJECT)
$final_bad_header_destiny = D_PASS; # (defaults to D_PASS), D_BOUNCE suggested

$warnbannedsender = 1;
$warnbadhsender = 1;
$virus_admin = undef;
$spam_admin = undef;

25-amavis_helpers
Functionality required for amavis helpers like amavis-release.

30-template_localization
read_l10n_templates(’en_US’, ‘/etc/amavis’);

40-policy_banks

# DKIM signing domain whitelist. The domain to use is the domain after
# d= in the DKIM header.

@author_to_policy_bank_maps = ( {
# ‘friends.example.net’ => ‘WHITELIST,NOBANNEDCHECK’,
# ‘user1@cust.example.net’ => ‘WHITELIST,NOBANNEDCHECK’,
‘.ebay.com’ => ‘WHITELIST’,
‘.ebay.co.uk’ => ‘WHITELIST’,
‘ebay.at’ => ‘WHITELIST’,
‘ebay.ca’ => ‘WHITELIST’,
‘ebay.de’ => ‘WHITELIST’,
‘ebay.fr’ => ‘WHITELIST’,
‘.paypal.co.uk’ => ‘WHITELIST’,
‘.paypal.com’ => ‘WHITELIST’, # author signatures
‘./@paypal.com’ => ‘WHITELIST’, # 3rd-party sign. by paypal.com
‘alert.bankofamerica.com’ => ‘WHITELIST’,
‘amazon.com’ => ‘WHITELIST’,
‘cisco.com’ => ‘WHITELIST’,
‘.cnn.com’ => ‘WHITELIST’,
’skype.net’ => ‘WHITELIST’,
‘welcome.skype.com’ => ‘WHITELIST’,
‘cc.yahoo-inc.com’ => ‘WHITELIST’,
‘cc.yahoo-inc.com/@yahoo-inc.com’ => ‘WHITELIST’,
# ‘google.com’ => ‘MILD_WHITELIST’,
# ‘googlemail.com’ => ‘MILD_WHITELIST’,
# ‘./@googlegroups.com’ => ‘MILD_WHITELIST’,
# ‘./@yahoogroups.com’ => ‘MILD_WHITELIST’,
# ‘./@yahoogroups.co.uk’ => ‘MILD_WHITELIST’,
# ‘./@yahoogroupes.fr’ => ‘MILD_WHITELIST’,
# ‘yousendit.com’ => ‘MILD_WHITELIST’,
# ‘meetup.com’ => ‘MILD_WHITELIST’,
# ‘dailyhoroscope@astrology.com’ => ‘MILD_WHITELIST’,
} );

50-user
# Place your configuration directives here. They will override those in
# earlier files.
#
# See /usr/share/doc/amavisd-new/ for documentation and examples of
# the directives you can use in this file
#


Saturday, January 10, 2009

checking for X... configure: error: Can't find X libraries. Please check your installation and add the correct paths!

checking for X... configure: error: Can't find X libraries. Please check your installation and add the correct paths!

This is about installing the K3B CD/DVD Burning application into a Debian-type desktop (Mepis 8 Lenny).

We are driven into trying to compile from source because the version that arrives from using Synaptic has a bug that always reports a 'Track 1 write error' at the very end of a burn. This bug is not present on K3B in other distros in the PC (Its a multiboot).

So after unpacking the source, and running './configure', it starts checking, ending up with..
Quote:
checking for X... configure: error: Can't find X libraries. Please check your installation and add the correct paths!
Now these paths to libraries, for the use applications, are not at all the same kind of path as in
Code:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games


I searched about,until I found..
Quote:
/usr/share/doc/libx11-6
/usr/share/doc/libx11-data
/usr/share/doc/libx86-1

.. but I have no idea what to do about it.
Right about now, I just feel very ignorant. Maybe someone can help..
==

Libs checked for by "configure" will be searched for first
in /usr/lib/ and the suffix is usually .so which is in
the development package. ( libname = libx11.so )

# 'apt-get install libx11-dev' will do ( or use Synaptic )


You will also need 'libxext-dev' 'zlib1g-dev' 'libpng12-dev'
'libjpeg62-dev' 'libqt3-mt-dev' (11 packages) 'kdelibs4-dev'
(35 packages)
Numbers mentioned are interdependecies installed, when
installing libqt3-mt-dev and kdelibs4-dev.

Optional, if cd / DVD-ripping, encoding etc. is a requirement :
'libdvdread' 'libhal-dev' 'libhal-storage-dev'
'libavcodec-dev' 'libavformat-dev'
'libflac++-dev' 'libmpcdec-dev' 'libtag1-dev'
'libmusicbrainz4-dev'
...... and 2 packages, not in the usual repo ?
'liblame0' 'liblame-dev'
http://debian-multimedia.org/dists/s...e/liblame0.php

'./configure' was run using Debian Lenny.

Wednesday, January 7, 2009

7 Best Free/Open-source Backup Software for Linux



A computer application utilized to perform a complete backup by duplicating the original source of data is called backup software. Obviously, the main purpose of backup software is to create order out of chaos by recovering essential files in the event of a disaster.

If you are using Linux, there are plenty of backup software to choose from. I have here a list of some of the best free and open source backup software that you may want to check out.


Time Vault

Time Vault is a GNOME-based Linux-equivalent to Time Machine from Apple. Like many backup utilities, it creates incremental backups of files that can be restored at a later date. Its snapshots are copies of a directory at a certain point in time. Snapshots use very little space for the files that haven't changed since the last snapshot was made. This is because instead of backing up the entire unchanged file, snapshots use hard links that point to the existing backup of the unchanged file.


Clonezilla
Clonezilla is an open source clone of Symantec Ghost Corporate Edition. It is based on DRBL, Partition Image, ntfsclone, partclone, and udpcast that will allow you to do bare metal backup and recovery. Two types of Clonezilla are available, Clonezilla live and Clonezilla SE (server edition). Clonezilla live is suitable for single machine backup and restore. While Clonezilla SE is for massive deployment, it can clone many computers simultaneously.


Duplicity
Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.


Bacula
Bacula is an open source, enterprise level computer backup system for heterogeneous networks. It is designed to automate tasks that had often required intervention from a systems administrator or computer operator. Bacula supports Linux, UNIX and Windows backup clients, and a range of professional backup devices including tape libraries. Administrators and operators can configure the system via a command line console, GUI or web interface; its back-end is a catalog of information stored by MySQL, PostgreSQL, or SQLite.


AMANDA

AMANDA (Advanced Maryland Automatic Network Disk Archiver) is a backup system that allows the administrator to set up a single master backup server to back up multiple hosts over network to tape drives/changers or disks or optical media. Amanda uses native dump and/or GNU tar facilities and can back up a large number of workstations running multiple versions of Unix.


rsync

rsync is an open source utility that synchronizes files and directories from one location to another while minimizing data transfer using delta encoding when appropriate. An important feature of rsync not found in most similar programs/protocols is that the mirroring takes place with only one transmission in each direction. rsync can copy or display directory contents and copy files, optionally using compression and recursion.


FlyBack

FlyBack is based on rsync and modeled loosely after Apple's Time Machine. Like many rsync-based backup utilities, it creates incremental backups of files which can be restored at a later date. FlyBack presents a chronological view of a file system, allowing individual files or directories to be previewed or retrieved one at a time. FlyBack presents the user with a typical file manager style view of their file system, but with additional controls allowing the user to go forward or backward in time.