( airween | 2009. 10. 04., v – 21:46 )

Hello,

szvsz összekevertél valamit: a megadott doksiban nagyon jó a példa, ott pont a gazdarendszerBE mutat a chroot, tehát a gazdarendszerben futó shell-ben készítesz egy linket a chroot filerendszeréből a gazdarendszer egyéb helyére. Ez azért jó, mert ha pl megadod a jailernek, hogy másolja be a /etc/apache2 könyvtárat, majd azt utána "visszalinkeled", akkor az csak tényleg az upgrade-del járó módosítást vinné át, de azt nem fogja, mert egyezik a dátumuk. Ha nem csinálnál symlinket, akkor is működne a chroot, csak figyelni kellene upgrade-kor, hogy egy esetleges apache upgradekor megjelenő konfig módosulás ne írja felül a chroot-on belüli beállításodat.

ha jól veszem ki szavad, akkor a gazda rendszer frissítésekor a jailer-hez kapcsolódó fájlok is automatikusan az új fájlok lesznek
A jailer fájlokat másol, amit leírhatsz egyesével, vagy csomagként, tehát beleírsz egy csomagnevet, pl: libapache2-mod-php5, ekkor a csomag összes fájlját bemásolja. Viszont van, mikor a csomag telepítése után kell még néhány dolgot futtatni, ez a jailer nem csinálja meg, nekem nemrég ilyen volt egy chroot-on belüli Python modul. Ez esetben kézzel chroot, és ott a megfelelő parancsok kiadása megoldotta a problémát.

Még annyi megjegyzés a fenti doksihoz (amit nem olvastam végig), hogy én soha nem csinálok debootstrap-al alap rendszert apache-nak, elég a jailer által bemásolt (itt a jailer.conf etch-hez: http://pastebin.com/m69c83d2d). Ill van olyan, hogy pl PHP-ból exec-el hívott processznek kell a /proc, azt nem árt mountolni, de nem kötelező. Aztán javasolt az egész chroot-ol rendszernek külön partíciót adni, ro-val mountolva, az azon belüli /home (vagy ahol vannak a vhost docroot-ok) szintén külön partíció noexec,nodev,...-el, a /tmp detto... csak hogy legyen értelme is annak a chroot-nak :)

a.