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.

Wir werden uns mit einigen Interessierten zum ersten Mal "in persönlich" Im Linuxhotel treffen.

Matthias war so freundlich, die Rahmeninformationen in einem Text zu sammeln.

Hier nur kurz die Information:

• Termin: 06.-08.03.2015 im Linuxhotel in Essen
• Bei dem Wochenende geht es darum, dass wir uns kennenlernen.
• Das ist ein Community-Angebot des Linuxhotels.
• Wer im Hotelzimmer übernachten möchte, muss sich bis zum 19. Februar 2015 bei mir melden.
• Tagesgäste sind willkommen, aufgrund der besseren Planbarkeit bitte ebenfalls mir Bescheid sagen.

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.

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.

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

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.

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.

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.

Je länger ich mich mit der Shell (BaSH in diesem Fall) beschäftige, desto mehr denke ich, dass ich schon alles gesehen habe.

Dieses Konstrukt aber ist mir neu, ja das mit < <(kommando) und vielleicht kann das auch jemand von Euch brauchen.



Es macht einen tail -f logfile und durchläuft die Schleife für jede Zeile im logfile . Alle Zeilen werden ausgegeben und wenn ein Suchtext im logfile vorkommt, wird die Schleife abgebrochen. Für die, die es nicht kennen, mit =~ kann man ab BaSH Version 3 auch mit regulären Ausdrücken suchen. Die Schrägstriche / werden nur für den Fall benötigt, dass im logfile auch Leerzeilen vorkommen.

Das Konstrukt umschifft einige Schwächen, die ähnliche Beispiele haben, die mit anderen Arten von Ein- und Ausgabeumlenkung arbeiten.

Wer es nicht glaubt, kann mal das Folgende probieren:

Ich bin mir nicht sicher, ob das für irgendjemanden hilfreich ist.

Die Schulung habe ich vor fast einem Jahr gehalten und ohne meine Erläuterungen helfen die "Folien" vielleicht nicht so viel. Die Firmeninterna, die ich ebenfalls geschult habe, wurden aus der Präsentation entfernt.

Highlights sind vielleicht, die allgemeine Einführung (Seiten 3-10), Überblick Filesysteme (Seiten 29-32), Einführung vi(m) (Seiten 33-43) und Links und Literatur (Seite 92-99).

Euer Feedback ist erwünscht.



linux.pdf (etwa 900 kB, Links sind klickbar)