Product SiteDocumentation Site

7.2. Vanlige prosedyrer

Formålet med denne delen er å presentere noen generelle tips om visse operasjoner som en administrator ofte må utføre. Disse prosedyrene vil selvsagt ikke fullt ut dekke alle mulige tilfeller, men kan tjene som utgangspunkt for de mer vanskelige sakene.

7.2.1. Oppsett av et program

Når du ønsker å sette opp en ukjent pakke, må du gå frem i etapper. Først bør du lese pakkeutviklerens dokumentasjon. Ved å lese /usr/share/doc/pakke/README.Debian får du nemlig muligheten til å lære om spesifikke grep som er gjort for å gjøre det enklere å bruke programvaren. Dette er noen ganger nødvendig for å forstå hvordan det avviker fra hvordan det opprinnelig oppfører seg, slik det er beskrevet i den generelle dokumentasjonen, for eksempel i howtos. Noen ganger har denne filen også detaljer over de mest vanlige feilene, slik at du skal unngå å kaste bort tid på vanlige problemer.
Deretter bør du se på programvarens offisielle dokumentasjon - se Seksjon 7.1, «Dokumentasjonskilder» for å identifisere de ulike tilgjengelige dokumentasjonskildene. Kommandoen dpkg -L pakke gir en liste over filene i pakken: Dermed kan du raskt identifisere tilgjengelig dokumentasjon (samt oppsettsfiler, som ligger i /etc/). dpkg -s pakke viser pakkens meta-data, og viser eventuelle anbefalte eller foreslåtte pakker. Der kan du finne dokumentasjon eller et verktøy som gjør oppsett av programvaren lettere.
Til slutt, oppsettsfilene er ofte selv-dokumenterte ved mange forklarende kommentarer som går i detaljer om mulige verdier for hver oppsettsinnstilling. Så mye at det noen ganger er tilstrekkelig å bare velge en linje blant de tilgjengelige for å aktivere dem. I noen tilfeller er eksempler på oppsettsfiler gitt i /usr/share/doc/package/examples/-mappen. De kan tjene som utgangspunkt for din egen oppsettsfil.

7.2.2. Holde kontroll med det bakgrunnsprosessene driver med

Å forstå hva en bakgrunnsprosess gjør er noe mer komplisert, siden den ikke kommuniserer direkte med administrator. For å sjekke at en bakgrunnsprosess faktisk fungerer, må du teste den. For eksempel, for å sjekke bakgrunnsprosessen Apache (nettjener), test den med en HTTP-forespørsel.
For å gjøre slike tester mulig, journalfører hver bakgrunnsprosess generelt alt den gjør, samt eventuelle feil som den møter, i det som kalles «loggfiler» eller «systemlogger». Loggene lagres i /var/log/, eller en av underkatalogene der. For å vite det nøyaktige navnet på en loggfil for hver bakgrunnsprosess, se dokumentasjonen. Merk: En enkel test er ikke alltid tilstrekkelig dersom det ikke dekker alle mulige brukstilfeller; noen problemer oppstår bare i spesielle tilfeller.
Som en forebyggende operasjon bør administratoren regelmessig lese de mest relevante tjenerloggene. En kan slik diagnostisere problemer til og med før de blir rapportert inn av misfornøyde brukere. Faktisk kan brukere noen ganger vente på at et problem skal skje gjentatte ganger over flere dager før de rapportere det. I mange tilfeller er det spesifikke verktøy for å analysere innholdet av de større loggfilene. Spesifikt finnes slike verktøy for vevtjenere (for eksempel analog, awstats og awffull for Apache), FTP-tjenere, tjenere for mellomlagre/hurtiglagre, brannmurer, e-posttjenere, DNS-tjenere, og selv for utskriftstjenere. Andre verktøy, slike som logcheck (et program diskutert i Kapittel 14, Sikkerhet), leser igjennom disse filene for å finne varsler som må behandles.

7.2.3. Be om hjelp på en e-postliste

Hvis dine ulike søk ikke har hjulpet deg å komme til roten av et problem, er det mulig å få hjelp fra andre, kanskje mer erfarne mennesker. Dette er nøyaktig formålet med e-postlisten og dens språkspesifikke søsken . Som med alle fellesskap, har det regler som må følges. Før du stiller spørsmål, bør du kontrollere at problemet ditt ikke allerede er dekket av nylige diskusjoner på listen eller av offisiell dokumentasjon.
Når disse to vilkår er oppfylt, kan du tenke på å beskrive problemet på e-postlisten. Inkluder så mye relevant informasjon som mulig: Ulike tester som er utført, dokumentasjon som er lest, hvordan du forsøkte å diagnostisere problemet, de berørte pakker eller pakker som kan være involvert, og så videre. Sjekk Debians feilsporingssystem (BTS, beskrevet i sidepanelet Seksjon 1.3.2.1, «Rapportering av feil») etter lignende problemer, og nevn resultatene av det søket, og gi linker til feil som er funnet. BTS starter på:
Jo mer høflig og presis du har vært, desto større er sjansen for å få et svar, eller i det minste en viss respons. Hvis du mottar relevant informasjon i privat e-post, vurder å sammenfatte denne informasjonen offentlig, slik at andre kan dra nytte av den. Dette gjør det mulig for listens arkiver, når de søkes gjennom ulike søkemotorer, å vise frem løsningen til andre som kanskje har det samme spørsmålet.

7.2.4. Rapportere en feil når problemet er for vanskelig

Hvis alle dine anstrengelser for å løse et problem feiler, er det mulig at det ikke er ditt ansvar å finne en løsning, men at problemet skyldes en feil i programmet. I dette tilfellet er riktige fremgangsmåte å rapportere feilen til Debian, eller direkte til oppstrømsutviklere. For å gjøre dette, isolér problemet så mye som mulig, og lag en minimal testsituasjon der problemet kan gjenskapes. Hvis du vet hvilket program som er den åpenbare årsaken til problemet, kan du finne den tilsvarende pakken ved hjelp av kommandoen dpkg -S aktuell_fil. Sjekk feilsporingssystemet (https://bugs.debian.org/pakke) for å sikre at feilen ikke allerede er rapportert. Deretter kan du sende din egen feilrapport, ved hjelp av reportbug-kommandoen. Ta med så mye informasjon som mulig, spesielt en fullstendig beskrivelse av de minimale testtilfellene som gjør det mulig for alle å gjenskape feilen.
Delene i dette kapitlet er hjelpemiddel til effektivt å løse problemer som de påfølgende kapitler kan få frem. Bruk dem så ofte som nødvendig!