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

Gestern hat uns Apple mit dem Update auf OS-X 10.6.4 beglückt, wo es wohl hauptsächlich um zahlreiche Sicherheitsupdates sowie einige kleine Verbesserungen ging. Neue Feautures sind mir zumindest noch nicht direkt aufgefallen.

Beim Start der Mail.app wird allerdings die komplette Mail-DB aktualisiert. Das ging dank SSD rasend schnell bei mir. Leider erschien danach der Hinweis, dass Growlmail nicht mehr funktioniert. Das lässt sich aber relativ einfach beheben:

Zuerst Mail.app beenden, dann den Ordner GrowlMail.mailbundle von ~/Library/Mail/Bundles/Bundles (deaktiviert)/ nach ~/Library/Mail/Bundles/ verschieben. Anschließend sind noch folgende 2 UUIDs zu den SupportedPluginCompatibilityUUIDs hinzuzufügen:

defaults write ~/Library/Mail/Bundles/GrowlMail.mailbundle/Contents/Info SupportedPluginCompatibilityUUIDs -array-add "E71BD599-351A-42C5-9B63-EA5C47F7CE8E"
defaults write ~/Library/Mail/Bundles/GrowlMail.mailbundle/Contents/Info SupportedPluginCompatibilityUUIDs -array-add "B842F7D0-4D81-4DDF-A672-129CA5B32D57"

Anschließend sollte GrowlMail wieder wie vorher funktionieren. Besten Dank an langui.sh für den Hinweis, dort gibt es übrigens auch ein fertig gepatchtes Bundle zum Download, falls ihr keine Lust habt, die 2 Befehle im Terminal auszuführen

PS: Safari ist natürlich, wie bei jedem Update, auch wieder schneller geworden!
PPS: Die UUIDs für den Fix in 10.6.7 findet ihr in den Kommentaren!

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.

Viele unserer (Web)Server loggen auf einen zentralen Logging-Server, der via syslog-ng die Logdaten einsammelt und einheitlich zur Verfügung stellt. Besonders bei Webclustern, wo ein Loadbalancer die Anfragen auf diverse Server verteilt, ist z.B. ein zentrales Apache-Logfile u.A. für die Logfile-Auswertung wünschenswert. Außerdem kann man dann mit logcheck nette Security-Auswertungen etc. für alle Server gemeinsam machen und muss dies nicht auf jeder Kiste einzeln tun.

Bisher lief der Logging-Server auf Linux-Basis, nachts wurden die zig GByte großen Logfiles des letzten Tages dann komprimiert. Das hat soweit auch ganz gut funktioniert, nur leider wird es an der Stelle nervig, wenn man in den Logfiles der letzten Monate etwas sucht und dann beispielsweise 200 GByte an GZIP-Files durchsuchen muss. Ganz davon abgesehen sorgte die nächtliche Komprimierung via logrotate (GZIP) doch für eine ordentliche Serverlast über Stunden hinweg (CPU und I/O gleichermaßen).

Als Lösung fiel die Wahl jetzt auf FreeBSD 8.1 als OS für den Loghost. Filesystem ist, wie könnte es anders sein, nun ZFS! Und dank "eingebauter" Komprimierung ist die Verwaltung der Logfiles jetzt deutlich angenehmer. Auf Filesystem-Ebene via GZIP komprimiert ergibt sich für den Nutzer kein Nachteil, die CPU-Last wird nicht mehr auf die Nacht verteilt, sondern permanent beim Schreiben der Files - aber eben kaum merklich, da konstant und minimal. Die Kompressionsrate ist identisch mit der früheren Kompression unter Linux. Neben GZIP stand noch LZJB als Methode zur Auswahl. Das soll wohl schneller sein, komprimiert aber nicht so akkurat wie GZIP.


Wie erstellt man nun ein solch komprimiertes Filesystem via ZFS?

Man erstellt einen zpool z.B. als RAID-1 via:

zpool create data mirror /dev/da1 /dev/da2

Nun erstellt man das Filesystem via:

zfs create -o compression=gzip -o mountpoint=legacy data/varlog

Mit -o gibt man die Optionen an, hier gzip. Default ist die Kompression auf Stufe 6 (=ausgewogen) eingestellt, man könnte aber auch gzip-9 für maximale Kompression verwenden.

mountpoint=legacy bedeutet, dass ZFS sich nicht um die Verwaltung des Mountpoints kümmert. Default würde dies sonst unter /data/varlog gemountet werden. Da wir aber /var/log haben möchten, behelfen wir uns mit diesem Eintrag in der /etc/fstab:

data/varlog /var/log zfs rw 1 0

Tricky war allerdings, dass der Installer selbst dies nicht zur Verfügung gestellt hat (zumindest haben wir es nicht gesehen..). Daher wurde normal mit UFS installiert und anschließend die neue Partition erstellt, gemountet und mit den Inhalten aus der alten UFS-Partition gefüllt. Eine etwas umständliche Methode, die allerdings problemlos funktioniert hat.

Die Kompression kann man via ls und du sehr gut nachvollziehen, da ls die ursprüngliche Dateigröße anzeigt. Mit du sieht man dann die tatsächliche Größe auf Platte:

# l -h apache_central.log-20110109
-rw------- 1 root wheel 3.9G Jan 9 06:25 apache_central.log-20110109

# du -sh apache_central.log-20110109
412M apache_central.log-20110109

Insgesamt ein sehr nettes Szenario, um Speicher zu sparen und Logfiles dauerhaft vorzuhalten, ohne sich durch viele GZIP-Files wühlen zu müssen. Die Performance ist ingesamt gut, es gibt eigentlich keine Probleme trotz sehr großer Logfiles, die täglich anfallen.

Ich bin ja ein gebrandmarktes Kind, was Internet-Geschwindigkeit angeht. Schließlich hatte ich dank meiner vorherigen "schlechten" Wohnlage (hier ein Posting aus 2006 dazu) noch lange nur ISDN zur Verfügung, wo meine Kollegen alle schon mind. 6000er DSL oder sowas hatten. Der blanke Hass war das, ehrlich. Immerhin konnte ich Downloads auf Arbeit tätigen, denn da gab es schon lange eine 100MBit/s Leitung danke des direkten Anschlusses an unser Rechenzentrum. Schon eine echte Flatrate war damals ein Traum, von 10, 50 oder gar 100Mbit/s zu Hause konnte ich nur träumen.

Die letzten Jahre 3 hatte ich dann allerdings erst 16.000er DSL von Alice und bisher eine 32.000er Leitung via Kabel Deutschland. Allein der Upload von nur 1-2 MBit/s nervte, besonders beim Abgleich von Fotos zu Flickr oder anderen Diensten mit entsprechend hohem Datenaufkommen von zu Hause aus.

Da kam das neue Angebot von Kabel Deutschland mit bis zu 100MBit/s down und 6Mbits/s up für mich wie gerufen. Es ist erst seit ca. einer Woche hier in Dresden verfügbar, daher gehöre ich quasi zu den ersten Kunden vor Ort, die den Spaß nutzen dürfen.



Und es ist wirklich ein toller Spaß, denn die versprochene Datenrate wird wirklich fast erreicht. Dazu trägt einerseits das neue Cisco-Kabelmodem (wow, endlich Markenware auch zu Hause) Cisco EPC3212 mit Gbit-Ethernet und andererseits natürlich meine Apple Time Capsule mit 5GHz WLAN @ 300Mbit/s bei. Ein normales 54MBit-WLAN würde natürlich hier nicht mehr reichen.

Insgesamt also soweit sehr empfehlenswert und, wenn der Speed dauerhaft so hoch und konstant verfügbar ist, preislich durchaus in Ordnung. Klar, der Upload könnte noch schneller sein, aber das wird wohl privaten Haushalten noch lange vorenthalten werden.

