Heute habe ich mich mal eingehend mit XCode beschäftigt und festgestellt, dass XCode sich auch über den AppStore installieren lässt (mittlerweile sogar in der Version 4.3.2). Um ein Software-Durcheinander zu vermeiden, habe ich die manuell installierte, alte Version zuerst deinstalliert. Das geht ganz leicht mit dem folgenden Kommando, das man am besten in einem Terminal ausführt:

sudo <Xcode-Dir>/Library/uninstall-devtools --mode=all

“<XCode-Dir>” muss natürlich durch das Verzeichnis ersetzt werden, in dem XCode installiert ist. Bei mir war das “/Developer“. Der vollständige Programm-Aufruf war hier also:

sudo /Developer/Library/uninstall-devtools --mode=all

Wer den XCode-Pfad nicht auf Anhieb findet, kann den Pfad zum uninstall-Programm mit diesem Befehl finden:

find / -type f -name “uninstall-devtools”

Nachdem das Kommando ausgeführt wurde, dauerte es eine ganze Weile, bis die Deinstallation durchgeführt war. Auch die CPU hatte einige Minuten ganz schön zu tun… dabei meldete sich sogar der Lüfter meines Air lautstark. Irgendwann hieß es dann

Finish time: Do 17 Mai 2012 17:39:29 CEST

und alles war gut. Zwischendurch gab’s ein paar Zeilen mit Warnungen, die waren bei mir jedoch zu vernachlässigen.

Bei knapp 30 Domains war die Umstellung problemlos möglich. Bei einer der Domains meldete mir der Robot jedoch “Required glue record is missing“, als ich versuchte, bei der Domain meinen DNS-Server als 1. Nameserver einzutragen.

Ursache war, dass die Domain, die ich bearbeiten wollte, gleichzeitig der Name des zuständigen DNS-Servers war, d.h. ich habe versucht, “ns1.meinedomain.de” als 1. Nameserver der Domain “meinedomain.de” einzutragen. Hier meldet der Robot also, dass ein sog. “Glue record” fehlt.

Die Lösung ist leicht: Im Domain-Feld “1. Nameserver” wird nicht “ns1.meinedomain.de” eingetragen, sondern “ns1.meinedomain.de 1.2.3.4“, also Name + Leerzeichen + IP-Adresse. Statt 1.2.3.4 wird hier natürlich die korrekte IP-Adresse des Nameservers angegeben.

Die detaillierte Beschreibung zum Glue Record gibt’s im Hetzner-Wiki.

Eigentlich ist das ja noch nicht so super spannend, und nur wer beim LPI den LPIC-Level 3 erreicht hat, darf überhaupt damit prahlen. Aber ich dachte mir grad so “was soll’s” und hab auch gerade etwas Zeit, bevor es gleich ab zu unserem Lieblings-IrishPub geht. Fritzpatrick’s in Essen-Rüttenscheid übrigens. :-)

Zurück zum Thema: Das nächste Ziel ist also der Level 3. Nur wenige schaffen es bis dahin und ich glaube, das könnte zum Teil daran liegen, dass diese Prüfung das äußerst langweilige OpenLDAP behandelt. Es gibt ein Vorbereitungsbuch dazu. Ehrlich! Nur LDAP! Das ist so sterbenslangweilig, dass es mich bereits Monate gekostet hat, es überhaupt komplett zu lesen. Ich habe in den letzten Jahren immer wieder mit OpenLDAP zu tun gehabt, hab’s rauf und runter konfiguriert und stundenlang Troubleshooting betrieben. Und trotzdem habe ich das Gefühl, dass ich noch nix darüber weiß, da ich eben nicht alle erdenklichen Szenarien erlebt und ausprobiert habe.

Ich werde wohl bei Gelegenheit mal eine LDAP-Spielwiese aufbauen und mich damit zusammen noch mal durch die einzelnen Kapitel quälen. Oder ich zahle das Geld für die Prüfungsgebühr einfach und mache mir erst mal ein Bild vom Schwierigkeitsgrad. :-) Hat jemand von Euch zufällig den 3er-Level und kann mir ein bisschen Mut machen? Wäre toll. :-)

UPDATE: Ich zeige 4 Varianten, mit denen man das System ohne Unterbrechungen sperren kann. Für die Varianten 2, 3 und 4 bedanke ich mich bei den freundlichen Tipp-Gebern. :-)

Variante 1: Schlüsselbundverwaltung

1. Starten der Schlüsselbundverwaltung. Das geschieht bequem direkt über die Spotlightsuche. Alternativ kann die App auch über das Launchpad im Ordner Dienstprogramme gefunden werden:
   
   
2. Dann wird in den Einstellungen die Option Schlüsselbundstatus in der Menüleiste anzeigen aktiviert:
   
   
3. Ab sofort kann man nun in der Menüleiste das Schloss-Symbol anklicken und dan den Eintrag Bildschirm schützen wählen:
   
   

Daraufhin wird der Bildschirm unter Verwendung des eventuell eingerichteten Bildschirmschoners gesperrt und lässt sich nur durch Kennwort-Eingabe wieder entsperren. Anwendungen und Hardware bleiben aktiv.

Variante 2: Aktive Ecken

Diese Variante ermöglicht es, die Bildschirm-Sperrung durch Innehalten mit dem Mauszeiger in einer gewählten Ecke auszulösen. Zunächst muss die Erforderlichkeit einer Kennworteingabe konfiguriert werden:

1. Man öffnet die Systemeinstellungen und öffnet im Menü Sicherheit den Reiter Allgemein.
2. Dort wählt man eine geeignete Zeitspanne aus, nach der ein Kennwort erforderlich ist, wenn Bildschirmschoner oder Ruhezustand aktiviert wurden. Ich komme mit 5 Sekunden gut zurecht. Manch einer erhöht hier vielleicht auf 1 Minute.
   
   

Dann erfolgt die eigentliche Konfiguration:

1. Man öffnet die Systemeinstellungen und wählt im Menü Schreibtisch & Drucker den Reiter Bildschirmschoner.
2. Hier befindet sich unten links die Schaltfläche Aktive Ecken… .
3. Im entsprechenden Menü wählt man eine der Ecken aus und entscheidet sich für die Option Bildschirmschoner ein oder Ruhezustand für Monitor aktivieren.
   
   

Beide Optionen sorgen für eine Aktivierung der Sperre nach der definierten Zeit.

Variante 3: Benutzerwechsel

Hier sorgt man für eine Sperrung der Sitzung, indem ein Benutzer-Wechsel gestartet wird (der nicht zwingend durchgeführt werden muss).

1. Man öffnet die Systemeinstellungen und wählt das Menü Benutzer & Gruppen.
2. Hier wählt man im Bereich Anmeldeoptionen die Checkbox Menü für schnellen Benutzerwechsel zeigen als und wählt eine Option aus, z.B. Symbol.
   
   
3. Daraufhin erscheint in der Menüleiste (je nach gewählter Option) ein neues Symbol, in dessen Menü man den Punkt Anmeldefenster wählen kann.
   
   

Diese Auswahl bewirkt eine Sperrung der Session und einen Wechsel zu einem Login-Menü, das gleichzeitig die Möglichkeit bietet, einen alternativen User zu wählen.

Variante 4: Tastenkombination

Die vierte Variante im Angebot ist eine Tastenkombination, die bei allen Geräten mit Auswurf-Taste funktioniert: Ctrl + Shift + Eject

Ich möchte heute das Werkzeug “ab” (ApacheBench) vorstellen. Immer wieder begegne ich Leuten, die zwar seit Ewigkeiten mit dem Apache-Webserver arbeiten, jedoch von ab noch nie etwas gehört haben.

So geht’s “ab”

ApacheBench liegt dem Apache-HTTP-Server-Paket bereits standardmäßig bei. In den aktuelleren Versionen heißt das Executable ab2 und liegt – am Beispiel von openSUSE 12.1 – im Ordner /usr/sbin. Im Wesentlichen wird das Programm mit einer zu testenden URL und der Anzahl von durchzuführenden Aufrufen gefüttert. Dabei kann außerdem angegeben werden, wie viele “concurrent”, also gleichzeitige Zugriffe, erfolgen sollen. Die Gesamtübersicht über alle Aufruf-Optionen erhält man wie gewohnt über “/usr/sbin/ab2 –help”. Ich nenne hier die für mich Wichtigsten:

-n {num}   (Anzahl der Anfragen an URL)
-c {num}   (gleichzeitige Anfragen)
-k         (HTTP KeepAlive verwenden)

Die ersten beiden Optionen sind selbsterklärend. “-k” bedeutet, dass multiple Aufrufe innerhalb der selben HTTP-Session ausgeführt werden. Standardmäßig wird diese Option nicht verwendet. Auch ich verzichte in den folgenden Beispielen darauf, um voneinander unabhängige Aufrufe simulieren zu können.

Ein Beispiel aus dem Leben

Am besten lassen sich die Funktionsweise und die Ausgabe von ab2 anhand eines praktischen Beispiels erklären: Ich entwickle und betreibe einen Dienst, der von beliebigen Websites “Vorschau-Fotos” (ThumbSniper) erstellt, die sich über HTTP abrufen lassen. Der Nutzer dieses Dienstes ruft eine bestimmte parametrisierte URL auf und erhält einen Redirect auf die URL zu einem JPG-Bild zurück. Das Backend ist ein Apache-Webserver, wo der dort abgelegte Code verschiedene Daten mit einer Datenbank austauscht und am Ende die entsprechende weiterführende URL zurückgibt. Die Nutzer dieses Dienstes erwarten eine schnellstmögliche Verarbeitung ihrer Anfragen und eine zügige Bereitstellung der angeforderten Bilder. Hier kommt es tatsächlich auf Millisekunden an. Da der Dienst international angeboten und genutzt wird, muss die hierfür verwendete Technik in der Lage sein, auch bei einer hohen Anzahl von Besuchern effektiv zu arbeiten.

Jede Millisekunde zählt

Hält mein Webserver einer hohen Anzahl Anfragen stand?
Wie schnell wird meine Datenbank unter Last unperformant?
Welche Auswirkung hat eine schnellere Festplatte auf die Verarbeitungsgeschwindigkeit?
Zu welchen Performance-Veränderungen wird ein bestimmtes SQL-Statement führen?
Kann mir ein Caching-Reverse-Proxy zu mehr Speed verhelfen?

Am Einfachsten lassen sich diese und ähnliche Fragen mit einem Vorher-/Nachher-Test beantworten. Und genau hier kommt ApacheBench ins Spiel. Ich werde zwei Tests durchführen: Ich setze insgesamt 1.000 Requests (jeweils 55 Gleichzeitige) zu oben beschriebenen Dienst ab, zunächst direkt an den Ziel-WebServer (Anfrage-URL kaschiert). Das Ergebnis ist Folgendes:

ab2 -n 1000 -c 55 "http://foobar.xyz/skript.php?key=wert" 
This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking foobar.xyz (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache
Server Hostname:        foobar.xyz
Server Port:            80

Document Path:          /skript.php?key=wert
Document Length:        0 bytes

Concurrency Level:      55
Time taken for tests: 22.344 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      290000 bytes
HTML transferred:       0 bytes
Requests per second: 44.76 [#/sec] (mean)
Time per request:       1228.894 [ms] (mean)
Time per request:       22.344 [ms] (mean, across all concurrent requests)
Transfer rate:          12.67 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.3      1       3
Processing:   151 1198 556.0   1091    4655
Waiting:      151 1196 555.9   1091    4655
Total:        152 1199 556.1   1092    4658

Percentage of the requests served within a certain time (ms)
  50%   1092
  66%   1124
  75%   1160
  80%   1194
  90%   1611
  95%   2501
  98%   3280
  99%   3503
 100%   4658 (longest request)

Der Request, den ich zum Testen des Dienstes verwende, bietet mir den Vorteil, dass lediglich ein HTTP-Status-Code zurückgegeben wird (Redirekt 301/307). Daher liegt in der Ausgabe der Wert “Document-Length” bei “0″ und ich erhalte Performance-Daten zur reinen PHP- und Datenbank-Verarbeitung zurück. 1000 identische Requests wurden in ca. 22 Sekunden abgearbeitet, wobei pro Sekunde ca. 44 Requests durchgeführt werden konnten. Interessant ist auch die Auflistung im unteren Teil. Hier lässt sich ablesen, wie lang die meisten Requests dauerten.

Normalnull (NN)

Diese Ausgabe lässt sich als Ist-Zustand verwenden. Führt man nun eine beliebige Änderung durch, kann man die Auswirkungen auf die Performance messen und vergleichen. Ich schalte für diesen zweiten Test einen Varnish-Cache (Reverse-Proxy) vor den Webserver. Dieser wird alle HTTP-Anfragen annehmen und bei Bedarf an den echten Webserver weiterleiten. Bei entsprechender Konfiguration wird Varnish jedoch auf seinen auf Geschwindigkeit optimierten Cache zurückgreifen und bereits bekannte Anfragen daraus beantworten, um den Webserver zu entlasten. Das erstaunliche Ergebnis:

ab2 -n 1000 -c 55 "http://foobar.xyz/skript.php?key=value"
This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking foobar.xyz (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache
Server Hostname:        foobar.xyz
Server Port:            80

Document Path:          /skript.php?key=wert
Document Length:        0 bytes

Concurrency Level:      55
Time taken for tests: 0.491 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1001
Total transferred:      383249 bytes
HTML transferred:       0 bytes
Requests per second: 2035.52 [#/sec] (mean)
Time per request:       27.020 [ms] (mean)
Time per request:       0.491 [ms] (mean, across all concurrent requests)
Transfer rate:          761.83 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.7      0       5
Processing:     1   25  42.7     14     252
Waiting:        1   23  42.4     11     232
Total:          1   26  43.1     14     256

Percentage of the requests served within a certain time (ms)
  50%     14
  66%     19
  75%     23
  80%     25
  90%     39
  95%    180
  98%    195
  99%    220
 100%    256 (longest request)

Das nenne ich mal einen Unterschied! Alle Anfragen wurden innerhalb einer halben Sekunde abgearbeitet. Natürlich wird dieser konkrete Testfall bei mir nur selten (wenn überhaupt) im richtigen Leben auftreten. Trotzdem ist es das perfekte Beispiel, um die Arbeit mit ApacheBench zu veranschaulichen.

Die oben gezeigten Werte sollten natürlich keinesfalls als Referenz für irgend welche Analysen heran gezogen werden. Der verwendete Code und die darin verarbeiteten Daten sind einmalig. Die Ergebnisse können daher nicht sinnvoll mit Euren Anfragen verglichen werden. ApacheBench sollte außerdem mit Bedacht und nur für Tests des eigenen Webservers eingesetzt werden, denn ehe man sich versieht, kann so ein Benchmark in eine Denial-of-Service-Attacke umschlagen.

Google Labs hat eine Website veröffentlicht, die helfen soll, die Maße einer Website besser darstellen und deuten zu können. Dazu gibt man zunächst die URL der zu testenden Site oben links in das Eingabefeld ein. Nachdem die Seite geladen wurde, wird sie zusammen mit einem Overlay, das unterschiedlich große Fenstermaße visualisiert, angezeigt. Genauer gesagt, geht es nicht um die Größe des Bildschirms oder des Browsers, sondern um die sog. “client size area”, also den Inhaltsbereich eines Browsers, ohne Adressleiste, Menü, Statusleiste etc. Die Deckkraft des Overlays kann in vier Stufen eingestellt werden.

Diese Seite wird am besten verwendet, indem man die zu untersuchende Webseite lädt und dann das Browserfenster manuell vergrößert oder verkleinert. Das MyNakedGirlfriend-Blog wird zentriert dargestellt und besitzt – je nach verwendeter Browser-Größe – unterschiedlich breite Ränder auf der linken und rechten Seite. Ich verkleinere beim Testen daher meinen Browser so weit, dass die seitlichen Ränder verschwunden sind und jede weitere Verkleinerung ein Verdecken von Inhalt zur Folge hätte. Dann kann ich am Overlay ablesen, in welchem Breitenbereich ich mich befinde und kann anhand der Prozentzahl erahnen, wie viele Benutzer mit dieser Browser-Größe tatsächlich arbeiten.

Dieses Blog nutzt weitestgehend ein gekauftes Theme mit recht komplexen Strukturen, daher werde ich tunlichst die Finger von den globalen Größen-Einstellungen lassen. Aufgrund dieser Entscheidung habe ich mich aber indirekt gleichzeitig dazu entschieden, meine Website für “nur” 90% der Websurfer zu optimieren. Die anderen 10% nutzen Browser mit geringerer Auflösung und können nicht alles reibungslos darstellen. Ich betrachte 90% als einen fairen Wert, der für einen Großteil der User funktioniert. Ehrlich gesagt habe ich auch kein Interesse daran, jede erdenkliche (geringere) Auflösung bedienen zu können. Eine zeitgemäße IT-Ausstattung sollte schon bei einer möglichen Auflösung von mindesten 1024 Pixeln Breite liegen (Smartphones ausgenommen – das ist ein anderes Thema).

Quelle: http://browsersize.googlelabs.com/

Zunächst mal ist die genutzte Session “belegt”, d.h. bis zum Ende der Befehlsausführung kann kein anderes Kommando ausgeführt werden. Einige Jobs laufen möglicherweise über Stunden (oder sogar Tage!) und man möchte oder kann die Session nicht so lange geöffnet lassen. Selbst wenn man die Session aufrecht erhalten möchte, kommt es immer wieder vor, dass eine Netz- oder Stromunterbrechung zum Beenden der Sitzung führt. Damit ist dann auch die Befehlsausführung beendet und das Spiel beginnt von vorn… wenn dann nicht schon alles im Eimer ist, weil der Job unbedingt hätte durchlaufen müssen.

Natürlich weiß man als Linux-Admin, dass Befehle schon auf einfache Weise in den Hintergrund geschickt werden können: “nohup ./foobar &” erfüllt oft bereits seinen Zweck. Die Ausgabe des Prozesses landet dann automatisch in einer Datei namens “nohup.out“. Leider ist “nohup” nicht in allen Situationen die beste Idee. Vielleicht möchte man zwischendurch in die Befehlsausführung eingreifen. Möglicherweise ist nach einiger Zeit eine Entscheidung oder ein einfacher Tastendruck notwendig. Auch die Ausgabe eines Prozesses kann von Interesse sein, wird aber sinnlos, wenn sie in eine Datei umgeleitet wird.

Praktisch wäre es daher, wenn man eine Konsole benutzen könnte, von der man sich trennen und bei Bedarf wieder verbinden könnte. Eine Session, die nach der Trennung so weiter läuft, als wäre sie noch aktiv…

…darf ich vorstellen – “screen”:

“screen” ist ein Multiplexer, mit dem es möglich ist, mehrere “virtuelle” Sitzungen in einer “echten” Terminal-Sitzung zu benutzen. Dabei verhält sich jede dieser Sitzungen wie eine ganz normale Session. Die Besonderheit ist hier, dass man zwischen den einzelnen Sitzungen hin und her springen kann. Besser noch: Man kann Sitzungen “detachen”, also trennen und in den Hintergrund schicken. Später kann die Sitzung dann “re-attached” und wie gewohnt weiter verwendet werden.

Die aktuelle Manpage zu “screen” ist ca. 2500 Zeilen lang, daher beschränke ich mich hier auf die wichtigsten Kommandos. Den Rest kann jeder selbst über “man screen” nachlesen.

• screen
  Über diesen Befehl wird eine neue screen-Session gestartet. Es erscheint zunächst ein Willkommens-Bildschirm und danach erhält man wieder eine normale Konsole, der man erst mal nicht ansieht, dass es sich um eine screen-Sitzung handelt. Wird in dieser Sitzung “exit” eingegeben, terminiert die Session.
• Steuerung-a c
  Wird in einer aktiven screen-Sitzung die Tastenkombination “Steuerung-a” und dann “c” gedrückt, erscheint der Hinweis “[detached]” und man befindet sich wieder in der Sitzung, in der zuvor “screen” gestartet wurde. “screen” läuft im Hintergrund weiter.
• screen -ls
  Dieser Befehl listet alle aktiven screen-Sessions und ihren attached/deattached-Status auf.
• screen -r
  Über dieses Kommando kann man sich zu einer detached-screen-Session verbinden lassen. Funktioniert nur, wenn genau eine screen-Session existiert.
• screen -r {name}
  {session} bezeichnet hier den Session-Namen, der von “screen -ls” ausgegeben wurde. Standardmäßig wird der Name im Format pid.tty.host generiert.
• screen -S {name}
  Über dieses Kommando kann man einen eigenen Sitzungsnamen vergeben. Erleichtert “screen -r {name}”.
• screen -x {name}
  Mit diesem coolen Kommando kann man sich mit einer Sitzung verbinden, zu der bereits an anderes Terminal verbunden ist. Quasi ein “Mirror-Modus” zur Spiegelung. Man kann dann z.B. gemeinsam mit jemand anderem in der Sitzung arbeiten. Beide sehen das Gleiche und können gleichberechtigt in der Session arbeiten.

Wie gesagt, die Manpage ist lang und das Programm ist vielfältig einsetzbar. Weitere Features sind das Toggeln, also das Hin- und Herschalten zwischen Sessions, Passwort-Absicherung gegen unbefugten screen-Zugriff, ACLs für unterschiedliche User/Gruppen und zahlreiche Optionen für die Verwendung unter X11. Dazu kommen noch Features, mit denen ich mich bisher noch gar nicht beschäftigt habe.

“screen” liegt so ziemlich allen gängigen Distributionen bei und ist oft bereits vorinstalliert. Es ist für mich vollkommen ausreichend, um “unterbrechungsfrei” remote arbeiten zu können. Ein Beispiel: Es ist mir endlich möglich, über SSH mit “vi” eine Datei geöffnet zu halten und meinen Laptop kurzerhand ausschalten zu können, ohne mich danach mit dem Locking von vi auseinandersetzen zu müssen, weil die Datei nicht ordnungsgemäß geschlossen wurde. Dank “screen” ist die Datei nämlich immer noch geöffnet und vi immer noch aktiv. Ein “re-attach” genügt.

• Fatal error: Class ‘Piwik_Config_Ini’ not found in [...]/core/Config.php on line 102
• Fatal error: Class ‘Piwik_MultiSites_API’ not found in [...]/plugins/MultiSites/Controller.php on line 58
• Class Piwik_DataTable_Filter_Piwik_MultiSites_CalculateEvolutionFilter does not exist
• Fatal error: Interface ‘Piwik_View_Interface’ not found in [...]/core/View.php on line 27

Am Ende habe ich dann doch ein Backup meiner Daten angelegt, Piwik neu auf dem Webserver entpackt und dann aus dem Backup heraus die Datei “config/config.ini.php” in den neuen Ordner “config” kopiert.

Diese Aktion hat nur unnötig Zeit verschwendet. In Zukunft werde ich also Updates direkt manuell durchführen. Da weiß ich, was ich hab.

Nun ist es endlich soweit – die nächste Stufe wurde erreicht:

Bereits am Montagabend (23.01.12) wurde auf vielfachen Wunsch eine erweiterte Version des 200-Puls-Soundboards veröffentlicht. Die neuen Sounds und das angepasste Design wurden von der Community sehr positiv aufgenommen. Außerdem wurde der Ruf nach einer App für Smartphones lauter. Aufgrund der rasanten Entwicklung durch “S.APP”  ist heute bereits die dergeht.de-Android-App im Android Market aufgetaucht.  Hinter dem Publisher-Pseudonym “S.APP” verbirgt sich  meiner Meinung nach eines der vielversprechendsten Nachwuchstalente für Android-App-Entwicklung aus NRW.

Ich freue mich sehr über die erfolgreiche Zusammenarbeit und hoffe, dass Website und App weiterhin eine Menge Besucher und positiven Zuspruch finden.

Ich nutze die FRITZ!Box 6360 von Unitymedia. Die Firmware-Version ist 85.05.09 und wurde erst am 12.01.2012 automatisch aktualisiert. Mehrmalige Reboots halfen bisher nicht, das Problem zu lösen. Auf der Übersichtsseite ist die “Status-Lampe” grau dargestellt. Der Beschreibungstext lautet: “3 Rufnummern aktiv, davon keine registriert“. Auf der Telefonie-Ereignis-Seite finden sich zahlreiche Meldungen mit dem Inhalt “Anmeldung der Internetrufnummer [...] war nicht erfolgreich. Gegenstelle meldet Ursache 301“.

Die Internetverbindung ist von dem Problem offenbar nicht betroffen und funktioniert tadellos. Bei der Internet-Suche nach der Fehlermeldung habe ich bisher nur einen Foren-Beitrag mit heutigem Datum gefunden, der das gleiche Problem beschreibt.

Ich habe die Störung über das entsprechende Unitymedia-Kontaktformular gemeldet und warte nun auf eine Reaktion. Hier der Vollständigkeit halber mein gesendeter Text:

Hallo Unitymedia,

seit einigen Stunden funktionieren keine Telefonverbindungen mehr in meinem Haushalt.

Die Fritzbox zeigt (auch nach Reboot) an: “3 Rufnummern aktiv, davon keine registriert”. Die weiterführende Meldung lautet: “Anmeldung der Internetrufnummer [...] war nicht erfolgreich. Gegenstelle meldet Ursache 301″. Die Fritzbox hat die Firmware “85.05.09″.

Bitte prüfen. Danke.

Falls noch jemand dieses Problem hat: bitte Artikel kommentieren. Danke.

[UPDATE]

Ich konnte soeben die Telefonie erfolgreich wieder reparieren. Schuld waren offenbar die Anbieter-Einstellungen der in der FRITZ!Box hinterlegten Internetrufnummern.

Um die Konfiguration zu reparieren, begibt man sich zunächst in das Menü Telefonie -> Telefoniegeräte.

Dort wählt man recht das Bearbeiten-Symbol neben der jeweiligen Internetrufnummer.

Als Internettelefonie-Anbieter war bei mir Anderer Anbieter eingetragen. Ich musste hier lediglich den Wert Unitymedia einstellen. Es verschwinden daraufhin einige Optionen weiter unten im Menü. Das schadete bei mir jedoch nicht. Im Gegenteil, denn nach Bestätigen der Schaltfläche OK funktionierte das jeweilige Telefon mit der registrierten Nummer bereits wieder (siehe auch “Update 16.02.2012″!)

Hier die vorher/nachher-Bilder:

Auf diese Weise konnte ich mir ein Zurücksetzen auf Werkseinstellungen ersparen. Hoffe, dass das beschriebene Verfahren auch bei anderen Teilnehmern funktioniert.

[UPDATE 2]

Ich habe gerade bei Unitymedia angerufen, meine Störungsmeldung storniert und die o.g. Lösung beschrieben. Als Dankeschön erhielt ich eine 10 EUR Gutschrift. Danke, Unitymedia! :-)

[UPDATE 16.02.2012]

Offenbar bereitet die von mir beschriebene Lösung ein paar Leuten Probleme, daher möchte ich hier ausdrücklich darauf hinweisen, dass ich jegliche Verantwortung für die Umsetzung des o.g. Tipps ablehne. Wenn Ihr die Konfiguration auf eigene Faust durchführen wollt: viel Glück! Ansonsten wendet Euch an Euren Provider.

Wie im rechten Screenshot zu sehen, ist als Registrar “telefon.unitymedia.de” eingetragen. Scheinbar ist diese Einstellung nicht für alle Unitymedia-Teilnehmer korrekt. Wer also nach Anpassung der Konfiguration noch immer Probleme hat, kann versuchen, in das Feld Registrar den Wert “sslxx.telefon.unitymedia.de” einzutragen (Danke an Martin für den Tipp!).

Ich habe mich daraufhin auf die Suche im Internet begeben. Offenbar bin ich mit dem Problem nicht allein. Die Apple-Foren füllen sich mit ähnlichen Meldungen aus aller Welt. Gestern, am 17.01.12 startete iTunes Match in 19 weiteren Ländern. Hierdurch kann es laut Apple Feedback zu Performance-Problemen kommen, die wohl erst in den nächsten Tagen nachlassen werden.

Eine sehr schwache Leistung von Apple, wie ich finde. Wer im großen Stil Cloud-Dienste international anbietet, sollte über genügend Rechenleistung verfügen, um seine Kunden bedienen zu können. Hoffen wir mal, dass es schnell wieder besser wird.

Mit der neuen Version 16 des Webbrowsers Google Chrome ist es möglich, mehrere User-Profile einzurichten und leicht ohne Neustart zwischen ihnen zu wechseln. “Profil” hört sich zunächst vielleicht etwas verwirrend an, denn schnell denkt man an das User-Profil auf einem Computer, das man verwendet, wenn man sich mit seinem Benutzernamen an Windows, KDE, Mac OS X etc. einloggt.

Warum dann noch seinen Browser mit mehreren Benutzern teilen?

Das Verständnis wird leichter, wenn man statt von Profilen einfach von Identitäten spricht. An eine Identität sind in Chrome sehr viele Informationen geknüpft. Dazu gehören Website-Cookies, Browser-Verlauf, gespeicherte Passwörter, Apps und zahlreiche andere Dinge. Für den Otto-Normal-Nutzer reicht vermutlich sein Standardprofil. Aber es gibt Szenarien, in denen es von Vorteil sein kann, blitzschnell zwischen verschiedenen Identitäten wechseln zu können.

LEBEN IN ZWEI WELTEN

Ein Beispiel: Ein Anwender nutzt zuhause einen Computer, um seinen privaten Interessen nachzugehen. Ein Heim-Computer eben. Er besucht Webseiten, nutzt Webmail, guckt YouTube-Videos und kauft online ein. Um möglichst leicht auch auf seinem Zweitgerät, z.B. seinem Laptop, auf seine Browser-Daten zugreifen zu können, hat er sein Profil mit Google verbunden und synchronisiert so ziemlich alles, was es zu synchronisieren gibt.

Im Büro nutzt er ebenfalls Google Chrome. Da es ihm laut Betriebsvereinbarung erlaubt ist, den Firmen-Internetanschluss auch für private Zwecke zu nutzen, hat er die Google-Synchronisation auch hier aktiviert. Auf diese Weise hat er auch im Büro Zugriff auf seine zuhause angelegten Lesezeichen, Website-Passwörter usw.

Doch genau hier beginnen nun Komplikationen: In der Firma wird eine Webanwendung verwendet, um – sagen wir mal – kritische Daten zu verarbeiten. Diese Anwendung wird häufig benötigt, der Login-Name ist lang und das Passwort ist kompliziert. Da gerät man leicht in Versuchung, auch hier den “Passwort für diese Website speichern”-Button zu drücken. Doch nun vermischen sich private und geschäftliche Daten! Durch die Google-Synchronisation sind die Zugangsdaten nun auch zuhause am Privat-PC nutzbar. Wie steht es dort um die Sicherheit? Virenscanner installiert und aktuell? Ist das Netzwerk ausreichend geschützt? Erlaubt der Arbeitgeber überhaupt, sensible Geschäftsdaten “mit nach Hause” zu nehmen? Schnell begibt man sich hier in Gefahr, Daten unbefugt weiter zu geben. Durch die Synchronisation sogar ins Ausland! Das eigene Profil wird verwässert.

DIE LÖSUNG: CHROME’s USER-PROFILE

Gehen wir vom Firmen-PC aus: Mit dem neuen Chrome nutzt man zunächst wie bisher ein Standardprofil. Über den Schraubenschlüssel-Button oben rechts und der Auswahl den Menüpunktes “Einstellungen” gelangt man in die Chrome-Verwaltungsmenüs. Hier findet man unter “Privates” den Bereich “Nutzer”.

Klickt man nun auf die Schaltfläche “Neuen Nutzer hinzufügen”, springt sofort ein neues Chrome-Fenster auf. Damit ist das neue Profil bereits angelegt. Das Fenster kann zunächst jedoch erst mal wieder geschlossen werden. Der Name eines neuen Profils richtet sich nach dem zufällig gewählten Profil-Symbol.

Durch Doppelklick auf eines der Profile können Name und Logo angepasst werden.

Sobald mehr als ein Profil existiert, zeigt der Chrome-Browser in der Menüleite den Menüpunkt “Nutzer”.

Hier kann schnell zwischen den vorhandenen Identitäten gewechselt werden. Zur besseren Orientierung wird das aktuelle Profil-Logo rechts oben im Fenster angezeigt.

CHOOSE BEFORE USE

Mit zwei Profilen (“Privat” und “Büro”) ausgestattet, fällt es nun leichter, Dienst und Schnaps voneinander zu trennen. Für gewöhnlich arbeitet man im Büro dann unter dem “Büro”-Profil. Man verzichtet auf die Google-Synchronisation und kann trotzdem seine Passwörter lokal speichern. Die Lesezeichen-Leiste enthält die für den geschäftlichen Alltag wichtigen Einträge.

Möchte man sich mal eine Pause gönnen und den Browser für private Zwecke nutzen, schaltet man über das Menü “Nutzer” auf das “Privat”-Profil um. Hier darf Google-Sync aktiviert werden. Daraufhin erscheinen u.a. die privaten Lesezeichen und auch die Passwörter für WebMail & Co. sind wie zuhause nutzbar. Ist die Pause beendet, schaltet man wieder in den Büro-Modus um.

FAZIT

Den Security-Administrator dürfte dieses Feature sehr freuen. Am Schwierigsten wird es jedoch werden, den User an diese Vorgehensweise zu gewöhnen und ihn dazu zu bringen, die goldene Regel des “Choose-before-Use” einzuhalten, um nicht inkonsequent zu handeln.

Mit dem neuen Profil-Manager erhält man schlussendlich ein tolles Werkzeug von Google, um sich selbst ein bisschen besser organisieren zu können. Leben muss man es dann allerdings selbst.

Zunächst benötigt man das Redirection-Plugin. Nach der Installation und der Aktivierung kann das Konfigurationsmenü im WordPress-Adminbereich unter “Werkzeuge -> Umleitungen” aufgerufen werden. Dann trägt man in das Feld “URL-Quelle” den Text “/+” ein und gibt als “Ziel-URL” die Adresse zum Google-Plus-Profil an.

Fertig. Danach kann man die eingerichtete Adresse testen und beliebig weiter verwenden.

UPDATE: Dummerweise scheint irgend ein WordPress-Plugin diese Umleitung bei mir neuerdings zu stören, daher habe ich die Umleitung bei mir bis auf Weiteres wieder abgeschaltet. :-(

UPDATE 2: Offenbar hat ein Plugin-Update zu einer Korrektur der Umleitung geführt. Ab sofort klappt die “/+”-Umleitung bei mir wieder.

Ich nutzte die Gunst der Stunde un bloggte einen Artikel mit dem Titel “DJ Tomekk fliegt aus Camp – die Gründe…”. Viel zu sagen hatte ich allerdings nicht, da ich natürlich keine Insider-Infos besaß. Ich beschrieb das Ganze einfach als Server-Benchmark, machte noch einen kleinen Scherz und wartete ab. Es dauerte nicht lange und die Besucher kamen in rauen Mengen. Sie riefen den Artikel auf, Einige posteten Kommentare. Innerhalb von ca. 20 Minuten stand der Server so dermaßen unter Last, dass selbst der Zugriff via SSH Ewigkeiten benötigte. Mit letzter Kraft konnte ich den Webserver abschalten, um zumindest die anderen Services wieder nutzen zu können. Am nächsten Morgen war der Spuk dann vorbei.

Grund für den Besucher-Ansturm war oben genannter QDF-Algorithmus: Ähnliche Suchabfragen von vielen Benutzern in kurzer Zeit signalisierten der Google-Suche, dass hier gerade offenbar irgendwas Neues passiert sein muss und lieferte daher möglichst aktuelle Artikel in den SERPs vor allen anderen aus. Einer der aktuellsten Beiträge war tatsächlich von mir – Jackpot!

Am 3. November 2011 hat Google im offiziellen Blog verkündet, durch ein kürzlich erfolgtes Update nun noch frischere Ergebnisse liefern zu können. Dies soll ca. 35% aller gestellten Suchanfragen beeinflussen. In Zukunft kann die Suche also noch effizienter mit aktuellen Ereignissen umgehen: Eine Suche nach aktuellen Themen, z.B. [Olympiade] bringt nun eher Webseiten zur bevorstehenden Olympiade statt der Olympiade von 1900. Wiederkehrende Themen, wie z.B. [Fußballergebnisse] werden genauso optimiert wie auch gelegentliche Updates, wie [subaru impreza reviews].

Wichtig bei diesen Suchanfragen ist natürlich auch, dass jede Anfrage unterschiedliche Anforderungen an die Gewichtung der Aktualität hat. Die Suche nach einem [Rezept für Tomatensuppe] muss nicht das neueste, sondern das “beste” Rezept liefern. Die bessere Unterscheidung dieser Gewichtung ist ebenfalls Teil des Updates.

Ich glaube, zu den Basics (Maße, Preise etc.) brauche ich hier wohl kaum noch etwas zu sagen. Das haben andere bereits zur Genüge erledigt. Mein Hauptaugenmerk beim AppleTV liegt auf dem Zusammenspiel mit meinem FileServer. Zwar kann das Gerät ganz toll Leihfilme von Apple oder aus iTunes streamen. Ich hatte jedoch vor, meinen Home-Theatre-PC abzulösen. Dazu gehört nun mal auch das Abspielen von diversen Audio- und Videoformaten, die sich im Netzwerk befinden. Ohne DVD-/BluRay-Laufwerk bleibt einem beim ATV auch keine andere Wahl. Ich betreibe das Gerät mit HDMI-Kabel an einem Samsung-TV und mit optischem Audio-Out (Ziel ist hier ein Yamaha-AV-Receiver).

Ich war seit jeher ein großer Fan des XBox-Media-Centers (XBMC). Damals war es noch die originale XBox, die mittels Modding-Chip zur Multimedia-Zentrale wurde. Dann kam der HTPC und nun sollte es also auch auf dem ATV seinen Platz finden. Der Jailbreak war mit SeasonPass (unter Mac OS X Lion) ein Kinderspiel – die wohl größte Hürde war das fehlende Mikro-USB-Kabel, da es im Standard-Lieferumfang nicht enthalten ist. Nach einem kurzen Ausflug zum Elektrofachhandel mit unverschämten Preisen lief XBMC dann auf Anhieb. Vorher habe ich noch fix mit TinyUmbrella den SHSH-Blob gesichert. Seitdem ich vor einiger Zeit massive Probleme beim Downgrade meines iPhones hatte, habe ich mir angewöhnt, die Blobs meiner Geräte gelegentlich zu sichern.

Alles in Allem bin ich schon ziemlich zufrieden damit. Die Navigation zwischen den Menü-Elementen und das Scrollen in Listen sind nicht so smooth wie im nativen ATV-Menü. Das Abspielen von Musik und Filmen war bisher jedoch sehr zufriedenstellend. Mittlerweile habe ich die Datenbank für Audio und Video auf einen externen MySQL-Server umgestellt. Das hat den Vorteil, dass mehrere XBMC-Instanzen im Haushalt auf den selben Datenbestand zugreifen können und so die Inventarisierung zentralisiert werden kann. Auf diese Weise kann man z.B. einen Film im Wohnzimmer beginnen, unterbrechen und im Schlafzimmer fortsetzen – die Abspiel-Informationen liegen ebenfalls in der DB. Außerdem ist die Performance beim Laden von Listen subjektiv schneller.

Einigen Ärger hatte ich zunächst, da Apple immer wieder zur Software-Aktualisierung aufforderte. Zum Einen stürzt bei der Überprüfung das XBMC gern ab, zum Anderen passierte es mir (nach der PERFEKTEN Einrichtung von XBMC), dass ich leichtsinnigerweise mit ausgeschaltetem Fernseher ein Firmware-Update des ATV auslöste, da ich dem Update unbewusst durch Tastendruck zustimmte. Also alles von vorn. :-( Ich habe nun noch die Software NitoTV installiert und hierüber das Paket UpdateNoMore nachgezogen. Nun gibt’s keine nervenden Hinweise mehr und auch das Risiko, alle Einstellungen zu verlieren, ist deutlich geringer geworden.

Fazit bisher: Das AppleTV ist ein toller, lautloser und Feature-reicher Ersatz für meinen HTPC. Ein Wermutstropfen ist allerdings das fehlende DVD-/BluRay-Laufwerk. So müssen Disks, die ich mir anschauen möchte, zunächst auf dem FileServer abgelegt oder über einen PC mit iTunes gestreamt werden. Ich arrangiere mich mit dieser Einschränkung jedoch gern, da die positiven Eigenschaften deutlich überwiegen.

Piwik nutzt ein Plugin namens “RankChecker”. Der dazugehörige Link zur Author-Seite führt leider zu einem 404-Fehler, eine neuere Version war  nicht zu finden. Ich habe daher die Korrektur selbst erledigt. Die Änderung ist minimal, so dass sie von jedem selbst vorgenommen werden kann. Die Anpassung der URL ist übrigens auch für zahlreiche andere Checker relevant und sollte dort quasi genau so funktionieren:

1. Die Datei “plugins/SEO/RankChecker.php” mit einem Editor öffnen.
2. Zeile 45 anpassen:
   
   $url="http://toolbarqueries.google.com/search?client=navclient-auto&ch=".$chwrite."&features=Rank&q=info:".$this->url."&num=100&filter=0";

   wird zu:

   $url="http://toolbarqueries.google.com/tbr?client=navclient-auto&ch=".$chwrite."&features=Rank&q=info:".$this->url."&num=100&filter=0";

3. Speichern.

Danach sollte die PageRank-Anzeige wieder wie gewohnt funktionieren. Ich hoffe, dass die Änderung auch in der nächsten Piwik-Version enthalten sein wird.
 

Bei der Einrichtung meiner E-Mail-Konten in der Mail-Anwendung von Mac OS X Lion habe ich einen Menüpunkt zur Konfiguration meiner Mail-Aliase leider vergeblich gesucht. Ich war bereits auf der Suche nach alternativen Mail-Clients, als ich auf einen Support-Artikel bei Apple gestoßen bin, der das Problem löst:

Bei der Account-Konfguration kann man im Feld “E-Mail-Adresse” beliebig viele Adressen durch Kommata getrennt hintereinander schreiben, wie im Screenshot zu sehen:

Schreibt man nun eine neue Mail, antwortet oder leitet eine Mail weiter, kann man den Absender-Alias in einem Drop-Down-Menü auswählen:

Noch besser wäre es, wenn man pro Adresse nun außerdem noch unterschiedliche Absender-Namen angeben könnte. Aber hierzu habe ich leider noch keine Infos gefunden. Vielleicht ja in der nächsten Version.

• das Betriebssystem aktuell ist,
• die Firewall dicht ist,
• alle Passwörter sicher sind,
• WordPress aktuell ist,
• die verwendeten WP-Plugins aktuell sind

Hier  die wichtigsten Features des Kennenlern-Pakets (kann sich jederzeit ändern – keine Haftung für die Richtigkeit):

• Amazon EC2 Linux Micro Instance”: 750 Stunden (613 MB RAM und 32-Bit- und 64-Bit-Plattform-Unterstützung), ausreichend für den Dauerbetrieb
• Elastic Load Balancer: 750 Stunden plus 15 GB Datenverarbeitung / 10 GB Amazon Elastic Block Storage, plus 1 Mio. I/Os, 1 GB Snapshot-Speicher, 10.000 Lese- und 1.000 Snapshot-Schreibanfragen
• Amazon S3-Speicher: 5 GB, 20.000 Lese- und 2.000 Schreibanfragen
• Datentransfer: 30 GB (jeweils 15 GB ein- und ausgehend für alle Dienste außer Amazon CloudFront)
• Amazon SimpleDB: 25 Maschinenstunden und 1 GB Speicher
• Amazon Simple Queue Service: 100.000 Anfragen
• Amazon Simple Notification Service: 100.000 Anfragen, 100.000 HTTP- und 1000 E-Mail-Benachrichtigungen

Zusätzlich zu diesen Diensten steht auch die AWS Management Console kostenlos zur Verfügung, in der eigene Anwendungen in AWS erstellt und verwaltet werden können.

Ich hatte bisher noch nicht viel Zeit, mich mit den AWS zu beschäftigen. Ich habe bereits eine selbst erstellte openSUSE-Appliance über das SuSE-Studio in die EC2-Umgebung gebracht, für alles Weitere nehme ich mir demnächst etwas mehr Zeit. Dafür stehen mir ja nun 12 Monate zur Verfügung. Ich freue mich aber schon jetzt sehr darüber, dass Amazon auch Privatanwendern die einfache Möglichkeit bietet, sich kostenfrei mit der Cloud-Thematik beschäftigen zu können.

Das “REST API Module” ist im Standard-Umfang der Gallery enthalten und bietet eine komfortable Möglichkeit, von außen mit der Gallery zu kommunizieren. Funktionen für das “Entgegennehmen” von hochgeladenen Dateien existieren bereits, so dass meine Aufgabe nun darin bestand, einen für mich nutzbaren Client zu schreiben, der die von mir benötigte Funktion des galleryadd-Skripts ablösen sollte.

Also schrieb ich in PHP ein Upload-Skript: gallery3-upload-1.00.txt (muss in .php umbenannt werden)

Es besteht aus zwei Funktionen, die zusammen arbeiten. Darunter befinden sich die Site-spezifische Konfiguration und der eigentliche Aufruf.

$galleryHost = "gallery.site";            // Gallery-URL
$galleryPort = 80;                        // HTTP-Port
$apiKey      = "xxx";                     // API-Key eines Gallery-Users
$itemID      = 1;                         // Album-ItemID

$importDir   = "/data/upload";    // Quell-Verzeichnis
$archiveDir  = "/data/archive";   // Archiv-Verzeichnis (optional)

processFiles($galleryHost, $galleryPort, $itemID,
        $apiKey, $importDir, $archiveDir);

Das Skript setzt voraus, dass die Gallery sich im Stammverzeichnis des Servers befindet und nicht als Unterordner (z.B. “/gallery/”). Falls jemand diese Erweiterung benötigt, möge er/sie sich bitte melden.

Die Album-ItemID habe ich kurzerhand direkt in der MySQL-Datenbank in der Tabelle “items” nachgesehen (Filter auf Datensätze mit “type” = “album”). Den API-Key kann man in der Administrationsoberfläche den User-Details entnehmen. Wichtig ist, dass der User des verwendeten API-Keys auch entsprechende Schreibrechte auf das Album besitzt.

Das Skript überträgt alle Dateien aus dem Ordner $importDir, es findet keine Filterung auf Dateitypen statt. Die Angabe von $archiveDir ist optional. Statt die hochgeladenen Bilder aus dem Ordner zu löschen, lege ich sie lieber in einem separaten Archiv ab. Ist diese Form des Backups nicht gewünscht, kann man $archiveDir auf NULL setzen. ACHTUNG: In diesem Fall muss man sich selbst darum kümmern, die abgearbeiteten Dateien aus dem $importDir zu entfernen!

Man kann diese PHP-Datei durch require/include zwar innerhalb einer anderen PHP-Anwendung verwenden, ich rufe sie stattdessen jedoch direkt über die Kommandozeile oder über einen Cronjob auf.

Kommandozeile:

/usr/bin/php /pfad/zum/skript/gallery3-upload.php

Cronjob (alle 10 Minuten):

*/10 * * * *    /usr/bin/php /skriptpfad/gallery3-upload.php > /dev/null 2>&1

Feedback ist herzlich willkommen.