Jöhetne a Debianban az egybeolvasztott /usr

 ( gee | 2016. november 27., vasárnap - 11:17 )

A Debian arra készül, hogy átalakítsa az alapértelmezett fájlrendszer struktúráját, ami így a Fedorához és CentOS-hez fog hasonlítani. A váltásra készülődés már az év eleje óta folyik, és mostanában került be az unstable (sid) ágba az a változás, hogy a debootstrap már tud egybeolvasztott /usr-t használva is telepíteni. Ebben az esetben a /bin, /sbin, /lib szimbolikus linkek a /usr alatti hasonló nevű könyvtárakra.

A váltás egyik oka, hogy a Debian csomag karbantartókra jelentős terhet ró a jelenlegi rendszer. Egy másik ok, hogy jelenleg a /usr ugyan mountolható csak olvasható módon, de írható / esetén a /bin, /sbin és /lib alatti fájlokat, például valami malware, adott esetben írni tudja. Ha minden rendszerprogram a /usr alatt lesz csak olvashatóan mountolva, ez a biztonságot is növeli.

Ha valaki külön fájlrendszernek kívánja használni a / és /usr-t, csupán annyit kell tennie, hogy az initramfs-nek a root mellett a /usr-t is fel kell mountolnia.

További részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Idézet:
A váltás egyik oka, hogy a Debian csomag karbantartókra jelentős terhet ró a jelenlegi rendszer.

Ez nagyon érdekelt, elolvastam a cikkben linkelt levelet.
Arra, hogy pl. egy /bin-be települt, boot-kor induló alkalmazás egy olyan alkalmazást (libet) igényel, amely a (csak később csatolandó) /usr-ben van, miért az a megoldás, hogy mindent egybe rakunk? Nem vagyok rendszermérnök, de ez nem tervezési hiba (vagy egy jó terv rossz megvalósulása)?

Ha a /bin alatt csak szimbolikus linkek vannak, ahogy írják, akkor miért is lenne a /bin alatt egy bináris?

Idézet:
Ha a /bin alatt csak szimbolikus linkek vannak

Ezt hol írják? Lehet, hogy így van, nem használok Debian-t.

Konkrétan a levél ezen részére gondoltam:

Idézet:
There have been various
unexpected dependencies on /usr in at least some packages for at least
that long (such as sysvinit scripts that use binaries in /usr without
depending on $remote_fs).

Elbeszéltek egymás mellett.

uzsolt a jelenről beszél, Zizi meg a bejelentett jövőképről.

Az is meglehet :)

Ha jól értem, ezt MOST sem így van, éppen ezért a debiannál már nagyon korán behúzzák a /usr-t.

https://lists.debian.org/debian-devel/2016/01/msg00081.html

De. Csak ugye a többség...

... és akkor itt jön a kérdés, hogy a Devuan is átveszi-e, vagy éppenséggel forkoljuk a Devuan-t is, ha normális könyvtárazást akarunk :)

Mik a normalis konyvtarazas mellett szolo ervek?

- Simpler and cleaner overall file system layout, with full compatibility.
- Clear separation of operating system and host specific resources.
- Improve compatibility with other Unixes/linux, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work. All binaries will be available on both /usr and / thus minimizing compatibility problems.
- Improve compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place
- Minimize difference to other Unixes, such as Solaris, which already did the same move
- Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication

https://fedoraproject.org/wiki/Features/UsrMove

Remek, felsoroltad a nem-normalis melletti erveket...ha jol ertem mauzi allaspontjat.

Fiatalok kedvéért: régen az volt a koncepció, hogy mondjuk a /usr-en kívül van 10MB szoftver, azon belül meg 10GB; de ami /usr-ben van, az egy esetleges hiba utáni rendszer-helyreállításnál nem esszenciális, tehát adott esetben fel sem kell mountolni.

