Product SiteDocumentation Site

Kapitel 9. Unixtjänster

9.1. System Boot
9.1.1. Systemds init-system
9.1.2. System Vs init-system
9.2. Fjärrinloggning
9.2.1. Säker fjärrinloggning: SSH
9.2.2. Använda grafiska fjärrskrivbord
9.3. Hantera behörigheter
9.4. Adminstrationsgränssnitt
9.4.1. Administrera över ett webbgränsnitt: webmin
9.4.2. Konfigurera paket: debconf
9.5. syslog Systemhändelser
9.5.1. Princip och mekanism
9.5.2. Konfigurationsfilen
9.6. Superservern inetd Super-Server
9.7. Schemalägga uppgifter med cron and atd
9.7.1. Format för crontab
9.7.2. Använda kommandot at
9.8. Schemaläggar asynkrona uppgifter: anacron
9.9. Kvoter
9.10. Säkerhetskopia
9.10.1. Säkerhetskopiera med rsync
9.10.2. Restoring Machines without Backups
9.11. Hot Plugging: hotplug
9.11.1. Introduction
9.11.2. The Naming Problem
9.11.3. How udev Works
9.11.4. Ett konkret exempel
9.12. Strömhantering: Advanced Configuration and Power Interface (ACPI)
Kapitlet täcker en rad grundläggande tjänster vanliga för många Unixsystem. Alla administratörer bör vara bekanta med dem.

9.1. System Boot

När du startar upp datorn visas många meddelanden för automatiska konfigurationer och initieringar på konsolen. Ibland kanske du vill ändra lite på hur denna fas fungerar, vilket innebär att du måste förstå dem. Det är själva syftet med detta avsnitt.
Först tar datorns BIOS kontroll över datorn, identifierar diskarna, läser in Master Boot Record och kör starthanteraren. Starthanteraren tar över, hittar kärnan på disken, läser och exekvererar den. Sedan initieras kärnan och börjar att leta efter samt montera partitionen som innehåller root-filsystemet, och sedan körs det första programmet — init. Ofta finns denna ”root-partition” och init på ett virtuellt filsystem som endast finns i RAM (därav dess namn ”initrams”, förr kallad ”initd” för ”initialization ram disk”). Filsystem läses in i minnet av starthanteraren, ofta från en fil på hårddisken eller från nätverket. Det innehåller det minsta som krävs av kärnan för att läsa in det riktiga root-filsystemet: det kan vara drivrutinsmoduler för hårddisken eller andra enheter för vilka systemet inte kan starta, eller oftare, initieringsskript och moduler för att sätta ihop raid-vektorer, öppna krypterade partitioner, aktivera LVM-volymer med mera. När väl root-partitionen är monterad ger initramfs kontrollen till den riktiga init, och maskinen återgår till standarduppstarten.
Startsekvens för en dator som kör Linux med systemd

Figur 9.1. Startsekvens för en dator som kör Linux med systemd

9.1.1. Systemds init-system

Den ”riktiga init-processen” tillhandahålls av systemd och en beskrivning följer i detta avsnitt.
Systemd exekverar flera processer som har ansvar för att hantera systemet: tangentbord, drivrutiner, filsystem, nätverk, tjänster. Det sker samtidigt som systemd också har en översikt över helheten och komponenters behov. Varje komponent beskrivs som en ”enhetsfil” (ibland mer); den generella syntaxen härleds från de allmänt använda syntaxen för ”*,ini”-filer med nyckel = värdepar grupperade mellan [avsnitt]. Enhetsfiler lagras under /lib/systemd/system/ och /etc/systemd/system/; de kommer i flera varianter, men vi fokuserar på ”services” och ”targets” här.
En ”service”-fil i systemd beskriver en process hanterad av systemd. Den innehåller ungefär samma information som ett gammeldags init-skript, men uttrycks i ett deklarativt (och mer enhetligt) sätt. Systemd hanterar merparten av de repetetiva uppgifterna (starta och stanna processen, kontrollera dess status, loggning, minska rättigheter och så vidare) och service-filen behöver endast fylla i det som är speciellt för processen. Här är till exempel service-filen för SSH:
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service
Det är, som du kan se, väldigt lite kod och bara deklarationer. Systemd ansvarar för att visa förloppsrapporter, hålla reda på processer och även om att starta om dem vid behöv.
En ”target”-fil i systemd beskriver ett systemtillstånd där en mängd tjänster ingår. Det kan jämföras med forna tiders körnivå (runlevel). En av målen är local-fs.target som gör att systemet, när målet uppfylts, kan anta att alla lokal filsystem är monterade och tillgängliga. Andra mål omfattar network-online.target och sound.target. Beroenden för ett mål kan listas i antingen target-filen ( raden Requires=) eller med en symbolisk länk till en systemtjänstfil i katalogen /lib/systemd/system/targetname.target.wants/. Till exempel innehåller /etc/systemd/system/printer.target.wants/ en länk till /lib/systemd/system/cups.service; systemd kommer därför att försäkra sig om att CUPS körs för att kunna uppfylla printer.target.
Eftersom unit-filer är deklarativa och inte skript eller program kan de inte köras direkt, och de tolkas bara av system; det finns därför flera verktyg som låter administratören interagera och kontrollera systemtillståndet för varje komponent.
Det första verktyget av det slaget är systemctl. Nä det körs utan argument listar det alla enhetsfiler kända för systemd (förutom de som har blivit inaktiverade) såväl som deras tillstånds. systemctl status ger en bättre överblick över tjänsterna, såväl som relaterade processer. Om givet namnet för en tjänst (som i systemctl status ntp.service), returnerar den ännu mer detaljer, såväl som de sista få loggraderna relaterade till tjänsten (mer om det senare).
Att starta en tjänst manuellt är så enkelt som att köra systemctl start tjänstenamn.service. Och, som du kanske gissat redan, stoppas tjänsten med systemctl stop tjänstenamn.service; andra kommandon omfattar reload och restart.
För att kontrollera huruvida en tjänst är aktiv (det vill säga huruvuda den startas automatiskt vid uppstart), använd systemctl enable tjänstenman.service (eller disable). is-enabled gör en statuskontroll av tjänsten.
En intressant egenskap i systemd är att den kommer med en loggningskomponent vid namn journald. Den är en komplettering till mer traditionella loggningssystem som syslogd, men lägger till intressanta egenskaper som en formell länk mellan en tjänst och meddelanden den skapar, och förmågan att fånga felmeddelanden skapade av dess initieringssekvens. Meddelandet kan visas senare, med lite hjälp från kommandot journalctl. Utan några argument kastar den ur sig alla loggmeddelanden som uppstått sedan systemstart.; men så används den sällan. För det mesta används det med en tjänstidentifierare:
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. --
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2
Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)
En annan användbar kommandoradsflagga är -f, som intstruerar journalctlatt visar nya meddelanden allt eftersom de skapas (i still med tail -f fil).
Om en tjänst inte fungerar som väntat så är det första steget att kontrollera att tjänsten verkligen körs med systemctl status; om den inte gör det, och meddelanden från kommandot inte är nog för att finna problemet, kontrollera loggarna som samlats av journald. Som exempel, anta att SSH-servern inte fungerar:
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago
  Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
 Main PID: 1188 (code=exited, status=255)

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. --
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2
Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# vi /etc/ssh/sshd_config
# systemctl start ssh.service
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago
  Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 1222 (sshd)
   CGroup: /system.slice/ssh.service
           └─1222 /usr/sbin/sshd -D
# 
Efter att ha kontrollerat tjänstens tillstånd (misslyckad) gick vi vidare med att kontrollera loggarna; de visar på ett fel i konfigurationsfilen. Efter att ha redigerat konfigurationsfilen och rättat felet startar vi om tjänsten, och verifierar sedan att den körs.

9.1.2. System Vs init-system

/etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.
Bland dem hittar du program som för att:
  • konfigurera konsolens tangentbord;
  • läsa in drivrutiner: de flesta av kärnmoduler läses in av själva kärnan då hårdvara identifieras; extra drivrutiner läses sedan in automatisk när motsvarande moduler listas i /etc/modules;
  • kontrollera integretitetn i filsystem;
  • montera lokala partitioner;
  • konfigurera nätverket;
  • montera nätverksfilsystem (NFS).
I detta steg tar init över och startar programmen aktiverade i standardkörnivå (vanligen körnivå 2). Det exekverar /etc/init.d/rc 2, ett skript som startar alla tjänster som listas i /etc/rc2.d/ och vars namn börjar med bokstaven ”S”. Det tvåsiffriga tal som fööjer har historiskt använts för att definiera den ordning för vilka tjänsterna skulle startas i, men nuförtiden använder startsystemen s insserv, som schemalägger allting automatiskt baserat på skriptens beroenden, Varje startskript deklarer därför villkoren som ska uppflyllas för att starta eller stoppa en tjänst (exempelvis om den måste starta innan eller efter en annan tjänst); init startar sedan upp dem i den ordning som krävs för att uppfylla villkoren. Den statiska namngivningen är därför inte längre använd (men de måsta alltid ha ett namn som börjar på”S” följt av två siffror och namnet på skriptet använt av beroendena). Vanligen startas grundtjänster först (som loggning med rsyslog, eller porttilldelning med portmap), följt av standardtjänster och det grafiska gränsnittet (gdm3).
Detta beroende baserad startsystem gör det möjligt att automatisera ordning, vilket skulle vara ansträngande om det var tvunget att ske manuellt, och det begränsar riskerna för mänskliga fel, eftersom schemaläggningen sker efter de parametrar som anges. En annan fördel är att tjänster kan startas parallellt när de är oberoende av varandra, vilket kan snabba upp startprocessen.
init skiljer på flera körnivåer så att det kan växla från den ena till den andra med kommandot telinit new-level. init exekverar omedelbart /etc/init.d/rc med den nya körnivån. Skripet kommer sedan att starta de saknade tjänsterna och stoppa de som inte längre önskas. För att göra detta, hänvisar den till innehållet i /etc/rcX.d (där X representerar den nya körnivån). Skript som börjar på ”S” (som i ”Start”) är tjänster som ska startas; De som börjar på ”K” (som i ”Kill”) är tjänster som ska stoppas. Skriptet startar ingen tjänst som redan var aktiv i tidigare körnivå.
System V använder i Debian fyra olika körnivåer:
  • Nivå 0 används endast tillfälligt medan datorn stänger av. Som sådan innehåller den många ”K”-skript.
  • Nivå 2, också känd som enanvändarläge, motsvarar system i degraderat läge; det innehåller bara grundläggande tjänster, och är avsett för underhållsåtgärder där interaktioner med vanliga användare inte är önskvärt.
  • Nivå 2 är nivån normal användning, vilket omfattar nätverkstjänster, ett grafiskt gränssnitt, användarinloggning med mera.
  • Nivå 6 liknar nivå 0, förutom att den används under nedstängningsfasen före en omstart.
Andra nivåer finns, speciellt då 3 till 5. Deras standardkonfiguration är att verka på samma sätt som för nivå 2, men administratören kan ändra dem (genom att lägga till eller ta bort skript i motsvarande kataloger för /etc/rcX.d) för att anpassa dem till speciella behov.
Startsekvensen för en dator som kär Linux med System V init

Figur 9.2. Startsekvensen för en dator som kär Linux med System V init

Alla skript i de olika katalogerna /etc/rcX.d är egentligen bara symboliska länkar — skapade vid paketinstallation med programmet update-rc.d —och pekar på aktuella skript som lagras i /etc/init.d/. Adminstratören kan finjustera de tillgängliga tjänsterna i varje körnivå genom att köra om update-rc.d med justerade parametrar. Manualsidan update-rc.d(1) beskriver syntaxen i detalj. Observera att ta bort alla symboiiska länkar (med parametern remove) inte är ett bra sätt att inaktivera en tjänst på. Istället bör du konfiguera den till att inte starta i önskade körniv (medan motsvarande anrop att stoppa den bevaras i den händelse att tjänsten köra i föregående körnivå). Eftersom update-rc.d har ett något rörigt gränssnitt kanske du föredrar att använda rcconf (från paketet rcconf) vilket ger ett mer lättanvänt gränssnitt.
Slutligen startar init kontrollprogram för flera olika virtuella konsoler (getty). Det visar en prompt, väntar på ett användarnamn och exekverar sedan login användare för att starta en session.