Kapittel 9. Unix-tjenester

Dette kapitlet dekker en rekke grunnleggende tjenester felles for mange Unix-systemer. Alle administratorer bør være kjent med dem.

9.1. Systemoppstart

Når du starter datamaskinen, vises de mange meldinger på konsollskjermen mange automatiske oppsett og igangsettinger. Noen ganger kan du ønske å endre litt på hvordan dette stadiet fungerer, noe som betyr at du må forstå det godt. Det er hensikten med dette avsnittet.

På systemer med BIOS, må BIOS først ta kontroll over datamaskinen, igangsette kontrollere og maskinvare, oppdage diskene, og knytte det hele sammen. Deretter sjekker den hovedoppstartssporet (MBR) for første disk i oppstartsrekkefølgen og laster inn koden som er lagret der (første trinn). Denne koden starter så andre trinn og kjører til slutt oppstartslasteren.

Til forskjell fra BIOS er UEFI mer sofistikert mtp. at det vet om filsystemer og kan lese partisjonstabeller. Grensesnittet søker i systemlagringen etter en partisjon merket med en globalt unik identifikator (GUID) som markerer den som EFI-systemoartisjonen (ESP), der oppstartslasteren, oppstartshåndterere, UEFI-skall, og så videre, er å finne, og starter ønsket oppstartsletter. Hvis sikker oppstart (engelsk «Secure Boot») er påskrudd vil prosessen bekrefte at EFI-binærfilene er sannferdige og samsvarer med sin signatur, altså er grub-efi-arch-signed påkrevd for dette). UEFI-spesifikasjonen definerer også støtte for start i gammeldags BIOS-modus. Dette heter kompabilitetsstøttemodul (CSM). Hvis CSM er påskrudd vil den prøve å starte opp fra en enhets MBR. Dog er det mange nye systemer som ikke støtter CSM-modus.

I begge fall tar den egentlige oppstartslasteren over, finner enten den stafettbaserte oppstartslasteren eller kjernen på disken, laster og kjører den. Kjernen blir så initialisert, og begynner å søke etter, og montere partisjonen som inneholder rotfilsystemet, og kjører slutt det første programmet — init. Ofte er, faktisk, denne «rotpartisjonen» og denne init plassert i et virtuelt filsystem som bare finnes i RAM (derav navnet, «initramfs», tidligere kalt «initrd» for «initialisering RAM disk»). Dette filsystemet er lastet inn i minnet av oppstartslasteren, ofte fra en fil på en harddisk, eller fra nettverket. Den inneholder bare et minimum av det som kreves av kjernen for å laste det «sanne» rotfilsystemet: Dette kan være drivermoduler for harddisken, eller andre enheter uten noe systemet ikke kan starte opp, eller oftere, initialiseringsskript og moduler for montering av RAID-matriser, åpne krypterte partisjoner, for å aktivering av LVM, og så videre. Når rotpartisjonen er montert, overlater initramfs kontrollen til den virkelige init-en, og maskinen går tilbake til forvalgt oppstartsprosess.

9.1.1. Systemd init system

Den «ekte init-en» blir nå levert av systemd, og dette avsnitter dokumenterer dette init-systemet.

ALTERNATIV Andre systemer for oppstart

Denne boken beskriver oppstartssystemet brukt som forvalg i Debian siden Buster (som implementert av systemd-pakken), så vel som det tidligere forvalget, sysvinit, som er avledet og nedarvet fra System V Unix-systemer; det finnes også andre.

The upstart system is not part of Debian and mentioned here only for historical reasons. It was started by Ubuntu, was present in Debian Jessie, but was not the default; it came, in fact, as a replacement for sysvinit, and one of the tasks launched by upstart was to launch the scripts written for traditional systems, especially those from the sysv-rc package. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent.

openrc er en avhengighetsbasert tjenestehåndterer. Den ble opprinnelig skrevet for Gentoo-prosjektet, men den tar sikte på å ikke være spesifikk for noen systemer. Den beholder kompabiliteten med System V-initsystemet, og har støtte for oppstart, endring av kjøringsnivåer, starting og stopping av tjenester (i parallell), og å slå av maskinen.

Det er også andre systemer og andre driftsmodi, for eksempel runit, file-rc, eller minit, men noen av dem er relativt spesialiserte, foreldet, og ikke utbredt.

Figur 9.1. Oppstartssekvens med en datamaskin som kjører Linux med systemd

KONKRET TILFELLE Oppstart fra nettverket

