Devuan Jessie 1.0 Beta

Debian

2014 végén magukat veterán UNIX adminokként jellemzők egy csoportja a systemd ellen lépett fel. Akkor azt ígérték, hogy ha a Debian-ban a systemd leváltja a sysvinit-et, akkor forkolják a disztribúciót és sajátot hoznak létre. Tartották a szavukat és nekiálltak a Devuan nevű disztribúció összeállításának. Ugyan 2015-re ígérték, de úgy néz ki, hogy csak mostanra lesz belőle valaki kézzelfogható. A projekt bejelentette a Devuan Jessie 1.0 Beta elérhetőségét.

Részletek a bejelentésben. Teszteléshez lemezképfájlok itt találhatók.

( Tassadar v | 2016. 04. 30., szo – 08:17 )

(Valaki röviden összefoglalná, hogy mi a baj a systemd-vel?)

Szerintem sokaknak az nem tetszik, hogy kicsit szembe megy a UNIX egyik alapfilozófiájával: "do one thing and do it well". Bár ha onnan nézzük, hogy csak egy init rendszer, akkor a " do one thing" teljesül is, az hogy mennyire "well", mindenki döntse el maga.
Gyanítom az ellenszenv inkább az "apukájának" szól.

Ne nézzük onnan, hogy csak egy init rendszer, mert nem (csak) az. Szerintem ez a legnagyobb elvi tévedés a systemd-vel kapcsolatban: a fikázók is mindig azzal jönnek, hogy "milyen init rendszer már az ami a gummiboot-tól kezdve a udev-en keresztül mindent magába kebelez és így 'single point of failure' lesz és megbízhatatlan és hurr-durr".
Ebben lehet igazság, de a systemd-re szerintem inkább egy alapvető Linux szolgáltatásgyűjteményként érdemes nézni, ami az asztali rendszerekre való fejlesztést egységesebbé tudja tenni. Mivel ott van a legtöbb disztróban, ezért egyre jobban lehet rá építeni, egy egységes (D-Bus) felületen keresztül egy csomó alapvető szolgáltatást el lehet érni, ami korábban mind külön kis programcsomag volt, változó elérhetőséggel, api-val.

Az "apukájának" szóló teljesen érthetetlen gyűlöletet és mocskolódást pedig megtarthatják maguknak, akik ezt úton-útfélen kinyilvánítják, rendszerint nyomdafestéket kicsit sem tűrő stílusban. Hogy mennyire toxikus a közösség azt mindenki döntse el magának, de tény, hogy ez a pár szerencsétlen nyomi akik gúnyolják és néha a halálba küldik Lennart-ot nem vet jó fényt a közösségre.

Az a problema, hogy a systemd nem wrapperkent viselkedik, hanem mindent maga akar megoldani, akkor is, ha ez az adott kornyezetben nem kivanatos vagy nem jo otlet. Tulsagosan is robosztus, raadasul radkenyszeriti a sajat filozofiait fuggetlenul attol, hogy az neked kenyelmes-e vagy sem, illeszkedik-e a helyi infrastrukturaba vagy sem, es nagyon nehez lebeszelni ezekrol.
--
Blog | @hron84
Üzemeltető macik

Engem a "rád kényszerít" dolog érdekelne... egész pontosan mit kényszerít rád, mit kell máshogy csinálnod egy SysV-hez képest -- belevéve azt is, hogy valóban több szolgáltatást ad, amiket többé-kevésbé meg lehetett csinálni SysV-vel (és mellé telepítve kismillió másik wrapper-t, hogy utána a debug mindig jó móka legyen) csinálni, de amiket kb. nem vagy köteles használni.

Ps.: rejtett subscribe volt, mert az ilyen témák jók szoktak lenni :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

SysV eseten volt egy inditoscript, azt elinditottad es szolt. Azon belul kb azt csinaltal, amit akartal, ha az inditott service elokeszitest igenyelt, akkor azt, ha a service tobb darabbol allt, akkor tobb demont inditottam ugyanazon service keretein belul. Ezt most mar csak mindenfele wrapper scriptekkel lehet megtenni, ami valojaban semmivel sem jobb, mint a SysV scriptek voltak, csak van az egesz felett egy teljesen felesleges reteg. Az upstart meg az OpenRC megoldotta jol a fuggosegkezelest meg a szervizkovetest, cserebe pontosabb es jobb hibauzeneteket kaptam amikor a szerviz ugy dontott, megse indul el. Most meg lehet nyomozni a korlatozott tudasu journalctl-bol, ami - ahogy eszrevettem - mintha csak az stderr-t logolna, a stdout-ot nem, vagy forditva. Pedig sokszor mindket kimeneten van info.

Ugyanigy problema a forkolos demonok kezelese. A SystemD azt erolteti, hogy mindenkeppen eloterben futtasd az alkalmazast, es majd o lekoveti a folyamatot. Aztan ha ez valahogy megse jon ossze, akkor kinlodhatsz, mire reseteled a demon statuszat a SystemD allapottarolojaban, cserebe elvesztve az infokat. A forkolos szervizeknel legalabb biztos lehettem abban, hogy valahova biztos tesz egy logfajlt, ezeknel az uj, eloterben futo szervizeknel meg lehet talalgatni, hogy hova mennek a logok. Nincs meg a disztrokeszitokon/fejlesztokon az a kenyszer, hogy ertelmesen kezeljek a logokat, "fossuk ki az egeszet stdout-ra, aztan majd az uzemelteto sziv ezzel az egesszel".

Azt erzem, hogy a SystemD sokszor inkabb utban van a hibakereses/menedzseles soran, mintsem segitene a munkat. A SysV alapu init rendszerek legalabb probaltak nem utban lenni, ha nem is segitettek.
--
Blog | @hron84
Üzemeltető macik

Azon belul kb azt csinaltal, amit akartal, ha az inditott service elokeszitest igenyelt, akkor azt, ha a service tobb darabbol allt, akkor tobb demont inditottam ugyanazon service keretein belul.

Ha előkészítés/lebontás kell a service-nek, arra használható akárhány ExecStartPre/ExecStartPost. Ha egy service több démonból állt és azokat nem egy démon indítgatja, akkor az nem egy service, hanem két külön service, köztük valamilyen irányú függőséggel.

csak van az egesz felett egy teljesen felesleges reteg.

Leszámítva a rengeteg extra funkcionalitást (lásd fenn: biztonsági beállítások, erőforrás-menedzsment, process-menedzsment stb.), amit még kapsz.

mintha csak az stderr-t logolna, a stdout-ot nem, vagy forditva

Nézz szét az systemd-system.conf-ban (DefaultStandardOutput és DefaultStandardError), gyári beállításon mindkettőt el kéne kapnia. Nem lehet, hogy a unit valami shell scriptet indít, ami elnyeli vagy service szinten felülírod (StandardOutput=, StandardError=)?

Ugyanigy problema a forkolos demonok kezelese.

Erre van ott a Type=forking service típus (persze ennek feltétele, hogy az előkészítés tényleg az ExecStartPre-be kerüljön és az ExecStart tényleg már a forkoló démont indítsa), az egyetlen feltétele, hogy a PID filet (ha több processt forkol az ExecStart-ban indított process) hozza létre még a kilépés előtt.

A forkolos szervizeknel legalabb biztos lehettem abban, hogy valahova biztos tesz egy logfajlt, ezeknel az uj, eloterben futo szervizeknel meg lehet talalgatni, hogy hova mennek a logok.

Akkor most a systemd-vel van bajod, vagy az indított démonokkal? Meg milyen démon az, ami forkolva indítva fájlba logol, nem-forkolva meg (kötelezően) nem? (azzal mondjuk egyetértek, hogy iszonyat takony egy-egy service upstream unit fájlja)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha mar systemd.

Adott egy szgep ubuntuval, amelyik kb. 50%-ban elfelejti a modline-t a monitorhoz, es az 1600x1440 felbontas helyett ilyen 1024x768(?)-ban indul el.

Akartam irni egy systemd init scriptet, hogy futtasson le egy parancsot az X indulasa elott rogton, es az X indulasa utan. De nem sikerult.
Egy oraig matattam utana, de feladtam.
Annyira sekelyes infok vannak a neten rola, hogy nem eri meg a befektetest.

Ugyanilyen feladatot anno init scripttel sikerult meglepnem (~2006).

Szerintem tobb nagysagrendbeli nehezites lett.
Valakinek biztos egyszerubb tole az elete,
de az atlagnak nagyon magas ez a lec.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Felettem már írták az xorg.conf -ot (bár inkább xorg.conf.d-be).
Egyébként tippre (Ubuntuból még nem láttam systemd-set, csak a minden másból tudok kiindulni):
Két új service (legyenek mondjuk /etc/systemd/system/pre-displaymanager.service és /etc/systemd/system/post-displaymanager.service), mindkettő Depends=displaymanager.service (az indítja az X-et), az ExecStart-ba meg amit indítani akarsz, az egyik Before, a másik After, aztán attól függően, hogy mit csinálsz és minden X indításnál kell-e vagy csak az elsőnél, PartOf. Lehet játszani :)

Vagy ha egyszerűbben akarod: /etc/systemd/system/displaymanager.service.d/modeset.conf, benne egy ExecStartPre= (indítás előtti parancs) és egy ExecStartPost= (indítás utáni parancs).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Felettem már írták az xorg.conf -ot (bár inkább xorg.conf.d-be).

Nem tudom, hogy mostanaban probaltatok-e,
de kb. lehetetlen kikonyorogni az aktualis autogeneralt konfigot az X-bol.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Anno megoldottam mashogy. De majd legkozelebb plusz 10 percet raszanok.

De ha mar systemd. Mai elmeny:
beragadt systemd job miatt nem engedi a laptopot kikapcsolni.
Sehogy se megy (sudo poweroff, sudo shutdown -h now, sudo poweroff -f, sudo reboot, sudo reboot -f, sudo shutdown -r now).

Kb. a CUPS-sal van egy megbizhatosagi szinvonalon. Tisztara windows feeling.

Nem hiszem el, hogy 2016-ban a kikapcsolo gomb 10sec nyomasaval kellene egy laptopot aramtalanitani.

Szerintem egy oltari nagy szornyet teremtettek, ami mindenhonnan bugzik egy picit. Altalaban jo...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

legeloszor suspend job ragadt be, de aztan minden mas (miutan systemctl cancel-lal kivettem), akkor mindegy volt, hogy mi (poweroffnal ilyen 128 job volt beragadva, ekkor kapcsoltam ki inkabb. Mindenki turelme veges...)

CUPS-szal? Hat a nyomtatas igy 2016-ban meg mindig nem erte be a Windows-t.
Az en nyomtatom (HP laserjet), altalaban jo a nyomtatas, de ha grafika van (pl. epitesz terv), akkor van ugy, hogy 2.5ora, mire kijon a papir (de a vegen kijon!:). Ejszakara ott szoktam hagyni...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez a beragadas nalam is van. Sajnos azon a ponton mar nincs semmi terminalom, hogy kideritsem, mi ragad be, egyszeruen nem hajtodik vegre a kikapcsolas/ujrainditas. Windows-ban ugyanez problemamentesen megy. Bizonyosan nem driver hiba, mert korabban ennek semmi baja nem volt, menet kozben betegedett meg.
--
Blog | @hron84
Üzemeltető macik

Bizonyosan nem driver hiba, mert korabban ennek semmi baja nem volt, menet kozben betegedett meg.

Ami egyszer jó volt, azzal sose lesz semmi baj? Jártam már úgy a wifi-driverrel még linux alatt, hogy kernelfrissítés után nem működött. Lett is gyorsan egy AUR-csomag, ami a régi meghajtót telepíti. Persze a következő kernelverzióban ismét jó lett.

de kb. lehetetlen kikonyorogni az aktualis autogeneralt konfigot az X-bol.

Miért kellene? Neked csak a monitorhoz kell egy sor, ehhez nem kell egy egész komplett konfigot összerakni. Nekem is csak egy /usr/local/etc/X11/xorg.conf.d/radeon.conf fájlom van, amiben a kártya grafikus teljesítményét korlátozom (nem kell, hogy állandóan menjen a laptop ventilátora, meg amúgy se használom ki a képességeit). És megy minden: egér, billentyűzet, külső usb-s billentyűzet (bedugom, oszt' megy), "beépített" és "csatlakoztatott" kijelző, stb.

Na most a dbus ugye fuggetlen a systemdtol...ja varj, csak volt hiszen mar azt is bedaralta.
De akkor nezzuk:
Init: szerveres kornyezetben nincs szukseg systemd-re. A parhuzamositassal nem nyerunk idot, mikozben maga a szerver tiz percig tolti s biost, mindegy hogy utana nyerunk fel percet. Raadasul szerverben nincs annyi szolgaltatas, hogy kelljen, ha meg jo sok szolgaltatas kell, akkor VM vagz Docker, arra meg megint nem kell.
Syslog benyelese: a binaris log egy agyrem. Tovabbitani tavoli kozponti logszerverre es ott elemezni lehetetlen. Jo van syslog target, de akkor minek is nyeltebbe? Desktopon meg nem tudom hany felhasznalo hasznalja. Szerintem winen sem bogarasznak az emberek eventlogot. Tehat itt sincs letjogosultsaga, de legalabb mindent megnehezit, elfed, szetkur.
Utemezes: cron pont eleg jo. Ha meg tobb kell, akkor enterprisenal centralis utemezo, ami tobbet tud. Desktopon hanyan allitanak be utemezett feladatokat? Tehat letjogosultsag megint nulla, viszont ismet raeroszakolja magat mindenre.
Az egesz egy rakas fos, amit egy narcisztikus barom fejleszt.
Figyelem, ez meg az en velemenyem. Nem mas, mint velemeny. Nem akarok systemd junkiekat megserteni. :)

Nem ismerem az "apukáját", sem a munkásságát, csak azt látom, hogy egy csomóan ekézik az arcot. Ha annyira szar lenne a systemd, nem terjedhetett volna el szerintem. DE! Az a marha nagy szerencse, hogy választhatunk, azért akad még pár disztró, ahol nincs systemd. Ezért is üdvözlendő pl. a fent nevezett Devuan projekt.
Lehetne vitatkozni a létjogosultságán. Desktop felhasználóknak, akiket nem érdekel mi van a motorháztető alatt, csak gyorsan induljon, megfelelő.
Szerver felhasználáskor ugye ez nem lényeges, mivel nem sűrűn indítgatja az ember. No meg, aki szervert üzemeltet, feltételezem tud annyit, hogy kicserélje, vagy olyan disztrót használjon, amiben nincs.

Keresgelj egy kicsit a neten es fogsz talalni infokaf. Poettering egy megoszto figura, az Avahi, Pulseaudio etc. projektjei kapcsan is megkapta a jelzoket, hogy overbloated szarokat ir, es raadasul be sem fejezi, belekezd masba. Teny, hogy mindket funkciora leteznek az altala irtaknal kompaktabb szoftvercsomagok.

A systemd egy tipikusan linuxos NIH-projekt, kellett valami, ami kezeli a dependency-based bootingot, de lehetoleg nem mas rendszerbol jon. OS X tud mar ilyet, a Solaris SMF-je tobb, mint egy evtizede a piacon van, a NetBSD rc.d-rendszere dependencyt biztosan kezel, parhuzamos inditasra nem tudom, h. kepes-e. Linuxon volt a Canonical reszerol egy probalkozas az upstarttal, ami mindenkeppen jobb volt olyan szempontbol, h. nem volt egy monolitikus bloatware. Ja, meg a kernek parametereket se nyulja le maganak.

Egyik se volt eleg jo. A systemd erzesem szerint azert is tudott gyorsan elterjedni, mert Pottering mogott ott all a Redhat es tamogatta. Hogy a Redhatnek pontosan miert volt szuksege ilyen initrendszerre, az szamomra sem egeszen egyertelmu.

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

Init: szerveres kornyezetben nincs szukseg systemd-re.

Szükség nincs rá, de azért kényelmes az...

A parhuzamositassal nem nyerunk idot, mikozben maga a szerver tiz percig tolti s biost, mindegy hogy utana nyerunk fel percet.

A boot gyorsítása deklaráltan soha nem is volt cél, az egy pozitív mellékhatása a más szemléletmódnak. Egyrészt a párhuzamos indítás, az on-demand indítás (socket és D-Bus activation, aminek egyébként secu vonzata is van, ami nem fut állandóan, az nem lesz állandóan attack vector...), függőségek kezelése stb.

Raadasul szerverben nincs annyi szolgaltatas, hogy kelljen, ha meg jo sok szolgaltatas kell, akkor VM vagz Docker, arra meg megint nem kell.

Viszont van olyan, hogy egy szolgáltatás opcionálisan, a helyi konfiguráció miatt (!) függ egy másik szolgáltatástól [pár hete volt egy szál az iSCSI + lvm + systemd témában, ahol kifejezetten kontraproduktív volt az iSCSI init scriptje, mert próbált felkészülni egy ilyen opcionális függőségre]: egy triviális példa, ha AD-ből akarsz RADIUS-szal authentikálni. Megteheted, ott a kulcsrakész konfig a FreeRADIUS-hoz, kell hozzá egy futó winbind. És akkor lehet arról vitatkozni, hogy van-e értelme annak, hogy fusson-e egy Radius szerver, ha csak éppen autholni nem lehet róla, de legalább lehet vele beszélgetni a hálózaton... ez egy egész pontosan három soros konfig fájl kérdése systemd-vel. Anélkül?

És akkor még nem említettük a cgroup-támgatást. Amivel tudsz erőforrást szabályozni (az szerverre minek, ugye?), követni processeket (melyik melyik service-hez tartozik) és persze secu oldala is van a dolgoknak, chroot helyett egy elegáns mozdulattal letilthatsz útvonalakat a teljes szolgáltatástól.

Syslog benyelese: a binaris log egy agyrem. Tovabbitani tavoli kozponti logszerverre es ott elemezni lehetetlen. Jo van syslog target, de akkor minek is nyeltebbe?

Első mondatra: kivéve, hogy így strukturált, és lehet benne keresgélni. De nem muszáj, mert bár központi logszerverre továbbítani lehetetlen (kivéve, hogy a következő mondatban már írod, hogy pont nem az és lehet továbbítani Syslog-ba, ahonnan azt kezdesz vele, amit akarsz), és úgy dolgozod fel, ahogy akarod.

Szerintem winen sem bogarasznak az emberek eventlogot.

Egyébként elég baj az. Ha a desktopoknál maradunk (mert szervernél meg azért végképp illik bogarászni a logokat), valóban működik az zúzzuk be és toljuk vissza az image-t megoldás, de bőven belefér, hogy ezzel annyit értél el, hogy eltüntetted a naplót, amiből egyébként a tényleges hibára (legyen az HW hiba, vagy rossz SW) utalásokat ki tudnál szedni, és amikor legközelebb ugyanúgy előjön az észlelt hiba, nincs mihez nyúlnod.

Utemezes: cron pont eleg jo.

Persze, leszámítva, hogy mivel az nem használja ki a kernel Linux-specifikus dolgait (elsősorban: cgroups), nem tudsz vele erőforrásokat szabályozni és biztonsági következményei is lehetnek.

Desktopon hanyan allitanak be utemezett feladatokat?

Valóban inkább szerveres téma, de (a gép, ami előtt most ülök, gyakorlatilag hót-default desktop Süsü): 


> sudo ls /etc/cron.daily/
logrotate  packagekit-background.cron  suse-clean_catman         suse.de-backup-rpmdb   suse.de-cron-local  suse-do_mandb
mdadm      rsnapshot                   suse.de-backup-rc.config  suse.de-check-battery  suse.de-snapper     suse-texlive

Ebből az egyetlen, amit én állítottam be, az az rsnapshot. Ezen kívül: 


> systemctl status -t timer
systemd-readahead-done.timer - Stop Read-Ahead Data Collection 10s After Completed Startup
   Loaded: loaded (/usr/lib/systemd/system/systemd-readahead-done.timer; static)
   Active: active (elapsed) since szo 2016-04-23 21:44:20 CEST; 6 days ago
     Docs: man:systemd-readahead-replay.service(8)


systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
   Active: active (waiting) since szo 2016-04-23 21:15:10 CEST; 1 weeks 0 days ago
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)

Vagyis akadnak azért ütemezett feladatok...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A modern Linux-alapú rendszerekben rengeteg minden ellentmond a UNIX-filozófiának, kezdve magával a monolitikus kernellel. Vagy kezdve olyan filerendszerekkel, mint a btrfs. Vagy mondjuk olyan szoftverek, mint a Busybox. Vagy a gcc. Vagy éppen sok GNU eszköz. UNIX filozófiával érvelni baromira nem érv, eleve a UNIX nem tartja be a UNIX filozófiát.

mindha még bugzana itt-ott. Konkrétan amivel szívtam systemd kapcsán: nem válrja meg, hogy legyen hálózat, bármit csinálsz. A hálózatfüggő szolgáltatásokat, felcsatolásokat akkor is ráindítja és azok failelnek. Régi kernel mellett nem töltődik be a firmware az usb eszközbe.
Igaz ez nem debian volt, hanem raspbian és orange pi-re gányolt ubuntu.

( uid_16313 | 2016. 04. 30., szo – 08:34 )

Elég hülye nevet sikerült neki adniuk.

--
robyboy

( dejo v | 2016. 05. 01., v – 10:51 )

Kíváncsi lennek, hogy szerintetek tartósan fennmarad-e ez a disztribúció?
A legnagyobb terjesztések többsége systemd-re váltott.
Ezek után én úgy gondolom, hogy vagy általános lesz a systemd és sorra követi ennek bevezetését a terjesztések zöme, vagy kiderül az idők során, hogy több a probléma vele mint a haszna és akkor a nagyok is váltanak valami másra.
Ráadásul a Debian használók elég "hűségesek" és kitartanak mellette. Nem hiszem hogy azokat akik több mint tíz éve használnak Debiant, pont ez tántorítson el a kedvencüktől.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox