Tänased teemad runlevelid 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 – – 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 – 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