Pl az IBM-nek se sikerült elfogadnia ezt a koncepciót, az AIX-ban is csak szimlink-ként létezik a /bin, /sbin, /lib a /usr -beli megfelelőjükre.

Szerk: mondjuk régen sok furcsa dolog volt, például egy tipikus szerveren nem hogy Gnome3 / Kde5 nem volt, de még X-szerver sem. (Minek is lett volna, tipikusan képernyő és billentyűzet se volt.)

Egy tipikus szerveren most sincs. :)
--
"Sose a gép a hülye."

Idézet:
régen az volt a koncepció, hogy mondjuk a /usr-en kívül van 10MB szoftver, azon belül meg 10GB

FreeBSD-nél még most is ez a koncepció, persze kicsit más a rendszer felépítése is a Linux-hoz képest (gondolok arra, hogy pl. a cp, mount, stb. parancsok a csomagkezelő "hatáskörén" kívül vannak (azaz nem a coreutils és hasonló csomagok tartalmazzák), ők az alaprendszer részei, a freebsd-update paranccsal frissítheted).

Régen a / egy (nem túl nagy méretű) lemez volt, ahol működött a random elérés.
A /usr pedig mágnesszalag, ami alapvetően szekvenciális elérésű (persze lehetett előre-hátra tekergetni), jóval nagyobb méretű, de lassúbb, mint a lemez.

Fuszenecker Róbert

Nem értem, ez a biztonságot miért növeli..

rm /bin
mkdir /bin
cd /bin
ln -s /usr/bin/* .
mv mymalware /bin/bash
--
"Sose a gép a hülye."

Ki mondta, hogy ennek elsődleges célja a biztonság növelése? Ezt javaslom átolvasásra:

https://fedoraproject.org/wiki/Features/UsrMove

Idézet:
Ki mondta, hogy ennek elsődleges célja a biztonság növelése?

A forrásként megjelölt cikk így kezdődik:

Tidying up the artefacts of the 90s should make things more secure and efficient

Az okok felsorolásában az első helyre a Register a biztonságot írta. Szóval ők mondták :-)

Hm, ahol ezek a parancsok szépen sorban lefutottak (nem sysadmin által, vmi malware**/exploit**/stb**), annak a rendszernek kb már édesmind1... :)

Persze, de ahol ez nem fut le, ott ugyanúgy nem tudod a /bin-t írni akkor sem, ha külön van.
--
"Sose a gép a hülye."

Már megint a hurrikán a szarosbiliben...

A Solaris ezt rég meglépte, már a 10-esben a root device-on csak /sbin volt és speciális binárisok /etc alatt, ami mind csak ahhoz kellett, hogy nagyobb probléma eseten, single user módban lehessen kezdeni a rendszerrel valamit, javítani (még nagyobb gáznál meg úgyis resuce ISO-t bootol az ember). Egy normál bootfolyamat az /usr-t elég korán fölcsatolja, minden más program mehetett oda (no meg persze /opt alá és egyéb helyekre).

De ennek Solarison is csak a ZFS előtti időkben volt igazán értelme (és ez igaz FreeBSD-re is, illetve btrfs-re Linuxban), amíg a / és az /usr külön block device-on volt. A ZFS a root poolt dinamikusan osztja föl, / és /usr is egy poolon vannak, nem sok értelme van köztük különbséget tenni.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Idézet:
csak a ZFS előtti időkben volt igazán értelme

Mit szólsz egy olyan esethez, hogy egy egyszerű kliens, amelyen az alaprendszer van, és a /usr-t hálózati meghajtón van. Nem tudom, manapság még mennyire van ilyen, de ez is egy fő ok volt a kettéválasztáshoz (persze helyi hálózaton belül el tudok képzelni egy ilyet manapság is, hogy egy szerver, és sok vékonykliens csatlakozik hozzá - a szoftveres karbantartás, pl. programok frissítése lényegesen egyszerűbb; persze ha a szerver fertőződik valamivel, akkor az mindre kihat ;) ).
Persze egy szimpla egyszeri gépen annyira túl sok jelentősége valóban nincs (persze nálam külön partíción vannak - az okát ne kérdezd, lehet, hogy csak a geek-faktor vagy az e-penis növelése lehet a cél).

