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.

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! :-)

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

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.

Eines Abends musste ich feststellen, dass bei der Besucheranzahl-Statistik plötzlich ein Tag einer bestimmten Website auf “0″ gesunken war. Ich wusste aber, dass die Anzahl bei einer Kontrolle ein paar Stunden zuvor bereits deutlich > 0 gewesen war. Die Nachfrage im Piwik-Forum bestätigte mir, dass ich mit dem Problem nicht allein war. Auch andere User hatten so etwas beobachtet.

Die Ursache für die Falsch-Anzeige hat offenbar mit der Archivierung der Statistik-Daten zu tun. Den genauen Grund kenne ich zwar noch nicht, dafür aber die Lösung, um die Zahl wieder zu korrigieren:

Nehmen wir an, die Website mit der Piwik-Site-ID “3″ weist Statistik-Probleme am “24.06.2011″ auf. Um die Archivierung rückgängig zu machen und so die Berechnung erneut durchführen zu lassen, muss händisch in die Piwik-Datenbank eingegriffen werden. Dies kann bequem mit phpMyAdmin oder einem anderen MySQL-Client erledigt werden. Piwik erstellt pro Monat eine Tabelle mit dem Namen “piwik_archive_numeric_” + “Jahr_Monat”. Wir benötigen für unser Bespiel also die Tabelle “piwik_archive_numeric_2011_06″. Innerhalb der darin enthaltenen Datensätze existieren auch Einträge, die als Checkpoints dienen. Diese haben den Namen “done” und geben an, dass bestimmte Auswertungen für einen Tag erfolgreich abgeschlossen wurden.

Diese “done”-Datensätze müssen für die entsprechende Website-ID am betroffenen Tag entfernt werden. In diesem Beispiel lautet das SQL-Kommando daher:

DELETE FROM `piwik_archive_numeric_2011_06`
    WHERE idsite = '3'
    AND date1 = '2011-06-24'
    AND name = 'done'

Beim nächsten Piwik-Aufruf werden die Daten dann neu berechnet und das Ergebnis ist wieder korrekt. Danke an das Piwik-Forum für die Unterstützung.

Allgemeine Infos zu IPv6, die grundsätzliche Konfiguration unter Linux und die Einrichtung eines SixXS-Tunnels werden bereits ausgezeichnet im IPv6-Wiki von Ralf Krüdewagen beschrieben, daher werde ich hier nicht nochmals darauf eingehen.

Stattdessen erzähle ich über ein paar Dinge zu DHCP und DNS, die mir erst heute klar geworden sind und zeige, wie die technische Umsetzung funktioniert. Mag sein, dass ich mich hier und da nicht ganz korrekt ausdrücke… Feedback ist willkommen. :-)

Zusammengefasst sind Stand heute folgende Funktionen möglich:

• IPv6-Tunnelnutzung mit SixXS
• Router Advertisement mit radvd
• DHCP-Server für IPv4 / IPv6
• DNS-Server für IPv4 / IPv6
• dynamische DNS-Updates (DDNS) für IPv4 / IPv6

Im Doppelpack

Ich bin bisher davon ausgegangen, dass man entweder “radvd” oder einen IPv6-fähigen DHCP-Server für die dynamische Zuweisung von IP’s verwendet. Richtig ist aber, dass beide Dienste als Team arbeiten. radvd verkündet im Netz lediglich das IPv6-Prefix, also das zu verwendende Subnetz und Angaben zum Router. Clients weisen sich anhand dieser Informationen selbst eine IP-Adresse zu. Wird nur radvd eingesetzt, spricht man von Stateless Address Autoconfiguration. In diesem Szenario können sich Clients bereits im Netz bewegen und mit anderen IP-Adressen/Hosts kommunizieren.

In einem typischen (Heim-)Netzwerk reicht das jedoch nur sehr selten. Das wohl wichtigste Feature ist das Zuweisen eines DNS-Servers. Hinzu kommen Optionen wie z.B. Domain-Name, Such-Suffixe, PXE oder WPAD-Angaben. Genau hier setzt der DHCP-Server auf, der den radvd sinnvoll ergänzt.

Kurz: IP-Adressen kommen vom radvd, Zusatz-Optionen vom DHCP-Server. Man spricht hier von “Stateful Address Configuration”. (siehe auch IPv6-Autokonfiguration bei Wikipedia).

Die technische Umsetzung:

Die radvd-Konfiguration wird auf ein Minimum reduziert. Wichtig ist die Option “AdvManagedFlag on”. Die Angabe eines prefix-Bereichs entfällt.

“/etc/radvd.conf”:

interface eth0
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 10;
}

Ich nutze unter openSUSE 11.4 den ISC DHCP Server (RPM-Paket “dhcp-server”), derzeit in der Version 4.2.1. Dieser Dienst besteht aus zwei Komponenten, “dhcpd” für IPv4 und “dhcpd6″ für IPv6. Ich beschäftige mich in diesem Artikel ausschließlich mit Letzterem. Die DHCP-Konfiguration wird in zwei Dateien vorgenommen:

“/etc/sysconfig/dhcpd” (Auszug):

DHCPD6_INTERFACE="eth0"

“/etc/dhcpd6.conf” (<- auf die “6″ achten!):

authoritative;
ddns-update-style interim;
ddns-updates off;

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.info-refresh-time 21600;

allow leasequery;

log-facility local7;

subnet6 2001:xxxx:yyyy::/64 {

        range6 2001:xxxx:yyyy:: /64;

        option dhcp6.name-servers 2001:xxxx:yyyy::1;
        option dhcp6.domain-search "ipv6.site site";
}

(IP-Adressen wurden anonymisiert)

Wenn nun beide Dienste gestartet wurden und keine Firewall im Weg ist, sollten Clients bereits in der Lage sein, eine IPv6-Adresse inkl. Router- und DNS-Server-Adresse zu beziehen. In Kürze werde ich außerdem beschreiben, wie dynamische DNS-Updates mit IPv6 funktionieren.

Ich bemerkte eher zufällig, dass das Aufrufen beliebiger Artikel und Kategorien-Seiten bloß noch in 404-Fehlern endete…

Kurz und knapp: Der Grund hierfür waren die Permalinks. Unter “Einstellungen -> Permalinks -> Allgemeine Optionen” verwende ich die Option “Benutzerdefinierte Struktur” mit dem Wert “/%postname%/”. Lösen konnte das Problem dann tatsächlich dadurch, dass ich die Permalink-Struktur pro Blog (!) zunächst auf “Standard” umstellte, die Einstellung speicherte und dann wieder die ursprüngliche Einstellung aktivierte.

Möchte gern mal einen WordPress-MultiSite-Betreiber in einer wirklich großen Umgebung sehen. Da gibt’s dann wohl Einiges zu tun.

Offensichtlich kann man als User seine kompletten Account-Daten paketieren lassen, um sie danach herunter zu laden. Dies bringt mehrere Vorteile mit sich. Zum Einen erhält man ganz bequem einen Überblick darüber, welche Informationen man eigentlich überhaupt mit anderen Usern teilt. Zum Anderen ist es ein bequemer Weg, einen Export aus Facebook durchzuführen, um die Daten anderweitig zu verwenden.

Zu den herunterladbaren Daten gehören u.a. Profilinformationen, Pinnwandeinträge, hochgeladene Fotos und Videos, Notizen, Freundeslisten, Nachrichten zu- und abgesagte Veranstaltungen und auch hinterlassene Kommentare.

Die Funktion zum Download findet man innerhalb der “Kontoeinstellungen“. Beim Punkt “Lade deine Informationen herunter” muss rechts daneben “mehr dazu” angewählt werden.

Der Bildschirminhalt wechselt dann und bietet dann die Schaltfläche “Herunterladen”. Es wird noch ein kurzer Hinweis gezeigt und nach einer weiteren Bestätigung beginnt im Hintergrund auf den Facebook-Servern das Einsammeln und Packen aller Account-Daten. Dies kann einige Zeit dauern (bei mir ca. 2,5 Stunden), daher sendet Facebook bei Fertigstellung eine E-Mail an den Account-Inhaber. Darin befindet sich ein Link, der endlich zur Download-Seite auf facebook.com führt. Nach Eingabe des eigenen Passworts wird die Schaltfläche “Jetzt herunterladen” sichtbar und der Download kann beginnen.

Das Ergebnis ist eine ZIP-Datei, die quasi eine vollständige Mini-Homepage beinhaltet. Hat man sie lokal ausgepackt, kann man die Datei “index.html” mit einem Webbrowser öffnen und bekommt dann alle Profil-Infos in verschiedene Sektionen unterteilt zu sehen. Ganz schick gemacht, wie ich finde.

Es ist derzeit bei Facebook nur möglich, alle Informationen als Ganzes herunter zu laden. Wer nur gelegentlich ein Backup seiner hochgeladenen Facebook-Bilder anfertigen möchte, kann alternativ auch http://facebook-backup.de/ verwenden. Das geht wesentlich schneller und ignoriert alle anderen zur Verfügung stehenden Daten.

Anwenden kann man diese Konfiguration z.B. bei Shared-Webhosting, wo unabhängige User ihren eigenen Webspace verwalten. Anstelle des unsicheren FTP kann hier dann eine sichere SFTP-Kommunikation stattfinden. Auch CVS-Repositories können auf diese Weise abgesichert werden.

Ich gebe in diesem Artikel nachfolgend eine Kurzanleitung, die die grundsätzliche chroot-Konfiguration beschreibt. Ich verwende derzeit openSUSE 11.3, grundsätzlich ist die Distribution aber natürlich nicht entscheidend.

Als Beispiel-Basisordner für die chroot-Umgebung verwenden wir “/srv/sftp“. Jeder User soll darin seinen eigenen Unterordner erhalten.

1. Erstellen einer neuen Benutzergruppe “sftponly”:

   groupadd sftponly

    

2. Erstellen zweier Benutzerkonten “user1″ und “user2″:

   useradd -s /bin/false user1
   useradd -s /bin/false user2

    

3. Setzen der Passwörter für die neuen User:

   passwd user1
   passwd user2

    

4. Hinzufügen der User zur neuen Gruppe:

   usermod user1 -A sftponly
   usermod user2 -A sftponly

    

5. Erstellen des Ordners “/srv/sftp” und der exemplarischen Unterordner “/srv/sftp/user1″ und “/srv/sftp/user2″:

   mkdir /srv/sftp
   chown root:sftponly/srv/sftp
   chmod 750 /srv/sftp
   
   mkdir /srv/sftp/user1
   chown user1: /srv/sftp/user1
   chmod 700 /srv/sftp/user1
   
   mkdir /srv/sftp/user2
   chown user2: /srv/sftp/user2
   chmod 700 /srv/sftp/user2

    

6. Anpassen der Datei “/etc/ssh/sshd_config”:

   #Subsystem      sftp    /usr/lib64/ssh/sftp-server
   Subsystem       sftp    internal-sftp
   
   Match Group sftponly
       ForceCommand internal-sftp
       ChrootDirectory /srv/sftp
       X11Forwarding no
       AllowTcpForwarding no

    

7. Neustart des SSH-Servers:

   /etc/init.d/ssh restart

    

Verbinden sich die eingerichteten User nun via SFTP (z.B. “sftp”-Kommando bei Linux oder WinSCP bei Windows) mit dem Server, sollten sie automatisch im Ordner “/srv/sftp” landen. Im eigenen Unterordner des User ist dann die Schreibberechtigung für abzulegende Inhalte vorhanden.

Wichtig ist bei dieser Einrichtung vor allem die korrekte Vergabe der Verzeichnis-Berechtigungen:

• Der Eigentümer des chroot-Ordners MUSS “root” (UID 0) sein.
• Die Gruppe des chroot-Ordners MUSS die in der “sshd_config” angegebene Gruppe (hier “sftponly”) sein.
• Die Berechtigung des chroot-Ordners MUSS 750 (User: Vollzugriff, Gruppe, lesen+ausführen, Andere: kein Zugriff) sein.

Wird eine dieser Bedingungen nicht erfüllt, verweigert der SSH-Server den Zugriff mit einer entsprechenden Fehlermeldung im Syslog:

Feb 11 11:33:02 server sshd[10053]: fatal: bad ownership or
modes for chroot directory "/srv/sftp"

Requested file to big, increase BLKSIZE

Grundsätzlich ist es so, dass das TFTP-Protokoll bei einer Standardgröße von 512 Byts pro Datenpaket nur Dateien mit einer Maximalgröße von 32 Megabytes übertragen kann. Dies liegt am 16-Bit Paketzähler (512 * 65536).

Will man nun größere Dateien übertragen, muss man die Anzahl der Bytes pro Datenpaket erhöhen. Gemeint ist hiermit der “blocksize”-Wert.

BlockSize = „zu übertragende Image-Größe in Bytes“ / 65536

Am Einfachsten ist es, das Ergebnis etwas nach oben aufzurunden. Die maximal verwendbare BlockSize ist “65504″:

65504 = 65536 - IP-Header(20) - UDP-Header(8) - TFTP-Header(4)

Die Blockgröße muss vom Client aus angegeben werden, d.h. der Client muss sie anfordern können. Gängige TFTP-Client, wie “atftp”, kennen diese Option. Die LAN-Boot-Funktion im BIOS der meisten Motherboards bietet diese Möglichkeit leider nicht.

Beispiel:

• Physical Volumes: /dev/sda6, /dev/sdb6
• Volume Group: volg1
• Logical Volume: /dev/volg1/logvol1
  (“lvcreate” wurde mit “-i 2″ ausgeführt)

Möchte man beispielsweise die Platte “/dev/sdb” austauschen, würde man zunächst die darauf liegenden Daten verschieben, um sie beim Ausbau nicht zu verlieren:

pvmove /dev/sdb6

Danach entfernt man das PV aus der VG und tauscht die Platte aus. Wie so etwas funktioniert, wird bestens im LVM-HowTo beschrieben. Wir gehen hier von dem Ergebnis aus, dass am Ende wieder mind. zwei PV’s in der VG vorhanden sind, die nun wieder Speicherplatz bieten.

Nun folgt der interessante Teil: Unser LV, das aus zwei Teilen bzw. Stripes besteht, befindet sich durch das ausgeführte “pvmove” nicht mehr gleichmäßig auf zwei, sondern nur noch auf einem PV (“/dev/sda6″). Das beweist auch die folgende Ausgabe:

lvdisplay -m /dev/volg1/logvol1

--- Logical volume ---
LV Name /dev/volg1/logvol1
VG Name volg1
LV UUID                a0zoBZ-xFQU-SlJj-kVzv-nnJr-Wpjh-SIuOP1
LV Write Access        read/write
LV Status              available
# open                 2
LV Size                20.00 GB
Current LE             5120
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     1024
Block device           253:11

--- Segments ---
Logical extent 0 to 5119:
Type                striped
Stripes 2
Stripe size         64 KB
Stripe 0:
Physical volume /dev/sda6 Physical extents 38400 to 40959
Stripe 1:
Physical volume /dev/sda6 Physical extents 40960 to 43519

Hier kann man sehen, dass das LV aus 2 Stripes besteht, die derzeit nur auf “/dev/sda6″ liegen. Glücklicherweise können wir nun anhand der jeweils angegebenen Physical Extents eine Verschiebung vornehmen:

pvmove /dev/sda6:38400-40959

Dieses Kommando hat zur Folge, das die angegebenen Physical Extents von “/dev/sda6″ verschoben werden. Sie landen in unserem Beispiel somit automatisch auf “/dev/sdb6″, wie die Überprüfung am Ende der Verschiebe-Aktion zeigt:

--- Logical volume ---
LV Name /dev/volg1/logvol1
VG Name volg1
LV UUID                a0zoBZ-xFQU-SlJj-kVzv-nnJr-Wpjh-SIuOP1
LV Write Access        read/write
LV Status              available
# open                 2
LV Size                20.00 GB
Current LE             5120
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     1024
Block device           253:11

--- Segments ---
Logical extent 0 to 5119:
Type                striped
Stripes 2
Stripe size         64 KB
Stripe 0:
Physical volume /dev/sdb6 Physical extents 2560 to 5119
Stripe 1:
Physical volume /dev/sda6 Physical extents 40960 to 43519

Damit ist die Verteilung abgeschlossen und man profitiert wieder von der höheren Performance durch die gleichmäßige Verteilung auf zwei physikalische Festplatten.

In einem meiner Systeme stecken 2 SATA2-Festplatten mit je 750 GB Speicherplatz. Das Betriebssystem ist SLES11 und hauptsächlich befinden sich dort Xen4-DomU’s. Die Gäste stellen Webserver, Mailserver und andere Systemdienste bereit. Bisher war es so, dass ich einen Teil der ersten Platte mit LVM genutzt habe. Die zweite Platte war für Backups und andere Dinge in Verwendung. Die Performance war in Ordnung, aber auch nicht überragend.

Um diese Situation zu verbessern, hab ich mich im Internet auf die Suche gemacht. Es galt, ohne neue Hardware auszukommen (bei Mietservern unverschämt teuer) und ohne den Server komplett umzukrempeln, wie es z.B. bei einem neu konfigurierten Software-RAID der Fall wäre. Ich bin fündig geworden! Die Lösung funktioniert in meiner Umgebung wunderbar, ist aber grundsätzlich auch problemlos woanders verwendbar:

Das Geheimnis liegt im LVM verborgen. Statt weiterhin nur ein einziges Physical Volume (PV) zu verwenden, in dem die Volume Group (VG) und ihre Logical Volumes (LV) liegen, habe ich einen Teil der zweiten Festplatte zur bereits bestehenden VG hinzugefügt. Das ist erst mal nichts Neues, sondern bei LVM üblich.

Neu für mich war allerdings beim Kommando “lvcreate“, das zum Anlegen neuer Logical Volumes verwendet wird, der Parameter “-i 2“. Dieser Parameter gibt an, auf wie viele Physical Volumes das zu erzeugende Logical Volume aufgeteilt werden soll. In diesem Fall auf 2 PV’s. Auf ganz bequeme Art schaffen wir somit ein Software-RAID-0 für dieses LV. Wichtig ist aber, dass alle PV’s einer VG unbedingt auf separaten Platten liegen müssen, da es sonst zu Performance-Einbußen kommt.

Die Festplatten-Geschwindigkeit meines Xen-Gastes, den ich zum Testen verwendet habe, ist massiv gestiegen.

Hier die Ausgaben von hdparm zu den Lesegeschwindigkeiten:

(“/dev/xvdb” liegt auf einem einzigen PV, “/dev/xvdc” liegt auf 2 PV’s)

3x hintereinander “hdparm -Tt /dev/xvdb” (ALT)

/dev/xvdb:
Timing cached reads:   18416 MB in  1.99 seconds = 9251.71 MB/sec
Timing buffered disk reads:  280 MB in  3.00 seconds =  93.29 MB/sec

/dev/xvdb:
Timing cached reads:   18144 MB in  1.99 seconds = 9114.75 MB/sec
Timing buffered disk reads:  274 MB in  3.00 seconds =  91.24 MB/sec

/dev/xvdb:
Timing cached reads:   17474 MB in  1.99 seconds = 8778.24 MB/sec
Timing buffered disk reads:  276 MB in  3.02 seconds =  91.45 MB/sec

3x hintereinander “hdparm -Tt /dev/xvdc” (NEU)

/dev/xvdc:
Timing cached reads:   17672 MB in  1.98 seconds = 8909.50 MB/sec
Timing buffered disk reads:  552 MB in  3.01 seconds = 183.52 MB/sec

/dev/xvdc:
Timing cached reads:   17226 MB in  1.99 seconds = 8651.80 MB/sec
Timing buffered disk reads:  560 MB in  3.01 seconds = 186.18 MB/sec

/dev/xvdc:
Timing cached reads:   18446 MB in  1.99 seconds = 9267.25 MB/sec
Timing buffered disk reads:  550 MB in  3.02 seconds = 182.30 MB/sec

Und hier noch das “dd”-Kommando bei der Erzeugung von ca. 4 GB großen Dateien:

ALT:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 51.6753 s, 79.3 MB/s

real    0m51.682s
user    0m0.556s
sys     0m10.405s

NEU:

time dd if=/dev/zero of=test1.bin bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 26.8236 s, 153 MB/s

real    0m26.813s
user    0m0.512s
sys     0m8.845s

Na, wenn das nichts ist… ich find’s großartig! :-)