Jail - welche Art

P

pom

Well-Known Member
Hallo,

ich habe auf einem FreeBSD Server, den ich über viele Versionen hinweg immer aktuell gehalten habe, einige Jails, die ich seinerzeit mit ezjails eingerichtet habe.
Es scheint so, dass das nicht mehr weiterentwickelt wird.

Nun frage ich mich
a) ob ezjails nach wie vor eine gute Wahl ist, oder ich befürchten muss, dass ein kommendes Update mein Jail Setup unbrauchbar macht
b) auf welcher Basis / Verwaltungstools man heute Jails einrichten würde
c) wie ich meine Jails einfach dahin migrieren kann

Für jede Jail existieren folgende Mounts (Bsp für SVN):

/home/jails/basejail on /home/jails/svn/basejail (nullfs, local, read-only, nfsv4acls)
/usr/ports on /home/jails/svn/usr/ports (nullfs, local, read-only, soft-updates, journaled soft-updates)
devfs on /home/jails/svn/dev (devfs)
fdescfs on /home/jails/svn/dev/fd (fdescfs)
procfs on /home/jails/svn/proc (procfs, local)

Im Handbuch werden Thin und Thick Jails unterschieden. Auf was deuteten die Mounts hin :-) ?

Das System ist aktuell bei 14.2-RELEASE-p2

Danke und Gruß,
Peter
 
Ich würde für jedes Jail eine eigenes ZFS-FS erstellen und alle eizeln verwalten. Ich verwende dazu nur die Tools vom Basissystem und ein paar eigene Scripts, die aber nur Kosmetik sind. Früher habe ich ein Basisjail erstellt durch Snapshots diese auf die Jails verteilt. Mitlerweile verzichte ich aber darauf. Platz ist ja meist genügend da.
 
Was @jmt sagt würde ich voll unterstützen.

Ich habe jahrelang iocage Base-Jails genutzt, was ja dann auch nicht mehr (oder kaum noch?) weiterentwickelt wurde. Das ganze benötigte immer ein großes Geraffel an Python-Packages, was mich bei jedem Update etwas nervös machte: Wie starte ich meine Jails, wenn ein von iocage benötigtes Python-Paket nicht da ist oder nicht funktioniert. Base-Jails waren insofern cool, als System-Update/-Upgrades sehr einfach und schnell gingen - wenn sie denn gingen. Wenn bei einem Upgrade etcupdate einen manuellen Eingriff erforderte, war man jedes Mal aufgeschmissen und musste mühselig drum herum arbeiten.

Ich würde wie von jmt vorgeschlagen, für jede Jail mind ein eigenes root Verzeichnis als ZFS-Dataset anlegen. Dann mit bsdinstall jail /pfad/zum/jail-rootverzeichnis das Basissystem der Jail installieren. Je nach Bedarf kannst Du vorher weitere Datasets anlegen, z.B. wenn Du die einzeln Snapshotten willst (ich will z.B. immer /etc und /usr/local/etc separat Snapshotten können) oder für MySQL die ZFS-Datasets für die Datenbank-Dateien optimieren (siehe z.B. die Empfehlungen im MariaDB-Serve package ).

Für devfs, fdescfs und procfs gibt es eigene Konfigurationsanweisungen für die /etc/jail.conf. Das kannst Du für alle oder für einzelne Jails spezifizieren.
Code: 
mount.devfs
mount.fdescfs
mount.procfs

Am Ende musst Du die benötigten Ordner/Dateien aus Deiner alten Jail in die neue rüberkopieren (sicher einiges aus den etc-Verzeichnissen und ansonsten das, was Deine jeweiligen Anwendungen verwenden, z.B. sowas wie /usr/local/www/data wenn Du einen Webserver am Laufen hast usw.)
 
Da die Jail-Konfiguration globbing unterstützt kannst Du auch für jedes Jail getrennt eine eigene jail.conf anlegen. Bei mir liegen die z.B. unter /jails/{jail-name}/ . Dort habe ich dann eine jail.conf und das Direktory für das rootfs der Jail.
 
Ich habe für die Jail Verwaltung "BastilleBSD" für micht entdeckt. Wurde hier auch schonmal öfters erwähnt und ist quasi der Nachfolger von iocage. BastilleBSD ist allerdings ein bash Shell Skript (mehrere). Die Python Abhängigkeit von iocage fand ich auch schlimm. Vor allem hat der iocage Befehl ewig gebraucht bis er mal was angezeigt hat.
 
Was mir noch nicht klar ist, ist die Rolle der Basejail in mein Setup. Ist das das FreeBSD Basissystem, das durch ezjail in neue Jail kopiert wird (wie Fat Jail). Oder ist das im Sinne einer Thin Jail das System, das für jede Jail irgendwie in die Jail gemounted wird - d.h. gleich für jede Jail ist?
 
Soweit mir bekannt verwendet ezjail Thin-Jails. Also wird das Basisjail in jedes Jail gemountet. Hiermit ergibt sich dann auch gleich ein Problem, dass eine Änderung am Basisjail alle Jails betrifft. Deshalb verwende ich kein Basisjail, sondern erstelle jedes Jail mit bsdinstall neu. Dann sind alle Jails unabhängig und können einzeln geupdated werden.
 
Auch wenn ich nicht weiß obs da wirklich ne formale Definition gibt: Für mich, und die meiste SW mit der ich bisher gearbeitet hat ist ThinXY und in diesem Fall eben Thinjail eine Basisjail, von der abgeleitet wird, Änderungen werden aber nicht in deses Basisjail commitet. Also zB mit zfs ein Snapshot und von diesem ein Clone. Zu Beginn ist das alles gleich und braucht keinen Platz, wenn sich die Jails dann ändern, wird eben für diese Änderung immer mehr Platz verwendet.

Basejail ist ein (ro) Mount eines Filesystems in mehreren Jails. Davon würde ich abraten, das macht nur Kopfschmerzen.
 
Ein Basejail als Ursprung aller Jails hatte ich auch mal, aber ich bin davon wieder weg. Wie Du schon schriebst, spart man am Anfang Platz. Ich wurde die alten Snapshots dann aber nicht wieder los ohne sie zu promoten. Und dann ist man wieder bei der Variante, bei der jedes Jail das komplette OS in seinem FS hat. Also warum nicht gleich dahin gehen und eine Ebene Komplexität abbauen? Ich habe nur noch ein Skeleton-Verzeichnis, dass ich über die frisch installierte Installation kopiere.
 
jmt schrieb:
Ein Basejail als Ursprung aller Jails hatte ich auch mal, aber ich bin davon wieder weg. Wie Du schon schriebst, spart man am Anfang Platz. Ich wurde die alten Snapshots dann aber nicht wieder los ohne sie zu promoten. Und dann ist man wieder bei der Variante, bei der jedes Jail das komplette OS in seinem FS hat. Also warum nicht gleich dahin gehen und eine Ebene Komplexität abbauen? Ich habe nur noch ein Skeleton-Verzeichnis, dass ich über die frisch installierte Installation kopiere.
Zum Vergrößern anklicken....

Du könntest halt zB deine ganzes Jail als Ansible Playbook vorliegen haben, und zB bei jedem Major Upgrade die Jails neu anlegen und das Playbook drüber jagen. Hat natürlich noch nen Layer Komplexität mehr ;) Kommt wohl stark auf den Anwendungsfall an. Wenn du als Firma zB sowieso zur Dokumentation alle Maschinen als Playbook hast, würde das nix extra hinzufügen.
 
Die Mühe habe ich mir bisher nicht gemacht. Aber die Idee hatte ich schon. Das ganze noch etwas extremer gedacht und Du bist bei Docker für BSD. :D
 
Ich habe es ähnlich medV2 gemacht. Ich hatte früher ezjail im Einsatz und bin vor Jahren zu iocage gewechselt. Funktionierte auch soweit.
Sehr nervige Probleme gab es bei manchen Jails mit dem Upgrade auf eine neue Version von FreeBSD. Ioage stolperte oft über das immutable Flags, gibts auch Beiträge von anderen Usern dazu. Nichts davon half. Dann wurde mir auch der Backupplatz für ein privates Hobby zu kostenintensiv und ich dachte mir, ich steige auf Ansible um, muss nur noch die DBs nach backblaze b2 sichern, den Rest macht Ansible und es ist alles schön dokumentiert. Zeit wollte ich auch sparen, weil viel alltäglicher Kram liegen blieb. Mit Ansible + SemaphoreUI ist das ein Klacks. Jails sind nun auch schnell gemacht.
Natürlich muss man sich da einarbeiten, aber inzwischen läuft es gut. Hat aber auch 2 Jahre gedauert.
Upgrades mache ich noch per Hand.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben