Galactic Developments ist umgezogen auf einen neuen Server als KVM

Bisher war die Galactic Developments Website ein Apache Virtual Server auf meinem alten Hetzner Rootserver. Den hatte ich vor 6 Jahren bei einer keine-Setupgebühr-Aktion gebucht (und dann 3 Monate lang nicht installiert, was die keine-Setupgebühr-Aktion für mich ad-absurdum geführt hat, für Hetzner nicht). Inzwischen ist das Betriebssystem (Debian Sarge) aber schon aus den Security-Fixes raus gelaufen.

(Ich finde Sicherheitsaktualisierungen für nur 3 Jahre etwas kurz. Naja, ist ja Open Source. Wenn es einem nicht gefällt, dann einfach nicht benutzen oder selbst fixen, wie man so schön sagt, jedenfalls nicht meckern.)

Die Rechner der Rabatt-Aktion waren damals etwas schwach auf der Brust. Das stört nicht, wenn man nicht viel Traffic hat, aber heutzutage will man virtualisieren und mehrere Server gleichzeitig laufen lassen. Dafür ist ein ganzes GB RAM nicht genug. Der neue Server ist wieder bei Hetzner, hat aber 2 TB Platte, 32 GB RAM, 8 CPUs incl. Hyperthreading. Das sollte reichen für ein paar virtuelle.

Ich kann Debian, also weiter Debian-stable, d.h. Jessie 8.2.

Zum Virtualisieren kvm und libvirt drauf. Ein 2 GB Image für das Guest-Template erstellen mit einer Debian-minimal Installation ohne alles außer sshd. Die VMs sind nur über das interne "default" Netzwerk zu erreichen. Alle VMs bekommen statische IP Adressen vom internen DHCP.

Ein VM als Reverse-Proxy, der HTTP-Requests an verschiedene virtuelle Maschinen weiterleitet. Dafür eine iptables-Konfiguration per qemu-Hook, die immer dann die 2 iptables-Regeln setzt/löscht, wenn die VM startet/stoppt. Auf dem Proxy ein nginx, der alle Anfragen für www.galactic-developments.de an die Galactic Developments VM weiterleitet.

Der Galactic Developments Server bekommt eine eigene VM. Hier mit Apache, weil ich Apache schon kann und nicht zu viele Konfiguration ändern muss, dachte ich. Tatsächlich haben sich die Apache Entwickler ein neues Sicherheitskonzept einfallen lassen und erst mal geht gar nichts, bis ich herausfinde, dass man einen neuen Befehl (Require) braucht. Zusätzlich zum Galactic Developments Apache virtual Server gibt es noch einen CatchAll virtual Server, der Adressen wie galactic-developments.de (ohne www.) und *.galactic-developments.com auf den Hauptserver umleitet (401/permanent).

Dateien und Daten der Galactic Developments Website sind in Subversion. Das bleibt erstmal so bis sich die Community mehr beteiligt. Dann will ich git nicht im Wege stehen. Also: Repository auschecken und Apache-config darauf zeigen lassen. Bisher waren SVN Server und Website auf dem gleichen Rechner. Ein Subversion post-commit Hook hat automatisch die Website svn update'd. Poor man's Continuous Delivery. Das geht jetzt nicht mehr, weil es verschiedene Rechner sind und später - wenn der SVN Server auch umgezogen ist - gleicher Rechner, aber getrente VMs. Deshalb muss der post-commit Hook jetzt das Deployment anders triggern. Ich mag Trigger per HTTP-Request. In diesem Fall: ein Einzeiler-PHP in der Galactic Developments Website (Name lang und geheim, quasi das Passwort im Namen, Security by Obscurity), das ein lokales Shellscript startet, das wiederum "svn update" macht. Drei Einzeiler hintereinander. Man muss noch die Benutzer-Grenze überwinden vom wwwdata-User des Apache zum Eigentümer des Repositories. Deshalb wird das Shellscript mit sudo ausgeführt. Dafür eine Zeile in /etc/sudoers. Bei jedem svn commit ruft der post-commit Hook das update PHP-Script in der Zielwebsite per wget ("-O -" nicht vergessen) auf.

Dann noch DNS für www.galactic-developments.de umbiegen von rama.wolfspelz.de auf fred.wolfspelz.de und Galactic Developments ist umgezogen.

