Skip to content

Serendipity 2.0-beta3

Rund drei Monate nach dem Release der Beta-Version von Serendipity 2.0 haben sich etliche kleinere und größere Verbesserungen und Fehlerbehebungen angesammelt, so dass die Zeit reif war für eine dritte Beta-Version, die ich mittlerweile - nach einem Probelauf im Testblog und der obligatorischen Sicherheitskopie - auch hier auf Netz - Rettung - Recht einsetze.

Ich bin sehr zufrieden: alles ist noch runder, funktionaler, praktischer geworden, und die in meinem letzten Beitrag aufgezählten kleineren Haken und Ösen sind wohl auch allesamt verschwunden.

Leider war ich in den letzten zwei Monaten nicht mehr in der Lage, täglich die Diskussionen im Forum und den Issue Tracker weiterzuverfolgen oder mich gar selbst einzubringen - man hat es wohl auch an der erneuten relativen Stille hier im Blog bemerkt -, aber ich habe den Eindruck, dass Serendipity 2.0 auf einem sehr guten Weg ist.

Late adopter - bleich wie Papier

Offenkundig gehöre ich nicht (mehr?) zu den Menschen, die allzeit das neueste technische Gadget als allererster haben müssen - im Gegenteil.

Dauerte es schon bei dem Thema Smartphone ungewöhnlich lange, nämlich bis ins Frühjahr 2010, bis ich mich für ein solches erwärmen könnte (obwohl ich schon anderthalb Jahre vorher neidisch beobachtete, wie praktisch so eine Bedienoberfläche mit Touchscreen ist, während ich neben einem Skelett im Wald hockte … - aber das ist eine andere Geschichte), ist der Funke auch bei dem Thema “E-Book-Reader” bisher nicht so recht übergesprungen. Meine Frau nennt schon lange einen Kindle ihr eigen, von Kollegen habe ich mir bereits vor zwei Jahren die Vor- und Nachteile der verschiedenen Modelle erläutern lassen - dennoch konnte ich mich bislang nicht dafür erwärmen, ein gedrucktes Buch gegen ein elektronisches Gerät einzutauschen, obwohl ich schon mehrfach darüber nachgedacht hatte.

Den Anlass zum erneuten Überdenken bot jetzt die Tatsache, dass die beiden letzten Bücher von Karen Rose, die ich noch nicht gelesen hatte, nur als E-Books erschienen sind. Kurzentschlossen habe ich daher Mitte Juli einen Kindle Paperwhite geordert … und bin, mal wieder, durchaus zufrieden. Gerade die Art Bücher, die ich nach dem Lesen ohnehin wieder über BookMooch oder ähnliche Dienste vertauschen würde, kann ich sehr gut auch nur in elektronischer Form lesen. Außerdem hat so ein Gerät echte Vorteile, wenn man im ÖPNV unterwegs ist oder Pausen von 15-45 Minuten außerhalb des Büros zu füllen hat, so dass die Rückfahrt nicht lohnt.

Offenbar macht das Gerät auch durchaus süchtig, oder es geht einfach nur so schnell, “mal eben” in ein Buch hineinzuschauen; jedenfalls habe ich in dem knappen Monat seither immerhin 19 (gut, zumeist kürzere) Bücher rein elektronisch gelesen. Bemerkenswert.

Mobiles Internet - reloaded

Schon vor gut fünf Jahren hatte ich über meine guten Erfahrungen mit einer UMTS-Mobilfunkkarte von Novatel für meinen Laptop berichtet; und diese Karte tut auch noch in meinem aktuellen Laptop unter Windows 7 gute Dienste, denn dessen eingebautes UTMS-Modul hat mich sehr enttäuscht und ist für mich nicht brauchbar.

Inzwischen hat sich die Welt aber natürlich fortentwickelt; und wiederum wurde ich durch Berichte in Blogs auf UMTS-WLAN-Router (wie ich sie bezeichnen möchte - Geräte, die einerseits als WLAN-Accesspoint arbeiten und sich andererseits über eine UMTS-SIM-Karte mit dem Mobilfunknetz verbinden und so für alle Geräte im WLAN eine Internetverbindung bereitstellen) neugierig. Das ist natürlich noch besser, als nur den Laptop selbst online zu bringen, zumal, wenn die UMTS-Abdeckung am Standort des Laptops schlechter ist als anderswo in der (Ferien-)Wohnung.

Also habe ich mir im Juli vergangenen Jahres vor dem Urlaub einen Huawei E5331 zugelegt, der sich bewährt hat und mit dem ich seitdem sehr zufrieden bin.

Mobilfunk-Datentarife

Ein Mobiltelefon nutze ich - für Telefonie und SMS - seit gut 20 Jahren. Seitdem hat sich vieles geändert, nicht zuletzt an den Tarifen. Lange Zeit war ich Vertragskunde - seit 2000 bei Vodafone - und hatte mir irgendwelche Pakete aufschwatzen lassen, für die ich dann im Monat bis zu 30,- € bezahlt habe (ohne Datenoption, wohlgemerkt!), obwohl ich Wenigtelefonierer bin und das Mobiltelefon v.a. benötige, wenn (und weil) ich erreichbar sein muss und - wenn wirklich nötig - kurze (!) Telefonate zu führen. Vor rund 7 Jahren wurde mir das alles zuviel, und ich bin in einen Prepadi-Tarif gewechselt. Seitdem lade ich im Monat - für Telefonie und SMS - in der Regel weniger als 15,- € auf, und ich vermute, dass der Löwenanteil dieser Kosten auf dienstliche Gespräche entfällt (die ich meinem Arbeitgeber bislang großzügigerweise schenke).

Vor gut 10 Jahren war ich einmal einige Jahre täglicher Fernpendler und habe zudem erstmals einen Laptop genutzt; klar, dass ich irgendwann einmal mein Telefon damit via Kabel oder Bluetooth gekoppelt und dann (per GPRS) Mail und News von unterwegs gecheckt (und teilweise auch gechattet) habe. Auch klar, dass ich - bei zeit- oder volumenbezogener Abrechnung! - einige Zeit lang meine monatlichen Rechnungen dank Kostenexplosion quasi mit einem roten Schleifchen zugeschickt bekam; es fehlte eigentlich nur noch ein Dankesbrief des Vorstands für die Sanierung des Unternehmens. Später bin ich dann sinnvollerweise auf eine entsprechende Karte umgestiegen und habe vor allem einen günstig(er)en Anbieter genutzt. Insbesondere als ich dann vor vier Jahren als “late adopter” mein erstes Smartphone mein Eigen nennen durfte, stellte sich die aber auch die Frage nach einem brauchbaren “Flatrate”-Angebot (bzw. einem Volumentarif mit Freivolumen und nachfolgender Drosselung bei Überschreitung).

"Mobilfunk-Datentarife" vollständig lesen

Kommentare des Blogautors hervorheben

In anderen Blogs fand ich es immer ganz schön, wenn Kommentare des ursprünglichen Autors - des Blogeintrags - optisch hervorgehoben werden. Wer das gleichfalls schick findet, kann das auch mit Serendipity umsetzen.

Voraussetzung ist, dass im verwendeten Theme (oder Template) zum einen entsprechender Smarty-Code vorhanden ist, der auf die Übereinstimmung von “Kommentarautor” und “Blogautor” prüft, und es zum anderen dort entsprechende CSS-Definitionen gibt, die dann zu einer Hervorhebung führen. Ersteres ist im neuen Standardtheme “2k11” der Fall, letzteres nicht.

Wenn die Überprüfung ergibt, dass der Kommentar vom Autor des Beitrags selbst stammt, bekommt der entsprechende <article>-Abschnitt die Klasse serendipity_comment_author_self zugewiesen. Für diese Klasse sind also entsprechende Definitionen vorzunehmen, die dann zu einer optischen Hervorhebung führen. Dazu erstellt - oder ergänzt - man eine entsprechende Datei namens user.css im Verzeichnis des Themes (templates/2k11) entsprechend (deren Nutzung freilich in der Konfiguration des Themes aktiviert sein muss), bspw. so wie hier in diesem Blog:

  1. .serendipity_comment_author_self {
  2.         background: #ff9;
  3.         padding: 0.5em;
  4.         border-radius: 0.75em;
  5. }

Die Überprüfung erfolgt standardmäßig auf Identität der jeweils angegebenen Namen von Kommentar- und Eintragsautor, nicht über die Identität der E-Mail-Adresse. Das lässt sich natürlich ändern, bspw. in der Datei comments_by_author.tpl im Theme-Verzeichnis (templates/2k11). Bei einer Überprüfung auf Identität der E-Mail-Adresse wäre aber zu prüfen, ob nicht etwa ein Spamschutz-Plugin die Ausgabe der E-Mail-Adressen unterdrückt; falls doch, stehen die entsprechenden Daten für Smarty nicht zur Verfügung. Nachdem zumindest in 2k11 ohnehin über das Template selbst die Ausgabe der Mailadressen unterbunden wird, kann man die entsprechende Spamschutz-Konfiguration aber auch getrost deaktivieren.

Im Serendipity-Forum finden sich zu den näheren Einzelheiten u.a. folgende Threads:

Beachten sollte man im übrigen, dass natürlich letztlich jedermann Namen und E-Mail-Adresse des Blogautors für Kommentare verwenden kann …

Dokuwiki als "Multisite"-Installation

DokuWiki ist für mich derzeit und schon länger die generische Antwort auf die Frage nach einem Wiki, nicht nur für Dokumentationszwecke, und auch für die Frage nach einem (simplen) CMS.

Ich installiere DokuWiki dabei (wie die meisten Webapplikationen) nicht als Debian-Paket, sondern direkt vom Erzeuger; zum einen, weil ich gerne eine aktuelle Version habe, zum anderen, weil ich dann (wie bei anderen Webseiten) frei entscheiden kann, wo die Dateien liegen sollen - und das ist in der Regel nicht dort, wo Debian sie ablegen würde, insbesondere, wenn es mehr als einen Nutzer mit Webseiten geben soll - und nicht zuletzt, weil das trivial funktioniert. Das führt dazu, dass ich Updates von Hand durchführen muss, und das kann dann schon etwas nervig werden, wenn es mehrere Hosts und mehrere Wikis betrifft.

Daher überlege ich schon länger, wie ich - zumindest bei Installationen auf demselben Host - den Aufwand (und, natürlich, auch den Platzverbrauch) minimieren kann. Die offenkundige Lösung ist eine “Farm”- oder “Multisite”-Installation, bei der der Code nur einmal vorhanden ist, aber jedes Wiki seine eigenen Konfiguration und natürlich seinen eigenen Speicherplatz für Inhalte hat. DokuWiki unterstützt das prinzipiell, aber die nächste Frage ist ja immer, wie gut das auch tatsächlich funktioniert: stabil, flexibel und vor allem ohne krude Hacks.

Nachdem ich mich diese Woche damit beschäftigt habe, kann ich sagen: es funktioniert gut. Die Flexibilität bleibt erhalten, Hacks braucht man nicht, weil die aktuellen DokuWiki-Versionen eine “Multisite”-Installation unterstützen, und stabil wirkt es bisher auch.

Der offensichtliche Vorteil liegt darin, dass man für beliebig viele Wikis nur einmal den Code für das Wiki selbst - und den für Plugins und Templates - installieren, updaten und pflegen muss. Der offensichtliche Nachteil liegt darin, dass alle Plugins und Templates im “Master”-Wiki installiert werden müssen und in den einzelnen Wikis nicht nachinstalliert werden können, und dass sich alle Wikis in Unterverzeichnissen unter einem “Stammverzeichnis” befinden müssen, deren Namen identisch mit der URL des Wikis sind.

"Dokuwiki als "Multisite"-Installation" vollständig lesen

Blogs und Editoren

Wer ein Blog betreibt, kennt vermutlich die Frage danach, welcher Editor für die Einträge am sinnvollsten verwendet werden sollte.

Meine erste Blogengine, sunlog, bot meiner Erinnerung nach bloß ein Eingabefeld, in das man entweder HTML eingeben oder darauf setzen konnte, dass der ansonsten nicht weiter bearbeitete Text schon irgendwie ausgegeben werden würde.

Nach dem Umstieg auf Serendipity habe ich auch erst einmal den Standard-Editor verwendet, wozu braucht man schließlich WYSIWYG, wenn man HTML beherrscht? Das war auf die Dauer dann aber doch eher anstrengend: um jeden Absatz herum <p>...</p> schreiben, Hervorhebungen korrekt mit <strong>...</strong> einbauen, Links von Hand setzen … Das macht keinen wirklichen Spaß. Und der Einbau von Bildern ist von Hand auch eher eine Strafe als ein Vergnügen.

Also bin ich später auf den WYSIWYG-Editor von Serendipity gewechselt; ich glaube, ich habe sogar nacheinander verschiedene solche benutzt. So richtig zufrieden war ich damit aber auch nicht; das daraus generierte HTML erschien teilweise suboptimal, zwischendurch hatte das Gerät aufgrund irgendeiner (vermutlich von mir irrtümlich getroffenen) Einstellung die Neigung, alle Texte per <font>-Tag mit weißem Hintergrund zu hinterlegen und Spielereien dieser Art mehr. Außerdem war es so mit nicht unerheblichem Aufwand verbunden, Einträge in einem Texteditor vorzubereiten und später per copy & paste ins Blog zu übernehmen, bedurfte es dann doch eines zweiten Schrittes, in dem Formatierungen und Links hinzugefügt wurden, wie auch lx4r in einem vergleichbaren Blogbeitrag berichtet. Wenn ich stattdessen direkt im Editor schrieb, ereilte mich gerne ein Missgeschick wie “langen Blogeintrag geschrieben, abgeschickt, mittlerweile aber ausgeloggt” (worauf Serendipity den Beitrag üblicherweise hungrig verspeist und man ihn neu schreiben darf) oder, noch schlimmer, ich komme an eine Tastenkombination, die eine Browseraktion auslöst und dann den Browser den Text verschlucken lässt. Gut, dagegen hilft Lazarus, aber der wahre Jakob ist das trotzdem nicht, ganz abgesehen davon, dass man eben so nicht sinnvoll offline arbeiten (oder auch nur die Annehmlichkeiten eines guten Texteditors nutzen) kann.

Mit dem Relaunch des Blogs habe ich auch dafür eine Lösung gefunden: ich verwende den simplen Standardeditor von Serenditpity zusammen mit dem Markdown-Plugin. Wieder eine für mich sehr hilfreiche Anwendung von Markdown. Jetzt kann ich flüssig Texte schreiben, sie ggf. per copy & paste ins Blog übernehmen und muss mich nie wieder um seltsame Formatierungen kümmern. Passt. Das ist ein Workflow, der Spaß macht.

(Um zu verhindern, dass ältere Einträge durch das Markdown-Plugin zerhackt werden, kann man dieses Plugin für die älteren Einträge - jeweils einzeln pro Eintrag - deaktivieren. Jedenfalls dann, wenn man das Plugin “erweiterte Eigenschaften für Artikel” [serendipity_event_entryproperties] installiert hat. :-))

Geldsenke Amazon

Amazon habe ich als Buchladen kennengelernt, und früher habe ich dort auch (nur) Bücher gekauft. Dann ab und an auch mal Software, v.a. Spiele. Und DVDs. Und später dann Elektronikzeugs, und mittlerweile fast alles.

Das hat natürlich Folgen.

Wer das ungute Gefühl, dass Amazon für einen wesentlichen Teil des Ausgabenbudgets verantwortlich ist, einmal näher quantifizieren möchte, dem kann mit damazon.py geholfen werden.

(Wem - wie mir - pip install requests beautifulsoup4 nichts sagt, außer der Vermutung, dass es sich um entsprechende Bibliotheken handelt, die zunächst installiert werden müssen, dem hilft - wenn er nicht noch einen weiteren Paketmanager zusätzlich zu apt bzw. aptitude (Debian), cpan (Perl), gem (Ruby) und Co. auf dem System begrüßen möchte - unter Debian Wheezy auch die Eingabe von aptitude install python-requests python-bs4 weiter.)

Via @towo.

Markdown: HTML aus Text erzeugen

Der erste längere (Erläuterungs-)Text, den ich zur Veröffentlichung im Netz verfasst habe, war im September 1998 die Header-FAQ, deren erster Entwurf am 18.09.1998 in der Newsgroup de.admin.net-abuse.mail veröffentlicht wurde und die dann seit dem 15.10.1998 unter dem Titel “E-Mail-Header lesen und verstehen” dort über viele Jahre lang monatlich erschien.

Text- und HTML-Version

Natürlich sollte es zu der monatlich geposteten FAQ auch eine Web-Version geben, die bereits im Oktober entstanden war und deren URL im November 1998 das erste Mal in der FAQ genannt wurde. Und natürlich sollte diese Version auch mit allem Annehmlichkeiten, die HTML für Optik und Funktion bietet, also namentlich Formatierungen und Verlinkungen, ausgestattet sein. Das bedeutete dann umgekehrt aber auch, dass zwei völlig getrennte Versionen desselben Textes zu pflegen waren; insbesondere bei größeren Änderungen und Ergänzung keine wirklich gute Idee. Es musste also eine andere Lösung her: die eine Fassung sollte aus der anderen Fassung generiert werden, oder ggf. beide Fassungen aus demselben Rohtext.

HTML-Dokumente aus Textdokumenten erzeugen

Da mir das Usenet als Publikationsmedium (damals) deutlich näher lag, hatte ich zuerst den Gedanken, die Webseite - also das HTML-Dokument - zumindest im wesentlichen aus dem Textdokument der geposteten FAQ zu erzeugen. Bei entsprechenden Recherchen stieß ich dann auch auf das Tool AscToHTM, das genau diesem Zweck diente und sich auch insbesondere an FAQ-Autoren richtete. Eine Zeit lang habe ich damit auch gearbeitet (und das erzeuge HTML-Dokument dann quasi mit Header und Footer versehen, um es optisch und organisatorisch - Navigation! - in meine damalige Webseitenstruktur einzubinden), aber so wirklich überzeugend war das nicht. Es bedurfte einiger Kompromisse im Layout des geposteten Textes, um die HTML-Generierung überzeugend hinzubekommen, und der Aufwand war doch vergleichsweise groß.

Textdokumente aus HTML-Dokumenten erzeugen

Daher habe ich mich - theoretisch im übrigen völlig richtig - in der Folge davon überzeugen lassen, dass die Vorgehensweise, aus (letztlich) unstrukturiertem Text strukturierten Text (mit Markup) zu erzeugen, bereits gedanklich verfehlt ist und keinen dauerhaften Erfolg haben könne: HTML enthält gegenüber text/plain zusätzlichen Informationsgehalt, Struktur, Markup eben, und aus der Gestaltung des Rohtextes das Markup zu “erraten”, ist keine brauchbare Lösung. Daher bin ich danach dann eben den umgekehrten Weg gegangen und habe beschlossen, dass nunmehr die Webversion der FAQ das “Master-Dokument” (oder die Quelle) sein sollte und ich den geposteten Text daraus erzeuge. Information und optische Gestaltung zu kürzen sollte ja vergleichsweise trivial sein. — Ganz so war es dann erwartungsgemäß doch nicht, denn auch der gepostete “reine” Text sollte ja einigermaßen apart formatiert sein, mit dem was, man an “Formatierungen” in E-Mail und Usenet so gewohnt ist: Zitate eingeleitet mit “|” am Zeilenfang, Hervorhebungen und Betonungen durch *Sternchen* o.ä. und dieser Dinge mehr. Für den Anfang half dazu html2text, damals in C++ geschrieben, mittlerweile durch den verstorbenen Aaron Swartz auch in PYthon reimplementiert, aber ganz zufrieden war ich mit dem Output noch nicht.

Einiges Experimentieren führte dann zu dem folgenden Workflow:

  1. wget http://th-h.de/faq/$1 -O output.html
  2. html2text -nobs -width 70 -rcfile html2text.rc output.html > output.txt
  3. ./wrap.pl &lt; output.txt > wrapped.txt

