Timeout Option in /etc/resolv.conf

30 04 2012

Heute eine kleine, aber feine Zeile aus dem täglichen Leben. Wer aus Redundanzgründen mehrere Nameserver in der /etc/resolv.conf eingetragen hat, sollte ebenfalls erwägen diese Optionszeile hinzuzufügen:

options timeout:1

Dies führt dazu, dass beim Timeout der DNS-Anfrage auf dem ersten Nameserver bereits nach 1s Wartezeit der nächste Nameserver aus der Liste probiert wird. Für viele Applikationen oder Dienste sind einfach die 10s Timeout (Default Wert) zu lange.


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.


SKYWAY DataCenter startet VMware vCloud Hosting

02 09 2011
SKYWAY DataCenter bietet ab sofort den neuen VMware vCloud Hosting
Service an. Durch die VMware Partnerschaft bildet SKYWAY DataCenter mit
seinem vCloud Hosting Dienst alle Kosten- und Effizienzvorteile des
Cloud Computing ab, ohne die Kontrolle über die Informationssicherheit
zu verlieren.

Unser Hauptziel ist es eine kosteneffiziente und stabile "Infrastructure
as a Service"-Lösung (IaaS-Lösung) für den Business-Bereich anzubieten.

Vorteile:
  • Niedrige TCO durch bedarfsgenaue Ressourcen-Bereitstellung
  • Abrechnung abhängig von der Nutzungsdauer (pay-as-you-grow)
  • Höchste Rechenleistung und Speicherkapazität, verfügbar on-demand
  • Maximale Flexibilität und Skalierbarkeit
  • Webinterface und API ermöglichen Ihnen volle Kontrolle über alle Ressourcen
  • Vollautomatische Datensicherung
  • Sichere und vollständig redundante Betriebsumgebung im eigenen TÜV-zertifizierten TIER-III Rechenzentrum in St. Ingbert, Deutschland
  • Ihre Daten verbleiben im deutschen Rechtsraum

Zum Start des neuen VMware vCloud Hosting Service bietet SKYWAY
DataCenter einen kostenlosen 30-tägigen Testaccount an. Die Anzahl der
Test-Accounts ist limitiert ("first-come, first-served").

Bei Interesse wenden Sie sich bitte an: info@skyway-dc.com.

Weitere Informationen finden Sie hier:

http://www.skyway-datacenter.de/Cloud-Datacenter

4-star IPv6 RIPEness

16 05 2011

Unsere IPv6 Anbindung wurde in den letzten 2 Monaten auf Herz und Nieren getestet und wird zum 31.05.2011 die Testphase offiziell verlassen. Im Zuge dessen freuen wir uns nun auch mit SKYWAY/Key-Systems auf der Liste der deutschen RIPE-Mitglieder mit vollständiger IPv6 Unterstützung aufgeführt zu sein.

http://ripeness.ripe.net/4star/DE.html


Worldhostingdays 2011

20 03 2011

Endlich ist es wieder soweit! Die zuvor als Webhostingdays bekannte Veranstaltung präsentiert sich dieses Jahr zum ersten Mal internationalem Publikum. Aufgrunddessen wurde der Name der Veranstaltung als "Worldhostingdays" internationalisiert und auch eine größere Location ausgewählt. Die Worldhostingdays 2011 finden vom 23-25.03.2011 im Europa-Park in Rust statt. Man darf sich auf hochkarätiges Fachpublikum, spannende Vorträge und eine große Hosting.FAIR freuen!

Das SkyWay DataCenter ist nebst Muttergesellschaft Key-Systems natürlich auch mit eigenem Stand (Hosting.FAIR 53) vertreten. Gerne stehen wir für persönliche Gespräche und Informationen vor Ort zur Verfügung und freuen uns über Ihren Besuch. Einen Vortrag von Key-Systems und SkyWay DataCenter CEO Alexander Siffrin gibt es am Donnerstag.

Für weitere Informationen zur Veranstaltung besuche man die Webseite des WHD.


Vertipper des Tages

28 02 2011

Selten so schön (und völlig unabsichtlich) vertippt:

server ~ # xm lost|grep 65
Error: Subcommand lost not found!


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...



SSL connect auf der CLI

16 02 2011

Man braucht es immer wieder und kann es sich einfach nicht merken:

openssl s_client -connect host.name.tld:443


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


IPv4 Adressen neigen sich dem Ende

04 02 2011