Das hört sich alles locker flockig an, hat mich aber mehrere Tage gekostet. Es gibt fast keine Anleitungen für libvirt/kvm OHNE lokales Display und ohne VNC. Auch virt-manager usw. alles nett gemeint, aber ich will kein Desktop auf meinem Server nur zum Installieren. (Wer bis hier gelesen bekommt von mir ein nagelneues Notebook). Genauso das Netzwerk: entweder es wird nicht erwähnt, was blöd ist, wenn man die VM vom Netzwerk installieren will oder es wird bridge-Networking vorgeschlagen, was bei mir einfach nicht wollte. Dabei geht das "default" Netzwerk super. Man muss es nur anschalten. Das könnte mal irgendwo stehen. Ein qemu-Hook statt bridge-Netz sehe ich nicht als Hack an, im Gegenteil.

PS: rama.wolfspelz.de war keine Frühstücksmargerine, sondern ein 50 km langes Alien-Raumschiff.

_happy_migrating()

Throttling Bandwidth with Linux Tools

As a semi-professional admin I do backups of production systems all the time. This means various "tar", "scp", "rsync" and even "lftp" operations depending on what is to be backup-ed.

The problem: Backup interferes with normal operation

Backup is running at the same time as the normal operation of the production system and the system is already quite busy. Copy and transfer tools take as many resources as they can get from CPU, DMA and network. This usually interferes with the normal server operations and can even bring down the server (thank you DMA).

The solution: Throttling

Many of the tools have a throttling option, which can limit the bandwidth in network transfers and file system operations.

scp:

• Option -l limits the used bandwidth, specified in Kbit/s. 
• Example for max 5 MByte/sec: scp -l 40000 myfile $user@$host:

rsync:

• Option --bwlimit limits I/O bandwidth in KBytes per second. 
• Example for max 5 MByte/sec: rsync --bwlimit 5000 myfile destfolder 

lftp:

• Setting "net:limit-rate" limits transfer rate on data connection in bytes per second. 
• Example for max. 5 MByte/sec: echo "set net:limit-rate 5000000; put myfile" | lftp -u $user,$password $host

Anything else, e.g. tar, use the cstream command:

• cstream can limit throughput of pipes with option -t in bytes per second.
• Example for max 5 MByte/sec: tar cf - myfolder | cstream -t -5000k > myfolder.tar
• Use "-5000k" instead of "5000k" to never exceed the max. Otherwise cstream saves throughput it could not use for later, which may be more bursty.

happy_throttling()

Im VMware Player vom ISO Image installieren

Für Noob-Admins wie mich: Debian in VMware Player vom ISO-Image installieren

Eigentlich soll man mit dem VMware Player keine Syteme installieren (können). Dafür gibt es die Workstation und die ist ihr Geld auch wert. Aber wenn man mal ein System probieren will, bevor man die Workstation kauft, kann man das mit etwas Handarbeit auch im Player machen.

Ich habe eine bootfähige CD als ISO-Image (in meinem Fall "C:\debian-6.0.2.1-i386-netinst.iso") und will von diesem Image ein neues Linux installieren:

1. Dupliziere eine bestehende VM oder lade eine VMware Appliance runter. Die VM kommt mit einer Konfigurationsdatei mit der Endung .vmx, mit einer virtuellen Platte mit der Endung .vmdk und anderen Dateien.

2. Im .vmx setze oder ändere die 4 Werte:

ide1:0.autodetect = "TRUE"

ide1:0.deviceType = "cdrom-image"

ide1:0.fileName = "C:\debian-6.0.2.1-i386-netinst.iso"

ide1:0.present = "TRUE"

3. Boote die VM durch Doppelklick auf die .vmx Datei

4. Beim Bootvorgang, bevor das Auswahlmenü erscheint und das Betriebssystem bootet, drücke F2 für BIOS-Setup SCHNELL.

5. Im BIOS-Setup die bootbaren Devices herum schieben bis die CDROM vor (über) der Festplatte steht. F10: Save and Exit

6. Jetzt sollte die VM automatisch nochmal booten und den Installer des ISO-Images anzeigen.

7. Nach der Installation ordentlich runterfahren

8. Das ISO-Image aus der .vmx Datei löschen:

ide1:0.fileName = ""

