Archiv 27. April 2007

Freitag, 27. April 2007

London 2007: Oddities

Zwar bin ich bereits seit letztem Montag wieder zurück auf Schweizer Boden, habe aber auf Grund der während der Ferienabwesenheit aufgestauten Pendenzen noch keine Zeit gehabt, meine Erlebnisse im Land der Angelsachsen zu bebloggen. Dies möchte ich hiermit nachholen – zuallerst in Form eines Beitrages, der sich den „Oddities“, den Merkwürdigkeiten, annimmt, die mir bei meinem ersten Besuch der britischen Insel aufgefallen sind.

Tags:
Labels: Allgemein

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. April 2007

mysqlhotcopy streikt

Seit einiger Zeit sichere ich die Datenbanktabellen auf meinem Entwicklungsserver (Debian) jeden Abend mit dem Perl-Script mysqlhotcopy. Einerseits beuge ich so einem Datenverlust vor, wenn ich für ein neues Projekt die Nacht durchgecodet habe und am nächsten Tag dummerweise DROP database ausführe, andererseits wenn Partyguide wieder einmal versuchen sollte, die Datenbank vollzuspammen.

Seit dem letzten

apt-get upgrade

spinnt die Routine leider und produziert folgende Fehlermeldungen:

Invalid db.table name 'mysql.mysql`.`columns_priv' at
usr/local/mysql/current/bin/mysqlhotcopy line 855.

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Das Problem taucht mit dem Upgrad auf DBD::mysql 4.003 auf. Da ich in der Eile nicht herausfinden konnte, wie ich dieses Package downgrade, habe ich mysqlhotcopy folgendermassen gepatcht:

...
my @dbh_tables = eval { $dbh->tables() };
map { s/^.*?\.//o } @dbh_tables;

## Remove quotes around table names
...

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Nun läuft das Backup wieder sorgenfrei.

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. April 2007

Wenn VMWare das Wochenende herauszögert …


VMWare streikt
Originally uploaded by emeidi.

Vor etwa einer Stunde erhielt ich einen Telefonanruf eines Kunden: „Wir können nicht mehr auf unser Wiki zugreifen. Was ist da wohl los? Wir präsentieren die Applikation doch morgen Samstag einem breiteren Publikum, ein Ausfall liegt da nicht drin!“.

Tatsächlich – der Server reagierte auf kein Ping mehr, logischwerise funktioniert auch der Zugriff auf Web-Seiten nicht mehr. Der Adrinalinaustoss verdoppelte sich innert eines Bruchteils einer Sekunde.

Murphy’s Law Extended

Sofort machte ich mich daran, das Problem zu lösen. Natürlich war Murphy nicht weit und sein Effekt trat kumulativ auf:

  • Der Virtual Infrastructure Client läuft nur unter Windows – Linux/Mac? Fehlanzeige
  • Mein MacBook mit Intel CPU und einer Windows XP-Installation unter Parallels ist momentan leihweise bei der Freundin in Basel, weil deren MacBook von WLAN-Empfangsprobleme geplagt wird und nun in der Reparatur weilt
  • Das Thinkpad, ein Arbeitsgerät, von dem aus ich die Instanz normalerweise betreue, liegt brav gesichert im Panzerschrank im Büro
  • Ein in eine Web-Site eingebettetes Applet zur Administrierung einer VMWare-Instanz (Alternative zum Infrastructure Client) lässt sich per VPN-Verbindung unter Mac OS X (Safari sowie Firefox) nicht laden.
  • Mangels funktionierender VPN-Verbindung von der Wintel-Maschine aus versuche ich, mittels WebVPN auf die entsprechende Seite zu kommen. Zumindest mit dem Internet Explorer müsste das Vorhaben doch gelingen? Leider nein – ob das Applet oder die Verschlüsselung und Zertifizierung spukt, WebVPN erlaubt mir nicht, auf die dringend benötigte Web-Seite zuzugreifen.
  • Immerhin gibt es hier zu Hause noch eine ältere Wintel-Kiste, die von meinem Vater benutzt wird – versuchen wir es damit!
  • Der Cisco VPN-Client funktioniert auf meinem PowerMac tadellos, auf der Windows-Maschine klappt die Einwahl hingegen nicht.
    • Vielleicht gibt es ein Update? Auf der Web-Site des Arbeitgebers findet sich tatsächlich die Version 5, installiert ist noch die Version 4.6. Glücklicherweise darf der Client mittlerweile auch aus dem Internet heruntergeladen werden, man muss sich also nicht mehr zwingend auf dem Campus aufhalten.
    • Bevor der neue Client installiert werden kann, muss der alte vom System geputzt werden. Selbstverständlich mit dem obligatorischen Windows-Neustart (wobei auch ein Mac für einmal neugestartet werden müsste, weil sich der Client relativ tief ins System einklinkt)
    • Nachdem der neue Client installiert wurde, ist ein weiterer Windows-Neustart nötig. Ohne Neustart läuft zwar ein Prozess vpngui.exe, doch das Fenster wird nicht angezeigt.
    • Nach dem Neustart startet auch die Applikation ordnungsgemäss und wählt sich – o Freude – tatsächlich in das Campus-Netzwerk ein
  • Nun muss der satte 50MB wiegende Infrastructure Client heruntergeladen werden
  • Die Installation klappt (für einmal kein Neustart nötig), die Applikation lädt
  • Wie lauten schon wieder die Zugangsdaten zum ESX-Server (Server, Username, Passwort)? Zurück zum PowerMac und dort den Mailverkehr abgesucht. Dank IMAP und einer ordentlichen Sortierung der eingegangenen Mails in aussagekräftige Unterordner finde ich das gesuchte Mail schnell
  • Es klappt, meine VMWare-Instanzen werden angezeigt. Ich wechsle auf die Konsole des fehlerhaften virtuellen Servers und sehe die Bescherung:
    Apr 27 14:38:02 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
    Apr 27 14:38:02 server kernel: eth0: transmit timed out, status 0073, resetting.

    Das virtuelle Netzwerkinterface streikt – was ist denn los? Andere Instanzen auf demselben Server funken tadellos in die weite Welt hinaus.

  • Als ich die Einstellungen der VM durchsehe, fällt mir auf, dass zwei Häkchen nicht gesetzt sind (vgl. Screenshot). Äusserst fahrlässig von mir – wieso habe ich das bei der Installation damals übersehen? Rätselhaft! Nachdem ich beide Häkchen gesetzt habe und den Server vorsichtshalber neu booten lasse, ist endlich wieder alles im grünen Bereich – das Wiki kann wieder angesurft werden.

Das Wochenende konnte gerade noch rechtzeitig gerettet werden. Puuuh! Auch die Dummen haben manchmal ein wenig Glück …

Tags:
Labels: IT

Keine Kommentare | neuen Kommentar verfassen