Dirks Logbuch

Wenn auf einem Linux-System Updates eingespielt werden, beispielsweise von Bilbiotheken, die von vielen Programmen benutzt werden, dann werden die neu installierten Libraries erst benutzt, wenn ein neues Programm gestartet wird. Alle bereits laufenden Programme nutzen noch die Bibliothek, die vor dem Update vorhanden war.

Um festzustellen, welche Programme das sind, gibt es unter CentOS das Skript needs-restarting, es ist im Paket yum-utils zu finden. Unter Debian und Ubuntu heisst das Skript checkrestart und ist im Paket debian-goodies zu finden.

Es lohnt sich, diese Skripte direkt nach einem Update auszuführen, um sich nicht in falscher Sicherheit zu wiegen.

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:


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.

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).



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!

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:



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.



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.



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.



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.

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:


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.

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).


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.


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!

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

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

Das neue Jahr beginnt mit einer neuen Version von Taskwarrior.

Es gibt einige spannende Neuerungen, die einen Blick wert sind.

Fragen? Fragen!

ACHTUNG:

In dieser Version wurden die Kommandos push, pull und merge entfernt.

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.

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.

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.

Gestern Abend hat die erste Beta von Taskwarrior 2.4.0 das Licht der Welt erblickt.

Es ändert sich eine Menge. Leider fallen mit Version 2.4.0 die alten "Synchronisations"-Mechanismen, die auf Curl aufsetzen weg. Mit Taskserver gibt es eine neue Möglichkeit, die Aufgaben zu synchronisieren.

Dafür gibt es eine Reihe neuer Features, die drei, die für mich herausragen sind:

• Calc command task calc '1 + 1' Hint: it's '2', but it's a beta, so who knows? And yes, it can do more than that. Enhanced DOM support task add due:123.due Date math task add ... due:eom wait:'due - 1week'

Es gibt aber deutlich mehr Änderungen, die im News-Artikel erwähnt sind und noch weitere, die im Changelog zu finden sind.

Testet bitte reichlich und gebt uns Rückmeldungen.

Als Nachschlag zu diesem Artikel kamen in der gleichen Keynote noch ein paar Bemerkungen, zu dem, was eine (Perl-)Community braucht.

Das lässt sich eins-zu-eins auch auf andere Communities beziehen, deswegen schreibe ich das hier im Blog.

Eine Community braucht:

• producers
• consumers
• critics
• curators

Ich würde lieber "creators" statt "producers" schreiben, dann fängt alles wenigstens mit "c" an.

Jede Community braucht also Erzeuger (oder Gestalter oder Produzenten) von Inhalten und Programmen und was die Community auch immer ausmacht. Es werden Konsumenten benötigt, die die Erzeugnisse auch benutzen. Konstruktive (!) Kritik ist wichtig, nicht nur "Verneiner" oder Menschen, die das Schild "Dagegen" hochhalten. Und zusätzlich werden Menschen gebraucht, die die Inhalte verwalten, weiterpflegen und auch Werbung dafür machen.

Wenn man sich das anschaut, so gilt das für jede Community und auch jeden Verein.

Brian d foy fasst das drumherum in einem weiteren Blog-Artikel bezogen auf die Perl-Community zusammen:

[...]
The Perl projects that survive and do well are the ones that have constant human input and have someone who pays attention to them everyday. It's not enough to have a webpage or a Twitter account, or to upload some code.
[...]
It's not something that we can optimize or automate away. We've seen what happens when we do that: no one sticks around. If you want to build community, you need dedicated organizers and agitators who personally interact with people to find out what they think and want. You can't get that from surveys. Someone needs their finger on the zeitgeist.
[...]

Also übersetzt und kurz zusammengefasst. Es überleben nur die Projekte, die aktiv sind und regelmässig (täglich) gepflegt werden. Definitiv nicht ausreichend ist es, nur eine Webseite oder einen Twitteraccount zu erstellen und etwas Inhalt hinzuzufügen. Das kann nicht automatisiert werden, es muss Leute geben, die persönlich mit Menschen interagieren, um herauszufinden, was gewünscht wird. Das bekommt man nicht durch Umfragen heraus, jemand muss den Zeitgeist spüren.

Vielleicht ist das auch der Grund, weshalb wir mit DeimHart einen solchen Erfolg haben oder weshalb die deutsch sprachige Ubuntu-Community in Summe ein Erfolgsmodell ist.

Die Abkürzung "JFDI" sieht auch wie "Jedi", deswegen mag ich sie. Sie steht für "Just fucking do it". Wenn Ihr Euch irgendwo beteiligen könnt, macht es einfach.

Bezogen auf Linux denke ich gerade über einen Wechsel im grossen Stil nach. Beruflich habe ich neben kommerziellen Unixen (momentan zu 100% Solaris) nahezu ausschliesslich mit Red Hat Enterprise Linux zu tun.

Dem möchte ich gerne privat Rechnung tragen. Die Server sollen auf das "Community Enterprise Operating System" CentOS migriert werden und der Desktop auf Fedora. Das passiert nicht "von Heute auf Morgen", ich habe vorher noch dringendere Arbeiten zu erledigen.

Axel schrieb ja schon einmal:

Irgendwie werde ich das Gefühl nicht los, dass Dirk nie lange bei einer Distribution bleiben wird. Marcus scheint da ähnlich zu ticken. Wirklich verstanden wieso, habe ich bisher nicht.

Mir wäre es jedenfalls viel zu mühsam, alle paar Monate meine produktiven Kisten neuzuinstallieren und mich wieder an was neues gewöhnen zu müssen, trotz dass ich die meisten Konfigurationdateien für mein $HOME in Git-Repositories habe. (Ein weiter Grund für Debian: Nie Neuinstallieren, nur alle paar Jahre mal Dist-Upgraden.

Ja, ich habe die für mich ideale Distribution noch nicht gefunden. Nachdem letztlich ein Dist-Upgrade von Squeeze auf Wheezy mal so richtig viel Nacharbeit erfordert hat, hat das Ansehen von Debian bei mir eine deutliche Macke bekommen. Um eventuellen Nachfragen und dummen Kommentaren vorzubeugen: Es kamen keine Fremdrepositories zum Einsatz. Im "Normalbetrieb" kann ich mich nicht beklagen, da tut Debian seinen Dienst sehr gut.

Der Grund, der Axel bewegt bei Debian (für immer) zu bleiben, ist bei mir der Grund zu wechseln, ich möchte mich auch nicht immer an etwas Neues gewöhnen müssen. Der Unterschied ist, dass ich beruflich und privat zwei Welten bediene. Aber letzten Endes ist die Wahl der Distribution zweitrangig und fast nur Geschmackssache. Wie schon häufiger erwähnt, könnte ich meine private und berufliche Arbeit auf nahezu jedem System erledigen.

Eventuell liegt es auch an der Grundeinstellung, ich sehe mich eher als Linuxer als als Vertreter einer bestimmten Distribution. Und das wirklich schöne ist, dass man auch bei einem Distributionswechsel fast alles weiterverwenden kann, die Programme sind ja grösstenteils die gleichen.

Im Job sind die meisten Server nur einer einzigen Aufgabe (oder Webseite) zugeordnet. Privat verwalte ich rund 30 Domains mit entsprechenden Diensten.

Da ich nicht das Debian-Konfigurationsschema auf CentOS portieren möchte, suche ich nach Dokumentation, die gezielt auf Debian-Umsteiger abzielt. Habt Ihr da Tipps?

Bezüglich Fedora brauche ich noch Hinweise auf "non-free" Software, leider für die üblichen Verdächtigen mp3-Support, DVD und Flash. Da scheint RPM Fusion das Mittel der Wahl zu sein. Weitere Tipps nehme ich sehr gerne entgegen.

Bin für jeden Hinweis dankbar.

Hier ist das Bild des vermutlich jüngsten Lesers, unseres Adminbuchs, das übrigens Ende des Monats in einer neuen Auflage erscheint.

Danke Arthur!

Und vielen Dank auch, dass ich das Bild verwenden darf.

Ein Kollege von mir hat die "Source"-Schriftserien von Adobe ausgegraben und mir gefallen sie so gut, dass ich meinen Desktop angepasst habe, um sie zu benutzen.

Die drei Schriftarten, um die es geht heissen:

• Source Code Pro - eine Schriftart, die sich sehr gut als Schriftart für Monospaced-Geschichten eignet, beispielsweise als Default-Schrift in Editoren oder Terminalfenstern.
• Source Sans Pro - ist perfekt für Menüs und Übersichten auf dem Desktop (ersetzt bei mir Deja Vu Sans).
• Source Serif Pro - passt sehr gut bei Drucksachen.

Dass Adobe selber auch im Rahmen von Open@Adobe Teile ihrer Entwicklung als Open-Source-Software veröffentlichen war mir neu. Eine Übersicht findet sich auf der Projekt-Seite.