Areca: Linux desktop backups made easy

There are some desktop backup tools available for Linux, but most of them are not developed anymore. Areca however is under constant development and also provides a user friendly GUI.

Backups and Linux are a twofold thing: if you have hundreds or thousands of computers backups are not a problem at all: Amanda, Bacula, Restore and others are your friends. Also, if you want to create backups on single machines, there are many tools available: rsync, tar, and many, many more.
However, all these solutions are not suitable for the average user.

In the last years several projects were started to provide user friendly solutions for the backup of Linux desktop machines. A year ago I already reported about SBackup. Also, the Ubuntu team developed the solution TimeVault and last but not least there is flyback which I used for several months to keep a backup of my thesis. But despite their advantages they all suffer from stalled development: all mentioned projects are effectively dead at the moment.

There is only one exception: the little known Areca. This in Java programmed backup solution provides a user friendly GUI and is even suited for desktop users who have a quite complex idea of backup systems.

Despite some current bugs (it chokes on large numbers of files, you have to use several backup rules in such cases) and some shortcomings (the file choose dialog only allows to mark one single file each time) the program has matured over the time and can easily be used in a productive environment. Besides the usual backup/restore it also features statistics, the ability of merging backups, different backup profiles, encryption and other gimmicks. But be sure to quickly read through the documentation so that you understand what backup groups and backup targets are before you start!

The only problem I now have is that it is not packed for Fedora - or any other bigger distribution besides Ubuntu. The download section provides pre-compiled tar.gz packages, however I would prefer a rpm I could automatically fetch with yum.

Short Tip: A simple udev rule for burn rights on /dev/sg*

udev is a very helpful tool to manage your device lists and rights on your Linux machine. With custom rules you can alter your system to do exactly what you want. A simple example which I recently needed is to change the group and the rights of a device. Let’s say you need to have write rights on the device /dev/sg*. These are not given usually under Fedora:

crw-------   1 root     root       21,   0  2. Apr 18:26 sg0
crw-------   1 root     root       21,   1  2. Apr 18:26 sg1

However, programs like Nero’s burning suite for Linux require these. So the best way is to change the group of the devices to disk and afterwards give the group write rights. In udev the best way is to create a custom rule file: /etc/udev/rules.d/55-disk-burning.rules.

# cat /etc/udev/rules.d/55-disk-burning.rules
BUS=="scsi", KERNEL=="sg[0-9]*", GROUP="disk", MODE="0660"

After a reboot the rights are as needed:

crw-rw----   1 root     disk       21,   0  2. Apr 18:26 sg0
crw-rw----   1 root     disk       21,   1  2. Apr 18:26 sg1

Of course this still requires the user to be a member of the disk group…

Short Tip: Mount directories via SSH

Other computers are often accessed via ssh. That is very easy and comes along with a lot of possibilities. However, working on files which are saved on the server is not that simple all the time. KDE offers the fish:// KIO for these cases, but this just works for KDE apps, and has to be called for each app individually.

In such cases it makes more sense to actually mount the server directories locally: sshfs let you mount any given server directory locally. And since it works on top of FUSE it does not require root interaction at all (given that the local user is a member of the fuse group).

All you have to do is:

sshfs -o idmap=user 192.168.0.1:/data ~/sshDir

The idmap=user option translates the server side uid to the client side uid and is therefore an often used and also needed option to avoid permission problems.

Of course the given directories have to exist on the used machines. Also, as already mentioned, make sure that the user who tries to use sshfs is a member of the fuse group! Last but not least the server must have a running ssh server, and the program sshfs has to be installed on the client machine. On Fedora, the package is called fuse-sshfs and is part of the main repositories. I guess it is similar on the other, bigger distributions as well.

Since every sshfs directory is a regular fuse directory, the umount is done via:

fusermount -u ~/sshDir

This can even be embedded into /etc/fstab and also understands typical ssh configuration options like other ports or the very handy key authorization.

NetworkManager enterprise encryption (Eduroam style) works again

NetworkManager was recently updated in Fedora 8. The newest version now works well again with a specific but widely used enterprise encryption method.

One of the major regressions in Fedora 8 was that the new NetworkManager was not working with a specific encryption method used by the European Eduroam (wlan) project. This network uses a certificate based TKIP-TTLS-PAP encryption system to allow or deny access to wireless university networks across Europe and is therefore at home at almost all larger universities in Europe (and Australia, btw.).

The proper solution to handle that situation was to configure wpa_supplicant manually or to run other tools or home-made scripts.

Two days ago, after more than two months, an update of libnl required a rebuild of NetworkManager and libdhcp as well. And with these updates, the login works again without any further problem.

It is not entirely clear why the bug is now fixed but it looks like the libnl package had some serious problems which might have caused the problem. I hope that NetworkManager soon reaches a state were all promised 0.7-features are available - and where I have a KDE gui to configure them

While the issue is solved the bug itself raises some valid questions: If the bug hit all Eduroam users, which are mostly students or academic people which have a high percentage of Linux users, why did so few people care? Is it because most European users don’t use Fedora but Opensuse, Mandriva or Ubuntu which all did not ship that specific NetwokManager version?
Or did the system work for most people and failed only for some odd reason for me and a couple of others? Strange in any case.

Howto: Using newest flash in Konqueror in Fedora

Recent flash plugins didn’t work with newer Konqueror versions. But now the Fedora-KDE team released new KDE packages with support for the newest flash in Konqueror.

For quite some time now the newer flash plugins didn’t work with Konqueror: they required direct Xembed support which was not provided by Konqueror. As a result most Konqueror users sticked to the latest flash plugin that still supported the old-style Window passing. Some newer features were missing, but the rest worked.

However, recently several problems and vulnerabilities were found in the old flash plugin versions - some of them quite serious. As a result the flash plugin had to be updated or deactivated in Konqueror.

In the meantime the KDE project reacted and update the nspluginviewer library to support direct Xembed. The support is not perfect yet but works. And now the KDE-Fedora team took that code and patched the current kdebase and kdelibs: Konqueror can now use the newest flash plugins.

The updates are still in testing and therefore must be installed via

yum --enablerepo=updates-testing update kdebase kdelibs

But: keep in mind that this is still non-perfect code! There are reports that 86_64 could run into trouble of some kind. But you can help improving the packages by simply testing them and report all problems in the corresponding bug report.