Hardware Server zu Xen Migration Error: Boot loader didn't return any data!

04 10 2011

Beim Umzug eines Kundenservers von einem dedizierten Server auf eine Xen Plattform konnte ich einmal mehr interessante Beobachtungen machen.

Anforderung war es, den bestehenden Server samt Betriebssystem und Software in eine Xen DomU zu migrieren.

Die ursprüngliche Maschine also ins Rescue System gebootet und via tar einen Komplettbackup erstellt. Auf dem Wirtsystem des neuen Rechners dann die root Partition (im LVM) gemountet und das dorthin kopierte tar.gz wieder ausgepackt. Anschließend notwendige Anpassungen der fstab Einträge, Netzwerkdaten und dergleichen. Da die neue DomU per pygrub gebooted wird, braucht kein Bootloader in das LVM Device geschrieben werden. Allerdings ist es nötig die menu.lst an die neue Festplatte anzupassen (sda -> xvda).

Der erste Startversuch der DomU ergab schließlich ein schnörkelloses "Error: Boot loader didn't return any data!". Das xend.log war leider wenig hilfreich und lies keine Rückschlüsse auf das Problem zu.

Nach längerer Recherche und einigen erfolglosen Versuchen stellte sich heraus, dass pygrub offenbar keine anderen Dateien im /boot/grub Verzeichnis des Gastsystemes toleriert. Nachdem alles bis auf die Datei menu.lst aus dem Verzeichnis entfernt ist, booted die DomU einwandfrei.


Debian Backports unter Squeeze

21 02 2011

Vielleicht mal ein guter Zeitpunkt um ein wenig über mein Lieblingsrepo zu reden.

Wer kennt das nicht, man sucht ein Softwarepaket und muss leider feststellen das die Version die wir in unsere Liste finden (okay, ich rede von 24 Monaten Lenny :-) ) eigentlich schon ziemlich alt ist. Nun haben wir hierbei ein wirkliches gutes Repository zur Hand welches genau aus diesem Grund geschaffen wurde

http://backports.debian.org/

Um es mit den Worten der Maintainer zu sagen:

You are running Debian stable, because you prefer the Debian stable tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. This is where backports come in.

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates) in a stable environment so that they will run without new libraries (whenever it is possible) on a Debian stable distribution. It is recommended to select single backports which fit your needs, and not to use all available backports.

Der Weg zu diesem Repo ist auch sehr einfach gestaltet, und geht prinzipiell in 3 Schritten

Zu allererst brauchen wir einen neuen Eintrag in /etc/apt/source.list

deb http://backports.debian.org/debian-backports squeeze-backports main

wenn wir diesen Eintrag angelegt haben brauchen wir nur noch die Liste zu updaten

  • aptitude update


hier wird dann die Liste der Pakete auf den neusten Stand gebracht. Nun können wir einzelne Pakete aus diesem Repo installieren mit

  • aptitude install -t squeeze-backports <paketname>


das gleiche gilt natürlich auch für search/update



Nun sollte man noch einen Eintrag in /etc/apt/preferences machen, dieser soll dafür sorgen, das auch automatisch Upgrades aus den Backports genommen werden

Package: *
Pin: release a=squeeze-backports
Pin-Priority: 200

Und das war es auch schon...



MySQL Replikation

15 02 2011

Heute beschäftigen wir uns kurz mal mit dem Thema "MySQL Replikation".

Kurz?

Ja! Lange dauert das ja nicht :-)

Nehmen wir mal die Ausgangssituation

Einen Debian Server MASTER mit MySQL

Auf die Installation von Debian bzw MySQL muss man wohl nicht mehr im Detail eingehen, diese ist bei Debian ja so schön automatisiert das nichts schief gehen sollte, und

Einen Debian Server SLAVE mit MySQL

 Wenn man die beiden Server zufällig in einem Rack haben sollte, so bevorzuge ich es an eth1 einfach ein Crosskabel anzuschliessen (Anmerkung!: Ein Crosskabel braucht man eigentlich nicht mehr, neue Neztwerkkarten sind so toll das sie dies alleine tun können).

Somit konfigurieren wir uns auf beiden Servern ein Netz, zB

auto eth1

iface eth1 inet static

        address 10.0.1.X

        netmask 255.255.255.0

        network 10.0.1.0

        broadcast 10.0.1.255

10.0.1.X sollte hierbei das X als 1 auf dem Master und 2 auf dem Slave gesetzt sein. Nach einem  /etc/init.d/networking restart sollte eine ping Probe möglich sein

root@mysql-master:~# ping 10.0.1.2

PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.

64 bytes from 10.0.1.2: icmp_req=1 ttl=64 time=3.95 ms

Nun beginnen wir mit der Arbeit auf dem Master

Als erstes editieren wir die /etc/mysql/my.cnf, hier suchen wir die Zeile


  • #server-id            = 1
  • #log_bin              = /var/log/mysql/mysql-bin.log

und kommentieren sie ein, danach

  • mysql -p

um in das MySQL Interface zu gelangen

  •  GRANT SUPER, RELOAD, REPLICATION SLAVE ON *.* TO 'repl'@'10.0.1.2' IDENTIFIED by '<ANYPASSWORD>';
  • flush privileges;

Nun brauchen wir noch den Grunddatensatz, hierzu packen wir uns einfach das data_dir welches wir in /etc/mysql/my.cnf finden. Im Falle von Debian sollte dies /var/lib/mysql sein

  • cd /var/lib/mysql
  • tar cfz /tmp/mysnap.tar.gz .
  • scp mysnap.tar.gz 10.0.1.2:

Letzter Punkt auf dem Master, wir brauchen das aktuelle Logfile

mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000001 |      106 |              |                  |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)


ACHTUNG! Debian hat einen eigenen Systemnutzer, mit dieser Methode wird auch sein Passwort überschrieben, was dazu führt das MySQL auf dem Slave gleich nicht mehr gestartet werden kann. Workaround ist relativ simple, man kopiere sich die Passwörter aus /etc/mysql/debian.cnf und ersetze diese auch auf dem Slave.

Nun machen wir auf dem Slave weiter

Auch hier suchen wir den server-id Eintrag, setzen ihn aber auf 2

  • server-id            = 2

Nun entpacken wir unser Archiv, wenn Sie unsicher sind können Sie hier auch im my.cnf File nachsehen welches das data dir ist

  • tar xfz mysnap.tar.gz -C /var/lib/mysql/

Im letzten Schritt

  • mysql -p
  • CHANGE MASTER TO  
    MASTER_HOST="10.0.1.1",
    MASTER_USER="repl",
    MASTER_PASSWORD="<ANYPASSWORD>",
    MASTER_LOG_FILE="mysql-bin.000001";
  •  START SLAVE;

Abschliessende Kontrolle:

So, eigentlich sollte unsere Arbeit hiermit erledigt sein, wir testen unser tun natürlich noch, ich kopiere mit Absicht nicht die ganze Zeile der Ausgabe, aber so ungefähr sollte sie aussehen

Auf dem Master

  • show processlist;
  • 35 | repl | 10.0.1.2:36874 | NULL | Binlog Dump |  914 | Has sent all binlog to slave; waiting for binlog to be updated | NULL


 Auf dem Slave, so etwas wie

  • show processlist;
  • Waiting for master to send event | 10.0.1.1    | repl        |        3306 |            60 | mysql-bin.000001 |                 106 | mysqld-relay-bin.000002 |           251 | mysql-bin.000001 

ACHTUNG! Fast hätte ich es vergessen. Was mir auch sehr spät bei der Kontrolle aufgefallen ist, ist das Debian standardmässig nur auf 127.0.0.1 hört daher muss die bind-adresse noch angepasst werden.

  • bind-address = 0.0.0.0

Danke das wars :-)


Der Ioncube Loader

10 02 2011
Der Ioncube Loader. Wird immer beliebter. Er ermöglicht es zwar php Anwendungen an einen Kunden herauszugeben, verhindert aber das dieser Kunde den Quelltext sehen kann.
Somit ist er Ioncube Loader natürlich für Unternehmen interessant die primär mit ihren Webentwicklungen Geld verdienen wollen.

Also erstmal zum Abgleich die Grundlagen
  • Debian Lenny 5.0.8
  • Apache/2.2.16 (Debian)
  • PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2
Wir laden von der oben genannten Seite das passende Linuxpaket
  • http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz
oder
  • http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
nach dem entpacken haben wir folgende Verzeichnisstruktur 

home01:~/ioncube# ls
ioncube_loader_lin_4.1.so     ioncube_loader_lin_5.1_ts.so
ioncube_loader_lin_4.2.so     ioncube_loader_lin_5.2.so
ioncube_loader_lin_4.3.so     ioncube_loader_lin_5.2_ts.so
ioncube_loader_lin_4.3_ts.so  ioncube_loader_lin_5.3.so
ioncube_loader_lin_4.4.so     ioncube_loader_lin_5.3_ts.so
ioncube_loader_lin_4.4_ts.so  LICENSE.txt
ioncube_loader_lin_5.0.so     loader-wizard.php
ioncube_loader_lin_5.0_ts.so  README.txt ioncube_loader_lin_5.1.so

natürlich kann man an dieser Stelle den loader-wizard in den Webspace verschieben, die seite aufrufen und der Anleitung folgen, da es aber nun schon ein paar mal getan wurde, geht es so weiter:

Wir verschieben alle Dateien nach /usr/local/ioncube (wahlweise auch nur die die wir wirklich brauchen in unserem Falle also die ioncube_loader_lin_5.2.so)
Wir erstellen folgenden Eintrag in der /etc/php5/apache2/php.ini am besten direkt ganz am Anfang der Datei, da es sonst (zumindest bei mir) öfter zu Problemen kommt
  • zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.2.so
Apache neustarten und Thats it!

Roundcube mit hoher Wait

07 02 2011
Letztens ist es passiert das Roundcube auf einem unserer Rechner am Limit war.
Soll heissen das die Ausgabe von top eine Wait von 85% zeigte, und damit einhergehend natürlich auch Loginzeiten (bzw auch Seitenaufbauzeiten) jenseits der 1 Minute Grenze.

Der erste Lösungsansatz schlug leider fehl. Dieser bestand darin den Apache Server und den MySQL Server neuzustarten. Doch wie gesagt, dies führte zu einer Verbesserung für gerade mal 3 Minuten. Bevor die Wait auch hier wieder über einen Wert von 60% ging.
Allgemein sollte man vielleicht wissen das Wait zumeist mit Festplatten zugriffen zusammenhängt, also ein Prozess würde zwar gerne etwas tun, muss jedoch auf die I/O warten.

Also, da Roundcube primär auf MySQL basiert, bzw diese Datenbank als Backend nutzt, fand sich hier auch ein besserer Lösungsansatz und zwar über das löschen/leeren einer Roundcube Tabelle in Mysql.
Hierzu betrachtet ich mir die Zugriffe in MySQL selbst und fand schnell heraus das Roundcube mittels einer Tabelle eine Art Cache simuliert.

Die Lösung und Vorgehensweise:
  • mysql -p
Dann natürlich das Login in die Datenbank als root mit Passwort.
  • use roundcube;
  • select count(*) from cache;
Dies brachte einen Wert jenseits von 160.000 Einträge zurück.
  • truncate cache;
  • quit;
Dies führte dazu das es ziemlich genau 3 Monate sehr gut lief, bis der Speicher auch hier wieder voll war. Scheint somit ein kleiner Fehler zu sein, oder die Erfinder hatten mit einer solchen Auslastung nicht gerechnet. 

Debian 6.0 (squeeze) veröffentlicht

06 02 2011

Nach 2 Jahren Entwicklungszeit präsentiert die Debian Entwicklergemeinde am heutigen Sonntag die stabile Version 6.0 (squeeze) Ihres Betriebssystemes. Squeeze machte in den letzten Monaten bereits einen sehr ausgereiften und guten Eindruck im produktiven Betrieb. Die Veröffentlichung entspricht dem normalen Debian Release Zyklus.

Als eine der wichtigsten strukturellen Neuerungen ist die ausschließliche Einbindung von Paketen, Treibern und Firmware auf Basis der GPL oder vergleichbaren freien Lizenzmodellen zu nennen. Alle nicht-freien Pakete wurden aus dem main-tree ausgelagert - den Benutzern soll bewusst gemacht werden, dass es sich bei diesen Paketen nicht um freie Software handelt.

Die offizielle Release Note gibt es hier.

Nachtrag: Den inoffiziellen Debian Release Kuchen gibt es hier


Zonentransfer zwischen MyDNS und BIND

27 01 2011

Durch einen Kunden, der einen eigenen MyDNS Master Nameserver und unsere BINDs als Secondary Nameserver benutzt sind wir diese Woche auf ein Problem beim Zonentransfer zwischen beiden Nameserver-Typen aufmerksam geworden. Wird eine Zone auf dem Master Nameserver aktualisiert, gibt es ein Notify an die Slaves. Diese versuchen einen Zonentransfer - scheitern aber mit der Fehlermeldung:

failed while receiving responses: end of file

Der AXFR via dig funktionierte aber problemlos! Nachdem wir nach und nach alle üblichen Konfigurationsfallen überprüft hatten, kamen wir nach einigen Recherchen dahinter, dass MyDNS scheinbar primär einen IXFR, also einen inkrementellen Zonentransfer versucht. Offenbar unterscheiden sich die Implementierungen des IXFR von MyDNS und BIND aber oder sind inkompatibel.

Der Fehler ließ sich nur durch Deaktivierung der IXFRs von BIND Seite beheben, dazu trägt man in die BIND Konfiguration folgendes ein:

options {
...

request-ixfr no;

...
};

Danach klappt das Ganze wie ursprünglich angedacht, auch wenn es natürlich keine perferkte Lösung ist.