Skip to content

Serendipity 2.0 ...

serendipity

Yippieh, da ist sie endlich die Version 2.0 der besten Blogsoftware der Welt.

Achtung: Das ist ein grosses Update. Macht bitte in jedem Fall vorher ein Backup Eurer Datenbanken und des Serendipity-Verzeichnisses. Wichtig ist auch, dass alle Plugins aktualisiert werden bevor es los geht.

Erfahrungsgemäss gibt es bei einem neuen Release immer Fehler, die erst auffallen, wenn eine breitere Masse testet, daher schlage ich vor, erst einmal zwei Wochen ins Land gehen zu lassen, bevor Ihr aktualisiert.

Hier im Blog läuft die 2.0 seit der ersten Beta-Version, vielleicht sogar schon früher, weiss ich gerade nicht.

Rechtsbelehrung ...

podcast

Der Podcast Rechtsbelehrung sollte zur Pflicht für jeden gehören, der irgendwelche (!) Online-Aktivitäten durchführt. Nachdem ich die ersten paar Episoden gehört hatte, wollte ich mich schon aus dem Netz zurückziehen, so viele Stolperfallen gibt es.

Interessanterweise habe ich auch erfahren (leider weiss ich die Folge nicht mehr), dass es eigentlich völlig sinnlos ist, mit dem Rootserver in die Schweiz zu wechseln, da sich das angewendete Recht nach dem Zielpublikum richtet. So ist beispielsweise die New York Times von einem Gericht in Deutschland rechtskräftig verurteilt worden, weil sie sie sich mit Artikel direkt an eine Leserschaft in Deutschland gewendet hat.

Das dürfte auch für die Schweizer Leser sehr interessant sein.

Da wir auf unseren Webseiten, die auf dem Rootserver laufen, ausschliesslich die Deutsche Sprache verwenden, ist das Zielpublikum schon einmal sehr eingeschränkt.

Mich würde ein solcher Podcast in der Schweiz auch sehr interessieren.

Benchmarking ...

Man kann viel über Tools lernen, wenn man nachvollziehbare Messungen macht.

Für mich hat sich als sinnvoll erwiesen, fünf Mal zu messen. Die beste und die schlechteste Messung wird gelöscht ("Ausreisser") und aus den verbleibenden drei Messungen nehme ich den Mittelwert.

Die Messungen für den Artikel dd vs. fallocate vs. truncate ... habe ich mit diesem Skript gemacht:

#!/bin/bash
set -o errexit

# echo 'sync ; time (dd if=/dev/zero of=10gig.dd count=20971520 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=1024 count=10485760 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=10240 count=1048576 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=20480 count=524288 ; sync)'
# echo 'sync ; time (fallocate -l 10G 10gig.fallocate ; sync)'
echo 'sync ; time (truncate -s 10G 10gig.truncate ; sync)'
for i in $(seq 1 5); do
        sync ; time (truncate -s 10G 10gig.truncate ; sync)
        rm 10gig.truncate
done

Dabei habe ich das Kommando eingesetzt, was ich gerade getestet habe.

Interessant ist, wie sich die Blocksizes bei dd auf die wirkliche Schreibperformance auswirken ... nämlich minimal. Hier kommen nur die mittleren der fünf Werte, die komplette Liste der Messwerte lässt sich hier sehen.

sync ; time (dd if=/dev/zero of=10gig.dd count=20971520 ; sync)
20971520+0 records in
20971520+0 records out
10737418240 bytes (11 GB) copied, 36.6231 s, 293 MB/s

real    2m2.442s
user    0m2.772s
sys     0m33.771s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=1024 count=10485760 ; sync)
10485760+0 records in
10485760+0 records out
10737418240 bytes (11 GB) copied, 20.5773 s, 522 MB/s

real    1m55.923s
user    0m0.974s
sys     0m19.529s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=10240 count=1048576 ; sync)
1048576+0 records in
1048576+0 records out
10737418240 bytes (11 GB) copied, 7.79126 s, 1.4 GB/s

real    1m53.523s
user    0m0.123s
sys     0m7.667s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=20480 count=524288 ; sync)
524288+0 records in
524288+0 records out
10737418240 bytes (11 GB) copied, 6.87154 s, 1.6 GB/s

real    2m8.122s
user    0m0.068s
sys     0m6.808s

Die Cloud ...

Hier ist endlich einmal eine gelungene Übersichtsgrafik, was mit den ganzen Abkürzungen im Cloud-Umfeld "eigentlich" gemeint ist. Die Bausteine bedingen einander.

