aufs

Fórumok

Sziasztok.

Azt szeretném elérni, hogy bizonyos program, ami sok könyvtárba telepedik (etc, lib, share, bin stb.), egyetlen tömörített állományban legyen (squashfs), majd valahogy be tudjam mountolni úgy, hogy utána azt érezhessem, mintha telepítettem volna.
Mivel lehet ezt elérni? aufs-sel? Semmit sem tudok erről...

Hozzászólások

Már nem emlékszem, de mintha a unionfs-nek nem lett volna támogatása, mindenesetre valami bajom volt vele. Az overlayfs viszont létező dolog, használja például az OpenWrt/LEDE is. Az image egy tömörített squashfs, erre van húzva egy overlayfs, ami változik, az pedig megy írható-olvasható memóriába.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem (okosabbak javítsanak ki) meg lehet úgy csinálni, hogy egy mountpointra behúzod az eredeti fájlrendszer gyökerét READ ONLY és arra rá egy unionFS réteget. Aztán az egészet chroot-olod a mountpointba.

Így van egy read only eredeti rendszer+írható unionFS réteg, amiben lehet garázdálkodni. Ha megvolt a telepítés, akkor squashfs-be mehet az írható réteg tartalma, és végül "középső" rétegként lehet használni.

Elég perverz, de talán működik :-)

Nem pont erre valok a kontenerek? Docker pl. Bar nem egeszen ertem miert/mire kell ez neked.

mire kellene? Azt nem merem leírni, mert tudásom nem engedi még, hogy megszólaljak, hiszen hüje ember csak hüjeségeket beszél. De nem dinamitrudak magamra szereléséhez, ezt már ki merem mondani.
Szóval jelen helyzetben még a Dunning–Kruger-szindróma elején állok, amikor már tisztán tudom, hogy hüje vagyok.

Már le merem írni.
Adott egy egészen speciális cuccokkal ellátott distrib, melyekben van pár hiba és hiányosság. Arra gondoltam, hogy mivel 1-2 dologban már segítettem, gyorsíthatok pár folyamaton azzal, hogy segítek fejleszteni. Csakhogy a liverendszerek beleihez még nem volt szerencsém csak nagyon régen valami ubuntun, így most itt tanulok.
https://marinux.tuxfamily.org/

mksquashfs-el megcsinalod az imaget, majd azt loop mountolod valahova. aufs mounttal meg tudsz egy ro es rw konyvtarat "osszefesulni" egy harmadikra.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ahogy az initrdben csinaljak az ilyen mutyur cuccok. ott mountoljak az ro-t, rw-t, aufs/overlayt valahova, majd chroot. konkret parancsokat nem tudok, de fel kell turni a netet. openwrt is igy csinalja, az (ubuntu) live cdk is.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szórakozom egy ideje, egyszerűen annyira idegen az egész, hogy nem értem, mi történik és mikor.

Már volt, hogy sikerült összemosnom két könyvtárat, melynek egyikében volt egy alkönyvtár, melyre rámountoltam egy squashfs-tömörítményt.
Aztán ahogy átírtam a neveket hogy egyszerűsítsem és felfogjam, elfelejtettem, miből indultam ki, elvesztettem a fonalat. Így nem lehet...

# cat test.sh
mkdir -p ./base/jre

mkdir ./upper/jre
mount -t squashfs ./other/jre.sfs ./upper/jre

mkdir upper
mkdir lower
mkdir merged

mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged
## mount -t overlayfs -o lowerdir=./lower,upperdir=./upper none ./overlay

exit 0

## és azt sem tudom, mi történik..

work könyvtárat nem hoztam létre...
De így már a merged-be beíródik minden. Viszont mi a work dir értelme, minek van?
Nem értem a scriptet, de már működik. Létrehozza, amit akartam, de hogyan? Ha nem értem, engem megevett a fene.

Ha a merged könyvtárból törlök valamit, törlődik, mínusz előjellel bekerül az upperkönyvtárba. Az eredeti könyvtárból, amiből a mergedbe került, nem tűnt el. Príma. De mi az a negatív előjel? Csupán valami cucc ennek az összemosott fájlrendszenek, nem is kéne vele törődnöm?

Work dir: "The workdir option is required, and used to prepare files before they are switched to the overlay destination in an atomic action (the workdir needs to be on the same filesystem as the upperdir)."

