Kapitel 3. Initialisering av systemet

Innehållsförteckning

3.1. En översikt av boot strap-processen
3.1.1. Steg 1: UEFI
3.1.2. Steg 2: startladdaren
3.1.3. Steg 3: mini-Debian-systemet
3.1.4. Steg 4: det normala Debian-systemet
3.2. Systemd
3.2.1. Systemd startas
3.2.2. Systemd-inloggning
3.3. Kärnans meddelande
3.4. Systemets meddelande
3.5. Systemhantering
3.6. Andra systemövervakare
3.7. Systemkonfiguration
3.7.1. Värdnamnet
3.7.2. Filsystemet
3.7.3. Initialisering av nätverksgränssnitt
3.7.4. Initialisering av molnsystem
3.7.5. Anpassningsexempel för att justera sshd-tjänsten
3.8. Udev-systemet
3.9. Initialisering av kärnmodulen

Det är klokt att du som systemadministratör vet ungefär hur Debian-systemet startas och konfigureras. Även om de exakta detaljerna finns i källfilerna för de installerade paketen och deras dokumentationer, är det lite överväldigande för de flesta av oss.

Här är en grov översikt över de viktigaste punkterna i initieringen av Debiansystemet. Eftersom Debiansystemet är ett rörligt mål, bör du läsa den senaste dokumentationen.

Datorsystemet genomgår flera faser av boot strap-processer från det att det slås på tills det erbjuder ett fullt fungerande operativsystem (OS) till användaren.

För enkelhetens skull begränsar jag diskussionen till den typiska PC-plattformen med standardinstallation.

Den typiska boot strap-processen är som en fyrstegsraket. Varje steg i raketen överlämnar systemkontrollen till nästa steg.

Naturligtvis kan dessa konfigureras på olika sätt. Om du till exempel har kompilerat din egen kärna kanske du hoppar över steget med mini-Debian-systemet. Så anta inte att detta är fallet för ditt system förrän du har kontrollerat det själv.

UEFI (Unified Extensible Firmware Interface) definierar en starthanterare som en del av UEFI-specifikationen. När en dator slås på är starthanteraren det första steget i startprocessen som kontrollerar startkonfigurationen och utifrån dess inställningar kör den angivna startladdaren för operativsystemet eller operativsystemets kärna (vanligtvis startladdaren). Startkonfigurationen definieras av variabler som lagras i NVRAM, inklusive variabler som anger filsystemets sökvägar till OS-laddare eller OS-kärnor.

En EFI-systempartition (ESP) är en datalagringsenhetspartition som används i datorer som följer UEFI-specifikationen. Den öppnas av UEFI-firmware när datorn slås på och lagrar UEFI-program och de filer som dessa program behöver för att köras, inklusive operativsystemets startladdare. (I äldre PC-system kan BIOS som lagras i MBR användas i stället)

Startladdaren är det andra steget i startprocessen som startas av UEFI. Den laddar systemkärnans avbildning och initrd-avbildningen till minnet och överlämnar kontrollen till dem. Denna initrd-bild är rotfilsystembilden och dess stöd beror på vilken startladdare som används.

Debian-systemet använder normalt Linux-kärnan som standardkärna för systemet. Initrd-avbildningen för den aktuella Linuxkärnan 5.x är tekniskt sett initramfs-avbildningen (initial RAM filesystem).

Det finns många olika boot loaders och konfigurationsalternativ.


[Varning] Varning

Lek inte med startladdare utan att ha ett startbart räddningsmedium (USB-minne, CD eller diskett) som skapats från bilder i grub-rescue-pc-paketet. Det gör att du kan starta ditt system även utan fungerande bootloader på hårddisken.

För UEFI-system läser GRUB2 först ESP-partitionen och använder UUID som anges för search.fs_uuid i "/boot/efi/EFI/debian/grub.cfg" för att bestämma partitionen i GRUB2-menyns konfigurationsfil "/boot/grub/grub.cfg".

Den viktigaste delen av GRUB2-menykonfigurationsfilen ser ut som följer:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

För den här delen av /boot/grub/grub.cfg betyder den här menyposten följande.


[Tips] Tips

Du kan göra det möjligt att se kärnans startloggmeddelanden genom att ta bort quiet i "/boot/grub/grub.cfg". För en bestående ändring, redigera raden "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" i "/etc/default/grub".

[Tips] Tips

Du kan anpassa GRUB-startbilden genom att ställa in variabeln GRUB_BACKGROUND i "/etc/default/grub" som pekar på bildfilen eller genom att placera själva bildfilen i "/boot/grub/".

Se "info grub" och grub-install(8).

Mini-Debian-systemet är det 3:e steget i startprocessen som startas av startladdaren. Det kör systemkärnan med dess rotfilsystem i minnet. Detta är ett valfritt förberedande steg i startprocessen.

[Notera] Notera

Termen "mini-Debian-systemet" har myntats av författaren för att beskriva det tredje steget i uppstartsprocessen i det här dokumentet. Det här systemet kallas vanligen initrd- eller initramfs-systemet. Ett liknande system i minnet används av Debians installationsprogram.

Programmet "/init" körs som det första programmet i detta rotfilsystem på minnet. Det är ett program som initierar kärnan i användarutrymmet och överlämnar kontrollen till nästa steg. Detta mini-Debian-system erbjuder flexibilitet i uppstartsprocessen, t.ex. genom att lägga till kärnmoduler före den huvudsakliga uppstartsprocessen eller genom att montera rotfilsystemet som ett krypterat filsystem.

  • Programmet "/init" är ett skalskriptprogram om initramfs skapades av initramfs-tools.

    • Du kan avbryta denna del av startprocessen för att få root shell genom att ange "break=init" etc. till kernel boot parameter. Se skriptet "/init" för fler avbrottsvillkor. Den här skalmiljön är tillräckligt sofistikerad för att du ska kunna göra en bra inspektion av maskinens maskinvara.

    • De kommandon som finns tillgängliga i detta mini-Debian-system är avskalade och tillhandahålls huvudsakligen av ett GNU-verktyg som heter busybox(1).

  • Programmet "/init" är ett binärt systemd-program om initramfs skapades av dracut.

    • Kommandon som är tillgängliga i detta mini-Debian-system är avskalade från systemd(1)-miljön.

[Observera] Observera

Du måste använda alternativet "-n" för mount-kommandot när du befinner dig på det skrivskyddade rotfilsystemet.

Det normala Debian-systemet är det 4:e steget i startprocessen som startas av mini-Debian-systemet. Systemkärnan för mini-Debian-systemet fortsätter att köras i den här miljön. Rotfilsystemet byts från det som finns i minnet till det som finns på den riktiga hårddiskens filsystem.

Init-programmet körs som det första programmet med PID=1 för att utföra den huvudsakliga startprocessen för att starta många program. Standardfilvägen för init-programmet är "/usr/sbin/init", men den kan ändras med kärnans startparameter "init=/path/to/init_program".

"/usr/sbin/init" är symlänkat till "/lib/systemd/systemd" efter Debian 8 Jessie (utgiven 2015).

[Tips] Tips

Det faktiska init-kommandot på ditt system kan verifieras med kommandot "ps --pid 1 -f".


[Tips] Tips

Se Debian wiki: BootProcessSpeedup för de senaste tipsen för att snabba upp uppstartsprocessen.

När Debian-systemet startar, startas /usr/sbin/init symlänkad till /usr/lib/systemd som init-systemprocessen(PID=1) som ägs av root(UID=0). Se systemd(1).

Systemd init-processen skapar parallella processer baserat på enhetskonfigurationsfilerna (se systemd.unit(5)) som är skrivna i deklarativ stil istället för SysV-liknande procedurell stil.

De processer som skapas placeras i individuella Linux-kontrollgrupper som får sitt namn efter den enhet de tillhör i den privata systemd-hierarkin (se cgroups och Avsnitt 4.7.5, ”Säkerhetsfunktioner i Linux”).

Enheter för systemläget laddas från "System Unit Search Path" som beskrivs i systemd.unit(5). De viktigaste är följande i prioritetsordning:

  • "/etc/systemd/system/*": Systemenheter som skapats av administratören

  • "/run/systemd/system/*": Runtime-enheter

  • "/lib/systemd/system/*": Systemenheter som installerats av distributionens pakethanterare

Deras inbördes beroenden specificeras av direktiven "Wants=", "Requires=", "Before=", "After=", ... (se "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" i systemd.unit(5)). Resurskontrollerna är också definierade (se systemd.resource-control(5)).

Suffixet i enhetens konfigurationsfil kodar deras typer som:

  • *.service beskriver den process som styrs och övervakas av systemd. Se systemd.service(5).

  • *.device beskriver den enhet som exponeras i sysfs(5) och udev(7) enhetsträdet. Se systemd.device(5).

  • *.mount beskriver den monteringspunkt för filsystemet som kontrolleras och övervakas av systemd. Se systemd.mount(5).

  • *.automount beskriver den automatiska monteringspunkten för filsystemet som kontrolleras och övervakas av systemd. Se systemd.automount(5).

  • *.swap beskriver den swap-enhet eller -fil som kontrolleras och övervakas av systemd. Se systemd.swap(5).

  • *.path beskriver den sökväg som övervakas av systemd för sökvägsbaserad aktivering. Se systemd.path(5).

  • *.socket beskriver det uttag som styrs och övervakas av systemd för uttagsbaserad aktivering. Se systemd.socket(5).

  • *.timer beskriver den timer som styrs och övervakas av systemd för timerbaserad aktivering. Se systemd.timer(5).

  • *.slice hanterar resurser med cgroups(7). Se systemd.slice(5).

  • *.scope skapas programmatiskt med hjälp av bussgränssnitten i systemd för att hantera en uppsättning systemprocesser. Se systemd.scope(5).

  • *.target grupperar andra enhetskonfigurationsfiler för att skapa synkroniseringspunkten under uppstarten. Se systemd.target(5).

Vid systemstart (dvs. init) försöker systemd-processen att starta "/lib/systemd/system/default.target (normalt symlänkat till "graphical.target"). Först dras några speciella målenheter (se systemd.special(7)) som "local-fs.target", "swap.target" och "cryptsetup.target" in för att montera filsystemet. Sedan dras även andra målenheter in genom målenhetsberoendena. För mer information, läs bootup(7).

systemd erbjuder funktioner för bakåtkompatibilitet. Startskript i SysV-stil i "/etc/init.d/rc[0123456S].d/[KS]name" tolkas fortfarande och telinit(8) översätts till begäran om aktivering av systemd-enheter.

[Observera] Observera

Emulerade runlevel 2 till 4 är alla symlänkade till samma "multi-user.target".

Det kärnfelmeddelande som visas på konsolen kan konfigureras genom att ställa in dess tröskelnivå.

# dmesg -n3

Under systemd loggas både kärn- och systemmeddelanden av journaltjänsten systemd-journald.service (a.k.a journald) antingen till en beständig binär data under "/var/log/journal" eller till en flyktig binär data under "/run/log/journal/". Dessa binära loggdata nås med kommandot journalctl(1). Du kan t.ex. visa loggen från den senaste uppstarten på följande sätt:

$ journalctl -b

Under systemd kan systemloggningsverktyget rsyslogd(8) avinstalleras. Om det installeras ändrar det sitt beteende för att läsa flyktiga binära loggdata (i stället för "/dev/log" som var standard före systemd) och för att skapa traditionella permanenta ASCII-systemloggdata. Detta kan anpassas med "/etc/default/rsyslog" och "/etc/rsyslog.conf" för både loggfilen och visningen på skärmen. Se rsyslogd(8) och rsyslog.conf(5). Se även Avsnitt 9.3.2, ”Logganalysator”.

Systemd erbjuder inte bara init-system utan även generiska systemhanteringsåtgärder med kommandot systemctl(1).

Tabell 3.6. Lista över typiska kommandoutdrag för systemctl

Operation Kommandosnuttar
Lista alla tillgängliga enhetstyper "systemctl list-units --type=help"
Lista alla målenheter i minnet "systemctl list-units --type=target"
Lista alla serviceenheter i minnet "systemctl list-units -typ=service"
Lista alla enheter i minnet "systemctl list-units --type=device"
Lista alla monteringsenheter i minnet "systemctl list-units --type=mount"
Lista alla uttagsenheter i minnet "systemctl list-sockets"
Lista alla timerenheter i minnet "systemctl list-timers"
Starta "$unit" "systemctl start $unit"
Stoppa "$enhet" "systemctl stop $unit"
Ladda om tjänstespecifik konfiguration "systemctl reload $unit"
Stoppa och starta alla "$enheter" "systemctl restart $unit"
Starta "$unit" och stoppa alla andra "systemctl isolate $unit"
Byt till "grafisk" (GUI-system) "systemctl isolera grafisk"
Växla till "multi-user" (CLI-system) "systemctl isolate multi-user"
Växla till "räddning" (CLI-system med en användare) "systemctl isolate rescue"
Skicka dödssignal till "$unit" "systemctl kill $unit"
Kontrollera om tjänsten "$unit" är aktiv "systemctl is-active $unit"
Kontrollera om tjänsten "$unit" är misslyckad "systemctl is-failed $unit"
Kontrollera status för "$unit|$PID|device" "systemctl status $unit|$PID|$device"
Visa egenskaper för "$unit|$job" "systemctl show $unit|$job"
Återställning misslyckades "$unit" "systemctl reset-failed $unit"
Lista beroendet av alla enhetstjänster "systemctl list-beroenden --all"
Lista enhetsfiler installerade på systemet "systemctl list-unit-files"
Aktivera "$unit" (lägg till symlänk) "systemctl enable $unit"
Inaktivera "$unit" (ta bort symlänk) "systemctl disable $unit"
Avmaskera "$unit" (ta bort symlänken till "/dev/null") "systemctl unmask $unit"
Mask "$unit" (lägg till symlänk till "/dev/null") "systemctl mask $enhet"
Hämta inställning för standardmål "systemctl get-default"
Ställ in default-target till "graphical" (GUI-system) "systemctl set-default graphical"
Ställ in default-target till "multi-user" (CLI-system) "systemctl set-default multi-user"
Visa arbetsmiljön "systemctl show-environment"
Ställ in "variabel" för jobbmiljö till "värde" "systemctl set-environment variable=value"
Oreglerad "variabel" i arbetsmiljön "systemctl unset-environment variable"
Ladda om alla enhetsfiler och daemons "systemctl daemon-reload"
Stäng av systemet "systemctl poweroff"
Stänga av och starta om systemet "systemctl reboot"
Stänga av systemet "systemctl suspend"
Lägg systemet i viloläge "systemctl hibernate"

Här kan "$unit" i exemplen ovan vara ett enskilt enhetsnamn (suffix som .service och .target är valfria) eller, i många fall, flera enhetsspecifikationer (globs i shell-stil "*", "?", "[]" med fnmatch(3) som kommer att matchas mot de primära namnen på alla enheter som för närvarande finns i minnet).

Kommandon som ändrar systemtillståndet i exemplen ovan föregås vanligtvis av "sudo" för att uppnå den administrativa behörighet som krävs.

Utdata från "systemctl status $unit|$PID|$device" använder punktens färg ("●") för att sammanfatta enhetens tillstånd på ett överskådligt sätt.

  • Vitt "●" anger ett "inaktivt" eller "avaktiverande" tillstånd.

  • Röd "●" indikerar ett "misslyckat" eller "felaktigt" tillstånd.

  • Grönt "●" indikerar ett "aktivt", "omladdande" eller "aktiverande" tillstånd.

Här är en lista över andra kommandoutdrag för övervakning under systemd. Läs relevanta manpages inklusive cgroups(7).


Monteringsalternativen för normala disk- och nätverksfilsystem anges i "/etc/fstab". Se fstab(5) och Avsnitt 9.6.7, ”Optimering av filsystem med hjälp av mount-alternativ”.

Konfigurationen av det krypterade filsystemet anges i "/etc/crypttab". Se crypttab(5)

Konfigurationen av RAID-programvara med mdadm(8) anges i "/etc/mdadm/mdadm.conf". Se mdadm.conf(5).

[Varning] Varning

Efter montering av alla filsystem rensas temporära filer i "/tmp", "/var/lock" och "/var/run" vid varje uppstart.

Molnsysteminstansen kan startas som en klon av "Debian Official Cloud Images" eller liknande bilder. För en sådan systeminstans kan personligheter som värdnamn, filsystem, nätverk, lokal, SSH-nycklar, användare och grupper konfigureras med hjälp av funktioner som tillhandahålls av cloud-init- och netplan.io-paketen med flera datakällor, t.ex. filer som placerats i den ursprungliga systemavbildningen och externa data som tillhandahålls under lanseringen. Dessa paket möjliggör deklarativ systemkonfiguration med hjälp av YAML-data.

Se mer på "Cloud Computing with Debian and its descendants", "Cloud-init documentation" och Avsnitt 5.4, ”Den moderna nätverkskonfigurationen för moln”.

Vid standardinstallation startas många nätverkstjänster (se Kapitel 6, Nätverkstillämpningar) som daemonprocesser efter network .target vid uppstarten av systemd. "sshd" är inget undantag. Låt oss ändra detta till on-demand start av "sshd" som ett exempel på anpassning.

Först inaktiverar du den systeminstallerade serviceenheten.

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

Systemet för aktivering av uttag på begäran i de klassiska Unix-tjänsterna skedde via superservern inetd (eller xinetd). Under systemd kan motsvarande aktiveras genom att lägga till enhetskonfigurationsfilerna *.socket och * .service.

sshd.socket för att ange ett uttag att lyssna på

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

sshd@.service som den matchande servicefilen för sshd.socket

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Ladda sedan om.

 $ sudo systemctl daemon-reload

Systemet udev tillhandahåller en mekanism för automatisk upptäckt och initialisering av maskinvara (se udev(7)) sedan Linux-kärnan 2.6. När kärnan upptäcker varje enhet startar udev-systemet en användarprocess som använder information från sysfs-filsystemet (se Avsnitt 1.2.12, ”procfs och sysfs”), laddar nödvändiga kärnmoduler med hjälp av modprobe(8)-programmet (se Avsnitt 3.9, ”Initialisering av kärnmodulen”) och skapar motsvarande enhetsnoder.

[Tips] Tips

Om "/lib/modules/kernel-version/modules.dep" av någon anledning inte genererades korrekt av depmod(8), kan det hända att moduler inte laddas som förväntat av udev-systemet. Kör "depmod -a" för att åtgärda det.

För monteringsregler i "/etc/fstab" behöver enhetsnoderna inte vara statiska. Du kan använda UUID för att montera enheter istället för enhetsnamn som t.ex. "/dev/sda". Se Avsnitt 9.6.3, ”Åtkomst till partition med hjälp av UUID”.

Eftersom udev-systemet är något av ett rörligt mål, lämnar jag detaljerna till andra dokumentationer och beskriver minimiinformationen här.

[Varning] Varning

Försök inte att köra långvariga program som t.ex. säkerhetskopieringsskript med RUN i udev-reglerna som nämns i udev(7). Skapa en korrekt systemd.service(5)-fil och aktivera den istället. Se Avsnitt 10.2.3.2, ”Montera händelsestyrd säkerhetskopiering”.

Programmet modprobe(8) gör det möjligt för oss att konfigurera Linux-kärnan från användarprocessen genom att lägga till och ta bort kärnmoduler. Udev-systemet (se Avsnitt 3.8, ”Udev-systemet”) automatiserar dess anrop för att underlätta initieringen av kärnmodulen.

Det finns moduler som inte är hårdvarumoduler och speciella drivrutinsmoduler för hårdvara, t.ex. följande, som måste förinstalleras genom att de listas i filen "/etc/modules" (se modules(5)).

Konfigurationsfilerna för modprobe(8)-programmet finns i katalogen "/etc/modprobes.d/", vilket förklaras i modprobe.conf(5). (Om du vill undvika att vissa kärnmoduler laddas automatiskt kan du överväga att svartlista dem i filen "/etc/modprobes.d/blacklist")

Filen "/lib/modules/version/modules.dep" som genereras av programmet depmod(8) beskriver modulberoenden som används av programmet modprobe(8).

[Notera] Notera

Om du har problem med modulinläsningen vid start eller med modprobe(8) kan "depmod -a" lösa problemen genom att rekonstruera "modules.dep".

Programmet modinfo(8) visar information om en modul i Linux-kärnan.

Programmet lsmod(8) formaterar innehållet i "/proc/modules" på ett snyggt sätt och visar vilka kärnmoduler som för närvarande är inlästa.

[Tips] Tips

Du kan identifiera exakt maskinvara i ditt system. Se Avsnitt 9.5.3, ”Identifiering av hårdvara”.

Du kan konfigurera maskinvaran vid start för att aktivera förväntade maskinvarufunktioner. Se Avsnitt 9.5.4, ”Konfiguration av hårdvara”.

Du kan förmodligen lägga till stöd för din speciella enhet genom att kompilera om kärnan. Se Avsnitt 9.10, ”Kärnan”.