Das Advanced Format für Festplatten bringt mehr Platz für Daten auf dem gleichen Platz einer Festplatte. Eine wirklich gute Sache, die aktuell vor Allem Western Digital voranzutreiben scheint (eine WD "Fachinformation" dazu gibt es hier als PDF).

Versprochen wird bessere Fehlerkorrektur und Kompatibilität mit Windows sowie OS-X. Leider taucht hier Linux vorerst nicht auf, da das Advanced Format erst ab 2.6.31 unterstützt wird. Die meisten Server-Distributionen (Debian stable etc.) setzen jedoch natürlich nicht auf einen so aktuellen Kernel.

Dieses Problem hatten wir bereits mit mehreren Systemen sowohl unter Linux aus auch unter FreeBSD. Trotz RAID-10 mit 4 WD20EARS 2 TB Platten und aktueller Hardware kamen wir unter Debian kaum über 20 MByte/sec Transferrate (dd mit oflag=direct, mit oflag=dsync sogar nur 13 MByte/sec). Auch die Anpassungen der Blocksize via fdisk halfen leider nicht weiter, da i.d.R. bei einem Server ja noch ein RAID-Controller dazwischenhängt. Was sich dort genau abspielt, konnten wir nicht herausfinden. WD beschreibt dieses Vorgehen zwar selbst auf seinen Support-Seiten, Hilfe brachte es aber dennoch nicht.

Ob dieses Vorgehen bei direkt angeschlossenen Platten, also ohne RAID-Controller, womöglich zu einem normalen Datendurchsatz führt, bleibt mangels Test derzeit hier noch unbeantwortet. Für die meisten Serversysteme ist dies allerdings sowieso nicht relevant, da dort normalerweise ein RAID erwünscht ist.

So blieb in allen Fällen bisher nur der Einsatz anderer Platten, die nicht das Advanced Format einsetzen. Das gleiche RAID 10 hat nun dank Seagate-Platten locker den 6-fachen Durchsatz. Generell ist, sofern man nicht eine Distribution mit aktuellem Kernel wie Ubuntu 10.04LTS mit 2.6.32 benutzt, die Verwendung von "normalen" Festplatten wohl die bessere Wahl.

Immer mehr ISPs packen in ganz normale Server-Angebote eine SSD bzw. man kann sie optional dazu buchen. Jüngst hatten wir ein Kundensystem zur Administration, wo das der Fall war. Der Server hatte konkret 4 x 1 TB SATA II Platten (RAID 10) an einem RAID-Controller und eine Intel 80 GB SSD direkt am SATA-Controller. Der Kunde hatte natürlich gehofft, mit der SSD seinem Server den gewissen Performance-Kick geben zu können, denn bekanntermaßen sind SSDs einfach unglaublich schnell.

Der ISP hatte spontan direkt das Linux-Sytem auf der SSD installiert, wohl um die tolle Performance beim Bootvorgang etc. auszunutzen. Das ist ja auch gut und schön, nur wozu hat man denn dann ein RAID 10? Wenn die SSD mal ein Problem hat, war es das für den Server. Für ein Produktivsystem eher ungeeignet. Also installierten wir das System auf dem RAID 10. Doch was nun auf die SSD? Die Datenbank wäre eine gute Sache, doch auch hier mangels Redundanz nicht empfehlenswert. Denn einen kompletten Datenbank-Fail nach SSD-Problemen will man natürlich auch nicht haben. Also die DB auch auf das RAID 10. Selbiges gilt für Web- und Anwendungsdaten.

So bleibt eigentlich nur, die SSD für Swap oder /tmp bzw. andere Temporäre-Daten wie PHP-Sessionfiles etc. zu verwenden. Dafür lohnt sich aber eigentlich das Ganze nicht. Wären allerdings 2 SSDs im RAID1 drin, sähe die Sache schonmal anders aus.

Das dachte sich wohl auch Serverloft und schreibt bei EINER SSD direkt mal RAID1 dahinter - was auch immer das bedeuten soll. Der Preis ist allerdings wirklich sehr gut, wobei die oben genannten Probleme natürlich auch hier wieder mangels einer 2. SSD wieder zutreffen.

Fazit:
SSD im Server zum Produktiveinsatz macht eigentlich nur unter speziellen Bedingungen (viele temp. Files, Caching etc.) oder als RAID mit mind. 2 SSDs Sinn.

In den Medien las man die Tage recht viel über den neuen Browser "RockMelt". Für RockMelt verantwortlich ist unter Anderem Netscape-Gründer Marc Andreessen. Grund genug, sich die Software auf Basis der freien Chrome-Variante "Chromium" mal anzuschauen. Ein Einführungsvideo der Entwickler findet ihr auf YouTube.

Dies ist derzeit allerdings noch nicht so einfach nötig, denn der Download ist nur über einen Beta-Invite möglich. Sinn ist wohl, das Ganze interessanter zu machen. Ansonsten kann ich mir diese Methode nicht erklären. Netterweise erhielt ich kurzfristig einen Invite und durfte mir den Browser in der Mac-Version herunterladen. Übrigens ist sowohl für die Benutzung als auch für die Anmeldung zur Betaphase von RockMelt ein Facebook-Account erforderlich. Etwas seltsam, aber schließlich ist das ja ein Facebook-Browser.

Auf den ersten Blick sieht es aus wie Google's Chrome, bei jedem Start des Browser wird man jedoch direkt zu Facebook connected. Dazu ist initial die Freigabe so ziemlich aller Profildaten für die RockMelt-App nötig. Das finde ich eher nicht so toll, zumal ich auch noch keine Möglichkeit gefunden habe, wenigstens das Passwort zum Facebook-Account beim Start manuell eingeben zu können. Im Grunde ist man sofort in meinem Facebook-Profil, wenn man den Browser startet.

Durch die optionale Verknüpfung mit Twitter ebenso auch bei Twitter. Die Integration ist aber nicht wirklich toll gelungen, so findet sich derzeit offenbar nicht einmal die Möglichkeit, direkt Tweets abzusetzen. Somit muss man immer den Umweg über twitter.com oder eine andere Twitter-App gehen.

Das Interface von RockMelt ist Chrome sehr ähnlich. Links und rechts finden sich jedoch die als "Edges" bezeichneten Infoleisten mit allen derzeit bei Facebook aktiven Freunden links und Buttons für Facebook und Twitter rechts. Auf Wunsch kann man durch einen Klick auf das Profilbild links direkt einen Chat starten, dem Nutzer eine Nachricht schreiben oder dessen Pinnwand zuspammen. Rechts zeigt sich auf Wunsch die Facebook- oder Twitter-Timeline (siehe Screenshot).

Ganz fehlerfrei scheint die Beta noch nicht zu laufen, zumindest bekomme ich bei jedem Start diesen Fehler:


Mein Fazit

Ich brauche es nicht. Klar, ich schaue mehrfach täglich bei Facebook rein, lese via installiertem Echofon öfter Twitter mit und interagiere auch gern mit meinen Freunden über diese Kanäle. Permanent online zu sein bzw. damit berieselt zu werden ist mir im Browser aber dann doch zuviel. Ich entscheide lieber selbst, ob ich auf Facebook.com gehe, oder eben die nächste Stunde nicht, um in Ruhe meine Feeds und News zu lesen.

Einen echten Mehrwert gegenüber der Einzelnutzung von Facebook.com bzw. Twitter.com (oder Twitter über eigene Apps wie "Echofon" oder "Tweetie") sehe ich derzeit auch nicht. Ganz davon abgesehen frage ich mich, warum man dafür einen eigenen Browser stricken musste. Über Plugins für Firefox, Chrome oder Safari kann man eigentlich fast eine identische Funktionalität bekommen. Spontan würde ich RockMelt also also eine Abfuhr erteilen und bei Safari bleiben ( ), wenn nicht noch bahnbrechende Sachen hinzukommen.

Absolut sehenswerte Doku aus dem Jahre 1984 (Zufall?) zum Thema "Heimcomputer". Ich finde die Parallelen zur heutigen Zeit ziemlich amüsant. Und auch damals schon waren Kriegs- und Actionspiele der Renner - wer hätte das gedacht?

Einige Szenen erinnerten mich an meine eigene C64-Zeit, auch wenn ich erst deutlich später damit angefangen habe. Äußerst interessant sind auch die Einstellungen der männlichen Technikfans zum Thema Frauen und Computer ..

Die ganze Doku geht eine knappe Stunde. Viel Spaß dabei:





[ via | YouTube-Playlist ]

Nach dem Tipp eines Bekannten und der äußerst schicken Darstellung in diesem Blog beschloss ich, mein iPhone4 mit einer schicken Metall-Rückseite zu versehen. Die $16 dafür waren bei eBay auch eine durchaus überschaubare Investition. Hauptgrund war, neben der schicken Optik, die Tatsache, dass mein iPhone4 auf der Rückseite nach nur wenigen Monaten schon total zerkratzt ist. Verantwortlich dafür ist nicht etwa ein Sturz oder sowas, sondern schlicht die Tatsache, dass die Rückseite offenbar mega-empfindlich ist. Es reicht augenscheinlich zu, wenn sich beim rein- oder rausziehen ein kleiner Dreckkrümel zwischen meiner Suncase-Hülle und dem iPhone befindet. Betroffen ist nur die Rückseite, vorne sieht es noch aus wie neu. An der Apple-Care-Hotline konnte man mir nicht definitiv sagen, ob dies eine Rekla ist, daher ging ich das Risiko erstmal nicht ein, das in solchen Fällen versendete Vorab-Austauschgerät bezahlen zu müssen. Die China-Hülle schien also eine nette Alternative.

Nach einer recht langen Lieferzeit (die neue Rückseite kam tatsächlich aus Hong-Kong) machte ich mich direkt an den "Umbau". Dies ging wirklich sehr einfach, man muss mit einem Mini-Schraubendreher einfach nur die 2 Kreuzschlitz-Schrauben unten lösen und kann die Rückseite dann abschieben. Dabei fiel mir auf, wir dünn und eigentlich billig verarbeitet die originale Rückseite doch ist. Ob das wirklich Glas ist, vermag ich nicht zu sagen. Wie festes stabiles Glas fühlt es sich zumindest nicht an. Also fix die neue Rückseite drangesteckt - sieht absolut schick aus. Ein wenig wie das allererste iPhone von hinten und irgendwie ziemlich edel. Ich war durchaus begeistert und machte die Schrauben wieder fest. Vermutlich geht dadurch die Garantie verloren, allerdings ist es kaum nachweisbar. An den Schrauben sieht man keine Spuren und auch sonst wüsste ich nicht, warum dieser extrem simple Schritt die Garantie beeinträchtigen sollte.

Die erste Ernüchterung stellte sich bei dem Versuch ein, das iPhone nun in das Dock zu stecken. Mit ein wenig mehr Kraft als gewohnt funktioniert das zwar, das Telefon steht dann aber nahezu im 90°-Winkel zum Tisch und nicht mehr leicht schräg, so dass man den Screen nicht mehr wirklich sieht. Die Austausch-Rückseite scheint minimal dicker zu sein als das Original. Aber das konnte meine Begeisterung erstmal noch nicht schmälern. Das Feedback von Bekannten und Freunden war ebenfalls positiv, alle fanden die neue Rückseite schick. Mit dem Empfang hatte ich übrigens trotz anfänglicher Bedenken keine Probleme, da die Antennen ja an den Außenseiten liegen.

Vor wenigen Minuten habe ich allerdings wieder den Schraubendreher gezückt und das Ganze zurückgebaut. Mein iPhone ist nun wieder schwarz hinten und die neue, schicke Hülle liegt in der Schublade. Nur warum?

Seht her:



Wie man unschwer erkennen kann (zumindest in der großen Ansicht..), funktioniert die Kamera nicht mehr wie gewohnt. Nach mehrfachen Tests und Umbauten liegt es offenbar daran, dass das "Loch" in der China-Hülle nicht zu 100% an der korrekten Stelle sitzt und der Abstand zur Linse am iPhone zu groß ist. Somit sieht man diese unschönen Ränder die fast aussehen wie eine Vignettierung, egal wie man die Rückseite hin- und herschiebt. Außerdem scheint das durchsichtige Plastik minderwertig zu sein, so dass die Farben nicht immer korrekt eingefangen werden oder das Bild u.U. verwaschen aussieht.

Für mich als Fan der integrierten Kamera natürlich ein No-Go, schließlich mache ich öfter mal ein Video oder Foto mit meinem Telefon. Die Rückseite ist somit für mich unbrauchbar. Falls man jedoch keinen Wert auf die eingebaute Kamera legt, ist die Metall-Rückseite eine wirklich schicke Alternative. Eine Rekla via eBay nach China spare ich mir, vermutlich ist das ein prinzipieller Fehler in der Konstruktion.

Wie ich letztens ja schon erwähnt hatte, haben wir den Admin Blog seit geraumer Zeit leider etwas vernachlässigt. Das hatte ganz einfach den Grund, dass wir an einer neuen Idee programmiert und gefeilt haben, die wir euch heute vorstellen möchten - webPerf.

WebPerf ist, wie der Name schon sagt, ein Web Performance und Analyse Tool. Es wurde zur periodischen Auswertung von Webseiten, sowie der Messung von einzelnen Leistungsdaten, wie z.B. Anzahl der Dokumente, größe der Dokumente, Trankationen oder der JavaScript-Ausführungszeit, entwickelt. Und hier ist auch schon einer der großen Vorteile von webPerf. Alle Informationen die webPerf sammelt, werden periodisch von der jeweiligen Webseite abgefragt und dann gespeichert. Diese Informationen können dann zum Beispiel dafür genutzt werden, um eine längerfristigen Betrachtung der untersuchten Webseite darzustellen. Weitere Infos gibt es auf webPerf.de.

Für unsere treuen Leser gibt es hier auch noch 5 Invite-Codes, womit kostenlos und unverbindlich der "Basic 100" Tarif genutzt werden kann. Als Gegenleistung würden wir uns über Feedback zu webPerf sehr freuen.

Bitte einen der folgenden Links zur Anmeldung verwenden, um einen Invite zu nutzen (jeder Link ist nur für eine Anmeldung nutzbar):

https://www.webperf.de/users/add/vJrn1E
https://www.webperf.de/users/add/G3LPmc
https://www.webperf.de/users/add/s8Atac
https://www.webperf.de/users/add/q9z18W
https://www.webperf.de/users/add/A7gxKV

UPDATE, 28.10.2010

Der Basistarif ist nun dauerhaft für alle Nutzer gratis. Weitere Informationen im webPerf.de Blog.

FaceTime ist schon ganz nett, immerhin kann man vom iPhone4 aus zu anderen iPhone4 gratis aus dem WLAN samt Videochat reden. Gerade für Familien etc. eine wunderbare Sache. Bisher hielten sich allerdings die Endgeräte in Grenzen, denn natürlich haben nicht alle Leute aus dem Freundeskreis ein iPhone4. Meine Frau z.B. hat ein 3GS und kann ohne Jailbreak FaceTime nicht nutzen - mangels Frontkamera wäre das mit dem Video auf dem 3GS eh nicht so der Knaller, Sprache würde aber funktionieren. Das möchte aber wohl Apple (derzeit?) nicht.

Auf der letzten Keynote wurde nun aber die FaceTime-Betaversion für den Mac vorgestellt, die ich direkt installierte. Damit es nun also z.B. möglich, dass meine Frau mich von ihrem MacBook auf dem iPhone4 anruft, sofern ich unterwegs in einem WLAN bin - via UMTS wäre natürlich zukünftig noch wünschenswert. Die Anmeldung und Zuordnung der Kontakte für das Mac-FaceTime erfolgt via E-Mail-Adresse oder Telefonnummer, man "ruft" quasi einen Kontakt aus dem Adressbuch via E-Mail-Adresse an. Auf dem Mac bin ich nun also unter meiner E-Mail und auf dem iPhone4 via Handynummer in FaceTime erreichbar.

Zu meiner Verwunderung klinkt sich der FaceTime-Dienst doch recht tief ins System ein, so laufen permanent 2 Dienste, die es ermöglichen, jederzeit angerufen zu werden, selbst wenn man die Applikation augenscheinlich zu hat:

mbp:~ rob$ ps ax | grep -i facetime | grep -v 'grep'
170 ?? S 0:00.40 /Applications/FaceTime.app/Contents/PrivateFrameworks/IMCore.framework/imagent.app/Contents/MacOS/imagent
180 ?? S 0:00.11 /Applications/FaceTime.app/Contents/Frameworks/ApplePushService.framework/apsd-ft

Das ist in der Tat sehr nervig - bei Skype kann ich immerhin selbst entscheiden, ob ich online oder offline bin. Bei FaceTime kann man dann zwar Anrufe ablehnen, das Popup und den Ton wird man aber nicht los. Hier würde ich in der finalen Version gern die Möglichkeit haben, richtig offline zu gehen.

Erschwerend kommt hinzu, dass die Apple-Server somit jederzeit wissen, in welchem (W)LAN ich mich aufhalte bzw. welche externe sowie lokale IP ich habe. Mit Wireshark lässt sich das auch nachweisen, so kommuniziert der FaceTime-Client u.A. über das Jabber-Protokoll mit Apple. Das ist nicht nur unschön, sondern natürlich auch sicherheitstechnisch relevant. Wir erinnern uns: Es scheint - bis auf die Deinstallation der FaceTime-Beta - derzeit keine Möglichkeit zu geben, dieses Verhalten zu deaktivieren.

Mein Kollege hat aufgrund dieser Tatsache FaceTime für Mac spontan wieder deinstalliert, ich warte mal noch die nächste Version ab ..

UPDATE, 24.10.2010
Wenn man in den Einstellungen von FaceTime den Schalter "FaceTime" auf 0 stellt, ist man tatsächlich abgemeldet und der Anrufer bekommt die Meldung "Nutzer XYZ ist für FaceTime nicht verfügbar. Das hatte ich beim ersten Test gar nicht auf dem Schirm



Danke an Christian für den Hinweis in den Kommentaren!

Sorry, dass es schon so lange nicht's mehr von uns zu hören gab, aber zur Zeit haben wir echt viel beruflich zu tun und zu coden. Mehr davon demnächst von Rob.

Heute möchte ich mal wieder etwas Frust los werden. Neuerlich hatten wir uns nach einer Online-Storage-Lösung für Backups und "Immererreichbardaten" umgesehen. Abgesehen davon, dass es leider nur wenige Anbieter gibt, die verschlüsselte Online-Storages bieten (z.B. Cryptoheaven, Swissdisk) war bei diesen das Problem, dass es diesen Storage nur in kleinen Grössen gab. Da wir aber in etwa 500 GB aufwärts benötigen, kam für einen vernünftigen Preis eigentlich nur Strato in Frage. Diese bieten im Moment ein Angebot namens HiDrive Pro an, bei dem man 1TB Speicher für 19€/Monat bekommt. Ein auf den ersten Blick sehr angenehmes Angebot.