Am gestrigen Donnerstag hat die IANA jeweils einen der letzten 5 verbleibenden /8 IP Adressblöcke an die regionalen Vergabestellen (RIR) verteilt. Damit nähern wir uns wieder einen weiteren Schritt dem Tag X, an dem alle freien IPv4 Adressen "aufgebraucht" sind. Wie gehabt werden die /8 Blöcke von den RIRs nach Bedarf an die einzelnen Mitglieder (LIR) aufgeteilt, von dort aus werden sie meist Ihrem endgültigen Benutzer zugewiesen (Hoster, Carrier, ISP).

Wie lange die restlichen verfügbaren IPv4 Adressen noch den Bedarf decken ist schwer abzuschätzen, sicher mehr als ein paar Tage oder gar Wochen - vielleicht aber auch nicht mehr mehrere Monate oder gar ein Jahr. Zu viele Faktoren spielen eine Rolle um exakte Prognosen abgeben zu können - einige LIRs haben fleißig gehamstert, andere haben sich noch garkeine Gedanken gemacht. Fraglich ist auch ob die IANA nicht doch noch irgendwo wieder ein paar ausgemusterte oder reservierte Blöcke aus dem Hut zaubert und freigibt.

Die in den letzten Tagen heraufbeschworene IPcalypse mag nicht wirklich der tatsächlichen Situation entsprechen, dennoch sollten die letzten Netzbetreiber langsam einmal anfangen sich mit dem Thema IPv6 zu beschäftigen. Das kein Weg daran vorbeigehen wird (früher oder später) ist mittlerweile abzusehen, trotz weiter vorhandener Protokoll-Bugs.


Abuse Handling 1

01 02 2011
Mit dem Abuse Handling der verschiedenen Provider ist das ja immer so eine Sache. Ich schreibe häufiger Abuse Meldungen, z.B. wenn sich mal wieder irgendein gekaperter Server daran versucht einen meiner Server aufzumachen. In 99% der Fälle bekommt man bei sowas keine Antwort, was ich sehr schade finde. Deshalb möchte ich hiermit eine Artikelserie einleiten, bei der es um die positiven Beispiele geht, also Provider von denen man auch mal eine Rückmeldung erhält.

Vor einigen Tagen lief also mal wieder eine Attacke eines gehackten Servers gegen sämtliche Server meines Subnets. Da ich fail2ban und ähnliche Tools verwende, erfahre ich das immer recht zeitnah. In diesem Fall handelte es sich um eine IP aus Slovenien. Also habe ich den Provider darum gebeten sich um das Problem zu kümmern. Überraschenderweise bekam ich noch am gleichen Tag eine Antwort. Es handelte sich um einen kleinen slovenischen Kabelnetzbetreiber. Der dortige IT Leiter teilte mir mit, man habe den Kunden (eine kleine Softwarefirma) über das Problem informiert und sei sehr dankbar für die Meldung, denn der Firma war noch nicht aufgefallen, dass ihr Server gekapert wurde. Man bat mich um einige weitere Informationen und bedankte sich noch einmal herzlich für die Meldung.

Das ist mal ein vorbildliches Abuse Handling.

Ein Negativbeispiel kann ich auch noch zum besten geben: Vorgestern lief eine ähnliche Attacke aus den USA gegen einige meiner Server. Auch dort bat ich darum den Server abzuklemmen und desweiteren um eine Rückmeldung. Die Attacken stoppten zwar nach etwa 13 Stunden, auf die Rückmeldung warte ich allerdings noch vergebens.

Und das ist leider - wie bereits erwähnt - der Regelfall. Ich werde also keine weiteren Negativbeispiele nennen. Dieses sollte die Symptomatik nur vedeutlichen.

Ehrlicherweise muß man aber auch sagen, dass die Fehler nicht immer auf Seiten der Provider liegen. Fehlgeleitete Abuse Reports oder falsche Erstellung sind häufige Ursachen für unbeantwortete oder ignorierte Reports. Im nächsten Artikel beschreibe ich darum in einem kurzen Howto, wie man einen korrekten Abuse Report erstellt.

Und dann wollen wir mal sehen wann ich den nächsten Provider loben darf...

P.S.: Auch wenn man nicht immer Antworten auf seine Abuse Reports bekommt, ist es trotzdem wichtig diese zu schreiben. Schließlich bewahrt man sich und andere dadurch evtl. vor größeren Schäden. Und bei manchen Providern kann es durchaus auch sein, das auf Grund der Menge der eingehenden Reports gar keine Beantwortung mehr möglich ist.


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.