Seit dem ich mir vor einigen Wochen einen vServer angemietet habe, habe ich mich wieder verstärkt mit Linux beschäftigt. Und nach meinem Rage Quit vor zwei Wochen sowie der anschließenden Frustration, bin ich wieder sehr von der Struktur von Linux angetan. Diese hatte zwar im Großen und Ganzen nichts mit meinen Ärgernissen zutun, aber meine Unkenntnis über das System trugen ihren Teil bei. Jetzt, wo aber alles soweit läuft, wie ich es möchte, muss ich sagen, dass Linux, in meinem Fall Ubuntu, verständlicherweise von vielen gelobt wird.
Aus diesem Grund übernehme ich heute einmal diese Linux-Neuigkeit, welche den ein oder anderen freuen wird. Der Entwickler von Systemd Lennart Poettering gab heute in einem Blog-Beitrag bekannt, dass es bald zwei neue Systemd-Werkzeuge geben wird. Diese heißen „Mkosi“ und „Casync“. Mkosi erlaubt es OS-Images zu generieren. Während Casync beim Verteilen dieser hilft.
Woher kommen die Namen? Nun ja „mkosi“ bedeutet lang „Make Operating System Image“ und ist inspiriert von mkdir sowie mkfs. Clever nicht war? Casync ist dabei eine simple Kombination aus Rsync und dem Content-Address-Ansatz von Git, welche zugleich die Basis von Casync sind.
Mkosi ermöglicht es Entwicklern einfach bootbare OS-Images zum Testen und Debuggen zu erstellen. Auch kryptografisch geschützte Images für den produktiven Einsatz sind möglich. Für die Images benutzt Mkosi aktuelle Techniken, wie z.B. GPT-Partitionstabellen, so Golem. Damit laufen die Abbilder nur auf Systemen mit EFI-Firmware. Genauer gesagt, werden rohe GPT-Abbilder mit wahlweise Ext4, Btrfs und Read-Only-Squashfs als Root-Dateisystem erzeugt. Als Alternative kann auch ein flaches Verzeichnis erzeugt werden, welches den reinen OS-Baum enthält, ein Btrfs-Subvolume oder den Tarball eines flachen Verzeichnisses.
Es gibt noch zahlreiche weitere Möglichkeiten, welche man in der Ankündigung weiter unten nachlesen kann. Was macht nun aber Casync? Dies ist zum Verteilen der erstellten Images gedacht und kombiniert, wie bereits geschrieben, die Rsync-Algorithmen mit dem Content-Address-Ansatz von Git. Vereinfacht soll das heißen, dass der Chunking-Algorithmus die Daten serialisiert und in verschieden große Teile zerteilt. Diese xz-komprimierten Chunks sollen dann in einem Chunk Store landen, während ein Chunk Index mithilfe einer SHA256-Hashfunktion sich die Reihenfolge merkt. Danke dahingehend nochmal an Golem für die gute Vereinfachung.
