Tänased teemad init runlevelid systemd pisike harjutus Init – Kõige Tähtsam Deemon • Init on süsteemis Esimene Deemon • Initi ülesandeks on tegeleda kõigi teiste süsteemi tööks vajalike protsessidega Init – Kõige Deemonite Ema ● Init on esimene protsess mis alglaadimisel käivitatakse ● init on „daemon“ ehk taustaprotsess mis töötab kogu süsteemi töötamise ajal ● Kõik teised protsessid on initi „järglased“ -- init käivitab kõik teised protsessid (daemonid) otseselt või kaudselt ● init „lapsendab“ kõik „orvuks jäänud“ (hüljatud) protsessid ● Alglaadimisel käivitab kernel initi (selle programmi nimi on kerneli koodi jõuga sisse kirjutatud) ja satub paanikasse (kernel panic) kui vastav rakendus puudub. ● tüüpiliselt on init PID (process ID 1) Init – ajalooga tegelane ● Initi juured on sügaval klassikalises UNIXis ● Ilmus juba UNIX System III (75) ja System V (83) ● Klassikalist initit on kahes „maitsevariandis“ „BSD- stiilis“ (linuxitest kasutas Slackware) ja „SystemV-stiilis“ -- seda kasutas kuni viimase ajani enamik linuxeid ● Kuigi moodsad distributiivid on kõik enamasti migreerinud juba systemd peale ei lähe „SysV-init“ „stiilis“ asjad esialgu veel mitte kusagile ● Tagasiühilduvuse huvides sälitatakse vajalikke init osi Kuidas init oma tööd teeb ● runlevel – runlevel on eeldefineeritud süsteemi „olek“ – tüüpilises linuxi süsteemis on 7 runlevelit (0-6) – linuxi standardsed runlevelid: ● 0 Halt – süsteemi töö peatamine ● 1 Single-user – ühekasutajarežiim süsteemi haldamiseks ja konfigureerimiseks ● 2 – multiuser, ilma võrguteenusteta ● 3 – multiuser + networking – serveri kontekstis süsteemi normaalne töörežiim ● 4 – defineerimata, ise seadistatav – vaikimisi pole kasutusel võimalik defineerida oma olek ● 5 – runlevel 3 + GUI – graafiline kesskkonna tavaline töörežiim ● 6 -- „kuum“ restart – süsteemi taaskäivitamine „reboot“ Kuidas init oma tööd teeb ● init scripts – tavaline shelli script (sh või bash enamasti sh) – peab vastama teatud nõuetele ● käsurea parameetrid start | stop | reload | restart | force-reload | status ● peab suutma tagastada viisaka väljundkoodi (exit code) ● päises sisaldab infot sõltuvuste kohta (paha-paha!) – init scripte saab ka ise luua võttes aluseks mõne olemasoleva või kasutades linuxi dokumentatsiooniga kaasas olevat malli (linuxi keeles skeleton) Paneme 2 ja 2 kokku ● igal protsessil peab olema oma käivitusskript /etc/init.d kataloogis ● igale runlevelile vastab /etc/rc.dX kataloog ● iga kataloog sisaldab symlinke vastava runleveli jaoks käivitatavatele või seisatavatel init scriptidele ● rc.local on spetsiaalne skript roodu tarbeks ● rcS.d :( rc.dX süntaks ● symlinkid /etc/init.d/ skriptidele ● prefiks S tähendab protsessi käivitamist ● prefiks K tähendab protsessi seiskamist ● Number näitab prioriteeti – väiksema numbriga skript käivitatakse varem SysV-initi puudused ● Kuigi init on vana, hea ja ajahambale hästi vastu pidanud süsteem, on tal mõningaid puudusi – suhteliselt keerukas ja ebaintuitiivne on teenuste käivitamine „nõudmise“ peale – init skriptid ei ole eriti kasutajasõbralikud modifitseerimise ja haldamise suhtes – tihtipeale sõltub süsteemi haldur rakenduse looja loodud init-scriptist, mis on sõna otses mõttes KEHVASTI programeeritud – puudulik automaatne protsessihaldus – näiteks puudub mehhanism vajalike protsesside automaatseks taaskäivitamiseks, kui nad on nii-öelda „pange pannud“ – puudulik integratsioon udev seadmehalduriga. Puudub võimalus initit seadistada nii, et seadme ühendamisel käivitatakse automaatselt mõni vajalik daemon – ebamugav sõltuvuste haldus, iga protsess peab ise teadma oma sõltuvusi ja need on kirjeldatud protsessi init scriptis Alternatiivid SysV-initile ● Eelmisel slaidil toodud puudustest üle saamiseks on loodud mitmeid alternatiive – Upstart – loodi sysVinit asenduseks, aga suhteliselt ebaõnnestunud arhitektuur nullib head omadused ära. Kust leiame: Chrome OS – OpenRC – pole päris init vaid sõltuvuse-teadlik teenusehaldur, võimalik kasutada SysV-init täiendusena – launchd ja SystemStarter – OSX – systemd – see tegelane, kes erinevate „initite“ „sõjas“ tundub olevat võitjaks jäänud, enamik moodsaid linuxi distributiive on otsustanud systemd kasuks Systemd ● Systemd on Linux'i süsteemi ja teenuste haldur. ● Nagu init on ka tema Kõigi Deemonite Ema ● Kirjutatud C keeles, võimaldamaks suuremat töökiirust võrreldes eellastega, kuid sellest hoolimata on tagasiühilduv SystemV ja LSB käivitusskriptidega. ● Praktikas näeme, et enamik distributiive on mingid „hübriidid“, kus mingit osa süsteemseid protsesse hallatakse systemd abil ja tagasiühilduvuse huvides vahib meile vana hea SysV-init ka otsa Systemd ● Põhilised omadused – Agressiivne teenuste käivitamise paralleliseerimine – Sõltuvustepõhine teenuste käivitamine – Soklitel ja D-Bus'il põhinevalt vajadusepõhine teenuste käivitamine – Protsesside haldamine cgroup'ide abil – Kettajagude külgehaakimise vajadusepõhine haldamine – Protsessihaldus ja jälgimine (võimeline „pange pannud“ protsesse taaskäivitama) Systemd ● Arhitektuur – systemd on tarkvarapakett, mis koosneb ● mitmest protsessist (dameon) ● jagatud teekidest (libraries) ● käsureautiliitidest (administraatorile) ● arendaja utiliitidest (arendajatele) – tähtsamad komponendid ● systemd ● logind ● journald ● networkd ● user session ● D-Bus daemon – oluline nüanss – oskab töötada koos udeviga Kuidas systemd töötab ● Unit file – systemd alternatiiv init scriptile – realiseeritud deklaratiivses süntaksis (vs. imperatiivne nagu initis) – palju kergemini loetavam ja hallatavam – unit file ei piirdu ainult protsessi käivitusfaili rolliga vaid võib olla ka mõnda teist tüüpi, näiteks ● monteerimispunkt ● virtuaalse seadmefaili loomiseks ● sokli (socket) loomiseks Kuidas systemd töötab ● Näide systemd „unit“ failidest ● suffiksi järgi tehakse kindlaks uniti tüüp ● /etc/systemd/ administraatori mängumaa ● /usr/lib/systemd süsteemsed failid ● target „runleveli“ analoog ● wants sõltuvuste käitlemine Why systemd sucks? ● Breaking promises and immaturity – udevi allakugistamine (enam ei saa udevi eraldi kasutada) ● Stability Promises (and problems) – lots of bugs, instability, security holes ● Scope creep (bloat) – assimilates udev, mount, IP forwarding etc. – unneccessary and duplicating components: logging, web server(!) etc. Systemd vastuolud ● Bloatware? ● Ajab oma kombitsad sinna kuhu ei peaks? ● But devs like it! ● There is no escape! ● We still have hope! Abiks linke ja harjutus ● https://wiki.archlinux.org/index.php/Systemd#Ta rgets ● https://www.digitalocean.com/community/tutoria ls/understanding-systemd-units-and-unit-files ● https://wiki.archlinux.org/index.php/Init ● https://wiki.archlinux.org/index.php/Initscripts/ru nlevels ● https://fedoraproject.org/wiki/SysVinit_to_Syste md_Cheatsheet ● http://suckless.org/sucks/systemd .