Software as a Service (SaaS) setzt auf Platform as a Service (PaaS) auf, die als Basis Infrastructure as a Service (IaaS) hat bis schliesslich die Hardware als Fundament erreicht ist.

(Die verlinkten Wikipedia-Artikel sind auch lesenswert).

Nils Magnus/inovex GmbH

Die Grafik ist dem lesenswerten Artikel Cloud Computing - The Name of the Game entnommen und die Veröffentlichung erfolgt mit freundlicher Genehmigung von Nils Magnus und Marius Moise (beide inovex GmbH). Vielen Dank!

dd vs. fallocate vs. truncate ...

linux

Gerade bei Virtualisierung kommt man nicht darum herum, Filesystem-Container in einer bestimmten Grösse anzulegen, wenn man nicht komplette Devices übergeben kann oder möchte.

Der Standardweg war bisher, einen solchen Container bzw. eine solche Datei mit dem Kommando dd zu erzeugen. Das kann zuweilen schon einmal einige Zeit benötigen, wie hier auf einem Testserver zu sehen ist:

dirk@testserver:~$ sync ; time (dd if=/dev/zero of=10gig.dd bs=1024 count=10485760 ; sync)
10485760+0 records in
10485760+0 records out
10737418240 bytes (11 GB) copied, 20.7891 s, 516 MB/s

real    1m42.645s
user    0m0.942s
sys     0m19.807s

Die Dauer resultiert daher, dass dd jeden einzelnen Block schreibt (bzw. kopiert) und 10 GiB schreiben, dauert ein wenig ...

Insbesondere ist spannend zu sehen, dass das dd-Kommando bereits nach etwa 21 Sekunden fertig ist, es aber weitere 80 Sekunden dauert bis alles auf der Festplatte ist.

Ein Arbeitskollege wies mich jetzt auf fallocate hin, was ich bisher noch nicht kannte.

dirk@testserver:~$ sync ; time (fallocate -l 10G 10gig.fallocate ; sync)

real    0m0.165s
user    0m0.000s
sys     0m0.013s

Das Programm ist so schnell, weil nicht 10 GiB an Daten geschrieben werden, sondern nur der Platz für die Datei reserviert wird. Das ist völlig ausreichend für nahezu alle Anwendungsfälle.

Die Filesysteme, die fallocate unterstützt sind btrfs, ext4, ocfs2 und xfs.

Das dritte Programm im Bund ist truncate.

dirk@testserver:~$ sync ; time (truncate -s 10G 10gig.truncate ; sync)

real    0m0.087s
user    0m0.000s
sys     0m0.007s

Es ist noch ein wenig schneller als fallocate, weil es mogelt. Es erzeugt ein "sparse file" und gaukelt dem Betriebssystem vor, dass dort eine Datei mit lauter Nullen zu finden ist. Spätestens wenn man eine bestimmte Position in der Datei springen oder etwas verändern will, werden die I/O-Operationen durchgeführt, die man anfänglich vermieden hat.

Aus Sicht des Nutzers sehen alle drei Dateien gleich aus.

dirk@testserver:~$ ls -lah 10gig.*
-rw-r--r--. 1 dirk dirk 10G Jan 10 15:46 10gig.dd
-rw-r--r--. 1 dirk dirk 10G Jan 10 15:48 10gig.fallocate
-rw-r--r--. 1 dirk dirk 10G Jan 10 15:50 10gig.truncate

Die Empfehlung ist aber, in jedem Fall fallocate zu nutzen und nicht dd oder truncate oder anders ausgedrückt, Ihr solltet wissen, was die drei Programme tun und dann das passende für Euren Zweck auswählen.

DeimHart ist beendet ...

deimhart

Natürlich muss ich das auch hier im Blog erwähnen, nachdem ich gestern die offizielle Mitteilung über das Ende von DeimHart geschrieben habe.

Es war eine schöne Zeit - immerhin fünf Jahre - und es hat immer Spass gemacht. Wir haben viele nette Leute bei uns zu Gast gehabt und auch einige thematische Tiefen durchschritten. Was übrigbleibt, ist ein bisschen Wehmut, rund 80 Audiofolgen mit - neben dem regulären - auch experimentellen Formaten.

Durch Eure Kommentare habt Ihr und immer angespornt weiter zu machen. Das hätten wir auch gerne getan, wenn Romans Erkrankung und die daraus resultierenden Spätfolgen nicht dazwischen gekommen wären.

Mir bleibt nur ein schnief und ein grosses Danke schön! an Euch.

Eine Bitte hätte ich, kommentiert bitte drüben bei DeimHart, wenn Euer Kommentar für Roman und mich bestimmt ist.

Ach ja, und wir benötigen dringend bespendbare Projekte, an die wir das Geld für unser Crowdfunding weitergeben dürfen.

Git-Server auf CentOS ...

centos

Eigentlich ist "Git-Server" etwas hoch gegriffen, da als Server-Komponente SSH zum Einsatz kommt. Nichtsdestowenigertrotz ist das Endergebnis ein Git-Repository-Server, den man sehr bequem nutzen kann.

Für den Server habe ich einen User git (UserID 600) angelegt, mit dem die Repositories verwaltet werden sollen und das Homeverzeichnis soll unter /srv/git liegen:

groupadd -g 600 git
useradd -u 600          \
        -g 600          \
        -d /srv/git     \
        -m -s /bin/bash \
        git

Eine Besonderheit unter CentOS ist, dass dort SELinux läuft und wir dem System bekanntgeben müssen, dass es sich bei /srv/git um ein Homeverzeichnis handelt. Die einfachste Methode ist, den Kontext eines bestehenden Homeverzeichnisses auf das neue Verzeichnis zu übertragen.

semanage fcontext -a -e /home/dirk /srv/git
restorecon -R -v /srv/
ls -Zd /srv/git

Zu SELinux gibt es reichlich Dokumentation, ich verweise hier einmal auf den SELinux User's and Administrator's Guide bei RedHat. SELinux kann man auch abschalten, wenn einem der Aufwand zu hoch ist.

Der Rest ist relativ einfach und geht strikt nach der gitolite-Anleitung.

Den eigenen Public-Key (wird benötigt, um gitolite zu verwalten) in das Verzeichnis /srv/git kopieren, für mich hat sich dafür das Format user-host.pub bewährt (ich habe auf jedem Host einen separaten SSH-Key und nutze nicht überall den gleichen).

git clone git://github.com/sitaramc/gitolite
mkdir -p ${HOME}/bin
gitolite/install -to ${HOME}/bin
export PATH=${HOME}/bin:${PATH}
echo 'PATH=${HOME}/bin:${PATH}' >> ${HOME}/.bashrc
gitolite setup -pk user-host.pub

Fertig!

Die restliche Konfiguration läuft über das admin-Repository, das man auschecken muss und dann bearbeitet. Die neue Konfiguration ist direkt nach einem git push aktiv.

git clone git@host:gitolite-admin.git gitolite-admin-host.git

Dort finden sich im keydir-Verzeichnis alle Public Keys von Usern, die Zugriff auf irgendeines der Repositories haben sollen und im Verzeichnis conf liegt die gitolite.conf mit einem Beispiel-Repository.

Viel Spass!

Taskserver auf CentOS 7 ...

centos

Im Rahmen meines privaten Migrationsprojektes habe ich natürlich mit Hürden gerechnet, manchmal tauchen die Herausforderungen allerdings an unerwarteten Stellen auf.

Taskserver lässt sich nach Dokumentation relativ leicht installieren. Allerdings läuft bei CentOS 7 ein firewalld mit, der eingehende Verbindungen blockt, was meiner Meinung nach sinnfrei ist, wenn es nur ein Netzwerkinterface hat, aber gut.

Mittels

firewall-cmd --zone=public --add-port=53589/tcp

lässt sich der firewalld überzeugen, eingehende Taskserver-Verbindungen zu akzeptieren.

Serendipity 2.0 RC2 ...

serendipity

Tja, aus diesem Grund macht man Releasekandidaten, um möglichst schnell feststellen zu können, ob es noch Probleme gibt, die behoben werden müssen.

Wenn Ihr den RC1 installiert habt, installiert bitte ohne Umweg und ohne über Los zu gehen, den RC2, es ist ein kritischer Fehler gemeldet worden.

Serendipity 2.0-rc2 released

Es ist nur eine Datei betroffen, es ist ausreichend, wenn die ausgetauscht wird:

templates/2k11/admin/overview.inc.tpl

Serendipity 2.0 RC1 ...

serendipity

Der erste Release-Kandidat der "besten Blogengine der Welt" wurde am vergangenen Samstag veröffentlicht und steht für eine breitere Masse an Menschen, auch für Dich, zum Test bereit. Ich bitte zu beachten, dass das noch nicht die finale Version ist, aber, da ich die 2.0 seit der Alpha-Version einsetze, vermute ich, dass das Risiko bei einem Wechsel überschaubar ist.

Malte fasst sehr gut die Änderungen in einem Blogartikel zusammen und Matthias schreibt noch ein paar Dinge zum Hintergrund.

Wer mitverfolgt hat, wie sparsam die Versionsnummern bisher aktualisiert wurden, sieht, dass die neue Version ein Riesenschritt beinhaltet. Serendipity ist im Backend deutlich moderner geworden und sieht grossartig aus. Meiner Meinung nach hat sich die Funktionalität durch die Änderungen auch deutlich erhöht.

Ich freue mich riesig darüber, dass sich so viel getan hat. Serendipity hat vielleicht nicht die Verbreitung wie Wordpress, dafür aber eine sehr nette Community, die immer offen für Änderungen und Anpassungen war und ist.

In dem Zusammenhang ist vielleicht zu Erwähnen, dass für 2015 ein Serendipity-Wochenende im Linuxhotel geplant ist. Informationen dazu finden sich im Forum.

Kein guter Start ...

fedora

Wie schon vor längerer Zeit angekündigt, wollte ich meinen Hauptrechner auf Fedora umstellen. Interessanterweise hat weder bei der Installation noch danach das Kabel gebundene Netzwerk funktioniert. Das hatte ich bei Linux unabhängig von der Distribution tatsächlich noch nie.

Allerdings war schon spannend, dass ich das WLAN nach der Installation nutzen konnte. Nachdem die Updates eingespielt waren, funktionierte auch Netz über Kabel. Verrückt!

Es wäre klasse, wenn die Installationsmedien entsprechend angepasst würden.

Nachtrag: In den Common F21 bugs, habe ich den Eintrag IP address discovery via DHCP does not work gefunden.

PHP Fortgeschrittene ...

In der letzten Woche durfte ich die Schulung PHP Fortgeschrittene im Linuxhotel besuchen. Gehalten wurde die Schulung von Martin "Joey" Schulze.

Das war mein vierter Aufenthalt im Linuxhotel, aber das erste Mal, dass ich dort eine Schulung besucht habe. Und, ich muss sagen, dass die Schulung grossartig war. Danke Joey! (Lasst Euch von seiner Webseite nicht blenden, er hat wirklich etwas drauf).

Erschreckenderweise - als alter Perl-Liebhaber - muss ich gestehen, dass ich auch von den Möglichkeiten von PHP sehr angetan bin. Da kann man mit relativ wenig Aufwand sehr gute objektorientierte Programme schreiben.

Ich habe viel gelernt!

BTW: PHP muss ich lernen, weil ich in der Firma ein in objektorientiertem PHP geschriebenes System übernehme und erweitern soll. Meine Einarbeitung in PHP - also das Basiswissen - habe ich mir mit diesem Buch angeeignet.

Vielleicht ergibt sich darüber auch die Möglichkeit, "die beste Blogsoftware der Welt" in der Programmierung zu unterstützen.

Der Aufenthalt im Linuxhotel war nett und ich habe es sehr genossen, abends meine Eltern besuchen zu können, so häufig kommt das ja leider nicht mehr vor.

Poodle ...

Es gibt nicht weniger Sicherheitslücken als früher, sie erreichen nur einen grösseren Anwenderkreis.

Die neueste Lücke betrifft die Version 3 von SSL und nennt sich Poodle. Ich zitiere einmal aus dem verlinkten Wikipedia-Artikel:

Mozilla Firefox deaktiviert ab Version 34 SSL 3. In älteren Versionen muss unter about:config der Wert security.tls.version.min auf 1 gesetzt werden.

In Google Chrome und Chromium wird SSL 3 manuell auf der Kommandozeile mit dem Parameter -ssl-version-min=tls1 abgeschaltet.

Im Internet Explorer muss unter "Internetoptionen" > "Erweitert" > "Sicherheit" der Haken bei "SSL 3 verwenden" entfernt werden. Lediglich der ursprünglich mit Windows XP ausgelieferte Browser Internet Explorer 6 unterstützt das nachfolgende TLS 1.0 noch nicht.

Meiner Erinnerung nach war das schon länger bekannt, es kocht gerade nur wieder einmal hoch.

Bloonix wird Open-Source-Software ...

Der Monitoring-Dienst Bloonix von Jonny Schulz wird Open-Source-Software. Über den Dienst habe ich hier im Blog schon einmal berichtet.

Ich freue mich sehr darüber, da ich das für eine ausgereifte Lösung halte, die von Jonny mit viel Liebe gepflegt wird. Ausserdem ist es an der Zeit, dass es eine weitere Alternative zu den derzeitigen Platzhirschen gibt.

Well done!

In dem Zusammenhang: Mein privater Server wird von Bloonix überwacht.