Debian - melyik init rendszert használjuk a jövőben?

Címkék

A Debian fejlesztőket egy ideje már foglalkoztatja, hogy milyen modern init rendszert kellene bevezetniük a jövőben. Marco d'Itri szerint egyre inkább nyilvánvaló, hogy a modern szoftvereknek eseményvezérelt init rendszerre van szüksége. Az ilyen init rendszer mellett több minden is szól:

  • több funkcióval rendelkezik
  • stabil támogatást nyújt a fejlettebb boot / SAN környezetekhez
  • vele az olyan dolgokat, mint például a GNOME, egyszerűbb lenne csomagolni
  • stb.

Hogy mi szól ellene? Marco szerint az, hogy a bevezetése némi munkával jár. Természetesen azt is érdemes megjegyezni, hogy a SysVinit - amellett, hogy vannak érvek mellette is - életben tartása is munkával jár.

A Debian Technical Committee egyes tagjai elkezdték publikálni, hogy milyen következtetésre jutottak azzal kapcsolatban, hogy a Debian-nak a jövőben melyik init rendszert kellene használnia.

Ian Jackson az Ubuntu által is használt upstart mellett tette le voksát. Ian hangsúlyozta, hogy a systemd karbantartókkal ellentétben ő úgy gondolja, hogy fontos a portabilitás a nem Linux rendszerekhez. Lehet, hogy a Debian nem Linux portjait nem használják széles körben, azok lehet, hogy nem megfelelően karbantartottak, illetve lehet, hogy nincsenek éles felhasználásra alkalmas állapotban, de szerinte fontos a Debian számára, hogy ezeket az opciókat nyitva hagyják.

Vele ellentétben Russ Allbery a systemd megoldást favorizálja. Véleménye szerint a systemd-nek két területen is jelentős előnye van az upstart-tal szemben. Szerinte ezek mindegyike önmagában is elegendő lenne ahhoz, hogy a systemd mellett döntsenek, együtt azonban meggyőző érvet alkotnak a systemd mellett.

Linkek:

Hozzászólások

Zahy ezen az előadáson azt mondta, hogy talán az init rendszernek csak init rendszernek kellene maradnia. Én ezzel teljes mértékben egyetértek. Tegye fel a kezét, aki ellenállhatatlan vágyat érzett, hogy a grep-be integrálja a sed és a vim bizonyos funkcióit, mert akkor nem kell két szoftvert telepíteni! Naugye. Cipőt a cipőboltból. Szerintem a SysVinit a leginkább átlátható, biztonságosan használható. A boot idő és az új, szuper integrált szolgáltatások inkább ilyen funkciónáciság. A helyett, hogy a meglévőket tökéletesítenék...

SysVinit résznél:

"Mi a megoldás a problémákra ?
Strukturáljuk át az ismert, szabványosított (LFS/FHS) felépítésű fájlrendszert!"

Pont ezt teszi poliverzum is. Akkor innen (is) merített támogató szavakat a terveihez.

:-)

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Lassan eljut minden Linux distro a servicek kezelését illetően oda, ahol már a Windows NT is volt 15-20 évvel ezelőtt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Függőségkezelés servicek között, servicek követése, service elhalálozása esetén események, párhuzamos indítás (oké, ezt mondjuk a Windows 2000 még nem tudta, de az XP azt hiszem, már igen, ami szintén már 12,5 éves rendszer...), meg ilyen apróságok, amik miatt most váltani akarnak.

Hja és mondjuk ugyanezek az ütemezett feladatokra is. Most mondjam azt, hogy láttam azért olyan helyet, ahol az jelentette a technika csúcsát, hogy a cronból futtatott PHP script végén küldtek egy mail-t, és "onnan tudom, hogy elhalt a cron, hogy hosszú ideig nem jön levél" (LOL).

Na meg amióta van MMC, azóta még be sem kell lépkedni minden egyes gépre külön-külön, egy központi helyről is lehet ezeket menedzselni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Biztosan így van, elhiszem Neked.
Felteszem, nem láttál normálisan üzemelő Debian -t; ez azonban nem a Debian hibája, mint ah ogy a Tiéd sem - sokkal inkább az ott dolgozó rendszergazdáé.
Vagy ért az üzemeltetéshez, vagy nem. Az init rendszerek pedig a legkevésbé hangsúlyosak egy production környezetben, ahol egy szolgáltatásnak nem naponta, hanem évekig sem szabad akár újraindulnia. Arra meg monitoring kell, s az hívhat esetleg event handlert.

Azért ehhez az is hozzátartozik, hogy Winen nem attól lesz service egy executable, hogy rámondjuk, hogy service, hanem - a néha visszafelé egyáltalán nem kompatibilis* - service API miatt. Almát körtével tipikus esete, mert a zárt platformokon túli világban nem sokan szeretik, ha előírják, hogy pontosan mit hogyan használjon ;)

És azért a Win service kezelő se tökéletes, lehet gyári service-el is találkozni, ami egy leállítási kérelemre cseszik időben (30 sec, azt hiszem?) válaszolni, MMC meg ilyenkor közli, hogy "bocsi, nem sikerült".

BlackY
*: Lásd desktop interactive szolgáltatások

"Azért ehhez az is hozzátartozik, hogy Winen nem attól lesz service egy executable"

Pontosan jól tudom, hoyg nem attól lesz service, hogy sc-vel betolok egy random exe-t. Magam is írtam már Windowsra servicet.

"mert a zárt platformokon túli világban nem sokan szeretik"

És az kit érdekel? Én sem szeretek egy csomó mindent, senkit nem hat meg.

"ha előírják, hogy pontosan mit hogyan használjon ;)"

Úgy van, halál a szabványokra, szabványos formátumokra, halál a jól definiált protokolokra, interfacekre és az ezeken keresztül egymással kommunikáló programokra! Nehogy bárki is elő merjen írni bármit is!

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az, hogy valami kotelezo vagy szabvanyos nem ugyanaz. Nem veletlenul van legtobb megoldasra altalaban tobb szabvanyos lehetoseg is es a gyakorlat/nepszeruseg idovel igazolja melyikek lesznek a befutok azokbol.
Itt sincs tobbrol szo, minthogy van 3 nepszeru variacio ami kozul valasztani szeretnenek debianosok, megis a tema elejetol kezdve atment flame-be, hogy minden sz@r & windows

Amit írtam inkább arra vonatkozott, hogy van egy szabvány programok készítésére, amivel minden platformon lehet démonként működő kódot írni, gyakorlatilag minimális portolási költséggel (tudom, tudom, egyszerűsítés).* És akkor ott van a Win, ami meg nagyjából azt mondja, hogy jó, ha usertől független démont akarsz írni, akkor használd a service API-t vagy ígyjárás; és igen, az OS-sel történő kommunikáció egy arányaiban kb. 0%-nyi kód, de azt is meg kell írni. Ha pedig a máshol standard eszközökkel csináltad ezt (pl. signal-ok), akkor szép ígyjárás.

*: és igen, az init scripteknél (és továbbra is különbséget kéne tenni az init script és a démonként ténylegesen futó executable között) tényleg sok esetben ott van a taknyolás (pid fájlok, etc.), viszont továbbra sem kell különleges kódot írni csak azért, mert valami a háttérben akarsz állandóan futtatni.

BlackY

Ami elég nagy szopás lesz, ha belegondolok.
Linuxon valamit elkefél a rendszergazda, egy live CD-ről az esetek többségében viszonylag könnyű helyretenni.
Ugyanezt egy windows-os, bináris adatbázison alapuló (registry), csak a saját programjaival konfigurálható rendszeren előadni... hát legalábbis kényelmetlen.

Ezzel szemben a realitás most az, hogy:
- servicek követése nem vagy nem jól megoldott, tipikusan alkalmi gányolások vannak.
- megy a pampogás, hogy "de lehet ám, hogy nem olyan jó az, hogy automatikusan újraindítja a serviceket, ha elhalálozik, mert [random indok]". Ezzel szemben az átlag üzemeltetési tapasztalat az, hogy ha valami elbaszódás van, akkor jellemzően megpróbálják a servicet újraindítani. Ugyanott vagyunk, csak a szolgáltatás hosszabb ideig esik ki.
- crontabnál cronok követése legalább ennyire nem megoldott.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem azt mondom, hogy jó ami van, csak azt, hogy az irány, amerre a systemd-vel elindultak, engem kissé megriaszt a felsorolt (és millió kifelejtett) ok miatt.
Automatikus service restart meg... hát egy-két alkalommal OK, de ha nincs lehetőség beállítani, hogy x restart után ne próbálkozzon újra, az tapasztalataim szerint tényleg több bajt csinál, mint ha kiesik a szolgáltatás arra az időre, míg az ügyeletes elhárítja a hibát.

+1
Kiválóan eltalált kifejezés a "megriaszt".
Valójában a service kezelés hiányossága és az egységesség hiánya a borzasztó.
Pl. szeretnék írni/használni egy service-t
- szabványosat
- egy régit
- egy kis scriptet és nem foglalkozom az illesztésével
- egyszerűt és nem foglalkozom az illesztésével

Well, ilyen már létezik elég régen, úgy hívják resource controller: srcmstr
A link éppen AIX 6.1-re mutat, de létezett jóval korábbi verziókon is.
A végeredmény várható: Elkészül a linuxra a tökéletes, majd az IBM benyom újabb billió dollárt, hogy működjön is. :)
Nopersze ekkor már lesz 8 féle és az opensource alapján ki-ki választhat kettőt-hármat magának.

Nem akarom nagyon degradálni az AIXet, mert:
1)offtopic
2)szerintem (is) az egyik legegyszerűbben üzemeltethető Unix
3)imádom

de azért a régebbi APARok és a mostani advisories-ok között is van egy kettő, amitől sírva kérném a IBM fejlesztőközpontok orbitális pályáról való bombázását.
Másrészt meg próbáltál már akár csak open source cuccot betolni alája?

Bocs mindenkitől az offtopicért.

+1
Ez itt az off ág. :)
Mindent el kell távolítani amit nem használsz, aztán azokat nem kell frissíteni! A fejlesztők is emberek.
Vannak trükkök:
--disable-asm
#define register
Fordítottam alá stunnelt (installp,resource controller alá), postfixet, de a legtöbbjét én írtam.

én a solarios smf-et is meglehetősen szerettem (leszámítva azt, hogy a fejlesztőknek nem sikerült felfogni, hogy ezt kéne használni, meg hogy broáf xmlben volt a konfigja).

Mondjuk az AIX nekem kimaradt.

szerk: mármint azoknak, akikkel akkor dolgozni kellett, nem úgy általánosságban.

Pedig nagy élmény lett volna. Ráadásul a konfig jó része ODM-ből jön. (Ez olyasmi, mint a windows registry, csak mégse :)))) Régen volt olyan menüpont, ahol feltette a kérdést: Primitív konfigfájlt szeretnél a hálózathoz, vagy normálisat? Egy példa "init script":
/etc/methods/cfginet
(nem magyarázom, vége)

Ha egy szolgáltatást ujra kell indítani annak oka van. Ezt az init rendszer nem hivatott vizsgálni/eldönteni. (egyébiránt ott a monit/nagios/icinga/whatever, ha ennek így kell mennie)
Cronok követése nem megoldott? Miért, nincs syslog? vagy: nincs anacron? vagy: nincs monitoring egy olyan szolgáltatásra, amit eszerint figyelni kell?

Szerintem elbeszéltek egymás mellett: ő szolgáltatásokról beszél, te initről. (szolgáltatás nem feltétlenül indul init scriptből, az inetd meg kissé kiment a divatból)

És igen, van monitoring, de az külön szoftver, külön meg kell tanulni, nem kerül fel automatikusan stb. Szóval bizonyos szempontból lehet előnye, ha az op.rendszer tudja felügyelni az általa indított szolgáltatásokat.

Nagyszerű, attól, hogy X task benyőg valamit a syslogba, hogyan fogok mondjuk olyat megadni, crontabban, hogy Y task ne fusson le, hanem anyázzon az adminnak, hogy gebasz van. Ja, persze, megírhatom én mindig újra és újra a celluxot rá.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ennek oka az, hogy a wind*ws felfogása szerint minden számítógép desktop amihez kellően felkészületlen felhasználó tartozik (mocsok dolog az általánosítás no, de a filozófia ami a win* mögött van az szerintem ez). Ezért alkottak olyan rendszert, amely általános eseteket definiálva jól/rosszul "elműködget".
Ehhez generáltak egy módosító felületet amelyet szintén a fenti elvre támaszkodva, jól elbonyolítva, proprietary eszközökkel lehet kezelni, és a kezelést drága tanfolyamokon tanulni.
Persze a 15-20 év túlzás a fenti írásban is, de az elfogultság néha megszépíti a számokat.
Ha egy céleszköz (szerver egy speciális szolgáltatási célra konfigurált számítógép) tervezett eseményekkel van felkészítve hozzáértő által, akkor a systemd restart igényeire nincs szükség. A monitor és az event kezelésen lehet vitázni, hogy kell e az init rendszernek ezzel foglalkozni, de az hogy a rendszer egy szolgáltatást újraindítson, mert az megáll... na azt nem. Max szóljon az operátornak, vagy legalább valami AI-val rendelkező másik rendszernek, hogy lécci megállt, döntsd el újra kell e indítani.
Amiért a Linux distrok ide jutnak az az, hogy általános célú oprendszereket adnak ki, és a desktopként használt gépeknél az események fontos részei a működésnek, az hogy ez így jó e, vagy sem, azt majd az idő eldönti, de nem lennék meglepve, ha lenne egy debian fork ami majd hanyagolja a "modern" init rendszereket.

+1

Már amikor először olvastam (nem itt hanem valami másik cikkben valahol, napokkal ezelőtt) hogy a rendszer maga csak úgy önhatalmúlag újraindít egy rendellenesen leállt szolgáltatást, hát esküszöm szinte megállt bennem az ütő, mert eddig egyszerűen fel se merült bennem a gondolat hogy ilyesmi egyáltalán létezhet Linux környezetben! Hiszen ez iszonyatos biztonsági kockázat!

Gondoljunk csak bele: A hibás leállásnak oka van. Nem tudhatjuk, mi az oka. Úgy értem, a rendszer ezt nem tudhatja. Tuti hogy fogalma sincs róla. Ha ugyanis előre lehetne számítani az eseményre, máris nem rendellenes leállás lenne, hanem valami olyasmi, aminek a kezelését előre megírták, beleépítették. Teljesen nyilvánvaló előttem, hogy ilyenkor a rendszernek kutya kötelessége nyugton maradni, amíg valaki Illetékes Személy utána nem néz a dolgoknak. Akit persze kell hogy a rendszer értesítsen.

Fogalmam se volt róla addig hogy ilyesmi egyszerűen létezhet a Linux ökoszisztémában, és mélyen csalódtam amikor megtudtam hogy de ez mégis van, és egyesek ezt elfogadhatónak tartják.

Ami meg az initrendszereket illeti, nos, nem tudom melyik az egyszerűbb, de megtippelem hogy talán a systemv. Mindenesetre szerintem nyilvánvaló hogy a debiánba a legegyszerűbbet kell betenni alapból, azaz default, akinek bonyolultabb kell, az már úgyis eléggé ért ahhoz hogy ő maga feltelepítse.

-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Van az az eset is, hogy pl csomagfrissites eseten is onhatalmulag ujraindulnak altalaban a frissitett service-ek debian-on, fuggetlenul attol, hogy futott-e, vagy jelenthet-e ez gondot.

Vagy csak en nem talaltam meg egyelore hogy lehet ennek elejet venni, szoval ha valaki tudja megoszthatna :)

Olyannyira hallatlan dolog ez, hogy pl. egy autoiparban dolgozó ismerős mesélte, hogy ott pl. egyenesen követelmény az, hogy hiba esetén újra kell tudnia indulni X millisecen belül a komponensnek.

De mondhatnék a saját házunk tájáról is több olyan példát, ahol nincs idő arra várni, hogy valaki hajlandó legyen foglalkozni a feladattal. Pl. mi van, ha kiesik a sphinx (egy keresőmotor) az oldal mögül mondjuk egy 4 napos hosszú hétvége előtti este? Recovery process kb. úgy is úgy nézne ki, hogy
1) megpróbálja újra elindítani az admin
2) törli az indexet, újraépíti, goto 1
3) egyéb megoldások keresése.

Na most ebből az első két megoldás teljesen automatizálható. Kettő között az a különbség, hogy ha lehetséges, akkor perceken belül újra üzembe áll a service, egyébként meg lehet, hogy órák kérdése. És egyelőre a bevételt a működő szolgáltatások hozzák, nem az, hogy te mit hiszel arról, hogy mi létezhet a Linux ökoszisztémában.

De mondhatnék szintén házon belülről példát: pgagent (job scheduler postgresql-hez) + debian. Alapvetően tök jól működött, leszámítva, hogy időnként szó nélkül megállt. Hogy mi okozta, azt a mai napig nem tudjuk. Csodás megoldás az lett rá, hogy időnként a cron nézte, hogy mi a helyzet vele. Szóval légyszi ne mond már, hogy az igény egy normális megoldásra légből kapott.

De mindegy, könnyű a partról okoskodni és hitvitázni, és más dolog az, amikor valamire a gyakorlatban valaminek mennie kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

-Olyannyira hallatlan dolog ez, hogy pl. egy autoiparban dolgozó ismerős mesélte, hogy ott pl. egyenesen követelmény az, hogy hiba esetén újra kell tudnia indulni X millisecen belül a komponensnek.
-Az autóiparban ugye van egy olyan mérnök, hogy mechatronikai mérnök. Ez a mérnök neked nem fog operációs rendszert tenni a kocsidra jobb esetben. Beágyazott rendszeren oldanak meg.
Én már mondtam máshol is, hogy a POSIX-hoz szükséges dolgokat elektronika szinten is meg lehetne valósítani.
Kicsit elkalandoztam, de lényegében vannak dolgok amik egy operációs rendszernél evidensnek kéne, hogy legyen.
Én azzal kapcsolatban, hogy melyik a jobb megoldás nem foglalok állást, szerintem már a hw-knak is fejlettebb állapotban kéne lennie.

mc futtatására képes eszközt munkagépnek nevezzük

pl. egy autoiparban dolgozó ismerős mesélte, hogy ott pl. egyenesen követelmény az, hogy hiba esetén újra kell tudnia indulni X millisecen belül a komponensnek
Ezt ugye watchdog-nak hivjak, es embedded cuccokban (lasd autoipar) elegge fontos. Ezt nem vonja ketsegbe senki.

Csak az eredet kerdessel (linux boot, init, auto restart) kapcsolatosan erdekes, hogy egy init rendszernek mennyire kell watchdog-kent is funkcionalnia...

Ha mar egyszer az kezeli a serviceket, akkor talan csak erdemes kordaban is tartania es figyelnie, hogy mi tortenik.

Miert? Egyreszt, bizonyos dolgokat anelkul keptelen vagy megcsinalni, pl. fuggosegkezeles, fuggosegek alapjan torteno inditas, jol parhuzamositott inditas. Pl. ott a pgagent, slony-i, amit addig nem erdemes inditani, ameddig nem fut a PostgreSQL. Na, ez az, amit nem kepes megmondani az init rendszer, ha nincs benne semmifele watchdog funkcio.

Lenyegeben annyi, hogy az eddigi visszacsatolas nelkuli iranyitasbol lenne egy visszacsatolasos szabalyozo. Nem ertem, hogy miert okoz ez egyesekben ekkora megrokonyodest, hogy valamit tovabb akarnak fejleszteni.

Ami mar erdekesebb kerdes volt, hogy a cron funkcionalitasat minek belerakni az initbe. A helyzet ugyanaz mint a fentinel: alapvetoen egy job scheduler is indit dolgokat. Ha meg mar van egy megirt kodunk, ami arra szolgal, hogy esemenyek hatasara indit es figyel dolgokat, onnan mar csak egy lepes, hogy mi legyen a kivalto esemeny. Ha azt nezzuk, meg egyszerusodik is a scheduler, mert nem kell mar foglalkoznia magaval az inditas resszel, ahhoz meg eddig is eleg buta volt, hogy vegul is mi lett a taskkal.

"Ezt nem vonja ketsegbe senki."

Pedig a felallas itt is ugyanaz. Kulonbseg annyi, hogy itt most sok kis onallo, buta, lazan kapcsolodo dolog lenne kidobva es lenne helyette egy jol integralodo program(csomag)*, ami egyebkent ugyanugy viszonylag egyszeru modulokbol all, csak nem kiscsillio onallo binarisbol es megvalosul(hat)na egy szabalyozasi kor is.

Ami a regi rendszerben egy picit bonyolultabb modon johet csak letre. (De ez ugy latszik, mindenkinek elkeruli a figyelmet.)

* Ofc. implementacio mas kerdes, de eddig meg senkit nem lattam aki upstart/systemd/launchd/egyeb init replacement temakorben az implementacioval foglalkozna, csak azzal, hogy "ha'hogykepzelik!!!111"

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

-Lenyegeben annyi, hogy az eddigi visszacsatolas nelkuli iranyitasbol lenne egy visszacsatolasos szabalyozo. Nem ertem, hogy miert okoz ez egyesekben ekkora megrokonyodest, hogy valamit tovabb akarnak fejleszteni.
-Most akkor irányítástechnikáról vagy szabályozástechnikáról beszélsz?
Tudod szabályozásnál kell lenni visszacsatolásnak és ez analóg is lehet.
Irányítástechnikával ellentétben digitálisról beszélünk és nincs visszacsatolás.

mc futtatására képes eszközt munkagépnek nevezzük

Értem én, de akár az initet is meg lehet patkolni. Illetve nyilván van valahol egy középút a "sysv init jézus óta így működik, semmit nem szabad megváltoztatni, mert akkor mindenki nagyon szomorú lesz" és a "dobjuk ki az egészet a gecibe, és majd systemd néven Lennart végre megírja, hogy az emacsot be lehessen bootolni" között azért van középút.

Félreértés ne essék, értelmes gyerek, meg szerintem alapvetően jól csinálja, de nem mindig értem, hogy miért jó egybegyógyítani mindent.

Tudom, csak nem feltétlen szeretem az implikációit. Magukkal a funkciókkal nincs gond, az hogy ennyire monolitikus, azt nem szeretem, mert ellent megy a unixos nem is tudom, szemléletnek. (Ami a lényeg hosszú távon imho, nem pedig az, hogy soha semmi ne változzon.) A sysv initre ráfért a nagytakarítás, tényleg meg kell nézni, hogy ahány disztró, annyi fele széjjelizélt shellscriptek. (Meg eleve -- tudom, Zahy meg fog ölni, de -- shellscriptek? Nem nagyon rajongok értük fontos dolgok környékén, bár itt az indokok egy jó része valószínű egyszocprob.)

Pl a lentebb linkelt qr kódos izé. Ok, van benne logolás, ráadásul szimpatikus featureökkel, meg tök igaza van a faszinak, hogy service control log nélkül nem az igazi. Aztán ha szeretnéd, jön vele az egész basz, ezzel együtt mutogatnak tovább egy featureset után, hogy hát akkor ott az rsyslog. Ami persze egy pár dolgot ebből nem tud, aztán majd lesz valami, ami miatt kell ez, és akkor jöhet a systemd, és nem jöhet az rsyslog (A default offra csinált qr kód meg legyen már bazira moduláris, könyörgöm).

Vagy van benne valami cron szerű izé. Éljen éljen. De összeintegrálva, minek? Udev is, ok, értem, hogy minek, de tényleg jó, hogy így össze van nőve?

Aztán a real life mutatja is, hogy miért tuszkolják be a disztrók? Mert kell a GNOMEnak, azért. (Akik meg elmehetnek tényleg a picsbe, hogy egy ennyire linux only techre építenek).

"De összeintegrálva, minek?"

Na, most itt azon megy a hepaj, hogy egy programcsomagban jon? Az miert is baj? Mert, azert nekem ugy tunik, ezek különálló komponensei a systemd-nek.

Na, meg hogy miert kell osszeintegralni? Ha, most csinálsz egy rendszert, ami követi a servicejeid életútját, dependenciait, es lényegében Ugyanez kell neked a cronnal is, akkor miert valositsd meg Ugyanezt, es miert ne egy ütemező servicet valosits meg, a többit meg bízd a meglévő kódra.

Na, es mivel ezek nagyjabol egy projekten belul mennek, miert is baj, hogy egy csomagban kapod? Raadasul ugy, hogy te valogatpd ossze mi kell?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™""

Nem mondanám hepajnak, az túlzás. De azért, mert nem biztos, hogy nekem ez kell? Ellenben ha csomagban le van nyomva a torkán az embernek (márpedig ha nem úgy készül eleve, hogy elvannak a darabok magában, akkor azért nem triviális szétszedni), akkor jön a mindenféle vackával együtt, mikor egy disztribútor szállítja, mert valakinek kell, és lesz belőle káosz. (Megkockáztatom, hogy a systemd is úgy volna legfaszább, ha maaga a szerviz bizgető része is tudna úgy menni, ha nem ő viszi az egész rendszert, hanem kvázi csak a daemonok egy részére használja az ember, ha kell neki.)

Meg fene tudja, én nem szeretem, mikor jön az adott projekt (ezesetben pl Lennart), hogy a journalctlbe épített mindenféle szűrő mennyivel faszább, meg gyorsabb úgy, mintha tailelnél, meg greppelnél, meg ilyesmiket csinálnál, minek az neked, miért zavar, ha a compatibility mode helyenként bugzik. És látszik, hogy elfelejti, hogy azért, mert az admin dolgozik még a systemd-n túl úgy 100 másik istenverésével, amit mind tailel, meg greppel, meg cuttal szűr, és érdemei elismerése mellett idgesíti, ha mind a 100nál külön meg kell tanulni, hogy hogy tud benne keresni, mikor alapvetően azért ugyanarról van szó mind a 100 esetben.

Megint ez a csőlátás... Felfogtuk, nem dolgozol az IT-ben, de nem kéne olyan dolgokhoz hozzászólni, amiről fingod sincs. Már bocsánat a nyers kifejezésért, de ezek engem nagyon tudnak zavarni.

Nem tudhatjuk, mi az oka. Úgy értem, a rendszer ezt nem tudhatja. Tuti hogy fogalma sincs róla.
Lehet, hogy Linuxon tényleg nincs ilyen eszköz, ebben akár igazad is lehet, én még sosem kerestem. De attól még ne zárd ki a lehetőségét annak, hogy máshol legyen. ;)

Ha ugyanis előre lehetne számítani az eseményre, máris nem rendellenes leállás lenne, hanem valami olyasmi, aminek a kezelését előre megírták, beleépítették.
Ez egyébként nem igaz. Gondolom sosem fejlesztettél/terveztél még service-eket vállalati környezetben. Ezzel amúgy nincs is baj, de ismét arra kell kérjelek, hogy úgy ne alkoss valamiről véleményt, hogy nem értesz hozzá. Pontosabban véleményed nyilván lehet, de ne akard azt az abszolút igazságnak beállítani.

Teljesen nyilvánvaló előttem, hogy ilyenkor a rendszernek kutya kötelessége nyugton maradni,
Jobb helyeken azt is meg lehet mondani a rendszernek, hogy hányszor próbáljon újraindítani. Nyilván nem célravezető, hogy a probléma megoldásáig spammeli az újraindítást, de mondjuk lehet olyat, hogy ha a szolgáltatás kiesik, próbálkozzon _egyszer_, és ha az sem jön össze, sikítson.

Fogalmam se volt róla addig hogy ilyesmi egyszerűen létezhet a Linux ökoszisztémában
Szomorú lenne, ha így lenne, mert ez azt jelentené, hogy a Linux még nagyon messze van a vállalati felhasználástól.

nem tudom melyik az egyszerűbb, [...]. Mindenesetre szerintem nyilvánvaló hogy a debiánba a legegyszerűbbet kell betenni alapból, azaz default, akinek bonyolultabb kell, az már úgyis eléggé ért ahhoz hogy ő maga feltelepítse.
Lásd előző pont, véleményem szerint a "nem tudom" és a "szerintem nyilvánvaló" jobb helyeken nem fér el egymás közelében...

Egyik kedvencem az volt, amikor Exchange 2003 szerveren a POP3 szolgáltatás nem indult el reboot után és "Starting" állapotban ragadt. Ha az ember akart egy leállítást, vagy restart-ot a beragadt service-en, akkor egy idő után kapta a "service did not respond in timely fashion"-t. Ha jól emlékszem, akkor a megoldás az volt (annak idején fórumokon írták), hogy az inetinfo.exe PID-jét megkeressük (mondjuk pslist-tel) és killeljük (mondjuk pskill). Utána mindegyik szolgáltatást el lehetett indítani. \o/

A gyári grafikus felületen nem lehetett vele mit kezdeni. Esetleg Process Explorer-rel.

--
trey @ gépház

A "debian nem linux portjait..." nem értettem igazán...

Nekem is egyszerű volt használni, és eddig még nem hagyott cserben a VBoxManage köré írt megoldásom.
Fedora 15 alatt (systemd) pl nem tudtam összehozni, hogy az nfs korábban választódjon le mint a hálózat. (Mondjuk pár próbálkozás után nem vesződtem vele tovább.)

Valóban, de mellettem szól, hogy csak második szintű címsorokat használnak a http://www.debian.org/ports/index oldalon és valamiért a kFreeBSD nem a "Nem Linux-alapú portolások" részben van, hanem a Megjelent port-oknál (az angol oldal ebből a szempontból tisztább, nincs meg a két szempont szerinti szétválasztás)

BlackY

Tud valaki egy jo osszehasonlito tablazatot amiben latszik 3 versenyzo kozul melyik miket tud es milyen megoldassal/aron? (nem ismerdektem meg kulonosebben systemd-vel, de erdekelne gyakorlatban mi a haszna upstart-hoz kepest)

Igy elso keresgelesre ezeket talaltam, de nem tudom mennyire realisak (vagy idejet multak):
http://0pointer.de/blog/projects/why.html
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

Ezeket elnezve szerintem jobb valasztasnak tunik a systemd megha komplexebb is es tobb munkaval jarna atallni ra.
Systemd-vel lenne cgroup es selinux (bar debian ezt nem erolteti) tamogatas, illetve sokkal tobb mindent tudna dinamikusabban kezelni latszolag.

Arch-on használom a systemd-t, saját szkriptekkel is. Piszok kényelmes és nagyon jó a függőség/élettartam kezelése. Nagyon extra dolgát nem használom, csak mittomén svc halál esetén újraindítási próba párszor, saját pid fájljait, ilyen "alapdolgokat", amivel máshol sokat kell szívni.

Saját cuccnál a req sor belövése a legnagyobb falat, pár dolgot azért nehezen lehet letolni a torkán. :) Pl. dhcp network up-nál elsül a req, ip nélkül; érdemesebb egy okosabb szolgáltatásra "várni", ha nem tud vki bindelni az ip-re emiatt. :DDD

(A leírás tényleg jó, nézem is menten. :) )

A Nokia N9 upstart-ot hasznal, dolgoztam is vele kicsit. Mukodik es szep is lehetett volna, de a vegere elegge gany lett, pl amikor x dependency-je y service, y-nak meg z meg k, de ezek a service-ek lasan indulnak, es sleep-ekkel lettek az upstart scriptek telerakva, hogy minden akkor induljon amikor a masik service-ek mar tenyleg elindultak, ugyanis amikor x service-nek beallitod hogy y elindulasakor induljon, akkor az tortenik hogy y service init scriptje lefut es kuld egy signalt hogy y elindult, ekkor indulnak a ra dependalo service-ek. Es ekkor jon a problema, hogy ha y service sokaig indul valamiert, mondjuk 1 sec alatt lesz kesz, akkor a ra dependalo service pedig lehet hogy el sem tud indulni, leall. De ugye mar elkuldodott az o signalja is, azaz masik ra dependalo service-ek indulhatnak el. x service-nek bevolt allitva hogy ujrainduljon ha leallt, ekkor elkuldi a signaljat, hogy ujraindult, am a raepulo serviceeknek belehet allitani hogy ha egy dependency ujraindult, akkor o is ujrainduljon. Es ujraindulnak. Ez egy konkret eset volt, es elkerulheto az ilyesmi, ahogy az n9-ek is elegge stabilan bootolnak, csak elegge csunya tud lenni egy ido utan. Inkabb valami olyasmi megoldas lenne hogy, ha mar az adott service-ek egymasra dependalnak, hogy egy service ha kesz van, akkor szol hogy elindultam, es ekkor indul a tobbi.

SELinux-ot már én sem erőltetném, miután az NSA kezecskéi igen mélyen benne voltak a fejlesztésében. ;)

Amit viszont végképp nem értek, hogy miért a bevezetéséről beszélnek? Tényleg arról van szó? (ehhez talán kevés az angolom)
Ugyanis a wheezy-ben kb. egy apt-get install systemd, egy sor átírása az /etc/default/grub-ban és egy reboot az egész, attól kezdve használható.
Nem inkább az a kérdés, hogy alapértelmezetté tegyék-e valamelyiket a jelenlegi sysv helyett?
Vagy amit találtam és kipróbáltam, az csak látszólag systemd?

