Formålet med denne seksjonen er å presentere noen generelle tips om visse operasjoner som en administrator ofte må utføre. Disse prosedyrene vil selvsagt ikke uttømmende dekke alle mulige tilfeller, men de kan tjene som utgangspunkt i de mer vanskelige sakene.
7.2.1. Konfigurere et program
Når du ønsker å konfigurere en ukjent pakke, må du gå frem i etapper. Først må du lese pakkeutviklerens dokumentasjon. Å lese /usr/share/doc/package/README.Debian
vil faktisk åpne for å lære spesifikke grep for å forenkle bruken av programvaren. Det er noen ganger nødvendig for å forstå avvikene fra hva det opprinnelige programmet gjør, som beskrevet i den generelle dokumentasjonen, for eksempel i howtos. Noen ganger detaljerer også denne filen også de vanligste feilene, slik at vil unngå å kaste bort tid på vanlige problemer.
Deretter bør du se på programvares offisielle dokumentasjon - se
Seksjon 7.1, «Dokumentasjonskilder» for å identifisere forskjellige foreliggende dokumentasjonskilder.
dpkg -L package
-kommandoen gir en liste over filerne i pakken; Dermed kan du raskt identifisere tilgjengelig dokumentasjon (samt konfigurasjonsfiler, som ligger i
/etc/
).
dpkg -s package
viser pakkens meta-data og viser eventuelle anbefalte eller foreslåtte pakker. Der kan du finne dokumentasjon eller et verktøy som letter programvarekonfigurasjonen.
Til slutt, konfigurasjonsfiler er ofte selv-dokumenterte med mange forklarende kommentarer som detaljerer de forskjellige mulige verdier for hver konfigurasjonsinnstilling. Så mye at det noen ganger er nok å bare velge en linje for å aktivere blant de som er tilgjengelige. I noen tilfeller er eksempler på konfigurasjonsfiler gitt i /usr/share/doc/package/examples/
-katalogen. De kan tjene som grunnlag for din egen konfigurasjonsfil.
7.2.2. Å følge med i hva nissene gjør
Å forstå hva en nisse gjør er noe mer komplisert, siden den ikke kommuniserer direkte med administrator. For å sjekke at en nisse faktisk fungerer, må du teste den. For eksempel, for å sjekke Apache (nettjener) nissen, test den med en HTTP-forespørsel.
For å tillate slike tester, registrerer hver nisse 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 dens. For å vite det nøyaktige navnet på en loggfil for hver nisse, 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 serverlogger. De kan dermed diagnostisere problemer til og med før de blir rapportert inn av misfornøyde brukere. Faktisk kan brukere noen ganger vente på 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 loggfilerene. Spesielt finnes slike verktøy for nettjenere (for eksempel
analog
,
awstats
,
webalizer
for Apache), for FTP-servere, for tjenere for mellomlagre/hurtiglagre, for brannmurer, for e-posttjenere, for DNS-servere, og selv for utskriftstjenere. Noen av disse verktøyene opererer modulært, og tillater analyse av flere typer av loggfiler. Dette er tilfelle for
lire
. Andre verktøy, slike som
logcheck
(et program diskutert i
Kapittel 14, Security), skanner disse filene for å finne varsler som må behandles.
7.2.3. Å be om hjelp på en postliste
Hvis de ulike søkene ikke har hjulpet deg til å komme til kjernen av et problem, er det mulig å få hjelp fra andre, kanskje mer erfarne folk. Dette er nettopp hensikten med
debian-user@lists.debian.org
-postliste. Som med ethvert samfunn, har det regler som må følges. Før du stiller noen spørsmål, bør du sjekke at problemet ikke allerede er dekket av nyere diskusjoner på listen eller ved en offisiell dokumentasjon.
Når disse to vilkår er oppfylt, kan du forberede å beskrive problemet til epostlisten. Inkluder så mye relevant informasjon som mulig: Ulike tester som er utført, dokumentasjon som er konsultert, hvordan du forsøkte å diagnostisere problemet, de berørte pakker eller de som kan være involvert, etc. Sjekk Debian Bug Tracking System (BTS, beskrevet i sidepanelet
VERKTØY Bug sporingssystem (Bug tracking system (BTS) )) for 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 noen elementer av respons. Hvis du mottar relevant informasjon i privat e-post, vurder å sammenfatte denne informasjonen offentlig, slik at andre kan dra nytte av. Dette gjør det mulig for listens arkiver, når de søkes gjennom ulike søkemotorer, å vise løsningen for andre som kanskje har det samme spørsmålet.
7.2.4. Å raportere en feil når problemet er for vanskelig
Hvis alle dine anstrengelser for å løse et problem mislykkes, er det mulig at en løsning er ikke ditt ansvar, og at problemet skyldes en feil i programmet. I dette tilfellet er den riktige fremgangsmåten for å rapportere feilen til Debian eller direkte til oppstrøms utviklere. For å gjøre dette, isoler problemet så mye som mulig og lag en minimal test situasjon der det kan reproduseres. Hvis du vet hvilket program som er den åpenbare årsaken til problemet, kan du finne den tilsvarende pakken ved hjelp av kommandoen, dpkg -S file_in_question
. Sjekk Bug Tracking System-et (https://bugs.debian.org/package
) for å sikre at feilen ikke allerede er rapportert. Deretter kan du sende din egen feilrapport, ved hjelp av reportbug
-kommandoen, inkluder så mye informasjon som mulig, spesielt en fullstendig beskrivelse av disse minimale testtilfeller som vil tillate alle å gjenskape feilen.
Delene i dette kapitlet er et hjelpemiddel til effektivt å løse problemer som de følgende kapitler bringe frem. Bruk dem så ofte som nødvendig!