+1
Ezt el is felejtettem felemlíteni, pedig valóban, voltak régi időkben olyan varázsszavak is, hogy 'vékonykliens', 'NetPC', X-terminál...

Akkor szépen boot során felmountolja a /usr-t, a leírás alapján a debian legalábbis nagyon hamar mountolja a /usr-t. Ha nem sikerül? Hát, ígyjárás, tessék logokat olvasni... :(

Remélem a systemd valahol benne lesz a történetben, mondjuk egy /usr/lib/systemd/usrmontd komponenssel (pluszpont annak, aki észreveszi a rekurziót)

Először fel kell csatolni a /usr-t, hogy tudd használni a /usr-t felcsatoló szkriptet. Tisztára, mint egy XP-telepítésem: használni akartam a CD-t, de ahhoz, hogy használhassam, telepíteni kellett az alaplap meghajtóját - CD-ről... :)

Nem. Initrd.

És ahogy mondom, már MOST is KELL a /usr bemountolása debiannál, tehát ebben változás nem lesz.

>Nem. Initrd.

Linux felhasználók (c) 1990-2016

De ha már nem lesz külön szeparálva pl. a /bin és a /usr/bin, hanem csak egy szimlink lesz egyik a másikra (vagy másik az egyikre), nem fogod tudni megoldani.

Ezt úgy értettem, hogy ZFS-nél már nincs értelme, de még mindig meg lehet csinálni. Mondjuk most hirtelen meg nem mondom neked fejből, hogy az ilyen jellegű setup még támogatott-e hivatalosan Solaris 11 alatt. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Én Linuxot akarok használni. Marhára nem érdekel a Solaris nyűgje. És nem érdekel a Fedora/systemd új kreálmánya (tuti benne vannak, ha nem akkor bocsánat).

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

A Solarison ez nem nyűg, hanem 10+ éve működik, csak a ZFS eltérő felépítése miatt (nincs szükséged igazán partícionálásra) okafogyottá vált.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

A Solaris ezt rég meglépte, már a 10-esben

Konkrétan már a 2.5.1-ben is symlink volt a /bin :D

Épeszű ember eleve nem is csinált külön /usr-t, így az egész problémakör meg is volt oldva rögtön (OS: egy szál / fs, abban volt minden).

Hát ööö, izé, lehet, hogy azok az épeszűek akik Solarist használtak azok nem csináltak külön /usr -t (speciel a HP-UX is meglépte ugyanezt a/bin -> /usr/bin marhaságot), de attól még az önálló /usr egy kicsit könnyebb kézbentarthatóságot nyújtott. (Kézben, nem pedig karban.) Gondolok itt a szokásos non-exec root vs exec,ro /usr helyzetre mondjuk. Az nem érv, hogy a linuxos ld.so huncutsága miatt ezt mennyire könnyű vagy nem könnyű átlépni. És valóban, a ZFS, btrfs (vagy akár a Tru64-es AdvFS alatt) már fizikailag sem különültek el ennyire a "partíciók", ezzel együtt is szerver használatnál - nekem - szimpatikusabb az önálló /usr. Biztos azok a fránya megszokások.

Azt azért megkérdem, hogy vannak-e olyanok, akiknek nem RAM-diszken van a /tmp, és lelkesen helyeselnek-e a miatt, hogy akkor a /-ben levő (azaz nem önálló) /tmp -t kezdjünk el használni. Van pár szerver, ahol a használat miatt nem megoldás a memóriában levő tmpfs, de akkor a fenti gondolatmenet alapján az nem is baj, hogy a /tmp ott van a /-ben - rosszabb esetben nincs sehol, hanem csak /tmp -> /usr/tmp. (Sok sikert a single bootban való gatyába rázáshoz, mert ilyenkor - mármint symlinkes esetben - ugye nincs semmilyen temporary területed.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A följebb említett unixos security könyv már akkor azt írta, hogy a /tmp-t illik külön filerendszerre tenni, pont azért, hogy vmi elszabadult program ne tojja tele a root FS-t. Solarison meg ugye mindig a memóriában/swapen van by default, lehet is ezzel huncutkodni. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Extrém kicsi memóriájú gépen se csinál önálló valódi /tmp-t csak ramdiszket? Nem tartom jó default-nak.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem lényeges a memória, hiszen a tmpfs nem a RAM-ban lakik, hanem a virtuális memóriában. Ha betelik a RAM, majd kirakja a swapre. Ez tulajdonképpen ideális is, mert az amúgy üresen álló swapet lehet erre használni, nem kell külön diszket adni neki. Plusz nem kell bootnál takarítani a régi szemetet.

A P1-esem 16Mb RAM-mal szerinted hova "tempeljen"? ;-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Hol releváns az, hogy mennyi a RAM, ha arról beszélünk, hogy a swap-et használja ha kifut a RAM-ból?
Azt kéne megnézni, mekkora a swap.

64 Mb-os CF kártyán szerinted?

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Oszt azon hol akarnál bármit tárolni a /tmp-ben?!?!?!?!?

A nonexec rootnak kb. semmi értelmét nem látom (a root user szopatásán felül)... a full ro /usr meg mire jó? Aki tudna bele írni, az tud nyomni rá egy remountot is. Ennél sokkal értelmesebb megoldás ugyanerre a feladatra a chroot + ro + grsec, na ott a chrootolt processz uid=0 esetén sem tud remountot nyomni.

Van pár szerver, ahol a használat miatt nem megoldás a memóriában levő tmpfs

Nehéz elképzelni, hogy miféle használat is lehet ez...
De ha valakinek dedikált diszkterület kell alája mindenképp, akkor ne sajnáljon neki külön fs-t gyártani erre a célra.

A grsec biztosan sokkal jobb megoldás, csak kb egyetlen elterjedt disztróban sincs gyárilag grsec, míg mount igen. Ha jól tudom, még mindig ott tartunk, hogy SELinux van vagy AppArmnor. Ha valakinek már van joga remountot mondani, akkor kb tök mindegy. A grsec - véleményem szerint - azért jó, mert ehhez az extra joghoz nehezebb grsecet használó rendszer esetén hozzájutni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nekem kellett már azért újratelepítenem SCO Unixot, mert az egyik kolléga ügyetlenül adott ki valami parancsot rootként.
Az otthoni Debianomon is ro a /usr, és főleg azért, hogy véletlenek ne írják felül. Ha frissíteni akarok, majd remountolom rw. Utána ro újra.
Mellesleg áramszünet vagy ilyesmi után se dirty vagy sérült a fájlrendszer.

Erre nem emlékeztem, pedig 2.5.1-nél terelgettem először Solarist. :)

A leválasztott /usr-nek azért van értelme, pl. security szempontból. Emlékszem, hogy egy 1996-97-es Practical Unix Security még megemlítette, hogy az /usr-t rakhatod külön SCSI drive-ra, amit hardveresen írásvédetté tehetsz (külső drive-on kapcsoló) és onnét kezdve a gépre bejutú malicsusz ember/kód nem tudja azokat a binárisokat módosítani. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Erre a hardveres ro-ra én is emlékszem ugyanebből a könyvből.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

...hát én szoktam bizonyos oknál fogva...
--
Rózsár Gábor (muszashi)

Amikor én tanultam, akkor még az volt a mondás, hogy egy szervezeten belül a /usr lehet NFS-en megosztva valami fájl szerveren, így a munkaállomásokon nem kell ugyanazt tárolni sokszor.

Lokális fájlrendszernek ebben semmi szerepe nem volt.