Nekem az a tapasztalatom, hogy debianban talalhato kismillio csomag miatt sokat szamit mi az alapertelmezett, mert elsodlegesen ahhoz fogjak megcsinalni a szukseges konfigokat es modositasokat ahogy kell.
Ami viszont csak opcionalisan valaszthato ott konnyen lehet kevesbe gyakori service-ek eseten ez nem lesz meg (bar nem probaltam egyelore ez mennyire fest igy systemd+debian parossal).

Ugyan sysvinit konfigokat megeszi systemd es kepes hasznalni, ezert valoban atallithato igy konnyen systemd-re a rendszer, de attol meg nem lesznek valoban kihasznalva a systemd-ben rejlo lehetosegek ha nincsenek megirva hozza a konfigok, ezert szerintem igenis szamit mi lesz az alapertelmezett.

Hol van itt az osszefugges?
Szerinted miert minositi az a selinux-ot, hogy grsec fejleszto demo videokban kikapcsolja az alapertelmezetten bekapcsolt selinux-ot?
Nem lehet, hogy csak mert a sajat megoldasat akarja favorizalni, netan nem akar azzal foglalkozni grsec bemutatasnal hogy egyutt tud-e mukodni selinux-al, avagy csak konnyebb ugy demozni egy exploitot, hogy selinux nem fogja meg mert kikapcsolta?

Nem tudom hogy mi volt a neve de ~6-8 évvel ezelőtt amikor azon töltöttem ki a "kreativitásomat" hogy Gentoo -t patkoltam, abban már dependency kezelésre képes init rendszer volt.
Tehát nem határoztál meg sorrendet csak ha pl. csináltál egy új service -t annak azt mondtad hogy "kell neki a net" és cső.

--
http://developersideas.blogspot.hu/
http://neurogadget.com/

Gentoo alapbol sysvinit-et hasznal amire reheggesztettek a sajat init script rendszeruket. Ez az init script rendszer ujra lett irva C-ben es most OpenRC neven fut. A regi rendszer meg OpenRC kozott felhasznaloi szemszogbol semmi kulonbseg nincs, ugyanazok az init scriptek meg parancsok mukodnek. Max annyi, hogy az OpenRC mar tud parhuzamos inditast is.

Viszont most Gentoo is elkezdett "atallni" systemd-re, fokent mert Gnome 3-nak szuksege van ra. Mondjuk Gentoo eseteben az "atallas" azt jelenti, hogy ket teljesen supportalt init rendszer van az OpenRC es systemd. Azt teszel fel amit akarsz, de Gnome 3-hoz a systemd ajanlott/kell.

