Open Source, Physics & Politics

I have been using Bacula as our main backup system for years. While Bacula works perfectly for Linux systems, bare-metal recovery (also known as disaster recovery) of Windows systems has been an open issue ever since.

The Bacula manual describes some procedures, but they only apply to systems running an operating system not newer than Windows Server 2003 R2. Even these procedures remain a bit unclear. If you look for solutions that cover Windows Server 2008 and newer versions of Windows, you will only find a few mailing-list posts that discuss using Windows Server Backup in combination with Bacula. However, none of these solutions sound very appealing.

I believe that you do not have a backup unless you tested the restore, I wanted to find out the best way for backing up a Windows system with Bacula. So I spent some time and installed a Windows Server 2012 R2 system in a virtual machine, made a backup with Bacula, and then tried to restore this backup in a new virtual machine. I actually succeeded without using Windows Server Backup or any other third-party tool. It really seems to work with a Bacula-only solution.

I documented the steps I used in the wiki, just in case I might have to restore a Windows System from a Bacula backup in the future. Maybe this guide is useful for you as well.

Recently I experienced a strange problem with a HP ProLiant DL160 G6 server:

Sometimes after seeing the BIOS initialization messages, the system would not boot but just show a blank screen with a blinking cursor. After power-cycling, this problem sometimes would disappear and sometimes it would appear again.

Frankly this problem puzzled me. Luckily, someone else had experienced this problem before and found the reason:

This problem can be caused by an incompatible KVM console. In my case I had been using a Sharkoon PS/2 to USB adapter in order to connect the system to an ATEN KVM switch (the server does not have PS/2 and the KVM switch does not have USB). After I connected a USB keyboard directly, the problem disappeared, even if the PS/2 to USB adapter was connected in parallel.

Unfortunately I have not figured out yet, whether the problem is caused by the adapter, the KVM switch or the PS/2 keyboard. Maybe I will try a different adapter and report, whether this fixes the problem.

Recently I have been experiencing a strange with an installation of the Community Edition of Zimbra Collaboration Server 8: Although all services were running, no e-mails were delivered. In the log file /var/log/zimbra.log I found messages like "zimbra amavis[9323]: (09323-01) (!!)TROUBLE in process_request: connect_to_ldap: unable to connect at (eval 111) line 152.".

The strange things about this was, that the OpenLDAP daemon (slapd) was running and answering requests. After restarting Zimbra (/etc/init.d/zimbra restart), the problem disappeared, however it reappeared after the next reboot.

After some time I figured out, that - right after the reboot - slapd was only listening on an IPv4 socket, not on an IPv6 socket. After restarting the OpenLDAP server (ldap stop && ldap start as user zimbra), the problem disappeared again and netstat showed that now slapd was also listening on the IPv6 socket.

In the end I could not figure out, why the OpenLDAP daemon would only listen on IPv4 when started during system boot but would listen on both IPv4 and IPv6 when started later. I was suspecting some problem with name resolution in the early boot process (although both the IPv4 and the IPv6 address were listed in /etc/hosts).

However, I found a work-around for the problem: By setting the local configuration option ldap_bind_url to ldap:/// (zmlocalconfig -e ldap_bind_url=ldap:///) , I could configure OpenLDAP to listen on all local interfaces, which apparently fixed the problem.

While I am writing about curious bugs, here is another one, although technically it is not really a bug.

When setting up Icinga with mod_gearman, I wondered why service-checks where running on the assigned mod_gearman worker node, but host-checks were running on the main Icinga server and were not distributed using mod_gearman. I checked the configuration again and again, but could not find an error. Also searching the web did not bring much useful information.

The only thing that I could find were hints that do_hostchecks had to set to "yes" in /etc/mod-gearman/module.conf. But according to the mod_gearman documentation, this option was set to "yes" by default.

Well, as it turns out, the flag is set to "no" by default, at least in the version of mod_gearman that is available in the software repositories of Ubuntu 12.04 LTS (Precise Pangolin). By the way, the manual that is distributed in the source archive of mod_gearman 1.2.2 (this is the same version that comes with Ubuntu) says the same, so it is not a thing that was changed recently.

Recently I stumbled across a bug in the OpenDKIM configuration of the Zimbra Collaboration Server.

In ZCS 8.0.3 (Community Edition, but I guess the same applies to the Network Edition), the file /opt/zimbra/conf/opendkim.conf.in specifies the socket that OpenDKIM listens on in the following way:

Socket                %%zimbraInetMode%%:8465@[%%zimbraLocalBindAddress%%]

This results in the following socket address of "inet6:8465@[::1]" in the final file (opendkim.conf). However, the Postfix configuration file /opt/zimbra/postfix/conf/master.cf.in specifies the socket as "inet:localhost:8465". This leads to Postfix trying to connect to an IPv4 socket, while OpenDKIM is listening on an IPv6 socket, so that the connection cannot be established.

The fix is quite easy: By changing "%%zimbraInetMode%%:8465@[%%zimbraLocalBindAddress%%]" to "inet:8465@[127.0.0.1]" in opendkim.conf.in and restarting Zimbra, OpenDKIM can be made to listen on an IPv4 socket, so that Postfix can connect again.

The curious thing is, that this bug has already been reported half a year ago and has supposedly been fixed. However, it seems like this fix was only applied to the 9.0 branch of Zimbra and not to Zimbra 8.0.

About two years ago, I wrote an article about how to make libvirt on Ubuntu 10.04 LTS to shutdown the virtual machines gracefully, when the host system is shutdown or rebooted.

Now I recently found out, that they implemented a similar approach in Ubuntu 12.04 LTS. The only problem with this is, that the default timeout is too short (30 seconds) for virtual machines running complex services. Therefore, I documented how to change this timeout in my wiki.

Die meisten "Veronica Mars"-Fans dürften es schon mitbekommen haben: Auf Kickstarter läuft momentan eine Kampagne zur Produktion eines "Veronica Mars"-Films. Rob Thomas und viele der Schauspieler aus der Serie sind mit im Boot.

Inzwischen kann man das Projekt auch aus Europa unterstützen (zunächst war es auf die USA beschränkt). Wer also genau so wie ich ein Fan von Veronica Mars ist, kann das Projekt noch bis zum 12. April unterstützen.

Für diejenigen unter den Lesern, die mich persönlich kennen: Ihr könnt euch gerne die DVDs der Serie ausleihen. Sprecht mich einfach darauf an.

Nach stundenlangem Herumprobieren habe ich endlich herausgefunden, wie man bei Verwendung von Parallels Desktop 8 unter Mac OS X in einer Ubuntu 12.04 LTS VM die Tastatur konfigurieren muss, damit man diverse Sonderzeichen (@, geschweifte Klammern, etc.) eingeben kann. Die Gemeinheit ist, dass man die richtige Kombination von drei Einstellungen braucht, damit es funktioniert:

Zunächst muss man in der virtuellen Maschine das Tastatur-Layout auf "Deutsch (Macintosh)" einstellen. Dies ist noch der offensichtlichste Teil. Als nächstes muss man in den Optionen im Bereich "Taste zum Wechsel in die dritte Tastaturebene" die Option "Beliebe Alt-Taste" aktivieren. "Linke Alt-Taste" würde auch funktionieren, "Rechte Alt-Taste" hingegen nicht.

 Jetzt funktioniert die Eingabe von Sonderzeichen wie auf dem Mac gewohnt (z.B. mit Alt-L für das At-Zeichen). Allerdings hat man jetzt keine Alt-Taste mehr (um z.B. direkt einen Menüpunkt anzuspringen). Deshalb muss jetzt noch im Bereich "Verhalten der Alt/Windows-Tasten" die Option "Linke Alt-Taste ist gegen linke Windows-Taste vertauscht" gewählt werden.

Anschließend kann mann die Befehl-Taste dort verwenden, wo man sonst die Alt-Taste verwenden würde (z.B. um mit Alt-Buchstabe direkt einen Befehl in der Menü-Leiste auszuwählen). Parallels Desktop 8 bildet allerdings einige Tastenkombination mit der Befehl-Taste automatisch auf ihre Entsprechung mit der Steuerung-Taste ab, wenn als Profil "Linux" gewählt ist. So wird z.B. Befehl-X durch Strg-X ersetzt. Wenn man dieses Verhalten nicht möchte, muss man in den Einstellungen von Parallels Desktop unter Kurzbefehle als Profil "Generic" wählen. Dann werden die Tastenkombinationen unverändert weitergegeben.

In VirtualBox funktionieren zumindest die ersten zwei Schritte. Das Umbelegen der Befehl-Taste scheitert daran, dass VirtualBox ein Drücken dieser Taste nicht weitergibt sondern selbst verarbeitet.

Update (13. Juni 2017):

Im Prinzip gilt diese Anleitung auch noch für aktuelle Versionen von Ubuntu und Parallels Desktop. Allerdings gibt es in neueren Ubuntu-Versionen keine GUI mehr, über die sich die Einstellungen vornehmen lassen. Stattdessen, muss man die entsprechenden Optionen manuell setzen:

dconf write /org/gnome/desktop/input-sources/xkb-options "['lv3:alt_switch', 'altwin:swap_lalt_lwin']"

Mit diesem Kommando hat es in meinem Fall dann auch mit einer Ubuntu 16.04 LTS VM unter Parallels Desktop 12 funktioniert.

In an earlier blog post I claimed that I was seeing problems with VMs using the virtio driver for networking on an Ubuntu 12.04 LTS KVM host using DHCP.

However, as far as I am concerned, this claim was wrong. I now figured out, that the messages about bad UDP checksums had nothing to do with my problem. I was rather experiencing the problems caused by a configuration that did not list the VLAN network interface (eth0.X) on which the DHCP relay agent received the answers from the DHCP server.

The mean thing is, that switch away from virtio fixed this problem. However, this was not because of the UDP checksums now being right (this was merely a side effect). It fixed the problem, because when not using the virtio driver, the DHCP relay agent would receive the answer packets, even if they were received on a VLAN interface it was not listening to. I can only guess that the implementation for VLAN-tagged interfaces is slightly different when using the virtio driver.

After adding the interface to the list of interfaces used by the DHCP relay agent, the DHCP packets are relayed correctly, even if using the virtio driver. The messages about bad UDP checksums now reappeared in the log file, but obviously this is not causing any trouble.

On the other hand, according to a bug report some users really seem to have problems with DHCP when using the virtio driver. However, this might only affect Ubuntu 12.04 LTS guests but not VMs on a Ubuntu 12.04 LTS host.

Lately I experienced a problem with KVM-based virtual machine running a DHCP server and another one running a DHCP relay (for both I use the ISC implementations). The DHCP relay was complaining about "bad udp checksums". Using tcpdump and wireshark I quickly found out, that the software was right and the UDP checksums were in fact wrong. After some searching, I found a bug report, that basically described the same problem.

Although I cannot verify this, I think the problem might be related to the fact that I recently upgraded the host machine from Ubuntu 10.04 LTS (Lucid) to Ubuntu 12.04 LTS (Precise). As a workaround, I deactivated the use of the "virtio" support for the network interface in both virtual machines, which seems to fix the problem, because then the UDP checksums are correct.

However, when I performed the same change for a virtual machine still running on an Ubuntu 10.04 LTS host, this actually caused a problem: If VLAN interfaces are used inside the virtual machine, the normal non-virtio driver will screw things up on a Ubuntu 10.04 LTS host.

Long story short: For virtual machines running on a Ubuntu 10.04 LTS host you should use and for a Ubuntu 12.04 LTS you should avoid virtio networking.

Update [2012-07-08]: It seems like the conclusions I draw in this article are actually wrong. Therefore I posted an update clarifying the situation.

Some time ago Ubuntu 10.04 LTS received a Firefox update from the 3.6 branch to the more recent versions (10.0+).

After that upgrade, Firefox on one of my Ubuntu systems suddenly appeared in English instead of the correct locale (German in my case). I first thought that this might be a problem with some localization packages not being installed correctly. However, the problem persisted after upgrading the system to Ubuntu 12.04 LTS.

Some globally extensions (in particular the language pack) showed up in an old version in the add-ons list, although the newest version was installed. Finally I found out, that Firefox looks for the extensions in /usr/lib/firefox/extensions. The new language packs however had been installed in /usr/lib/firefox-addons/extensions. On other systems, /usr/lib/firefox/extensions is a symbol link to /usr/lib/firefox-addons/extensions. In my case however the directory existed and contained the files from the old versions of the language packs.

For some reasons, the old language packs (which had different package names) had not been removed and thus the Firefox upgrade did not place the symbol link (because the directory was not empty). After manually removing the old versions of the language packs, deleting the directory and reinstalling Firefox, the symbol link was created automatically and suddenly the globally installed Firefox add-ons worked again.

Ich hatte bereits vor ein paar Wochen geschrieben, was ich über die Reaktionen auf die fehlerhaften Messungen der Neutrino-Geschwindigkeit denke.

Nun ist also der Leiter der Opera-Kollaboration zurückgetreten. Es ist wohl unnötig zu sagen, dass ich diesen Schritt für übertrieben halte. Immerhin ist der zugehörige Artikel auf SPIEGEL ONLINE deutlich zurückhaltender. Dort heißt es jetzt:

Doch das öffentliche Interesse war so groß, dass der Fund des Fehlers schließlich - wohl zu Unrecht - wie das Eingeständnis einer Schludrigkeit wirkte. Dabei funktioniert Wissenschaft nach dem Prinzip von Versuch und Irrtum.

Das ist eine deutlich treffendere Einschätzung als in dem Artikel, der vor einigen Wochen erschienen war.

Als Bonus gibt es noch etwas zum Lachen: Im Forum zum Artikel gibt es einen Link auf eine Internet-Seite, die erklärt, dass es gar keine Neutrinos gibt.

"Loses Kabel blamiert Teilchenphysiker" - so betitelt heute SPIEGEL ONLINE einen Artikel, der Meldungen über neue Erkenntnisse bezüglich der Zeit-Anomalie beim CNGS-Experiment zum Inhalt hat.

Wir erinnern uns: Im vergangenen Jahr gab es eine Veröffentlichung, in der die Wissenschaftler vom CNGS/OPERA-Experiment darüber berichteten, dass sie für Neutrinos, die mit Hilfe des SPS am CERN erzeugt worden waren, eine kürzere Flugzeit zum OPERA-Detektor im Gran-Sasso-Massiv gemessen hatten, als man für den gegebenen Abstand eigentlich hätte erwarten müssen.

Die Presse stürzte sich damals auf die Meldung und während zum Teil wenigstens auf Zweifel an den Ergebnissen hingewiesen wurde (wenn auch wesentlich schwächer als in der ursprünglichen Veröffentlichung), klangen manche Artikel geradezu euphorisch und sahen die Verifizierung der Ergebnisse fast als reine Formsache an.

Heute gab es eine Kurzmeldung, dass man möglicherweise die Ursache für die gemessene Anomalie gefunden hat: Eventuell sorgte eine schlechte Verbindung zwischen dem als Referenz-Zeitquelle dienenden GPS-Empfänger und der am Detektor für die Zeiterfassung dienenden Elektronik dafür, dass man die bei der Übertragung entstehende Verzögerung falsch bestimmte und entsprechend das Messergebnis falsch korrigierte.

Auf Basis dieser Meldung entstand dann wahrscheinlich auch der oben genannte Artikel bei SPIEGEL ONLINE. Ich vermag allerdings in der neuen Meldung keine Blamage für die beteiligten Wissenschaftler erkennen: Diese gingen nämlich von Anfang an von einem Messfehler aus und brachten dies auch in ihrer Veröffentlichung zum Ausdruck.

Blamabel ist die Sache meiner Meinung nach eher für die Personen, die - wahrscheinlich ohne die Original-Veröffentlichung zu lesen - die Meldungen von den "überlichtschnellen Neutrinos" unreflektiert weitergaben und zum Teil schon die spezielle Relativitätstheorie widerlegt sahen. Selbstkritik scheint man aber bei jenen Journalisten die einen guten Beitrag zum damaligen Hype leisteten aber anscheinend nicht üben.

Heute ist planmäßig unsere neue Telefonanlage in Betrieb gegangen. Damit ist auch das Geheimnis gelüftet, was sich in den Kartons befand.

Wir haben uns für eine Telefonanlage von STARFACE entschieden. Überzeugt hat mich an dieser Anlage, die ich auf der CeBIT letztes Jahr zum ersten mal gesehen hatte, dass die Anbindung der Telefone vollständig über IP erfolgen kann, Telefone unterschiedlicher Hersteller unterstützt werden (wir benutzen Tischtelefone von snom) und man die Anlage mit eigenen Modulen erweitern kann.

Nachdem ich die eigentliche Anlage und die Telefone schon vor rund drei Wochen direkt bei STARFACE in Karlsruhe abgeholt hatte, musste noch etwas Netzwerk-Hardware und anderes Zubehör organisiert werden. Die Kontakte die ich mit verschiedenen STARFACE-Mitarbeitern hatte, waren alle sehr nett, so dass ich diese Firma uneingeschränkt weiterempfehlen kann.

Als überraschend schwierig hat es sich erwiesen passende Netzwerk-Switches zu bekommen. Eigentlich hätten diese schon vor rund zwei Wochen kommen sollen, aber da unser Lieferant, Office-Partner, selbst Probleme mit seinem Vorlieferanten hatte, verzögerte sich die Lieferung immer weiter. Glücklicherweise konnte Office-Partner die Switches dann doch noch von einem anderen Vorlieferanten kurzfristig beziehen, so dass wir letzte Woche dann alle benötigte Hardware hatten. An dieser Stelle auch ein herzliches Dankeschön an Herrn Wittneven von Office-Partner für seinen Einsatz.

Für den neuen Telefon-/DSL-Anschluss hatten wir uns für Vodafone entschieden. Ausschlaggebend war nicht nur der im Vergleich zur Telekom deutlich niedrigere Preis bei den Geschäftskunden-Angeboten, sondern auch die Tatsache, dass uns Vodafone DSL-6000 anbieten konnte, während bei der Telekom nur DSL-3000 möglich war.

Heute morgen war dann schließlich der Telekom-Techniker da um die Leitung zu schalten. Über den Service der Telekom wird ja gerne gelästert, insbesondere wenn es um die Schaltung von Leitungen für Mitbewerber geht. In unserem Fall war der Telekom-Techniker aber nicht nur sehr pünktlich sondern auch ausgesprochen freundlich und kompetent.

Da die neue Telefonanlage über einen ISDN-Anlagenanschluss verfügt, habe wir jetzt endlich auch die Möglichkeit flexibel Durchwahlen für verschiedene Zwecke festzulegen. Das ist schon sehr bequem im Vergleich zum ISDN-Mehrgeräteanschluss, den wir vorher hatten. Leider haben sich dadurch unsere Telefonnummern geändert, aber mittelfristig wird sich der Aufwand in der Umstellungsphase sicherlich auszahlen.

Besonders gut gefällt mir die Möglichkeit der STARFACE-Telefonanlage eigene Module in einer speziellen Skriptsprache zu schreiben. Als jemand, der auch gerne mal selbst etwas bastelt, habe ich damit die Möglichkeit nahezu beliebige Funktionen in der Anlage selbst zu implementieren. Bei anderen Anlagen müssten wir hingegen teure Zusatzmodule vom Hersteller kaufen, insofern für die benötigte Funktion überhaupt Module verfügbar wären. Ein erstes Modul habe ich bereits entworfen, dazu werden ich aber noch in einigen Tagen etwas schreiben.

Zusammenfassend kann ich sagen, dass ich mit der jetzt gefundenen Lösung sehr zufrieden bin, und glaube, dass sich die vielen Stunden, die ich in Auswahl, Organisation und Einrichtung investiert habe, gelohnt haben.

Im Laufe der letzten zwei Wochen sind diverse weitere Pakete eingetroffen. Heute ist das letzte Paket gekommen (diese Artikel zu besorgen hat sich als schwieriger als erwartet erwiesen).

Damit haben wir jetzt alle benötigte Hardware und warten nur noch auf einen Dienstleister. Wenn alles glatt läuft, ist es am 31. August soweit, und dann wird auch verraten, was sich in den Kartons befunden hat und wofür wir die ganzen Sachen brauchen.

Als kleine Anregung zum Grübeln gibt es hier noch eine Information zum Foto von vor zwei Wochen: Diese Kartons habe ich alle in der Stephanienstraße in Karlsruhe abgeholt.