Also ruck-zuck dieses Angebot bestellt und ein paar Tage später hatte ich dann auch die erste Gelegenheit mir das Produkt genauer anzusehen. Hier muss ich zugeben, dass sich Strato echt Mühe gegeben hat. Das Webfrontend, was sehr im Web-2.0 Style daherkommt, hat viele Funktionen und lässt eine einfache Verwaltung des gebuchten Online-Speichers zu. Dabei gibt es verschiedene Möglichkeiten um von unterschiedlichen Betriebssystemen auf den Speicherplatz zu zugreifen. Unter anderen etwa SMB welches unter den gängigsten Betriebssystemen verfügbar ist. Auch an WebDAV, FTP in allen erdenklichen Varianten, sowie SSH wurde gedacht. Da einige Protokolle allerdings unverschlüsselt über die Leitungen gehen, besteht sogar für SMB die Möglichkeit, dieses über einen OpenVPN-Server anzusprechen. An sich also erstmal ein durchdachtes Konzept mit einer guten Benutzeroberfläche.

Nun zu den leider unerfreulichen Tatsachen des HiDrive Pro's - der Datendurchsatz und - wie leider schon fast üblich bei Strato - der Support!
Als erstes wollte ich natürlich die Bandbreite zu den Servern des HiDrive Pro's testen, denn schliesslich sollte ja täglich unser Backup und wichtige Daten dahin transferiert werden. Und schon gab es die erste Enttäuschung, denn keines der angebotenen Protokolle, schaffte es auf Anhieb mehr als 1,8 MB/s auf das HiDrive Pro zu schreiben. Als erstes dachte ich natürlich, dass das an unseren Servern/Mac's/Rechenzentrum lag, aber auch von externen Servern gab es keine höhere Bandbreite. Ich wollte ja nicht mit 50 MB/s auf das Laufwerk zugreifen, aber in Zeiten von 1Gbit Ethernets und multi redundanten ISP Anbindungen, hätte ich mir schon etwas mehr erhofft. Also war der nächste Weg den Strato-Support anzurufen, um zu Fragen ob dies den so gewollt ist. Der nette Techniker am anderen Ende der Leitung nahm ein Ticket auf, mit dem Versprechen sich in den nächsten 24h bei uns melden. Doch dabei blieb es dann leider auch.

Als ich mich dann nochmal's ein paar Tage später meldete, um nach meinen Ticket zu fragen, bestätigte mir der Techniker, dass nach der Ursache geforscht würde und wir informiert werden würden, wenn das Problem behoben ist. Prompt kam einige Stunden später die E-Mail mir dem Inhalt "[...]Das STRATO-Technik Team hat festgestellt, dass keine Einbußen in der Performance Ihres Hidrive Paketes festzustellen ist[..]". Ok, also doch noch einmal den Support anrufen und nachfragen wie die sich das gedacht haben. Ich erfragte wie ich zum Beispiel ein Volumen von 200GB innerhalb eines Tages auf das Drive spielen sollte, um dieses für unsere Zwecke nutzen zu können?! Der Techniker antwortete nur trocken: "Verteilen Sie es doch auf mehrere Tage". Ahh ja hab hier war dann bei mir Schluss. Ich fragte noch warum man denn überhaupt solch grosse Laufwerke anbietet und auch noch als professional kennzeichnet, wenn das gebuchte Volumen nicht täglich Nutzbar ist? Wieder eine trockene Antwort: "Dafür ist das eben nicht gedacht, Sie können das schon voll nutzen, eben über mehrere Tage.". Hier reichte es mir dann und ich brach das Telefonat ab. Die Kündigung des HiDrive Pro's folgte prompt.

Am Ende lief es dann doch wieder auf einen eigenen Server hinaus. Dort sind die Daten wenigstens in unseren Händen und auch die Bandbreite liegt weit über den 1,8MB/s. Wer nur ab und an Daten auf und vom HiDrive haben möchte ist mit dem Angebot sicher gut bedient, alle anderen die es professionell nutzen möchten sind mit einem eigenen Server sicherlich besser beraten.