skoleni:sprava_uzivatelu_a_sluzeb

Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

skoleni:sprava_uzivatelu_a_sluzeb [2019/04/22 12:36] – [Služby] eskultetyskoleni:sprava_uzivatelu_a_sluzeb [2022/11/14 12:26] (aktuální) – upraveno mimo DokuWiki 127.0.0.1
Řádek 1051: Řádek 1051:
 Službou v Linuxe nazývame aplikáciu (proces) alebo súbor aplikácií tvoriacich logický celok, ktoré bežia na pozadí a typicky čakajú na príchodzie požiadavky, ktoré obsluhujú (toto však nie je nutná podmienka). Existujú rôzne subsystémy (príp. softvérové kolekcie) na vytváranie a správu služieb, ale na väčšine dnešných distribúcií túto úlohu plní **systemd**. My sme //systemd// spomenuli ako predka všetkých procesov s **PID == 1**. Okrem kľúčovej úlohy //init// systému, ktorý nainicializuje celý //user-space//, plní systemd zároveň úlohu správcu služieb a systému ako takého. Službou v Linuxe nazývame aplikáciu (proces) alebo súbor aplikácií tvoriacich logický celok, ktoré bežia na pozadí a typicky čakajú na príchodzie požiadavky, ktoré obsluhujú (toto však nie je nutná podmienka). Existujú rôzne subsystémy (príp. softvérové kolekcie) na vytváranie a správu služieb, ale na väčšine dnešných distribúcií túto úlohu plní **systemd**. My sme //systemd// spomenuli ako predka všetkých procesov s **PID == 1**. Okrem kľúčovej úlohy //init// systému, ktorý nainicializuje celý //user-space//, plní systemd zároveň úlohu správcu služieb a systému ako takého.
  
-===Systemd units===+====Systemd units====
 Systemd nespravuje iba služby. Podobne ako plánovač v kerneli pristupuje k procesom a vláknam transparentne a jednotne ich nazýva //tasks//, systemd dokáže spravovať aj sokety, mount pointy, časovače (''systemd.timer'' ako náhrada za ''cron''), targets (target by sa dal v kontexte systemd preložiť ako referenčný bod - //checkpoint// - pre iné služby, uvidíme neskôr), a ďalšie iné entity, ktoré združene nazývame **//units//**.\\ Systemd nespravuje iba služby. Podobne ako plánovač v kerneli pristupuje k procesom a vláknam transparentne a jednotne ich nazýva //tasks//, systemd dokáže spravovať aj sokety, mount pointy, časovače (''systemd.timer'' ako náhrada za ''cron''), targets (target by sa dal v kontexte systemd preložiť ako referenčný bod - //checkpoint// - pre iné služby, uvidíme neskôr), a ďalšie iné entity, ktoré združene nazývame **//units//**.\\
 //Pozn.//: všetky typy **//units//** rozoznáme podľa koncovky (//.service, .mount, .target, .timer//, atď.) //Pozn.//: všetky typy **//units//** rozoznáme podľa koncovky (//.service, .mount, .target, .timer//, atď.)
Řádek 1147: Řádek 1147:
   * ''systemctl disable <service>'' - zakáže naštartovanie služby po reštarte systému   * ''systemctl disable <service>'' - zakáže naštartovanie služby po reštarte systému
  
-Spustitelné služby se nachází v ''/usr/lib/systemd/system/'' a ''/etc/systemd/system/'' (tato cesta má vyšší prioritu).+===Manuálové stránky=== 
 +  * ''systemd.unit'' (5) 
 +  * ''systemd.service'' (5) 
 +  * ''systemctl'' (1) 
 + 
 + 
 +==== Konfiguračné súbory ==== 
 +Konfiguračné súbory služieb môžu byť systéme uložené hneď na niekoľkých miestach: 
 +  * ''/etc/systemd/system'' - lokálna perzistentná konfigurácia, sem patria všetky užívateľské služby s efektom na celý systém 
 +  * ''/run/systemd/system'' - dočasné konfigurácie pre dané systémové sedenie 
 +  * ''/usr/lib/systemd/system'' a ''/usr/local/lib/systemd/system'' - konfiguračné súbory, ktoré sa nainštalovali ako súčasť nejakého balíčku, **neodporúča** sa pracovať s týmito konfiguračnými súbormi priamo 
 + 
 +Občas ale potrebujeme konfiguráciu nainštalovaných služieb pozmeniť podľa našich požiadavkov. Ak teda nemáme pracovať s konfiguráciami v ''/usr'' priamo, mohli by sme vytvoriť našu vlastnú identickú kópiu danej služby a používať ju namiesto tej nainštalovanej, ale asi vidíme, že to nie je zrovna efektívny prístup. Systemd nám totiž poskytuje príkaz ''edit'', ktorý dokáže meniť exitujúce konfigurácie za pomoci špeciálneho súboru, ktorý sa vytvorí automaticky ako ''/etc/systemd/system/<sluzba>.d/override.conf''
 + 
 +My si to ukážeme na príklade s ''httpd''. Ako každá iná aplikácia, aj ''httpd'' môže skončiť abnormálne (napr. neoprávnený prístup do pamäte). V kontexte //systemd// by to znamenalo, že ''httpd'' prejde do chybného stavu a služba prestane bežať, čo spôsobí výpadok služby pre klientov. Odhalenie a odstránenie príčiny je nesmierne dôležité, ale za určitých okolností chceme, aby služba bežala naďalej, než zistíme, prečo v skutočnosti spadla. V manuálovej stránke nájdeme parameter ''Restart='', ktorý dovoľuje práve špecifikovať, za akých okolností sa má daná služba reštartovať
  
-Znovu načtení konfigurace jednotky: 
 <code> <code>
-systemctl reload unit+# najprv simulujme pad httpd bez zmeny nastaveni 
 +(root)$ pkill -SIGSEGV httpd 
 +(root)$ systemctl status httpd 
 +● httpd.service - The Apache HTTP Server 
 +   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) 
 +  Drop-In: /etc/systemd/system/httpd.service.d 
 +           └─override.conf 
 +   Active: failed (Result: core-dump) since Mon 2019-04-22 13:29:06 CEST; 1s ago 
 +     Docs: man:httpd.service(8) 
 +  Process: 7177 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=dumped, signal=SEGV) 
 + Main PID: 7177 (code=dumped, signal=SEGV) 
 +   Status: "Running, listening on: port 80"
 </code> </code>
  
-**TODO:**+Upravme teda nastavenie ''httpd'' tak, aby sa pri chybe reštartoval 
 +<code> 
 +(root)$ systemctl edit httpd 
 +[Service] 
 +Restart=on-abnormal 
 + 
 +# overme, ze override.conf sa vytvoril nasou zmenou 
 +(root)$ systemctl cat httpd 
 +... 
 + # /etc/systemd/system/httpd.service.d/override.conf 
 +[Service] 
 +Restart=on-abnormal 
 +... 
 + 
 +# teraz nastartujme httpd znovu a vyskusajme nasimulovat pad 
 +(root)$ systemctl restart httpd 
 +(root)$ pkill -SIGSEGV httpd 
 +● httpd.service - The Apache HTTP Server 
 +   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) 
 +  Drop-In: /etc/systemd/system/httpd.service.d 
 +           └─override.conf 
 +   Active: active (running) since Mon 2019-04-22 13:41:56 CEST; 1s ago 
 +     Docs: man:httpd.service(8) 
 + Main PID: 7846 (httpd) 
 +</code> 
 + 
 +===Manuálové stránky=== 
 +  ''systemd.unit'' (5) 
 +  ''systemd.service'' (5) 
 +  * ''systemctl'' (1) 
 + 
 +====Vytvárame systémovú službu==== 
 +V predchádzajúcej sekcii sme si na príklade ukázali ako zmeniť konfiguráciu existujúcej služby. V tejto sekcii si vytvoríme vlastnú službu úplne od začiatku. V našom prípade pôjde o systémovú službu a preto budú potrebné práva **roota** po celý čas. 
 + 
 +Vyrobme službu, ktorá nám zaloguje aktuálny dátum a nazvime ju **mydate.service** a vytvoríme príslušný súbor v ''/etc/systemd/system'' s nasledujúcim obsahom: 
 +<code> 
 +(root)$ cat /etc/systemd/system/mydate.service 
 +[Unit] 
 +Description=Ukazem datum 
 + 
 +[Service] 
 +Type=oneshot 
 +ExecStart=date 
 +</code> 
 + 
 +Parameter ''Type='' hovorí, o aký druh služby sa jedná, naša služba je jednorázová (angl.//oneshot//), teda vypíše dátum a skončí. Parameter ''ExecStart'' zase vraví, čo sa má vykonať, ak spustíme službu, v našom prípade sa zavolá ''date''. \\ 
 +K tomu, aby systemd vedel o našej novej službe je potrebné najskôr zabezpečiť, že súbor má správne SELinux práva, aby ho systemd mohol vôbec čítať. 
 +<code> 
 +(root)$ ls -lZ /etc/systemd/system/mydate.service 
 +-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 0 Apr 22 13:54 /etc/systemd/system/mydate.service 
 +(root)$ restorecon -FRvv /etc/systemd 
 +Relabeled /etc/systemd/system/mydate.service from unconfined_u:object_r:systemd_unit_file_t:s0 to system_u:object_r:systemd_unit_file_t:s0 
 +</code> 
 + 
 +Teraz už môžeme povedať systemd o našej novej službe, to sa robí príkazom ''daemon-reload''
 +<code> 
 +(root)$ systemctl daemon-reload 
 +(root)$ systemctl list-unit-files -t service mydate.service 
 +UNIT FILE      STATE    
 +mydate.service disabled 
 + 
 +</code> 
 + 
 +Po naštartovaní služby by sme mali vidieť zmenu v logu: 
 +<code> 
 +(root)$ systemctl start mydate 
 +(root)$ systemctl status mydate 
 +● mydate.service - Ukazem datum 
 +   Loaded: loaded (/etc/systemd/system/mydate.service; disabled; vendor preset: disabled) 
 +  Drop-In: /etc/systemd/system/mydate.service.d 
 +           └─override.conf 
 +   Active: inactive (dead) 
 + 
 +(root)$ journalctl -e -u mydate 
 +Apr 22 14:01:27 skoleni systemd[1]: Starting Ukazem datum... 
 +Apr 22 14:01:27 skoleni date[8755]: Mon Apr 22 14:01:27 CEST 2019 
 +Apr 22 14:01:27 skoleni systemd[1]: Started Ukazem datum. 
 +</code> 
 + 
 +Zároveň vidíme, že tým, že je naša služba nastavená ako //oneshot//, tak ihneď prejde do stavu **inactive**. Ak by sme chceli zachovať stav **active** aj keď proces už skončil, môžeme tak učiniť parametrom ''RemainAfterExit''
 +<code> 
 +(root)$ systemctl cat mydate.service 
 + 
 +# /etc/systemd/system/mydate.service 
 +[Unit] 
 +Description=Ukazem datum 
 + 
 +[Service] 
 +Type=oneshot 
 +ExecStart=date 
 + 
 +# /etc/systemd/system/mydate.service.d/override.conf 
 +[Service] 
 +RemainAfterExit=yes 
 +</code> 
 + 
 +Ďalej by sme chceli, aby sa naša služba púšťala vždy po štarte systému, tak ju skúsme povoliť, ako sme si ukazovali vyššie 
 + 
 +<code> 
 +(root)$ systemctl enable myservice 
 +The unit files have no installation config (WantedBy, RequiredBy, Also, Alias 
 +settings in the [Install] section, and DefaultInstance for template units). 
 +This means they are not meant to be enabled using systemctl. 
 +Possible reasons for having this kind of units are: 
 +1) A unit may be statically enabled by being symlinked from another unit'
 +   .wants/ or .requires/ directory. 
 +2) A unit's purpose may be to act as a helper for some other unit which has 
 +   a requirement dependency on it. 
 +3) A unit may be started when needed via activation (socket, path, timer, 
 +   D-Bus, udev, scripted systemctl call, ...). 
 +4) In case of template units, the unit is meant to be enabled with some 
 +   instance name specified. 
 +</code> 
 + 
 +Systemd nám hneď povie, že s našou konfiguráciou nie je niečo vporiadku. Chýba nám tam totiž sekcia ''[Install]'', ktorá je pre systemd kľúčová, pretože mu vraví, kedy našu službu môže spustiť (služby totiž môžu mať na sebe závislosti). Tu sa dostávame k téme **//targets//**. 
 + 
 +====Systemd target==== 
 +Systemd **target** je špeciálny druh jednotky, ktorý zoskupuje iné jednotky a vytvára tak určitý synchronizačný //checkpoint// pre služby, ktoré majú definované závislosti, napr. nemá význam spúšťat webserver, keď nemáme spustený **NetworkManager** a nemáme nakonfigurovanú sieť. Takáto závislosť sa potom prejaví v konfigurácii ''httpd'' nasledovne 
 +<code> 
 +$ systemctl cat httpd 
 +[Unit] 
 +... 
 +After=network.target remote-fs.target nss-lookup.target httpd-init.service 
 +... 
 +</code> 
 + 
 +Takýchto synchronizačných bodov je v systemd niekoľko a tie úplne najzákladnejšie korešpondujú s operačnými režimami sytému **SysV**, známymi ako //**runlevels**//. Hoci systemd rozoznáva aj //runlevels//, správame sa k nim jednotne ako aj k iným //targets//. Mapovanie medzi starými //runlevels// a systemd je pekne vidno [[https://wiki.archlinux.org/index.php/systemd#Mapping_between_SysV_runlevels_and_systemd_targets|tu]].\\ 
 +Vráťme sa teda k našej službe a nastavme ju ako službu spustiteľnú vrámci ''multi-user.target'' a službu povoľme: 
 + 
 +<code> 
 +(root)$ systemctl cat mydate 
 +... 
 +# /etc/systemd/system/mydate.service.d/override.conf 
 +[Service] 
 +RemainAfterExit=yes 
 + 
 +[Install] 
 +WantedBy=multi-user.target 
 + 
 +(root)$ systemctl enable mydate 
 +Created symlink /etc/systemd/system/multi-user.target.wants/mydate.service → /etc/systemd/system/mydate.service. 
 +(root)$ systemctl status mydate 
 +● mydate.service - Ukazem datum 
 +   Loaded: loaded (/etc/systemd/system/mydate.service; enabled; vendor preset: disabled) 
 +... 
 +</code>
  
-power management suspend, hibernate, poweroff...+===Manuálové stránky=== 
 +  ''systemctl'' (1) 
 +  * ''systemd.target'' (5)
  • Poslední úprava: 2022/11/14 11:12
  • (upraveno mimo DokuWiki)