Und wrap.pl, das (daher der Name) vor allem für den Umbruch auf 70 Zeichen pro Zeile unter Beachtung von (nicht zu umbrechenden Zitaten) zuständig war, sah folgendermaßen aus:

  1. #!/usr/bin/perl</p>
  2.  
  3. <p>use Text::Wrap qw(&amp;wrap $columns);
  4. $columns = 70;</p>
  5.  
  6. <p>while (&lt;>) {
  7.  if (/[-\/]$/) {
  8.   ($zeile, $rest) = /(.+\s)(\S+)$/;
  9.   print &#8220;$zeile\n&#8221;;
  10.   JOINLOOP: while (&lt;>) {
  11.    $rest .= $_;
  12.    last JOINLOOP if (/^$/);
  13.   }
  14.   $rest =~ s/\n/ /g;
  15.   $_ = wrap(&#8221;, &#8221;, $rest).&#8221;\n&#8221;;
  16.  };
  17. print $_;
  18.  if (/^[|>:]/) {
  19.   QUOTELOOP: while (&lt;>) {
  20.    chomp;
  21.    if (/^$/) {
  22.     print &#8220;\n&#8221;;
  23.     last QUOTELOOP;
  24.    } elsif (/^[|>:]/) {
  25.     print &#8220;\n$<em>&#8221;;
  26.    } else {
  27.     print $</em>;
  28.    }
  29.   };
  30.  };
  31.  print &#8220;\n&#8221;;
  32. };

Das ließ sich jetzt durchaus automatisieren; andererseits gefiel es mir nicht wirklich, dass die Quelle des Textes nun ein HTML-Dokument war und ich erst längere Konversionsprozesse laufen lassen musste, um zu überprüfen, ob auch die (aus meiner Sicht immer noch primäre) Textfassung ordentlich aussah. Und HTML schreiben ist auch deutlich aufwendiger als “Klartext”, selbst wenn man sich durch geeignete Editoren beim Einfügen der passenden Tags (und deren Schließen!) unterstützen lässt.

Die Lösung?

Am Ende habe ich, glaube ich, einfach wieder beide Texte getrennt gepflegt oder, wahrscheinlicher, die FAQ (erst einige Zeit nicht mehr richtig aktualisiert und dann) gar nicht mehr gepostet; sowohl das Spam-Problem (jedenfalls der Wunsch, Spam nachzuverfolgen und zu melden) als auch das Usenet waren dabei, in die Bedeutungslosigkeit abzurutschen.

"Markdown: HTML aus Text erzeugen" vollständig lesen

Serendipity, Spartacus und Dateirechte

Wie ich schon im Eintrag “Serendipity 2.0-beta” dokumentiert habe, hatte ich anfangs mit meiner Serendipity-Installation das Problem, das alle (über Spartacus) heruntergeladenen Plugins falsche Dateirechte hatten, die Verzeichnisse nämlich 0700 und die Dateien allesamt 0600. Das hatte zur Folge, dass der Webserver auf die Dateien und Verzeichnisse nicht zugreifen und u.a. Grafiken nicht anzeigen konnte, und auch sonst die Funktion der Plugins eingeschränkt war. Stattdessen müssten richtigerweise Rechte von 0755 und 0644 (oder zumindest 0705 und 0604) gesetzt werden.

Nachträglich beheben lässt sich das - im Verzeichnis plugins - ganz einfach so:

  1. find . -type d -perm 700 -exec chmod 755 &#8216;{}&#8217; \;
  2. find . -type f -perm 600 -exec chmod 644 &#8216;{}&#8217; \;

Nachdem ich einen Bug reportet hatte, bekam ich sehr schnell den richtigen Hinweis, dass die Spartacus-Konfiguration entsprechende Einstellungsmöglichkeiten aufweist, was ich übersehen hatte. Im Plugin lassen sich daher die richtigen Rechte vorgeben, und dann funktioniert die Installation auch zukünftig direkt problemlos.

Die Ursache für die zu strikten Rechte war für mich dann nicht auf Anhieb zu finden; die umask des Systems stand nämlich erwartungsgemäß und korrekt auf 0022. Allerdings setzte suphp für PHP dann noch einmal eine eigene umask in /etc/suphp/suphp.conf, und dort steht tatsächlich 0077

Wer also vor demselben Problem steht, sollte an der einen oder der anderen Stelle entsprechend den Schraubenzieher ansetzen.

Keywords: serendipity s9y spartacus plugins apache php suphp permissions too strict wrong

Serendipity 2.0-beta

Mitte April 2014, gerade als ich überlegte - und im Usenet diskutierte -, ob ich für den Relaunch meines Blogs weiter auf Serendipity (s9y) setze oder zu Wordpress wechseln soll, erschien die erste Beta des lange entwickelten Serendipity 2.0, auf die mich zuerst Dirk in seinem Blog aufmerksam machte und über die man kurz danach dann auch in Nur ein Blog lesen konnte.

Also habe ich ein Testblog aufgesetzt und mir das mal angeschaut, und nachdem das ganz gut lief und alles sehr schick aussah für den Relaunch meines Blogs direkt auch auf die Beta-Version gesetzt.

Unter anderem YellowLed und onli haben sehr gute Arbeit geleistet: das Standard-Template 2k11 funktioniert gut und ist sehr schick, und auch die renovierte Backend-Oberfläche kann auf den ersten Blick bereits optisch, aber auch technisch-inhaltlich gefallen. Insgesamt ist bereits die Beta einen Blick wert, und so stabil, wie man das von Serendipity gewohnt ist.

Natürlich gibt es auch noch einige kleine Fehler, Haken und Ösen:

  • Die Vorschaubilder der Templates (jetzt: “Themes”) stecken in riesig großen Rahmen, die zu Scrollorgien führen, weil ein Vorschaubild übergroß ist (mittlerweile behoben).
  • Das Einfügen von Bildern als Thumbmail mit Link auf das große Bild funktioniert mit dem eingebauten Button irritierender Weise nur beim ersten Mal; danach wird kein Link mehr generiert (mittlerweile behoben).
  • Ab und an (konkret insbesondere: beim Filtern bzw. Durchsuchen von Einträgen nach ihrem Inhalt) führt ein Druck auf die Enter-Taste nicht zum erwarteten Ergebnis, sondern zum Aufruf einer ganze anderen Seite (mittlerweile behoben).
  • Kategorien können über die Admin-Oberfläche nicht mehr bearbeitet werden, weil dann eine Namenskollision auftritt (bereits behoben).
  • Das serendipity_event_entrycheck-Plugin versagt schweigend: wenn es eigentlich wegen leerer Titel o.ä. das Speichern verhindern müsste, bestätigt es zumindest bei Entwürfen das erfolgreiche Speichern, verwirft den Eintrag aber (es lebe das Lazarus-Plugin für Firefox!).
  • Der schöne neue Button “Veröffentlichen” im neuen Admin-Dashboard für Entwürfe funktioniert nicht; der Eintrag wird zwar auf “veröffentlicht” gesetzt, erscheint aber nicht im Blog (mittlerweile behoben).
  • Zumindest bei mir hatten alle Plugin-Verzeichnisse und -Dateien zu strikte Zugriffsrechte.
  • Mit HTTPS werden (aufgrund der Protokollangabe in den Links zu CSS- und Javascript-Dateien) Stilinformationen, Icon-Schriften und Javascript nicht korrekt eingebunden.

Das sind jedenfalls die Kleinigkeiten - oder auch Größerigkeiten -, über die ich bisher gestolpert bin, aber: es wird!

Ich habe heute abend dann mal noch Bugreports für alle noch nicht bekannten Probleme eingeworfen (statt des Forums hat Serendipity dankenswerterweise jetzt auch einen Bugtracker in Form von github Issues) und bin sicher, dass wir in einiger Zeit einen Release Candidate und dann eine großartige 2.0-Version von Serendipity haben werden!

Nachtrag vom 19.05.2014 und 22.05.2014:

Das HTTPS-Problem lässt sich dadurch lösen, dass man unter “Konfiguration” (Block “Einstellungen” im Backend) und dort dann im Panel “Pfade” die Option “HTTP-Hostnamen automatisch erkennen” auf “Ja” setzt. Es handelt sich also eher um eine Fehlkonfiguration als einen Fehler. :-)

Und die Einstellungen für die Dateirechte lassen sich im Spartacus-Plugin vorgeben (was ich auch hätte bemerken können). Mit passenden Werten (0644 für Dateien und 0755 für Verzeichnisse) dort funktioniert dann auch alles blendend. - Allerdings sollten leere Eingaben dort einen Fallback auf die umask nach sich ziehen, und die ist korrekt auf 0022 gesetzt. Ganz in Ordnung scheint mir das daher noch nicht zu sein. Allerdings nur die umask des Systems. In der /etc/suphp/suphp.conf ist hingegen standardmäßig, auch unter Debian, eine umask von 0077 gesetzt … was das Problem erklärt. Also kein Fehler in Serendipity, sondern nur etwas, woran man denken sollte.

Nachtrag vom 10.06.2014:

Die meisten gemeldeten Probleme - und noch einige kleinere Baustellen, die mir zwischendurch aufgefallen sind - sind mittlerweile im Entwicklungszweig 2.0 bereits behoben.

Smaug - ein neuer Rechner

Viele Jahre lang war mein Hauptrechner mein jeweiliger Laptop (derzeit Landroval), vor allem auch deshalb, weil ich E-Mail und Newsgroups nicht sinnvoll zwischen Laptop und (verschiedenen) Desktop-Rechner(n) synchronisieren konnte und der Hauptteil meiner Zeit am Rechner für das Lesen und Verfassen von E-Mails und Newsbeiträgen aufgewandt wurde. In letzter Zeit hat sich das geändert; ich schreibe Scripts, bastele an Webseiten oder verfasse längere Texte, und all das geht an einem Desktoprechner mit großer Tastatur und einem entsprechend großen Bildschirm doch sehr viel angenehmer.

Glaurung, der bisherige Desktoprechner (seit Januar 2009), war allerdings einigermaßen in die Jahre gekommen, und gerne wollte ich einen neuen, aktuellen, leisen Rechner mit entsprechendem Hauptspeicher und vielleicht einer flotten SSD haben, um das Arbeiten noch angenehmer zu machen. Und diesen Wunsch habe ich mir im Sommerurlaub erfüllt und Smaug, den neuesten Zugang zum heimischen Rechnerpark, mittlerweile auch eingerichtet.

Hier werkelt nunmehr ein Intel Core i7-3770 (3.40 GHz “Ivy Bridge” 64bit) auf einem Z77-Mainboard von MSI mit 8 MB RAM in einem “HAF XM”-Gehäuse von CoolerMaster vor sich hin, dessen MSI NVIDIA GeForce GTX660 ihr Bild auf einen Samsung SyncMaster TFT mit 24 Zoll Bildschirmdiagonale wirft. System und Programme laufen von einer Intel-520-SSD mit 120 GB Kapazität aus, während die Daten auf einem 1-TB-Software-RAID aus zwei Western-Digital-Platten gespeichert werden. Diese Zusammenstellung sollte jetzt wieder einige Jahre klaglos ihren Dienst tun können. :-)

[Dieser Eintrag wurde nachträglich im Mai 2014 veröffentlicht.]

Vom Advisory zum Exploit binnen eines Tages

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

"Vom Advisory zum Exploit binnen eines Tages" vollständig lesen

Faxen via DECT

Es gibt Dinge, bei denen man sich denkt, sie müssten ja eigentlich ganz einfach sein, aber nicht wirklich daran glaubt, dass sie wirklich erwartungsgemäß funktionieren. Die Anbindung unseres neuen OfficeJet Pro 8600 als Fax an die bestehende Telefon”anlage” gehört dazu.

Wie ich in einem Nachsatz bereits berichtete befindet sich der Telefonanschluss - in Form einer DECT-Basisstation - in einem anderen Raum als der Drucker bzw. das Multifunktionsgerät, und eine kabelgebundene Anbindung wäre aufwendig und fände keine Gnade vor den Augen des hiesigen Entscheidungskomitees. Eigentlich, so dachte ich mir, müsste es aber doch auch möglich sein, das Fax drahtlos via DECT anzubinden, so wie ich die Rechner - übrigens mit einem Netgear WNCE2001 - drahtlos angebunden habe. So einer Basisstation sollte es doch gleich sein, ob ein Mobilteil oder ein Fax (drahtlos) “angeschlossen” ist. Fragt sich nur, ob es entsprechende Technik auch tatsächlich gibt …

Und die Antwort auf diese Frage lautet: Ja! Nicht (mehr?) sehr verbreitet und auch nicht zwingend günstig, aber es gibt solche Zauberkästchen, und seit kurzem bin ich in Form einer Distybox 300 glücklicher Besitzer eines solchen Geräts, dessen Installation (nach der richtigen Konfiguration via angeschlossenem Analogtelefon, glücklich, wer ein solches noch zur Hand hat) sich als überraschend problemlos erwies.

Und so haben wir jetzt auch ein drahtloses Faxgerät. :-)

[Dieser Eintrag wurde nachträglich im Mai 2014 veröffentlicht.]

HP OfficeJet Pro 8600

Die Zeiten, in denen im “Home Office” viel zu drucken war, sind weitgehend vorbei - und für die eher selten notwendigen Ausdrucke habe ich seit jetzt bald 10 Jahren meinen HP LaserJet 1015, der mir gute Dienste leistet. Ab und an möchte man aber dann vielleicht einmal etwas besonderes farbig drucken. Und manchmal - selten, aber doch - wäre auch ein Scanner ganz schön, und sei es, um mal eben etwas zu scannen und dann zu mailen. Für letzteres hatte ich irgendwann einmal von Rince ein altes Kombigerät, bestehend aus Flachbettscanner und Farbtintenstrahler, übernommen; das mit dem Scannen klappte auch so einigermaßen befriedigend, in Verbindung mit dem sehr praktischen Tool iCopy - das nichts mit Apple zu tun hat - waren auch Kopien möglich, nur die Druckköpfe hatten es trotz neuer Patronen, Reinigung, Wasser, Alkohol und viel Aufwand ganz offensichtlich hinter sich, wie damals bereits berichtet.

Lange habe ich sehnsüchtig durch Kataloge geblättert und mir Farblaserdrucker angeschaut. Und Farbtintenstrahler. Und Kombigeräte, die auch scannen und kopieren können. Und meiner Frau zugehört, die die meisten meiner Überlegungen - zu Recht - als Geldverschwendung abtat, und wenig Verständnis dafür hatte, dass es einen Wert an sich darstellt, wenn man ein neues Spielzeug auf dem (ohnehin zu vollen) Schreibtisch stehen hat.

Am Ende konnte ich mich aber durchsetzen: das Argument, mit einem schönen Kombigerät könne man endlich einmal vernünftig scannen, ohne Einschalten des Rechners und Hinzunahme des Laserdruckers kopieren und farbig drucken (und kopieren), überzeugte. Also durfte ich vergangene Woche einen HP OfficeJet Pro 8600 bestellen, und nachdem das Gerät angeschlossen und in Betrieb genommen wurde (und der Schreibtisch komplett umgeräumt ist - es ist dann doch etwas größer), bin ich damit sehr zufrieden.

Es tut seinen Zweck, Ausdrucke und Scans gefallen gut (beides funktioniert auch doppelseitig), ebenso die Benutzerführung, es gibt eine praktische Weboberfläche (und allen möglichen Cloud-Kram, dessen Notwendigkeit und Sinn sich mir bisher nicht erschlossen hat) und man kann direkt auf ein freigegebenes Verzeichnis auf den Server scannen, auf das man dann wiederum aus dem ganzen lokalen Netz zugreifen kann. So kann auch meine Frau scannen und dann von ihrem Rechner aus die Scans weiterverarbeiten, ohne dass man irgendwelche zusätzliche Hardware in Betrieb nehmen müsste. Und das Gerät hat einen Netzwerkanschluss, muss also nicht an den Server angeschlossen werden, um im ganzen lokalen Netz verfügbar zu sein, so dass sich das Problem der Treiber für CUPS nicht stellt.

Ich bin sehr zufrieden, und meine Frau auch. (Sie hat sich sogar freiwillig gemeldet, regelmäßig farbige Seiten zu drucken, damit die Tinte nicht eintrocknen kann. Ich bin noch nicht völlig überzeugt …)

Schade nur, dass der Telefonanschluss sich in einem anderen Raum befindet - die ganze Technik (Server, Desktop, jetzt auch Drucker) ist per WLAN angebunden, aber die Faxfunktion des Multifunktionsgeräts lässt sich so nicht nutzen. Und ab und an, selten, aber doch, wäre es schon ganz praktisch, ohne irgendwelche Verrenkungen Faxe versenden zu können (der Empfang lässt sich ja heutzutage über UMS-Dienste lösen).

[Dieser Eintrag wurde nachträglich im Mai 2014 veröffentlicht.]