I noen oppsett kan systemet settes opp til ikke å kjøre kode fra den fysiske maskinvaren men isteden hente tilsvarende blokk fra nettverket, noe som gjør det mulig å lage datamaskiner uten en harddisk, eller som blir installert helt på nytt ved hver oppstart. Dette alternativet er ikke tilgjengelig for alle maskintyper, og det krever vanligvis en egnet kombinasjon av fastvare og nettverkskort.

Oppstart fra nettverket kan bli brukt til å kjøre debian-installer eller FAI (se Seksjon 4.1, «Installasjonsmetoder»).

SIKKERHET Bruk av skall som init for å få root-rettigheter

Tradisjonelt er den første prosessen som starter init-programmet (som normalt er en symbolsk lenke til /lib/systemd/systemd). Imidlertid er det mulig å sende et init-valg til kjernen for å indikere et annet program.

Alle som er i stand til å få tilgang til datamaskinen kan trykke på Reset-knappen og starte den på nytt. Så, på oppstartslasterens ledetekst, er det mulig å sende init=/bin/sh-valget til kjernen for å få rottilgang uten å kjenne administratorens passord.

For å unngå dette kan du beskytte oppstartslasteren med et passord. Du kan også tenke på å beskytte tilgang til BIOS (en mekanisme for passordbeskyttelse er nesten alltid tilgjengelig). Uten den kan en ondsinnet inntrenger fortsatt starte maskinen med et flyttbart medium som har sitt eget Linux-system, som de deretter kan bruke til å få tilgang til data på datamaskinens harddisker.

Til slutt, være klar over at de fleste BIOS/EFI-implementasjon -er har et generisk passord tilgjengelig. I utgangspunktet er de tenkt for feilsøking for dem som har glemt passordet sitt. Disse passordene er nå offentlige og tilgjengelig på Internett (se selv ved å søke etter «generiske BIOS-passord» i en søkemotor). Alle disse beskyttelsene vil dermed hindre uautorisert tilgang til maskinen, men uten å være i stand til å fullstendig hindre det. Det er ingen pålitelig måte å beskytte en datamaskin på hvis angriperen kan få fysisk tilgang til den; de kan uansett demontere harddisker for å koble dem til en datamaskin under egen kontroll, eller stjele hele maskinen, eller slette BIOS-minnet for å tilbakestille passordet …

Systemd utfører flere prosesser, som har ansvaret for å sette opp systemet: tastatur, drivere, filsystemer, nettverk, tjenester. Den gjør dette mens du holder et overordnet oppsyn på systemet som helhet, og kravene til komponentene. Hver komponent er beskrevet av en «enhetsfil» («unit file») (noen ganger mer); den generelle syntaksen er avledet fra den ofte brukte «* INI-filer» syntaksen, med nøkkel = verdi-par gruppert mellom [seksjon]-topptekster. «Unit filer» er lagret i /lib/systemd/system/, og /etc/systemd/system/. De kommer i flere varianter, men her vil vi fokusere på «tjenester» og «mål».

En systemd «.service-fil» beskriver en prosess styrt av systemd. Den inneholder omtrent den samme informasjonen som i et gammelt stil init-skript, men uttrykt på en deklaratorisk (og mye mer konsis) måte. Systemd håndterer mesteparten av de repeterende oppgavene (som starter og stopper prosessen, sjekker statusen, loggingen, dropper privilegier, og så videre), og tjenestefilen trenger bare å fylle ut detaljene i prosessen. For eksempel, her er tjenestefilen for SSH:

[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

[Unit]-delen inneholder generisk info om tjenesten, som for eksempel dens beskrivelse og manualsideressurser, og dens relasjoner (avhengigheter og rekkefølge) til andre tjenester. [Service]-delen inneholder deklarasjoner som har med tjenestekjøring å gjøre (starting, stopping, dreping, omstart), mapper og oppsettsfil(er) brukt. Siste del [Install], har også generisk info om hvilke mål som skal installere tjenesten og i dette tilfellet alias som kan brukes istedenfor tjenestenavnet. Demonstrativt er det veldig lite kode der, kun deklarasjoner. Systemd tar hånd om visning av framdriftsrapporter, visning av prosesser, og faktisk også omstart av dem når det trengs. Syntaksen for disse filene er beskrevet i sin helhet fordelt på flere manualsider systemd.service(5), systemd.unit(5), systemd.exec(5), og så videre).

En systemd «.taget-fil» beskriver et systems tilstand, hvor et sett av tjenester som kjører. Det kan sees på som å tilsvare det gammeldagse kjørenivået. Ett av målene er local-fs.target; Når det er nådd, kan resten av systemet gå ut fra at alle de lokale filsystemer er montert og tilgjengelige. Andre mål inkluderer network-online.target og sound.target (en full liste over mål er å finne i systemd.special(7). Avhengigheter for et mål kan enten være oppført i målfilen (i Requires=-linjen), eller man kan bruke en symbolsk fil i /lib/systemd/system/targetname.target.wants/-mappen. For eksempel inneholder /etc/systemd/system/printer.target.wants/ en link til /lib/systemd/system/cups.service; systemd vil derfor sikre at CUPS kjører, for å nå printer.target.

Siden enhetsfiler er deklarative heller enn skripter eller programmer, kan de ikke kjøres direkte, og de blir bare tolket av systemd. Flere verktøy tillater derfor administratoren å samhandle med systemd for å kontrollere tilstanden til systemet, og for hver komponent.

Det første slikt verktøy er systemctl. Kjørt uten argumenter, viser den alle enhetsfiler som er kjent for systemd (bortsett fra de som er blitt deaktivert), samt deres status. systemctl status gir en bedre oversikt over tjenestene, samt relaterte prosesser. Hvis navnet på en tjeneste er gitt (som i systemctl status ntp.service), returnerer den enda flere detaljer, så vel som de få siste logglinjer knyttet til denne tjenesten (mer om det senere).

Å starte en tjeneste for hånd er en enkel sak, kjør systemctl start tjenestenavn.service. Som man kan gjette seg til, å stoppe tjenesten gjøres med systemctl stop tjenestenavn.service. Andre underkommandoer inkluderer reload og restart.

For å kontrollere om en tjeneste er aktiv (dvs. om den vil komme i gang automatisk ved oppstart), bruk systemctl enable tjenestnavn.service (eller disable). is-enabled åpner for å sjekke tjenestens status.

Et interessant trekk ved systemd er at den inneholder en loggingskomponent som heter journald. Den kommer som et supplement til mer tradisjonelle loggingssystemer, for eksempel syslogd, men den legger til interessante funksjoner som en formell kobling mellom en tjeneste og meldingene den genererer, og evnen til å fange opp feilmeldinger generert fra sin initialiseringssekvens. Meldingene kan vises senere, med litt hjelp fra journalctl-kommandoen. Uten noen argumenter, avgir den bare alle loggmeldinger som har oppstått etter oppstart av systemet. Det vil sjelden bli brukt på den måten. Mesteparten av tiden vil den bli brukt med en tjenesteidentifikator:

# journalctl -u ssh.service

May 20 19:28:59 debian systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
May 20 19:28:59 debian sshd[532]: Server listening on 0.0.0.0 port 22.
May 20 19:28:59 debian sshd[532]: Server listening on :: port 22.
May 20 19:28:59 debian systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
May 20 19:34:17 debian sshd[532]: Received signal 15; terminating.
May 20 19:34:17 debian systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server...
May 20 19:34:17 debian systemd[1]: ssh.service: Deactivated successfully.
May 20 19:34:17 debian systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
-- Boot 539ead7492344c2baddeea6bba357eee --
May 20 19:36:56 debian systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
May 20 19:36:56 debian sshd[532]: Server listening on 0.0.0.0 port 22.
May 20 19:36:56 debian sshd[532]: Server listening on :: port 22.
May 20 19:36:56 debian systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

En annen nyttig kommandolinjemarkør er -f, som instruerer journalctl til å fortsette å vise nye meldinger etter hvert som de er sendt ut (mye på samme måte som tail -f file).

Hvis en tjeneste ikke ser ut til å virke som forventet, er første skritt for å løse problemet å kontrollere at tjenesten faktisk kjører, med systemctl status. Hvis den ikke kjører, og meldingene er gitt av den første kommandoen ikke er nok til å diagnostisere problemet, sjekk loggene samlet av journald om denne tjenesten. For eksempel, anta at SSH-tjeneren ikke virker:

# 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
#

Etter å ha sjekket status på tjenesten (feilet), gikk vi videre til å sjekke loggene. De indikerer en feil i oppsettsfilen. Etter å ha endret på oppsettsfilen og fikset feilen, starter vi tjenesten, og kontroller så at den faktisk kjører.

FOR VIDEREKOMMENDE Andre typer enhetsfiler

Vi har bare beskrevet det mest grunnleggende som systemd kan gjøre i denne delen. Det tilbyr mange andre interessante funksjoner, og vi vil bare liste noen få her:

socket aktivering: en «socket» enhetsfil kan brukes til å beskrive et nettverk eller en Unix socket administrert av systemd. Dette betyr at socket-en vil bli opprettet av systemd, og selve tjenesten kan startes etter behov ved et faktisk tilkoblingsforsøk. Dette replikerer omtrent funksjonssettet til inetd. Se systemd.socket(5).
tidsur: en «tidsur»-enhetsfil beskriver hendelser som inntreffer med en fast frekvens, eller på bestemte tider. Når en tjeneste er knyttet til et slikt tidsur, vil den tilsvarende oppgaven bli utført når tiden er inne. Dette gjør det mulig å kopiere en del av cron sine egenskaper. Sjekk systemd.timer(5).
nettverk: enhetsfil av type «network» beskriver et nettverksgrensesnitt som gjør det mulig å sette opp slike grensesnitt, samt uttrykke at en tjeneste er avhengig av at et bestemt grensesnitt er oppe. Sjekk systemd.network(5).

9.1.2. System V init system

System V init system (som vi kaller init for korthets skyld) utfører flere prosesser, etter anvisning fra /etc/inittab-filen. Det første program som kjøres (som tilsvarer sysinit trinnet) er /etc/init.d/rcS, et skript som kjører alle programene i /etc/rcS.d/-mappen.

Blant disse finner du suksessivt programmer med ansvar for:

oppsett av konsolltastatur;
laste drivere: de fleste av kjernemodulene er lastet av kjernen selv i takt med at maskinvaren blir oppdaget; ekstra drivere blir deretter lastet inn automatisk når de korresponderende modulene er oppført i /etc/modules;
sjekke integriteten til filsystemene;
montere lokale partisjoner;
sette opp nettverket;
montere nettverk filsystemer (NFS).

DET GRUNNLEGGENDE Kildemoduler og valgmuligheter

Du har allerede lært at kjernemoduler kan innlastes under oppstart av systemet ved å legge dem til i /etc/modules eller en fil i /etc/modules-load.d/. Modules kan dog også ha valgmuligheter som kan settes opp ved å sette noen filer i /etc/modprobe.d/. Disse alternativene er definert med anvisninger som dette: options modulnavn opsjonsnavn=opsjonsverdi. Flere alternativer kan spesifiseres med en eneste anvisning om nødvendig.

Disse oppsettsfilene er beregnet for modprobe — programmet som laster en kjernemodul med dets avhengigheter (moduler kan faktisk påkalle andre moduler). For å listeopp alle alternativer for en modul kan du bruke modinfo -p modul-kommandoen. Beggene programmene finnes i kmod-pakken.

Når du har lært om systemd, tjenester og mål kan du bruke modprobe@modul.service for å laste inn kjernemodulene de avhenger av.

Etter dette trinnet tar init over, og starter programmene aktivert i standard kjørenivå (som vanligvis er driftsnivå 2). Den utfører /etc/init.d/rc 2, et skript som starter alle tjenestene som er oppført i /etc/rc2.d/, og der navnet begynner med bokstaven «S». Det tosifrede nummer som følger, har historisk blitt brukt til å definere i hvilken rekkefølge tjenestene måtte startes, men i dag brukes det standard oppstartssystemet insserv, som berammer alt automatisk basert på skriptenes avhengigheter. Hvert oppstartsskript melder om betingelsene som må være oppfylt for å starte eller stoppe tjenesten (for eksempel hvis det må starte før eller etter en annen tjeneste); så starter init dem i den rekkefølgen som oppfyller disse betingelsene. Skriptenes statiske nummerering tas derfor ikke lenger i betraktning (men de må alltid ha et navn som begynner med «S» etterfulgt av to sifre, og selve navnet på skriptet som brukes for avhengighetene. Vanligvis startes basistjenester (for eksempel logger med rsyslog, eller tildeling av port med portmap) først, fulgt av standardtjenestene og det grafiske brukergrensesnittet (gdm3).

Dette avhengighetsbaserte oppstartssystemet gjør det mulig å automatisere renummerering, som kan være ganske kjedelig hvis det må gjøres manuelt. Det begrenser risikoen for menneskelige feil, ettersom tidsrekkefølgen blir gjennomført i henhold til de parameterne som er angitt. En annen fordel er at tjenester kan startes parallelt når de er uavhengige av hverandre, noe som kan akselerere oppstartsprosessen.

init skiller mellom ulike kjørenivåer, så det kan bytte fra ett til et annet med telinit new-level-kommandoen. Umiddelbart vil init kjøre /etc/init.d/rc igjen med det nye kjørenivået. Dette skriptet vil da starte de manglende tjenestene, og stoppe de som ikke lenger er ønsket. For å gjøre dette viser det til innholdet i /etc/rcX.d (der X representerer det nye kjørenivået). Skript som begynner med «S» (som i «Start») er tjenester som skal i gang; de som starter med «K» (som i «Kill») er de tjenestene som skal stoppes. Skriptet starter ikke noen tjenester som allerede var aktive med det forrige driftsnivået.

Som standard bruker System V init i Debian fire forskjellige driftsnivåer:

Nivå 0 brukes bare midlertidig, mens maskinen slår seg av. Dermed inneholder den bare mange «K»-skripter.
Nivå 1, også kjent som enkeltbrukermodus, tilsvarer systemet i nedgradert modus; det inneholder bare basistjenester, og er beregnet for vedlikeholdsoperasjoner hvor samhandling med vanlige brukere ikke er ønsket.
Nivå 2 er nivået for normal drift, som omfatter nettverkstjenester, et grafisk grensesnitt, brukerpålogging, og så videre.
Nivå 6 er lik nivå 0, bortsett fra at det brukes under nedkoblingsfasen før en omstart.

Andre nivåer finnes, spesielt 3 til 5. Som standard er de satt opp til å operere på samme måte som nivå 2, men administratoren kan endre dem (ved å legge til eller slette skript i de tilsvarende /etc/rcX.d kataloger) for å tilpasse dem til spesielle behov.

Figur 9.2. Oppstartssekvens for en datamaskin som kjører Linux med System V init

Alle skriptene som inngår i de ulike /etc/rcX.d-kataloger er egentlig bare symbolske lenker - opprettet ved pakkeinstallasjon av update-rc.d-programmet - som peker til selve skriptet som er lagret i/etc/init.d/. Administratoren kan finjustere tjenestene som er tilgjengelige i hvert kjørenivå ved å kjøre update-rc.d igjen med justerte parametre. Manualsiden update-rc.d(1) beskriver syntaksen i detalj. Vær oppmerksom på at å fjerne alle symbolske lenker (med remove-parameteret) ikke er noen god metode for å deaktivere en tjeneste. I stedet bør du bare sette den opp til ikke å starte i det ønskede kjørenivået (mens man skjermer de samsvarende påkallinger for å stoppe den i det tilfelle tjenesten bruker det forrige kjørenivået. Siden update-rc.d har et noe innfløkt grensesnitt, kan du foretrekke å bruke rcconf (fra rcconf-pakken som gir et mer brukervennlig grensesnitt.

DEBIAN-RETNINGSLINJER Omstart av tjenester

Vedlikeholdsskripter for Debian-pakker vil noen ganger gi visse tjenester en omstart for å sikre at de er tilgjengelige, eller få dem til å ta hensyn til visse valgmuligheter. Kommandoen som styrer en tjeneste - tjeneste tjeneste operasjon - tar ikke driftsnivå i betraktning, forutsetter (feilaktig) at tjenesten brukes for øyeblikket, og kan dermed iverksette uriktige operasjoner (starter en tjeneste som bevisst var bevisst, eller stoppe en tjeneste som allerede er stanset, og så videre). Debian introduserte derfor invoke-rc.d-programmet: Dette programmet må benyttes av vedlikeholdsskripter til å kjøre skripter for å ta initiativet til tjenester, og det vil bare utføre de nødvendige kommandoer. Legg merke til at, i motsetning til vanlig bruk, er .d-suffikset her brukt i et programnavn, og ikke i en katalog.

Til slutt, init starter kontrollprogrammer for ulike virtuelle konsoller (getty). Den viser en ledetekst, venter på et brukernavn, og så kjører login bruker for å starte en økt.

ORDFORRÅD Konsoll og terminal

De første datamaskinene besto vanligvis av flere, svært store deler: Lagringskabinett og den sentrale prosessenheten var adskilt fra eksterne enheter som ble brukt av operatørene til å kontrollere maskinene. Dette var deler i et eget møbel, «konsollen». Dette begrepet ble beholdt, men betydningen har endret seg. Det har blitt mer eller mindre synonymt med «terminal», som er et tastatur og en skjerm.

Med utviklingen av datamaskiner, tilbyr operativsystemer flere virtuelle konsoller for å muliggjøre flere uavhengige økter på samme tid, selv om det er bare ett tastatur og en skjerm. De fleste GNU/Linux-systemer tilbyr seks virtuelle konsoller (i tekstmodus), som er tilgjengelige ved å skrive inn tastekombinasjonene Control+Alt+F1 til Control+Alt+F6.

I forlengelsen av dette, kan begrepene «konsoll» og «terminal» også referere til en terminalemulator i en grafisk økt (for eksempel xterm, gnome-terminal, eller konsole).