Linuxon a /tmp mappa az tényleg a RAM-ban van?

A kernel önmagától nem is fogja tmpfs-re rakni a /tmp-t, sőt a kernel szempontjából még az is mindegy, hogy van-e tmp vagy nincs.

Viszont ha Systemd-del telepíted a Gentoot, akkor az automatikusan tmpfs-be csatolja a /tmp-t, ezt írják is itt: [link]

Én magam ahány Gentoo telepítést láttam, ott mind RAM-ban volt a /tmp. Hogy nálad mi hogyan van telepítve és konfigurálva, az megint egy másik kérdés.

Itt egy két napos Fedora telepítés csatolási pontjai:

[link]

Itt egy Debian (ez évekkel ezelőtt lett telepítve, azóta csak frissítve volt):

[link]

Egy friss OpenSuse:

[link]

És egy szintén friss Manjaro:

[link]

Ja hát aki gentoot systemDvel használ, úgy kell neki! :)

Nekem is tmpfs-en van a /tmp, de csak azért, mert én akarom, hogy ott legyen. Gentoonál meg az az alap, hogy nem csak lehet, de kell is akaratérvényesítő tevékenység.

Természetesen! Ilyen systemD-s nehezen kontrollálható meg egyre több mindenbe belenyulkáló borzadálynak semmi keresni valója gentooban. Nem csak a KISS elvét, de magát a gentoot is szemközt köpi. A gentooban az a jó, hogy lehetőséget ad szembe menni mindennel. Sokáig pulseaudio helyett is alsát használtam, de azt el kellett engednem, beismerem eljárt afelett az idő. Meg aki bluetooth audiózik meg ilyen luxus, a mai kornak megfelelő igényei vannak, mint spotify és szeretné, hogy párhuzamosan más eszköz is hozzáférhesen egy időben a hangkártyához, annak nincs sok választása.

Amúgy régen Arch Linux is OpenRCt használt, ha emlékezetem nem csal. Ott találkoztam vele először és nagyon megtetszett. Aztán Arch is felzárkózott a a piroskalapos linux mérnökurai által diktált trendnek. Hozzáteszem nem csak systemD téren, sok más is van. Nem is értem miért van annyi Archos arc, ahelyett, hogy inkább Slackwaret használnának. Ha meg a rolling meg a frissesség a fő szempont, akkor ott a fedora. De nem téríteni akarok, meg betámadni az Archosokat, csak egyszerűen nem értem mit ad az a disztribúció, amit egyetlen másik sem tud megadni. Persze azt sem tartom kizártnak, hogy sokan nem tudják lenne olyan alternatíva, ami jobban megfelel az igényeiknek, csak nem ismerik.

Ettől függetlenül messze vagyok a hardcore gentoosoktól, mert azok rém egyszerű ablakkezelőt tolnak. Ez alatt azért nem az afterstepet meg fluxboxot értem. Nagyon elkanyarodtunk az eredeti témától, a kérdező meg jól felszívódott. Azért válaszolhatna milyen disztrót használ, hogy megírjuk kell-e fstabot taknyolnia és mit írjon bele. De látom nem érdekli.

Azért a Systemd-nek vannak előnyei szerintem. Pl. a journald-dal sokkal egyszerűbb logokat kezelni, mint a hagyományos módszerekkel. Illetve hogy egységesen megy a service-k telepítése, indítása, leállítása, ... ha leáll egy szolgáltatás, képes szt monitorozni és igény esetén újra tudja indítani, külső eseményekre (pl. egy hálózati meghajtó elérhetősége) is tud reagálni és el tud indítani egy adott processt (mondjuk egy backupot), illetve nincs olyan probléma, hogy valamely hálózati szolgáltatás azelőtt indulna el, mielőtt felállt volna a hálózat, mert meg lehet adni a szolgáltatásnak függőségként a hálózatit kapcsolatot meglétét, stb.

Az Archnak szerintem kettő kézzel fogható előnye van, egyik a frissesség, a másik a nagyon gyors csomagkezelés. A Fedora azért lassabban frissül (nem is rolling).

Én a piroskalaposok termékeit azért szeretem, mert ott azért rendesen össze vannak rakva a dolgok. Példának okáért, a Debian átvette a Systemd-et, de közben olyan dolgok, mint a hálózatkezelés, maradtak mind a régiek. A legfrisebb Debian Handbookban is a régi, net-toolsos hálózatkezelés van (ifconfig, /etc/networks/interfaces, stb.).

Red Haton viszont _alapból_ a NetworkManager intéz mindent, és meg lehet nézni, hogy az nmcli mennyivel többet tud, mint akár a net-tools, akár az ip csomag.

1. SystemD:

Persze, hogy vannak előnyei a systemD-nek, de sajnos hátrányai is.

Eleve egyik célja az egyszerűsítés, de tudok példát az ellenkezőjére is. És most nem a hagyományos sysV-vel akarom összehasonlítani, hanem az openRC-vel. Azt nem tudom menyire ismered, de kicsit profibb a hagyományos sysV-nél. Egy konkrét példa. Munkahelyemen az eset végpontvédelmet hasznáunk. Ennek van egy managelő környezete, amit készen virtualizált lemezképként adnak. Egy Centos 7be gyógyított managelő alkalmazás. Link: [link]

Ezt virtualboxban is lehet futtatni. Mivel az nem kerül külön pénzbe, ezért azt használom. Természetesen a gazda szerver os is linux, ezért fel kellett okosítanom a munkahelyi szervert, hogy automatizáltan indítsa, reboot vagy shutdown esetén hibernálja. Ez systemDvel négy darab fájl megírását jelentette, amiből kettő valami 50 soros borzalom , meg két másik valamivel kevesebb. Ugyanez openRC-vel összesen két fájl és egy-egy sor utasítás. Na ebben az esetben nagyon nem könnyíti meg a systemD a dolgomat.

2. Gentoo:

Gentoot nem azért használnak, hogy egyszerűbb legyen a linux, arra ott az Ubuntu és társai. Gentoot elvi meg ideológiai okokból használ az ember.

3. Arch vs. Fedora:

Azon vitáznék, hogy melyik disztró csomagja frisebb. Azért be szokta előzni archot. Persze Archnak is vannak teszting csomagokat kínáló repói, de az nem ér.

Fedora fél rolling. De félévente kijön belőle egy új kiadás és faék egyszerű a verzió frissítés.

4. Debian egy örömlány lett lett. De jó alternativa lehet a Devuan.

5. Red Hat és a hálózatkezelés:

"Red Haton viszont _alapból_ a NetworkManager intéz mindent"

Nana! Nem mindegy, hogy minimal istallt csinálsz mondjuk szerver célra, vagy egy full grafikus pl gnoem-mal felhúzott desktop os-t.

Mert akkor ifconfig van. Jó az igaz, hogy kilences centost meg oraclet még nem telepítettem, de feltételezem azon is így van. Szerveren luxus a networkmanager. Azt nem is beszélve, hogy minden rebootnál belenyúl a resolv.confba, ami rohatdul nem jó, ha egy sambás Active Directory Domain Controllert használsz.

OpenRC-t nem ismerem, az viszont igaz, hogy a Systemd megköveteli, hogy minden a helyén legyen és minden pedáns legyen. De szerintem ez nem gond, még ha kis többletmunkával jár is, de nem ad teret a gányolásnak.

Azért ha visszanézed, mik mentek a SysVinit-es időkben... nem volt ritka, hogy úgy kezdődött egy service start scriptje, hogy "sleep 30", mert másképp nem tudta bevárni a hálózatot.

Red Hat alapú disztróknál nincs ifconfig, akkor sem, ha szerver telepítést csinálsz. nmcli és nmtui van. De mondom, nmcli-vel szinte mindent be lehet állítani, route-olást, DHCP-t, VLAN-t, bridge-et, NIC-et, bonding-ot, libreswannal vagy strongswannal VPN-t, tunnelinget, port mirroringot ha épp az kell...

Az /etc/resolv.conf-tól elméletileg nem függhet semmi, az csak a hálózatkezelő alkalmazás használja (jó esetben legalábbis). Ha egy másik program ettől függ, akkor ott azzal a programmal van baj, mert nem a glibc által biztosított, szabványos függvényeket (mint a getaddrinfo()) használja névfeloldásra, hanem olyan helyen mókol, amihez neki nincs köze.

De egyébként ha a /etc/NetworkManager/NetworkManager.conf a dns= értékét átírod "none"-ra, akkor a NetworkManager nem fogja átírni. Illetve ugyanitt érdemes hozzáadni a "systemd-resolved=false" sort is, és letiltani a systemd-resolved-et, és akkor biztosan nem fogja felülírni a systemd-resolved sem.

"Red Hat alapú disztróknál nincs ifconfig, akkor sem, ha szerver telepítést csinálsz. nmcli"

Igaz. Pontosítok. Nmcli van, fde a konfig fájl neve ifcfg-, lásd az elérési útvonalat.

/etc/sysconfig/network-scripts/ifcfg-csatoloneve

Nálam most k-ra levizsgáztál linuxból. Elismerem az összes linuxhoz értesz, plus 2.

Be vagy véve a bandába. :)