minusz előjel: ezzel jelöli, hogy az alsóbb rétegben még meglévő fájl törlődött. Ha belegondolsz ezt az információt is tárolni kell, különben nem lehetne törölni az unionfsből.

A workdirt a rendszer belsőleg használja a félkész tranzakciók tárolásásra. Ugyanazon fájlrendszerben kell lennie, mint az overlaynek, ezért a végső move művelet már tranzakcionális. (Sajnos nincs a fájlkezeléshez tranzakció API Linux alatt még, ezért van szükség rá tudtommal.) Tehát veheted úgy, hogy valami technikai izé, ami userként nem érdekes, csak plusz paraméter a konfigurációban.

Rootra úgy tudod tenni, hogy egy másik folderben indítod, és végül chroot-tal belelépsz. Szerintem direktben a root-ra tenni nem lehet overlayt, de tévedhetek.

Most így fest a script, melyet nagyjából felfogtam:



mkdir base
mkdir user-datas
mkdir lower
mkdir merged

 mount -t overlay overlay -o lowerdir=./lower,upperdir=./user-datas,workdir=./base ./merged
#mount -t overlay overlay -o lowerdir=./lower,upperdir=./user-datas,workdir=./base ./merged

# other
 mkdir ./user-datas/opt
 mkdir ./user-datas/opt/jre
 mount -t squashfs ./extras/jre.sfs ./merged/opt/jre
# #

Itt a squashfs-t a merged könnytárba csatolom, szóval inkább a workdirbe (./base) kéne?

Ha a ./merged könyvtár helyett a / gyökeret adom meg, az alapoprendszerre értelmezi az összefűzést, azaz rálapolja a réteget a gyökeremre? Tulajdonképpen ilyesmit akarok.

Szóval ez a gyökérre mergel?
mount -t overlay overlay -o lowerdir=./lower,upperdir=./user-datas,workdir=./base /

------
Kipóbáltam, de csak látszatra csinálta meg:


Filesystem      Size  Used Avail Use% Mounted on
overlay          17G   16G   29M 100% /

# lsmod | grep overlay
overlay                26637  1

közben semmi nyomát nem látom, hogy új könyvtárak jöttek volna létre a /-en.

A gyökerem valójában a /mnt/sda9, ha ide rámountolom, az nem ugyanaz, mint a /

mount -t overlay overlay -o lowerdir=./lower:/,upperdir=./user-datas,workdir=./base ./merged

majd

chroot ./merged

így megkaptam amit akartam, félelmetes.

az egyik lower könyvtár a gyökér, így a mergedbe is bekerül, majd chroot után ott vagyok ahol vagyok, kibővített rencerrel.

Csak hát ronda.

Lehet, tudni kellene, mit akarsz. Ha csak egy alkönyvtárra szeretnél overlayfs-t, az viszonylag egyszerű. Ha a rootfs-re, az már nem biztos, hogy triviális, de lehet puskázni a nagyoktól, mit csinál például az OpenWrt/LEDE. Igaz, szerintem ott az egész a boot folyamatba van talán integrálva, nem feltétlenül a már teljesen elindult rendszerrel variálnak, de nem néztem utána alaposabban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most már meg merem mondani. Egy live rendszert szeretnék oly módon, hogy egy már meglévőre rárétegezném a tömörített dolgaimat modulárisan, mintha egy slax lenne. Ha nem kell, umount.

Persze könnyen előfordulhat, hogy az átlapolásoknál főleg az .so fájlok okoznának gondot, nagyjából ismerem már azon programokat, amelyeknél ezt alkalmaznám. Sok gigás adatkönyvtáraknál meg nincs .so meg lib-kavarodás

Nem sokkal egyszerűbb saját live image-et csinálni?

Amúgy a live-okkal éppen az a baj, hogy lényegében egy RAM-diskre tett overlayfs, s így minden módosítás falja a memóriát. Amikor megtelik a RAM-disk, szétesik a filerendszer, s vagy pánikol a kernel, vagy csak simán összedől az egész. Ez az oka, hogy live-okat nagyon nagy uptime-mal nem nagyon lehet üzemeltetni. Vagy elképesztő módon, szigorral oda kell figyelni arra, hogy ne írjon senki a rootfs-re, csak mondjuk a RAM-ba allokált /tmp-be írhat.

Átmeneti, néhány órás használatra jó a live, de nem mindenható.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE