Rat zur Struktur einer Basejail

satriani

satriani

SysLion
Hallo liebe Leute,

ich baue mir ein kleines Tool um die Jails zu managen, nach dem Vorbild von ezjail, allerdings mit eigenen Macken :)
Genauer gesagt wird eigentlich nur die Verzeichnisstruktur des ezjails übernommen. Die Umsetzung erfolgt mit Binärpaketen.
Soweit ich mich erinnern kann sehen die von basejail verlinkten Verzeichnisse wie folgt aus:
Code: 
/
|-bin
|-boot
|-lib
|-libexec
|-rescue
|-sbin
|-sys
|-usr
   |-bin
   |-include
   |-lib
   |-lib32
   |-libdata
   |-libexec
   |-ports
   |-sbin
   |-share
   |-src
Meine Frage ist ob es soweit gut aussieht? Das ziel ist die Jails möglichst schlank, leichtgewichtig, einfache und schnelle Jail-Administration.
Kritik, Empfehlungen sind willkommen, inkl. Erläuterung versteht sich ;)

Gruß.
 
Zuletzt bearbeitet:
Meine wirklich ernstgemeinte Antwort ist: Lass es mit Symlinks, Unionmounts und was es sonst noch so an Tricks gibt. Das mag früher mal sinnvoll gewesen sein - wobei ich auch da schon nicht so recht überzeugt davon war - heute ist es das aber definitiv nicht mehr. Das hat mehrere Gründe...

- Die Speicherplatzersparnis zählt nicht mehr. Ein leeres Jail benötigt ca. 200 Megabyte Speicherplatz. Auf jede billige SSD und Festplatte sowieso bekommst du mehr Jails, als deine Kiste mit ihren CPUs und RAM bedienen kann. Zudem nehmen normalerweise die Nutzdaten weitaus mehr Platz als das System ein.

- Verlinken und Unionmounts machen nur Ärger, denn sie machen das ganze Konstrukt schwer verständlich, Fehler zu finden wird komplizierter und jedes Problem im Basisjail schlägt gleich auf alle tatsächlichen Jails durch. Ausfallsicherheit ist was anderes... Man mag argumentieren, dass das Updaten einfach und schnell ist, da man ja nur das Basisjail aktualisieren muss. Aber inzwischen haben wir freebsd-update und pkg. Schnell einen eigenen Updateserver für freebsd-update und ein Paketrepo für pkg gebaut und mit weniger als einer handvoll Kommandos aktualisiert man jedes Jail in Sekunden. Wenn man wirklich viele Jails hat, kann der Prozess durch ein triviales Script automatisiert werden.

- Aus einem Basisjail kann man schnell neue Jails deployen. Aber eine Template, die per tar(1) entpackt wird, ist kaum langsamer. Und spätestens wenn man das Problem mit ZFS totschlägt (zfs clone, anschließend ein kleines Script zum anpassen der Details), ist ein neues jail in Sekundenbruchteilen(!) gebaut.

Daher wäre mein Tipp, dass du dir das Gedödel mit Symlinks sparst und lieber die Energie in eine etwas "moderne" Herangehensweise steckst. :)
 
Danke Yamagi,

ich bin eig. ganz deiner Meinung, doch eine Frage steht bei mir noch offen: Welche der Verzeichnisse aus dem root Baum bleiben _immer_ absolut unberührt? Sodass man die bedenklos zwischen den Jails teilen kann. Im wirtschaftlichem Sinne ist das natürlich verschwenderisch, wenn man bedenkt, dass eins und dasselbe, sagen wir 500 mal im System vorkommt. Wenn man die Backups noch dazu zählt, dann kommt schon ein ordentlicher Speicherbedarf zusammen. Und du weisst doch "Ohne einen Cent gibt es keine Million" :D
Jetzt im Ernst, wenn man die Sicherheit mit gewissem Paranoidengrad betrachtet, sollte man sich von solchem Vorhaben fern halten. Sozusagen ezjail ist für produktive Zwecke verantwortungslos :belehren:
Dennoch hätte ich gerne eine Antwort auf meine Frage :p
 
Ganz einfach. Im laufenden Betrieb ohne Portinstallationen werden verändert:
- /etc
- /tmp
- /usr/home
- /usr/local/etc
- /var

Wenn man Ports installieren möchte, kommen hinzu:
- /usr/ports
- /usr/local

Wenn man die Welt bauen (nicht installieren) möchte:
- /usr/obj
- /usr/src

Außerdem gibt es ein paar Sonderlocken. net-im/prosody will z.B. im Betrieb /usr/local/var schreiben. Perl installiert Symlinks nach /usr/bin. Und so weiter.
 
Danke Yamagi,

wird schon einiges klar :)
Wie man sieht, sind eig. nur usr, etc, tmp, und var davon betroffen. Alles andere bleibt immer unberührt.
Wenn ich mich nicht verrechnet habe, dann sind es ca. 279 MB pro jail die man mit basejail ersparen kann, auf Kosten der Sicherheit versteht sich :D

