Systemd

Systemd - tai toksai Linux sistemų paleidimo, automatinio sukonfigūravimo ir loginimo paketas, kuris maždaug nuo 2015 metų yra tapęs faktiniu standartu. Savo veikimu Systemd primena senesnėse Windows versijose naudojamus ".ini" tipo konfigūracinius failus, o ir bendrai sistemos valdymą kiek priartina prie Windows. Taip jau yra, kad Systemd daugelis visiškai nepakenčia, o kiti gi sako, kad gal ir visai nieko daiktas, nes visgi kraunasi greičiau, nei SystemV tipo init skriptai, ypač dėl to, kad daugelis softo gali pasileidinėti ne nuosekliai, o paraleliai.

Nemenka dalis patyčių, kuri daroma iš Arch Linux vartotojų, yra susijusi su tuo, kad šioji sistema dar 2012 tapo pačia pirma Linux distribucija, kuri pradėjo tą Systemd naudoti. Kaip paaiškėjo, vietoje žadamo sistemos supaprastinimo, anuo metu gavosi tik dar papildomos komplikacijos, tačiau Arch Linux naudotojai tuo tiktai didžiavosi, taip sustiprindami jau ir anuomet anekdotinį savo statusą. Tuo tarpu netgi RedHat Linux, kuriam ir buvo kuriama Systemd, šitą daiktą pradėjo naudoti tik 2014, kai anas bent jau darbingu tapo.

Iki Systemd daugelis Linux distribucijų naudojo stebėtinai sėkmingą Upstart demoną, kuris buvo puikiai suderinamas su senąja init, atitiko visus UNIX standartus, bet kartu neturėjo problemų su naujos aparatūros pajungimu. Kodėl įvyko toksai staigus perbėgimas nuo Upstart prie Systemd - niekas iki šiol viešai negali paaiškinti.

Dėl Systemd atsiradimo iki šiolei vyksta didžiuliai šitstormai, o kai kurios didelės distribucijos išvis suskilo - pvz., nuo Debian atskilo Devuan, kurioje naudojama sysvinit kaip pagrindas, o papildomai yra dar ir runit ir OpenRC. Gan juntama dalis Linux vartotojų pasuko link įvairių BSD sistemų, kadangi šios kategoriškai laikosi KISS principų ir visokių tokių Systemd tipo įrankių nenaudoja, nes jie laikomi nepritaikytais perkonfigūravimui.

Na, plius dar ir tai, kad Systemd tiesiog banaliai neatitinka POSIX reikalavimų.

Systemd sandara ir veikimas

Systemd bent jau teoriškai pilnai atstoja visokius įprastus sisteminius demonus, tapdamas superdemonu, kuris ir paleidinėja kitas sistemas, ir konfigūruoja kernelio veikimo parametrus, ir suranda ir įjungia visokius įrenginius, ir taip toliau, pakeisdamas ir tokius demonus kaip atd bei cron, ir tokį seną superdemoną, kaip intetd.

Esminės dalys:

• systemd - pats tas systemd demonas
• systemctl - komanda, kuri leidžia gauti duomenis apie systemd veikimą ir tą systemd valdyti
• systemd-analyze - naudojamas visokiai šiaip informacijai apie veikimą gauti

Skirtingai nuo įprastos paleidimo kontrolės, systemd, paleisdamas programas, jas valdo ne pagal PID (t.y., proceso ID), o pagal kernelio cgroup identifikatorius, todėl daugeliui demonų įprastas pabėgimo mechanizmas, paremtas dvigubu forkinimu (t.y., paleistas demonas paleidžia savo kopiją, o tada pats išsijungia), nesuveikia, o systemd ir toliau kontroliuoja tokį atsilaisvinusį demoną. Tai reiškia, kad netgi jei demonas yra nesuderinamas su systemd, visvien jis gali būti ir įjungtas, ir išjungtas per systemd. Šitai duoda šiokį tokį suderinamumą su nesuderinamais senesniais demonų paleidimo ir stabdymo mechanizmais.

Papildomai su Systemd yra krūva visokių priedų - pvz., journald, logind, localed, homed, networkd, resolved ir panašiai.

Kažkokie pusgalviai, kurie kūrė visą šitą paketą, dar sugalvojo, kad vardan didesnio suderinamumo ir panašumo su Windows, čia reikia dar ir tokio system-bsod - t.y., BSOD generuojančio demono, kuris būtų skirtas tiesiog tam, kad pamėgdžiotų Windows turimą BSOD. Čia rimtas, ne Pipedijos bajeris, o realus dalykas.

Bendrai imant, į Systemd paketą sukišta tiek visokio neaišku kiek reikalingo šlamšto, o taip pat anksčiau buvusių normalių servisų, kad daugeliui kyla klausimų, ar kartais ne kokie nors narkomanai šitą daiktą darė, nes tai primena bandymą parašyti išvis naują visai paskirą OS iš kažkokių tai snarglių.

Esminės bendros Systemd problemos

Dažniausiai įvardinamos šios Systemd problemos:

• Klasikinių UNIX principų pažeidimas, ypač KISS pažeidimas. Įprastos sistemos naudodavo atskirus įrankius viskam, kas skirtinga, gi Systemd viskas suplakta į vieną krūvą, kur yra ir init sistema, ir logai, ir tinklų valdymas, ir įrenginių valdymas, ir išvis neaišku kas. Sistemos sudebuginti darosi beveik neįmanoma, o pati sistema tampa tiesiog monstriška.
• Kadangi praktiškai viskas sukišta į vieną didelį gremėzdą, visa Linux pasidaro nelanksti ir sunkiai pritaikoma kokiems nors specifiniams atvejams. Vien dėl to dalis distribucijų tiesiog atsisakė Systemd - nes paprasčiausiai neįmanoma pritaikyti kokiems nors atvejams, kurie kuo nors neįprasti.
• Vietoje įprastų tekstinių logų, kur galima viską peržiūrėti su grep ir less, atsirado dvejetainiai logai, kurie tipo esą taupo vietą (nors tie taupymai juokingi), bet logai tampa banaliai nepritaikyti peržiūrėjimui. Dar blogiau - jei logų rašymo metu įvyksta klaidų (pvz., koks demonas palūžta), tai išvis visas logas pasigadina.
• Sudebuginti Systemd paremtą sistemos pasileidimą darosi nepaprastai komplikuota - nes sistema keliasi paraleliai, o pranešimai apie įvykius eina ne tekstiniai, ir išvis gaunasi neaišku kas
• Banaliai prarasta dalis suderinamumo su daugeliu klasikinių senų System V tipo UNIX sistemų, nes sistemų pasileidimo mechanizmai visiškai skiriasi nuo senų UNIX standartų
• Systemd buvo panaudotas kaip įrankis, per kurį įvairių Linux distribucijų kūrėjai buvo priversti persimesti ar bent jau smarkiai priartėti prie nelabai gero RedHat Linux palaikymo, o pati RedHat kompanija staiga gavo smarkiai perteklinę įtaką
• Du esminiai Systemd devai, Lennart Poettering ir Kay Sievers pasaulyje pagarsėjo kaip ypatingo išskirtinumo dalbajobai, ignoravę visiškai lameriškas savo pridirbtas nesąmones, o paskui jomis kaltinę kitus.

Systemd suderinamumas su įvairiomis Linux

Dalis Linux distribucijų dabar Systemd naudoja kaip pagrindą, bet kitos gi distribucijos šito daikto baidosi ir nepanašu, kad artimiausiu metu persijungtų. Taigi, vien dėl Systemd naudojimo/nenaudojimo šiuo metu yra įvykęs didžiulis Linux pasaulio skilimas.

Systemd naudojančios Linux distribucijos

Štai tokios yra Systemd naudojančios Linux distribucijos:

• Arch Linux
• RedHat
• CentOS
• Debian
• Fedora
• Mint Linux
• SUSE Linux
• Open SUSE
• Ubuntu

Deja, šitame sąraše matosi didžiausios Linux distribucijos, tad galim tarti, jog dauguma praktiškai naudojamų Linux sistemų jau yra paremtos Systemd naudojimu.

Systemd išvengusios Linux distribucijos

Štai kai kurios žinomesnės Systemd atsisakiusios Linux distribucijos:

• Antix
• Artix
• Android
• Devuan
• Knoppix
• Slackware
• Gentoo
• Void Linux
• Alpine Linux
• Chimera Linux
• OpenWRT
• MX Linux

Šitame sąraše matosi kai kurios senos geros distribucijos, bet iš didžiųjų tėra Android, kuri išvis yra atskiras pasaulis. Taigi, atsilaikė prieš Systemd tik mažesni, geresnius developerius turėję gamintojai.

Pwnie security awards 2017

Nuo platesnio naudojimo pradžios 2015 metais, Systemd buvo atrastas nemenkas kiekis absurdiškai lameriškų skylių, kurios buvo tiesiog WTF lygio. Ir kiekvienos šitokios skylės atradimas baigdavosi tuo, kad ar koks nors Lennart Poettering, ar (kiek rečiau) kitas Systemd developeris Kay Sievers pradėdavo viską neigti ar aiškinti, kad čia patys tie bugų radėjai yra durni, ir kad čia reikia kokį nors kernelį taisyt, o ne prie Systemd kabinėtis.

Tai už tokį nuostabų bugų taisymą, juos ignoruojant ir bulšitinant kitus devus, Lennart Poettering 2017 metais gavo Pwnie security awards apdovanojimą už lameriškiausią tiekėjo elgesį, valdant sugumo skyles.

Visas apdovanojimo tekstas buvo toks, kad rimtų devų supratimu, tai kaip purvinu skuduru per veidą duoti, ir dar ne vieną kartą, o kokius penkis:

"Where you are dereferencing null pointers, or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number, there’s no chance that the CVE number will referenced in either the change log or the commit message. But CVEs aren't really our currency any more, and only the lamest of vendors gets a Pwnie!"

Nepaisant to, kad apsilažalinimas čia buvo neįtikėtinas, įvairių Linux distribucijų autoriai taip ir liko su tuo Systemd, nes akivaizdžiai suveikė paskandintų kaštų sindromas - tiek metų darius šūdą, dabar darosi gaila palikt. Tokiu būdu Systemd ir gyvuoja, ir matomai ilgokai gyvuos ir ateityje.

Linus Torvalds ir Systemd

Nors pats Linux sukūręs Linux Torvalds Systemd atžvilgiu yra gana neutralus ir sako, kad Linux galima paleidinėti ir valdyti gan įvairiai, konfliktas čia visgi irgi išsivystė - kai vienas iš dviejų esminių Systemd developerių Kay Sievers (per visą Linux bendruomenę pagarsėjęs pusgalvis, labiausiai žinomas tuo, kad 2012 sąmoningai įkišo į udev, t.y., kernelio draiverių posistemę bugą, o tada naglai reikalavo, kad čia kernelio devai taisytų kernelį, kad jis prisitaikytų prie udev bugų), 2014 paliko bugą ir systemd, ir dar tokį, kuris nukrešina kernelį, o kartu neleidžia gauti jokios debuginimo informacijos.

Tai po šiokio tokio susirašinėjimo Linus Torvalds viešai pareiškė, kad užblokuos pataisymų priėmimą ir iš šito devo, ir bendrai iš RedHat, o tarp kernelio developerių netgi pakilo idėja, kad įvesti į kernelį testinimą dėl Systemd ir aptikus, kelti kernelio paniką (t.y., tą kernelio režimą, kur jis dėl krovimosi klaidų išsijungia su pranešimu "kernel panic").

Kiek vėliau, jau 2016 metais, buvo atrasta ir tokių bugų, kurie parodė, jog Systemd lieka fundamentaliai nesaugus, t.y., jei tik pasileidžia nors viena neprivilegijuota programa, kuri elgiasi piktybiškai, pvz., ddosina Systemd per iškvietimus, tai Systemd tokios atakos atlaikyti negali ir pasikabina.

Reziumuojant apie Systemd

Kaip kai kurie sako - Systemd yra tokio RedHat developerio Lennart'o Poettering'o suorganizuotas backdooras, prakištas kaip esminis Linux valdymo paketas. Taigi, revoliucinis kompo hackas, kuris galėtų prilygti Ken Thompson sugalvotam trojanui.