Innhold - Institutt for informatikk og e-læring

Transcription

Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag
Planlegge og installere en linux-server
Helge Hafting
31.8.2015
Lærestoffet er utviklet for faget «IINI3008 Linux systemdrift»
Resymé: I denne leksjonen vil du få vite hvordan du planlegger og installerer linux. Planlegging tar for
seg disker, partisjoner, filsystemer og RAID for en tjenermaskin. Vi ser også på behovet for maskinvare.
Leksjonen tar for seg generell konfigurasjon av programmer, og kompilering av linux spesielt. Herunder ser
vi også på bruk av teksteditorer i driftssituasjonen. Vi tar en rask titt på distribusjoner, og pakkesystemet i
debian.
Det skal gå an å klikke på lenkene i leksjonen, så fremt pdf-leseren din støtter funksjonen. Det samme
gjelder innholdslista og andre kryssreferanser. Kodeeksempler kan klippes ut og kopieres for å prøve dem
ut.
Innhold
1
Introduksjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
1.1
1.2
1.3
1.4
Harddisk – typer . . . . . . . . . . . . . . . . .
1.1.1 Størrelse . . . . . . . . . . . . . . . . .
1.1.2 Typer og hastighet . . . . . . . . . . .
Harddisker – partisjoner . . . . . . . . . . . . .
1.2.1 Hva er partisjoner . . . . . . . . . . . .
1.2.2 Hvorfor partisjonere . . . . . . . . . .
1.2.3 Minimum partisjonering . . . . . . . .
1.2.4 fdisk og cfdisk – partisjonering av disker
Flere harddisker . . . . . . . . . . . . . . . . .
1.3.1 Hvorfor . . . . . . . . . . . . . . . . .
1.3.2 Hvordan . . . . . . . . . . . . . . . . .
1.3.3 RAID . . . . . . . . . . . . . . . . . .
1.3.4 Mer informasjon . . . . . . . . . . . .
Filsystemer . . . . . . . . . . . . . . . . . . .
1.4.1 Ext2 – enkelt og raskt . . . . . . . . . .
1.4.2 Ext3 – et journalførende filsystem . . .
1.4.3 Ext4 . . . . . . . . . . . . . . . . . . .
1.4.4 Reiserfs . . . . . . . . . . . . . . . . .
1.4.5 JFS . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
6
6
7
9
10
11
11
12
13
20
21
21
21
23
23
23
side 2 av 38
1.4.6 XFS . . . . . . . . . . . . . . . . . .
1.4.7 Btrfs . . . . . . . . . . . . . . . . . .
1.5 Minne . . . . . . . . . . . . . . . . . . . . .
1.6 Prosessor . . . . . . . . . . . . . . . . . . .
1.7 Nettverk . . . . . . . . . . . . . . . . . . . .
1.8 Andre maskinvarebehov . . . . . . . . . . . .
1.9 Teksteditorer . . . . . . . . . . . . . . . . . .
1.9.1 Grafisk eller tekstbasert editor? . . . .
1.9.2 Noen editorer . . . . . . . . . . . . .
1.9.3 Teksteditoren vi . . . . . . . . . . .
1.10 Kompilere en linuxkjerne . . . . . . . . . . .
1.10.1 Hvorfor . . . . . . . . . . . . . . . .
1.10.2 Programpakker du trenger . . . . . .
1.10.3 Laste ned kode . . . . . . . . . . . .
1.10.4 Eventuelle patcher . . . . . . . . . .
1.10.5 Konfigurere . . . . . . . . . . . . . .
1.10.6 Kompilere . . . . . . . . . . . . . . .
1.10.7 Installere kjernen . . . . . . . . . . .
1.11 Kort om distribusjoner . . . . . . . . . . . .
1.11.1 Distribusjoner og dette faget . . . . .
1.11.2 Installere og oppgradere debianpakker
1.11.3 Installere rpm-pakker . . . . . . . . .
1.11.4 Andre distribusjoner . . . . . . . . .
1.11.5 Installere .tar.gz-filer . . . . . . . . .
1.12 Oppsummering . . . . . . . . . . . . . . . .
Innhold
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
26
27
27
28
29
29
31
31
32
32
32
33
34
34
35
35
36
36
36
37
38
Introduksjon
Velkommen til faget «Linux systemdrift». Faget fokuserer på drift og installasjon av
linuxtjenere. Vi ser bl.a. en del på linux som filtjener, i så måte er faget i slekt med
«Windows tjener for systemansvarlige» som ser et annet tjeneroperativsystem.
Når det gjelder filtjener ser vi på NFS og filtjeneren SAMBA, katalogtjenesten openLDAP,
aksesskontrollister, filrettigheter, skrivertjeneste og administrasjon av brukerkonti. Vi
ser også en del på shellscript, og hvordan de kan brukes for å automatisere rutinearbeid.
Lenger ut i kurset ser vi på bruk av webproxy, dhcp-protokollen, tynnklientløsninger og
fjernadministrasjon. Vi tar også for oss nettjener (webserver), e-post og databaser
For å få gjort praktiske øvinger er det nødvendig med en maskin som kjører linux. For å
få fullt utbytte av undervisningen bør man også ha en maskin til som kan være klient for
tjeneren. Jeg har tatt utgangspunkt i at klientmaskinene kjører windows, men det vil også
© Helge Hafting og stiftelsen TISIP
være mulig å bruke en mac eller linux-maskin som klient. Maskinene trenger ikke være
særlig kraftige for å gjennomføre kurset. For å få en god tjener vil man imidlertid bruke
noe bedre.
I kurset brukes begrepene unix og linux om hverandre. Kort fortalt er linux en variant
av operativsystemet unix. Det finnes andre unix-varianter også, som f.eks. BSD og
proprietære unix-varianter fra maskinleverandører som IBM, HP og Sun.
Enkelte synes at noen av leksjonene er ganske store i dette faget. Men husk at det er et
fag uten lærebok. Derfor burde ikke de 38 sidene i denne leksjonen være avskrekkende.
En kort leksjon som henviser til et kapittel i en lærebok, forutsetter gjerne at man leser
mange sider i den aktuelle boka.
Stoffet i leksjonene er laget for debian-distribusjonen av linux. Det går an å bruke andre
distribusjoner enn debian. (F.eks. ubuntu, mint eller redhat.) Men husk at det er en del
forskjeller på distribusjonene:
• Noen pakker kan ha andre navn. En del distribusjoner bruker et anderledes
pakkesystem. (rpm-baserte, og gentoo-baserte)
• Filer kan være plassert i andre mapper
Oppskriftene i leksjonene vil ikke passe like godt til andre distribusjoner. For de som
uansett liker å finne ut av ting på egen hånd, behøver det ikke være noe stort problem.
Men det blir en avveiing: Med debian vil leksjonene passe bedre, opp mot grunnene til at
du foretrekker en annen distribusjon.
1 Planlegge og installere en
linux-server
1.1 Harddisk – typer
1.1.1 Størrelse
Størrelsen er enkel å planlegge, det skal simpelthen være «plass nok til alt.» Hvor mye
det blir avhenger av hva tjeneren skal brukes til. Selve operativsystemet kan presses inn
på veldig lite plass, men det er enklere å sette av 12–20 gigabyte. DSL1 bruker f.eks.
bare 50MB. Debian linux kan presses inn på ca. 500MB, men det tar fort såpass lang tid
at det i en arbeidssituasjon lønner seg bedre å bruke en stor nok disk med en gang. Små
1
Damn Small Linux
side 4 av 38
installasjoner har mer for seg i spesielle situasjoner hvor en ikke kan bruke harddisk, og
derfor ønsker å boote fra CD, compactflash, sd-kort eller USB-penn.
For en filtjener tar vi antall brukere og ganger med hvor mye plass hver bruker skal ha.
Husk at en ny tjener gjerne skal brukes i noen år, så ta høyde for at det reelle behovet
for plass kan øke med tiden. I et firma i vekst bør en også ta hensyn til at antall brukere
kan øke. Men ikke overdriv dette med ekstrakapasitet – det er enkelt å installere flere
harddisker etterhvert, og de blir som regel billigere med tiden også.
Hvis maskinen skal håndtere e-post også bør en tenke over at det i blant kan komme
uvanlig mye på en gang, f.eks. i forbindelse med virusangrep og spam2 .
Hvis tjeneren skal kjøre spesielle programmer, f.eks. en database, er som regel programmets behov for plass dokumentert.
1.1.2 Typer og hastighet
Ytelsen bestemmes i stor grad av ting som overføringshastighet og rotasjonshastighet.
Når det gjelder overføringshastighet må en se på hvor fort data leses fra platene (off the
platter speed), ikke hvor fort data kan overføres over kabelen. Markedsføring oppgir
gjerne det siste, men en SATA-300 disk har ikke sjanse til å overføre 300 MB/s særlig
lenge ettersom platene ikke er på langt nær så raske. Det kan hende de klarer 20–50
MB/s . . .
Uansett hvor rask overføringshastigheten er, vil det i praksis være rotasjonshastigheten
som begrenser det hele. En filtjener for mange brukere vil til stadighet ha bruk for tilgang
til ulike deler av disken, og vil derfor flytte lesehodene en god del. Når de flyttes vil
vi deretter i gjennomsnitt måtte vente 12 rotasjon før interessante data havner under
lesehodet. Med dagens disker er det denne ventingen på 12 rotasjon som setter grenser for
ytelsen.
Med fokus på rotasjonshastighet skjønner vi at det er stor forskjell på 4 200 / 5 400 rpm
laptop-disker, 7 200 rpm disker, 10 000 rpm disker og 15 000 rpm disker.
SSD blir stadig mer populært. Diskene er raske fordi de ikke har roterende plater og deres
tilhørende venting. En laptop med SSD starter opp og lar oss logge inn på ca. 10s, mot
1/2–1 minutt med roterende disk. Men SSD er også såpass dyrt at en stor tjenermaskin
som regel må ha mye av lagerplassen på roterende disker.
2
Uønsket reklame og annen søppelpost.
Harddisk – typer
side 5 av 38
SCSI3
Disse brukes en del i tjenermaskiner. For tiden er typisk rotasjonshastighet for SCSIdisker 7 200, 10 000 eller 15 000 rpm. SCSI koster gjerne mer enn SATA, men har ofte
bedre garantiordninger. De billigste diskene er ikke i samme grad bygd for å vare lenge.
Med dagens SCSI-kontrollere kan en vanligvis koble opptil 15 disker (eller andre enheter)
til en kontroller med en kabel. Maskinen kan kommunisere med flere disker på en
gang, bare begrenset av samlet overføringskapasitet i kabelen. Hvis man f.eks. har
4
disker som klarer 40MB/s
160 til/fra platene og en kontroller som klarer 160MB/s kan
man dermed utnytte 40 = 4 disker fullt ut. Med en kontroller som klarer 320 MB/s
kan vi ha 8 slike disker. Flere disker enn dette vil øke kapasiteten ytterligere, men
ikke overføringshastigheten. Har en bruk for enda høyere ytelse, trenger en i så fall flere
kontrollere. Da må man imidlertid være oppmerksom på at overføringskapasiteten på PCIbussen også er begrenset. En pci-buss går typisk på 33.3 eller 66.6Mhz, og kan overføre
32 eller 64 bit parallelt. Kapasiteten blir dermed 133–532MB/s. Hvis det ikke er nok,
fins hovedkort med flere separate pci-busser. PCI-express (PCIe) har høyere kapasitet,
og det fins diskkontrollere for denne bussen. Hvis scsi-kontroller og nettverkskort er på
samme pci-buss halveres busskapasiteten for filtjenester, ettersom data først overføres
fra kontroller til minnet og deretter fra minnet til nettverkskortet. Bussen brukes altså to
ganger.
SATA
Serial ATA er en billigvariant av scsi. Protokollen som brukes er scsi-protokollen, derfor
behandler linux SATA-disker som scsi-utstyr. Men prisene for SATA-utstyr lavere. Med
SATA har man en ledning per disk. Overføringskapasiteten i en slik kabel er 150–600
MB/s, men som diskplatene ikke kommer i nærheten av.
SSD
SSD5 er lagringsmedium uten bevegelige deler. I stedet for en roterende magnetisk plate,
har SSD flash-minne.
For tjenermaskiner fins større SSD-enheter, basert på flash eller i noen tilfeller RAM.
Disse diskene er typisk dyrere enn roterende harddisker, og har noe lavere kapasitet. Men
3
4
5
Small Computer System Interface
Vær oppmerksom på forskjellen mellom MB/s (megabyte per sekund) og Mb/s (megabit per sekund).
Ytelse for disker og parallelle busser (som PCI og AGP) oppgis gjerne i MB/s, mens nettverk og annen
seriell kommunikasjon gjerne opererer med Mb/s. En byte er som kjent 8 bits.
Eng: Solid state disk
side 6 av 38
de er også betydelig raskere, på grunn av et problem med vanlige harddisker: Når en
pc leser fra flere steder på en roterende harddisk, må lesehodene flyttes fra et sted til et
annet. Det tar tid. Deretter må man simpelthen vente på at rett del av plata roterer inn
under lesehodet. En roterende disk som fint klarer 90MB/s så lenge den får lese data i den
rekkefølgen det er lagret, vil fort falle ned på en hundredel hvis den må flytte lesehodene
mye rundt omkring. SSD har ikke dette problemet. Data kan leses fra hvor som helst
uten forsinkelser, fordi det ikke er noen bevegelige deler å vente på.
I skrivende stund er SSD dyrere enn roterende disker, så SSD brukes først og fremst der
man har mest nytte av det. Noen anvendelser er sekvensielle i natur, f.eks. å streame
video. Her vil ikke SSD oppleves raskere. Hvis du derimot streamer mange ulike videoer
samtidig, i en youtube-lignende tjeneste, vil SSD kunne hjelpe. Kompilering av store
prosjekt med titusener av filer, eller travel database, er eksempel på en annen anvendelse
hvor mange små datasett hentes fra ulike steder på disken i rask rekkefølge. I slike tilfeller
kan hastighetsforskjellen med SSD være dramatisk. I ekstreme tilfeller går store jobber
fra å måles i timer til minutter. Databaser som er for store til å holdes i minnet, drar også
nytte av SSD.
Å starte opp en maskin som har operativsystem og programvare installert på SSD, er
også en god del raskere enn om det er installert på vanlig harddisk.
En rimelig SSD kobles til maskinen med SATA-kabel. Men SATA overfører på 300–
600MB/s, som ofte blir en begrensning. I motsetning til roterende disker, kan flashminne
overføre data raskere enn dette. Dyrere SSD-løsninger har flashminne montert på et
PCIe-kort. Dermed er ikke overføringshastigheten lenger begrenset av SATA, man kan
utnytte PCI-express fullt ut.
1.2 Harddisker – partisjoner
1.2.1 Hva er partisjoner
Filene lagres i et filsystem på harddisken. Den enkleste måten, som ofte brukes på
hjemmemaskiner, er å ha en stor partisjon med ett filsystem. Det er enklest, og all ledig
plass på disken er å finne på ett sted.
En partisjon er en del av harddisken, en del som spenner over et antall sylindre. Hver
partisjon har ett filsystem, så har man flere partisjoner kan man ha flere uavhengige
filsystemer.
Harddisker – partisjoner
side 7 av 38
1.2.2 Hvorfor partisjonere
Kontroll med diskplass
Hvis /home og /var er på hvert sin partisjon kan filsystemet /home gå fullt mens det
fremdeles er plass igjen på /var. Umiddelbart kan det se ut som en ulempe – det fins
ledig plass som vi ikke får utnyttet. Dette er imidlertid en fordel. Vi kan sette av plass for
filene under /var, plass som garantert vil være der uansett hvor mye brukerne sløser med
plassen sin på /home. Hvis /home blir fullt vil det altså likevel være igjen plass på /var,
og programmer som avhenger av denne plassen vil fortsette å virke. Dette er viktig, da
/var har mange viktige funksjoner i linux.
Når det gjelder å begrense brukere kan vi oppnå samme effekt med diskkvoter, men siden
noen brukere bruker lite plass er det praktisk å kunne la andre bruke over gjennomsnittet.
Det finnes også mange andre tilfeller hvor kvoter ikke er svaret, f.eks. når filer som eies
av systemet konkurrerer med hverandre.
Noen eksempler på mapper vi kan ønske å skille ut av plasshensyn:
/home
Hjemmemapper. I store organisasjoner kan det også være aktuelt med
flere /home-områder. Dette for å beskytte ulike grupper av brukere mot
hverandre. Noen kan ha en verre tendens til overforbruk.
/var
Å skille ut /var er et minimum, /var deles ofte videre opp avhengig
av hva vi har på tjeneren. Hvis /var fylles opp fører det typisk til
driftsproblemer og tjenerprosesser som kræsjer. I /var/log fins loggfiler
for det meste som skjer, og disse må kunne vokse ved behov.
/var/spool/mail Her havner all innkommende post. Blir det fullt tar ikke tjeneren imot
post lenger. Dette området kan fylles opp i forbindelse med spam eller
mailbombing, det er en fordel om det ikke går utover andre tjeneroppgaver. Spesielt bør ikke en slik epoststorm sette resten av /var ut av
spill.
/var/spool/news Kjører man newstjener er det her artiklene lagres.
/var/spool/cups Her mellomlagres utskrifter6 . Dette området kan fylles opp hvis en bruker skriver ut noe veldig stort. Fotografier og lignende høyoppløselige
bilder tar mye plass.
6
/var/www
Her finner vi dokumentrot for webtjener.
/tmp
Her har alle brukere adgang til å lagre midlertidige filer. Dermed er det
lett å fylle opp, og bør skilles ut. Har en mange brukere, bør det være en
kvoteordning på /tmp for å unngå at en ubetenksom bruker ødelegger
for andre.
Evt. /var/spool/lpd, avhengig av hvilken spooler man bruker.
side 8 av 38
Her ligger typisk linuxkjernen, og evt. noen få andre filer som trengs
for å starte maskinen. Hvis maskien bruker UEFI7 , vil /boot være uefipartisjonen.
/boot
Programmer som df viser total plass, brukt plass og ledig plass per filsystem. Slik
informasjon er mer brysomt å finne for deler av et filsystem. Programmet du gir forbruket
i et enkelt mappetre, som både kan være mindre eller større enn ett filsystem.
Ulik tilgang
Ulike filsystemer kan ha ulik tilgang. Vi kan f.eks. ha noen filsystemer som er skrivbare og
noen som bare er lesbare. Filsystemer som ikke er skrivbare øker sikkerheten. Tidligere
har f.eks. en del sørget for at /usr ikke er skrivbart, det hindrer til en viss grad crackere i
å overskrive programmer. Kommandoen mount /usr -o remount,rw vil gjøre
filsystemet skrivbart igjen, noe enhver hacker vet. Men mange angrep utføres av scriptkiddies8 som bare bruker et rootkit9 uten å forstå hva som skjer. De lar seg ofte stoppe av
slike små hindringer.
I det siste har distribusjonene lagt om oppstartrutinene slik at /usr trengs tidlig i oppstarten.
Det anbefales derfor ikke lenger å ha /usr på en egen partisjon.
Andre sikkerhetsrelaterte mount-opsjoner:
nodev
Hindrer devicenoder på filsystemet. Bør brukes på alle filsystemer utenom
det som inneholder /dev, det hindrer brukere/hackere i å opprette devicenoder på uventede steder. Devicenoder kan misbrukes til å ta kontroll over
maskinen.
noexec
Hindrer eksekverbare filer. Bør brukes overalt hvor slike ikke trengs. Det
begrenser bl.a. muligheten til å «gjemme vekk» rootkit-filer.
nosuid
Hindrer eksekverbare filer i å skifte prosessens identitet10 . Bør brukes
på alle filsystemer hvor eksekverbare filer tillates, utenom /bin, /usr/bin,
/usr/local/bin og tilsvarende for sbin. Disse mappene har normalt bruk for
suid-programmer, mens f.eks. /home og /usr/src kan ha bruk for exec men
neppe suid.
7
Unified Extensible Firmware Interface
Umodne personer med liten innsikt, som morer seg med datainnbrudd o.l.
9 Automatisert verktøy for å bryte seg inn å skaffe tilgang til brukeren root. Utnytter kjente svakheter i
operativsystem og tjenerprogramvare og representerer derfor liten fare for de som til enhver tid holder
tjeneren sin oppdatert.
10 Ett suid-program skifter identitet fra brukeren som kjører det, til brukeren som eier programfilen. Programmet passwd, som bytter passord for oss, er et slikt program. Det bytter identitet til root for å kunne legge
inn det nye passordet i den beskyttede passordfilen.
8
Harddisker – partisjoner
sync
side 9 av 38
All tilgang til filer skjer synkront. Dette er mye tregere enn async, men sikrer
oss mot datatap i forbindelse med plutselig strømbrudd eller andre former
for kræsj. Dette brukes sjelden da programmer som avhenger av synkron
lagring kan bruke fflush() og fsync() på normale asynkrone filsystemer. Noen
velger likevel å bruke synkron lagring for epost, særlig hvis de bruker en
eposttjener som ikke bruker fsync().
Hvis man tillater brukere å bruke egne minnepinner eller cd’er bør man absolutt bruke
nodev og nosuid, noe annet er naivt.
Noen velger å legge /tmp på en ramdisk (tmpfs) for å få raskest mulig tilgang til midlertidige filer. En må imidlertid være klar over at de midlertidige filene vil bruke av minnet,
og programmer som lagrer midlertidige filer gjør det til tider nettopp fordi de opererer
med datastrukturer som er store. Å bruke tmpfs kan likevel være en god idé, for det som
var for stort for gårsdagens minne er ikke nødvendigvis for stort i dag.
Ulike filsystemer
I underkapittel 1.4 på side 21 ser vi på filsystemer med forskjellige egenskaper. Flere
partisjoner gjør det mulig å bruke ulike filsystemer på ulike partisjoner.
1.2.3 Minimum partisjonering
Det går an å skille ut /home, /var og /tmp som egne partisjoner. (Evt. kan man ha /tmp på
en ramdisk) Dermed står vi også igjen med en liten partisjon for /, rotfilsystemet, og en
partisjon for swap.
Det har etterhvert blitt vanlig å ha /usr som en del av rotfilsystemet, fordi programvaren
som ligger der kan være nyttig å ha i oppstartfasen før andre filsystemer blir montert. På
en filtjener (eller hjemmemaskin) er /home det filsystemet som er viktigst å skille ut. Det
er der brukerne lagrer filer. Vi vil ikke at maskinen skal få problemer bare fordi brukerne
fyller opp disken. Og hvis vi må reinstallere, er det veldig praktisk at /home er et eget
filsystem. Da kan vi formatere rotfilsystemet på nytt, mens brukerne likevel får beholde
sine filer uendret.
Ofte legger man /tmp i tmpfs, et filsystem på ramdisk. Det er raskt, men kan sluke minne,
og det er naturligvis ikke mer plass her enn det er minne i maskinen. Har man bruk for
store filer i /tmp, er det bedre å bruke plass på en SSD-disk.
Noen liker å ha /var på et eget filsystem. Her ligger mye som får problemer hvis disken
skulle bli helt full. F.eks. pakkedatabasen i maskinen, som holder orden på installert
programvare. Enkelte tjenester, som databaser, epost og nettjener havner i undermapper
på /var. Hvis en slik tjeneste er plasskrevende, er det vanlig å skille den ut i et eget
side 10 av 38
filsystem. Dermed er den beskyttet mot at /var fylles opp på annet vis, og /var er
beskyttet mot at tjenesten plutselig tar opp plass.
For snurredisker er partisjonenes rekkefølge på disken heller ikke tilfeldig. Den ytterste
delen av disken, som vanligvis har de lavest nummererte sylindrene, kan være opptil
dobbelt så rask som den innerste delen (høye sylindernumre.) De mest brukte partisjonene
bør dermed ligge på den raskeste delen av disken. Når lesehodene flyttes er det dessuten
raskere å flytte kort enn langt. Filsystemer som brukes lite bør dermed legges ut mot
den trege enden av disken. Rotfilsystemet brukes lite, det er ingen grunn til å legge det
først på disken slik mange gjør når de installerer. I en filtjener er gjerne /home viktig,
i andre typer tjenere (epost, web, . . . ) er sannsynligvis /var viktigere. En del velger å
legge swap-partisjon og /tmp midt på disken. Det er ikke den raskeste plassen når det
gjelder båndbredde, men det er dit veien er kortest å flytte lesehodene på disken. Dette
passer bra for swap og /tmp som ofte er tidskritisk og preget av hyppige diskaksesser
med små datamengder.
1.2.4 fdisk og cfdisk – partisjonering av disker
Disse programmene brukes for å partisjonere disker. Vær forsiktig med disse. Gjør du
feil, sletter du fort et helt filsystem eller alt på disken. Disse programmene brukes ikke
bare ved installering, men også når man monterer ekstra disker i maskinen. Programmet
fdisk er noe tungvint å bruke, en starter programmet, f.eks. med fdisk /dev/hda,
og gir en og en kommando for å slette eller opprette partisjoner. Nybegynnere bør bruke
kommandoen p ofte, den skriver ut hvordan partisjonstabellen ser ut for øyeblikket.
Programmet cfdisk er noe greiere å bruke. Det viser hele tiden hvordan disken er
partisjonert, og lar deg velge partisjoner og ledige områder med en tekstbasert meny.
Programmet har de samme mulighetene som fdisk, men er mer brukervennlig uten å
bli tungt.
Begge programmer arbeider med én disk om gangen, og man angir denne disken som
parameter når man starter opp programmet. De har innebygd en viss sikkerhet mot
feil ved at en må gi en skrivekommando for å lagre forandringer, og dessuten bekrefte
kommandoen.
I tillegg til å dele opp disken, kan man bestemme hvilken partisjon som skal bootes (hvis
noen), og partisjonstyper. Alle linux filsystemer legges normalt på en partisjon av typen
Linux (83). Typen Linux swap (82) brukes for swap-partisjoner, og Linux raid autodetect
(fd) brukes for software-raid. Det finnes mange andre typer også, som stort sett brukes av
andre operativsystemer.
Flere harddisker
side 11 av 38
1.3 Flere harddisker
1.3.1 Hvorfor
Sikkerhet
Den mest opplagte grunnen til å ha flere harddisker er mer plass. Men det er mange flere
grunner enn det. Flere harddisker kan også øke datasikkerhet og oppetid, hvis vi lagrer
samme data på flere disker tåler vi at en går i stykker. Hvis vi kjører en tjener over flere år
må vi regne med at harddisker ryker i blant, en ansvarlig administrator må være forberedt
på det. Spørsmålet er når, ikke om det skjer!
I en tjener med bare en harddisk kan det bli nødvendig å skaffe en ny og legge inn alt
fra siste sikkerhetskopi. Da mister vi for det første alt som har skjedd siden kopien ble
tatt, og tjeneren er nede en stund. For en nettbutikk kan nedetid fort bli dyrt. Skjer det
etter arbeidstid kan det fort gå en stund før noen oppdager feilen også. Har man et godt
raid-system og hotplug-disker kan man klare seg helt uten nedetid. Som administrator
får man en epost om at en disk har gått dukken, og at systemet inntil videre klarer seg
med de andre. Så er det bare å skaffe en ny og installere den når det passer . . .
Vi kan også oppnå bedre sikkerhet mot innbrudd. I underkapittel 1.2.2 på side 8 så vi på
fordelen med et skrivebeskyttet filsystem. Det kan dessverre omgåes med kommandoen
mount. Men en harddisk kan skrivebeskyttes ved å sette en jumper – dermed blir det
umulig å skrive til den, og dette kan ikke omgåes med programmerte triks. Administrator
er nødt til å flytte jumperen hvis innholdet på disken skal oppdateres på noe vis, en
som bryter seg inn via nettet har ingen muligheter. Slik kan man beskytte filsystemer
som f.eks. /usr, men ulempen er at det blir mer bry med nødvendige endringer som
f.eks. sikkerhetsoppdateringer. I ekstreme tilfeller har sikkerhetsbevisste administratorer
lagt /usr, /bin og /sbin ut på CD, for å være 100% sikker på at eksekverbare filer ikke
kan overskrives ved innbrudd. Men vær oppmerksom på at CD er et tregt medium
sammenlignet med harddisk.
Ytelse
Det er søketiden som begrenser ytelsen for roterende harddisker. Når en harddisk er travelt
opptatt bruker den mesteparten av tiden på å flytte lese/skrivehodene rundt omkring. Med
mange aktive prosesser kan det gå mange slike søk mellom hver gang en bestemt prosess
får lest eller skrevet.
Hvis vi har flere harddisker kan vi imidlertid oppnå at en er relativt ledig og gir god ytelse
selv om en annen er overbelastet. La oss se på en maskin som både er fil- post- og nettjener
på en gang. Med alt på en harddisk er det nok at en av tjenestene overbelaster disken, så
side 12 av 38
går alt tregt fordi alle filoperasjoner ender opp med å vente på hverandre. Hvis vi derimot
bruker en harddisk per tjeneste vil de ikke forstyrre hverandre. En overbelastning på
nettjeneren vil fortsatt gi tregere tilgang til web, noe vi bare må akseptere. Men post
og filtilgang vil fortsatt gå med full fart ettersom disse diskene ikke er overbelastet i
øyeblikket. Tilsvarende vil ikke en epost-storm virke inn på web- eller filservice.
Enkelte som kommer fra windowsverdenen vil si at det er bedre å kjøre en maskin per
tjeneste — å samle fire–fem tjenester i den samme maskinen kan virke useriøst på slike.
Denne tankegangen har sin rot i stabilitetsproblemer, windows har en forhistorie med
tilfeller hvor en tjeneste kræsjer og trekker med seg hele maskinen og alle andre tjenester
som kjører på den. Men i unixverdenen har vi stabilitet nok til at mange tjenester i én
maskin ikke er noe problem.11 Nedetid er stort sett planlagt, f.eks. når man legger inn
sikkerhetsoppdateringer eller oppgraderer prosessoren. Så lenge vi unngår overbelastning
lønner det seg med mange tjenester i samme maskin. Færre maskiner å vedlikeholde
sparer oss for mye administrasjonsarbeid og utgifter til utstyr, særlig i forbindelse med
oppgraderinger.
1.3.2 Hvordan
For en tjener som skal kjøre flere uavhengige tjenester må vi se på hvilke som til tider er
disk-intensive og fordele dem på hver sine disker. Dette gjelder ikke bare ulike tjenester
som i det forrige eksempelet. Outsourcing/sky-tjenester er populært for tiden, og som
konsulent kan man fort ende opp med å kjøre f.eks. nettjenester for flere kunder på en
maskin. En kunde bør ikke vente unødig på grunn av mye trafikk til en annen kundes
sider. Dette kan vi unngå ved å ha de travleste nettsidene på egne disker. Ideelt en disk
per kunde, men det kan kanskje bli litt mye.
Det kan også være fornuftig å ha filsystemet /usr på en disk som ikke er travelt opptatt.
Nesten alle programfiler ligger på /usr, og det er en fordel at de starter raskt. Vær også
oppmerksom på at linuxkjernen ikke henter hele programmer inn i minnet når de starter.
Et program som er godt igang kan dermed få bruk for å hente inn mer av programfilen
når en annen del av programmet plutselig tas i bruk. Igjen er det en fordel om dette kan
skje uten å måtte vente på filtjenere, nettjenere o.l.
11 Forutsatt,
naturligvis, at maskinvaren er stabil. De fleste linuxkræsj skyldes hardware-problemer som
dårlig utstyr, overklokking, strømproblemer og lignende. En administrator som eksperimenterer med
betaversjoner av kjernen kan også lage problemer. Ellers regnes kræsj som unormalt, en linuxtjener kan
normalt holde ut kontinuerlig drift i årevis. På nettet finnes eksempler ved å søke etter ordet uptime.
Flere harddisker
side 13 av 38
1.3.3 RAID
RAID12
RAID er en teknikk for å få flere disker til å fremstå som én, på det viset kan vi øke lagringkapasitet, ytelse, feiltoleranse eller alle på en gang. Det fins spesielle diskkontrollere
som implementerer RAID i hardware, linux vil da se disk-samlingen som én stor disk.
Linux har også software-raid som gjør det mulig å bruke RAID med ordinære billigere
diskkontrollere.
Vær klar over at selv om RAID kan sikre oppetid og øke sikkerheten med tanke på diskfeil,
så beskytter ikke RAID mot operativsystemfeil, virus, innbrudd eller operatørfeil. Slike
problemer krever en backup-løsning i stedet.
Her ser vi på RAID-0, RAID-1, RAID-10, RAID-5 og RAID-6. Det finnes også andre
kategorier, men de har liten praktisk interesse.
RAID-0
Også kalt striping. Med n disker n - dobles både lagringskapasitet og ytelse, men sikkerheten er dårlig. Hvis én disk ryker er alt tapt. Hvorvidt ytelsen faktisk øker har mye å
gjøre med hva slags stripestørrelse en bruker. Ytelsen kan også bli dårligere med et dårlig
oppsett – dette bør testes under installasjon. På grunn av dårlig sikkerhet bør det ikke
brukes til annet enn midlertidige filer som vi tåler at går tapt. Datafiler for en webcache
eller newstjener er typiske eksempler. En kan også ha /tmp på raid-0. Nå har en vanligvis
ikke behov for så mye plass på /tmp alene et en setter opp raid-0 bare for det, men hvis
en har raid-0 for andre formål kan også /tmp plasseres der og få fordel av den høye
overføringskapasiteten.
Her ser vi hvordan raid-0 fungerer. Arrayet bygges opp stripe for stripe, ved å plukke en
og en blokk fra hver disk. Med to disker A og B, kommer blokken R0 fra A, R1 fra B, R2
fra A igjen, og så videre. Raid-0 kan lages med flere disker også. Til venstre i figuren er
diskene, inndelt i x blokker. Til høyre er arrayet slik operativsystemet ser det. Hvis en fil
lagres på blokkene R1 · · · R3 , ligger den altså egentlig på blokkene B0 , A1 og B1 .
12 Redundant
Array of Inexpensive Disks
side 14 av 38
Virkelige disker
z
A0 = R0
A1 = R2
A2 = R4
A3 = R6
..
.
Ax−1 = R2x−2
}|
+
Raid-0
B0 = R1
B1 = R3
B2 = R5
B3 = R7
..
.
Bx−1 = R2x−1
{
z
=
}|
{
Stripe 0
Stripe 1
Stripe 2
Stripe 3
..
.
Stripe x − 1
Hastighetsgevinsten får vi fordi maskinen kan lese/skrive de ulike diskene samtidig. Men
vær oppmerksom på hvordan én ødelagt disk vil ødelegge alt; Hvis f.eks. disk A ryker,
mister vi stripene R0 , R2 , R4 . . . R2x−2 , og står igjen med stripene R1 , R3 , R5 , . . . R2x−1 Vi
mister altså annenhver stripe, og filsystemet på R-disken tåler ikke slikt. Eksempelet viste
raid-0 med to disker, men man kan godt slå sammen mange flere for enda mer kapasitet
og ytelse. R-disken bygges da opp med en stripe fra hver av diskene, deretter en til fra
hver disk, og så videre. Å miste én av dem vil fortsatt være katastrofalt.
RAID-1
Også kalt speiling. Lagringskapasiteten øker ikke, men vi tåler at n − 1 av n disker
går i stykker samtidig. Linux optimaliserer lesing fra RAID-1 ved å alltid lese fra
den disken som har lesehodene nærmest det som skal leses, det kan gi en brukbar
ytelsesforbedring. Skriving skjer parallelt til alle diskene, og kan gå langsommere hvis
det ikke er overføringskapasitet nok. Ettersom kapasiteten ikke øker med flere disker er
det sjelden man bruker mer enn 2 eller 3 disker på dette viset.
I tillegg til diskene som er med i raid-1 kan vi ha en eller flere reservedisker13 . Dette er
disker som bare er montert i maskinen uten å brukes. Hvis en raid-1 disk ryker tas en
reservedisk disk i bruk automatisk, og oppdateres med data fra en disk som er i orden.
Dermed blir tiden uten ekstra sikkerhet veldig kort. Systemadministrator kan deretter
fjerne den ødelagte disken ved en passende anledning, og montere en ny disk som blir ny
reserve.
Her ser vi hvordan raid-1 fungerer. De to diskene A og B inneholder det samme. Hver
raid-blokk er lagret to ganger. Vi kan ha mer enn to disker i raid-1, men det er ikke vanlig.
Sikkerheten (og prisen) øker med flere disker, men ikke kapasiteten.
13 eng:
hot spare
Flere harddisker
side 15 av 38
Virkelige disker
z
}|
A0 = R0
A1 = R1
A2 = R2
A3 = R3
..
.
+
Ax−1 = Rx−1
Raid-1
{
B0 = R0
B1 = R1
B2 = R2
B3 = R3
..
.
=
z }| {
R0
R1
R2
R3
..
.
Bx−1 = Rx−1
Rx−1
RAID-4
Øker lagringskapasitet og sikkerhet. Med n disker økes kapasiteten n − 1 ganger. Den n −
1 første diskene brukes til striping, akkurat som RAID-0. Den siste disken er paritetsdisk.
Hver byte på paritetsdisken inneholder en xor-sum av tilsvarende bytes på de n − 1
diskene i stripesettet. Hvis vi skulle miste én disk, kan innholdet på den beregnes som
en xor-sum av de andre diskene og paritetsdisken. Hvis vi derimot mister paritetsdisken,
kan den beregnes på nytt ut fra de andre.
Til tross for mange gode egenskaper, som god kapasitet og sikkerhet, brukes ikke RAID4. Problemet er paritetsdisken. Hver gang vi oppdaterer én av de andre diskene, må
paritetsdisken også oppdateres. Men siden det er n − 1 «normale» disker blir det n − 1
ganger så mange skriveoperasjoner på paritetsdisken. Da vi ikke kan få kjøpt disker
som er n − 1 ganger så raske som de andre diskene våre, blir paritetsdisken en plagsom
flaskehals som begrenser ytelsen for RAID-4 settet. Dette problemet løses fullstendig
med RAID-5. Grunnen til at jeg tar med informasjon om raid-4, er at det fungerer som
en introduksjon for raid-5.
Her ser vi hvordan et raid-4 sett med fire disker blir seende ut. Diskene A, B og C fungerer
på akkurat samme måte som et raid-0 sett med tre disker. I tillegg ligger paritetsdata på
disk D.
Virkelige disker
z
A0 = R0
A1 = R3
A2 = R6
A3 = R9
..
.
Ax = R3x−3
+
B0 = R1
B1 = R4
B2 = R7
B3 = R10
..
.
Bx = R3x−2
}|
+
C0 = R2
C1 = R5
C2 = R8
C3 = R11
..
.
Cx = R3x−1
Raid-5
+
D0 = p0
D1 = p1
D2 = p2
D3 = p3
..
.
Dx = px−1
{
z
=
}|
{
Stripe 0
Stripe 1
Stripe 2
Stripe 3
..
.
Stripe x − 1
side 16 av 38
RAID-5
RAID-5 fungerer akkurat som RAID-4, men med én viktig forskjell: Paritetsinformasjonen ligger ikke på én disk, men spres utover alle de n diskene. Enhver oppdatering
skriver til to disker, data lagres på én og paritetsinformasjon på en annen. Men siden
paritetsinformasjon havner på ulike disker avhengig av hvilken diskblokk det gjelder, så
er det ingen av diskene som overbelastes.
Både lagringskapasitet og sikkerhet øker. Med n disker økes kapasiteten n − 1 ganger.
Hvis én disk ryker mister vi ingen data. Den ødelagte disken kan byttes ut og innholdet
på den gjenskapes. Ytelsen ved lesing kan i beste fall øke n − 1 ganger, skriving kan det
være verre med. Raid-5 kan benytte reservedisker, akkurat som raid-1. Ytelsesproblemer
ved skriving kommer av følgende: Ved skriving må vi i tillegg til data-sektoren også
oppdatere paritetssektoren. Hvis denne informasjonen ikke er i cache, må den leses inn
først. Dette tar tid.
Anvendelser som stort sett leser fra diskene virker bra med raid-5, fordi lesing kan
gjøres parallelt på samme måte som for raid-0. Anvendelser som stort sett skriver store
datamengder går også fort; hvis en skriver et datasett så stort at det trenger en blokk
fra hver disk er det nemlig ikke nødvendig å lese inn paritetsinformasjon. Fordi alle
sektorene i en stripe oppdateres samtidig vil linux kunne generere paritetsinformasjon ut
fra data som skrives.
Anvendelser som stadig skriver mindre datamengder her og der, vil forsinkes ganske
mye av paritetsoppdateringene. Raid-5 er dermed ikke egnet til alle anvendelser, travle
filtjenere og oracle-databaser sies å være spesielt uheldige kombinert med raid-5.
Når det er nødvendig med svært høy io-kapasitet kan vi få et annet problem; prosessoren
overbelastes med paritetsberegninger. Dette er imidlertid bare et problem for softwareraid, en raid-kontroller som gjør slikt i hardware avlaster cpu i slike tilfeller.
Her ser vi hvordan raid-5 fungerer. Figuren er nesten den samme som for raid-4. Linja
med 0-blokkene er lik, legg merke til hvordan paritetsblokken flyttes fra disk til disk
etterhvert som vi kommer nedover. I en normal installasjon er det mange flere blokker,
og når paritetsblokken har kommet frem til første disk begynner den på den siste igjen
slik at mønsteret gjentar seg.
Virkelige disker
Raid-5
z
}|
{
z }| {
A0 = R0
B0 = R1
C0 = R2
D0 = p0
Stripe 0
A1 = R3
B1 = R4
C1 = p1
D1 = R5
Stripe 1
A2 = R6 + B2 = p2 + C2 = R7 + D2 = R8 = Stripe 2
A3 = p3
B3 = R9
C3 = R10
D3 = R11
Stripe 3
..
..
..
..
..
.
.
.
.
.
Flere harddisker
side 17 av 38
RAID-6
RAID-6 er forholdsvis nytt. Det ligner RAID-5, men tåler at 2 hvilke som helst disker
ryker samtidig uten å tape data. Med n disker økes kapasiteten med n − 2. De som er
interessert i hvordan RAID-6 fungerer kan ta en titt på:
Eksempel14
http://www.acnc.com/04_01_06.html
Matematikken bak http://kernel.org/pub/linux/kernel/people/hpa/
raid6.pdf
Også raid-6 kan ha reservedisker klare i fall noe skulle skje. Problemene med io-kapasitet
og cpu-belastning er verre enn for raid-5. Hver skriving oppdaterer i tillegg to paritetsdisker og beregner to ulike sorter paritet. Dette må som regel gjøres i software, da få
kontrollere har støtte for RAID-6.
Det finnes de som mener raid-5/6 har utspilt sin rolle på grunn av ytelsesproblemet ved
paritetsoppdateringer. Teknikker som raid-1+0 har langt bedre ytelse og tåler også bedre
tap av disker. Man trenger selvsagt flere disker for å få samme kapasitet som raid-5/6,
men dette kan man tjene inn med mindre venting på grunn av høyere overføringskapasitet,
og bedre håndtering av diskkræsj. Disker koster ikke så mye som de en gang gjorde. Skal
man ha bra fart i sakene, er det raid-10 som gjelder.
Raid i flere nivåer
Komponenter i et RAID-system behøver ikke være enkeltdisker. En komponent kan også
være et annet RAID-sett. Dette kalles å bruke RAID i flere nivåer.
RAID-5+1
En kombinasjon for de som krever høy sikkerhet, er å ha to like store RAID-5 sett, og
så slå disse sammen med speiling. Dermed tåler vi å miste opptil tre disker på en gang.
Mister vi 3 disker i ett RAID-5 sett er det naturligvis dødt, men på grunn av speilingen
får vi data fra det andre RAID-5 settet. Mister vi 2 disker på det ene RAID-5 settet, er
det også dødt, men data er fortsatt tilgjengelig fra det andre settet som bare har mistet én
disk. Vi må miste minst to disker på hvert RAID-5 sett før vi mister data. Med n disker i
en slik kombinasjon blir kapasiteten n2 − 1.
RAID-10
En annen kombinasjon som brukes en del, er RAID 1+0. Dette kalles også RAID-10. Her
har vi flere RAID-1 sett som består av parvis like disker. Disse settene stripes deretter
side 18 av 38
sammen for å oppnå større kapasitet. Her tåler vi alltid å miste én disk, siden den andre i
paret fortsatt virker. Vi tåler også å miste mange disker, så lenge vi ikke mister to disker i
samme RAID-1 sett. Med to disker i hvert RAID-1 sett og n disker, blir kapasiteten n/2.
Denne varianten gir høy ytelse, også om den er implementert i software. Her er det ingen
problemer med tidkrevende paritetsberegninger. For å unngå å miste to disker i samme
speil, lager man gjerne speilparene av disker fra ulike produsenter. Ulik teknologi gjør
gjerne at de ikke feiler samtidig under identiske forhold. En bedrift med et slikt oppsett
klarte seg bra når samtlige disker fra en produsent gikk dukken i løpet av noen uker, det
var gjort feil i produksjonen. Mange røk samtidig, men de var altså speilet mot disker fra
en annen produsent som ikke hadde det samme problemet.
Vær oppmerksom på at kombinasjonen RAID 0+1 ikke er like sikker som raid 1+0. (To
store stripe-sett kombinert med speiling.) RAID 0+1 tåler forsåvidt å miste én disk, men
sjansen for havari er mye større hvis vi mister to ettersom sjansen er omtrent 1/2 for at de
to ødelagte diskene er i hvert sitt speil.
Mange PC-hovedkort leveres med en begrenset mulighet for raid-10, der to og to disker
speiles og så kjører man raid-1 på toppen av de to speilene. Men RAID-10 kan være mer
enn opplegg med akkurat fire disker. Det er fullt mulig å ha RAID-1 over mer enn to
speilsett. Og et speilsett kan forsåvidt inneholde mer enn to disker også, hvis man vil ha
mye redundans.
Linux RAID-10
Så langt er beskrivelsen av RAID-10 generelt og passer for de fleste operativsystemer.
Linux har imidlertid noen ekstra muligheter. Vi kan f.eks. ha RAID-10 med 3 disker og
dobbeltlagring. Eller 5 disker. Vi kan også ha opplegg hvor datablokker lagres mer enn 2
ganger, f.eks. 5 disker med tredobbelt lagring. eksemplene blir som følger:
Vanl. 2 disker
A
B
0
0
1
1
2
2
3
...
3 disker, A–C
A B
C
0 0
1
1 2
2
3 3
4
4 ...
A
0
2
5
7
5 disker, A–E
B C D
0 1 1
3 3 4
5 6 6
8 8 ...
E
2
4
7
5 disker, tredobbelt
A B C D E
0 0 0 1 1
1 2 2 2 3
3 3 4 4 4
5 5 5 ...
I stedet for å legge kopiene rett etter hverandre, har linux mulighet for å organisere
blokkene slik at den første halvparten av diskene ser ut akkurat som raid-0 (striping). På
den andre halvparten av diskene kommer kopiene av blokkene. På dette viset kan raid-10
leses like raskt som raid-0, og likevel ha samme sikkerhet som raid-1. Skriving kan bli
langsommere på dette viset, men mange anvendelser har mye mer lesing enn skriving.
Dessuten venter vi som regel ikke på treg skriving, fordi det skjer i bakgrunnen. Men
Flere harddisker
side 19 av 38
for lesing har vi ikke noe valg, vi får ikke resultatene før de er lest inn. Denne typen
RAID-10 med 2 disker vil se slik ut:
A
0
2
...
1
3
B
1
3
...
0
2
Implementasjoner i hardware og software
Hardware raid går ut på å ha en spesiell diskkontroller som tar seg av raid-funksjonalitet
for disker koblet til kontrolleren. Operativsystemet trenger dermed ikke bruke tid på
dette, for linux ser en raid-enhet ut som en hvilken som helst annen disk. Dette kan være
en fordel med raid-5, da beregning av sjekksummer både tar tid og ekstra io-kapasitet.
Fordelen er mindre med raid-1 og raid-0, da disse er så enkle at de ikke stjeler noen
kapasitet av betydning.
Software-raid går ut på å bruke vanlige diskkontrollere, og la linux gjøre jobben med
å beregne sjekksummer (for raid-5) og doble eller splitte opp io-operasjoner for raid1 og raid-0. Fordelen med dette er fleksibilitet. Diskene i et software-raid kan være
spredt på flere kontrollere. Disse behøver ikke være fra samme leverandør, de kan til og
med være av ulik type, f.eks. både SATA og SCSI. Flere kontrollere gir bedre ytelse,
ettersom hver kontroller har sine egne begrensninger. Dessuten arbeider software-raid
med partisjoner, ikke hele disker. Når budsjettet setter begrensninger kan vi dermed ha
en to-disk tjener hvor deler av de to diskene brukes til et raid-1 for data vi ikke tåler
å miste, f.eks hjemmemapper. Resten av de to diskene kan brukes til mindre kritiske
data. Operativsystemet er, overraskende for noen, lite kritisk. Dette fordi det lett kan
reinstalleres ved behov. Webcache og /tmp er andre eksempler på lite kritiske data.
Raid og planlegging
Vær oppmerksom på at siden raid får flere disker til å tilsynelatende fremstå som én, så
har vi ingen innflytelse på hvordan data organiseres innenfor ett raid-sett. Planlegging
som i avsnitt 1.3.2 på side 12, av hvilke filer eller tjenester som havner på hvilken disk
innenfor ett raid5-sett er altså umulig. Med tilstrekkelig mange disker kan en forsåvidt
ha flere separate raid-sett, for ulike anvendelser. Da blir maskinen ganske stor, en får fort
bruk for et ekstra kabinett til diskene. En maskin med mange disker har også lett for å
trenge ekstra strømforsyning.
side 20 av 38
Hvis du planlegger en stor filtjener, sjekk hvor mange watt diskene og andre komponenter
trenger. Så sørger du får tilstrekkelig kraftig strømforsyning, eller evt. separat strøm til
diskene.
Raid i praksis, og partisjoner
Hardware-raid settes opp ved hjelp av programvare som følger med raid-kontrolleren.
Ofte skjer dette ved hjelp av kontrollerens BIOS-oppsett, som aktiveres ved å trykke en
bestemt tast når maskinen starter opp.
Software-raid settes opp ved hjelp av programmet mdadm15 . De som er interessert, kan
installere debianpakken mdadm og lese man-sider og annen dokumentasjon.
Så langt har vi sett på RAID som en sammenstilling av hele disker. Software-raid i linux
tillater imidlertid at vi setter sammen ulike diskpartisjoner i RAID. Et eksempel: Vi
har to harddisker, hver med to partisjoner. Altså hda1, hda2, hdb1 og hdb2. Her kan vi
f.eks. kombinere hda1 og hdb1 med RAID-1, for å få økt sikkerhet. Vi kan fortsatt bruke
hda2 og hdb2 som separate partisjoner med egne filsystemer. De to partisjonene hda1 og
hdb1 er ikke tilgjengelige for å legge vanlige filsystemer på, de er nå slått sammen til
en ny enhet, kalt md0. Første raid-enhet får navnet md0, den andre får navnet md1 osv.
Tallene har altså ingenting å gjøre med hvorvidt det er raid-1, raid-0 eller raid-5. For å
legge et filsystem på vår nye sikre raid1-enhet, bruker vi mkfs og oppretter filsystemet
på /dev/md0. For å bruke dette filsystemet, legger vi /dev/md0 inn i /etc/fstab hvor alle
filsystemene er listet opp.
Sett aldri sammen flere partisjoner fra samme disk til en RAID-enhet. Ytelsen blir elendig
fordi lesehodene hele tiden må flytte seg mellom de to partisjonene, og sikkerheten uteblir
helt ettersom begge partisjoner ryker hvis hele disken ryker.
Til slutt vil jeg nevne at raid-enheter kan partisjoneres. Dette er nokså nytt. I eksempelet
over kunne vi altså ha delt opp /dev/md0 i partisjoner som /dev/md0p1, /dev/md0p2 og så
videre. Hvis en har kompliserte diskoppsett bør en ta notater i maskinens loggbok, slike
notater er gode å ha hvis det noensinne blir problemer med oppsettet.
1.3.4 Mer informasjon
For mer informasjon om harddisker og partisjonering, se http://www.tldp.org/
HOWTO/Multi-Disk-HOWTO.html. Dette bør leses!
15 multi-disk
administration
Filsystemer
side 21 av 38
1.4 Filsystemer
1.4.1 Ext2 – enkelt og raskt
Det finnes mange filsystemer for linux, og flere av dem kan være aktuelle på en tjener.
Ext2 velprøvd og det eldste av de praktisk brukbare filsystemene. Det er også det raskeste
i vanlig bruk. Ext2 har imidlertid et problem. Hvis filsystemet avbrytes ukontrollert
(strømbrudd, systemkræsj) må det gjennom en tidkrevende sjekk etterpå. Dette fordi
filsystemet kan havne i en tilstand med delvis oppdaterte mapper og strukturer, som må
rettes før filsystemet kan brukes. Sjekken kan ta flere minutter for en håndfull gigabyte,
og den kan dermed bli plagsomt lang med flere ti- eller hundretalls gigabyte.
For mer informasjon om ext2, ta en titt på http://e2fsprogs.sourceforge.
net/ext2intro.html.
1.4.2 Ext3 – et journalførende filsystem
Ext3 er stort sett som ext2, men er i tillegg et journalførende filsystem. Journalen øker
datasikkerheten og unngår tidkrevende sjekking etter kræsj. Ulempen er at journaloperasjonene også tar tid, ext3 er dermed ikke fullt så raskt som ext2. En fordel med ext3 er at
man kan konvertere eldre ext2-baserte systemer til ext3. Det går også greit å konvertere
tilbake til ext2 om det skulle bli nødvendig.
Generelt om journalførende filsystemer
Journalføring vil si at alle endringer i filsystemet (blokkallokeringer, forandring av
mapper o.l.) først skrives ut til en journalfil, for deretter å bli skrevet ut på sine riktige
områder på disken. Hvis maskinen kræsjer mens disken oppdateres får vi samme slags
feil i filsystemet som med en ext2-kræsj. Men det er ikke nødvendig å lete etter feil når
maskinen starter opp igjen, det er bare å hente inn de siste oppdateringene fra journalen
og legge dem ut på disken på rett sted. Det tar bare noen sekunder, og deretter vet vi
at filsystemet er i orden og klart til bruk. Hvis maskinen kræsjer mens ext3 oppdaterer
journalen får vi en ødelagt journal, men på et slikt tidspunkt er det garantert ingen
halvgjorte forandringer i filsystemet. Når maskinen starter opp igjen kan den dermed
nøye seg med å lage en ny journal, og anta at filsystemet er i stand uten ytterligere
sjekking.
Journalen for ext3 er typisk på 32MB, og ligger vanligvis på en skjult fil. Vi kan imidlertid
få bedre ytelse ved å legge journalen på en annen disk, skriving til journalen vil dermed
ikke konkurrere med vanlig bruk av filsystemet. For maksimal ytelse bruker noen en
side 22 av 38
batteridrevet ram-disk for journalformål. RAM er mye raskere enn en vanlig harddisk,
og batteriene sørger får at ingenting går tapt ved strømbrudd eller kræsj.
Data skrives til journalen til den går full, deretter skrives alt sammen ut på disken også
før ext3 starter en ny omgang i journalen. Journalen har altså fast størrelse, som vi kan
velge når vi oppretter filsystemet.
Alternativer for journalføring i ext3
Ext3 har tre måter å håndtere journalen. «data=writeback» er den raskeste måten,
og tilsvarer måten andre journalførende filsystemer virker på. Det er bare metadata
(mapper, allokeringsinformasjon) som journalføres. Vanlige data, altså innhold i filer,
journalføres ikke. Ved kræsj kan vi dermed garantere at filsystemet er konsistent, men
filer som var åpne da maskinen kræsjet kan inneholde søppel i form av tilfeldige data.
Den viktigste grunnen til å bare journalføre metadata er at det er lite metadata i forhold
til vanlige data, dermed får det lite å si for ytelsen.
Standard-alternativet er «data=ordered». Det er fortsatt bare metadata som journalføres, men metadata overføres ikke til journalen til før data for de tilhørende filene også
er skrevet ut på disken. Dette fører til at data må skrives ut hver gang journalen går full.
Det gir noe dårligere ytelse fordi filene oppdateres oftere, men større sikkerhet ved kræsj.
Etter kræsjet vil det ikke være noen filer med ubrukelig innhold, ettersom innholdet
skrives før journalen. Vi risikerer imidlertid at filer som var i ferd med å bli utvidet blir
kuttet ned i forbindelse med kræsjet.
For maksimal sikkerhet har vi alternativet «data=journal». Med dette alternativet
journalføres alt, både metadata og vanlig data. Det gir dårligere ytelser fordi absolutt
alt må skrives to ganger, først en gang i journalen og deretter en gang på disken. Det
er dermed et tungt alternativ for filsystemer med mye skriving. Til gjengjeld har vi
perfekt sikkerhet, ingenting av det som skrives til disk går tapt ved kræsj! Vær imidlertid
oppmerksom på at et program som var kommet halvveis med å oppdatere en fil fortsatt
etterlater seg en halvveis oppdatert fil etter kræsjet. Hvis programmet er såpass velskrevet
at det kan finne igjen hvor det stoppet går dette bra, ettersom ingenting går tapt. Det er
slett ikke alle programmer som får til dette, men f.eks. en kommersiell database bør klare
det.
Mer informasjon om ext3 finnes på følgende steder:
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
http://www.redhat.com/support/wpapers/redhat/ext3/
Filsystemer
side 23 av 38
1.4.3 Ext4
Ext4 er en videreutvikling basert på ext3, som har høyere ytelse og støtter større filsystemer. Filsystemet kan være opptil en exabyte, og enkeltfiler kan være opptil 16
terabyte. Ext4 har også bedre støtte for SSD; Når en sletter filer på ext4, vil ext4 bruke
TRIM-kommandoen for å gi SSD-disken beskjed om at den aktuelle blokken ikke lenger
er i bruk. SSD-disker slites ved bruk, og minimerer slitasjen ved flytte blokker som
brukes mye til andre deler av flashminnet. Men for å kunne gjøre slikt, må disken vite
hvilke blokker som ikke brukes av filsystemet. Ext4 har også en mer effektiv organisering
av store filer, basert på extents. Dermed gjør det noe mindre arbeid ved oppdatering i
store filer.
Mer informasjon om ext4:
http://ext4.wiki.kernel.org/index.php/Main_Page
http://en.wikipedia.org/wiki/Ext4
1.4.4 Reiserfs
Reiserfs er et annet journalførende filsystem. Det er raskere enn ext3 og mer effektivt
på mapper som inneholder mange16 filer. Det er også mer plass-effektivt når det gjelder
små filer, da det kan lagre flere små filer i én diskblokk. For mer informasjon om reiserfs,
se http://www.namesys.com/
1.4.5 JFS
Dette er linux-versjonen av IBM’s JFS fra AIX. JFS står for «Journalling File System».
Ta en titt på http://oss.software.ibm.com/jfs/ for mer informasjon.
1.4.6 XFS
Dette er et journalførende filsystem utviklet av SGI. Det er utviklet med tanke på høy
ytelse, spesielt for store filer og store mapper. Ta en titt på http://oss.sgi.com/
projects/xfs/ for mer informasjon.
1.4.7 Btrfs
Et av de nyeste og mest eksperimentelle filsystemene for linux. Interessant for de som
forsker på filsystemer. Nå og da sammenlignes det med ext4, sjekk hvorvidt det har bra
16 tusenvis,
titusenvis eller mer
side 24 av 38
ytelse for din type anvendelse før du bruker det. Btrfs har noen imponerende muligheter,
men er ennå ikke raskest/best for alle anvendelser.
Se https://btrfs.wiki.kernel.org/index.php/Main_Page
1.5 Minne
For en tjener bør en ha minne med paritet. Det er litt dyrere, men oppdager evt. feil.
Feil på enkeltbits rettes automatisk, og logges av operativsystemet. Hvis en plages med
minnefeil bør minnet byttes ut. Hvis det ikke hjelper bytter man hovedkort eller prosessor.
En tjener skal ikke ha ustabil hardware! En velkonfigurert linux-tjener skal være så stabil
at tilsynelatende tilfeldige kræsj, som ikke kan spores til et bestemt program eller en
spesiell driver, bør få en til å mistenke og undersøke hardware.
Linux trenger ikke mye minne selv, så lite som noen få titalls megabyte kan fungere17 .
En trenger selvsagt mer for de fleste praktiske anvendelser. Hvis man ønsker å bruke
enkle grafisk brukergrensesnitt er det en god idé å ha minst 128MB. For å bruke mer
krevende gnome/kde, kan 1 GB være praktisk. Det grafiske brukergrensesnittet er praktisk
å ha installert for administrasjonsbruk. Men siden tjenere ofte står for selv mesteparten
av tiden velger mange å bare starte det opp ved behov. Dermed kan minnet nyttes til
andre formål, som f.eks. diskcache. Det er sjelden man behøver å sette seg ned ved en
linux-tjener, all programvare for administrasjon (både tekst- og grafikkbasert) kan kjøres
via nettverket18 . Grafiske programmer kan fint kjøres via nett selv om tjeneren ikke har
noe skjermkort i det hele tatt.
Ellers må en se på minnebehovene for programmene en kjører. Dette oppgis gjerne i
et grunnbehov pluss en mengde minne per bruker. Se http://linuxselfhelp.
com/HOWTO/HP-HOWTO/linux-intranet.html for noen eksempler på dette.
Filtjeneren SAMBA bruker f.eks. ca. 800kB per bruker.
Når tjeneren er i gang kan man bruke kommandoen «vmstat 1» for å se hvordan
minnet og diskene brukes. Hvis det er mye swapping, ser vi at tallene kolonnene si og
so19 er større enn 0 mesteparten av tiden. Da kan det være fornuftig med mer minne.
17 8MB
kan være nok i en maskin som brukes som ruter og evt. brannmur. Nye maskiner har alltid mye mer,
en får ikke lenger kjøpt så små minnebrikker.
18 Vi ser på fjernadministrasjon i en senere leksjon
19 si: swap in, so: swap out
Prosessor
side 25 av 38
1.6 Prosessor
Man skal ha mange brukere for at prosessoren skal bli en begrensning, dette fordi linux
utnytter prosessoren veldig effektivt. Hvis tjeneren har andre og tyngre oppgaver, som
f.eks. databaser, stadig kompilering på en utviklingstjener, produksjon av animasjoner
e.l., kan dette skje. Kjør i så fall top. Hvis belastningen (load) er over 1 over tid er
prosessoren for svak. En raskere prosessor, eller en løsning med fler prosessorkjerner vil
hjelpe.
Eksempel på top
Se figur 1.1
Figur 1.1: Eksempel på top
Her ser vi at kompilatoren (cc1) bruker 26% av cputiden, mens resten av programmene
bruker veldig lite. Det er 107 programmer i gang, belastningen er på 0.33, dvs. 33% av
hva prosessoren kan klare. For øyeblikket er det altså ingen mangel på prosessorkraft.
Hvis noen lurer på hvorfor kompilatoren ikke bruker resten av prosessorkraften er det
side 26 av 38
flere grunner til det. Innimellom venter den på å få lest programkode fra harddisken,
andre ganger stopper den når den er ferdig med en fil og startes opp igjen for den neste.
Prosesser med kort levetid rapporteres ikke presist av verktøyet top.
Kort forklaring av kolonnene:
PID
Process ID. Et greit nummer å vite f.eks. hvis vi ønsker å drepe en brysom
prosess med kommandoen kill.
USER
Brukeren som kjører prosessen, så vet vi hvem vi kan kjefte på. :-)
PR
Prioritet.
NI
Nice. Positivt tall betyr en «snill» prosess som kjører med lavere prioritet
og dermed slipper til andre prosesser oftere. Negativt tall betyr en «ikkesnill» prosess som har fått ekstra høy prioritet. Høy prioritet brukes gjerne
for midi-synthesizere og lydmiksere, vi vil ikke at lyden skal hakke bare
fordi det kommer inn en epost e.l.
VIRT
Hvor mye virtuelt minne prosessen bruker. Tallet er overdrevet, prosesser
får omtrent aldri bruk for alt. Og noe er gjerne delt med andre prosesser
også.
RES
Resident size – hvor mye virkelig minne prosessen bruker nå.
SHR
Hvor mye av minnet som er delt minne. Dette er minne som går med til
delte biblioteker, f.eks. C-bibliotek og brukergrensesnitt-biblioteker. Slikt
minne er delt mellom alle prosesser som bruker den delte ressursen, og er
dermed mye mindre problematisk enn den delen av RES som ikke er med
i SHR.
S
State, tilstand. S=Sovende, R=kjører
%CPU
Prosentandel av cpu-kapasiteten prosessen bruker.
%MEM
Tilsvarende for fysisk minne.
TIME+
Hvor mye cputid prosessen har brukt frem til nå.
COMMAND Kommandoen brukt for å starte prosessen.
1.7 Nettverk
Linux støtter de fleste PCI-baserte 10Mb/s–10Gb/s ethernet nettverkskort. Se http:
//www.scyld.com/network/ for detaljer. Hvis man bruker kort med flere porter,
pass på at det ikke bare er et kort med ett enkelt interface og en innebygd hub. (En hub
har flere plugger, men overføringskapasiteten øker ikke når man bruker flere av dem.
Dette fordi bare én kan brukes om gangen!)
Andre maskinvarebehov
side 27 av 38
1.8 Andre maskinvarebehov
Hva slags skjerm og skjermkort en bruker er ikke viktig, ettersom skjermen bare brukes
til administrasjon og ikke tjener-oppgaver.
CD/DVD spillere kan deles ut over nett akkurat som harddisker. I så fall er det lurt å
investere i raske spillere.
Jeg anbefaler å selv kompilere linuxkjernen for en tjener. Velg riktig prosessortype, så
blir den noe raskere enn de generelle kjernene som leveres med distribusjonene. Dette er
også en fordel sikkerhetsmessig. Hvis det kommer en viktig sikkerhetsoppgradering er
det bare å patche koden man har liggende og kompilere. Dermed har man sikret seg flere
dager eller uker før distribusjonen.
1.9 Teksteditorer
En editor20 er et program for å redigere tekst. Til forskjell fra en tekstbehandler, opererer
en editor på rene tekstfiler uten formatering. Du kan altså ikke velge skrifttyper og slikt.
Siden så og si all systemkonfigurering på linux gjøres ved å redigere tekstfiler, er det
viktig å ha en god editor og kunne bruke den skikkelig. Når du bruker din favoritt-editor,
bør du ihvertfall mestre disse funksjonene:
• Skrive inn og slette tekst.
• Søke etter, og evt. bytte ut tekst.
• Kopiere/flytte tekst fra ett sted til et annet.
• Avslutte med eller uten lagring.
Nokså banalt, men hvis du er nybegynner med linux vet du ikke nødvendigvis hvordan alt
dette gjøres i en ukjent editor. Ofte nok har jeg sett studenter som sitter og skriver lange
kompliserte kommandoer om igjen når de kunne kopiert alt sammen på et par sekunder.
Derfor, finn deg en editor du trives med (linux har mange!) og lær den skikkelig. Det vil
du spare mye tid og tastetrykk på.
Noen editorer er enkle, og tilbyr ikke så mye mer enn funksjonene ovenfor. Andre er
mer kompliserte og har massevis av tilleggsfunksjoner. Den mest ekstreme er emacs,
som tilbyr enhver funksjon man kan tenke seg i en editor. Og en del mer — av de mer
spesielle ting emacs tilbyr er innebygd nettleser, epostklient, diverse spill o.l.
Noen av de mer praktiske tingene du finner i avanserte teksteditorer:
20 Fra
engelsk, edit betyr redigere.
side 28 av 38
• Søk med regulære uttrykk,21 der du kan søke etter mer avanserte sammenhenger
enn enkeltord. Du kan f.eks. angi slike ting som:
◦ Flere ord med ukjent mengde tilfeldig tekst imellom. Aktuelt når bare ett
søkeord finnes mange steder, mens kombinasjonen av flere finnes få steder.
◦ Lete spesielt etter start og slutt på linja. Ofte aktuelt når en søker etter
kommandoer, og ved søk i kildekodefiler og script.
◦ Ulike stavemåter for samme ord, i ett søk. Greit når en er usikker på stavemåten. Vær oppmerksom på at samme ord med store eller små bokstaver typisk
er ulikt!
• Syntax highlighting, som passer for linux konfigurasjonsfiler, html/xml, shellscript
og de fleste programmeringsspråk. Nøkkelord og tekststrenger utheves slik at det
er lettere å se strukturen i filen.
• Parentesmatching. Når markøren flyttes over tegn som {[()]} uthever editoren også
det motstående tegnet. Dermed er det lett å oppdage parentesfeil. Gjør programmering greiere ved å avsløre feil.
• Integrerte utviklingsmiljø, som gjør det mulig å kompilere/testkjøre programmer
direkte fra editoren. Editoren emacs har dette for de fleste programmeringsspråk.
1.9.1 Grafisk eller tekstbasert editor?
Grafiske editorer ser penere ut, og forutsetter at du har installert det grafiske brukergrensesnittet. De har som regel bedre støtte for mus enn de tekstbaserte editorene, og
kan også ha menyer som gjør det enkelt for nybegynnere å finne frem i de mer avanserte
funksjonene. Ofte oppgis aktuelle hurtigtaster i menyene, og jeg anbefaler på det sterkeste
å lære å bruke hurtigtastene for mye brukte funksjoner, som søk/erstatt og lagring.
Tekstbaserte editorer trenger ikke grafisk brukergrensesnitt, og kan derfor brukes også når
grafikken ikke er tilgjengelig. 22 Slike editorer kan selvsagt brukes innenfor det grafiske
miljøet også, da kjøres de i en terminalemulator som xterm. Tekstbaserte editorer har
vanligvis mindre støtte for mus. Det er f.eks. vanlig at du ikke kan posisjonere markøren
med musen, du må bruke piltastene. Musen kan likevel brukes til å kopiere og lime inn
tekst, hvis det grafiske brukergrensesnittet er i drift. En tekstbasert editor starter gjerne
raskere enn de grafiske.
Noen av de aller enkleste tekstbaserte editorene brekker om linjer hvis de blir «for
lange». Det er jo greit hvis man skriver et brev, noe som nesten ingen lenger bruker
21 Eng:
regular expressions
vindussystemet mangler/kræsjet, eller fordi du fjernstyrer maskinen over en forbindelse som er for
treg for grafikk. Eller du fjernstyrer fra en standard windowspc som ikke støtter linux-grafikk.
22 Fordi
Teksteditorer
side 29 av 38
teksteditorer til. Det passer veldig dårlig hvis man redigerer en konfigurasjonsfil eller
kildekode. Editoren pico/nano har dette problemet, jeg anbefaler at du lærer deg å
bruke en bedre editor enn det!
Noen editorer fins både i grafisk og tekstbasert versjon. Det gjelder f.eks. emacs og
vim/gvim. Dermed kan en bruke den samme editoren og likevel utnytte brukergrensesnittet optimalt.
1.9.2 Noen editorer
pico/nano
Veldig enkel å bruke, alle hurtigtaster vises på skjermen hele tiden.
Denne har dessverre ombrekkingsproblemet. For den som vil jobbe en
del med linux, anbefaler jeg å satse på noe bedre.
emacs
Stort tungt program, om enn ikke så tungt som en tekstbehandler. Har
«alt», men kan ta tid å lære seg. Den grafiske varianten har menysystem.
vi/nvi/vim/gvim Lettstartet kjapp editor. Uvant for begynnere, men kan brukes effektivt. Det fins mange varianter av vi, noen har mange nyttige tilleggsfunksjoner som syntax highlight o.l. Den grafiske varianten gvim har
brukervennlig menysystem.
yudit
Det spesielle for denne grafiske editoren er at den har veldig god støtte
for unicode. Den har dermed ingen problemer med norske bokstaver,
eurosymbolet, eller andre skriftsystemer som kyrillisk, gresk og kinesisk. Tekstfiler kan også konverteres mellom ulike kodesystemer som
unicode, 8-bits iso8859-koder tidligere brukt på linux, og codepagesystemet som windows bruker.
1.9.3 Teksteditoren vi
Hvorfor vi
Editoren vi er elsket av noen, og hatet av mange andre. En administrator som ikke
liker vi står selvfølgelig fritt til å installere noe annet. Teksteditorer for linux fins i
bøtter og spann, både grafiske og tekstbaserte. Grunnen til at alle bør kjenne litt til vi
er at den praktisk talt alltid er tilgjengelig. Hvis X23 streiker en dag må du rette opp
feil i konfigurasjonsfiler uten grafiske editorer, og vi klarer seg fint uten grafikk. (Det
finnes forsåvidt flere andre tekstbaserte editorer også.) Et nyinstallert linuxsystem har
ikke nødvendigvis andre editorer installert, og hvis du må boote fra en redningsdiskett
23 Vindussystemet
i linux
side 30 av 38
i et forsøk på å berge et system med alvorlig disktrøbbel e.l. er sannsynligvis vi den
eneste editoren som er liten nok til at den finnes på disketten. Det samme gjelder når
maskinen kræsjer i boot og vi sitter med en veldig begrenset bootloader, før rotfilsystemet
er montert.
Hvordan bruke vi, og litt historie
I dag kan vi virke temmelig sær på noen områder, f.eks. det faktum at en må trykke
i før det går an å skrive inn tekst. Dette har å gjøre med at vi ble laget før musen
ble oppfunnet, og en del tastaturer på den tiden hadde heller ikke piltaster for å flytte
på markøren. De fleste tastaturer hadde mer enn bare bokstaver og tall, men det de
hadde ekstra var lite standardisert bortsett fra tab, shift og ctrl. Selv vanlige taster som
enter/return og backspace kunne variere en del i funksjonalitet24 .
En teksteditor som vi trengte imidlertid en måte å flytte markøren på, i alle fire retninger.
Og det kunne ikke være en tungvint måte heller, så kompliserte kombinasjoner av
tastetrykk var utelukket. Det er fremdeles slik at en som virkelig er god i vi kan
redigere svært raskt, raskere enn hva en får til med mange av de mer «brukervennlige»
programmene. Det tar tid å bli så god, men tastatur er mye raskere enn mus for den
som kan å bruke det effektivt. For å få en enkel måte å flytte markøren, som virket på
alle tastaturer, falt valget på tastene h j k l. Prøv gjerne dette i vi. Disse tastene brukes
selvsagt også for å skrive tekst, så vi har to modus — kommandomodus og inputmodus.
Kommandomodus er aktivt når vi starter opp. Da kan vi flytte markøren (med h j k l
eller vanlige piltaster), og slette tegn med x. Mange andre bokstaver fungerer også som
kommandoer til vi. Kommandomodus er aktivt ved oppstart for at du raskt skal kunne
flytte deg rundt i filen til det stedet du vil gjøre forandringer.
En del kommandoer aktiverer inputmodus, f.eks. i. Deretter kan du skrive som normalt.
På et moderne tastatur fungerer piltastene også i inputmodus, så du kan flytte deg rundt i
fila uten å måtte gå tilbake til kommandomodus igjen.
Det neste nybegynnere setter seg fast i etter å ha lært om i, er problemet med å lagre og
avslutte. Jeg har selv opplevd frustrasjonen ved å ikke få til dette – jeg ble nødt til å drepe
vi-prosessen og mistet alle endringer. Her er oppskriften: Trykk escape for å bytte fra
inputmodus til kommandomodus. Deretter :w fulgt av enter om du vil lagre, og :q fulgt
av enter for å avslutte vi. For å både lagre og avslutte kan du bruke :wq fulgt av enter.
24 PC-tastaturer har både backspace (merket «←») og delete, som fungerer ulikt. Det har vært mange tastaturer
som bare hadde den ene eller den andre. PC-tastaturer har også både return og enter, plassert henholdsvis
på det alfabetiske og det numeriske tastaturet. På en PC gjør disse to som regel samme jobb, men historisk
har det vært nok av forskjeller. De gjør f.eks. forskjellig jobb på IBM stormaskiner. Frustrasjonen har til
tider vært stor hos de som har måttet bytte fra et slags tastatur til et annet. I dag opplever vi en mildere
variant av slike problemer når tastaturet feilaktig settes opp etter amerikansk standard.
Kompilere en linuxkjerne
side 31 av 38
Generelt kan man kombinere kommandoer i vi. Kolon angir at du vil gi en kommando,
w står for write og q står for quit. Hvis du prøver å avslutte uten å lagre nekter vi, men
du kan bruke utropstegnet for å angi at du virkelig vil utføre en slik «farlig» kommando.
Avslutte uten å lagre blir altså :q! fulgt av enter.
Klipp- og lim-funksjoner finnes også i vi. yy kopierer linja markøren står på, og p limer
inn kopien på linja etter den som markøren står på. I mellomtiden kan man selvsagt flytte
markøren, så linjer kan kopieres hvor som helst. Har en det grafiske brukergrensesnittet
i drift, kan en også merke tekst med musen og lime inn ved å trykke midtknappen.
Kommandoen man vi gir noe mer informasjon om vi, og komplett dokumentasjon
finnes på nettet.
Varianter av vi
Siden vi er såpass populær, finnes det nyere versjoner med utvidet funksjonalitet.
Prøv f.eks. vim (apt-get install vim) som er mer moderne og enklere i bruk.
gvim har grafikk og menyer, menyene angir dessuten hvilke hurtigtaster du kan bruke i
kommandomodus.
Menyene gjør livet lettere for nybegynnere, men lær deg de mest brukte tastekombinasjonene også. Det går mye raskere å bruke tastaturet, hvis du skriver etter touch-metoden og
slipper å strekke deg etter musa i utide. Dessuten er det kjekt å kunne noen kommandoer
utenat når du i blant trenger å jobbe i tekstmodus.
1.10 Kompilere en linuxkjerne
1.10.1 Hvorfor
Distribusjonen din har installert en kjerne, så hvorfor kompilere en ny? Det er mange
grunner:
• En ny kjerne har gjerne sikkerhetsoppdateringer og ytelsesforbedringer som ikke
fins i den gamle.
• Den nye kjernen kan ha drivere for utstyr den gamle ikke kjenner, eller nye
protokoller og filsystemer.
• Ved å kompilere selv kan du optimalisere kjernen for din prosessor. Det kan gi
ytelsesforbedringer, til og med om det er samme kjerneversjon som distribusjonen
bruker. Distribusjoner går gjerne inn for en kjerne som skal virke overalt, og
kompilerer derfor for 386 eller enkleste sort pentium. Hvis du har noe bedre, som
f.eks en i7-prosessor, har du noe å vinne. Og det gjelder nok de fleste av oss.
side 32 av 38
• Du kan ha bruk for spesielle kjernepatcher eller drivere som ikke er med i distribusjonen. Noen programmer krever en oppdatert kjerne.
• Prestisjen ved å ha «denne ukas25 linuxkjerne»!
1.10.2 Programpakker du trenger
For å kompilere en kjerne, trenger du foruten kildekoden en del programvare for programutvikling. Spesielt må du ha en passende teksteditor, kompilatoren gcc, og programmer
som make, diff, og patch.
Hvis du mangler noe av dette, bør du installere følgende debian-pakker: gcc, make,
patch, diff, libncurses5, xz-utils, bzip2, gzip, tar. Ennå enklere er det å installere pakka
build-essentials som selv sørger for at alle de andre pakkene er på plass.
1.10.3 Laste ned kode
Kildekode laster du ned fra http://ftp.kernel.org/pub/linux/kernel. I
skrivende stund er den nyeste kjernen v3.x/linux-3.2.2.tar.xz. Når du leser dette har det
muligens kommet en nyere, det er gjerne 4–6 uker mellom versjonene.
Pakk ut den komprimerte filen. Det er vanlig å bruke mappa /usr/src, eller evt. hjemmemappa.
1.10.4 Eventuelle patcher
Hvorfor patcher
Kildekoden er i utgangspunktet komplett, men noen ganger ønsker en å bruke nye
eksperimentelle drivere, protokoller, uprøvde feilrettinger eller andre tilpasninger. Slikt
lastes ned i form av patcher til kildekoden.
Hva er en patch
En patch er en liten fil som forteller hva som skal være anderledes enn standardkoden.
Ettersom patchen bare inneholder forskjeller, blir den mye mindre enn om forfatteren
skulle distribuert et komplett sett med kildekode. En patch er typisk fra noen få hundre
25 Å
ha nyeste kjerne på en privatmaskin er gøy, vær mer forsiktig med en tjenermaskin. Uansett pleier vi
ikke reboote tjenere like ofte som nye kjerner kommer ut. For tiden kommer det en kjerne ca. annenhver
måned, men en tjenermaskin kan godt være i drift i flere år sammenhengende.
Kompilere en linuxkjerne
side 33 av 38
byte opptil noen få megabyte, komplett kildekoden for kjernen er på over 800MB.
Systemet med patcher gjør det også lettere å kombinere flere uavhengige tilpasninger, så
lenge to patcher ikke opererer på samme del av samme fil går det greit.
Hvordan bruke en patch
Bruk kommandolinja, og skift til mappa hvor linuxkjernen er. Vanligvis legger man en
patch til kildekoden slik:
patch -p1 < patchfil
Skulle en senere angre på dette fjernes patchen slik:
patch -p1 -R < patchfil
Store patcher er gjerne komprimerte, de anvendes med en av følgende kommandoer:
zcat patchfil.gz | patch -p1
bzcat patchfil.bz2 | patch -p1
xzcat patchfil.xz | patch -p1
Hvis patching går galt kan en i verste fall bli nødt til å slette hele kildekodemappa
og pakke ut kjernen på nytt. For den som er usikker anbefales å bruke parameteren
--dry-run. Da leser patch-programmet gjennom patchfilen og sjekke den, men oppdaterer ingen filer. Hvis du ikke får noen feilmeldinger kan du trygt kjøre kommandoen
om igjen uten --dry-run.
1.10.5 Konfigurere
Når kildekoden er klar, er tiden inne for å konfigurere. Det går ut på å velge slike
ting som hvilke drivere vi vil ha med og hva slags prosessor kjernen skal tilpasses for.
Konfigurasjonen lagres i en fil som heter .config.
Konfigurere når vi har en bra konfigurasjon fra før
Ofte har vi en bra konfigurasjon fra før. Det er f.eks. tilfelle hvis vi har kompilert
linuxkjernen før og bare skal oppdatere til en nyere versjon. Hvis du kompilerer for
første gang kan det også hende du har en brukbar eksisterende konfigurasjon, i form av
konfigurasjonsfilen (.config) fra distribusjonen du bruker. Hvis distribusjonen din har
2.6-kjerne, kan du sannsynligvis få tak i konfigurasjonen slik:
zcat /proc/config.gz > .config
For å konfigurere kjernen med en eksisterende konfigurasjon bruker du denne kommandoen:
side 34 av 38
make oldconfig
Da leses den gamle .config-filen, og du får bare spørsmål om eventuelle nye ting som
har kommet til i den nye kjernen du har lastet ned. For å se mer på konfigurasjonen og
kanskje gjøre noen tilpasninger kan du bruke denne kommandoen:
make menuconfig
Konfigurere fra bunnen av
Hvis du ikke har noen gammel konfigurasjon å bygge videre på, bruker du kommandoen
make menuconfig og velger rett prosessortype samt drivere for alt du har bruk for.
Dette kan ta litt tid, for det er mye å velge i. Det går an å simpelthen svare ja til (nesten)
alt, men da kan man ende opp med en veldig stor og plasskrevende kjerne som tar lang tid
å kompilere. Har man linux fra før kan kommandoen lspci gi litt informasjon om hva
slags utstyr som finnes i maskinen. Kommandoen lsmod forteller hvilke drivermoduler
som er i bruk. Jeg vil også anbefale hjelpesystemet i menuconfig, som har informasjon
om de fleste valgene.
1.10.6 Kompilere
Når kjernen er konfigurert, kompileres den med kommandoen make bzImage. Det
tar sin tid, regn med fra 2 minutter på en rask maskin, til timer på en gammel/svak en.
Bruk ventetiden til noe bedre enn å sitte og se på kompileringen! Hvis alt går greit får du
produsert en fil som heter arch/x86_64/boot/bzImage26 . Hvis du har konfigurert kjernen
din med moduler, trenger du også kommandoen make modules.
1.10.7 Installere kjernen
Noen distribusjoner har egne mekanismer for å installere kjerner, se i så fall distribusjonens dokumentasjon. Her beskriver jeg hvordan kjernen kan installeres manuelt, på en
maskin som bruker lilo til å laste den inn. De som bruker grub eller noe annet får se
på tilhørende dokumentasjon.
Siden kjernen er det første som trengs når linux booter, må den legges på et sted hvor
maskinen kan finne den når den booter. Kopier derfor arch/x86_64/boot/bzImage til en
passende mappe, f.eks. /boot. Det er en god idé å gi kjernefilen et mer beskrivende navn
også. Ta gjerne med versjonsnummeret i filnavnet, f.eks. linux4.1.
26 Forutsatt
at du har valgt en 64-bits prosessor, men det gjelder for alle vanlige PCer. En 32-bits kjerne for
eldre prosessorer havner på arch/x86/boot/bzImage i stedet. Arm-baserte kjerner (for mobiltlf, nettbrett
o.l.) havner på arc/arm/boot/bzImage
Kort om distribusjoner
side 35 av 38
Deretter må vi gi lilo beskjed om å laste inn den nye kjernen ved oppstart. Lilo har
konfigurasjonsfilen /etc/lilo.conf hvor vi legger inn følgende:
image=/boot/linux3.9
label=3.9
Hvis det er flere linjer med image, setter vi den nye kjernen først. Det er lurt å beholde
de som finnes fra før i fall det blir problemer med den nye kjernen. Når du har lagret
/etc/lilo.conf kjører du kommandoen lilo som oppdaterer bootsector på harddisken.
Hvis du bruker moduler, bruk kommandoen make modules_install i tillegg.
Til slutt bruker du kommandoen shutdown -r now så maskinen starter på nytt med
den nye kjernen. Når den er kommet i gang, kan du bruke uname -r for å sjekke at det
virkelig er den nye kjernen som er i drift. En vanlig nybegynnerfeil er å glemme å kjøre
lilo, eller å gjøre feil i /etc/lilo.conf. Da ender en fort opp med at det er den gamle
kjernen som starter i stedet.
Etter å ha fått opp rett kjerne er det lurt å kjøre dmesg27 for å sjekke oppstartmeldingene,
og gjerne sjekke at alle tjenester har kommet i gang som de skal. Hvis en har glemt en
driver e.l. i den nye kjernen, viser det seg som regel med uventede feilmeldinger under
oppstart, eller ved at tjenester som trenger den aktuelle driveren ikke kommer i gang.
Hvis den nye kjernen ikke starter i det hele tatt resetter du PC’en, og holder skift-tasten
nede mens den starter opp. Da vil LILO vise en oppstartsmeny med alle kjernene du har.
Da kan du velge den forrige kjernen i stedet for den som står først. Dermed kommer
maskinen i gang med gammel kjerne slik at du får mulighet til å rette feilen.
1.11 Kort om distribusjoner
1.11.1 Distribusjoner og dette faget
Selv bruker jeg stort sett testing-versjonen av debian. Faget kan gjennomføres med
enhver distribusjon, men hvis distribusjonen mangler noen av programmene som brukes
kan det bli mye kompilering og lignende ekstraarbeid.
Et år ble det f.eks. en del ekstraarbeid for studenter som brukte slackware-distribusjonen,
fordi denne i utgangspunktet ikke hadde støtte for PAM. Dermed måtte de kompilere nye
versjoner av programmer som login o.l. for å kunne gjøre LDAP-øvingene.
27 Det
er gjerne mange oppstartmeldinger, bruk dmesg|less for å se en skjermfull av gangen.
side 36 av 38
1.11.2 Installere og oppgradere debianpakker
Jeg forutsetter her at /etc/apt/sources.list er satt opp til å hente pakker fra nettet. Hvis
ikke, les man sources.list og sett opp dette først. Ta sikkerhetskopi av filen, med feil i
/etc/apt/sources.list kan man ikke installere noe som helst. Å kopiere konfigurasjonsfiler
før en endrer på dem er forresten alltid en god idé – da er det lett å gå tilbake.
For å oppdatere pakkedatabasen med siste nytt:
apt-get update
For å oppgradere hele distribusjonen med nye versjoner og evt. sikkerhetsoppdateringer:
apt-get dist-upgrade
For å installere pakkene ftp og ssh:
apt-get install ftp ssh
Med debian-pakker skal du normalt aldri få problemer med avhengigheter. Hvis en pakke
avhenger av andre pakker, vil apt-get laste ned og installere disse andre pakkene også.
Bli derfor ikke overrasket om apt-get legger inn to–tre eller ti–tjue pakker i tillegg til
de du ba om.
1.11.3 Installere rpm-pakker
De fleste distribusjoner utenom debian/ubuntu bruker rpm-pakker. De brukes slik:
1. Hvis du har pakken på din installasjonsCD, fortsett fra punkt 2. Hvis ikke: Last ned
rpm-pakken. Pass på at det er rett versjon for din distribusjon. (Noen ganger bruker
f.eks. mandrake og redhat ulike versjoner. Ulike versjoner av distribusjonene kan
også ha ulike rpm-pakker for noen programmer.)
2. Installer pakken med følgende kommando:
rpm -i pakkefilnavn.rpm
Enkelte grafiske filhåndteringsprogrammer kan installere rpm-filer når du klikker
på dem. Det kan være et greit alternativ til denne kommandoen, men pass på at du
får med deg eventuelle feilmeldinger.
3. Hvis du får beskjed om at det mangler andre filer eller pakker, skaff og installer
disse først og prøv punkt 2 igjen.
1.11.4 Andre distribusjoner
Distribusjoner som gentoo og slackware gjør ting anderledes. Har du en av disse regner
jeg med at du vet nok om hvordan programmer installeres. Gentoo bruker f.eks. «emerge
pakkenavn» i stedet for «apt-get install pakkenavn»
Kort om distribusjoner
side 37 av 38
1.11.5 Installere .tar.gz-filer
Hvis et program ikke er pakket for distribusjonen din, eller hvis pakken er for gammel,
kan det bli nødvendig å installere fra kildekode i stedet. Det gjøres slik:
1. Last ned kildekode, vanligvis i form av en .tar.gz-fil fra programmets hjemmeside.
2. Pakk ut filen med følgende kommando:
tar xvzf filnavn.tar.gz
Hvis du har fått en .tar.bz228 -fil i stedet, blir kommandoen
tar xvjf filnavn.tar.bz2
3. Gå inn i mappa som ble pakket ut, les eventuelle filer kalt README og eller
INSTALL. Her finnes tips og instruksjoner for konfigurering, kompilering og
installasjon. Her står det gjerne hva du trenger av programvare ellers også. Store programpakker har gjerne en undermappe kalt doc e.l. hvor du finner mer
informasjon.
4. Konfigurer programmet, om nødvendig. Det gjøres vanligvis slik:
./configure
5. Kompiler programmet, vanligvis med følgende kommando:
make
6. Installer programmet, vanligvis slik:
make install
7. Tilpass eventuelle konfigurasjonsfiler, om nødvendig. Hvis det bare er én fil, heter
den som regel /etc/programnavn.conf. Hvis det er flere, ligger de vanligvis i mappa
/etc/programnavn.
8. Start opp programmet. Informasjon om bruken av det finnes på ett eller flere av
følgende steder:
a) Ved hjelp av kommandoen man programnavn.
b) I dokumentasjonsmappa sammen med kildekoden.
c) På programmets hjemmesider.
28 .bz2
er noe bedre komprimert enn .gz
side 38 av 38
1.12 Oppsummering
Vi har sett på valg vi gjør før vi installerer linux. For maskinvare gjelder det å velge
passende prosessor, minne og harddisk(er) for det tjenermaskinen vår skal brukes til.
Harddisker organiseres i RAID og deles inn i partisjoner. På hver partisjon brukes et
passende filsystem.
Vi har også sett litt på hvordan vi kompilerer en linuxkjerne, fått en oversikt over
distribusjoner, og repetert en del informasjon om debian linux.

Innhold - Institutt for informatikk og e-læring

Transcription

Similar documents

Intro. Struktur og trusselbilde - Avdeling for informatikk og e

01-linux - Høgskolen i Molde

Sikker internett-tilgang og brannmurer

CV for Tore Gryting Andersen

Strengbehandling og enkle beregninger

Plastisitet- Hvordan hjernen endrer seg over tid

Elotec CX datablad

Kvartalsrapport fra NILU IT

Håndtering av filer og kataloger

Lage ASP.NET sider - Institutt for informatikk og e