h^2 schrieb:
Man kann ezjail doch auch binärverwalten...
Zum Vergrößern anklicken....
Ja ich weiss, es gibt aber andere Dinge die ezjail, meines Wissens nicht bietet zB. erstellung der jails mit zfs clone usw. :)
 
Zuletzt bearbeitet:
Danke, werde ich mir mal anschauen. ezjail ist schon ein mächtiges Werkzeug, doch wie Yamagi schon erwähnte, ist das gesamte Konzept fragwürdig. Ich werde mich damit, aus reiner Neugier jedoch mal auseinandersetzen. Aber für produktive Zwecke, wird das doch so verlockendes Prinzip keinen Gebrauch finden, zumindest auf meinen Maschinen :)
Passiert mit der basejail was schlimmes, dann sind alle jails sozusagen im Ar...h und das ist mMn eine Verantwortungslosigkeit.
 
Das kann sein.
Interessant finde ich die offizielle Dokumentation zur Erstellung der jail.
@Yamagi, du kennst es bestimmt. Vor allem das
Diese Konfiguration basiert darauf, Jails so weit als möglich gemeinsam zu verwalten. Dies passiert auf sichere Art und Weise durch den Einsatz von mount_nullfs(8)-Mounts (read-only). Dadurch werden Aktualisierungen erleichtert und das Verteilen von verschiedenen Diensten auf verschiedene Jails wird attraktiver. Außerdem bietet dieses Verfahren einen einfachen Weg, Jails hinzuzufügen, zu entfernen und zu aktualisieren.
Zum Vergrößern anklicken....
hört sich vielversprechend an :D

Wuzu eig. noch Welt bauen wenn man Binärpakete ziehen kann? :confused:
 
satriani schrieb:
Wuzu eig. noch Welt bauen wenn man Binärpakete ziehen kann? :confused:
Zum Vergrößern anklicken....
Das ist ein Fetisch, der bei FreeBSD heutzutage nicht mehr ganz so doll vertreten ist, wie z.B. bei Gentoo Usern. Ich glaube, das hat damit zu tun, dass Leute es erregend finden, wenn durch die extra-verbrannten CPU-Cycles und den zusätzlichen Strom wahlweise Kinder in Afrika oder Wale sterben.
 
Ich hoffe ja, dass es endlich mit dem offiziellen pkg-Repo mal weitergeht. *doppelseufz*
 
Sorry, muss eien Dinosaurier ausgraben :ugly:
Ich experimentiere etwas an einem ezjail-Ersatz, ich kann es einfach nicht lassen :p

Und bekomme die gleiche Fehlermeldung wie der Threadersteller
# /usr/local/etc/rc.d/mysql-server start
/usr/local/etc/rc.d/mysql-server: WARNING: failed precmd routine for mysql
Zum Vergrößern anklicken....

das liegt daran, dass Perl, wie Yamagi schon erwähnte, seine Symlinks nach /usr/bin installiert.
Aber /base wohin /usr/bin verlinkt wird, ist doch read only, also nix mit MySQL.
Bei ezjail funktionier es, soweit ich weis ohne Probleme, ich gehe mal davon aus, dass ezjail's /basejail nicht read only in einer jail gemountet ist :rolleyes: Korrigiert mich wenn ich falsch liege.
Jedenfalls suche ich nach einer intelligenten Lösung, sowie ähnlichen Fallen.
Das gesamte Konstrukt sieht bei mir wie folgt aus:
Code: 
Jail
 ┣ base
 ┣ bin -> base/bin
 ┣ boot -> base/boot
 ┣ dev
 ┣ etc
 ┣ lib -> base/lib
 ┣ libexec -> base/libexec
 ┣ local
 ┣ rescue -> base/rescue
 ┣ root
 ┣ sbin -> base/sbin
 ┣ tmp
 ┣ usr
 ┃  ┣ bin -> ../base/usr/bin
 ┃  ┣ include -> ../base/usr/include
 ┃  ┣ lib -> ../base/usr/lib
 ┃  ┣ lib32 -> ../base/usr/lib32
 ┃  ┣ libdata -> ../base/usr/libdata
 ┃  ┣ libexec -> ../base/usr/libexec
 ┃  ┣ local
 ┃  ┣ ports
 ┃  ┣ sbin -> ../base/usr/sbin
 ┃  ┗ share -> ../base/usr/share
 ┗ var
Würde mich freuen wenn ihr euch anschließt ;)
 
Das gleiche hier hatte ich im Sinn, dabei bleibe ich wohl. Mir persönlich fällt keine intelligentere Lösung ein.
Bleibt nur noch die Frage offen welche Ports neben Perl benötigen zugriff auf Systemordner?
Ich hoffe ich führe hier keine Selbstgespräche :D
 
Perl ist der mit Abstand wichtigste Port. Es mag noch einige andere geben, aber so spontan fällt mir keiner ein.
 
Danke Yamagi,
Perl ist unverzichtbar, doch für einen oder anderen mag ein anderes Port nicht weniger wichtig zu sein.
Aber, wenn dir spontan nichts einfällt, dann ist Perl höchstwahrscheinlich ein Einzelfall ;)
Ich bleib vorerst beim
Code: 
/usr/bin/perl -> /usr/local/bin/perl
vielleicht mache ich mich auf die Suche im Netz. Falls jemandem noch was einfällt, immer her damit :)
Danke im Voraus.
 
Zuletzt bearbeitet:
Selbiges macht auch ezjail. Aus der Example-Config:
Code: 
# base jail will provide a soft link from /usr/bin/perl to /usr/local/bin/perl                                                            
# to accomodate all scripts using '#!/usr/bin/perl'...                                                                                    
# ezjail_uglyperlhack="YES"
 
Bin grade dabei, einen neuen Server aufzusetzen und in Betrieb zu nehmen. Auf der Maschine, die ich ablösen möchte, habe ich eine Konfiguration wie im FreeBSD-Handbuch beschrieben; d. h. mehr oder weniger alles aus den Sourcen gebaut. Ich komme derzeit auf ca. 30 Jails, und ob des hohen Maintenance-Aufwands muss ich euch zustimmen: eigentlich ist das nicht mehr zeitgemäß, und mir wär's lieber, Jails zu bauen, die ich mit freebsd-update und pkg warten kann.

Vom Grundsatz stelle ich mir das so vor: Jedes Jail bekommt (mindestens) ein ZFS Dataset (eventuell für die Nutzdaten wie z. B. die Maildirs, die SCM-Repos oder was halt sonst so da drin gehostet wird). Die "Installation" erfolgt einfach durch Entpacken von base.txz (oder durch zfs clone && zfs promote) + Konfigurationsanpassung.

Dazu kommt dann ein Jail, in dem poudriere installiert wird (ich mag das nicht im Basis-System haben); wobei Poudriere selbst ja wieder verschiedene Sub-Jails anlegen würde (brauche z. B. verschieden gebaute Apache-Versionen, je nach Einsatzzweck...). Da drängt sich natürlich die Frage auf, ob man für die "Kunden"-Jails ohne weiteres eine "gemeshte" Paketquelle zusammenstellen kann - das wäre jedenfalls eine enorme Arbeitserleichterung (z. B. vim, most, perl & Co. aus dem "Standard"-Pourdriere-Jail, und Apache (je nach benötigter Ausführung mit Proxy oder LDAP-Fähigkeit) aus einem "Spezial"-Poudriere-Jail.

A propos Poudriere: Wie geht das eigentlich mit ZFS um? Die Konfiguration suggeriert jedenfalls, dass poudriere ZFS nutzt (BASEFS und ZPOOL Optionen) - leider ist nicht dokumentiert, was poudriere damit anstellt...

Wie würdet Ihr so ein Setup angehen?
 
Sorry, dass ich diese Leiche noch mal ausgraben muss, aber mich beschäftigt gerade das hier:
Yamagi schrieb:
Man mag argumentieren, dass das Updaten einfach und schnell ist, da man ja nur das Basisjail aktualisieren muss. Aber inzwischen haben wir freebsd-update und pkg.
Zum Vergrößern anklicken....
Wie konkret gehst Du denn vor, um mit freebsd-update ein Jail zu aktualisieren? Vom Host-System (mit -b /pfad/zum/jail) funktioniert es bei mir jedenfalls nicht, da freebsd-update dann von der Version des Host-Systems ausgeht (habe ein Jail mit 9.1 auf einem Host mit 9.2, das ich gerne ebenfalls auf 9.2 heben möchte).
 
Mit freebsd-update lässt sich (mit der von dir erwähnten -b switch) sehr schön ein neues Patchlevel einspielen. Ein Update auf eine neue Release war mir damit auch nicht möglich. Hier half bei mir nur neu bauen oder auf ezjail umsteigen.
 
Es geht einigermaßen gut, wenn man die uname-Ausgabe fakt. Das geht mit Umgebungsvariablen, die in der Manpage beschrieben sind. Aber es ist recht frickelig, ja. In FreeBSD 10.0 soll freebsd-update angeblich deutlich besser mit Jails klarkommen, ausprobiert habe ich es aber noch nicht.
 
Das halte ich dann auf einem Produktivsystem doch für recht risikoreich - die genaue Version eines Jails lässt sich ja so ohne weiteres nicht erkennen; da bleibe ich dann (vorerst) lieber bei der bewährten Methode - die ist schließlich nicht so empfindlich, was zuvor installierte Versionen angeht...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben