From 05dd00db22cf7bc3355f74724f11cc288373ed4a Mon Sep 17 00:00:00 2001 From: Tom Rhodes Date: Fri, 20 Aug 2004 04:11:56 +0000 Subject: Add a freshly translated basics chapter. Submitted by: Aasmund Eikli (original version) --- no_NO.ISO8859-1/books/handbook/basics/chapter.sgml | 2384 ++++++++++++++++++++ 1 file changed, 2384 insertions(+) create mode 100644 no_NO.ISO8859-1/books/handbook/basics/chapter.sgml (limited to 'no_NO.ISO8859-1') diff --git a/no_NO.ISO8859-1/books/handbook/basics/chapter.sgml b/no_NO.ISO8859-1/books/handbook/basics/chapter.sgml new file mode 100644 index 0000000000..5d97293125 --- /dev/null +++ b/no_NO.ISO8859-1/books/handbook/basics/chapter.sgml @@ -0,0 +1,2384 @@ + + + + + + + Chris + Shumway + Rewritten by + + + + + Aasmund + Eikli + Translated by + + + + + + UNIX Basis + + + Introduksjon + basics + + Følgende kapitel vil gå over en rekke enkle kommandoer og + funksjonalitet i &os;-operativsystemet. Mye av dette materiellet + er relevant for alle varianter av &unix;. Om du har + erfaring med slikt fra før kan du skumme dette kapitellet. + Om du aldri har brukt &os; før, så er det en god ide å lese igjennom + materiellet. Du vil stå bedre utrustet etterpå. + + Etter at du har lest dette kapitellet vil du vite følgende: + + + + Hvordan bruke virtual consoles of + &os;. + + + Hvordan &unix; filrettigheter fungerer. + + + &os; filsystemlayout. + + + &os; diskorganisering. + + + Hvordan montere og demontere filsystemer. + + + Hva prosesser, daemons og signaler er. + + + Hva et shell er og hvordan du kan forandre standard loginmiljø. + + + Hvordan bruke teksteditorer + + + Hva devices og device nodes er. + + + Hva slags binært format som blir brukt i &os;. + + + Hvordan lese manualsider for mer informasjon. + + + + + + + Virtuelle konsoller og terminaler + virtual consoles + terminals + + &os; kan bli brukt på mange forskjellige måter. En av dem er å + gi kommandoer til en tekstterminal. Mye av fleksibiliteten og kraften i + et &unix; operativsystem når du bruker &os; på denne måten. Denne seksjonen + gir informasjon om hva terminaler og konsoller er, + og hvordan du kan bruke dem i &os;. + + + Konsollet + console + + Om du ikke har konfigurert &os; til å starte et grafisk miljø + når systemet starter opp, vil du få en login prompt etter at oppstartsskriptene + er ferdige med sine oppgaver. Du vil se noe som likner på: + + Additional ABI support:. +Local package initialization:. +Additional TCP options:. + +Fri Sep 20 13:01:06 EEST 2002 + +&os;/i386 (pc3.eksempel.no) (ttyv0) + +login: + + Beskjedene kan variere noe fra system til system, men mesteparten er likt. + De to siste linjene er hva vi er interessert i. Den nest siste ser omtrent + slik ut: + + &os;/i386 (pc3.eksempel.no) (ttyv0) + + Denne linja inneholder litt informasjon om systemet. Du ser på + et &os; konsoll som kjører på en Intel prosessor av + typen x86-arkitektur + + Dette er hva i386 betyr. Selv om du ikke kjører + &os; på en Intel 386 CPU, vil det fremdeles være i386. + Det er ikke typen prosessor, men hva slags prosessorarkitektur + som er vist her. + + . + Navnet på denne maskinen (hver &unix; maskin har et + navn) er pc3.eksempel.no, og du ser nå på + dets system console— 'sttyv0 + terminal. + + Den siste linjen er alltid: + + login: + + Dette er stedet hvor du må skrive inn ditt + ubrukernavn for å logge inn på systemet. Den neste + delen viser hvordan. + + + + + Innlogging + + &os; er et multibruker/multiprosessystem. Dette er det + vanlige navnet på et system som kan brukes av mange samtidig, som + igjen kan kjøre mange programmer samtidig på en enkelt maskin. + + Hvert eneste multibruker-system trenger en måte å skille + mellom brukere på. I &os; (og alle andre + &unix; operativsystemer) er dette løst på den måten at alle + brukere må logge inn på systemet før de kan faktisk + bruke det. Hver enkelt bruker har ett unikt navn (brukernavn) + og en personlig nøkkel (passord. &os; vil spørre om + begge før en bruker får lov til å gjøre noe som helst. + + + startup scripts + + Etter at &os; har startet opp og gjort seg ferdig med sine oppstarts- + skript + Oppstartsskrip er programmer som kjøres automatisk av &os; + når det starter. Deres normale funksjon er å konfigurere et miljø for alt + annet, samt starte tjenester som du har konfigurert til å kjøre i + bakgrunnen. + , vil systemet presentere deg med en prompt som spør om et + gyldig brukernavn: + + login: + + La oss i dette eksempelet gå utifra at vårt brukernavn er aasmund. + Skriv aasmund ved prompten og trykk Enter. Når + det er gjort får du en ny prompt som spør om et passord: + + login: aasmund +Password: + + Skriv inn aasmund's passord og trykk + Enter. Passordet blir ikke vist! + Dette er gjort av sikkerhetsgrunner. + + Om du skrev passordet ditt riktig, skal du nå være logget inn + i &os; og være klar til å prøve ut alle tilgjengelige kommandoer. + + Du skal nå se MOTD eller "message of the + day" etterfulgt av en kommandoprompt (en #, + $ eller %). Dette indikerer + at du har logget inn i &os; riktig. + + + + Flere konsoller + + Å kjøre &unix; kommandoer i ett konsoll er greit, men &os; + kan kjøre mange programmer på en gang. Å ha ett konsoll hvor kommandoer + kan skrives er litt lite når &os; kan kjøre dusinvis av dem på en + gang. Derfor finnes noe som heter virtuelle konsoller. + + &os; kan konfigureres til å presentere deg med mange forskjellige + virtuelle konsoller. Du kan gå ett til hvilket som helst annet virtuelt + konsoll ved å trykke et par taster på ditt keyboard. Hvert konsoll har + sin egen output-kanal og &os; sørger for at keyboard og monitor output + går der de skal mens du går imellom ett virtuelt konsoll til et annet. + + Spesielle tastekombinasjoner har blitt reservert av &os; for + å svitsje mellom konsoller + En rimelig teknisk og detaljert oversikt over &os; konsoll + og keyboarddrivere finnes på manualsidene &man.syscons.4;, &man.atkbd.4;, + &man.vidcontrol.1; og &man.kbdcontrol.1;. Disse vil ikke bli forklart her, + men om leseren er interessert, kan han/hun alltid ta en titt på manualsidene + for en mer detaljert forklaring av hvordan ting fungerer. + . Du kan bruke + AltF1, + AltF2, til + AltF8 for å svitsje + til et annet virtuelt konsoll i &os;. + + Mens du svitsjer fra ett konsoll til et annet tar &os; seg av + å lagre og gjenopprette skjermoutput. Resultatet er en illusjon + av at du har flere virtuelle skjermbilder og keyboards + som du kan bruke. Programmene du starter på ett virtuelt konsoll + stopper ikke å kjøre når det konsollet ikke er synlig. De fortsetter å kjøre + når du har svitsjet til et annet konsoll. + + + + + <filename>/etc/ttys</filename> Filen + + + En standard konfigurasjon av &os; vil starte med åtte + virtuelle konsoller. Dette er ikke en endelig innstilling og du kan + enkelt forandre din installasjon til å starte med flere eller færre. + Numrene og innstillingene til virtuelle konsoller finnes i + /etc/ttys filen. + + + Du kan bruke /etc/ttys filen til å konfigurere + virtuelle konsoller på &os;. Hver ukommenterte linje i denne filen + (linjer som ikke starter med en #) inneholder + innstillinger for en enkelt terminal eller virtuelt konsoll. Standard + versjon av denne filen som shippes med &os; inneholder ni virtuelle + konsoller og gjør åtte av dem tilgjengelige. Disse linjene starter med + ttyv: + + # name getty type status comments +# +ttyv0 "/usr/libexec/getty Pc" cons25 on secure +# Virtual terminals +ttyv1 "/usr/libexec/getty Pc" cons25 on secure +ttyv2 "/usr/libexec/getty Pc" cons25 on secure +ttyv3 "/usr/libexec/getty Pc" cons25 on secure +ttyv4 "/usr/libexec/getty Pc" cons25 on secure +ttyv5 "/usr/libexec/getty Pc" cons25 on secure +ttyv6 "/usr/libexec/getty Pc" cons25 on secure +ttyv7 "/usr/libexec/getty Pc" cons25 on secure +ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure + + For en detaljert forklaring på denne fila og alle innstillingene du kan bruke + vedrørende virtuelle konsoller, se &man.ttys.5; manualsiden. + + + + Single User Mode Konsoll + + En detaljert forklaring på hva single user mode er + finnes i . Det er viktig å huske på at + det kun er ett konsoll når du kjører &os; i single user mode. Det er ingen + virtuelle konsoller tilgjengelig. Innstillingene for single user mode konsollet + finnes også i /etc/ttys filen. Se etter linjen som starter + med console: + + # name getty type status comments +# +# If console is marked "insecure", then init will ask for the root password +# when going to single-user mode. +console none unknown off secure + + + Som kommentarene over console linja + indikerer, kan du editere denne linjen og forandre secure + til insecure. Om du gjør det vil &os; spørre om + root passordet når du starter i single user mode. + + Vær forsiktig hvis du forandrer til + insecure. Hvis du noegang glemmer + root passordet kan å starte i single user mode + bli interessant. Det er fremdeles mulig men kan være vanskelig + for noen som ikke er komfortabel med &os;'s oppstartsprosess og + hvilke programmer involvert i den. + + + + + + Rettigheter + UNIX + + Siden &os; er en direkte arving til BSD &unix; er det basert + på en del nøkkelkonsepter. Det første og viktigste er at &os; er + et multibruker operativsystem. Systemet kan håndtere flere brukere + som alle jobber samtidig på helt forskjellige ting. Systemet har + ansvaret for at alle brukerne har ca den samme tilgangen til CPU, + komponenter, minne og mye annet. + + + Siden systemet kan imøtekomme mange brukere har den et sett + med rettigheter på alt den har ansvar for. Dette inkluderer rettigheter + som hvem kan lese, skrive eller eksekvere en ressurs. Disse rettighetene + er lagret som tre oktetter, som igjen er brutt ned i tre biter: en for + eieren av filen, en for gruppa som fila tilhører og en for alle andre. + Nummerne ser slik ut: + + permissions + + file permissions + + + + + + Verdi + Rettighet + Katalogliste + + + + + + 0 + Ingen les, ingen skriv, ingen eksekver + --- + + + + 1 + Ingen les, ingen skriv, eksekver + --x + + + + 2 + Ingen les, skriv, ingen eksekver + -w- + + + + 3 + Ingen les, skriv, eksekver + -wx + + + + 4 + Les, ingen skriv, ingen eksekver + r-- + + + + 5 + Les, ingen skriv, eksekver + r-x + + + + 6 + Les, skriv, ingen eksekver + rw- + + + + 7 + Les, skriv, eksekver + rwx + + + + + + ls + + directories + + Du kan bruke kommandolinjeargumentet + til &man.ls.1; for å se en lang katalogliste som inkluderer en kolonne + med informasjon om en fil's rettigheter for eier, gruppe og alle andre. + For eksempel, en ls -l i en arbitrær katalog kan vise: + + &prompt.user; ls -l +total 530 +-rw-r--r-- 1 root wheel 512 Sep 5 12:31 minfil +-rw-r--r-- 1 root wheel 512 Sep 5 12:31 annenfil +-rw-r--r-- 1 root wheel 7680 Sep 5 12:31 epost.txt +... + + Det neste bildet viser hvordan den første kolonnen av ls -l + er brutt ned: + + -rw-r--r-- + + Den første (venstre> bokstaven forteller om denne filen er en vanlig fil, + en katalog, en spesiell "character device", en "socket", eller en annen pseuo-fil + komponent. I dette tilfellet indikerer - en vanlig fil. + De neste tre bokstavene i dette eksempelet, rw-, gir + rettigheter for eieren av fila. De neste tre bokstavene, r--, + gir rettigheter for gruppa fila hører til. De siste tre bokstavene, r--, + gir rettigheter for resten av verden. En strek betyr at rettigheten er skrudd av. + For denne fila er rettighetene satt så eieren kan lese og skrive til fila, gruppa + kan lese fila og resten av verden kan bare lese fila. Ifølge tabellen over vil + rettighetene for denne fila bli 644 hvor hvert nummer representerer + de tre delene av fila's rettigheter. + + Dette er vel og bra men hvordan kontrollerer systemet rettigheter + på komponenter? &os; ser på de fleste komponenter som en fil som programmer + kan åpne, lese og skrive til akkurat som en hvilken som helst annen fil. Disse + spesielle komponentfilene er lagret i /dev katalogen, + + Kataloger blir også sett på som filer. De har les, skriv og eksekver- + rettigheter. Eksekverbiten på en katalog har en litt annen mening enn + på filer. Når en katalog er merket eksekverbar betyr det at man kan gå inn + i den, dvs at det er mulig å cd (forandre katalog) inn i den. + Dette betyr også at inne i katalogen er det nå tilgang til filer (om rettighetene + på selve filene tillater det). + + Om man ønsker å liste filer i en katalog, må man ha leserettighet + på katalogen. Oom man ønsker å slette en fil som man vet navnet på, trenger + man å ha skriv og eksekverrettigheter på katalogen hvor + fila ligger. + + Det er flere rettighetsbiter enn rwx, men de er primært brukt i spesielle + tilfeller slik som "setuid" binærfiler og "sticky" kataloger. + Om du ønsker mer informasjon om filrettigheter og hvordan sette dem, les + &man.chmod.1; manualsiden. + + + + + + Tom + Rhodes + Contributed by + + + + + Symbolske Rettigheter + Permissionssymbolic + + Symbolske rettigheter er avogtil referert til som symbolske utrykk. Disse + bruker bokstaver istedet for oktale verdier for å gi rettigheter til filer + eller kataloger. Symbolske utrykk bruker (hvem) (handling) (rettighet) og følgende + verdier er tilgjengelige: + + + + + + Opsjon + Bokstav + Representerer + + + + + + (hvem) + u + Bruker + + + + (hvem) + g + Eier av gruppe + + + + (hvem) + o + Andre + + + + (hvem) + a + Alle (verden) + + + + (handling) + + + Legge til rettighet + + + + (handling) + - + Ta bort rettighet + + + + (handling) + = + Sette rettighet + + + + (rettighet) + r + Les + + + + (rettighet) + w + Skriv + + + + (rettighet) + x + Eksekver + + + + (rettighet) + t + "Sticky bit" + + + + (rettighet) + s + Sett UID eller GID + + + + + + Disse verdiene blir brukt med &man.chmod.1; kommandoen + akkurat som før, men med bokstaver istedet for nummer. For eksempel + kan du bruke følgende kommando til å blokkere andre brukere fra å + ha tilgang til FIL: + + &prompt.user; chmod go= FIL + + En kommaseparert liste kan brukes når mer enn en forandring på + en fil gjøres. For eksempel, følgende kommando vil ta vekk gruppe og + verden skriverettighet på FIL, + og deretter legger den til eksekverrettighet for alle: + + &prompt.user; chmod go-w,a+x FIL + + + + + + + Katalogstruktur + directory hierarchy + + &os; katalogstrukturen er fundamental for å forstå + hvordan systemet fungerer i praksis. Den viktigste konseptet + er rotkatalogen, /. Denne katalogen er den første + monterte katalogen ved oppstart og den inneholder basesystemet + som trengs for å klargjøre operativsystemet for multibruker. + Rotkatalogen inneholder også monteringspunkter for alle andre + filsystemer du tenker på å montere. + + Et monterinspunkt er en katalog hvor andre filsystemer kan bli + "satt på" rotfilsystemet. Vanlige monteringspunkter inkluderer + /usr, /var, + /mnt, og /cdrom. + Disse katalogene er som regel referert til linjer i /etc/fstab + fila. /etc/fstab er en tabell over forskjellige + filsystemer og monteringspunkter systemet har til rådighet. + Mesteparten av filsystemene i /etc/fstab er + montert automatisk ved oppstart fra skriptet &man.rc.8;. Om et filsystem + har opsjonen , vil det ikke bli montert automatisk. + Se &man.fstab.5; manualsiden for mer informasjon om formatet på + /etc/fstab filen og hvilke innstillinger tilgjengelige. + + En komplett beskrivelse av filsystem-hierakiet finnes i + &man.hier.7;. Her følger en liten oversikt over de mest + vanlige katalogene. + + + + + + + Katalog + Beskrivelse + + + + + / + Rotkatalogen på filsystemet. + + + + /bin/ + Brukerprogrammer for både singelbruker og multibruker- + miljøer. + + + + /boot/ + Programmer og konfigurasjonsfiler brukt under + oppstart av operativsystemet. + + + + /boot/defaults/ + Standard "bootstrapping" konfigurasjonsfiler; se + &man.loader.conf.5;. + + + + /dev/ + Komponentnoder; se &man.intro.4;. + + + + /etc/ + Systemkonfigurasjonsfiler og skript. + + + + /etc/defaults/ + Standard systemkonfigurasjonsfiler; se &man.rc.8;. + + + + /etc/mail/ + Konfigurasjonsfiler for mail transport agents slik som + &man.sendmail.8;. + + + + /etc/namedb/ + named konfigurasjonsfiler; se + &man.named.8;. + + + + /etc/periodic/ + Skript som kjøres daglig, ukentlig, og månedtlig, + via &man.cron.8;; se &man.periodic.8;. + + + + /etc/ppp/ + ppp konfigurasjonsfiler; se + &man.ppp.8;. + + + + /mnt/ + Tom katalog som normalt blir brukt av administratorer for + å montere temporære filsystemer. + + + + /proc/ + Process file system; se &man.procfs.5;, + &man.mount.procfs.8;. + + + + /root/ + Hjemmekatalog for root + kontoen. + + + + /sbin/ + Systemprogrammer og administrasjonsprogrammer for både + enbruker og flerbrukermiljøer. + + + + /stand/ + Programmer brukt i enbrukermiljø, "standalone". + + + + + /tmp/ + Temporære filer, som regel et &man.mfs.8; + minnebasert filsystem (innholdet av /tmp er som regel IKKE + beholdt om systemet restarter). + + + + + /usr/ + De fleste brukerprogrammer og applikasjoner. + + + + /usr/bin/ + Vanlige programmer, programmeringsverktøy og applikasjoner. + + + + /usr/include/ + Vanlige C include filer. + + + + /usr/lib/ + Arkiveringsbiblioteker. + + + + + /usr/libdata/ + Forskjellige applikasjonsdatafiler. + + + + /usr/libexec/ + System daemons & systemprogrammer (eksekvert av andre + programmer). + + + + /usr/local/ + + Lokale eksekverbare filer, biblioteker, osv. Også + brukt som standard destinasjon for &os; portstreet. + Inne i /usr/local skal den generelle + layout'en i &man.hier.7; for /usr bli + brukt. Et par unntak er man katalogen, som ligger under + /usr/local istedetfor under + /usr/local/share og ports- + dokumentasjonen som er i share/doc/port. + + + + + /usr/obj/ + Arkitekturspesifikkt tre som blir opprettet ved bygging av + /usr/src treet. + + + + /usr/ports + &os; ports collection (om installert). + + + + /usr/sbin/ + System daemons & systemprogrammer (eksekvert av brukere). + + + + /usr/share/ + Arkitekturløse filer. + + + + /usr/src/ + BSD og/eller lokale kodefiler. + + + + /usr/X11R6/ + X11R6 eksekverbare filer, biblioteker, osv + (om installert). + + + + /var/ + Logging, temporære filer, spool-filer, osv. + + + + + + /var/log/ + Forskjellige typer systemloggfiler. + + + + /var/mail/ + Mailboksfiler for brukere. + + + + /var/spool/ + Forskjellige printer og postspooling-kataloger. + + + + + /var/tmp/ + Temporære filer som blir beholdt ved systemrestart. + + + + /var/yp + NIS maps. + + + + + + + + + + + Diskorganisering + + Den minste organiseringen som &os; bruker for å finne filer + er filnavnet. Det skilles mellom store og små bokstaver i filnavn, noe + som betyr at readme.txt og README.TXT + er to forskjellige filer. &os; bruker ikke etternavnet + (.txt på en fil for å finne ut om filen er et + program, et dokument eller noen annen form for data. + + Filer er lagret i kataloger. En katalog kan inneholde ingen filer + eller mange hundre av dem. En katalog kan også inneholde andre kataloger + noe som lar deg bygge opp et hieraki av kataloger inni hverandre. + Dette gjør det mye lettere å organisere data. + + Filer og kataloger er referert til ved å gi filen eller katalogen + et navn, fulgt av en slash, /, + som igjen er fulgt av et annet katalognavn om nødvendig. Hvis du har + katalog foo, som inneholder katalog + bar, som igjen inneholder filen + readme.txt, så blir det fulle navnet, eller + stien til filen: + foo/bar/readme.txt. + + Kataloger og filer er lagret i et filsystem. Hvert filsystem + inneholder en katalog øverst i treet som kalles + rotkatalogen for det filsystemet. Denne rotkatalogen kan + så inneholde andre kataloger. + + Så langt er dette antakeligvis likt andre operativsystemer du har + brukt. Det er et par forskjeller, for eksempel, DOS bruker + \ for å skille mellom filer og katalognavn, mens MacOS + bruker :. + + &os; bruker ikke bokstaver for å angi drev + eller andre drevnavn i stien. Du kan ikke skrive + c:/foo/bar/readme.txt på &os;. + + Istedenfor er ett filsystem markert som rotfilsystem. + Rotfilsystemet's rootkatalog er referert til som /. + Hvilket som helst annet filsystem er så montert (mountet) + under rotfilsystemet. Uansett hvor mange disker du har på ditt &os; + system så ser hver katalog ut som at den er en del av samme disk. + + Si at du har tre filsystemer kalt A, + B, og C. Hvert filsystem har + en rotkatalog som inneholder to andre kataloger. Disse er kalt + A1, A2 (og det samme for de andre: + B1, B2 og + C1, C2). + + Kall A for rotfilsystemet. Hvis du brukte kommandoen + ls for å se på innholdet til denne katalogen + ville du se to underkataloger, A1 og + A2. Katalogtreet + ser ut som dette: + + / + | + +--- A1 + | + `--- A2 + + Et filsystem må bli montert på en katalog i ett annet filsystem. + Så si nå at du monterer filsystemet B på katalogen + A1. Rotkatalogen til B erstatter + A1, og katalogene i B kommer opp + som følger: + + / + | + +--- A1 + | | + | +--- B1 + | | + | `--- B2 + | + `--- A2 + + Filer som er i katalogene B1 eller + B2 kan nåes ved å følge stien + /A1/B1 eller /A1/B2 + Filer som var i /A1 har blitt gjemt. + De vil dukke opp hvis B er + avmontert (unmounted) fra A. + + Hvis B hadde blitt montert på A2 + ville diagrammet sett slik ut: + + / + | + +--- A1 + | + `--- A2 + | + +--- B1 + | + `--- B2 + + og stiene ville blitt /A2/B1 og + /A2/B2. + + Filsystemer kan bli montert på toppen av hverandre. Hvis vi + fortsetter med det forrige eksempelet: C + filsystemet kunne bli montert på toppen av B1 + katalogen i B filsystemet. + Diagrammet ser da slik ut: + + / + | + +--- A1 + | + `--- A2 + | + +--- B1 + | | + | +--- C1 + | | + | `--- C2 + | + `--- B2 + + Eller C kunne bli montert direkte på + A filsystemet, under A1 + katalogen: + + / + | + +--- A1 + | | + | +--- C1 + | | + | `--- C2 + | + `--- A2 + | + +--- B1 + | + `--- B2 + + Hvis du kjenner DOS så er dette ganske likt, men ikke identisk + til, kommandoen join. + + Dette er ikke noe du vanligvis trenger å bekymre deg noe om. + Når du installerer &os; lager du filsystemer og bestemmer hvor du + skal montere dem. Deretter forandres de aldri hvis du ikke legger til + en ny disk. + + Det er mulig å ha ett stort rotfilsystem og ikke lage noen andre. + Det er noen bakdeler ved dette og en fordel. + + + Fordelene Ved Flere Filsystemer + + + Forskjellige filsystemer kan ha forskjellige + monteringsinnstillinger. For eksempel, hvis du planlegger nøye så + kan rotfilsystemet bli montert read-only slik at du ikke ved en feiltagelse + sletter eller editerer en kritisk fil. + + + + &os; optimaliserer automatisk filene på et filsystem i forhold + til hvordan filsystemet blir brukt. Så for eksempel et filsystem som inneholder + mange små filer og er brukt mye har en annen optimalisering enn et filsystem + som inneholder få men store filer. Ved å ha ett stort filsystem vil + denne optimaliseringen ikke fungere. + + + + &os;'s filsystemer er svært robuste hvis du mot formodning skulle + miste strømmen. Et strømbrudd på et kritisk punkt kan likevel skade strukturen + på filsystemet. Ved å splitte opp data over flere filsystemer er det mer + sannsynlig at systemet vil komme opp. Deretter er det lettere å hente data + fra backup om nødvendig. + + + + + Fordelen Med Et Enkelt Filsystem + + + Filsystemer har en konstant størrelse. Hvis du lager et + filsystem når du installerer &os; og gir det en størrelse + kan du senere oppdage at du trenger å utvide partisjonen. + Dette er vanskelig å få til uten å ta backup, utvide filsystemet + til størrelsen du ønsker, og så laste tilbake data fra backupen. + + + + + + &os; 4.4 og oppover har en spesiell kommando, + &man.growfs.8;. Denne kommandoen gjør det mulig å + utvide størrelsen på et filsystem uten å først ta backup. + Problemet er derfor borte. + + + + + + Filesystems are contained in partitions. This does not have the + same meaning as the common usage of the term partition (for example, &ms-dos; + partition), because of &os;'s &unix; heritage. Each partition is + identified by a letter from a through to + h. Each partition can contain only one filesystem, + which means that filesystems are often described by either their + typical mount point in the filesystem hierarchy, or the letter of the + partition they are contained in. + + &os; also uses disk space for swap + space. Swap space provides &os; with + virtual memory. This allows your computer to + behave as though it has much more memory than it actually does. When + &os; runs out of memory it moves some of the data that is not + currently being used to the swap space, and moves it back in (moving + something else out) when it needs it. + + Filsystemer finnes i partisjoner. Dette har ikke den samme meningen + som den tidligere bruken av ordet i dette kapitellet på grunn av + &os;'s Unixarv. Hver partisjon er identifisert av en bokstav, + a til h. Hver partisjon kan bare + inneholde ett filsystem, noe som betyr at filsystemer ofte blir + beskrevet som enten deres typiske monteringspunkt på rotfilsystemet, eller + bokstaven på partisjonen de finnes i. + + &os; bruker også diskplass for swap. Swap + er &os;'s versjon av virtuelt minne. Dette gjør + at din datamaskin kan oppføre seg som om den har mer minne enn den faktisk + har. Når &os; går tom for minne, flytter den en del av data'en som + i øyeblikket ikke er i bruk over til swap. Den flytter data tilbake + (og derfor flytter noe annet ut) når den trenger det. + + Noen partisjoner har noen spesielle navn assosiert. + + + + + + Partisjon + + Navn + + + + + + a + + Vanligvis inneholder rotfilsystemet + + + + b + + Vanligvis inneholder swap + + + + c + + Vanligvis den samme størrelsen som delen rundt. Dette gjør + at programmer som trenger å jobbe på hele delen (for eksempel en + bad block skanner) kan jobbe på c partisjonen. + Du vil ikke vanligvis lage et filsystem på denne partisjonen. + + + + d + + Partisjon d pleide å ha en spesiell + mening assosiert, men den er nå borte. Til denne dag kan noen + programmer oppføre seg rart om de blir fortalt at de skal jobbe + på partisjon d, så Sysinstall + vil vanligvis ikke lage partisjon d. + + + + + + Hver partisjon som inneholder et filsystem er lagret i hva &os; + kaller en slice (del). En del er hva &os; + kaller en partisjon og dette er igjen på grunn av &os;'s Unixbakgrunn. + Deler er nummerert fra 1 til 4. + + slices + partisjoner + farlig dedikering + + Delnummre følger komponentnavnet, putter en + s foran og starter med 1. Så da0 + s1 er den første delen på den første + SCSIdisken. Det kan bare være fire fysiske deler på en disk + men du kan ha logiske deler inni de fysiske delene av korrekt + type. Disse utvidete delene er nummerert fra 5 og utover, så + ad0s5 er den første + utvidete delen på en disk. Disse komponentene blir brukt av + filsystemer som forventer å okkupere en del. + + Deler som er farlig dedikerte fysiske + drev og andre drev inneholder + partisjoner, som er representert som + bokstaver fra a til h. + Denne bokstaven er lagt til komponentnavnet, så + da0a er a-partisjonen på det + første da drevet, noe som er farlig dedikert. + ad1s3e er den femte partisjonen + i den tredje delen av den andre IDE disken. + + Hver disk på systemet blir identifisert. Et disknavn starter med en + kode som indikerer typen disk og så et nummer som indikerer hvilken + disk det er. Disknummerering starter med 0 og ikke 1 som i del-nummerering. + Vanlige koder som du vil se er listet i + . + + Når du refererer til en partisjon så krever &os; at du også + navngir delen og disken som inneholder partisjonen. Så når du referer + til en del burde du også referere til disk-navnet. Gjør dette ved å + liste opp disknavnet s, delnummeret og så + partisjonsbokstaven. Eksempler er vist i + . + + viser en konseptuell + modell av diskorganisering som burde hjelpe deg til å se ting klarere. + + For å kunne installere &os; må du først konfigurere disk-delene. + Deretter må du lage partisjoner inni delene du vil bruke for &os;, og til + slutt lage et filsystem (eller swap) i hver partisjon. Tilslutt må du velge + hvor filsystemet skal bli montert. + + + Vanlige Disk-koder + + + + + Kode + + Mening + + + + + + ad + + ATAPI (IDE) disk + + + + da + + SCSI direct access disk + + + + acd + + ATAPI (IDE) CDROM + + + + cd + + SCSI CDROM + + + + fd + + Diskett + + + +
+ + + Eksempel på Disk, Del, og Partisjonnavn + + + + + + Navn + + Mening + + + + + + ad0s1a + + Den første partisjonen (a) på den første + delen (s1) på den første IDE disken + (ad0). + + + + da1s2e + + Den femte partisjonen (e) på den + andre delen (s2) på den andre SCSI disken + (da1). + + + + + + + + Konseptuell Modell av en Disk + + Dette diagrammet viser &os;'s syn på den første IDE-disken + på systemet. Gå utifra at disken er 4GB stor og inneholder to + 2GB deler (DOS-partisjoner). Den første delen inneholder en DOS-disk, + C: og den andre delen inneholder en + &os; installasjon. Denne eksempelinstallasjonen av &os; har tre + partisjoner og en swap-partisjon. + + De tre partisjonene vil inneholde ett filsystem hver. Partisjon + a vil bil bruk som rotfilsystem, + e for /var katalog- + hierarkiet, og f for + /usr kataloghierakiet. + + + + + + + + .-----------------. --. +| | | +| DOS / Windows | | +: : > Første del, ad0s1 +: : | +| | | +:=================: ==: --. +| | | Partisjon a, montert som / | +| | > referert til som ad0s2a | +| | | | +:-----------------: ==: | +| | | Partisjon b, brukt som swap | +| | > referert til som ad0s2b | +| | | | +:-----------------: ==: | Partisjon c, intet +| | | Partisjon e, brukt som /var > filsystem, hele +| | > referert til som ad0s2e | &os; delen, +| | | | ad0s2c +:-----------------: ==: | +| | | | +: : | Partisjon f, brukt som /usr | +: : > referert til som ad0s2f | +: : | | +| | | | +| | --' | +`-----------------' --' + + + +
+ + + + + Montering og Demontering av Filsystemer + + Det er best å se for seg et filsystem som et tre + med sin rot /. + /dev, /usr, og de + andre katalogene i rotkatalogen er grener, som kan + ha sine egne grener, slik som + /usr/local, osv. + + root file system + + Det er forskjellige grunner til å ha disse katalogene på + forskjellige filsystemer. /var + inneholder katalogene log/, + spool/, + og andre typer av temporære filer, og kan bli fulle. + Å fylle opp rotfilsystemet er en dårlig ide, så å splitte + /var fra + / er som regel en mye bedre ide. + + En annen vanlig grunn til at det er smart å ha en del katalogtrær + på andre filsystemer er om de skal legges på separate fysiske disker, + eller er sparate virtuelle disker slik som + Network File System monteringer eller CDROM drev. + + + <filename>fstab</filename> Filen + + file systems + mounted with fstab + + + I oppstartsprosessen blir + filsystemene listet i /etc/fstab automatisk + montert (så lenge de ikke er listet med + opsjonen). + + /etc/fstab fila inneholder en liste + av linjer som ser slik ut: + + device /mount-point fstype options dumpfreq passno + + + + device + + Et "device"-navn (som skal eksistere), blir forklart i + . + + + + + mount-point + + En katalog (som skal eksistere), som + filsystemet monteres i. + + + + + fstype + + Filsystemtype som + &man.mount.8; skal bruke. Standard &os; filsystemnavn er + ufs. + + + + + options + + Enten for les-skriv- + filsystemer, eller for kun-les- + filsystemer, fulgt av andre innstillinger som kanskje trengs. + En vanlig innstilling er for + filsystemer som ikke blir automatisk montert ved oppstart. + Andre innstillinger er listet i &man.mount.8; manualsiden. + + + + + dumpfreq + + Dette blir brukt av &man.dump.8; for å finne ut av + hvilke filsystemer som trenger å dumpes. Om ikke feltet finnes, + gåes det utifra en verdi av null. + + + + + passno + + + Denne innstillingen indikerer hvilken rekkefølge + filsystemer blir sjekket på. Filsystemer som ikke trenger + eller ikke skal bli sjekket må ha passno satt til + null. Rotfilsystemet (som må sjekkes før alt annet) må ha + passno satt til større enn 1. Hvis flere + enn ett filsystem har det samme passno så vil + &man.fsck.8; prøve å sjekke filsystemene paralellt om mulig. + + + + + + + Kommandoen <command>mount</command> + + file systems + mounting + + + &man.mount.8; kommandoen brukes til å montere filsystemer. + + I sin basiske form, bruker du: + + + &prompt.root; mount device mountpoint + + + Det er mange innstillinger, som forklart i + &man.mount.8; manualsiden, men de mest vanlige er: + + + Monteringsinnstillinger + + + + + + Monter alle filsystemer listet i /etc/fstab, + bortsett fra dem merket noauto, ekskludert av flagget, eller de som allerede er montert. + + + + + + + + Gjør alt bortsett fra det faktiske monter-systemkallet. + Denne innstillingen er fin å ha når den brukes sammen med + for å finne ut hva &man.mount.8; faktisk + prøver å gjøre. + + + + + + + + Monter et urent filsystem uansett (kan være + farlig), eller tar bort skrivetilgangen når man nedgraderer + et filsystem's monteringsstatus fra les-skriv til kun-les. + + + + + + + + Monter et filsystem kun-les. Dette er det samme som + å bruke argumentet til + innstillingen. + + + + + + fstype + + + Monter gitte filsystem som den gitte filsystemtypen + eller monter bare filsystemer av gitte type, om + innstillingen er tatt med. + + ufs ufs er standard filsystemtype. + + + + + + + + Oppdater monteringsinnstillinger på filsystemet. + + + + + + + + Ekstra informasjon. + + + + + + + + Monter filsystemet skriv-les. + + + + + innstillingen tar en kommaseparert liste + av innstillinger, inkludert følgende: + + + + nodev + + + Ikke aktiver spesielle "devices" på filsystemet. + Dette er en god sikkerhetsinnstilling. + + + + + noexec + + + Ikke tillat eksekvering av binærfiler på dette + filsystemet. Dette er også en god sikkerhetsinnstilling. + + + + + nosuid + + + Ikke aktiver setuid eller setgid flagg på filsystemet. + Dette er en god sikkerhetsinnstilling. + + + + + + + <command>umount</command> Kommandoen + + file systems + unmounting + + + &man.umount.8; kommandoen tar, som et parameter, ett av et + monteringspunkt, ett "device"-navn, eller eller + innstillingene. + + Alle former tar for å tvinge demontering, + og for ekstra informasjon. Vær klar over at + som regel ikke er noen god ide. Å tvinge + demontering av filsystemer kan krasje datamaskinen eller + skade data på filsystemet. + + og brukes til å + demontere alle monterte filsystemer, men antakeligvis modifisert av + filsystemtypene listet etter . + prøver ikke å demontere rotfilsystemet. + + + + + Prosesser + + &os; er et multi-tasking operativsystem. Dette betyr at det kan se + ut som at mer enn ett program kjører samtidig. Hvert enkelt program som kjører + til enhver tid blir kalt en prosess og det er en god + del systemprosesser som kjører hele tiden og som har som oppgave å sørge for + at systemet er funksjonelt. + + Hver prosess har et unikt nummer kalt prosess-ID, + eller PID og som filer har hver enkelt prosess + en eier og ei gruppe. Eier og gruppeinformasjon blir brukt til å finne ut + hva slags filer og devices prosessen kan åpne ved å bruke filrettigheter + som forklart tidligere. De fleste prosesser har en foreldreprosess. + Foreldreprosessen er prosessen som startet dem. For eksempel, hvis du + skriver kommandoer til shellet, er shellet en prosess og alle kommandoer + du kjører også prosesser. Hver enkelt prosess du kjører på denne måten vil + ha shellet som sin foreldreprosess. Unntaket til denne regelen er en spesiell + prosess kalt &man.init.8;. init er alltid den første + prosessen, så dens PID er alltid 1. init blir startet + automatisk av kjernen når &os; starter opp. + + To kommandoer er svært hendige for å se prosessene på systemet, &man.ps.1; + og &man.top.1;. ps kommandoen blir brukt til å vise en + statisk liste over alle prosesser som kjører i det øyeblikket og kan vise deres PID, + hvor mye minne de bruker, kommandolinjen de ble startet med, osv. top + viser alle prosesser som kjører og oppdaterer skjermen etter et par sekunder så du + kan se hva datamaskinen din gjør hele tiden. + + Ved å skrive ps viser deg kun kommandoene som kjører og + er eid av deg selv: + + &prompt.user; ps + PID TT STAT TIME COMMAND + 298 p0 Ss 0:01.10 tcsh + 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) +37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) +48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi +48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) +72210 p0 R+ 0:00.00 ps + 390 p1 Is 0:01.14 tcsh + 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y + 6688 p3 IWs 0:00.00 tcsh +10735 p4 IWs 0:00.00 tcsh +20256 p5 IWs 0:00.00 tcsh + 262 v0 IWs 0:00.00 -tcsh (tcsh) + 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 + 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 + 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc + 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish + + Som du kan se i dette eksempelet er output fra &man.ps.1; organisert + i flere kolonner. PID er prosess-ID'en forklart tidligere. + Alle PIDs starter fra 1, går opp til 99999 og går ned til begynnelsen når du + går tom. TT kolonnen viser hvilken tty programmet kjører på + og kan sees bortifra for øyeblikket. STAT viser programmets + status og kan også ignoreres. TIME er hvor lenge programmet + har kjørt på CPU—'en. Dette er som regel ikke helt korrekt siden de fleste + programmer bruker mye tid på å vente på at ting skal skje før de trenger å bruke tid + på CPU'en.Til sist har vi COMMAND som er den faktiske kommandolinjen + brukt til å kjøre programmet. + + &man.ps.1; supporterer mange forskjellige innstillinger for å forandre + informasjonen som blir vist. En av de aller mest brukbare er + auxww. viser informasjon + om alle kjørende prosesser, ikke bare dine egne. + viser brukernavnet til eieren av prosessen samt minnebruk. + viser informasjon om daemon-prosesser og + gjør at &man.ps.1; viser den fulle kommandolinjen + istedetfor å kutte den om den blir for lang til å passe til skjermen. + + Informasjon fra &man.top.1; er ganske lik. Det kan se noe slikt ut: + + &prompt.user; top +last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 +47 processes: 1 running, 46 sleeping +CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle +Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free +Swap: 256M Total, 38M Used, 217M Free, 15% Inuse + + PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND +72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top + 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 + 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA + 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm +48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu + 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd + 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt +... + + Informasjonen kommer i to seksjoner. De første fem linjene viser + PID fra siste prosess som kjørte, gjennomsnittet av systembelastning + (hvor opptatt systemet er), oppetiden til systemet (tid siden siste + restart) og hva klokka er akkurat nå. De andre tingene i de øverste linjene + referer til hvor mange prosesser som faktisk kjører (47 i dette eksempelet), + hvor mye minne og swap som er brukt og hvor mye tid systemet bruker i + forskjellige CPU-tilstander. + + Under er en serie med kolonner som inneholder liknende informasjon + som du kan få fra &man.ps.1;. Som før kan du se PID, brukernavn, hvor mye + CPU tid brukt og kommandoen som ble kjørt. &man.top.1; viser deg også + hvor mye minne prosessen bruker. Dette er vist i to kolonner, en for total + plass og en for resident plass—total plass er hvor mye minne + applikasjonen har trengt og resident plass er hvor mye den faktisk bruker + i øyeblikket. I dette eksempelet kan du se at &netscape; har + spurt etter nesten 30 MB RAM, men for øyeblikket bruker 9 MB. + + &man.top.1; oppdaterer skjermbildet hvert andre sekund; + dette kan bli forandret med innstillingen. + + + + Daemons, Signaler, og Dreping av Prosesser + + Når du starter en editor er det enkelt å kontrollere den, for eksempel + fortelle den at den skal åpne en fil osv. Du kan gjøre dette fordi editoren + gir deg en grunnlag å gjøre det på samt at den er koblet til en + terminal. Noen programmer er ikke designet til å kjøre med + kontinuerlig brukerinput så de kobler seg fra terminalen med en gang + de får sjangsen. For eksempel, en webserver responderer til webforespørsler + hele dagen og trenger normalt ingen hjelp fra deg. Programmer som transporterer + e-post fra sted til sted er et annet eksempel på en slik applikasjonsklasse. + + Vi kaller disse programmene daemons. Daemons + var karakterer i gresk mytologi, de var ikke gode og ikke onde men var som + noen små hjelpere som gjorde ting for menneskeheten nå og da. Akkurat som + webservere og postservere nå til dags gjør det samme. Det er derfor + BSD-maskoten har vært en glad daemon med sneakers og høygaffel. + + Det er en konvensjon for å gi navn til programmer som vanligvis kjører + som daemons med en d på slutten. BIND er + Berkeley Internet Name Daemon (mens det faktiske programmet som kjøres kalles + named), applikasjonen Apache er + webserverprogrammet og kalles httpd, linjeprinterspooling + daemon kalles lpd osv. Dette er en konvensjon, ikke en regel. + For eksempel, den vanlige mail daemon for Sendmail + applikasjonen kalles sendmail og ikke maild. + + Noen ganger trenger du å kommunisere med en daemonprosess. + Disse måtene å kommunisere på kalles signaler og du kan + kommunisere med en daemon (eller med andre kjørende prosesser) ved å sende den + et signal. Det er mange forskjellige typer signaler du kan sende—noen av + dem har en spesifikk mening mens andre blir lest av applikasjonen og applikasjonens + dokumentasjon kan fortelle deg hvordan den applikasjonen leser signaler. Du kan bare + sende et signal til en prosess som du eier. Om du sender et signal til noen + andres prosess med &man.kill.1; eller &man.kill.2; vil du ikke ha rettigheter + til å gjøre det. Unntaket til dette er root brukeren som + kan sende signaler til hvem som helst sine prosesser. + + &os; vil også sende signaler til applikasjoner i noen tilfeller. Hvis + en applikasjon er dårlig skrevet og prøver å få tilgang til minne den ikke får lov + til å ha vil &os; sende signalet Segmentation Violation + til applikasjonen (SIGSEGV). Om en applikasjon har brukt + &man.alarm.3; systemkallet for å bli påminnet etter en viss tid har gått vil + den sende et Alarmsignal (SIGALRM) osv. + + To signaler kan brukes til å stoppe en prosess, + SIGTERM og SIGKILL. + SIGTERM er den høflige måten å drepe en prosess på; + processen kan få tak i signalet, finne ut at du ønsker + å stenge den, lukke eventualle loggfiler den kan ha åpent, og generelt + avslutte det den holder på med før den stenger ned. I noen tilfeller + kan en prosess fullstendig ignorere et SIGTERM signal + om den er i midten av en ting som ikke kan bli stoppet. + + SIGKILLblir ikke ignorert av en prosess. + Dette er Jeg bryr meg ikke om hva du gjør, stopp med en gang + signalet. Hvis du sender SIGKILL til en prosess, vil + &os; stoppe prosessen der og da + Dette er ikke helt riktig—det er en del ting som ikke kan bli forstyrret. + For eksempel, om prosessen prøver å lese fra ei fil som er på en annen + maskin på nettverket og den andre maskinen ikke svarer (den har blitt skrudd + av eller nettverket har feil) så vil prosessen være uforstyrrbar. + Etterhvert vil prosessen gå tom for tid, som regel etter to minutter. Når dette + skjer vil prosessen bli drept. + . + + Andre signaler du kan bruke inkluderer + SIGHUP, SIGUSR1, og + SIGUSR2. Dette er generelle signaler og + forskjellige applikasjoner vil gjøre forskjellige ting om de mottar + disse signalene. + + Si at du har forandret din webservers konfigurasjonsfil—du vil + at webserveren skal lese fila på nytt. Du kan stoppe og restarte + httpd, men dette vil resultere i en kort perdiode hvor webserveren + din vil være nede. Dette er kanskje ikke hva du vil. De fleste daemons er skrevet + slik at om de mottar et SIGHUP signal så vil de lese sin + konfigurasjonsfil på nytt. Så istedet for å drepe og restarte httpd + kan du sende den SIGHUP signalet. Fordi det ikke er noen standard + måte å respondere til disse signalene på kan forskjellige daemons oppføre + seg forskjellig, så les dokumentasjonen de kommer med så du er helt sikker. + + Signals are sent using the &man.kill.1; command, as this example + shows. + + + Sende et Signal Til en Prosess + + Dette eksempelet viser hvordan sende et signal til &man.inetd.8;. + inetd konfigurasjonsfilen er + /etc/inetd.conf, og inetd vil lese + denne konfigurasjonsfilen på nytt når + SIGHUP blir sendt. + + + Finn prosessID'en til prosessen du ønsker å sende signalet til. + Gjør dette ved å bruke &man.ps.1; og &man.grep.1;. &man.grep.1; + kommandoen blir brukt til å søke gjennom output for en streng du + spesifiserer. Denne kommandoen blir kjørt som en vanlig bruker og + &man.inetd.8; er kjørt som root, så + innstillingen må bli gitt til &man.ps.1;. + + &prompt.user; ps -ax | grep inetd + 198 ?? IWs 0:00.00 inetd -wW + + Så &man.inetd.8; PID er 198. I noen tilfeller vil + grep inetd kommandoen selv også dukke opp i + output. Dette er fordi hvordan &man.ps.1; må finne listen over + prosessene som kjøres. + + + + Bruk &man.kill.1; for å sende signalet. Fordi &man.inetd.8; er + kjørt av root må du bruke &man.su.1; først for å + bli root. + + &prompt.user; su +Password: +&prompt.root; /bin/kill -s HUP 198 + + Slik som det er vanlig med de fleste &unix; kommandoer, vil ikke + &man.kill.1; vise noen informasjon om den lykkes. Hvis du sender et signal til + en prosess som du ikke eier så vil du se kill: PID + : Operation not permitted. Om du skriver PID feil vil du enten + sende signalet til en gal prosess, noe som kan være ille, eller om du er heldig + har du sendt signalet til en PID som ikke er i bruk for øyeblikket. Om det skjer + vil du se kill: PID: No such process. + + + Hvorfor Bruke <command>/bin/kill</command>? + + Mange shell har kill kommandoen bygd inn i seg. + Shellet vil sende signalet direkte istedet for å kjøre /bin/kill. + Dette kan være hendig men forskjellige shells har forskjellige syntakser + for å spesifisere navnet på signalet som skal sendes. Istedet for å prøve + å lære navnene på alle sammen, kan det være enklere å bare bruke + /bin/kill ... + kommandoen direkte. + + + + + Å sende andre signaler er stort sett det samme, bare bytt ut + TERM eller KILL på kommandolinjen + etter behov. + + + Å drepe vilkårlige prosesser på systemet kan være en + dårlig ide. For eksempel, &man.init.8; med prosess-ID 1 + er veldig spesiell. Å kjøre kommandoen + /bin/kill -s KILL 1 er en kjapp måte + å stenge systemet ditt på. Alltid + sjekk argumentene du kjører &man.kill.1; med + før du trykker Enter. + + + + + Shell + shells + command line + + I &os; er mye av hverdagslig arbeid gjort på en kommandolinje + kalt et shell. Et shell's primære oppgave er å ta kommandoer + fra input-kanalen og eksekvere dem. Mange shells har innebygde + funksjoner for å hjelpe deg med typiske oppgaver som filbehandling, + kommandolinjeeditering, makroer, og miljøvariabler. &os; kommer + med flere forskjellige shells, slik som sh, + Bourne Shell, og tcsh, et bedre C-shell. Mange + andre shells er tilgjengelige fra &os; Portskolleksjonen slik som + zsh og bash. + + Hvilket shell bruker du? Det er et spørsmål om smak og behag. + Om du er en C-programmerer er kanskje et C-shell slik som tcsh + det beste. Om du har kommet fra Linux eller har akkurat begynt å bli kjent + med &unix; sin kommandolinje er kanskje bash et godt valg. + Hvert enkelt shell har sine unike innstillinger, og noen av dem passer deg + kanskje bedre enn andre, så du har en mulighet til å velge hva slags shell + du ønsker å jobbe med. + + En vanlig ting i et shell er å vise et filnavn automatisk. Ved å + skrive inn de første to-tre bokstavene i en kommando eller filnavn kan + shellet automatisk gjøre ferdig resten av kommandoen eller filnavnet + ved å trykke Tab på keyboardet. Her er et eksempel. + Si at du har to filer kalt foobar og + foo.bar. Du vil slette foo.bar. + Så hva du kan skrive på keyboardet er: rm fo[Tab].[Tab]. + + Shellet vil printe rm + foo[BEEP].bar. + + [BEEP] er konsollbjellen. Det er shellets måte å fortelle meg + at det ikke klarte å fullføre hele filnavnet fordi det er mer enn en + match. Begge foobar og foo.bar + starter med fo, men shellet klarte å fullføre navnet + opp til foo. Hvis du skriver . og + så trykker Tab igjen vil shellet klare å fylle inn resten + av filnavnet for deg. + environment variables + + En annen ting shells har er bruken av miljøvariabler. + Miljøvariabler er variabler som blir lagret i shellets miljøplass. + Denne plassen kan bli lest av hvilket som helst program som blir startet + av shellet og kan derfor inneholde mye programkonfigurasjon. Her + er en liste over vanlige miljøvariabler og hva de betyr: + environment variables + + + + + + Variabel + Forklaring + + + + + + USER + Innlogget bruker's navn. + + + + PATH + Kolonseparert liste over kataloger som kan søkes for + binærfiler. + + + + DISPLAY + Nettverksnavn som skjermbildet fra X11 kan koble seg til + , om det finnes. + + + + SHELL + Shellet som kjører for øyeblikket. + + + + TERM + Navnet på brukeren's terminal. Brukt til å finne ut + hva terminalen kan gjøre. + + + + TERMCAP + Database over terminal escape koder for å gjøre + forskjellige typer terminalfunksjoner. + + + + OSTYPE + Hva slags operativsystem, f.eks &os;. + + + + MACHTYPE + Hva slags arkitektur systemet kjører på. + + + + EDITOR + Hva slags editor brukeren vil ha. + + + + PAGER + Hva slags tekst-pager brukeren vil ha. + + + + MANPATH + Kolonseparert liste over kataloger som kan søkes + igjennom for manualsider. + + + + + + Bourne shells + Å sette en miljøvariabel varierer fra shell til shell. + For eksempel, i C-baserte shells slik som + tcsh og csh, vil du bruke + setenv for å sette miljøvariabler. + I Bourne shells slik som sh og + bash vil du bruke + export for å sette dem. + For eksempel, å sette eller modifisere + EDITOR miljøvariabelen under csh eller + tcsh til + /usr/local/bin/emacs vil se slik ut: + + &prompt.user; setenv EDITOR /usr/local/bin/emacs + + Under Bourne shells vil det se slik ut istedet: + + &prompt.user; export EDITOR="/usr/local/bin/emacs" + + Du kan også få de fleste shells til å ekspandere en miljøvariabel ved + å sette en $ foran variabelen på kommandolinjen. For eksempel, + echo $TERM vil printe ut hva $TERM inneholder + fordi shellet ekspanderer $TERM og gir den til echo kommandoen. + + Shellet har mange spesielle tegn, kalt metategn som representerer + spesielle typer data. Den mest vanlige av disse tegnene er * + tegnet. Dette tegnet representerer hvilket som helst nummer av tegn i et + filnavn. For eksempel, å skrive echo * er nesten det samme + som å skrive ls fordi shellet tar alle filene som matcher + * og putter dem på kommandolinjen slik at echo + kan lese dem. + + For å hindre at shellet skal behandle disse spesielle tegnene som + metategn kan man putte et backslash (\)-tegn foran. + echo $TERM printer hva terminalen din er satt til, mens + echo \$TERM printer $TERM akkurat som skrevet. + + + Å Forandre Shell + + Den enkleste måten å forandre et shell på er å bruke kommandoen + chsh. Kjører du chsh vil den + plassere deg inne i editoren du har satt i EDITOR + miljøvariabelen. Om denne variabelen ikke er satt, vil du bli plassert + i vi. Her kan du forandre Shell: + linjen til hva du ønsker. + + Du kan også gi chsh innstillingen + . Dette vil sette shellet for deg direkte, uten at + du trenger å gå inn i editoren. For eksempel, om du ønsker å sette shellet + ditt til bash bør følgende gjøre susen: + + &prompt.user; chsh -s /usr/local/bin/bash + + Å kjøre chsh uten parametre og editere shellet derfra + fungerer like bra. + + + Shellet som du ønsker å bruke befinne + seg i /etc/shells filen. Om du har installert + et shelkl fra portskolleksjonen bør + dette ha blitt gjort for deg allerede. Om du har installert et shell + for hånd, må du gjøre dette. + + For eksempel, om du installerte bash for hånd + og plasserte det i /usr/local/bin, trenger du å gjøre + følgende: + + &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells + + Deretter kjøre chsh en gang. + + + + + + Teksteditorer + text editors + editors + + Mye av konfigureringsarbeid i &os; blir gjort ved å editere + tekstfiler. På grunn av dette vil det være en god ide å sette seg inn + i hvordan en tekstedit fungerer. &os; kommer med et par som en del + av basissystemet og mange andre er tilgjengelige i portskolleksjonen. + + + ee + + Den enkleste editoren du kan lære deg er en editor kalt ee + som står for easy editor. For å starte ee, skriv + ee filnavn på kommandolinjen, og hvor + filnavn er navnet på filen du vil editere. + For eksempel, for å editere /etc/rc.conf skriver + du ee /etc/rc.conf. Når du så er inne i ee + er alle kommandoene for å manipulere editorens funksjoner listet på toppen + av skjermen. Tegnet ^ representerer Ctrl på + keyboardet, så ^e ekspanderer til tastekombinasjonen + Ctrle. For + å gå ut av ee trykker du Esc-tasten og velg + leave editor. Editoren vil spørre om du vil lagre endringer om filen har blitt + modifisert. + + + vi + + + editors + vi + + + emacs + + + editors + emacs + + &os; kommer også med andre kraftigere teksteditorer slik som + vi som en del av basissystemet, mens andre editorer slik som + Emacs og vim er en del + av &os; portskolleksjonen (editors/emacs og editors/vim). + Disse editorene har mye mer funksjonalitet og er mye kraftigere, men kan ta lengre + tid å lære. Om du planlegger å gjøre mye tekstbehandling er det en god ide + å lære seg en kraftigere editor slik som vim eller + Emacs. Dette vil spare deg tid i det lange løp. + + + + Komponenter og Komponentnoder + + En komponent er en terminologi som blir brukt for det meste + om hardware-relaterte ting på systemet slik som disker, printere, + grafikkort og keyboards. Når &os; starter opp vil majoriteten + av hva &os; viser på skjermen være komponenter som blir funnet. + Du kan se gjennom oppstartsbeskjedene igjen ved å lese + /var/run/dmesg.boot. + + For eksempel, acd0 er det + første IDE CDROM drevet, mens kbd0 + er keyboardet. + + De fleste av disse komponentene i et &unix; operativsystem + kan bare bli brukt gjennom spesielle filer kalt komponentnoder. Disse + finnes i /dev-katalogen. + + + Opprettelse av Komponentnoder + Når du legger til en ny komponent i systemet ditt + eller kompilerer inn support for nye komponenter må du + kanskje lage en eller flere komponentnoder for de nye komponentene. + + + MAKEDEV-skriptet + På systemer uten DEVFS (alle versjoner av &os; før 5.0) blir komponentnoder + laget bed å bruke &man.MAKEDEV.8; skriptet, som vist under: + + &prompt.root; cd /dev +&prompt.root; sh MAKEDEV ad1 + + + Dette eksempelet vil lage komponentnoder for det andre + IDE-drevet. + + + + <literal>DEVFS</literal> (DEVice File System) + + Komponentfilsystemet (device file system) eller DEVFS gjør + tilgjengelig kjernens komponentnavneplass i den globale filsystemnavneplassen. + Hva dette betyr er at istedet for å måtte lage og modifisere komponentnoder manuelt + vil DEVFS holde orden på dette filsystemet for deg. + + Se &man.devfs.5; manualsiden for mer + informasjon. + + DEVFS blir brukt som standard i &os; 5.0 og oppover. + + + + + + Binære Formater + + For å forstå hvorfor &os; bruker &man.elf.5; formatet må + du først vite litt om de tre eksekverbare formatene som dominerer + i &unix;: + + + + &man.a.out.5; + + Det eldste og mest klassiske &unix; + objektformatet. Det bruker en kort og kompakt "header" med et + magisk nummer på begynnelsen som ofte blir brukt til å + karakterisere formatet (se &man.a.out.5; for mer informasjon). + Det inneholder tre segmenter: .tekst, .data og .bss pluss + en symboltabell og en strengtabell. + + + + COFF + + SVR3 objektformatet. "Headeren" består nå av en seksjonstabell, + så du kan ha mer enn bare .tekst, .data og .bss seksjoner. + + + + &man.elf.5; + + Det som tok over for COFF. + &man.elf.5; har flere seksjoner og 32-bit eller 64-bit mulige + verdier. En stor ulempe: ELF var også designet + med det i minnet at det ville bare finnes en ABI per + systemarkitektur. Dette er ikke lenger korrekt og ikke en gang + i den kommersielle SYSV-verdenen (som har minst tre ABIs: SVR4, + Solaris, SCO) er dette sant lengre. + + &os; prøver å jobbe seg rundt dette problemet ved + å inneholde et program for å definere en ELF + eksekverbar fil med informasjon om hvilken ABI den støtter, kalt + branding. Se manualsiden for + &man.brandelf.1; for mer informasjon. + + + + &os; kommer fra det klassiske depotet og brukte + &man.a.out.5; formatet, en teknologi som er velbrukt og testet gjennom + mange generasjoner av BSD, helt til begynnelsen av 3.X treet. Det var + likevel mulighet for å bygge og kjøre ELF binærfiler + (og kernels) på et &os;-system en god stund før det. I første omgang + var ikke &os; villige til å bytte til ELF som det + standard formatet. Hvorfor? Vel, når Linux omstilte seg til ELF + var det ikke så mye å komme seg vekk fra a.out formatet + men heller det at det var deres ufleksible tabellbaserte delte bibliotek- + mekanisme. Dette gjorde at konstruksjonen av delte biblioteker ble veldig + vanskelig for selskaper og programmerere. Siden ELF + verktøy hadde en løsning på delte bibliotekproblemer og ble generelt + sett på som veien videre ble migrasjonskostnadene + akseptert som nødvendig og migreringen var et faktum. &os; sin + delte bibliotekmekanisme er basert tettere på Sun's &sunos; type + delte bibliotekmekanisme og er derfor enkel å bruke. + + Så, hvorfor er det så mange forskjellige formater? + + I den mørke fortid var det simple komponenter. Disse simple + komponentene supporterte et simpelt lite system. a.out + var helt greit for jobben å representere binærfiler på dette simple + systemet (en PDP-11). Etterhvert som folk portet &unix; fra dette + simple systemet beholdt dem a.out formatet fordi + det var godt nok for tidlige ports av &unix; til arkitekturer som + f.eks Motorola 68k, VAXen, osv. + + Men så kom en smart komponentingeniør på at hvis han kunne + tvinge software til å gjøre noen ekle triks, hadde han mulighet til + å barbere av litt design og derfor gi muligheten for CPU'en å kjøre + litt raskere. Selv om det ble lagd for å virke sammen med denne nye + typen komponenter (kjent i disse dager som RISC), + var a.out ikke egnet for denne typen komponenter + så mange formater ble laget for å få en bedre ytelse fra dem. Ting + som COFF, ECOFF og et par andre + mer obskure formater ble laget og deres limitasjoner ble utforsket + før man slo seg til ro med ELF. + + I tillegg begynte programstørrelser å bli store og disker + (og fysisk minne) var fremdeles rimelig små så konseptet med et + delt bibliotek var født. VM systemet ble også mer komplisert + etterhvert. Selv om hvert av disse fremskrittene ble gjort ved + å bruke a.out formatet, var dets brukbarhet + strukket mer og mer hver gang en ny funksjon ble lagt til. I + tillegg ønsket folk å kunne dynamisk laste inn ting når + et program ble kjørt eller å kutte av deler av programmet + etter at init-koden hadde kjørt for å spare minne og swap-plass. + Språk ble mer sofistikerte og folk ville ha kode som ble kalt + før primærkode automatisk. Masse såkalte "hacks" ble lagt til + a.out formatet for å tillate alle disse + tingene å fungere og de virket også en stund. Men det viste + seg snart at a.out ikke var godt nok for + å håndtere jobben, det kunne ikke ta seg av alle disse problemene uten at + det ble mer komplisert og mer overhead. Selv om ELF + løste mange problemer ville det bli vanskelig å gå vekk fra et + system som generelt fungerte. Så ELF måtte vente + til det var enda værre å ha a.out enn å måtte + migrere til ELF. + + Etterhvert som tiden gikk begynte byggingsverktøyene som + &os; arvet deres byggingsverktøy fra (spesielt assembler + og loader) å utvikle seg i to paralelle retninger. + &os;-treet la til delte biblioteker og fikset en del bugs. + GNU-folka som originalt skrev disse programmene skrev dem om + og la til enklere support for bygging av kompilatorer som kan + gå på tvers av formater osv. Mange folk ville bygge disse + typer kompilatorer for &os;, men støtte på en hindring + siden de gamle kildene som &os; hadde for as + og ld ikke klarte å håndtere noe slikt. + De nye GNU-verktøyene (binutils) supporterer + slike typer kompilatorer, ELF, delte biblioteker, + C++ kompilering, osv. I tillegg slipper mange selskaper + ELF binærfiler så det er en god ting at + &os; kan kjøre dem. + + ELF er mer ekspressivt enn a.out og + gjør at basesystemet kan utvides lettere. ELF verktøyene + er bedre opprettholdt og fornyet, tverskompilatorer er supportert, noe + som er viktig for mange folk. ELF er muligens litt + tregere enn a.out, men å teste det + kan være vanskelig. Det er mange detaljer som er forskjellig + mellom de to iht hvordan de håndterer initkode, mapper sider, osv. + Ingen av disse er veldig viktige men forskjellene er der. Over tid vil + support for a.out bli flyttet ut av + GENERIC kjernen og til slutt bli fjernet helt. + + + + For Mer Informasjon + + + Manualsider + manual pages + + Den mest komplette dokumentasjonen av &os; finnes i manualsidene. + Nesten alle programmer på systemet kommer med en liten referansemanual + som forteller deg hva programmet gjør og hvilke innstillinger du kan gi det. + Disse manualene kan bli lest med kommandoen man. + Bruken av man er enkelt: + + &prompt.user; man kommando + + kommando er navnet på kommandoen + du ønsker å lære noe som. For eksempel, å lære mer om + ls kommandoen, skriv: + + &prompt.user; man ls + + Onlinemanualen er delt opp i nummererte seksjoner: + + + + Brukerkommandoer. + + + + Systemkall og feilnumre. + + + + Funksjoner i C-bibliotekene. + + + + Komponentdrivere. + + + + Filformater. + + + + Spill. + + + + Forskjellige typer informasjon. + + + + Systemopprettholdelse og operasjonelle kommandoer. + + + + Kernelutviklere. + + + + I noen tilfeller kan det samme subjektet dukke opp i mer enn + en seksjon av manualen. For eksempel, det er en chmod + brukerkommando og et chmod() systemkall. + I dette tilfellet kan du fortelle man kommandoen + hvilken av disse du vil ha ved å spesifisere seksjonen: + + &prompt.user; man 1 chmod + + Dette vil vise manualsiden for brukerkommandoen + chmod. Referanser til en spesiell seksjon + av manualen er tradisjonelt plassert i parantes i dokumentasjonen, + så &man.chmod.1; refererer til chmod brukerkommandoen + og &man.chmod.2; refererer til systemkallet. + + Dette er greit nok hvis du vet navnet på kommandoen og vil bare + vite hvordan du kan bruke den. Men hva om du ikke husker kommandonavnet? + Du kan bruke man for a søke for stikkord i kommandooversikten + ved å bruke innstillingen: + + &prompt.user; man -k mail + + Med denne kommandoen vil du bli presentert med en liste + av kommandoer som har stikkordet mail i deres + forklaringer. Dette er akkurat det samme som å bruke + apropos kommandoen. + + Så du kikker på alle disse fancy kommandoene i + /usr/bin men har ingen anelse hva + mesteparten av dem gjør? Prøv: + + &prompt.user; cd /usr/bin +&prompt.user; man -f * + + eller + + &prompt.user; cd /usr/bin +&prompt.user; whatis * + + som gjør den samme tingen. + + + + GNU Infofiler + Free Software Foundation + + &os; inneholder mange applikasjoner og programmer + produsert av Free Software Foundation (FSF). I tillegg til + manualsider kommer disse programmene med mer ekstensive hypertekstdokumenter + kalt info filer som kan leses med + info kommandoen eller om du installerte + emacs, infomodusen til + nevnte applikasjon. + + For å bruke &man.info.1; kommandoen, skriv følgende: + + &prompt.user; info + + For en liten introduksjon, skriv h. + For en rask kommandoreferanse, skriv ?. + + +
+ + + -- cgit v1.2.3