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

 ( trey | 2014. január 1., szerda - 17:46 )

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á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ő.

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...

Tegye fel... mondjuk a perl fejlesztői? ;)

Amíg a vim szóhoz nem értem, én is ezt akartam válaszolni :-)

Igaz, a full screen funkciók ...

"funkciónáciság"

Inkább a featuritis szót kerested, nem?
___
Arany János: Grammatika versben

Nem ismertem, de _pontosan_ ezt a kifejezést kerestem :D

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."

Elhatárolódom.

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™

Miért, hol tartott? És hol tart most?

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™

<troll>

Idézet:
Ú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!

Ez nem a Microsoft credoja?
</troll>

BlackY

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)

Láttam azért, egyszer kétszer be kellett lépni valami futó izére megrugdalni valamit, de azt a szabvány izékkel meg lehetett oldani. Majd egyszer sok időm lesz, nézek egyet valahol.

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™

Ezt windows-on hogy csinálod meg, kizárólag az op.rendszer eszközeit használva? (ugyan jártam win2k tanfolyamra, még papírom is van róla, de az egyetlen ami megmaradt belőle, az az mmc használata :) )

> minden Linux distro

nem.

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

tanuld mar meg azt a nyomorult quote taget hasznalni

Itt nincs is olyan!

bucko írta:
Itt nincs is olyan!

Tenyleg? (Mas kerdes, hogy lehetne rajta valami normalisabb CSS)

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

ertem en, hogy 20 eve nem volt az asmed mellett, de itt van :(((

Mutasd meg mester!


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

Ez nálam a következőképp működik:
1) Meszes tekervényeimen dereng valami.
2) Megnézem.
3) Aztán hozzászólók.
Aki nálam sokkal okosabb, az azonnal ír valami marhaságot. ;)

Idézet:
szólók

es kik adjak elo? ;-)

Asimov, megvan?

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...

+1 néha elég idegesítő ez a watchdog.
Volt, hogy inkább kikapcsoltam.


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

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

Ne ertetlenkedj, mostani init rendszerben hol a visszacsatolas, hogy elhalt egy service?

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

??? Pont az az init dolga, hogy ha elhalt valaki, azt észlelje. Ugye-ugye, a jó kis inittab és a benne levő respawn kulcsszó. Használni kéne.

+1


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

A hiányosságai miatt gyakorlatilag alkalmatlan erre, kezdve a függőségek/sorrend kérdésével.

Mondjuk azt speciel azért meg lehetne oldani a spanyolviasz újra feltalálása nélkül is.

Igen, ez a megoldás a mostani SysV init rendszer. :)

É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.

"Lennart végre megírja, hogy az emacsot be lehessen bootolni"

:)

Ha jól értem a systemd nem egy init megoldás, hanem egy általános eszköz, ami tud initet is.

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.

Ez aztán a téves diszjunkt képzavar! :)

Én asszem a systemdtől láttam olyat, hogy inditom..., a shell visszajött, azt meg, hogy sikerült-e, megnézhetted a logban (bár erre talán oda is volt írva, hogy ezt kéne tenni). Na, az spec implementáció fuck you volt.

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...

Te kötelezőnek érzed, hogy dilettáns, hozzánemértő baromságokat fröcsögj állandóan?
--
ne terelj

Remélem sosem jut el odáig, h egy adott service nem tud leállni, task managerből sem lehet kilőni, csak komplett újraindítással. És ez mai napig megvan. Ok, lehet ráfogni, h ez az adott service hibája is, de azért na.

Oh, pedig ennek az oka már 15-20 éve ismert. Ez nem bug, hanem fícsör.

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

Taskmgr, process kilovese? #troll
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Én úgy emlékszem, hogy azt próbálhattad, de nem használt. Nem véletlenül kellett a pstools-t külön telepíteni a Resource Kit-ből. Nem beszélve arról, hogy az általad javasolt megoldást elég nehéz automatizálni.

--
trey @ gépház

Viszont az IP stack-et illetoen a Win 7 64 bit-es valtozataban sikerult 50 evet visszalepniuk, mert elfelejtettek egy 20 byte-os kivonast, ha tordelni kell a csomagokat.

Van erre linked?

--

Akkor okosabb vagyok mint a 64 bites win7, mert kb. 3 órája kellett tördelést számolnom és nem felejtettem el kivonni. :)

De most komolyan, ez annyira lehetetlenül hangzik, még ha el is követték a hibát, nem tűnik nehezen javíthatónak.

Ha mar kiados flame, a macos launchd-jerol se feledkezzunk meg. Ilyen tulbonyolitott vackot ritkan latni.

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

Azokert szerintem nem annyira kar, de ha mindenaron azt akarjak hogy azokra is portolhato legyen akkor hagyjak meg inkabb a mostani sysvinit-et, mintsem az upstart-ot ezert valasztani.

Pedig az upstart nem annyira rossz. En most dolgozgattam vele, es egesz kenyelmes hasznalni, es boven eleg a tudasa a legtobb feladathoz.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

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.)

http://www.debian.org/ports/kfreebsd-gnu/

Ez lemaradt a listáról.
G.

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.

http://0pointer.de/blog/projects/systemd-for-admins-1.html

Ezt a sorozatot érdemes végigolvasni (nem vészes mennyiség), a 20. környékétől már jönnek a szép dolgok (pl. Socket Activated OS Containers)

BlackY

Koszi, jo leirasnak tunik, vegignezem amint lesz idom.

Gyakorlati tapasztalatod is van vele, hogy mennyire konnyen kezelheto, mukodnek-e stabilan az ilyen extra funkciok vagy milyen gyermekbetegsegei vannak?

Sajnos nincs, systemd-val csak annyival találkoztam az írás átolvasásán túl, hogy az hajtja a desktop gépeimet. (Fedora nekem túlságosan GNOME-centrikus ahhoz, hogy részletesebben játszak vele, máshol meg nem nagyon van ott a bleeding edge systemd)

BlackY

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.

Mi az a 20. amit emlegettél? Lehet, hogy én valami mást láttam, mint ti?

20 fejezetbol all az iras, csak linkek nincsenek benne elozoekben, ez a 20. :
http://0pointer.de/blog/projects/socket-activated-containers.html
elejen ott vannak linkek az elozoekhez.

Erre tippeltem, de az url-t módosítva csak 404-et kaptam.

Meg kb. ezt is. Jo hosszu szal arrol, hogy miert kell bele egy HTTP server es QR kod. Csodas.

Azt hittem, hogy csak viccelsz. Aztán megnéztem. /o\ Itt az idő, hogy kipusztuljon az emberiség. A programozókkal az élen. Ha így folytatják, nemsokára elkezdik a grafikus alrendszert is bele integrálni. Ne vicceljünk már, minek kellene ahhoz is külön processz?

dafuq did I just see.

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.

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

A grsecurity kell. Spender a videoiban a selinux-ot kapcsolja ki eloszor, vajon miert?

es melyik enterprise disztrib is szallitja a kerneleit grseccel?

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?

selinux nem pro, hanem kontra

-------------------------
Trust is a weakness...

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/

En se tudom, de a fuggosegkezelesnek van am eleg sok szintje, es mondjuk amit egy sysvinit-tel el lehet erni, az sokaknak nem elegendo.

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.

Nem ez a legszomorubb az egeszben, hanem az, hogy kerdes nelkul kirangattak a Gnome 2-es csomagokat, mate meg nincs a Portage-ben. Mintha nem lenne a slotting rendszer.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A GNOME 2-es csomagok már egy jó ideje karbantartó nélkül maradt, ez nem slotting kérdése. Már van Mate overlay, akinek erre van szüksége szerintem nyugodtan telepítheti.

Kerdes, h mennyire straightforward a GNOME2 -> MATE migracio.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

sokáig gnome3-classic volt nekem
de már lassan csak 1 program miatt kapcsolom be az x-et


mc futtatására képes eszközt munkagépnek nevezzük
Core2Duo T5870 8GB ram 1TB hdd
Ubuntu 13.10 GNU/Linux 3.11.1 unity/terminál

Nálam is részben ez lett az eredménye az Xfce és a GNOME újítgatásainak: awesome+terminálok.

Kéne egy kis howto :D
Ezt az awesomet hogy szerzem be?


mc futtatására képes eszközt munkagépnek nevezzük
Core2Duo T5870 8GB ram 1TB hdd
Ubuntu 13.10 GNU/Linux 3.11.1 unity/terminál

Google is awesome
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

+1 meglepően kézreálló gyorsbillentyűi vannak alapból.

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/PredictableNetworkInterfaceNames/ 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

??? Ha egy rendszer elbaszott hálózati interfész nevezéktant használ, akkor ezt a sysvinit kidobásával és systemd-re váltással kell megoldani, nem pedig azzal, hogy értelmes IF-nevekere váltunk?

A gond nem az, hogy most akkor pityuka vagy gézuka legyen az interfész neve, hanem hogy a HW inicializálás és a boot folyamat annyira bonyolulttá válik, hogy máshogy nagyon nem lehet kezelni, mint hogy csomó felelősséget egy-két alrendszernek adunk (udev, systemd) át.

BlackY

Ok, de speciel ezt miert nem az udev oldja meg? :)

Speciel az, de AFAIK a udev 2012 óta a systemd része.

BlackY

bakker, tényleg. Asszem még nem tértem teljesen magamhoz az évvégi punnyból.

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"! ===

A Gentoo is megcsinalta, eudev neven, nagyjabol az a cucc van benne, mint a systemd-ben, csak a systemd koritesei nelkul.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

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.

--

A persistent-net.rules fájl pl. azért rossz, mert kell hozzá egy rw root vagy etc. Az összeolvadás: http://cgit.freedesktop.org/systemd/systemd/commit/?id=19c5f19d69bb5f520fa7213239490c55de06d99d

BlackY

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.

+1 szavazzunk :)

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_Virtualization/3.0/html/Evaluation_Guide/Evaluation_Guide-Create_RHEL_Template.html 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

Pont ez motoszkált a fejemben, hogy én inkább kihagynám ilyen esetben a sablonból a bekonfigurált hálókártyát.

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

Tudom, nekem is pont ott került elő :) Nem cáfolni akartam, simán csak rantoltam egyet :) Egyébként nekem semmi bajom azzal, ha konzisztensek az iface nevek :)

Eleje: El tudom azt képzelni, hogy virtuális gép deploya úgy történik, hogy egy kiherélt masterből lesz mondjuk egy ovf, az új helyen az bebootol, node specific dolgok bekér, és már éles is :)

A második fele az +1

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.

Szerintem egyáltalán nem kitálalhatatlan.
A MAC address-es (pl. enx00241dc10c9f) és az onboard-os (pl. eno1) az teljesen egyértelmű, a többi is lekérdezhető (pl. lspci).

Ezzel le is kérdezheted az összes infót:
udevadm info --query=all --name=/sys/class/net/eth0

"/sys/class/net/eth0" :D :D :D :D

A MAC addresses akkor vicces, mikor uj gephez ulsz oda. Egyebketn meg gepeljen ennyit, akinek hat anyja van.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Én kísérleti jelleggel a /usr-t tettem ro-ra. Már anyázok, pedig még csak egy hete van így. ;)

Hát ha nálad is /home -> /usr/home, akkor értem. Egyébként a frissítések miatt van ezzel gond.

Nem, nálam a /home az /home, csak az update-ek/telepítések döglenek meg minden alkalommal. :)

OK, ennek így még van is értelme. Nálam csak azért lett R/O, mert kíváncsi voltam, hány helyen okozhat problémát. :)
És persze mindig elfelejtettem, hogy nem lehet rá írni. :D

Én 96-ban vagy 97-ben tettem RO-ra. Lehet, hogy az első héten még anyáztam, de aztán megtanultam, hogy amikor nagy ritkán frissíteni kell, akkor kell egy mount /usr -o remount,rw

Ennek egyébként milyen előnye van azon kívül, hogy nem tudsz véletlenül se letörölni/felülírni egy rendszerfájlt?

Van akinél már ez is szempont. ;)
(pl. nálam :D)
Egyébként meg SELinux és társai jelenthetnének megoldást, de az meg nagyon macerás egyelőre, ráadásult mióta kiderültek érdekességek a fejlesztésében aktív részt vállaló NSA-ről...

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ő? :-)

Na jó, de ha amúgy is külön partíción van, ha rw is mountolod, amíg nem írsz rá nehezen lesz korrupt.

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á.

Elég, ha rw mountolod, máris ír rá:


root # dd if=x.img of=z.img
4000+0 records in
4000+0 records out
2048000 bytes (2.0 MB) copied, 0.034275 s, 59.8 MB/s
root # diff x.img z.img
root # mount -o loop x.img /mnt
root # umount /mnt
root # diff x.img z.img
Binary files x.img and z.img differ

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 ~]$ 

Idézet:
+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:

Idézet:
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

Ja, erről már el is felejtkeztem, olyan régen nem használtam

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)

Gondolom te sem abakuszt használsz. És az nem megoldás, olyanra megírni/fejleszteni, hogy elinduljon?


"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."

Végre valaki megkérdezi! \o/
Isten ments a systemd-től... Maradjanak a klasszikus initnél.
--
The Community ENTerprise Operating System

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

Fuszenecker_Róbert

:D Szerintem is fájóan hiányzik a többi kandidátusból a realtime audio és midi kezelés valamint a hatékony xlsx támogatás 64k sornál nagyobb táblázatokra. Én speciel abban szeretném a szolgáltatások listáját bekonfigurálni. Követelem, hogy írjanak újat!!4

Szerintem rt audio és midi is elég jó l14ux alatt :)
Mondjuk tr909 sequenceréhez hasonló midi-s cuccot még mondjuk nem találtam.


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

/o\

En pedig ruby es lua interpretereket akarok bele, mert en programozni is szeretnem az init rendszert! :-) #troll
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

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.

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

Nem, jó ez így, mert így csak a systemd csomagot kell eltávolítani, és viszi magával a teljes gnómot, nem kell egyesével vadászni minden g-vel kezdődő nevű csomagra egy telepítés után.

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.

Nem még, olyan linux-specifikus függőségei vannak (cgroups, udev, d-bus stb.), hogy várhatóan nem is fog menni. Ami viszont problémás, mert a Debian nem csak Linux, de többek közt FreeBSD disztró is (vagyis FreeBSD kernel felett GNU/Debian userspace)

BlackY

Mondjuk ugy remlik, D-Bus pont van BSD-re is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

d-bus van, valamilyen hal van, a systemd cgroups nelkul sem volna rosz, nemi feature veszetesseggel valoszinuleg megoldhato.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

hal != udev, es minden cucc kodjabol kibanyasztak a hal tamogatast sajnos. Pont a hal levaltasara szuletett (reszben) a systemd.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

> es minden cucc kodjabol kibanyasztak a hal tamogatast sajnos

Kiveve a KDE-t, ahol tudtommal van udeves, udiskes, upoweres, uanyamkinjas backend, meg halos.

Hat, az elkepzelheto. De szomoru vilag lesz az, amikor BSD-n csak a KDE lesz normalisan hasznalhato.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

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.)

OpenRC in Experimental
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ennek a váltásnak kifejezetten örülnék, de nem tűnik valószínűnek.