I praise myself of having a rather complete overview of the browser market. On my main sytem, I've got Opera, Firefox, Seamonkey, Konqueror, and Midori. In virtual machines, I can test Iron or Chromium, as well as IE 8 and Safari, and compare builds of all browsers to each other on various OS.

Years ago, I wondered why everybody was using IE. There was no rational reason. People ... just were used to it.

Now, I have the feeling that we got the same situation with FF. People use it without even thinking. It's just assumed to be without alternative.

Personally, I almost exclusively use Opera. Why? Because Firefox is basically an open-source hypocrite. The Mozilla foundation promised a slim browser already seven years ago. What happened? We got a browser with zero functionality but the memory consumption of three mozillas. They also promised a transparent browser. And look what you got: about:config. 😄 Compare that to the oldfashioned ini files of Opera (and there's always about:opera for converts from FF 😉 ).

There is of course one feature of FF which is outstanding: it's add-on system. It's what makes FF unique, and distinguishes it from all other browsers. I would guess that 90% of its current users are not even aware of this feature, which is as much blessing as it's curse. Curse? Oh yes. It's a security concern of gigantic dimensions. Major updates break most add-ons. Many add-ons render the browser sluggish and unresponsive. Playing with add-ons is addictive. 😄 Blessing? Well, without add-ons FF is just as unusable as IE. But with the right add-ons you'll get a browser with impressive value.

Let's look at the list of FF add-ons I've installed. I've installed many of them to mimic a function of Opera. Those which aren't are possibly not that terribly important ... but they are fun. 😉 Oh, and one more thing: while Opera does not feature add-ons, it can still be customized to an amazing degree. There are user buttons, user scripts, user styles ... check it out here. Please understand that an NA entry (aka not available) in the table below simply means that I'm not aware of a realization via the above means.

[1] A comprehensive urlfilter.ini, complete with a css for removing whitespace, and an adblocker realized as a user script.

Update: What a pity: Adsweep has been discontinued.

Of course, everyone knows how to select an alternative DNS server.

Many people, however, fear that this step alone will fail to guarantee an uncensored (and unlogged) access of the web in the foreseeable future. They are afraid that providers will be forced to redirect all requests bound to port 53 to their own DNS servers, which will of course be censored, monitored and logged. This, it seems, is our dystopian reality, and we have to deal with it.

IMHO, the easiest way to query DNS servers on nonstandard ports is the installation of pdnsd (not related to pdns aka PowerDNS, but the pdnsd of Paul Rombouts) which should be available on the repositories of your distribution. Just install it, and do the following:

First of all, edit /etc/pdnsd.conf:

global {
    perm_cache=65536;
    cache_dir="/var/cache/pdnsd";
#   pid_file = /var/run/pdnsd.pid;
    run_as="pdnsd";
    server_ip = 127.0.0.1;      # Use eth0 here if you want to allow other machines
                     on your network to query pdnsd.
    status_ctl = on;
    paranoid=on;
    query_method=tcp_udp;       # pdnsd must be compiled with tcp query support for this to work.
    min_ttl=15m;            # Retain cached entries at least 15 minutes.
    max_ttl=4w;         # Four weeks.
    timeout=10;             # Global timeout option (10 seconds).
    neg_rrs_pol=on;         # see https://wiki.archlinux.org/index.php/Pdnsd
    par_queries=1;          # see https://wiki.archlinux.org/index.php/Pdnsd
}

# The following section is most appropriate for fixed connections to the Internet.
server {
    label= "uncensored";
    ip = 85.214.20.141,         # h1768020.stratoserver.net (Foebud,DE)
         80.237.196.2,      # dnsc1.dtfh.de (CCC, DE)
         213.73.91.35,      # dnscache.berlin.ccc.de (CCC, DE)
         194.150.168.168,       # dns.as250.net (CCC, DE)
         62.75.219.7,       # awxcnx.de (German Privacy Foundation, DE)
         87.118.100.175,        # ns.anon.privacyfoundation.de (German Privacy Foundation. DE)
         94.75.228.29,      # privacybox.de (German Privacy Foundation, NL)
         87.118.104.203,        # spftor1.privacyfoundation.de (German Privacy Foundation, DE)
         194.8.57.12,       # ns.n-ix.net (Nürnberger Internet eXchange, DE)
         194.95.202.198;        # omni.digital.udk-berlin.de (Universität der Künste, DE)
#   port = 110;         # German Privacy Foundation accepts queries on this nonstandard port 😉
    proxy_only=on;          # Do not query any name servers beside those above.
    timeout=4;              # Server timeout; this may be much shorter that the global timeout option.
    uptest=if;
    interface=eth0;
    interval=10m;           # Check every 10 minutes.
    purge_cache=off;        # Keep stale cache entries in case the ISP's DNS servers go offline.
}

Second, edit your /etc/resolv.conf:

nameserver 127.0.0.1

Third, and only if you'd like to have a nonvolatile DNS cache, issue 'chown -R pdnsd:pdnsd /var/cache/pdnsd'

Fourth, start the service. 😉

Fifth, you can check the status of your DNS cache by issuing 'pdnsd-ctl status' as root.

Update (08/09/09): included the nameservers in the ZDNet-List.

Second update (05/09/13): refreshed server list.

Friends of mine complained about OpenSuse 11.1 in VirtualBox: they were simply unable to compile the guest additions. I ascribed these problems to their inexperience. I was wrong. 😒

Novell preinstalls the guest additions, and of course an ancient version! That's what causing all these irregular error messages, and all those frustrating installation experiences. Do a 'zypper search virtual', and remove everything which looks like one of these Suse-attempts-to-be-helpful-packages. Enjoy!

Having bypassed these difficulties, I've now successfully completed the transfer of all of my virtual machines from VMWare to VirtualBox. All (Arch, Debian, Ubuntu, Suse, XP, 7), except for the legacy machines like Windows NT and 98. Those will stay forever in VMWare. Naturally. 😊

[cobra@blackvelvet ~]$ less /etc/resolv.conf

nameserver 85.214.73.63
nameserver 213.73.91.35

Netalyzer: DNS resolver address: OK The IP address of your ISP's DNS Resolver is 85.214.73.63, which resolves to anonymisierungsdienst.foebud.org

As promised, let's talk about automated backups to a remote server.

Let me stress, first of all: the most important characteristics of a sensible backup scheme is that the backup takes place automatically, without any user intervention. Without this automatism, the backup you'd need will be missing since it was never made. That's one of Murphy's laws which is valid strictly!

There's one very elegant and secure way to do just that, which I'll describe in the following. Note that this way is not standardized amongst the various distributions. I trust you to find the culprits and solutions for the specific distribution of interest for you ... the following, however, applies to Mandriva.

First of all, make sure that you have installed OpenSSH. Generate a SSH2-DSA key pair by executing 'ssh-keygen -t dsa' in a terminal. Set a passphrase to protect your private key! Next, issue 'ssh-copy-id server.name.xy' to copy your credentials to the remote server. Follow the instructions.

Next, install keychain as well as one of the ssh-askpass dependencies (personally, I prefer gnome-ssh-askpass). Keychain is a frontend for ssh-agent, which in turn provides a secure way of storing the passphrase of your private key. For doing that, ssh-agent creates a socket in /tmp with restrictive permissions and then checks the connections from ssh. Keychain allows you to have one ssh-agent process per system, rather than per login session. That is, keychain will ask for your ssh passphrase only upon reboot.

Now, just try and reboot. Being asked for your ssh passphrase? Good! Note that keychain also manages gpg-agent.

For automation, we utilize cron. Copy the following two lines:

#Backup
15 11,14,17,20 * * *    source $HOME/.keychain/${HOSTNAME}-sh; $HOME/bin/backup.rdiff

Save them as 'cronentry' to a temporary location. Open this file with any editor and modify the path to your backup script (which may look just like the backup.rdiff I've shown here). Furthermore, change the time (the first number indicates the minute, the second the hour of a daily backup. The above, for example, means that the backup is processed daily and each three hours between 11.15 AM to 20.15 PM.) Then, execute 'crontab cronentry' in a terminal to create your crontab entry.

That's it. You should now enjoy a fully automatic backup. If you want to change, say, the intervals of your backup scheme, use 'crontab -e'.

Perhaps you've already noticed it: since a couple of days you can search this blog using either ixquick or scroogle. I'll probably add a WolframAlpha search of the entire web later on.

Here at home, I'm extremely happy with rsnapshot as a backup solution. It's exactly what I need: easy to configure (with just a few pitfalls), totally transparent, and very reliable. Too bad I can't use it at work: the incremental backups of rsnapshot rely on hard links, which are supported neither by cifs nor by sshfs. And no, I do not want a server-based (pull) backup. I want to push my data!

We briefly thought about setting up nfs, but that requires kerberos for secure authentication ... oh well, that's really too much hassle for a lonely snake. I instead decided to search an easy-to-use backup program which does not require hard links. Easy to use, mind you: enterprise-class solutions of the like as bacula or amanda are explicitely ruled out.

And I think I found one: rdiff-backup, which realizes incremental backups via rdiff.

The configuration is simple:

The exclude list might look like that:

/home/cobra/.beagle/
/home/cobra/.Mail/FalseNegs/
/home/cobra/.Mail/Junk/
/home/cobra/.Mail/Worms/
/home/cobra/.Mail/trash/
/home/cobra/temp/
/home/cobra/tmp/
/home/cobra/.opera/cache4/
/home/cobra/.opera/images/
/home/cobra/.mozilla/firefox/ytuudeoq.default/Cache/
/home/cobra/.VirtualBox/
/home/cobra/VMWare/

I've just started to use it, but so far it looks very promising. Ask me again in 30 days. 😊

What I will detail very soon in a forthcoming blog entry: how to automate this backup in the most convenient way.

Let's continue the story started on a wonderful day.

Of course I didn't give up just like that. Instead, I discovered that the lack of openssl support in the version of vpnc shipped with all current distributions is due to a licensing issue. Thus encouraged, I got the rpms of vpnc and compiled it with openssl support enabled ... but I was still unable to establish a connection to our gateway. After some research, I found that vpnc does not (yet?) support a certificate-based client authentication despite its option 'auth-mode cert' ... Note that this way of authenticating inbound connections is the only sensible one within the framework of a PKI infrastructure, and is thus the way we are enforcing.

After this ... eehhhh ... illuminating experience, I grew quite hesitant to keep myself busy with this obviously complicated issue. Ok, after installing new kernel versions, I've always tried to connect using the Cisco vpnclient (*shudder*), and indeed, there has been a certain improvement: since 2.6.29.1 I did not experience a kernel panic anymore. Instead, the client connects happily with our gateway, and then just sits there ... doing exactly nothing. Not even a ping will work. 😄

Today, I've checked tuxx-home for updates. Hey, an update from May 20 ... let's try!

Welcome back, kernel panic. 😞

If you're now under the impression that the Cisco vpnclient is a promising candidate for the worst-software-on-this-planet contest, you're wrong. It's the clear winner (check out the 64 bit and SMP issues which exist for all platforms, including Windows).

Are there alternatives? We have seen above that vpnc is not a viable replacement for me. A quick search in the net shows that most discussions of alternatives revolve around the ShrewSoft client, and the FreeS/Wan implementations OpenSwan and StrongSwan.

If you now expect a test of these clients, I have to disappoint you. I really can't be bothered with responsibilities of others, and I anyway don't have the time for it. No, I leave that to the guy who sold us the Cisco ASA and promised a functional vpn. Mr. Network Professional. 😉

Update: Turned out that Mr. Network Professional has not enabled SSL on our Cisco ASA, so that the openssl support of vpnc did not matter at all. Bummer.

Did I really say that you can't do an online upgrade from OpenSuse 11.0 to 11.1? Ahem ...

To use a memorable quote: "Uh... Mr. President. That's not entirely accurate." Well, but as it turns out, almost. How fortunate for me! 😄 In fact, zypper, as included in OpenSuse 11.0, does not support an online upgrade, which led me to the above statement. However, there's a trick of which I wasn't aware of until I read this article in today's c't.

Simply change all your repositories from 11.0 to 11.1. Then issue:

zypper in zypper libzypp

to install the latest version of zypper. Then, a simple

zypper dup

should be sufficient to upgrade smoothly from 11.0 to 11.1. Welcome home, Susi ... you're the last, but now there's one reason (well, the main reason) less for bashing you. 😉

A universal adblocker? Well, it's worth a try, and worked very well in my first tests on Chromium/Iron and Opera.