Einträge von Robert Klikics

Mit Proxmox VE kann man hervorragend virtualisieren und bekommt ein nettes Webinterface dazu, um die Konfiguration vorzunehmen. Deshalb kommt diese Lösung, vor Allem mit KVM, seit einiger Zeit auch bei den virtuellen managed Servern von RobHost erfolgreich zum Einsatz. Selbst Hochverfügbarkeit wird unterstützt - dazu in einem späteren Blogpost mehr.

Leider ist die Netzwerk-Config nicht immer ganz trivial, im Netz finden man haufenweise Fragen und Howto's zu diesem Thema. Zwar beschreibt das Proxmox-Wiki auch einige Szenarien, in der Praxis sind aber oft Host-IP und das Subnetz für die VM's verschiedene Netzbereiche.

Ein Problem bei vielen Rootservern ist, dass die Anbieter i.d.R. aus Sicherheitsgründen nicht zulassen, dass Netzwerk-Traffic über ein Interface von mehreren MAC-Adressen kommt. Dies hat zur Folge, das oft die normale Bridged-Lösung nicht funktioniert und eine etwas unschöne Routed-Konfiguration herhalten muss. Wir haben das Problem im Rechenzentrum zum Glück nicht, daher wird hier die Bridged-Variante vorgestellt.

Dennoch gibt es das "Problem", dass die IP des Proxmox-Host in einem anderen Netz liegt als das Subnetz für die virtuellen Maschinen. Daher klappt die ganz einfache Bridged-Konfiguration hier nicht, da wir ja keine IP verlieren wollen. Ansonsten könnte man natürlich dem Host die erste IP des Subnetzes geben. In Zeiten chronischer IPv4-Knappheit ist das aber wohl nicht im Sinne des Erfinders bzw. der RIPE

Also brauchen wir eine Point-to-Point Verbindung, so dass die VMs zum Gateway auch durchkommen und eine normal funktionierende Netzwerk-Config haben.

So sieht das Ganze dann unter Proxmox/Debian auf dem Host aus:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
address 62.xxx.xxx.43
netmask 255.255.255.255
gateway 62.xxx.xxx.1
pointopoint 62.xxx.xxx.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

Wichtig ist die Netzmaske von 255.255.255.255 sowie der pointopoint Eintrag (Achtung: nur mit einem "t"!). Mehr ist nicht nötig, d.h. es müssen keine expliziten Routen zu den VMs oder dem Subnetz gesetzt werden.

Innerhalb der VMS sieht das dann so aus (Debian/Ubuntu):

iface eth0 inet static
address 5.xxx.xxx.111
netmask 255.255.255.255
gateway 62.xxx.xxx.43 # VM Host
pointopoint 62.xxx.xxx.43 # VM Host

Bzw. so unter CentOS:

# File: /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"
BOOTPROTO="static"
IPADDR="5.xxx.xxx.111"
NETMASK="255.255.255.255"
GATEWAY="62.xxx.xxx.43"
HWADDR="D6:68:xx:xx:93:0B"
ONBOOT="yes"

# File: /etc/sysconfig/network-scripts/route-eth0

62.xxx.xxx.43 dev eth0 scope link
default via 62.xxx.xxx.43

Das war es auch schon, damit sollten alle VMs problemlos an das Netz angebunden sein.

In Kürze stellen wir hier unser Auto-Deployment Script für Proxmox vor. Bei Fragen einfach die Kommentare nutzen

Beim Entwickeln und Dokumentieren von Software mit Datenbankanbindung ist es unumgänglich, die Struktur der Daten zu visualisieren. Die Aktualisierung der Dokumentation erfordert allerdings viel Disziplin und Aufmerksamkeit. Im Termindruck kurz vor der Abgabe kommt es ab und zu vor, dass die Dokumentation auf die TODO-Liste gesetzt wird.

Auf der Suche nach einer automatisierteren Lösung sind wir an den ausgereiften Möglichkeiten der Graphviz community nicht vorbeigekommen. Eine einfache "DOT Language" ermöglicht es komplexe Grafiken und Strukturdiagramme mit unzähligen Einstellmöglichkeiten zu generieren.

In einem aktuellen Beispiel benutzen wir den dot-compiler um eine Datenbankstruktur als Anlage für ein Pflichtenheft zu visualisieren. Ein lediglich mit der Datenbankverbindung konfigurierbares Script erzeugt die DOT Datei. Tabellen, Spalten, Fremdschlüssel und Datentypen können ganz nach belieben in der einfach zu verstehenden DOT Language ausgezeichnet werden.

Das erwähnte Script in PHP findet ihr hier. Daraus wird ein Dotfile erzeugt, welches die hier dargestellte Grafik erzeugt.

Durch eine am Wochenden eingefügte Schaltsekunde gab es auf vielen Linux-Servern ein Problem mit der CPU-Load. Das ging von 100% CPU-Usage auf einem oder mehreren Cores bis zum kompletten Absturz. In der Verzweiflung haben viele Admins (so wie ich auch erstmal, bevor das Problem langsam klar wurde) mit Reboots die Rettung erzwungen. Inzwischen ist das Problem aber bekannt, so dass man zum Beispiel mit folgendem Befehl die Last wieder normalisieren kann:

date; date `date +"%m%d%H%M%C%y.%S"`; date;

Vor Allem betroffen waren Systeme mit MySQL und auf Java basierenden Applikationen (Tomcat etc.). Hoffen wir also, dass bis zur nächsten Schaltsekunde ein Fix direkt im Kernel integriert wird.

Der Webhoster Hetzner informierte seine Kunden sogar per Mail darüber, dass diese doch bitte mal ihre Server prüfen sollen. Durch den Anstieg der CPU-Load auf tausenden Servern ist dort der Stromverbrauch angeblich im 1 Megawatt (!) gestiegen.

Es lohnt also generell die Kontrolle des eigenen Servers.

Aus aktuellem Anlass hier ein Rewrite-Rule zur Google-freundlichen 301-Weiterleitung einer bestehenden Domain auf eine neue Domain via .htaccess oder direkt im Apache vHost:

RewriteEngine On
RewriteRule (.*) http://www.neue-domain.de/$1 [R=301,L]

Das Admin-Blog.com ist seit heute unterhalb von RobHost.de zu Hause - am Inhalt ändert sich aber natürlich nichts. Allerdings soll das Blog wieder mit mehr Leben befüllt werden, wobei die Mitarbeiter von RobHost helfen sollen (und auch wollen, so wurde mir versichert..). Denn täglich testen wir neue Tools oder beheben Fehler, die für die Nachwelt interessant sein könnten - sowohl aus dem Linux-Umfeld aus der Serveradministration bei unseren Kunden als auch in der Programmierung.

Die Idee schien einfach und gut zu sein. Einen vServer bei Server4You für weniger Euro im Monat mieten und dabei Serverstandort USA wählen. Dann über Squid (Proxy) entspannt Youtube und Hulu schauen. Soweit die Theorie.

In der Praxis stellt es sich allerdings so dar, dass offenbar die IP-Range (50.30.32.0 - 50.30.47.255) von Server4You bei YouTube auf Blacklist ist. Ich habe es nicht geschafft, ein hier gesperrtes Video über den Proxy zu schauen, stets werde ich als aus Deutschland kommend erkannt. Zuerst hatte ich die Browserkennung in Verdacht, aber selbst auf Konsole mit lynx kommt der Fehler:

Unfortunately, this video is not available in Germany because it may
contain music for which GEMA has not granted the respective music
rights.
Sorry about that.

Das Reverse-Lookup war der nächste Verdacht, denn das lautetet xxx.vserver.de - also wurde das auch fix auf eine .com Domain gelenkt - ebenfalls ohne Erfolg. Leider habe ich nirgends eine Info gefunden, warum das so ist. Bei einem anderen Anbieter, der direkt in den USA sitze, geht das Ganze problemlos.

Hat ein Leser vielleicht einen Hinweis dazu?

Nachdem kürzlich leider mein nagelneues iPhone 4S 32GB bei einem Einbruch gestohlen wurde (Kripo ermittelt und hat auch die IMEI, womit sie die Täter orten will bzw. es vielleicht sogar bereits getan hat), musste schnellstens Ersatz her. Natürlich war die erste Idee, bei der Telekom nachzufragen, denn dort habe ich schließlich mehrere Verträge und auch das 4S bezogen.

Nachdem meine Mail an die Kundenbetreuung nach einer knappen Woche nicht beantwortet wurde und die Hotline wie so oft durch Unwissenheit, was in solch einem Spezialfall zu tun sei, auffiel, war guter Rat teuer. Der heisse Tipp des Hotline-Menschen war, ich solle doch eine Mail an die Kundenbetreuung schreiben mit Diebstahlanzeige etc. Das hatte ich ja aber vor einer Woche bereits getan, sogar der Polizeibericht hing als Scan dran.

Gut, also mal den "Web 2.0 Support" der Telekom in Form des Twitter-Accounts @Telekom_Hilft bemüht. Dort wechseln sich anscheinend diverse Mitarbeiter ab und lesen die vorherigen Tweets zum Thema nicht, trotz dass ich extra immer brav "Reply" genutzt habe. Erst wurde mir ein weiterer neuer Vertrag, dann ein plötzlich ein Netlocked-iPhone 4 (ohne S) angeboten. So richtige Infos zu Preisen etc. bekam ich aber über Twitter nicht. Einen Vertrag habe ich ja aber schon, ich will einfach nur ein neues iPhone 4S und bin natürlich auch bereit, dafür zu zahlen. Die Versicherung kommt ja immerhin für den Neupreis des entwendeten Gerätes auf.

Eine weitere Woche später - ein neues 4S war längst bei Apple bestellt - kam dann noch ein Brief von der Telekom. Darin wurde mir allen Ernstes als "Ersatz für mein entwendetes iPhone 4S" ein netlocked iPhone 4 mit 32 GB für 729 EUR angeboten. Hallo? Ich zahle doch nicht den vollen Originalpreis eines veralteten iPhone 4, welches auch noch netlocked ist, obwohl mir ein 4S geklaut wurde. Irgendwie ziemlich sinnlos, dieses Angebot. Das iPhone 4S ist aber, warum auch immer, als Ersatz bei Diebstählen nicht verfügbar.

Inzwischen ist mein 4S von Apple bereits eingetroffen und die Telekom kann mich mal gerne haben, vermutlich am Ende der Vertragslaufzeit auch als Kunden. Ein wenig mehr Entgegenkommen bei einem Diebstahl sollte bei einem langjährigen Kunden doch drin sein, oder?

Ob das natürlich jetzt bei Vodafone oder O2 besser gelaufen wäre, kann ich nicht sagen. Der Ablauf bei der Telekom war zumindest eine herbe Enttäuschung.

Es soll ja vorkommen, dass ein Server von extern z.B. mit sehr vielen HTTP-Anfragen lahmgelegt werden soll. In so einem Fall ist guter Rat teuer, um Schaden vom Server und der darauf laufenden Websites bzw. Applikationen abzuwenden. Oft hilft einem auch der ISP dabei, verlassen kann man sich darauf freilich nicht. So wurde kürzlich bei einem Fall der Kunde zwar sogar von Hetzner über die DDOS-Attacke informiert Gegenmaßnahmen wurden aber nicht getroffen. Im schlimmsten Fall droht sogar die Sperrung der IP seitens Hetzner, was natürlich zum Teil auch nachvollziehbar ist.

Serverseitig kann man aber auch etwas tun, z.B. das kleine Shell-Script (D)DoS Deflate laufen lassen. Dieses kleine Script prüft ganz einfach per netstat, welche IP eine in der Config definierte Anzahl von Verbindungen überschreitet und sperrt diese wirksam direkt via iptables (diese Variante bevorzuge ich, es wird einfach DROP auf alle Pakete von der Quell-IP angewendet) oder via apf (Advanced Policy Firewall). Das Script hilft natürlich nur, wenn der Server noch erreichbar ist und arbeitet, d.h. wenn die Attacke nicht die die komplette Bandbreite verbraucht oder zu extrem ist.

Zur "Installation", die im Wesentlichen aus ein paar Downloads via wget und der Einrichtung eines Cronjobs funktioniert, holt man sich einfach wie auf der Website angegeben das Script install.sh von einem Server. Alternativ habe ich das Ganze hier nochmals als Mirror hinterlegt: ddos.tar (20 KByte). Den Tarball einfach z.B. nach /usr/local/ entpacken und es kann losgehen.

In der ddos.conf kann man via NO_OF_CONNECTIONS angeben, ab wievielen Verbindungen eine IP gesperrt wird. Das muss man einfach testen bzw. es kommt sehr darauf an, was auf dem Server normalerweise los ist. Bei zu niedrigen Werten läuft man natürlich Gefahr, auch "normale" User zu sperren. Mit BAN_PERIOD legt man dann fest, wie lange die IP gesperrt werden soll. Die eigene IP kann man übrigens mit einem Eintrag (neue Zeile) in der Datei ignore.ip.list whitelisten, 127.0.0.1 ist default auf der Whitelist

Jetzt kann man direkt ./ddos.sh ausführen und sieht auch direkt den Output den im Script ausgeführten netstat, das konkret so aussieht:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Alle IPs mit einer Connection-Anzahl > NO_OF_CONNECTIONS werden nun also für BAN_PERIOD Sekunden gesperrt. Ein Cronjob, der am besten im Abstand läuft, wie auch BAN_PERIOD gesetzt ist, rundet die Config ab.

Erfolge kann man dann ganz einfach z.B. via iptables -L -nv sehen. Diese recht rudimentäre Lösung kann bei kleineren Angriffen durchaus nützlich sein und hat sich schon mehrfach im Einsatz bewährt. Hilfreich sind übrigens auch weitere IP-Adressen und kurze TTL im DNS, um schnell reagieren zu können.

Sollte der Angriff nur auf einzelne Dienste wie z.B. Apache durchgeführt werden, lohnt auch ein Blick auf Fail2Ban.

Prozess-Informationen (ps oder pstree) und CPU- und Speicherauslastung eines Linux-Systems (top, vmstat oder free) gehören wohl zu den am häufigsten benutzten Kommandos eines Admin, der für Linux-Server verantwortlich ist. In den meisten Fällen schaut man nach einem SSH-Connect ja erstmal, was auf der Maschine so los ist, zu der man sich gerade verbunden hat.

Für mich ist das schon fast eine Obsession, schließlich bin ich Statistik-Fan. Neben dem auf jedem System vorhandenen top (welches man auch ganz gut anpassen kann) haben sich mit der Zeit noch ein paar andere Tools in meine tägliche Nutzung eingefügt, die auf keinem Server fehlen.

Klarer Favorit und inzwischen nahezu 100%iger Ersatz für top ist für mich htop. Grafisch ansprechender aufbereitet zeigt es die Auslastung der einzelnen CPU-Cores live mit einem Balken an und fühlt sich generell irgendwie moderner an. Ein weiterer Vorteil ist, dass htop schneller startet als top, da top erst einige Daten sammelt. Weitere Unterschiede sind hier aufgelistet. In Debian und CentOS ist es aus der Distribution problemlos zu installieren.

Das Schweizer Taschenmesser der "Tops" ist aber atop. Es zeichnet sich vor Allem dadurch aus, dass es deutlich mehr Statistiken und Daten liefert als top, nämlich z.B. "Disk Utilization" und "Network Utilization" je Prozess. Außerdem loggt atop periodisch diverse Systemparameter, die sich dann mit dem mitgelieferten Tool atopsar darstellen lassen. Dafür läuft dann allerdings permanent ein atop Prozess auf dem System.

Wer keinen eigenen Dienst laufen lassen möchte oder atop nicht nutzt, die Systemlast aber trotzdem permanent überwachen möchte, kann sich atsar mal anschauen. Hier wird im Grunde wie bei atop der Zustand periodisch geloggt und man kann im sich problemlos die Loadavg oder Disk Utilization der letzten Tage anschauen.

Weitere Live-Tools für diverse Anwendungsfälle, die ich häufig sinnvoll einsetze sind zum Beispiel apachetop, womit sich live sehen lässt, welche Dateien am häufigsten aufgerufen werden, oder iotop. Mit iotop kann man schön sehen, was gerade an I/O auf den Platten los ist und welche Prozesse dafür verantwortlich sind.

Zum Schluss noch der Hinweis auf ein "grafisches" Tool auf der Shell, womit sich der Traffic von Netzwerk-Interfaces ziemlich gut darstellen lässt: nload. Hiermit sieht man recht gut, was gerade an Traffic über ein bestimmtes Interface geht samt Durchschnittswerten.

Natürlich gibt es noch dutzende weiterer Tools. Hinweise oder Tipps in den Kommentaren dazu sind natürlich erwünscht

Nachdem meine Synology DS207 mit ihren 2x1TB (RAID1) Platten zu klein und auch generell zu langsam wurde, musste eine Neuerung her. Möglichst auch mit Verschlüsselung und mehr Kontrolle über das eigentliche System. Denn neben den Änderungen von Apple in der AFP-Implementation und der Tatsache, dass ältere Netatalk-Versionen dann plötzlich nicht mehr mit Lion reden wollten, nervte die Abhängigkeit vom Hersteller Synology schon extrem. Klar, nach ein paar Wochen kam dann das Update, so dass TimeMachine und AFP wieder korrekt funktionierten, mit einer eigenen Lösung hätte man das aber deutlich schneller hinbekommen.

Also fiel die Wahl auf einen "Home-Server" mit Atom-CPU, konkret auf den Acer EasyStore H341. Das Gehäuse ist mit 4 HDD Plätzen ausgestattet, so dass ich in meiner Ausbaustufe mit 4x2 TB Platten (Seagate Barracuda LP, ST32000542AS) auf 8 TB Plattenplatz komme. Die Intel Atom D410 mit 2 Threads und 1.66 Ghz samt 2 GB RAM ist zwar nicht der Renner, erschien aber erstmal ausreichend. Leider verfügt das Board nur über einen einzigen LAN-Anschluss (Realtek, GBit).

Viel schlimmer ist aber die Tatsache, dass kein VGA-Anschluss im Auslieferungszustand vorhanden ist. Somit ist es natürlich sehr schwer, andere Betriebssysteme als das bereits auf einer internen USB Disk (256 MB) vorhandenen Windows zu installieren. Abhilfe schafft ein optionaler VGA-Adapter (ca. 30 EUR bei Amazon), der samt Low-Profile-Adapter recht einfach in das Gehäuse gesteckt wird. Klappte hier sofort ohne Probleme. Außerdem sollte man wissen, dass nur USB und kein PS-2 vorhanden ist. Eine USB Tastatur sollte man also auch besitzen.

Mit einem USB-DVD ging es dann also an die Installation. Testweise kam erstmal Freenas 7 zum Einsatz, welches locker auf die interne 256 MB USB-Disk passte. Da aber in Freenas 7 die AFP-Implementation leider veraltet ist, war dies wirklich nur ein kurzer Test. Keine Chance, TimeMachine lauffähig zu bekommen. Außerdem war mit Freenas 7 und einem verschlüsselten ZFS-Volume die Performance grauenvoll, was wohl an der schwachen CPU lag (nur gut 15 MB/s Durchsatz!). Mit der kürzlich veröffentlichten Version 8 von Freenas - von einem 2 GB USB-Stick gebootet - ging zwar AFP reibungslos, leider ist dort aber noch keine Verschlüsselung implementiert. Außerdem hat Freenas grundsätzlich das gleiche Problem wie eine "fertige" NAS, nämlich die Abhängigkeit seitens der Herausgeber.

Daher fiel die Wahl nach den ganzen Freenas-Experimenten zuerst auf Debian Squeeze. Der Kernel wollte aber leider nicht mit der Hardware zusammenarbeiten (USB ging nicht, somit auch keine Tastatur etc.), so dass dann doch Ubuntu Server zum Einsatz kam. Hier lief die Installation sofort problemlos und die Hardware wurde komplett erkannt.

Bei der Installation entschied ich mich wegen der schwachen CPU ohne Hardware-AES-Support gegen komplett verschlüsselte Platten. Es kommen nunmehr mehrere "kleine" Crypto-Container mit je 1-10 GB zum Einsatz, die an die entsprechenden Stellen gemountet werden. Somit sind nur wirklich wichtige Sachen verschlüsselt und die Performance passt. Die Platten wurden in einem Software-RAID10 zusammengefasst und mit ext4 formatiert. Wegen der hohen Schreibrate durch Backups etc. erschien das hier als die bessere Wahl gegenüber RAID5, zumal 4 TB netto immernoch genug Speicherplatz sind. Zur Performance später mehr.

Nach der Installation des Grundsystems ging es an die Serverdienste. Hier standen in erster Linie AFP für die Macs und Samba für die Windows-Kisten zur Debatte. Samba war leicht konfiguriert, schließlich sollten nur 2-3 Shares eingerichtet werden. Die Nutzer wurden jeweils als normale Linux-User eingerichtet, wogegen sich dann die Dienste authentifizieren.

Ein wenig schwieriger war hingegen die Installation von netatalk für AFP. Wegen der Kompatibilität musste es unbedingt die neueste Version 2.1.1 sein, die natürlich nicht in der Distribution verfügbar war. Zum Glück stellt Stefano Rivera auf Launchpad fertige Pakete der neuesten Version für Ubuntu bereit, die sich problemlos installieren ließen. Ein paar Shares inklusive TimeMachine waren dann schnell eingerichtet und es funktionierte sofort problemlos. Und zwar genau so, wie ich es wollte, also mit Freigaben auf Gruppen- und Userebene.

Dank "avahi-daemon" wird die NAS auch von Macs als Server erkannt und kann direkt im Finder angesprochen werden. Außerdem wird die NAS noch als OpenVPN Gateway benutzt, was auch problemlos geht und unter Freenas schon ein kleiner Krampf war. Zur Überwachung kommt mdadm samt smartd zum Einsatz, womit sich Festplatten-Ausfälle zeitnah erkennen lassen sollten. Im Idealfall können ja in der RAID10-Konstellation sogar 2 der 4 Platten ausfallen.

Zur Performance kann ich mich weitestgehend positiv äußern. Nachdem der initiale Raid-Sync nach 30h (!) abgeschlossen war, erreiche ich bei lokalen Tests mit "dd" eine Schreibrate von über 140 MB/s im groben Schnitt. Via AFP sind es über GBit-LAN immernoch ausreichende 60 MB/s im Schnitt. Zu SMB liegen keine Messwerte vor, langsam erscheint es aber von Windows-PCs aus nicht. Das sind Werte, von denen ich mit der alten Synology-NAS nur träumen konnte.

Klar, die CPU könnte schon stärker sein. Bei simultanen Zugriffen merkt man schon, dass das der Flaschenhals ist. Für den Heimbereich oder, wie bei uns, im Büroeinsatz ist das Gerät aber ansich durchaus zu empfehlen. Denn für unter 500 EUR inkl. Platten hat man eine redundante, einigermaßen flotte und komplett selbst verwaltbare NAS-Lösung mit einem Linux-System, was sich perfekt anpassen lässt - so regeln z.B. diverse Cronjobs via "rsync" bei uns das Backup auf entfernte Server etc.

Ansich also eine durchaus empfehlenswerte Lösung. Es soll wohl einen Nachfolger (?) namens von Acer H342 geben, der dann eine Dualcore CPU hat. Scheint aber nur in den USA verfügbar zu sein. Zumindest gab es nirgends konkrete Infos oder Preise.

PS: Sollte Interesse an der konkreten Config unserer NAS bestehen, reichen wir diese gern nach und freuen uns über Kommentare.

Ein äußerst interessantes Projekt ist das Apache-Modul mod-authn-otp, womit sich Einmal-Passwörter gemäß dem RFC 4226 erzeugen lassen. Damit kann man hervorragend kritische Logins absichern oder Usern nur temporären Zugriff auf einen Loginbereich erlauben. Weitere Infos dazu gibt es auch auf der offiziellen OATH-Website.

Zuerst besorgt man sich den Quelltext von der Google-Code-Page des Projektes. Anschließend wird via ./configure; make modules ein .so Modul erzeugt, welches sich in Apache2 einbinden lässt. Mittels OTPAuthMaxLinger wird die maximale Gültigkeitsdauer eines Logins festgelegt (dies ist nötig, da das HTTP-Protokoll "stateless" ist).

Hier eine Beispiel-Konfiguration:

<Location /geheim>
AuthType basic
AuthName "Nutzer-Login (OTP)"
AuthBasicProvider OTP
OTPAuthUsersFile "/data/users/admin-blog/.apache22/htpasswd.otp"
OTPAuthMaxLinger 300
Require valid-user
</Location>

Zur Benutzung legt man eine spezielle .htpasswd-File nach der Vorlage hier an, welches man vorher in der Modul-Config unter OTPAuthUsersFile hinterlegt hat. Der Clou ist jedoch die Tatsache, dass man mit der iPhone-App "OATH Token" (AppStore-Link) nach Eingabe des Shared Secrets entsprechende Einmal-Passwörter generieren kann.

Wer nicht im Besitz eines iPhone ist, kann z.B. für 9,90 EUR ein kleines Gerät namens OTP C200 erwerben, welches die Passwörter ebenfalls erzeugen kann. Natürlich wäre es auch möglich, mit dem Algo aus dem RFC eigene Software dafür zu schreiben, uns hat aber die iPhone-App am besten gefallen.

160 GB Plattenplatz sind heute nicht mehr wirklich viel, für eine SSD sind aber größere Kapazitäten immernoch unverschämt teuer. Ein paar HD-Filme, Audiofiles oder dicke RAW's aus der DSRL und die SSD ist voll. Dabei ist es gerade für Fotos oder Filme nicht wirklich relevant, ob diese mit 200MB/sek oder 50 MB/sek gelesen werden können, wenn man sie nur normal anschauen will.

Als ich von der Lösung hörte, eine 2,5" HDD an die Stelle des Superdrive in das MacBook Pro einbauen zu können, musste ich nicht lange überlegen. Denn das ist die ideale Lösung, um das Problem der kleinen SSD umgehen zu können. Das Superdrive war eh fast nie in Verwendung, brennen oder rippen kann ich notfalls ja noch auf mit den Laufwerken aus anderen Rechnern wie dem MacMini.

Nach einiger Recherche im Netz über die sogenannten "OptiBays" war ich erstmal erstaunt, was da für Preise aufgerufen werden. Immerhin ist es eigentlich nur ein Plastik-Teil mit ein wenig Metall ohne eigene Chips oder Programmlogik. Da erschien mir der Preis von 99$ für das MCE OptiBay (die Referenz der OptiBays) deutlich zu hoch. Irgendwie etwas seltsam, wenn ein Adapter teurer ist als die darin befindlich Platte. Auf eBay gab es auch diverse Angebote, oft empfohlen wird auch das Kit von hardwrk.com. Letztendlich entschied ich mich aber für ein Kit von mac-optibay.de, was mit 44,90 EUR inkl. Versand zwar auch noch kein Schnäppchen, aber deutlich günstiger als die Konkurrenz ist. Schließlich braucht man ja auch noch eine Festplatte dazu.

Hier entschied ich mich für eine WD Scorpio Blue mit 750 GB und 5400 RPM zum Preis von rund 85 EUR bei Amazon. Auf die Geschwindigkeit kam es mir hier nicht so sehr an, wohl aber auf die Lautstärke. Denn mit SSD ist man es nicht mehr gewohnt, bei normaler Nutzung irgendein Geräusch aus seinem MacBook Pro zu hören. Mehr zur Performance der Platte später, denn erstmal ging es natürlich an den Einbau bzw. den Erhalt der bestellten Ware.

Denn mit dem Brief aus den Niederlanden mit dem OptiBay daran gabs bereits die erste Enttäuschung: Das Teil schien offenbar gebraucht zu sein und war einfach nur schlecht verpackt, wie man auf dem Foto sehen kann. Eine Anleitung lag nicht bei, ebenso kein Schraubendreher. Immerhin gab 4 Schrauben zum Einbau der Festplatte dazu, die man aber nicht wirklich braucht. Denn die Platte wird nur "eingesteckt" und dann mit dem beiliegenden Plastikteil fixiert. Normalerweise hätte man das Ganze sofort zurückschicken sollen, denn so eine Lieferung ist schon eine kleine Frechheit. Aber da man das Teil ja anschließend nicht mehr sieht und ich ganz heiss auf den zusätzlichen Speicher war, entschied ich mich für den Einbau. Der Hersteller ist übrigens "Fenvi" aka "Shenzhen Fenvi Electronic Technology Co., Ltd." aus China.

Dank der Anleitungen auf ifixit.com bzw. des MCE-Einbauvideos ging der Einbau eigentlich halbwegs gut über die Bühne. Ein wenig unschön ist allerdings die Tatsache, dass man die WLAN-Antenne samt Empfänger-Chip abbauen und ein wenig zur Seite "schieben" muss, aber auch das geht. Ansonsten sind nur einige wenige Schrauben am Superdrive zu entfernen, das Optibay selbst hält nur mit einer Schraube im MacBook Pro. Das ist aber kein Problem, da es ziemlich passgenau ist.

Nach dem anschließenden Neustart funktionierte erfreulicherweise das WLAN noch und auch die neue HDD wurde sofort erkannt. Mit zusätzlichen 750 GB steht nun endlich genug Platz zur Verfügung, die SSD konnte ich direkt entrümpeln und dort wieder 100 GB freimachen. Prinzipiell ist ein Optibay also eine sinnvolle Sache, wenn man mehr Speicher braucht, bei mac-optibay.de sollte man es allerdings vielleicht nicht unbedingt bestellen.

Wichtig ist noch der Hinweis, dass im Normalfall die Garantie erlischt, wenn man derartige Umbauten vornimmt. Allerdings gibt es für Apple wohl kaum eine Möglichkeit, dies nachzuvollziehen, wenn man es ordentlich macht und das Superdrive im Problemfall wieder zurückbaut. Alternativ kann man den Umbau auch bei einem Apple-Partner machen lassen, um die Garantie auf jeden Fall zu behalten.

Auf Wunsch gibts übrigens auch externe Gehäuse für das Superdrive zum Anschluss via USB 2.0 mit dazu, das habe ich mir aber erspart, da ich wie schon erwähnt das Superdrive nur 2x im Jahr benutze.

Abschließend noch ein paar Worte zur WD Scorpio HDD, von der ich ziemlich angetan bin. Sie ist nahezu unhörbar bei Aktivität, verbraucht wenig Strom und ist dank Advanced Format (was von OS-X ja zum Glück unterstützt wird) mit 750 GB wunderbar groß. Auch die Performance von rund 90 MByte/sec beim Lesen und Schreiben ist mehr als ausreichend für eine 2. HDD im MacBook Pro und für eine 5400er HDD ein ziemlich guter Wert.

Hier noch die Auswertung eines Benchmarks (AJA System Test) bei deaktiviertem Cache:

Im Sommer soll Mac OS X Lion erscheinen und die besten Sachen von iOS vom iPad bzw. iPhone auf den Mac bringen. Dass man das unter Umständen als "Poweruser" nicht will, ist wieder eine andere Geschichte! Ich bin zumindest mit der Bedienung meines Mac relativ zufrieden und brauche, zumindest aus heutiger Sicher, keine Ordner oder Icons in Form eines Launchpad, um meine Programme zu starten. Das übernimmt in 80% der Fälle das Dock, die restlichen 20% der Files oder Dokumente öffne ich via Spotlight.



Dennoch kann man Lion recht angenehm benutzen, das Launchpad ist ja nur auf Wunsch sichtbar und auch weitere iOS-Sachen wie das inversive Scrolling kann man deaktivieren. Umgekehrtes Scrolling macht eigentlich mit der Maus keinen Sinn, mit deinem Touchpad oder halt auf dem iPad sieht das schon anders aus. Jedenfalls für mich eines der verwirrendesten Feautures in Lion.


Eine gute Sache hingegen ist das neue Mail, das deutlich an Übersichtlichkeit gewonnen hat. Generell sieht das neue Interface von Lion mit seinen eckigen Buttons sehr schick aus und ist dank Aqua weiterhin sofort als Mac OS erkennbar. Die aus iOS bekannten "overlay Scrollbars" sind in Ordnung, einen Mehrwert stellen Sie allerdings nicht wirklich dar. Schick sind die "Popovers", die vermehrt zum Einsatz kommen. Weitere Neuerungen stellt Apple auf developer.apple.com vor.


iCal wurde auch überarbeitet und bietet nun endlich auch eine Jahresansicht. Leider sind dort offenbar aber keine Termine zu erkennen. Da wäre es schön gewesen, wenn die Tage mit Terminen irgendwie hinterlegt sind. Aber das kommt vielleicht in der Final noch. Neue Termine kann man nun im Wortlaut anlegen, so führt die Eingabe von "nächsten Montag 19:00 Essen" dazu, dass ein solcher Termin angelegt wird. Das funktionierte in ersten Tests wirklich gut und gefällt.



Versionierung bietet die Möglichkeit, auf frühere Versionen eines Dokumentes zu springen. Quasi wie Timemachine für Dokumente. Allerdings muss das Programm diese Technik unterstützen. Die Hoffnung, dass Apple hier vielleicht auf Snapshots ala ZFS oder gar ein neues Filesystem setzt, hat sich leider nicht bestätigt. Es kommt weiterhin HFS+ zum Einsatz, für die lokale Versionierung wird ein "mtfs" mit der Größe der normalen Festplatte angelegt. Ob die Sicherung bitweise funktioniert bzw. wie sie generell funktioniert, kann mit Sicherheit noch nicht gesagt werden. Das System ist aber hoffentlich effizienter als die Sparsebundle-Login von Timemachine. Im Hintergrund läuft für die Versionierung der Dienst "mtmd" bzw. "mtfs", der bisher bei einigen Nutzern hin und wieder für volle CPU-Auslastung sorgt.

Jetzt meldet sich das System bei uname -a nun mit "Kernel 11.0.0" und 64Bit:

Darwin Lion.local 11.0.0 Darwin Kernel Version 11.0.0: Sat Feb 19 19:29:29 PST 2011; root:xnu-1699.21.15~1/RELEASE_X86_64 x86_64

Unter Snow Leopard sieht das so aus:

Darwin mbp 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386 i386

Weitere Neuerungen in Lion, vor Allem am UI, hat Oliver von aptgetupdate.de ganz gut zusammengefasst. Es gibt aber sicher noch viele Sachen, die man in 1-2 Testtagen auf einer virtuellen Maschine nicht mitbekommt. So kann ich auch wenig über die echte Performance sagen. Alle Systemdienste und Apple-Programme außer iTunes (!) laufen nun auch nativ im 64Bit-Modus. Dass iTunes nicht erneuert wurde ist hingegen eher schwach. Hier muss dringend mal eine Frischzellenkur her!

Als Fazit würde ich bisher sagen, Lion ist "ok". Mehr aber eigentlich auch nicht. Ein wenig mehr hatte ich mir ehrlichgesagt erhofft, vor Allem "unter der Haube". Klar, die Versionierung ist in Ordnung, Mail ist besser etc. aber irgendwie klingt das bisher nach 10.6.7 als nach 10.7. Aber bis zur Final ist ja auch ein wenig Zeit.

Auf Wunsch kann ich in der VM gern Sachen testen, die euch interessieren. Tipps oder Entdeckungen in den Kommentaren sind ebenfalls ausdrücklich erwünscht.

Statistik-Tools gibt es viele, leider fehlt uns immernoch ein richtig guter Ersatz für Google-Analytics, der auf dem eigenen Server auch nur ansatzweise so performant läuft, wie es GA in der Google-Wolke tut. Nachdem Piwik aufgrund mangelnder Performance in der Vergangenheit leider nicht überzeugen konnte bekam kürzlich OWA (Open Web Analytics) eine Chance, sich zu beweisen. Als Härtest musste eine gut besuchte Seite mit mehreren mio. PI am Tag herhalten.

OWA stellt sich auf den ersten Blick genauso dar wie Piwik, das heisst ein PHP-Frontend mit MySQL-Backend sowie die Erfassung der Statistiken durch Einbindung eines JavaScripts in die Zielseite. Kennen wir ja von Google Analytics, das System ist auch durchaus einfach zu implementieren. Optional kann man die Statistiken auch direkt via PHP erfassen, wir nehmen aber für den Test die JS-Variante. Leider funktionierte der Login im Backend mit Safari nicht, unter Firefox jedoch problemlos

Im Vergleich bietet OWA ein sehr interessantes Feauture, das Piwik vermissen lässt, nämlich das sogenannte "Event Queueing". Damit ist es möglich, die Logdaten nicht direkt in die MySQL-Datenbank, sondern in ein normales Logfile (die Queue) schreiben zu lassen. Anschließend kann man dann per Cronjob oder manuell durch einen PHP-CLI-Aufruf die Analyse dieses Logfiles starten. Das klingt auf den ersten Blick nach einer eventuellen Lösung für die Performance-Probleme, die OWA wie Piwik beim direkten Schreiben der Logs in die Datenbank hat.

Denn auch bei OWA stieg die Serverlast trotz optimiertem MySQL und einer recht potenten Serverbasis (Dual Dualcore Opteron mit 2.6 GHz, 8 GB RAM, Linux, Lighty mit Fast-CGI und xCache) die Loadavg innerhalb weniger Minuten auf über 100.0 und der Server wurde unbenutzbar. Dies ist einfach den tausenden Requests pro Minute geschuldet, die die Datenbank einfach nicht weggeschrieben bekommt. Genau dieses Verhalten stellte sich ja damals auch bei Piwik dar.

Mit der Event-Queue blieb die Last im Rahmen (Loadavg unter 2.0), das Plaintext-Logfile wird also schnell geschrieben und der Lighty bekommt die vielen PHP-Anfragen gut abgearbeitet. Wie allerdings Kollisionen beim gleichzeitigen Zugriff auf das Logfile verhindert werden, ist unklar. Im schlimmsten Fall könnte das File dann zerstört werden, schließlich passiert dies ja auch alles via PHP. Man müsste man den Code durchsehen, ob da konkret Locking benutzt wird oder wie das nun genau funktioniert. Im Test wurde das File zumindest recht problemlos geschrieben, in 10 Minuten sammelten sich so um die 250 MByte im Log an.

Diese Daten galt es nun auszuwerten, wofür man "php cli.php cmd=processEventQueue" auf der Shell bemüht. Im Hintergrund wird das aktuelle Log dabei in ein Tempfile verschoben und ein neues Logfile begonnen, so dass es während der Auswertung nicht zu Datenverlust kommt. Eine nette Logik, schließlich muss man die Auswertung regelmäßig anstoßen, idealerweise dann als Cronjob.

Wo wir auch schon beim größten Nachteil von OWA wären: Die Auswertung ist furchtbar langsam! Für die 250 MByte aus 10 Minuten Logging in die EventQueue brauchte OWA zur Analyse über 30 Minuten bei guter Datenbank-Auslastung und mäßiger Serverlast (Loadavg um 4.0). Teilweise verhing es sich offenbar auch in einer Endlosschleife, so dass man den Prozess killen musste. Und jeder weitere Durchlauf war deutlich langsamer als der vorherige, da in der MySQL-DB ja immer mehr Daten bewegt werden mussten. Dass es keinen Sinn hat, wenn die Auswertung der Daten länger dauert als der eigentliche Erfassungszeitraum war, ist wohl klar

Fazit:
Auch OWA ist für den Einsatz bei Seiten mit hohem Traffic nicht benutzbar, da hilft auf die EventQueue nicht. Der Ansatz mit dem Logfile ist dennoch gut. In der Benutzung und im Interface ähnelt es Piwik ziemlich, Piwik gefällt aber ingesamt besser und stellt sich aufgeräumter dar.

Eine Alternative für GA ist also weiterhin gesucht ...

So ein Dock ist eigentlich eine wirklich gute Sache. Meine Ex-Dell Notebooks zumindest habe ich eigentlich ganz gerne im Dock betrieben, da man sich die tägliche Neu-Verkabelung von LAN, Strom, USB und VGA damit sparen konnte. Nach dem Umstieg auf ein MacBook Pro vermisst man das auch ein wenig, denn trotz Cinema-Display muss man mehrfach täglich mindestens 3 Kabel an- und abstecken (Strom, Display-Port und USB). Außerdem sieht es immer ein wenig unordentlich aus, wenn die Kabel so auf dem Tisch zu sehen sind.

Einen Workaround dafür bietet der US-Hersteller Henge Docks an. Deren Docks nehmen sowohl das kleine MacBook als auch alle Varianten des MacBook Pro hochkant (!) in einem Plastikständer auf. Ein echtes "Dock" ist es eigentlich nicht wirklich, da es keinerlei Anschlüsse nach außen stellt. Wie auch, dem MacBook fehlen ja echte Dock-Anschlüsse auf der Unterseite, wie sie z.B. Dell-Notebooks haben.

Also muss man seine normalen Kabel im Dock befestigen. Dies geschieht mittels Inbusschrauben. Je nachdem, was man für Anschlüsse nutzen möchte, gilt es also diverse Kabel im Dock zu befestigen. In meinem Fall zur Nutzung an einem Apple Cinema-Display sind dies also USB, Strom und Display-Port. Dies ist auch schon ein recht großer Nachteil an der Sache, denn will man ein anderes MacBook an diesem Display betreiben, muss man natürlich die ganzen Schrauben lösen.

Ansonsten passt das MacBook Pro ziemlich gut in das Dock und lässt sich leicht herausnehmen bzw. reinstecken. An die Optik gewöhnt man sich, dennoch ist die Lösung im Hochkant-Modus ein wenig "strange". Das SuperDrive funktioniert in der Stellung offenbar problemlos inkl. Auswurf nach oben, intensive Tests wurden allerdings nicht durchgeführt.


Probleme gibt es allerdings auch, so funktionierte beim Test mit einem "Display-Port zu DVI Adapter" die Erkennung des Monitors teils nur sporadisch. Der Monitor blieb teilweise einfach aus. Abhilfe schaffte dann nur die etwas nervige Prozedur, das MacBook herauszunehmen, aufzuklappen, den Monitor anzustecken, das 2. Display zu konfigurieren und dann wieder in das Dock zu stecken. Dass das keinen Spaß macht, kann man sich ja denken. Mit dem Cinema-Display gibt es allerdings keinerlei Probleme, das wird stets erkannt.

Ein weiteres Problem gab es mit Bluetooth, konkret brach die Verbindung zur MagicMouse oft ab. Außerhalb des Docks gab es diese Probleme nicht. So richtig nachvollziehbar ist das Problem technisch allerdings nicht, da laut ifixit.com der BT-Empfänger in der rechten oberen Ecke sitzt. Und diese Ecke steht ja oben aus dem Dock heraus.

Insgesamt aber ein ganz nettes Dock für das MacBook [Pro] (und wohl auch das eizig derzeit verfügbare Modell) mit einigen Schwächen bzw. Designfehlern, die aber natürlich auch daran liegen, dass Apple die Nutzung im Dock nicht wirklich vorsieht. Samt Zoll und Versand nach Deutschland ist unser Test-Dock für rund 90 EUR bei Henge Docks aus den USA zu haben.

Heute ist es mal wieder so weit, dass ich Apple verfluche und tatsächlich in Erwägung ziehe, keine Computer mehr aus diesem Hause zu kaufen. Morgen sieht das sicher wieder anders aus, zumal auch andere Hersteller derartige Probleme habe. Aber der Reihe nach:

Bei meinem MacBook Pro Late 2009 fehlt einer der 4 Gummifüße am Boden. Dies fiel mir gestern auf und ich weiss leider nicht, wie oder wo er abhanden kam. Aber so schlimm fand ich das gar nicht, denn ich habe ja Apple Care für dieses Gerät abgeschlossen und die würden sicher eine unproblematische Lösung für das Problem haben.

Das erwies sich leider als Tagtraum. Ein nette, wenn auch mit mangelhaften Deutsch-Kenntnissen ausgestattete, Dame an der frecherweise kostenpflichtigen Apple-Care Hotline sicherte mir zu, dass der lokale Apple-Partner um die Ecke die Füße da hat und i.d.R. auf Kulanz gratis tauscht. Das klang toll. Leider wusste der Apple-Partner davon nichts und versicherte mir, dass es die Gummifüße nicht einzeln gibt. Abhilfe schafft wohl nur eine neue Unterseite, die mit mindestens 80 EUR einschlägt. Das erschien mir irgendwie zuviel für einen fehlenden Gummifuß. Immerhin "friemelte" der nette Herr einen Gummifuß von einem defekten Unibody-MacBook Pro ab und gab ihn mir mit.

Der passte jedoch nicht, da man die Füße nicht unbeschadet aus einem intakten Unterboden herausbekommt - warum auch, schließlich ist das sicher nicht vorgesehen. Aus Frust folgt ein weiterer kostenpflichtiger Anruf bei Apple-Care. Diesmal hatte ich einen netten Mann am Telefon, der sogar meine Sprache konnte. Ironischerweise versicherte er mir ebenfalls, dass es die Füße nicht einzeln gibt und äußerte ein wenig Unverständnis über die Aussage seiner Kollegin von vorher. Selbstverständlich sind solche Sachen übrigens nicht von Apple-Care abgedeckt, wäre ja auch zu schön gewesen.

Jetzt hatten sie mich tatsächlich so weit, dass ich für 80 EUR beim lokalen Partner einen kompletten neuen Unterboden bestellen wollte. Schließlich habe ich hier ein MacBook Pro für über 2000 EUR rumliegen und es kann wohl nicht angehen, dass dieses Teil auf dem Tisch kippelt.

Doch der Schock folgte beim optimistisch getätigten Bestell-Anruf für den Unterboden. Ich sollte mein MacBook Pro dann mal vorbeibringen und könnte es in einer Woche wieder abholen. Hallo, gehts noch? Die Apple-Richtlinien erfordern es explizit, dass das MacBook Pro die ganze Zeit dort bleibt. Meine Vorstellung war allerdings, dass ich einfach den neuen Unterboden bekomme und diesen dann selbst montiere. Die 10 Schrauben dafür bekomme ich gerade noch verarbeitet. Eine Woche ohne mein Arbeitsgerät mit all seinen Daten drauf sind eigentlich unmöglich.

Ende vom Lied ist jetzt, dass ich den geschenkten Gummifuß nun soweit mit Feile und Schere bearbeitet habe, dass ich ihn mit Sekundenkleber ankleben konnte. Ob und wie lange das hält kann man leider nicht wissen. Auf jeden Fall mal wieder nicht gerade ein Service-Highlight von Apple. Bei dem Preis für Apple-Care eigentlich eine Frechheit.