ide1:0.present = "FALSE"

happy_booting()

ejabberd crash solved by raising number of network connections

I was bothered by ejabberd crashes. Suddenly it started to crash quicky. The crash dumps said something like:

eheap_alloc: Cannot allocate 747325720 bytes of memory (of type "heap")

and:

eheap_alloc: Cannot allocate 934157120 bytes of memory (of type "old_heap").

I tried the installer, tried compiling erlang and ejabberd from source. I usually run ejabber in a virtual server. I tried on the native host. Nothing helped. We had a similar problem before with a memory bug related to mnesia tables where a server with 5000 clients reaches 3 GB in 5 days and crashes. That case was solved by upgrading the erlang runtime from R12B-3 to R12B-5.

But in this case it needed only 5 minutes and 1000 users to suck up the entire system memory. This was different. The number of about 1000 client connections was the constant of all crashes. @zeank suspected that the problem is the limit of open file descriptors, 1024 by default. The open file descriptor limit means also the max number of TCP (client) connections. Setting this to a higer value, e.g. 32.000 solves the problem.

In practice: insert into ejabberdctl
after:

ERL_MAX_PORTS=32000

the line:

ulimit -n $ERL_MAX_PORTS

_happy_ejabbering()

Applikationen sind auf Windows instabiler, als auf Linux

Warum? Weil Windows besser ist. Nochmal: Windows ist besser, deshalb sind Applikationen in der Praxis instabiler.

Windows bietet unendlich viele Systemkomponenten. Viele Dienste, die man im taeglichen Programmierleben braucht, bietet Windows als API. Das faengt an beim XML Parser, ueber HTTP mit Caching, URL-Behandlung, Embedded Browser, Verschluesselung, bis zu Sicherheitsdiensten und vielen anderen mehr. Als Programmierer bin ich froh, das alles nutzen zu koennen. Warum selbst implementieren, wenn das Betriebssystem das alles bietet? Auf Linux gibt es das alles nicht. Zumindest nicht als System-APIs. Natuerlich gibt es XML-Parser, Verschluesselung, HTTP-Libraries und Browser zum Einbetten. Aber man muss sie sich meistens im Netz beschaffen, selbst nochmals wrappen, moeglicherweise selbst kompilieren und dann dazulinken. Sehr muehsam, wenn man viel braucht, weil diese Komponenten auf Linux (oder Open Source) im allgemeinen eben aus verschiedenen Haenden kommen. Alle mit eigenen Coding Conventions und Interface Conventions.

Bei meinen Windows Anwendungen linke ich gegen LIBs, und benutzt werden dann vom Betriebssystem bereitgestellte DLLs. Bei Linux linke ich die libXX.a oder lege die Shared Libraries dazu. Meine-Windows Anwendungen haben damit Laufzeitabhaengigkeiten vom System. Meine Linux-Anwendungen sind selbst-konsistent. Jetzt kommt eine neue Betriebssystem Version oder (schlimmer) eine Bugfix Release (auch Service Pack genannt). Dann fliegen mir die Installationen der Kunden um die Ohren, und zwar fast nur die Windows Installationen.

Das kommt so: angenommen es gibt bei jedem Systemdienst, den ich verwende eine 0,1 % Wahrscheinlichkeit, dass sich die Semantik einer Schnittstelle, oder das Verhalten oder Abhaengigkeiten geaendert haben. Ich verwende 20 solcher Systemdienste. Ich habe 20 Kunden. Das ganze ueber 5 Jahre bei 8 Systemupdates pro Jahr plus 8 "signifikanten" Konfigurationsaenderungen des Kunden intern. Macht zusammen 30 Notsituationen in denen betriebskritische Dienste beim Kunden nicht laufen. Diese addieren sich zu den ueblichen Bugs, die es eh schon gibt und die erst bei "ungewoehnlicher" Bedienung auftreten. Bei jedem Kunden also zusaetzlich 1-2 mal. Fuer mich bedeutet das alle 2 Monate Emergency-Debugging am Livesystem waehrend der Betrieb eines Kunden steht.

Manchmal wuensche ich mir, Windows waere nicht so gut und ich wuerde alle Dienste wie auf Linux selbst einbinden muessen. Auf jeden Fall sollte man auch bei Windows statisch binden.

_happy_coding_