Régebben - ha nem is szerettem a GNOME-ot, legalább nem volt ellenszenves. Az utóbbi időben viszont (például ennek a systemd-s őrületnek köszönhetően) kezd egyre visszataszítóbb lenni. Tökéletes példája annak, hogy csak addig lázadoznak a bezártság ellen, ameddig nekik kellemetlen, mikor már neki kellene valamit tenni (pl. odafigyelni másokra), akkor már semmi probléma a bezártsággal. Pont ugyanolyan vendor lock-in, mint ami ellen annyira hőzőngenek. És mint ilyen, tökéletes megcsúfolása a GNU-nak. A modern GNOME-nak kell pulseaudio. Meg udev. Meg systemd. Holnapután pedig az is kell, hogy a /etc/*-release fájlban benne legyen az, hogy ..... (sőt eleve csak az a release fájl lesz jó, amit úgy hívnak, hogy ...).

Igen, ez eléggé. Még süti bácsiéknál/redhatéknál értem, for profit, csomagolják azt, ami nekik kell, meg fejlesztenek olyat, de gnomenál, ami önmagában nagy FOSS, nekem is furi (bár mostanság ritkán látok desktop linuxot, uh. személy szerint fájni nem fáj).

Egyébként nekem a gnome azon túl, hogy anno azzal kezdtem sose volt szimpatikus. Onnan lehetett megismerni, hogy új release van, hogy valami interfacenáci már megint eltüntetett valami beállítást, hogy az oda úgyse kell. Bezzeg azt, hogy a default kinézet ne úgy nézzen ki, mintha megtámadott volna a 70es évek, azt nem sikerült megnáculni sose.

Regebben volt errol szo az openbsd valamelyik levlistajan. ajacoutot@ eleg sokat toltott el, hogy hasznalhato legyen, a sok Linux-only dolog miatt.
Vicces, hogy a FLOSS community mennyire elfelejtette, hogy mas rendeszerek is vannak, pedig... Theo meg pont ez ellen kuzd. Erdekes ez az open(smtpd/ssh/stb...) kapcsan.

Szerintem olyan kérdéseket is fel kéne tenni, hogy egyáltalán az init rendszerre kell-e bízni a servicek futtatását, és hogy az esemenykezelés meg az automatikus függőségkezelés a serviceket illetően hasznos-e vagy káros. A boot folyamat párhuzamosítása baromság, nyerni lehet vele pár másodpercet, annak fejében, hogy a szerver néha nem indul el. Az a biztos, ami egyszerű.
--
ulysses.co.hu

Egyszerű viszont max. akkor lehet, ha valamelyik VM guest-ként dolgozol, nagyjából kötött hardware-rel. Példa: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInte… A bevezetőben ott a hibás use case: firewall, két interface-el, amik ha reboot után máshogy jönnek fel, bárki benn van a belső hálódban (vagy épp senki nem jut ki onnan).

BlackY

Azért még nincs veszve minden. Ki lehet szedni az udevet a systemd karmaiból. Az LFS például így csinálja. Le van írva ott pontosan, hogy hogyan. Nekem is annak alapján van udevem, de systemd nincs nálam.
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInte…

Ez kicsit váratlanul ért. Systemd+udev összeolvadnak? MAC cím alapján történő ethX névadás udev szabályok alapján dobva lett? Én a mai napig használom Debianon a 70-persistent-net.rules fájlt, ezek szerint elavult vagyok? Diszkeknél a pozíció szerinti elnevezés rossz, ezért azonosítót használnak, a hálókártyáknál meg pont fordítva sikerült? Elég gáz.

--

rw etc kell. És ez miért probléma? (Arról nem is beszélve, hogy szerintem ez a rw / vagy rw etc csak speciális esetekben kell: OS telepítésnél, illetve hardvercsere után. Erre meg nyugodtan fenn lehet tartani valami secialitast. Hívjuk mondjuk maintainance módnak (a'la AIX). De hívhatnánk akár single-user módnak is. És annyi a dolga szegény szerencsétlen hátbatámadott Linux-rendszergazdának, hogy amikor kicseréli a hálókártyát, és ehhez rebootol, akkor single-be indít, ott kiadja az "update-persitent-net-rules --yes-I-am-a-fucking-bastard" parancsot és ennyi volt. Ha meg olyan a hardvere, hogy hálókártyát újraindítás nélkül tud cserélni, akkor fenti parancsot pedig a kártya kicserélése után adja ki, kiegészítve az "--I'have-two-mother-of-course" opcióval. A parancs meg elintézi a tobbit.

Most komolyan, kéne egy szavazás hogy a Hupon Linuxot is használók közül hánynak van ro / es ro /etc-t használó rendszere. Tegyük fel sok - ez mondjuk több, mint tíz elképzelésem szerint, akkor egy másik szavazás pedig arról kell, hogy hány Linuxot használónak van többségében, vagy kizárólag így felhúzott rendszere.

Akkor játszuk el mondjuk ugyanezt úgy, hogy a HUP-on hány ember virtualizál hálókártyát, aminél időnként cserélni kell a MAC címet (VM klónozás, ugyebár). Vagy játszunk el azzal, hogy hány ember bootol PXE-ről valami linuxot. Stb. Nem megoldhatatlan probléma, viszont mennyivel tisztább az, hogy (igaz, bonyolultabb, de) fix neveket generálunk, mint az, hogy a garantált fix nevekhez mindenképp kelljen valami storage.

Az újraindítás nélküli hálókártyához még csak nagyon speckó hw sem kell, elég egy sima USB-s ethernet csatoló.

BlackY

És te a klónozott gépet rebootolod és már is mehet élesbe, mindenféle egyéb teszt nélkül? Mert ha nem, akkor mégiscsak ott a maintainance mód. Az USB-s ethernet nem rendít meg, de félek, ez a kisebbség :-)

Amúgy nekem tök mindegy, hogy hogyan lesz perzisztens interfésznevem. Nekem az új elnevezéssel semmi bajom nincs, csak az, hogy megint egy olyan módszer, amit át fognak hágni. Azaz gondolom kb 3 perc lesz, és a disztrók beépítik a boot-scriptekbe az
ip link set $DEVICE name eth0
sort, mert különben a világ rendszergizdáinak 95%-a nem fogja megtalálni az interfészeit, ha annak nem az a neve, hogy ethX. (Legalábbis még nem tudok róla, hogy láttam volna embert, aki /dev/disk-by-uid/kriksz-kraksz néven tutujgatja *kézzel* a diszkjeit, nem /dev/sda-ként.)

Én nem, de nagyjából ez az ötlet. (lásd: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_V… ahol pont a network device infókat törlik a template-ből)

Szerk.: persze az unconfigured miatt AFAIK egy interaktív felület jön be az első bootkor, de mintha egy anaconda válasz fájllal azt is nullázni lehetne.

Értelme pl. akkor van, ha valami masszívan párhuzamosítható, de nagyon változóan terhelt rendszerről van szó, ahol mondjuk (akár automatizáltan) időnként be kell dobni pár új feldolgozó VM-et.

Fedora (azt hiszem 19, de lehet, csak a 20) és openSUSE (13.1) pl. hagyta az új elnevezést eredetiben.

BlackY

Minden tisztelem a prominens észak amerikai linux vendoré, de ami az unconfiguredkor törénik, az konkrét katasztrófa. Egyrészt, az, hogy mit kérdez ilyenkor, az attól függ, hogy a system-config-* csomagok közül mi van fent (ill. még valami másból is hív ezt-azt, ha van, valahol az rc.d-ben van egy script, amiből ki lehet bogarászni, hogy mik indulnak, aztán lehet yum whatprovidesozni, mert a man az ... ).

Aztán pont a system-config-network-tui fos. Ha nincs ott egyetlen ifcfg-dev file sem, akkor nem lehet hozzá devicet adni, arról ne is álmodj, hogy automata listát ad arról, hogy mit kerhelt az udev. Ellenben ha teliben otthagyod az ifcfg fileokat, akkor meg a mac a régi mac miatt új vmben (vagy hardveren), akkor mire ide kerültünk, addigra az udev a 70-persistent-net miatt már rég új device neveket adott nekik, és hasonló szépségek (onboot-ot pl. nem lehet állítani vele, és a default asszem no). Ráadásul valami bugban olvastam, hogy a system-config-network hivatalosan is hulla, ha szeretnél command line nw configot, akkor nyaggasd a network-manager fejlesztőket, hogy a hetes szériára kapják össze maguk.

Bár a RHEL-t linkeltem, leginkább a sablon-alapú virtuális gép provision-re akartam példát hozni; nem kifejezetten az implementációt, hanem az ötletet.

És speciel ezzel alá is támasztottad, hogy van értelme a konzisztens, generált iface neveknek, mert így kapsz konzisztens és generált iface neveket :)

BlackY

Azokkal a fix nevekkel az a baj, hogy gyakorlatilag kitalalhatatlanok. Ha mar ezt ennyire eroltetik, legalabb a BSD vonalon mennenek, hogy driverneve + interfesz szama, nem valami idota, mindentol elrugaszkodott nevezektan menten. Ennel meg az ethX is jobb.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Ez az egyik előny. A másik előny, hogy rendszer összeomlás vagy áramszünet esetén sem lesz korrupt a fájlrendszer, így utána csak mountolni kell, nem kell ellenőrizni.
Ez mostanában lehet, hogy nem nagy különbség, de még a naplózó fájlrendszerek elterjedése előtt egy rw ext2-re elég sokat lehetett várni. A ro ext2 meg rögtön működött.

Egyébként egy előny miért nem elegendő? :-)

Nem feltétlenül az adatok összekócolódása volt a probléma, hanem az, hogy ha nem tisztán volt unmountolva, akkor fsck futott. Nem naplózó rendszer esetén az fsck végigolvas mindent, és igen hosszú ideig elszöszmötölhet.

+1 dolog: ha valaki bejut a gépre, de nem root, akkor nem tud a ro mountolt partíciókba/logikai kötetekbe betenni dolgokat, átírni dolgokat, stb.

Nem ismerem ext2-t belülről, de számomra az lenne a logikus, hogy még ha rw is muntolsz egy fs-t, amíg egy bitet nem írsz rá, addig úgy tekinti, hogy ro volt, vagyis addig nem is kellene fsck-zni. De elhiszem, hogy ez egy valós probléma.

A másikra: ha már root joga van, akkor remountolni is tud, ha meg nincs, akkor amúgy se tud írni rá.

Megint a hozzaertes csodaja.

Valoban ir a diszkre, de mindosszesen metadata-t frissit, meghozza novel egy countert a fajlrendszeren belul, hogy hanyszor volt mountolva. Ezen felul a fajlrendszerbe _tenyleges_ iras (tehat olyan, amit kesobb az fsck ellenoriz) nem tortenik. A diff nem a legmegfelelobb eszkoz a demonstraciohoz, mert abszolut nem erti a fajlrendszerek mukodeset.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Ennek mi köze a hozzáértéshez?
Megszoktam, hogy sok az 1.0-s user már itt is, egyszerűbb volt demonstrálni, mint magyarázni.
(Az előttem hozzászólót nem ismerem, nem tudom, mennyire van képben)

update (eredetileg mobilról írtam, nem akartam részletezni) :

"számomra az lenne a logikus, hogy még ha rw is muntolsz egy fs-t, amíg egy bitet nem írsz rá, addig úgy tekinti, hogy ro volt, vagyis addig nem is kellene fsck-zni."

1. Ír rá.
2. Nem csak a countert módosítja, hanem a mount időpontját is felvési, valamint a mountolt állapot idejére kinullázza a superblock 58-as offsetjén lévő mezőt, amit az umount visszaír 0-ra, illetve ha jól tudom, az fsck állítja 2-re, amennyiben az ellenőrzés során hibát talált.

update2: arra viszont egyáltalán nem gondoltam, amit Zahy említett, hogy ha nincs noatime a mount opciók között, akkor bizony tempósan módosítja a rw fájlrendszereket, függetlenül attól, hogy akarsz-e írni rájuk vagy sem.

Igen, ugy tekinti, de van valami metadata bit, amit mountolaskor egybe allit, lemountolaskor meg nullaba (vagy valami hasonlo modon mukodhet), amivel nezi, hogy volt-e tiszta unmount. Ha nem tisztan volt lemountolva az rw particio, akkor mountolaskor lefut egy nagyon gyors check (_nem_ fsck, ezt maga a kernel csinalja, es annal sokkal-sokkal gyorsabb), ami ellenorzi a metaadatok konzisztenciajat, es utana mountol. Ha tisztan volt lecsatolva, akkor ilyen ellenorzes - hogy gyorsabb legyen az egesz - nem tortenik.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Ha olyan fajlrendszert hasznalsz, amelyikben letezik atime (access time) mezo a fajlokhoz (Linux alatt kb a Minix fajlrendszer nem ilyen, az osszes tobbiben van), es nem noatime-mal csatolod, akkor mar egy egyszeru 'ls konyvtarnev' parancs is modosit a fajlrendszeren, ezt az egyetlen infot a listazott konyvtar jellemzoi kozul modositja. Hasonloan egy 'echo konyvtar/*.c' szinten. (Szerintem amikor azt mondod, hogy paran(TAB)(TAB), akkor az ahhoz tartozo listat is a PATH-ban szereplo konyvtarak vegigolvasasaval gyujti ossze a bash (lenyeges kulonbseg, hogy tippem szerint nem akkor, amikor megnyomod a ket tabot, hanem akkor, amikor elindul a bash). Szoval a rw-mountolt fajlrendszer siman valtozik normal rendszerhasznalat kozben is, nem kell hozza "direkt" irni ra.


foo:~# loremip(TAB)(TAB)
foo:~# touch /bin/loremipsum 
foo:~# loremip(TAB)(TAB)
foo:~# chmod u+x /bin/loremipsum
foo:~# loremip(TAB)(TAB) -> kiegészíti

Így nem csak indításkor keresgél, esetleg még inotify-al szórakozhat (nincs NFS megosztás a környékemen, hogy kipróbáljam), de nem hiszem.

BlackY

első bliccre nem csak induláskor:


Please enter login information for host.
Username: user
Password: 
Last login: Thu Jan  9 09:15:49 2014 from ---
[user@host ~]$ echo $PATH
/usr/lib/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/user/bin
[user@host ~]$ wh
whatis    whereis   which     while     whiptail  who       whoami    
[user@host ~]$ wh
whatis    whereis   which     while     whiptail  who       whoami    
[user@host ~]$ wh^C
[user@host ~]$ touch bin/whatwasnotherebefore
[user@host ~]$ chmod +x bin/whatwasnotherebefore 
[user@host ~]$ wh
whatis                whereis               while                 who                   
whatwasnotherebefore  which                 whiptail              whoami                
[user@host ~]$ what
whatis                whatwasnotherebefore  
[user@host ~]$ what^C
[user@host ~]$ 

+1 dolog: ha valaki bejut a gépre, de nem root, akkor nem tud a ro mountolt partíciókba/logikai kötetekbe betenni dolgokat, átírni dolgokat, stb.

Különösen, ha pl. az nem is az adott gépen van; akkor még akár root-ként is bejuthat. Pl. egy read-only nfs-en levő /usr:

Example: /usr Network Share

With the merged /usr directory we can offer a read-only export of the vendor supplied OS to the network, which will contain almost the entire operating system resources. The client hosts will then only need a minimal host-specific root filesystem with symlinks pointing into the shared /usr filesystem. From a maintenance perspective this is the first time where sharing the operating system over the network starts to make sense. Without the merged /usr directory (like in traditional Linux) we can only share parts of the OS at a time, but not the core components of it that are located in the root file system. The host-specific root filesystem hence traditionally needs to be much larger, cannot be shared among client hosts and needs to be updated individually and often. Vendor-supplied OS resources traditionally ended up "leaking" into the host-specific root file system.

(Forrás: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/)

BlackY

NFS-en lévő /usr-t szoktak használni szerverek esetében is?
Mert diskless workstation esetében láttam már ilyet, de valahogy szervernél nem tudom elképzelni. (különösen, hogy anno az egyik legnagyok *nix sec.hole-ként az NFS-t emlegették - bár feltételezem, az újabb NFS-nél már kiküszöbölték a régi hibáit)

Miért nem írnak egy teljesen újat? :-)

Fuszenecker_Róbert

Szerintem inkább távolítsák el a GNOME-ból a systemd függőséget és hagyják az init rendszert úgy ahogy van.

gentoo/openrc megoldas talan a legjobb kalszikus init rendszer, foleg ha valaki ockodik a modern "csoda micsidaktol" :)

Viccess lenne egy Linux distronal nem a systemd -t valszatani init rendszernek, csak mert az nem megy (meg?) FreeBSD -vel.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerintem az XFCE pl. most is hasznalhato, max valami normalis automountert hianyolok kevesse geekek szamara. Es ha jol tudom, erosen erik a GNOME2 -> MATE + GNOME3 lepes. De hogy mi modon kuszoboltek ki az udev fuggoseget, illetve hogyan oldjak meg azokat amihez az kell, azt nem tudom. (OK, ez FreeBSD, a tobbirol nem tudok nyilatkozni.)