Hovedprosjekt: 2003

ForfatterE: vIDAR gRØNLAND

rAGNAR hAUGLAND

tARJEI WESTRUM

sVEN ARE FINNEVOLDEN

Dato: 19.05.2003

Sammendrag av hovedprosjekt

Tittel:	Skolelinux – Overvåkningssystem			Nr. :
	Skolelinux – Monitoring system			Dato :	19/5-03
Deltakere:	Vidar A. Grønland
	Tarjei Westrum
	Sven Are Finnevolden
	Ragnar Haugland
Veiledere:	Intern veileder ved HiG: Erik Hjelmås
	Ekstern veileder (Skolelinux): Frode Jemtland
Oppdragsgiver:	Skolelinux
Kontaktperson:	Frode Jemtland
Stikkord	Overvåkning, Perl, Nagios, Skolelinux
(4 stk)
Antall sider: 198		Antall bilag: 124	Tilgjengelighet: Åpen
Kort beskrivelse av hovedprosjektet: Prosjektgruppa har utarbeidet en overvåkningsmodul, implementert og skreddersydd den for det landsomfattende og dugnadsbaserte Skolelinux prosjektet.

Forord

Ingeniørstudiet ved Høgskolen i Gjøvik er et 3-årig studie som i siste vårsemester ender opp i en større praktisk prosjektoppgave. Der studentene skal demonstrerer at de kan bruke sine kunnskaper til å lage gode løsninger på en praktisk måte. Prosjektet gjennomføres normalt i samarbeid med en bedrift eller en annen ekstern institusjon.

Første del er å finne et prosjekt å jobbe med, en oppgave som skal være unnagjort før siste semester, for å få mest mulig tid til selve prosjektet.

Deretter leveres et dokument som inneholder gruppesammensetning, navn på veileder og en kort prosjektbeskrivelse for godkjenning senest den 6.1.2003. Når dette er godkjent og prosjektet er i gang, skal det foreligge en detaljert forprosjektrapport og kontrakt med oppdragsgiver innen 24.1.2003 samtidig som prosjektets web-side skal være operative.

Selve prosjektarbeidet pågår da frem til innleveringsfristen for prosjektrapporten den 19.5.2003. Og til slutt må det forberedes til presentasjonen som finner sted ved Høgskolen i Gjøvik (HiG) 26-28.05.2003.

Prosjektet er også beskrevet på internett: http://developer.skolelinux.no/info/studentgrupper/2003-HIG-overvaakning

___________________________ ______________________________

Tarjei Westrum Sven Are Finnevolden

___________________________ ______________________________

Ragnar Haugland Vidar Grønland

Om Skolelinux

Skolelinux prosjektet er et norsk dugnadsprosjekt som ble startet 16. juli 2001 og styres av prosjektleder Knut Yrvin.

Prosjektet kom i gang etter økende misnøye rundt dagens IT-satsing i norske skoler. Da spesielt på bakgrunn av kostnaden den propriære programvare fører med seg av lisenser inn til skolene.

Prosjektet går ut på lage et fritt tilgjengelig Linuxbasert alternativ for norske skoler. Grunnprinsippene i prosjektet er at enhver skal kunne kopiere, bruke og forbedre programvaren som brukes, uten å tenke på lisensadministrasjon og -utgifter. Operativsystemet Linux, som er hjørnesteinen i prosjektet, har blitt utviklet på samme måte siden 1992, og resultatet av prosessen har vært en formidabel suksess.

Takk til:

Vår oppdragsgiver Skolelinux og kontaktperson Frode Jemtland, for en utfordrende og meget lærerike oppgaven. Samt alle som har bidratt på mailing lista [10] med synspunkter og svar på ting vi har lurt på.

Skolelinux har også vært flinke med å få oss til å føle oss ”hjemme” noe vi har satt stor pris på. Vi har også fått delta på tre utviklingsseminarer (Oslo og Stavanger/Bryne(Appendiks A5)), hvor vi kom i kontakt med mange av de involverte i prosjektet. En av dem vi har fått mest hjelp av er Tor Erik Neuberg som til daglig jobber som drifter i EDB Teamco på Skøyen (Appendiks A1). Neuberg har gitt oss gode tips om hva som bør vektlegges i systemet vi har utarbeidet.

Til slutt vil vi takke Erik Hjelmås, som vår veileder på HiG. Han har stått til disposisjon og hjulpet oss når vi har trengt det som mest, samt Tom Audun Seljeflot for god hjelp.

Innholdsfortegnelse

Kapittel 1 - Innledning. 6

1.1 Definisjoner 6

1.2 Praktiske opplysninger 9

1.3 Rapportorganisering. 10

1.4 Oppgavedefinisjon. 11

1.5 Målgrupper 11

1.6 Bakgrunn for valg av oppgave. 12

1.7 Egen bakgrunn og forutsetninger 13

1.8 Arbeidsformer 14

Kapittel 2 - Kravspesifikasjon. 16

2.1 Introduksjon. 16

2.2 Bruker beskrivelse. 17

2.3 Detaljert kravspesifikasjon. 24

2.4 Data spesifikasjon og dataordliste. 25

2.5 Operasjon i feilsituasjoner 26

2.6 Begrensninger 27

2.7 Hardware design begrensninger 28

2.8 Aspekter omkring livssyklus. 28

2.9 Aspekter omkring installasjon. 29

2.10 Prosjektstyring, inkludert kvalitetssikring. 29

2.11 Metode bruk og fremgang i utarbeidelse av. 30

kravspesifikasjonen. 30

Kapittel 3 - Analyse og design. 31

3.1 Tidligere system.. 31

3.2 Nytt system.. 33

3.3 Metoder 33

3.4 Design. 34

Kapittel 4 - Installasjon. 52

Kapittel 5 - Implementering. 54

5.1 Verktøyvalg. 54

5.2 Organisering av kode og prinsipper 54

5.2.1 Organisering av kode. 55

5.3 Administrasjon. 55

5.4 Hvordan bruke Nagios. 55

5.5 Beskrivelse av konfigurasjonsfilene. 56

Kapittel 6 - Testing. 57

6.1 Testing. 57

6.2 Testing av åpen kildekode. 57

6.3 Testing av Skolelinux. 58

6.4 Testene vi har gjort 58

Kapittel 7 - Konklusjon. 64

7.1 Prosessen. 64

7.2 Hva har vi oppnådd. 64

7.3 Hva har vi lært?. 65

7.4 Videre arbeid. 65

7.5 Evaluering. 66

7.5.5 Timelister 69

7.5.6 Logg bok. 69

7.5.7 Oppsummering. 73

Kapittel 8 Referanser 74

8.1 Litteraturliste. 74

Bøker: 74

Artikler og kompendier 74

Internettsider: 74

Kapittel 9 - Appendiks. 76

Kapittel 1 - Innledning

1.1 Definisjoner

Det blir flere steder gjennom hele rapporten referert til tekniske og forkortede ord. I alfabetisk ordnet liste under, er det laget en oversikt over de mest brukte ordene med forklaringer.

B:

Brannmur: Se Firewall

C:

CGI: Common Gateway Interface. En standardisert måte for å utveksle informasjon mellom en WWW-tjener og en WWW-klient.

CVS: Concurrent Versions System. Et system som skal gjøre det enklere å holde orden på revisjoner av programpakker og gjør det lettere så flere utviklere kan jobbe på samme program samtidig. Fordelen med dette er at man kan gå tilbake til tidligere versjoner dersom man oppdager at endringer som er gjort, har ført til nye bugs. Appendiks A2

D:

Debian: Debian er et fritt tilgjengelig operativsystem for datamaskiner. Debian bruker Linux- kjerne, men mesteparten av det grunnleggende operativsystemet stammer fra GNU-prosjektet, derfor navnet GNU/Linux. Debian tilbyr mer enn et rent OS, distribusjonen kommer med mer enn 8710 pakker, ferdigbygd programvare satt sammen i et velegnet format for en enkel installasjon på maskinen din.

DHCP: DHCP står for "Dynamic Host Configuration Protocol", og med DHCP kan en server gi deg den rette informasjonen for at din datamaskin kan komme seg ut på nettverket/internett uten at du trenger å sette opp dette manuelt.

F:

Firewall: En firewall er en atskillelse mellom et LAN og et WAN - i vårt tilfelle Internet. En firewall "filtrerer" all trafikk mellom de to nettverkene, og bestemmer hvor forskjellige typer trafikk kan gå, og hvilken trafikk som ikke må komme igjennom til det interne nettverket.

Fri programvare: Dreier seg om frihet, ikke pris, dvs. fri programvare refererer til brukernes rett til å bruke, distribuere, studere, endre og forbedre programvare. Med andre ord så er fri programvare og åpen kildekode en og samme ting. Se: Open source.

G:

GPL: General Public Licens. Hovedgrunnen til GPL-lisensen er å sørge for at all programkode skrevet under GPL for alltid vil være like tilgjengelig for alle. Appendiks A3

GUI: Graphical User Interface. Grafisk brukergrensesnitt.

H:

HiG: Høgskolen i Gjøvik

Hub: En "HUB" er omtrent det samme som en "switch", men ikke like intelligent med fordelingen av data til rette mottakere. Se Switch.

I:

Inkrementell utviklingsmodell: En modell som beskriver gangen i et software prosjekt. Se Appendiks A4

Internett: Et verdensomspennende datanettverk.

L:

Linux: Et operativsystem som kan drive en PC, på samme måte som Windows gjør på de fleste datamaskiner i dag. Se Os.

LTSP: ”Linux Terminal Server Project” er programvare som tillater å bruke eldre datamaskiner som har skjerm og tastatur (tynne klienter uten harddisk), og som kjører sine programmer på en kraftigere datamaskin. Ved å gjenbruke gammelt datautstyr, så kan slike terminalløsninger føre til at en sparer penger på vedlikehold og oppgraderinger av gammel maskinpark og programvare. For mer info, se: [7].

M:

MAC-adresse: En unik adresse for hvert nettverkskort (eks.: 00:60:94:e5:78:1e).

N:

Nagios: Omfattende overvåkningsprogram for datanettverk.

O:

Open Source: Går ut på i sin helhet at kildekoden til programmer er tilgjengelige for alle og enhver. I utgangspunktet gir dette brukerne full mulighet til å studere og endre programmene, men de fleste programmene som distribueres fritt med kildekode har en eller annen form for lisens som setter visse betingelser og krav til bruk eller ved videre distribusjon. Se Fri programvare.

OS: Et operativsystem er samlingen av grunnleggende programmer og verktøyer som får maskinen din til å virke, og er et brukegrensesnitt mellom hardware og software. Se Linux og Debian.

P:

Perl: Practical Extraction Report Language. Dette er et programmeringsspråk som kombinerer syntaks fra flere UNIX verktøy og språk. Perl er designet for å ta seg av system adminstrator funksjoner og gir mulighet til avansert strengbehandling.

Pxe: Kjøre opp (boot) en arbeidsstasjon (tynnklient), via nettverk. Den er integrert på nettverkskortet.

R:

Root: Bruker på et UNIX system som har alle rettigheter på systemet.

Router: Enhet som sender og mottar datapakker i et datanett. En ruter leser adresseinformasjon som finnes i pakkene, og vil deretter sende dem videre i riktig retning slik at de kommer frem til riktig maskin.

S:

SSH: Secure shell er et program for å kunne logge seg på maskiner man ikke fysisk sitter ved. Det er ment som en erstatter for de usikre remote login programmene rlogin og rsh. Programmet krypterer informasjonen som blir sendt mellom to hoster over ett usikkert nett.

Switch: En "switch" er et samlingspunkt i et nettverk hvor maskiner kobles opp imot med bruk av TP-kabler, hvor "switchen" igjen deler pakkene til de rette mottakere, slik at datamaskinene kan kommunisere med hverandre.

T:

Tynnklienter: Datamaskiner uten harddisk, som starter opp med booting fra en diskett eller pxe, med nettverkskortinformasjon. Se pxe.

Tynnklienttjener: En maskin som innholder den informasjonen som tynnklienter trenger for å boote sitt OS

TP: Twisted pair. Kabel for tilkobling mellom to maskiner.

U:

UNIX: Et flerbruker operativsystem.

X:

X: X Windows System. Det er et vindusbasert grensesnitt som benyttes under UNIX. Det kan også brukes på de fleste nye operativsystemer.

1.2 Praktiske opplysninger

Vi bruker skrifttypen ”Palatino Linotype” og skriftstørrelse 12 på vanlig tekst i rapporten. Hovedoverskrifter er markert med skriftstørrelse 16 og halvfet. Overskrifter på hovedkapitler har skriftstørrelse 14 og halvfet, mens underkapitler har skriftstørrelse 12 og halvfet.

Kode i rapporten er skrevet med Courier New med skriftstørrelse 10/8.

Figurer som befinner seg i rapporten er merket med kapittelnummeret de tilhører, i tillegg til et eget nummer (for eksempel figur 1.1).

1.3 Rapportorganisering

Rapporten er skrevet etter malen som er utgitt av Høgskolen i Gjøvik, og består av en innledning, hoveddel, avslutning og en konklusjon i tillegg til vedleggene.

Du vil også se at deler av rapporten er skrevet på engelsk, dvs. en del av vedleggene. Dette ble gjort fordi Skolelinux ønsket den tekniske informasjonen rundt koding og konfigurering på engelsk, for lettere å kunne utveksle informasjon utover landegrensene.

Kapittel 1: Innledning

Kapittel 2: Kravspesifikasjon

Kapittel 3: Analyse

Kapittel 4: Installasjon

Kapittel 5: Implementering

Kapittel 6: Testing

Kapittel 7: Konklusjon

Kapittel 8: Litteraturliste og referanser

Kapittel 9: Appendiks/Vedlegg

Vedleggene er merket med hver sin bokstav, fra A-G der A tilhører kapittel 1, B tilhører kapittel 2 osv. Vedleggene er merket med Appendiks X øverst i høyre hjørne.

Innledningen beskriver kort innholdet i rapporten. Det vil bli en kort forklaring på hva hovedprosjektet har gått ut på, hvem som har vært oppdragsgiver og en forklaring på ord og uttrykk.

Kravspesifikasjonen setter selve grunnlaget for rapporten og oppgaven. Beskrivelsen av systemet som skal være et ferdig produkt beskrives her. Dette er en mal for sluttresultatet av hovedprosjektet.

Analysekapittelet inneholder en analyse av eksisterende programvare, en forklaring av disse med fordeler og ulemper i tillegg til hvilket system vi har valgt å bruke.

Installasjon, implementering og testing, går mer spesifikt inn på selve oppgaven.

Konklusjonen oppsummerer oppgaven og drøfter resultatet som vi har kommet frem til.

1.4 Oppgavedefinisjon

1.4.1 Problemområde

Faget ”Hovedprosjekt” har noen retningslinjer som må følges for å få det godkjent. Dette går på tidsfrister, arbeidsmengde, organisering, presentasjon, krav til prosjektets hjemmeside og kontrakt med høgskolen og oppdragsgiver. For mer info, se: [9].

Hovedprosjektet går ut på å lage et overvåkningssystem for Skolelinux. Et system som i korte trekk skal varsle IT-ansvarlige ved skolene når en feil har oppstått på datamaskiner, eller når tjenester som web, e-post, etc. ikke fungerer som det skal.

Systemet blir en del av Skolelinux distribusjonen, som blir installert på skoler som ønsker å ta i bruk Linux som operativsystem. Oppdragsgiver har store forventninger til det ferdige produktet. Navigeringen rundt i programmet er enkel, grunnen til dette er at overvåkningssystemet skal i hovedsak bestå av et web grensesnitt med linker til forskjellige statusvinduer og rapporter.

1.4.2 Avgrensninger

Når prosjektet er ferdig leveres et produkt som er klar til å tas i bruk. Det skal da være en del av installasjonen til Skolelinux. Det må kun kjøres enkle kommandoer for skript etter installasjonen for å få riktig oppsett i systemet.

Det vil bli utarbeidet en brukermanual for installeringen, og en manual for navigeringen i programmets web grensesnitt.

1.5 Målgrupper

1.5.1 Rapport

Det er to målgrupper for rapporten. Den ene er HiG og den andre er Skolelinux. Sluttrapporten vil også bli rettet mot sensor. Det vil være en fordel å ha en viss teknisk innsikt i dataverdenen for å få et fullt utbytte av rapporten. Rapporten skal gi god dokumentasjon av hva som er gjort i prosjektet, og hvilke problemer som har oppstått under prosjektperioden.

En annen målgruppe for rapporten er sensor, veileder og andre interesserte som vil lese rapporten.

Alle prosjekter ved HiG blir publisert via web, noe som kan være til nytte for studenter som skal gjennomføre lignende prosjekter senere. Dette for å se hva et prosjekt innebærer.

1.5.2 Oppgaven

Oppgaven er selve produktet av hovedprosjektet. De som skal benytte seg av selve produktet som er utarbeidet gjennom hovedprosjektet, er Skolelinux og systemadministratorene på skolene. Systemadministratorene av er IT-ansvarlige ved skolene. Ansatte med mer eller mindre erfaring med datasystemer, noe som må tas høyde for i en brukermanual.

Med å gjennomføre et slikt prosjekt får man testet ut sine kunnskaper som har vært del av opplæringen i løpet av en treårig ingeniørutdanning. Et hovedprosjekt er det nærmeste vi kommer arbeidslivet før vi skal begynne med det virkelige liv. Derfor er også gruppen en målgruppe her.

1.6 Bakgrunn for valg av oppgave

Vi hadde to muligheter for valg av hovedprosjekter, enten ta del i prosjekter HiG hadde fått i gang eller finne et prosjekt på egenhånd. Ettersom prosjektene fra Høgskolen ikke var av særlig interesse for vår del, valgte vi mulighet nummer to, nemlig å finne et prosjekt på egen hånd.

Det hele startet opp i november 2003 med at klassestyrer Erik Hjelmås kom i kontakt med Skolelinux, der interessen for hovedprosjektgrupper var veldig høy. De hadde også flere driftsrettede oppgaver vi kunne velge mellom, deriblant overvåkning av nettverk.

Det endte derfor opp med at vi startet med et prosjekt som omhandler overvåkning av Skolelinux-nettverkene.. Dette ble fastsatt etter et møte med sjefen for Skolelinux Knut Yrvin 13. januar 2003, på Holumskogen barneskole i Nittedal. Da overvåkning var en oppgave gruppa fattet interesse for og alle på gruppa hadde stor tro på. Oppgaven var også veldig relevant for vår studieretning, da alle på gruppa går studieretning for drift.

Alle medlemmene av prosjektgruppen har en felles interesse for drift av flerbrukersystemer, og da spesielt innen Linux-distribusjonen debian. Vi så derfor for oss en mulighet til å lære mer om Linux og generell drift av datasystemer ved å gå inn på oppgaven. Tema overvåkning er også et spennende tema vi helt klart ser fordelene av å ha kjennskap til med tanke på senere jobbutsikter.

Vi så det også som en utfordring å utvikle og implementere et eksisterende produkt, da dette var en helt annen måte å sette seg inn i oppgaven på enn om vi skulle produsert noe fra bunnen av. Hvis vi skulle ha utviklet et helt nytt system fra bunnen av, hadde prosjektet vært alt for tidskrevende innenfor den tidsrammen som er fastsatt fra skolen sin side. Med tanke på analyse, og det å sette seg inn i et eksisterende produkt for å oppnå full forståelse av hva som er gjort og ikke gjort, måtte vi allikevel følge en nokså krevende tidsramme.

Gruppen valgte å jobbe med Skolelinux prosjektet, fordi vi alle ser nytten av deres formål om å gjøre IKT mer tilgjengelig i barnas skolehverdag til en billigere penge enn i dag. Og vi ønsket å bidra så godt vi kan til at dette blir en realitet i den nærmeste framtid.

1.7 Egen bakgrunn og forutsetninger

Gruppen består av 4 individer med ulike erfaringer. Alle på gruppen går studieretningen drift, der vi har lært litt om ulike driftsverktøy og operativsystemer. For det meste har det dreid seg om drifting av systemer på Linux plattformen.

Generelt under studier ved HiG har vi tilegnet oss erfaringer og bakgrunnskunnskap innen følgende fag som er relevante mht. vårt prosjekt:

· Økonomi og prosjektstyring

· Investering og Finansiering

· C++

· SQL

· Unix

· Perl

· Java

· C

· Bash

· Html

· Java script

og følgende kurs med eksamen i mai/juni 2003:

· Ledelse

· XML.

Gruppen har generelt liten arbeidserfaring med unntak av en som har jobbet som elektriker noen år. Ragnar Haugland kommer fra allmennfaglig studieretning, mens Sven Are Finnevolden og Vidar Grønland har fagbrev som Serviceelektroniker innen data og kontor i tillegg til forkurs for ingeniørhøgskole. Tarjei Westrum har arbeidet som elektriker i noen år, i tillegg har han også forkurs for ingeniørhøgskole. Alle er vi i vårt siste semester av en treårig ingeniørutdannelse innen drift av datasystemer.

Hvilke kunnskaper må vi tilegne oss:

Lære perl og systemdrifting på et høyere nivå enn vi har på dagens tidspunkt.

Bruk av CVS for oppdateringer opp mot Skolelinux sin tjener.

Klient server programmering og fysisk kobling av nettverk.

1.8 Arbeidsformer

Vi har naturligvis benyttet oss mye av internett, for å få tilgang til den aller nyeste informasjonen. Skolelinux har også en maillingliste hvor man kan stille spørsmål og den som vil kan svare.

Dette har vært en viktig ressurs for oss, da kompetansenivået på listen er svært høyt. Vi fikk beskjed av oppdragsgiver at vi skulle basere oss på eksisterende programvare og ikke ”finne opp kruttet på nytt”, noe som medførte mye søking på internett samt analyser og testing av programmer vi tok med til vurdering. Vi har også benyttet oss av tidsskrifter (spesielt [13]), som har hatt tester og ekspert uttalelser om ulike temaer rundt overvåkningsprogrammer. Vi har også hatt kontakt med driftspersonell i forskjellige firmaer (Opera, EDB Teamco, Forsvarets datasentral), som har gitt oss nyttig informasjon underveis.

Det meste av arbeidet har foregått på A113, hvor vi har satt opp et Skolelinux testnettverk. Vi har stort sett jobbet to og to, for å kunne lære av hverandre på en best mulig måte og samtidig kunne kjøre ting parallelt. Vi valgte en gruppeleder i starten av prosjektet, men har ikke hatt noe stort behov for en ”sjef” da vi stort sett har vært enige i beslutningene vi har tatt.

Under prosjektet har vi ført loggbok individuelt om hva vi har gjort de dagene vi har jobbet med prosjektet og hvor lenge vi har jobbet.

Vi har benyttet oss av inkrementell utviklingsmodell i prosjektet. Dette fordi det har blitt utarbeidet forskjellige inkrementer i utviklingen av prosjektet. (Se Appendiks A4)

Kapittel 2 - Kravspesifikasjon

2.1 Introduksjon

2.1.1 Kort om krav til systemet

Vår systemmodul skal brukes som et hjelpemiddel for overvåkning av (LAN og WAN) nettverk som innehar Skolelinux konfigurasjonen.

Systemet vil i første omgang bestå av en stor modul som skal implementeres i Debian distribusjonen Skolelinux.

Innholdet til hovedmodulen vil bestå av mange små og mellomstore moduler, avhengig av hva et Skolelinux nettverk trenger av overvåkning og hva vår behovsanalyse vil gi svar på.

Kostnadene for prosjektet anses å være minimale da vi hele veien vil benytte oss av åpen kildekode (GPL), som er en av hovedreglene til Skolelinux.

Da det gjelder tidsplan, henvises det til fremdriftsplan (Appendiks B1)

2.1.2 Kort om systemets omgivelser

· Konfigurere et overvåkningssystem som er stabilt og egnet for bruk av pakkene i Skolelinux.

· Kompetanseoppbyggende.

· Kursing av andre.

Overvåkningssystemet skal brukes på Linux plattform, og kjøres på en filtjener. Fra vår side skal den omfatte overvåkning av et homogent Linux miljø. Men det skal på sikt være mulig å ha tilkoblet andre arbeidsstasjoner som Microsoft Windows, som systemet også skal ha oversikt over.

2.1.3 Kravspesifikasjonens struktur

Del 1: Inneholder en generell innledning til Skolelinux prosjektet, og i grove trekk hva vår oppgave går ut på.

Del 2: Hva skal systemet gi systemadministratoren?

Del 3: Mer teknisk beskrivelse av hva programmet skal gjøre og ikke gjøre.

2.1.4 Referanser

Vi har benyttet oss av internett og personer med driftserfaring under oppbygningen av spesifikasjonen. Noen av disse er: Tor Erik Neuberg (EDB Teamco), Johnny Birkelund (IT-sjef i Opera), Sverre Stoltenberg (Driftsansvarlig i Opera) og Jon Magnus Dullerud (Forsvaret Kolsås).

Verktøy vi har benyttet oss av:

Perl, Nagios, Skolelinux, Open office, mail, Gaim (Linux basert chat).

2.2 Bruker beskrivelse

2.2.1 Omgivelser

Det vil være en forutsetning at vårt overvåkningssystem kjøres på et Skolelinux nett dvs. (Debian), da vi har brukt dets oppsett i konfigurasjonen. Systemet vil bestå av en overvåkningsmodul som automatisk installeres på filtjeneren, som er ”mora” til alle andre maskiner på nettet.

Serveren er tilkoblet alle maskiner i nettverket gjennom maskiner eller svitsjer.

Kommunikasjonsstandarder er: TCP/IP, SMTP, SNMP, UDP

2.2.2 Systemets brukere

Systemets brukere er lærere og IT-ansatte i grunnskolen. Mest basert på 1-7 klasse, men også til bruk på ungdoms- og videregående skoler. Selv om Skolelinux er tenkt brukt i skolesammenheng, er det også mulighet for vanlige privatpersoner å bruke Skolelinux.

Systemet vil kreve en viss datakunnskap, for å kunne tolke det output programmet gir.

2.2.3 Operasjon

Systemet skal overvåke datamaskiner på et lokal nett (LAN). Det skal detektere feil på nettverket og på maskinene. Feilmeldingene skal si hvor feilen er, og hva slags kategorifeil det dreier seg om. Dette systemet må være oppe å gå hele tiden, oppetid bør helst være 100 %, men pga vedlikehold og lignende, vil oppetiden automatisk bli noe redusert.

Enkelte av feilene er ment som 1. linjes feil og skal kunne utføres av IT-ansvarlig (situasjon for Skolelinux: Bibliotekaren, vaktmesteren etc.) på hver enkelt skole. Ellers er det IT-ansvarlig i hver enkelt kommune som har det overordnede ansvaret (2.linjes feil).

Sikkerheten i systemet må til en hver tid være høy, og dette opprettholdes ved at nye oppdateringer av eks. software jevnlig utbedres. Systemet skal gi en feilmelding vha. røde, gule eller grønne lamper, hvor det også skal komme opp hva som er feil, eventuelt hva som kan komme til å bli feil.

2.2.4 Aspekter omkring livssyklus

Hele prosjektet baserer seg på open source programvare og er lisensiert under GPL. Dvs. At dersom systemet viser seg å fungere som det skal er det åpent for alle å videreutvikle og videreføre programmet. Testing vil skje av de som tar i bruk Skolelinux og eventuelt andre som ser på Skolelinux som interessant.

· Vedlikehold/videreutvikling er åpent for hvem som helst som vil forbedre systemet

· Muligheter til å lage nye moduler og utvide systemet

· Systemet skal være tilpasset Skolelinux

· Sluttrapporten vår vil inneholde dokumentasjon som omhandler systemet

· Alt vi gjør, blir lagt inn på Skolelinux sin CVS server

2.2.5 Ytelse

For å kjøre Nagios er kravet at en har en datamaskin med Linux eller en UNIX variant og en C kompilator. Nettverket må være basert på TCP/IP fordi de fleste sjekkene er basert på dette.

For å få vist alt grafisk (GUI), må vi også ha:

· En web-server (for eksempel Apache)

· Thomas Boutell’s gd library versjon 1.6.3 eller nyere

Det forutsetter også internett tilgang fordi oppgraderinger og installasjoner på systemet skjer ved hjelp av kommandoen apt-get.

Tjenerne (filtjener og tynnklienttjener) i systemet bør være ganske kraftige, siden dette er maskinene som utveksler informasjonen i nettverket. En filtjener/tynnklienttjener bør være minst 300MHz med 256MB RAM, men det anbefales servere opp til dagens nivå på maskiner for å utnytte kapasiteten fullt ut.

2.2.6 Begrensninger

Brannmur:

Vi er kun interessert i å sjekke om den er oppe og går. Det vil si at vi pinger den med jevne mellomrom. Vi vil ikke ta sikte på å sjekke innkommende og utkommende pakker på brannmuren, det vil si at vi ikke skal kontrollere hva slags trafikk som kommer inn og ut gjennom brannmuren. Dette må bli tatt hensyn til i senere utvikling/prosjekter av overvåkningssystemet. Vi tar kun for oss det som er innenfor hver enkelt skole/LAN. Brannmuren skal filtrere pakker og stenge for uønsket trafikk.

Filtjener:

Filtjeneren skal også fungere som en webtjener og en mailtjener. Dette gjør at filtjeneren kan bli ustabil. Tross dette velger vi å stole på at hardware i tjeneren klarer å takle overvåkningssystemet uten å gå ned. Alternativet er å sette opp en egen maskin som kun kjører overvåkningssystemet. Dette blir en større kostnad, fordi det må kjøpes inn en ekstra server for dette formålet. Slik Skolelinux nettverket er satt opp i dag er det ikke tatt forbehold for en slik ekstra kostnad. Dette gjør at vi bruker filtjeneren som overvåkningsmodul, og lar denne overvåke tjenere, tynnklienter, og arbeidsstasjoner. Vi har tenkt oss en tidsavgrensning, som styrer perioden overvåkningssystemet skal sjekke tynnklientene. Oppetiden av tynnklientene vil bli overvåket døgnkontinuerlig. Overvåkningssystemet skal ha oversikt over hvor mye diskplass som er igjen og hvor stor belastning det er på tjenerne. Modulen skal gi et signal når disken(e) begynner å bli fulle, oransje lampe ved 90 % av brukt diskplass.

Arbeidsstasjoner:

Disse maskinene kan kjøres på forskjellige operativsystemer/plattformer. Dette gjør det vanskelig/tidskrevende og tid har vi ikke all verden av. Å integrere overvåkningsmodulen med alle typer av plattformer vil spenne over et større spekter enn de tidsrammene som er satt. Dette gjør at vi ikke tar sikte på å sjekke oppetid på andre operativsystemer enn Skolelinux. Det vil si at alle andre maskiner som det er installert andre typer operativsystemer på, kun vil bli pinget for å se om maskinen er operativ.

Tynnklienttjener:

Dette er den mest “kritiske” delen av systemet når det gjelder lagring og oppetid. Dette er knutepunktet mellom tynnklientene og omverdenen. Hvis denne feiler så er også alle tynnklientene ute av drift. Våre avgrensninger på tynnklienttjeneren vil bli å sjekke ledig diskkapasitet, maskinens belastning og om nettverket fungerer mellom maskinene. Overvåkningsmodulen skal overvåke diskplass på tynnklienttjeneren, og gi et varsel da det begynner å bli fullt. Vi har tenkt oss et varsel (oransje lampe) da disken(e) er 90 % fulle. Den sjekker også hvor mye det er igjen av swap partisjonen og SMTP.

Tynnklienter:

Dette er diskløse arbeidsstasjoner, som bootes fra diskett eller pxe via nettverkskortet. Vi ønsker derfor at overvåkningssystemet kun skal kunne pinge tynnklientene for å sjekke om de er operative til enhver tid. På grunn av at tynnklientene er diskløse er det begrensninger på hva overvåkningsmodulen har muligheten for å sjekke, siden vi ikke i utgangspunktet har muligheten til å ha en ”daemon” gående på tynnklientene.

Vi har kommet frem til at vi vil lage et script som henter ut antall tynnklienter på 192.168.0.10-99 nettet, og gir Nagios de rette parametere for å kunne overvåke gjeldende maskiner.

Forutsetningen vil da være at man ved oppsett av nye tynnklienter er fast på at disse legges inn med MAC adresse i Webmin. Dette er nødvendig fordi de ellers vil få adressestart på 192.168.0.200-254.

Grunnen til at vi gjør dette, er for å få det til å gå automatisk rett ut av boksen. Alle hostene må også være oppe da opptellingen skjer vha. scriptet.

For å få et innblikk i hvor de respektive hoster er plassert, anbefales den som legger inn klientene i Webmin, å lage et ip-kart, slik at det blir lettere å finne rett maskin når noe feiler (pga. dhcp problematikken).

Hovedtrekk:

Brannmur: Blir kun pinget for å sjekke om den er operativ

Filtjener: Plasseringen av overvåkningsmodulen, sjekke diskplass, gi signal når harddisken begynner å bli full og maskinens belastning.

Arbeidsstasjoner: Arbeidsstasjoner som ikke bruker Skolelinux vil kun bli pinget for å sjekke om de er operative. De som bruker Skolelinux, vil vi kunne pinges og sjekke diskplass.

Tynnklienttjener: Sjekke diskplass, oppetid og belastning på nettet.

Tynnklienter: Disse skal kun bli pinget av overvåkningsmodulen for å sjekke om de er operative.

2.2.7 Hardware krav

Når det gjelder maskinvare til vår testinstallasjon, vil vi nevne noe om minimumsspesifikasjoner til de forskjellige maskinene og utstyr med tanke på maskinvare. Totalt sett er det mer lønnsomt å benytte bedre utstyr enn det som er beskrevet som minimumskrav til testinstallasjon.

Alle maskinene bør inneholde:

· Skjermkort av type pci/agp

· Nettverkskort av type pci

· Diskettstasjon, skjerm, tastatur og mus.

· I tillegg så må tjenermaskinen for tynnklienter ha to nettverkskort,

· helst to forskjellige

Minimumskrav for Filtjener

· Prosessor: 200MHz

· Minne (RAM): 256 MB

· Harddisk: 3 GB

· CD-ROM

Minimumskrav for tynnklienttjener som skal betjene opptil 4 tynnklienter er:

· Prosessor: 300MHz

· Minne (RAM): 256 MB

· Harddisk: 2 GB

· CD-ROM

En arbeidsstasjon bør minst ha:

· Prosessor: 150 MHz

· Minne: 64 MB

· CD-ROM

En tynnklient krever minimum:

· Prosessor: 80 MHz

· Minne: 24 MB

· Det er ikke nødvendig med pci/agp skjermkort

· Det går greit med isa nettverkskort, for eksempel 3com509, men helst et pci nettverkskort

Minimumsspesifikasjon for en HUB er:

· Hastighet: 10 Mb/s

· Porter: 4 stk

Vårt Test Nettverk ved HiG, består av følgende spesifikasjoner:

Filtjener: 200 MHz, 256 RAM, 3GB HD, CD-ROM, 1 stk PCI 10/100 nettverkskort, diskettstasjon, samt mus og tastatur.

Arbeidsstasjon: 233 MHz 64 RAM, CD-ROM, 1 stk PCI 10/100 nettverkskort, diskettstasjon, samt mus og tastatur.

Tynnklienttjener: 300 MHz, 256 RAM, 3 GB HD, CD-ROM, 2stk PCI 10/100 nettverkskort, diskettstasjon, samt mus og tastatur.

Tynnklienter: 233 MHz, 64 RAM, diskettstasjon, 1 stk PCI 10/100 (3Com 3c905(c)), samt mus og tastatur

2 stk Switch: 5 port 10/100 Mbps

Firewall/Router: 133MHz, 256 RAM, 2stk nettverkskort PCI 10/100, ingen skjerm da vi benytter oss av ssh.

2.2.8 Softwarekrav

Skolelinux/Debian OS (filtjener, arbeidsstasjon, tynnklienttjener)

Overvåkningsprogram: Nettverk overvåkningsprogrammet Nagios.

Tjeneren Nagios skal kjøre på må ha Apache webserver installert noe som allerede ligger med i Skolelinux distribusjonen.

2.3 Detaljert kravspesifikasjon

2.3.1 Overordnet struktur

Fig 2.1 Oversiktskart

2.3.2 Funksjonell struktur og tverr-relasjoner

Systemet har webgrensesnitt, hvor all informasjon publiseres. Dette er et enkelt system med fargekodene grønn, gul og rød slik at det enkelt legges merke til hva slags feil det dreier seg om og hvor feilen ligger.

Struktur:

· Oppbygging av nettverk

· Moduler i Nagios (add-ons, plugins)

2.4 Data spesifikasjon og dataordliste

2.4.1 Data input

Nagios vil ved hjelp av plugins, kunne sende forespørsler over nettet til maskiner den er konfigurert til å spørre om informasjon. Den tar så og bearbeider svarene den får, og legger informasjonen ut på web.

2.4.2 Data output

Nagios vil vise all den informasjonen den innhenter i webgrensesnittet. Den lager også loggfiler som oppdateres i realtime. Samtidig vil webmaster bli varslet via mil dersom noe ikke er som det skal.

2.4.3 Normal operasjon

Ved normal drift vil ikke systemet gi noen signaler om feil. Den vil da bare utføre sjekker som er satt opp i programmet. Disse utføres med jevne mellomrom, i vårt tilfelle hvert andre minutt.

2.4.4 Modus og kontroll

Nagios tjeneren vil få informasjon fra maskiner som kjører Nagios daemon, i tillegg til at den sender forespørsler selv. Det er også mulig å sette tidsintervaller når du vil at Nagios skal scanne nettverket manuelt og hvor mange hoster/tjenester du ønsker at skal sjekkes parallelt. Dette kan være en fordel ved et høyt belastet nettverk, da Nagios scanning bruker litt av båndbredden.

2.4.5 Ytelse

Responstiden vil avhenge av hardware spesifikasjonen til tjeneren, og nettverkshastigheten. Ettersom nettverket er bygd opp med TCP/IP som protokoll vil det være stor pålitelighet, fordi TCP utfører sjekker på om pakkene kommer frem.

Forespørsler fra Nagios besvares innen noen millisekunder, fordi det går en ”daemon” på den andre maskinen som samler informasjon, og sender til Nagios tjeneren så fort den får en forespørsel.

2.4.6 Sikkerhet

Systemet vil gå på en tjener tilknyttet et lokalt nettverk (LAN). Det vil være en firewall tilknyttet internett, som vil prøve å blokkere for inntrengere i nettverket/systemet.

Nagios krever passord (kjører som egen bruker ved navn Nagios) for å få lov til å endre filer. I tillegg er det autentisering og verifisering med brukernavn og passord for å få startet web grensesnittet av Nagios.

2.4.7 Oppstart og nedtakning

Dette er et nettverkssystem som fra vår side vil bli overlevert Skolelinux den 19.mai 2003 (se appendiks B1). Etter denne dato er det opp til Skolelinux hvor lenge de vil bruke systemet. Videreutvikling vil skje dersom noen ønsker å forsette med dette prosjektet.

2.4.8 Tilgjengelighet

Systemet skal kjøres en på en maskin, og skal være oppe hele tiden bortsett fra når den må vedlikeholdes. Vedlikehold skal skje på kveldstid, da det er minst muligheter for at det er noen som benytter seg av maskiner på nettverket.

2.4.9 Innebygde tester

Systemet skal gi tilbakemelding når en eller flere hoster/tjenester feiler. Dette blir vist i et grafisk vindu på maskinen der programmet kjører. Der lyser det da lamper som indikerer feil og en kort tekst om hva som er galt.

2.5 Operasjon i feilsituasjoner

2.5.1 Feilrapportering

Når en maskin feiler skal det komme opp en feilmelding på skjermen der systemet kjøres. Feilen vil bli merket med rødt, samtidig som det kommer en melding om hva som er galt med den spesifikke maskinen. Feil vil bli skrevet til logg filer. Samtidig vil feilene bli varslet på e-post til administratoren på systemet.

2.5.2 Gjenervervelse etter feil

Dersom strømmen blir brutt vil systemet starte automatisk opp igjen ved oppstart av maskinen. Systemet vil resette seg, og begynne å overvåke på nytt. Loggfiler vil da indikere at maskinen har startet på nytt, men fortsatt inneholde den gamle informasjonen.

2.6 Begrensninger

2.6.1 Software standarder og språk

Videreutviklingen vi selv har gjort er skrevet i Perl, fordi den eksisterende kode består av Perl. Web grensesnittet kan åpnes i Opera og Konqueror.

2.6.2 Software grensesnitt

Ved å kjøre de egenproduserte skriptene blir det laget Nagios konfigurasjonsfiler. Filer blir kopiert over nettverket vha. kommandoen scp benytter seg av SSH protokollen. Her blir brukeren bedt om å taste inn passordet til maskinen den prøver å kopiere filer til.

2.6.3 Software pakker/verktøy

Vi har benyttet oss av stabile versjoner av programvare. Programmene kan være av typen tar.gz, eller deb-pakker (debian pakker). Debian pakkene er installert med en funksjon i Debian distribusjonen som heter apt-get. Nagios-kjernen som kjøres på filtjeneren, er installert ut i fra det pakkede formatet tar.gz. NRPE plugin er installert på tynnklient-tjenerene med deb-pakker (debian pakker).

2.6.4 Software kommunikasjonsstandarder og grensesnitt

Nettverket vi har benyttet er et Ethernet. Dette kan kjøre på hastighetene 10 og 100 Mbps. Det brukes i tillegg TCP/IP som kommunikasjonsprotokoll.

2.6.5 Operativsystem

Systemet skal kjøres på Linux-plattformen, mer bestemt Skolelinux. Skolelinux kjører debian som kjerne, og er utviklet ut fra det.

2.6.6 Toleranser, marginer og muligheter/tilfeller

Vi har satt overvåkningssystemet til å sjekke status hvert 2. minutt pga. at ping osv. tar opp båndbredde. Programmet i sin helhet bør være så lite som mulig da det er ønskelig å få hele Skolelinux inn på en CD.

2.7 Hardware design begrensninger

2.7.1 Hardware krav og omgivelse

Overvåkningssystemet krever ingen endring i hardware spesifikasjonen utover det Skolelinux har satt som et minimumskrav for filtjeneren. Se pkt 2.6.

2.8 Aspekter omkring livssyklus

2.8.1 Dokumentasjon

Dokumentasjonen blir laget i en papirutgave og i elektronisk form. Dokumentet blir liggende som en pdf fil på tjeneren til Skolelinux sin CVS. Den vil da være tilgjengelig for alle som ønsker å lese dokumentet.

2.8.2 Krav til support, service og vedlikehold

Det vil fra vår side ikke bli aktuelt med support, service eller vedlikehold av produktet etter innlevering, men supporten for Nagios vil foreligge vha. maillister hos Skolelinux og via maillister hos Nagios. Ref [1].

2.8.3 Krav til utvidelser

Systemet kan videreutvikles av alle som ønsker det, fordi det er åpen kildekode. Om Skolelinux ønsker utvidelser av programmet kan de gjøre dette. Vårt system er halvautomatisk, men det er muligheter for å gjøre det helt automatisk.

2.9 Aspekter omkring installasjon

2.9.1 Hardware installasjon

Her blir det opp til vær enkelt skole å avgjøre hvor systemet fysisk skal plasseres, rent softwaremessig er vår applikasjon ment å ligge på filtjeneren samt ”demons” som eksekverer på tynnklienttjeneren.

2.9.2 Opplæring

Det vil fra vår side foreligge en brukermanual og en installasjonsveiledning på hvordan systemet ser ut, fungerer og installeres. Utover dette skal det holdes en fremlegging/opplæring for Skolelinux medio mai.

2.10 Prosjektstyring, inkludert kvalitetssikring

Vi har hele tiden hatt kontakt med Skolelinux via deres mailingliste. Her har vi fått svar på de fleste spørsmål og problemer som har kommet opp underveis. Vi har hatt en egen veileder fra Skolelinux (Frode Jemtland) i tillegg til en intern veileder her ved HiG (Erik Hjelmås).

Vi har hele tiden lagt ut dokumenter på vår webside, dvs. den aller siste dokumentasjonen til forskjellige tider under prosjektets gang. Annenhver uke har vi hatt møte med intern veileder her ved HiG, i tillegg egne gruppemøter hver uke. Møte med ekstern veileder har foregått på utviklersamlinger til Skolelinux.

Gruppen følger en ganske flat organisasjonsstruktur gjennom hele prosjekt perioden, men har gitt en person leder ansvaret dersom noen uenigheter skulle oppstå innad i gruppa.

2.11 Metode bruk og fremgang i utarbeidelse av

kravspesifikasjonen

For utarbeidelse av denne kravspesifikasjonen, så vi først på mulighetene med å lage en behovsanalyse for å gå ut i ”felten” å sjekke en vanlig brukers oppfattning. Men når det gjelder utførelse av behovsanalyse, viser det seg at det ikke var så mye informasjon å hente ut fra målgruppen (lærere, IT-ansatte og ellers folk som skal kunne drifte et Skolelinux nettverk). Dette er sannsynligvis fordi prosjektet enda er på et tidlig stadium og de færreste har rukket å sette seg inn i overvåkningsproblematikken.

Vi bestemte oss derfor å foreta en helhetsvurdering av hvilke faktorer som skal være med og ikke med, på bakgrunn av egne erfaringer og samtaler med personer som driver med overvåkning og drifting til daglig.

Noen av personene vi har benyttet oss av er Sverre Stoltenberg(Opera), Jonny Birkelund(Opera), Tor Erik Neuberg(EDB TEMCO), Jon Magnus Dullerud (Forsvarets datasentral Kolsås)

Gruppen har på bakgrunn av møter, mailer og samtaler med disse samt egne erfaringer kommet frem til punktene oppsatt i kravspesifikasjonen 2.1 - 2.10

Kapittel 3 - Analyse og design

3.1 Tidligere system

Vi tok en gjennomgang av aktuelle eksisterende systemer innen overvåkning av nettverk, og gjennomførte en analyse av hvert enkelt program. Etter noe tid med testing og innhenting av informasjon kom vi frem til en løsning alle på gruppa var fornøyd med.

3.1.1Helhetsvurdering av nettverk overvåkningsprogrammer

Vi har sett på flere overvåkningsprogrammer i forhold til hverandre. Grunnregelen er at programmet må støtte GPL (General Public Licence). Følgende programmer har vi tatt med i vår helhetsvurdering:

Valget av overvåkningssystem har vi fattet ut i fra analyse av programmene på bakgrunn av dokumentasjon vi har funnet på internett og på deres respektive hjemmesider.

Analysen har gått ut på å lese dokumentasjon, teste, diskutere, innhente erfaringer hos enkeltpersoner og møter med aktive innen Skolelinux miljøet. For mer informasjon om de forskjellig programmene se vedlegg sist i dette kapittelet.

3.1.2 Big Brother [2]

Gruppa holdt lenge en finger på overvåkningsprogrammet Big Brother etter en samtale med Jonny Birkelund fra Opera. Opera bruker dette og var veldig fornøyde med funksjonalitet og oppsett. Men etter en del undersøkelser og samtaler med overvåkningsansvarlig hos Opera, Sverre Stoltenberg, ble vi enige om å vrake Big Brother da applikasjonen har et alt for komplisert lisens oppsett [vedlegg 2], noe som ikke svarer til Skolelinux sine forventninger og krav.

3.1.3 The Angel Network Monitoring system [3]

Et meget bra overvåkningssystem som faktisk støtter de fleste av våre krav til systemet, men har ikke noe form for ip-kart. Og slik web grensesnittet går frem, vil den bli veldig rotete dersom det skal opereres med flere enn 20 hoster, noe et Skolelinux nett sannsynligvis vil overgå. Systemet har heller ingen form for grafisk fremstilling av systemet og sjekker ikke prosess kapasitet. Systemet ble derfor vraket.

3.1.4 Snort [4]

Programmet Snort er et enkelt program og er lett å sette seg inn i men har flere ulemper vi ikke ønsker. Programmet krever mye software, databasetilgang, PHP og består av mye software du egentlig ikke har noe nytte av. Det er også et utall av kommandoer, som fort kan forvirre den uerfarne bruker. Samtidig lagrer programmet utrolige mengder med data og er et verktøy du fort blir lei av å bruke i følge Kollbjørn Bekkelund (ref. [13]). Fordelene er at det har en utrolig stabilitet.

3.1.5 Spong [5]

Spong er en liten og enkel program pakke, ikke i tvil om at den er bra til sitt bruk, men har uoversiktlige konfigurasjonsfiler og krever en del tilleggs pakker for å få opp ønskede tjenester. Eks: Systemstatus.

3.1.6 Mon [6]

Vi kjørte opp Mon for test på vårt nettverk, men fant ut at dette var enkelt og lett å sette opp, men har et alt for uoversiktlig grensesnitt på feilmeldinger, samt at det ikke inneholder noe form for ip-kart. Du er også avhengig av å kjøre opp web grensesnittet via terminalvinduet, med de opsjoner du ønsker å sjekke. Dette er et program for de med litt mer innsikt og er alt for enkelt med hensyn til våre krav til system.

3.1.7 Nagios [1]

Nagios er en videreføring av programmet Netsaint. Et program som innehar alle de aktuelle tjenester vi har satt som krav og det er store muligheter for utvidelse dersom det er ønskelig. Nagios er ikke det enkleste å konfigurere, (Ref. vedlegg 2: ”Om noen greide og løse konfigurasjons-fil-helvete...”) men en utfordring gruppa faktisk velger å ta, da målet vil være å automatisere installasjon ”rett ut av boksen”. Nagios er også det programmet vi har fått flest positive tilbakemeldinger på mht. oversiktlighet og brukervennlighet.

Gruppa velger derfor Nagios som overvåkningsprogram.

Se slutten av kapittelet, referert som vedlegg 1-7, for mer informasjon .

3.2 Nytt system

Det nye systemet skal kunne installeres ”rett ut av boksen”, dvs. rett fra en Skolelinux CD. Når selve programmet er installert er vi avhengig av å kjøre noen perlscript for å få den rette konfigurasjonen på nettverket, ettersom Skolelinux nettet i prinsippet består av to nett(10.0.2-nettet og 192.168-nettet) Nagios er derfor avhengig av å få informasjon i fra ulike servere og derfor perlscriptene for å slippe å legge inn hver enkelt host manuelt.

3.2.1 Hva skal systemet løse

Systemet skal løse Skolelinux sitt ønske om å kunne overvåke et nettverk med maskiner og finne ut når og hvor maskiner og tjenester får feil. Systemet skal kunne administreres av IT ansvarlige på de skolene som tar i bruk Skolelinux.

3.2.2 Fremover

Dette systemet vil kunne overvåke et Skolelinux nettverk på skoler som har dette installert, men systemet trenger oppdateringer for å kunne være optimalt med tanke på ytelse og sikkerhet.

For IT ansvarlige ved skolene vil dette bli et verktøy for å kunne se hvilke feil som har oppstått, og rette disse så fort det lar seg gjøre. De vil også få beskjed via e-post når noe har skjedd.

Siden dette prosjektet baserer seg på fri kildekode, vil det ikke være noe økonomisk perspektiv på dette. Dette prosjektet går under GPL lisensen. Da kan alle utvikle systemet videre uten å måtte tenke på lisenser.

3.3 Metoder

For å få automatisert dette programmet og få det til å fungere på et Skolelinux nettverk, må det kjøres noen perlscript. Dette må gjøres på tjeneren av det nettet som skal overvåkes.

3.3.1 Fremgangsmåte

Alle gruppemedlemmene har fulgt kurset ”Drift av flerbrukersystemer”, hvor Perl er en del av pensum, og med dette utgangspunktet kunne vi komme i gang med litt programmering.

I begynnelsen utførte vi analyser av eksisterende programvare og etablerte prosjektets webside (se vedlegg B1). På disse sidene la vi ut dokumentasjon som andre kunne lese og gi tilbakemeldinger på.

Det viste seg at analysen av programvare, og det å lære seg Skolelinux oppsettet tok lengre tid enn vi hadde planlagt. Pga. dette kom vi litt sent i gang med programmeringen.

3.4 Design

Flyt diagram og Use-case

Overordnet Nagios struktur og hvordan den behandles av brukeren/administratoren

3.4.2 Use-case diagram m/beskrivelse

Fig 3.5

Use-case Beskrivelse

Navn: Sjekke diskplass på servere

Aktør: It-ansvarlig og Elev

Handlings flyt:

- Sjekke disk hda1/5/7/9 på filtjener+ swap partisjon

- Sjekke disk hda 1og 5 på LTSP-tjener + swap partisjon

- Viser deretter status fra disker på skjerm

Alternativ handlings flyt: disk full, sjekke mot grenseverdier og gi melding til skjerm og elever gir beskjed om noe er feil.

Navn: Sjekke CPU load

Aktør: It-ansvarlig

Handlings flyt:

- Sjekke CPU load på filtjener.

- Sjekke CPU load på LTSP-tjener.

- Viser deretter status fra CPU load på skjerm.

Alternativ handlings flyt:

Høy CPU load, sjekke mot grenseverdier og gi melding til skjerm.

Navn: Sjekke at alle hoster er operative

Aktør: It-ansvarlig

Handlings flyt:

- Sjekke ping status på filtjener, ingen nødvendighet da Nagios kjører fra denne hosten

- Sjekke ping status på LTSP-tjener

- Sjekke ping status fra tynnklienttjener og videre ned til de tynne klientene

- Sjekke ping status på arbeidsstasjoner

- Viser deretter status på skjerm.

Alternativ handlings flyt:

Filtjener ikke operativ, LTSP-tjenere ikke operative, arbeidsstasjoner ikke operative og tynneklienter ikke operative. Gir melding til skjerm.

Navn: Sjekke servicer/tjenester på nettet

Aktør: It-ansvarlig

Handlings flyt:

- Sjekke smtp, http, dns, swap på filtjener.

- Sjekke smtp, swap load på LTSP-tjener.

- Viser deretter status for tjenester på skjerm.

Alternativ handlings flyt:

Tjenester er ikke i orden, gir melding til skjerm.

Navn: Sjekke om arbeidsstasjon er operativ

Aktør: It-ansvarlig og lærer

Handlings flyt:

- Sjekker om arbeidsstasjoner er operative.

- Viser deretter status for tjenester på skjerm.

- Diskplass må læreren sel holde kontroll på.

Alternativ handlings flyt:

Arbeidsstasjoner ikke operative, gir melding på skjerm

Vedlegg 1

BIG BROTHER [2]

Big Brother er et webbasert system og nettverks overvåknings verktøy. Det inneholder et enkelt shell script som kontinuerlig overvåker systemforhold og nettverkets stabilitet. Diskplass, CPU, tjenere og viktige prosesser kan holdes under oppsikt. Systemet støtter Unix og NT.

Big Brother's web grensesnitt er oversiktlig og presenterer maskinene og servicer i en matrise med farge koder som angir systemstatus.

Krisevarsling foregår vha. logger og e post. Men kan også varsle vha nummeriske logger og SMS, dersom de respektive tilleggs programmer er installerte.

Fordeler:

Oversiktlig

Sjekker det vi har satt som vesentlig i vår oppgave beskrivelse

Lett å konfigurere

Anbefales av folk som har brukt programmet en tid

Ulemper:

Big Brother innehar en altfor komplisert lisens, som ikke svarer til våre og Skolelinux sine krav.

Print Screen av web-GUI fra Big Brother

Vedlegg 2

Mail fra Sverre Stoltenberg hos Opera

BB har en litt råtten lisens, og er ganske kronglete og ha med å

gjøre. Vi på Opera kan bruke BB fritt fordi vi kun overvåker våre

egne servere... Fra <URL: http://www.bb4.com/license.html

Do I need to buy a license?

* E-commerce sites, MSPs and ASPs need licenses

* ISPs don't need licenses for Virtual Web servers but do for

co-located servers

* If you monitor your customer's servers, you need licenses

* If you're an independent system/network admin contractor, no

licensing is required

* You're monitoring your own internal servers, you don't need

licenses

If you're an independent system/network... faller kanskje i kategorien Skolelinux?

De tok den ut av debian for lenge siden, så ting kan tyde på at det ikke er så bra.

BB ble forresten ganske grei å ha med og gjøre i kombinasjon med rsync og cfengine.

”Har du noen erfaringer med Nagios?”

Jeg har også kikket en del på nagios og har seriøst vurdert og bytte

til det. Problemet er at vi samler en del statistikk og slikt gjennom bb, og det blir litt for mye for nagios og overføre av data. Det kan nok løses utenfor nagios men det ligger litt på is foreløpig.

Nagios kommer jo ferdig pakket for debian, og det er lett og lage sine egene sjekker, så jeg ville kanskje vurdert den. (Om noen greide og løse konfigurasjons-fil-helvete...)

/Sverre Opera Software

Vedlegg 3

The Angel Network Monitoring [3]

Angel er et enkelt og brukbart verktøy for å overvåke tjenester på nettverket.

Teknisk sett er det et perl program som kjører hvert (x) minutt vanligvis i fra cron og kaller opp forskjellige perl sub program (også kalt plugins) for å gjøre de aktuelle testingene den er konfigurert til.

Den vil så generere en HTML tabell som viser status av nettverket ditt.

Hovedsaker:

- Administreringen er sentralisert, så å legge til hoster og tjeneste innebærer kun editering av ei fil.

- Programmet benytter seg av ”plugins” konseptet som vil si at det er enkelt å tilpasse og gjøre endringer.

- Programmet benytter seg av HTML- output, som vil si at du fra hvilken som helst maskin med internett, kan sjekke statusen på nettverket ditt.

- Programmet inneholder Java applet support og Java script support slik at du ved en alarm vil kunne få en pop-up nederst på skjermen som sier om noe er galt.

- Programmet støtter også ssh.

- Programmet støtter kravet til gratis programvare (GLP)

Basis:

Kjernen av programmet er et angel perl script, som er ment å kjøre i fra din cron. Ved kjøring(eksekvering) av programmet, vil det først lese fra filene conf /hosts.conf og conf /angel.conf. For så å utføre de spesifikke sub testene og generere status med eventuelle spesifikke feil på maskinene som er i nettverket ditt.

Positivt:

- Enkelt web grensesnitt

- Sjekker diskplass

- Sjekker TCP kommunikasjon på en gitt port

- Sjekker trafikk kapasitet på nettverket

- Sjekker oppetid på maskiner i nettet

- Web grensesnitt for konfigurering

- SSH support

- Java script support

- Java applet support

- Html output

- Lett å konfigurere

Negativt:

- Ikke ip-kart, kan da muligens bli noe rotete dersom du har opp til 255 hoster på nettet.

- Ingen grafiske framstillinger av systemet, slik vi ønsker oss, for å få et lettfattelig bilde av hva som skjer eller kommer til å skje.

- Benytter seg av programmeringsspråket Perl. Perl er et program som er gjør mye på lite, dvs. et lett språk å kode, men vanskelig å lese og forstå, dersom du ikke er innside i språket. Men som sagt, et enkelt språk å editere.

- Sjekker ikke ønskede prosesser.

Skjermbilde av web-GUI.

Oversiktsbilde av alle maskiner på nettet

Eks. på feilmeldinger:

Vedlegg 4

Snort [4]

Snort er et verktøy som kan gjøre mange oppgaver på samme tid.

Vanskelighetsgraden for å sette opp Snort er ikke for høy, men en ulempe er at den krever databasetilgang, PHP og en masse saker du egentlig ikke har brukt for. Snort er ikke særlig vanskelig å bruke, men et utall av kommandoer kan forvirre den som ikke kan så mye om IT og drift.

Snort opptrer i tre moduser: sniffer, packet-logger og network intrusion detection (crakere).

I sniffer mode, leser Snort pakkene direkte fra nettet og viser dem i en kontinuerlig strøm i konsollet.

Som packet logger går samme informasjon direkte til disk i stedet.

Network intrusion detetection mode er den mest komplekse og konfigurerbare måten. Her lar man Snort analyserer all nettverkstrafikk og sjekker resultatene mot forhåndsdefinerte regler. Deretter utfører Snort bestemte aksjoner basert på hva slags trafikk den ser.

Tilleggsprogrammet ACID (Analysis Console for Intrusion Databases fra [8]) lar deg visualisere Snort-loggene i web-format.

Uten å installere ACID er Snort unyttig for den jevne bruker.

Et meget bra verktøy for den vitebegjærlige, men minus for at den krever mye software, lagrer utrolige mengder med data, og er et program du fort kan bli lei av å sjekke etter en tid.

Fordeler:

Ganske enkelt å sette opp og konfigurere. Det er enkelt å bruke.

Ulemper:

Krever mye software, databasetilgang, PHP, og en masse saker du egentlig ikke har brukt for. Den lagrer utrolige mengder med data, og er et verktøy man blir lei av å sjekke etter en tid.

Vedlegg 5

Spong v2.7 [5]

Dette er en enkel systemovervåkningspakke som kalles Spong.

Spong har følgende tjenester:

- Klient basert overvåkning (CPU, disk, prosesser, logger osv.)

- Overvåkning av nettverkstjenester som (smtp, http, ping, pop, dns, osv.)

- Gruppering av hoster (routere, tjenere, arbeidsstasjoner og datamaskiner)

- Regelbasert melding da problemer oppstår.

- Status vises vha. tekst eller web-GUI

- Lagrer historiske data

- Informasjon om hjelp ved problemer

Eksempel på gruppering av hoster:

'servers' => { name => 'Main servers',

summary => 'Main servers that are up 24x7',

members => [ 'zero.monsters.org',

'godzilla.monsters.org',

'rodan.monsters.org',

],

display => 1,

Mulighet for grafer over:

Diskbruk (4stk: pr time, dag, uke, måned)

Last gjennomsnitt.

Ledig plass

Antall brukere

Antall jobber

System sammendrag for hver enkelt maskin

Fordeler:

Bra diskbruk grafer.

Ulemper:

Lite oversiktlig GUI.

Print screen av Web-GUI:

Vedlegg 6

MON Overvåkningssystem [6]

Inneholder:

Overvåker:

ICMP, SMTP, Telnet, FTP, NNTP, HTTP, POP-3, IMAP, TCP-baserte tjenester, diskplass, oppetid via asynkron SNMP, HP skrivere via SNMP, prosesser via SNMP, diskovervåkning over nettverk via SNMP, kvotehåndtering over nettverk via SNMP, LDAP, DNS, mSQL and MySQL

databases, Sun RPC tjenester, Compaq Presario chassis, Brocade SilkWorm FCAL switcher.

Feilmeldinger:

1. Email varsling.

2. Alfanumerisk pagineringsvarsel via modem, ved å bruke

QuickPage.

3. Alfanumerisk beskjed til portabelt utstyr ved å bruke SNPP.

4. Alfanumerisk paginering via email.

5. Feller kan bli levert til en fjern Mon server.

6. Det er trivielt å legge til sine egne alarmer, og det trengs ikke å legges til kode på serveren pga dette.

MON deler opp i forskjellige områder. Den kjører ikke feilmeldingsskriptene før en monitor har sagt at den spesifikke tjenesten er nede.

Fordeler:

1. Programkode skrevet i C, Perl, shell

2. Fri programvare (fri distribuering)

3. Kan definere grupper av maskiner

4. Fleksibel konfigurasjonsfil, lage grupper av maskiner og hver gruppe kan ha flere tjenester.

5. Kan legge til tjenester, selv etter at mon er ferdig konfigurert og er oppe og kjører. Trenger ingen endringer på MON-serveren.

Ulemper:

1. Må kjøre opp webgrensesnitt fra terminalvindu med de opsjoner man ønsker.

2. Uoversiktlig grensesnitt på feilmeldinger.

3. Har ikke ip-kart

4. Ingen muligheter for grafisk fremstilling av systemet.

Print screen av Web-GUI:

Vedlegg 7

Nagios [1]

Nagios er et nettverks overvåkningssystem som overvåker oppe /nede tid og prosesser/tjenester du ønsker på maskinene i nettet ditt.

Hva kan Nagios gjøre for deg?

· Et veldig kraftig verktøy som overvåker nettverket ditt med tjenester som SMTP, POP3, HTTP, NNTP, PING osv.

· Overvåkning av systemressurser som CPU last, harddisk og minnebruk, etc.

· Enkle plugin design så brukeren lett kan utvikle sine egne host og service tester.

· Lett å definere nettverks hoster i hierarki, slik at man lett ser om det er hosten og eller en kommunikasjons bro mellom to nett som er nede.

· Gir automatisk informasjon dersom det oppstår problemer med tjenester eller hoste. Og gir melding om dette via e-post, SMS etc.

· Automatisk rotasjon av log filer.

· Web grensesnitt som viser deg status av nettet ditt, osv.

· Ability to define event handlers to be run during service or host events for proactive problem resolution.

· Gjenoppretter host og service overvåkning ved restart

· Fastsette nede tid på systemet ved eventuelle utbedringer, slik at ikke systemet varsler feil.

Nagios er lisensiert under termer av GNU General Public License Version 2. Se Appendiks A3 for mer informasjon om GPL.

Kapittel 4 - Installasjon

Når vi manuelt skal installere Nagios på et Skolelinux nettverk, er det tre hovedpakker man må forholde seg til; Kjernen til Nagios, Nagios-plugin, og NRPE-plugin. Det må også installeres noen ekstra biblioteker for at Nagios skal fungere med alle sine respektive tjenester. Disse bibliotekene har som hovedoppgave å tilpasse og forstå noen av de grafiske fremstillingene av Nagios på web-grensesnittet. Kjernen til Nagios og Nagios-plugin installeres på filtjeneren. NRPE-plugin og Nagios-plugin installeres på LTSP-tjenerene. Noen av pakkene kan bli lokalisert på Nagios sin offisielle hjemmeside [1]. Andre pakker kan installeres ”automatisk” med kommandoen: ”apt-get install <pakken>”

I dette kapittelet har vi illustrert steg for steg hvordan man installerer Nagios manuelt og alle pakkene den avhenger av. Vi har brukt masse tid på å installere og konfigurere Nagios manuelt, hovedsakelig for å få kjennskap og kunnskap rundt strukturen og oppbyggingen av programmet. Siden Nagios har åpen kilde, var det vesentlig at vi satte oss inn i byggesteinene til programmet. Ved første blikk i brukermanualen, fikk vi inntrykk av at Nagios ikke var egnet for nybegynnere. Ingen på gruppa er nybegynnere, men vi fant ut med en gang at det var mye konfigurering og lesing som var nødvendig for at Nagios skulle fungere slik vi ønsket det.

I begynnelsen av prosjektet var det usikkerhet om vi skulle bruke tar.gz-filer eller deb-pakker. Som konklusjon fant vi ut at deb-pakker var den enkleste løsningen, men det er dessverre kun ustabile debian pakker tilgjengelig på internett. Fordelen med debian installasjon er at Nagios blir automatisk kompilert og installert på maskinen. Dette tar atskillig kortere tid enn å kompilere inn manuelt. Nå skal vi ta en kikk på hvordan manuell kompilering og installasjon av Nagios kan utføres.

For å få applikasjonen til å fungere etter vårt ønske på systemet, installerte vi noen pakker på tjeneren og på tynnklienttjeneren.

Installasjonen til Nagios er vist i detaljer på norsk i Appendiks D1, og på engelsk i Appendiks D2. Disse viser steg for steg ulike kommandoer som må eksekveres, og ”output” fra programmet under kompilering.

Installasjonen av NRPE er beskrevet i Appendiks D3 (engelsk). Dette vedlegget viser hvordan installasjon av NRPE utføres med bruk av deb-pakke.

Den automatiske konfigurasjonen til Nagios er beskrevet i Appendiks E1. Dokumentet illustrerer hvordan de ulike scriptene skal eksekveres på alle tjenerne. Denne er skrevet på engelsk, fordi dette er en brukermanual som er rettet mot Skolelinux prosjektet.

Appendiks E2 er en brukermanual for hvordan man konfigurerer k-mail, slik at den tar i mot feilmeldinger fra Nagios. Det vil si at nagios-administrator får feilmelding per email hver gang det oppstår en feilmelding, og når den returnerer til stabil tilstand i Nagios.

Kapittel 5 - Implementering

I dette kapittelet forklares hvilke prinsipper som er fulgt, hvilke verktøy vi har brukt og hvorfor vi har valgt disse verktøyene.

Det meste av dokumentasjonen som omhandler implementasjon er skrevet på engelsk. Grunnen til dette er at denne dokumentasjonen er direkte rettet mot Skolelinux og er beregnet for videre utvikling. Derfor har vi valgt å trekke ut disse som egne appendikser, siden det ikke er ryddig å blande engelsk og norsk i selve rapporten. Henviser til appendiks E1, E2, E3, E4, E5, E6.

5.1 Verktøyvalg

All koden vår er skrevet i Perl. For å skrive koden har vi brukt teksteditorene ”vi” og ”advanced editor” i Linux. For å testkjøre programmet har vi brukt kompilatoren til Perl. Utarbeidelsen av Gant skjemaet ble gjort i Microsoft Project. og selve rapporten er skrevet i MS Office Word XP.

Vi valgte å programmere i Perl, siden vi har hatt grunnleggende Perl koding høsten 2002. Ettersom vi skulle hente ut informasjon fra filer som inneholdt tekststrenger og splitte disse, så var valget av Perl innlysende da Perl er meget godt egnet for behandling av tekststrenger. Vi valgte MS Office Word XP fordi maskinene på vår test lab var av så dårlig kaliber at de hadde problemer med å åpne Open Office.

5.2 Organisering av kode og prinsipper

Under kodingen har vi prøvd å være konsekvent med navngiving av variabler og filnavn.

Variabler er angitt med en eller flere bokstaver. Filnavnene som blir generert ut fra skriptene, har logiske navn i forhold til det de blir generert ut fra.

Eksempel på et filnavn kan være: hosterTKS100.txt. Hvor hoster betyr at filen inneholder hoster ”under ” TKS100. Tallet 100 er tatt i fra siste del i IP adressen til maskinen (10.0.2.100). Dette er en fil som blir generert på tynnklienttjeneren, derav navnet TKS (tynnklient server).

5.2.1 Organisering av kode

Koden er organisert med tabulatorinnrykk og linjeskift for å skille forskjellige deler av koden fra hverandre. Dette gjelder bl.a. løkker, der vi har organisert med tabulatorinnrykk ved starten av løkka og helt til løkka er slutt. Dette gjør at det blir enklere å vite hvor løkker starter og slutter.

Vi har brukt denne metoden på alle skriptene, siden det er mange linjer med kode. Innrykk i koden gjør den enklere å lese og den blir mer oversiktlig.

Filer som blir generert på forskjellige maskiner hentes inn av den sentrale maskinen ved å kopiere filene over nettverket. Filene blir også automatisk lagt i den katalogen som de skal ligge for å få programmet til å fungere med riktig konfigurasjon.

5.3 Administrasjon

Ved betjening av web grensesnittet er det autentisering med brukernavn og passord for å få tilgang til det. Det er laget en brukermanual som beskriver de forskjellige funksjonene og informasjonen som hvert skjermbilde inneholder. (Se Appendiks E4).

Fra webgrensesnittet kan man administrere feilmeldinger og få rapporter om hoster og hostgrupper. Ved endringer i nettverket (f eks lagt til/fjernet maskiner) må manualen i Appendiks E1 følges.

5.4 Hvordan bruke Nagios

I menyen vises en liste med linker til forskjellige typer skjermbilder som viser informasjon og status til maskiner og tjenester. Her kan det også lages rapporter over feilmeldinger og status om hoster og hostgrupper. Disse spesifiseres av den som ønsker rapporten. Vha. rullgardinmenyer kan en velge forskjellige spesifikasjoner. Dette kan en se i brukermanualen (engelsk) vedlagt i Appendiks E4.

Dokumentasjon av script og kode er beskrevet i Appendiks E3. Beskrivelsen gir innsikt i hvordan scriptene er bygd opp og tanken bak virkemåten til scriptene. Denne er skrevet på engelsk fordi den er en brukermanual som er rettet mot brukere av Skolelinux.

5.5 Beskrivelse av konfigurasjonsfilene

Nagios er avhengig av mange konfigurasjonsfiler for at tjenestene skal fungere på ønskelig måte. Overvåkningsprogrammet benytter seg av tretten konfigurasjonsfiler, derav to av filene blir generert av perl-scriptene. De resterende elleve konfigurasjonsfilene, er statiske etter modifikasjon som tilfredsstiller den utarbeidede kravspesifikasjonen. Dette vil si at perl-scriptene har ingen innvirkning på de resterende elleve filene. Vi har valgt å konfigurere Nagios på en så enkel måte som mulig. Dette vil si at vi har gruppert maskiner i to grupper. En for arbeidsstasjoner, og en for LTSP-tjenere. Brannmuren og filtjeneren er lagt inn ”default” i konfigurasjonsfilene, siden de alltid vil få samme adresse og tjenester knyttet til seg.

De dynamiske konfigurasjonsfilene er vedlagt i Appendiks E5. Disse konfigurasjonsfilene er et resultat av eksekvering av scriptene i Appendiks E3.

De statiske konfigurasjonsfilene til Nagios er dokumentert i Appendiks E6. Disse konfigurasjonsfilene forblir statiske etter modifikasjon som er fastlagt og bestemt ut i fra vår kravspesifikasjon.

Kapittel 6 - Testing

6.1 Testing

Testing er en sentral del av Skolelinux prosjektet. For hver liten del som blir utviklet blir det laget en Pre Release (PR) som blir lagt ut på internett for nedlasting og testing. Når vi begynte med våres hovedprosjekt var PR 31 kommet. Denne lastet vi ned og installerte på vårt testnettverk. I skrivende stund er det PR 37 som for Skolelinux er gjeldende, noe som tidligere nevnt har forsinket vår jobb, da vi hele veien har vært avhengige av å teste vår modul opp mot nyeste Pre Release.

6.2 Testing av åpen kildekode

Det er stor forskjell på hvordan utvikling av åpen kildekode og utvikling av tradisjonell programvare utføres.

Tradisjonell utvikling er som regel en lang, tung og lukket prosess som gir lite informasjon til brukerne underveis. I motsetning til åpen kildekode som er en lettere og mer åpen prosess, som hele veien tar imot innspill fra interesserte parter.

I tradisjonell utvikling gir en som regel ikke ut et produkt før det er ferdig testet og fungerer stabilt. Utviklingen av slike produkter går gjerne over flere år. Også versjoner som blir gitt ut senere har samme tidshorisont. I dag skal produkter og tjenester ut på markedet på kortest mulig tid, og i en slik situasjon kan en tradisjonell utviklingsprosess være tung og tidkrevende. Dette fører derfor til at synet på metoder som åpen kildekode for utvikling, har endret seg den siste tiden.

I utvikling av åpen kildekode er hovedtrekkene å slippe ut versjoner av produktet til kunder tidlig i utviklingsfasen, for etter hvert å komme med nye versjoner ofte. Ofte vil si ukentlig eller daglig. Brukeren får samtidig tilgang til hele kildekoden. Noe som igjen gir fordelen av et tett samarbeid mellom bruker og utvikler i utviklingsfasen og brukeren kan komme med tilbakemeldinger om feil og mangler på et tidligere tidspunkt i utviklingen enn han kunne gjort ved en tradisjonell utviklingsmodell.

6.3 Testing av Skolelinux

Skolelinux blir oppdatert ca. hver sjette time på Skolelinux sin CVS. Testing kan da skje umiddelbart når en har lastet ned den nye versjonen. For hvert produkt som blir utviklet blir det gitt ut PR for testing så fort det lar seg gjøre. Feil rapporteres til mailinglista til Skolelinux [10] eller via Bugzilla [11].

Skolelinux har også et samarbeid med Linux Magasinet, der de distribuerer Skolelinux relatert stoff en gang i mellom. Dette for å øke interessen rundt Skolelinux distribusjonen og kapre flere testere, og kanskje også noen som rapporterer feil og forslag til forbedringer.

6.4 Testene vi har gjort

Når hvert element i prosessen var ferdig, testet vi det. Om det ikke fungerte, rettet vi på feilen og testet en gang til. Når gruppa godkjente testen gikk vi videre til neste element.(figur 6.1)

figur 6.1

6.4.1 Test av perl skript

Det har blitt utført to store tester, men vi har også kjørt tester på mindre endringer i programkoden underveis. Vi vil hovedsakelig ta utgangspunkt i de to store testene som ble utført. Arbeidsmetoden bygger på den inkrementelle systemutviklingsmodellen. Dette vil si at vi implementerer/utviklet nye moduler og testet disse underveis. Etter at alle modulene var på plass, kjørte vi en stor test for hele systemet. Den første testen avslørte en del småfeil og en stor feil, og førte til en del endringer i programkoden som følge av disse feilene.

1. test:

Det første som ble gjort var å legge alle de nødvendige scriptene på deres respektive sted. Dette vil si at alle scriptene som skulle kjøres på filtjeneren ble lagt i en egen katalog på filtjeneren (/home/script/), og alle scriptene som skulle kjøres LTSP-tjeneren ble lagt i egen katalog på LTSP-tjeneren(/home/perlscript/).

Scriptene kjøres i den rekkefølgen de står oppført.

Scriptene på LTSP-tjeneren:

- pingscriptTKS.pl

Scriptene på filtjeneren:

- pingscriptFS.pl

- tks_fs.pl

- hosts.pl

- hostgroups.pl

- addroute.pl

- reload.pl

Vi har hele tiden tatt utgangspunkt i det testnettverket av Skolelinux-nettet vi har installert på vår skolelabb. Hovedmålet i starten var å få scriptene til å konfigurere Nagios så automatisk som mulig for vårt nett. Dette vil si at alle maskinene blir automatisk lagt inn med sine respektive tjenester i konfigurasjonsfilene til Nagios. Vårt mål var å få alle maskinene på nettene inn i Nagios sitt web-brukergrensersnitt, inkludert tynnklienter. Vårt test-nett bestod da kun av en LTSP-tjener, en arbeidsstasjon, to tynnklienter, en brannmur, og en filtjener (se Appendiks F1 test 1). Nagios er installert på filtjeneren og kan overvåke alle maskiner som er koblet via en hub/svitsj på 10.0.x.x-nettet. Men når man skal overvåke nett under andre tjenere byr det på visse problemer, siden Nagios ikke får kontaktet disse maskinene selv. M.a.o. den vet ikke den elektroniske veien (routen) til disse maskinene. Dette løste vi med å lage et script som la til disse elektroniske veiene for hver LTSP-tjener som ble detektert av ping-scriptene.

Steg for steg i testen:

- Kjørte pingscriptTKS.pl på LTSP-tjeneren, den genererer en fil med alle tynnklientene LTSP-tjeneren har under seg (hosterTKS.txt)

- Kjørte pingscriptFS.pl på filtjeneren, den genererer en fil med alle maskiner på 10.0.x.x nettet. (hosterFS.txt)

- Kjørte tks_fs.pl for å slå sammen hosterTKS.txt og hosterFS.txt til en fil (hoster.txt)

- Kjørte hosts.pl, den genererer hosts.cfg ut i fra informasjonen i fila hoster.txt

- Kjørte hostgroups.pl, som genererer fila hostgroups.cfg ut i fra informasjonen i hoster.txt

- Kjørte så addroute.pl som legger til elektroniske veier til de forskjellige tynnklientnettene.

- Så til slutt eksekverte vi scriptet reload.pl, som laster de nye .cfg filene inn i Nagios

Konklusjon:

Alle tynnklienter har lik nettverksadresse, uavhengig av hvilken LTSP-tjener de er tilkoblet. Siden vi ikke kan legge til flere elektroniske veier til like nett (192.168.0.0), vil ikke systemet virke med addroute-scriptet, hvis det er mer enn en LTSP-tjener. Et annet problem var også at Nagios ikke liker at det defineres flere maskiner med lik ip-adresse (noe som vil bli tilfelle hvis det er flere LTSP-tjenere på nettet) Dette kom ikke direkte ut av testen, men etter nøye ettertanke og manuell innlegging slik vi så for oss at det skulle være, konkluderte vi og Nagios med at dette ikke var spesielt heldig. M.a.o Nagios nektet å reloade (reload.pl) med de nye konfigurasjonsfilene. Vi så også for oss at services.cfg kunne bli statisk, siden vi omgrupperer maskinene i konfigurasjonsfilene fra tre grupper til kun to (arbeidsstasjoner og LTSP-tjenere).

2. test:

Vi satte oss ned og analyserte muligheter til forbedringer av scriptene. Vi ble nødt til å tenke i helt nye baner med hensyn på overvåking av tynnklienter. Det ble klart for oss at vi trengte en plugin på hver LTSP-tjener som kunne overvåke tynnklientene og sende resultatet til Filtjeneren. Vi begynte da å forske på muligheter for å benytte oss av NRPE (Nagios Remote Plugin Executor) som er en daemon for utføring av sjekker på en remote hosts. Denne benyttes allerede for sjekking av diskplass på LTSP-tjeneren. Den fungerer på den måten at når Nagios spør den om noe, så kjører NRPE den sjekken som ble etterspurt, og sender resultatet tilbake til Nagios. Vi håpet da på å finne en plugin for overvåkning av tynnklienter via NRPE, men dette viste seg å ikke eksistere. Vi kontaktet da Studentgruppen ved NITH som har samme prosjekt som oss, om de hadde funnet en løsning på problemet. De hadde da laget en egen plugin til NRPE som sjekket hvor mange tynnklienter som til en hver tid er skrudd på. Dette var ikke det vi egentlig var ute etter, men vi ble nødt til å gå for denne løsningen da vi ikke hadde tid igjen. Vi begynte så å se på muligheten for å konfigurere denne pluginen (check_dead) ved hjelp av et script. Dette resulterte i noen linjer ekstra i pingscriptTKS.pl scriptet. Dette scriptet vil nå ta seg av konfigurering av NRPE og rapporterer til Filtjeneren hvor mange tynnklienter som er tilkoblet LTSP-tjeneren. Ble også en del endringer i hostgroups_services.pl pga at grupperingssystemet vi først implementerte ikke lenger ville fungere med flere LTSP-tjenere på samme nett. Dette resulterte i kun to grupper i hostgroupes.cfg, en for LTSP-tjenere og en for arbeidsstasjoner. Scriptet hostgroups_services.pl finner selv ut om en maskin er en LTSP-tjener eller en arbeidsstasjon.

Ved utføring av test nummer to, koblet vi opp en ekstra LTSP-tjener med en tynnklient. (Se Appendiks F1 test 2). Dermed fikk vi litt bedre testgrunnlag, siden Skolelinux-nettverket ofte vil bestå av flere LTSP-tjenere.

Scriptene kjøres i den rekkefølgen de står oppført.

Scriptene på LTSP-tjeneren:

- pingscriptTKS.pl

Scriptene på filtjeneren:

- autoconfig_nagios.pl eksekverer følgende scripts:

- pingscriptFS.pl

- tks_fs.pl

- hosts.pl

- hostgroups.pl

Steg for steg i testen:

- Eksekverte pingscriptTKS.pl på begge LTSP-tjenerne. Disse returnerte en fil hver (hosterTKS100.txt og hosterTKS106.txt), som inneholder informasjon om tynnklientene de er tjenere for. Deretter generer de hver sin command.cfg fil som kopieres til den katalogen NRPE leser fra. Denne filen spesifiserer hvilke sjekker NRPE kan foreta på vegene av Nagios. Så kopieres hosterTKSxxx.txt til filserveren.

- Kjørte autoconfig_nagios.pl på filserveren. Dette scriptet eksekverer alle scriptene i katalogen den kjøres i fra (pingscriptFS.pl, tks_fs.pl, hosts.pl og hostgroups.pl).

Konklusjon:

Problemene vi oppdaget under første test, var nå rettet og eliminert. Ut i fra vår kravspesifikasjon og avgrensninger, fungerte alt som planlagt for vårt testnettverk. Problemet vi hadde ang. å sjekke om tynnklienter er i live, var nå løst med check_dead pluginen. Dette scriptet returnerer antall maskiner som er skrudd på og er online på tynnklientnettene. Etter 1. test fikk vi misstanke om at services.cfg kunne bli statisk, og dermed bli utelukket fra perl-scriptet hostgroups_services.pl. Dette viste seg å stemme overens med testen. Vi ga scripetet et nytt navn (hostgroups.pl) og fjernet delen som genererte services.cfg. Dermed er det kun hosts.cfg og hostgroups.cfg som blir generert til konfigurasjonsfilene til Nagios. De andre konfigurasjonsfilene er forhåndskonfigurert og tilpasset Skolelinux-ditribusjonen.

Utbedringer som kan gjøres

Siden overvåkning av store nettverk (med subnett) er et bredt tema og inneholder mange utfordringer som må løses, har ikke vi rukket å gå inn på alle disse. Vi har tatt for oss de mest grunnleggende og nødvendige overvåkningsmodulene, slik at de viktigste elementene blir overvåket i Skolelinux-nettverket. Noen forandringer og tilføyelser i koden, er nødvendig for å forbedre overvåkningssystemet. Maskiner som er på 10.0.3.x nettet må også bli tatt hensyn til i autokonfigurasjonen av Nagios, men på grunn av manglende tid må vi dessverre la dette problemet stå uløst. Et annet problem som står uløst er at alle scriptene må eksekveres som root. Dette er et sikkerhetsspørsmål, siden det kan være uheldig å la en uerfaren bruker eksekvere scriptene som root-bruker.

Hva vi har lært av testing

Vi har jobbet etter den inkrementelle systemutviklingsmodellen, og har erfart at det var den riktige arbeidsmetoden i forhold til implementasjon av vårt prosjekt. Teste små moduler underveis og kjøre en stor test til slutt, gjorde at vi antageligvis sparte en del tid på større problemer som kunne ha oppstått til slutt.

Kapittel 7 - Konklusjon

7.1 Prosessen

Vi startet opp prosjektet med å gjøre oss kjent med Skolelinux i slutten av desember 2002. Fikk deretter startet opp selve planleggingen i begynnelsen av januar, med å etablere arbeidsrutiner, definere grupperegler og avtale møter med veileder.

I januar var vi på første besøk hos Skolelinux, et møte med prosjektleder Knut Yrvin og ekstern veileder Frode Jemtland på Holumskogen barneskole i Nittedal for å se Skolelinux distribusjonen i praksis.

Deretter startet tilegning av kunnskap, samt analysering av eksisterende programvare og kobling av testnettverk. En operasjon som tok litt lenger tid enn forventet (Se Appendiks B1 og B2).

Etter at jobben med testinstallasjonsnettverk og analysen var klar, startet vi opp med installasjon og konfigurering av Nagios. Her måtte vi teste ut og kompilere alt fra bunn, da det viste seg at det ikke fantes stabile debian-pakker av programmet. Da dette var gjort kunne jobben med tilpassning og automatisering begynne. Vi delte gruppen i to slik at noen sto for dokumentasjon, mens andre tok seg av perl programmeringen. Oppdelingen ble endret underveis for at alle skulle få jobbe med alt.

I mai gikk det meste av tiden med på å teste det helhetlige arbeidet opp mot Skolelinux nettet og på rapportskriving.

7.2 Hva har vi oppnådd

Målet med prosjektet var å få til et overvåkningssystem som er riktig konfigurert og fungerer på et Skolelinux sitt nettverks oppsett og samtidig automatiserer dette til å fungere ”rett ut av boksen”. Dette målet er nesten nådd, dvs. at det fungerer på et Skolelinux nettverk, men er ikke fullt automatisert da det gjenstår å lage en debian pakke av all konfigurasjon. Vi har oppnådd følgende kunnskap gjennom prosjekt perioden:

· Fått kunnskap om Linux og om bruk av åpen kildekode.

· Vi har satt oss dypere inn i programmeringsspråket Perl.

· Gruppearbeid som er målrettet.

· Lært å dokumentere arbeidet vi gjør, planlegge arbeid lenger frem i tid, sette fremtidige mål, samt planlegging og gjennomføring av møtevirksomhet og rapportering.

· Satt oss inn i overvåkningssystemer generelt og spesielt Nagios og dets funksjonalitet.

· Brukt CVS for utvikling med flere aktører via web.

Noe vi ikke klarte å oppnå i prosjektet:

· Overholde alle tidsfrister.

· Holde kontinuerlig arbeid.

· Møtetidspunkter.

7.3 Hva har vi lært?

Ved gjennomføring av dette prosjektet er gruppen enige om at vi har lært utrolig mye, ikke bare fagteknisk men også praktisk.

Har fått godt innblikk i hvordan et større prosjekt som Skolelinux er oppbygd og gjennomføres, samtidig som vi sitter igjen med følelsen av å faktisk bidra med noe konstruktivt til et godt formål. Rent teknisk har gruppen tilegnet seg mye kunnskap om hvordan større program applikasjoner innenfor overvåkning fungerer og er strukturert. Samtidig har vi lært oss Perl koding bedre, siden vi bare hadde grunnleggende Perl kunnskaper fra før.

Gruppen sitter også igjen med større kunnskap om Linux, debian, Open Source og ikke minst praktisk drift av nettverk.

Har også gjort en del viktige erfaringer i forbindelse med organisering, planlegging og utførelse da det gjelder gjennomføring av prosjektet.

7.4 Videre arbeid

Slik som overvåkningsmodulen ser ut på nåværende tidspunkt og ettersom vi har benyttet oss av GPL, vil oppgaven hele tiden være åpen og tilgjengelig for videre utvikling eventuelt forbedring av de som måtte ha interesse av dette.

Slik vi ser det gjenstår det en liten del dersom det skal overvåkes et ekstremt stort nettverk, da adresseringen overgår adresserangen 10.0.2.x. Vi er innebefattet med at det her kan fikses mer, men på grunn av tidspress har vi ingen kapasitet til å utføre dette.

Oppdateringen vil bestå av å videreutvikle et perl script som pinger alle maskiner på nettet, og sammenlikner resultatet for så å legge det inn i konfigurasjonsfilene til Nagios. Grunnen til dette er at det er fastsatt at adresser på rangen 10.0.3.z skal kunne brukes dersom det skulle bli for lite plass på nettet, dvs. at vi får flere arbeidsstasjoner og tynnklienttjenere enn 150, noe vi på nåværende tidspunkt ser som lite sannsynlig.

7.5 Evaluering

7.5.1 Gruppas arbeid

Arbeidet og arbeidsfordeling innad i gruppa har fungert utrolig godt, med få unntak. Gruppa startet opp med friskt pågangsmot i januar 2003 og arbeidsmoralen var på topp de første to månedene. Men så var det akkurat som om gruppa fikk en knekk i medio mars og ingen klarte helt å se lyset i enden av tunnelen/ingen progressiv fremgang.

Det ble da satt i gang tidsfrist møter hver uke for å øke motivasjonen, dvs. (de forskjellige arbeidsoppgaver skulle være ferdig på bestemte tidsfrister, uansett). Denne omorganiseringen førte utrolig nok til en heving av arbeidsmoralen i gruppa og vi merket en betraktelig fremgang i arbeidet. Selv om det til tider var mye jobb, skal gruppa ha ros for måten de reiste seg opp igjen på.

Det har også oppstått små problemer utover dette, og da spesielt innenfor programmeringsdelen, men dette er problemer vi klarte å løse med hjelp fra veileder og egne kunnskapstillegninger.

7.5.2 Gruppa om veileder

Erik Hjelmås har stilt opp for oss hele veien med hjelp og innspill da vi har hatt behov for dette. Vi har hatt jevnlig kontakt gjennom prosjektperioden, med ett veileder møte annenhver tirsdag. Samtidig som vi har levert inn foreløpige dokumentasjoner gjennom perioden og fått konstruktive tilbakemeldinger på disse.

7.5.3 Gruppa om oppdragsgiver

Vår eksterne veileder og kontaktperson hos oppdragsgiver Frode Jemtland har fungert som et siste bindeledd til Skolelinux. Men slik Skolelinux prosjektet på landsbasis er oppbygd, har Skolelinux-lista (mailista) vært vår hovedmedhjelper fra Skolelinux`s side gjennom prosjektet. Maillista er en plass der vi har kunnet diskutere og stilt spørsmål om ting vi har lurt på. Kunne kanskje ha brukt lista mer flittig i starten, men allikevel et godt verktøy for oss under utviklingsprosessen. Sjefen for Skolelinux prosjektet Knut Yrvin har også vært til stor hjelp for gruppa og gitt oss utfordrende oppgaver, som å forelese IT-ansvarlige ved en skole i Stavanger i brannmurer (se appendiks A5).

7.5.4 Evaluering av fremdriftsplan

I forhold til fremdriftsplanen er det gjort noen endringer. På noen punkter hadde vi satt av for liten tid.

Oppsettet av nettverket med Skolelinux tok lenger tid enn vi hadde planlagt. Dette fordi det oppstod hardware feil med systemet, som eks. feil drivere til nettverks kort, defekte nettverkskort og defekte skjermkort. Dette medførte en del skruing og testing, og en forsinkelse på ca. en uke.

Også det å sette seg inn i Skolelinux og annen relevant teori, ble mer tidkrevende enn vi hadde trodd. Skolelinux har sin egen struktur på systemet, noe som gjør systemet litt annerledes enn et vanlige Linux nettverk. Hovedessensen i Skolelinux er å kunne kjøre diskløse maskiner, for å spare penger. Det betyr at all informasjon går over nettverket, noe som tok litt tid å skjønne oppbygningen av. Vi brukte også litt tid på å sette oss inn i de programmer som er brukt i Skolelinux.

Tilegning av Perl kunnskaper gikk etter tidsplanen, samtidig som vi også tilegnet oss kunnskaper underveis i programmeringen.

Dette førte til at vi kom litt sent i gang med programmeringen og implementering av kode i Skolelinux. Allikevel klarte vi å holde oss innenfor tidsfristen på programmeringsdelen, siden vi jobbet hardt til tider for å få til dette.

Testingen av scriptene forgikk underveis i programmeringen, siden vi har brukt en inkrementell utviklingsmodell. Etter at hver del av scriptene var klare, testet vi det og kunne rette feil med en gang dersom det var noen.

En gang i uken hadde gruppen møter for å avklare ukens målsettinger, og hva som hver enkelt skulle ta seg av. I tillegg hadde vi møte med veileder annen hver uke for å få tilbakemeldinger på det vi hadde gjort, og at veileder kom med innspill på hva vi burde gjøre i neste arbeidsperiode og hva som burde være ferdig til gitte tidspunkt.

Siste dagen i hver måned hadde vi et statusmøte for å diskutere fremgangen i prosjektet. Samtidig som vi lagde en oversikt over hva vi hadde gjort forrige måned og hva som burde gjøres neste måned (Se Appendiks G2).

Da det gjelder møtetidspunkter, fulgte vi fremdriftsplanen som oppsatt, men det ble som nevnt noen endringer på de andre punktene. Dette fordi innledningsfasen gikk seinere enn forventet (Se Appendiks B1 og B2).

Vi burde nok vært flinkere til å ta notater av det vi gjorde i begynnelsen. Dette førte til at mye gikk i glemmeboken. Men etter at vi ble oppmerksom på dette, startet gruppen en iherdig innsats mod loggføring.

Milepælene vi hadde satt oss ble overholdt. I prosjektet våres hadde vi også ”deadlines” for når forskjellige ting skulle være ferdig.

7.5.5 Timelister

Uke	Tarjei	Vidar	Sven Are	Ragnar	Timer pr. uke totalt:
2	12	13	12	11	48
3	15	13	14	15	57
4	17	14	17	20	68
Ulsrud 5	15	25	20	23	83
6	17	16	16	17	66
7	16	16	15	15	62
Bryne 8	18	18	13	18	67
9	14	13	15	13	55
10	17	18	17	17	69
11	15	16	18	19	68
12	20	16	19	18	73
13	18	17	22	20	77
14	16	15	17	18	66
15	31	32	25	24	112
Påske 16	8	3	4	2	17
Ulsrud 17	48	46	37	46	177
18	55	60	43	56	214
19	52	52	54	52	210
20	20	20	20	20	80
Totalt timer	424	423	398	424	1669

7.5.6 Logg bok

En kort logg på hva vi har gjort, mer spesifikt ligger i appendiks G1 og G2 (ukereferater og statusrapporter).

Uke 2:

Denne uka har vi jobbet med det grunnleggende i forprosjekt rapporten.

Uke 3:

Jobbet med forprosjekt rapport som skulle leveres den 21.01.03. Mandag den 13.01.03 var vi på Holumskogen skole hvor vi fikk en omvisning på hvordan Skolelinux fungerer. Det var første møte med oppdragsgiveren Knut Yrvin og Frode Jemtland.

Uke 4:

Dagsordenen denne uka var å ferdiggjøre forprosjektrapporten til innlevering.

Uke 5:

Denne uka fikk vi på plass maskinvaren, og begynte å sette opp nettverket slik Skolelinux sin struktur er. Det førte til en del problemer da vi ville ha en egen struktur, mens Skolelinux oppsettet var en annen struktur. Begynte å skrive kravspesifikasjon.

Uke 6:

Fortsatte på kravspesifikasjonen, hvor vi prøvde å følge malen som er gitt av HiG. Fylte inn på de punkter hvor vi var sikre på hva som skulle være med. To på gruppa reiste på utviklertreff til Ulsrud vgs. i Oslo.

Fortsetter med å sette opp vårt testnettverk, men vi har fortsatt noen problemer med å få tynnklientene til å fungere. Vi manglet drivere for å få opp skjermbilde på tynnklientene. Det ble en del leting etter informasjon om hvordan problemet kunne løses. Oppsett av nettverk, fortsatt noen problemer.

Uke 7:

Kravspesifikasjon begynner å ta form, og de fleste punktene er fylt ut. Resterende punkter må fylles ut når vi får satt opp systemet i drift og vi kan teste det. Nettverks oppkobling.

Uke 8:

Endelig klarte vi å få opp våres testnettverk etter mye problemer i starten. Skrev kravspesifikasjon.

Reiste på utviklertreff til Time kommune på Jæren.

Uke 9:

Vi satte oss inn i Skolelinux distribusjonen, for å få et innblikk i hvilke programmer og tjenester en kunne bruke for å sette opp et ordentlig Skolelinux nettverk. Startet med analysering av eksisterende programvare.

Uke 10:

Vi analyserte mulige overvåkningsprogrammer vi kunne bruke til overvåkning på et Skolelinux nettverk. Under denne analysen kontaktet vi ulike personer med erfaringer fra drift og overvåkning. Vi kommuniserte med Jonny Birkelund og Sverre Stoltenberg fra Opera over e-post og et møte vi hadde med Jonny her på HiG. I tillegg har vi vært i kontakt med Tor Erik Neuberg som er aktivt med i Skolelinux prosjektet. Testet ut noen av de aktuelle programmene som vi tok med i analysen.

Uke 11:

Skrev et dokument om analyse av de programmene vi har testet. Samtidig bestemte vi oss for Nagios som overvåkningsverktøy. Begynte å studere manualen til Nagios for å få et innblikk i hvordan vi skulle gå frem. Begynte å kompilere Nagios fra tar.gz filer.

Uke 12:

Fylte ut flere punkter i kravspesifikasjonen. Fortsatte å lese om Nagios, for å finne ut alle de muligheter programmet har. Veilederen vår ville ha foreløpig dokumentasjon av oss, så vi leverte det vi hadde skrevet. Hadde installert Nagios, men fikk noen feil på systemet. Det kom en ny Skolelinux distribusjon (nr.37), så vi reinstallerte hele testnettverket våres, noe som tok lenger tid enn planlagt.

Uke 13:

Installerte Nagios på nytt med de erfaringer vi hadde fra forrige installasjon. I tillegg installerte vi Nagios plugins, noe som er nødvendig for å utføre sjekker på andre maskiner. Skrev deler av kapittel 1 og 2 på rapporten, så det kun gjenstår finpuss der tilslutt.

Uke 14:

Jobbet en del med prosjektet i sikkerhet denne uken. Dette tok mye av tiden, så vi fikk minimal tid til hovedprosjektet. Prøvde å finne ut hvordan utdelingen av ip til tynnklienter ordnes. Installerte NRPE daemon på tynnklienttjener (kompilering), for å få utført overvåkning av diskplass o.a. på denne maskinen. Skrev script for å starte daemon automatisk under oppstart av maskinen. Begynte å tenke på muligheten til å lage et perl script til konfigurasjon av Nagios.

Uke 15:

Fikk beskjed av Erik Hjelmås om å gå tilbake til stabil tar.gz versjon av Nagios.

Begynte å skrive på prosjektrapporten. Studerte NRPE daemonen som skulle kjøres på tynnklienttjeneren. Det ble litt problemer med å få den til å starte som egen daemon. Noen endringer ble gjort i nrpe.cfg fila, slik at den passet til vårt system. Begynte å lage perlscript for generering av hosts.pl og hostgroups.pl. Klargjorde all dokumentasjon, slik at vi kan levere det til Erik før påske, slik at han kunne gå igjennom og si hva som var bra og hva som manglet i rapporten. Leverte dokumentasjonen fredag før påske.

Uke 16:

Skrev litt videre på rapporten. Utbedret hosts.pl og pingscriptFS.pl. Laget nytt script, tks_fs.pl. Tok en velfortjent påskeferie etter mye hard jobbing før påske.

Uke 17:

Modifiserte flere av scriptene. La inn muligheten for flere tynnklienttjenere inn i pingscriptTKS.pl og tks_fs.pl. Gjorde om hostgroups.pl til å gruppere tynnklienter under hver sin tynnklienttjener, noe som viste seg å ikke fungere. Begynte å dokumentere scriptene. Var på utviklersamling på Ulsrud skole lørdagen denne uka, hvor vi fikk avklart noen viktige spørsmål angående Skolelinux oppsett og hvordan de ønsket programmet. Det ble problemer med å overvåke tynnklienter hvis flere tynnklienttjenere ble overvåket samtidig. Rapportskriving er også en viktig del av hverdagen denne uka. Ble skrevet på kapitler om installasjon, testing og analyse.

Uke 18:

Problemet med overvåkning av tynnklienter er løst. Fikk en plugin av en gruppe i Oslo som jobber med samme oppgaven som oss. Det ble gjort endringer på flere av scriptene for å passe til den nye pluginen. Så på problemet med eierskap av filer, og på grunn av tidsnød har vi ikke tid til å se på mulig løsning av dette annet enn å kjøre alt som root. Gjorde ellers noen små justeringer i de fleste scriptene og fikset varsling via mail. Fortsatte skrivingen av rapport, bl.a. på konklusjon, rettelser på kravspesifikasjonen og vedlegg som skulle være med i rapporten.

Uke 19:

Testet scriptene på systemet. Måtte gjøre små endringer igjen. Skrev manual på hvordan bruke scriptene for en nybegynner. Rapporten begynner å ta form, slik at vi kunne sette sammen mange av delene i rapporten. Nå begynte finpussingen på rapporten, slik at den skulle bli optimal.

Uke 20:

Denne uka har vi finpusset på rapporten før vi sender den til trykking. Utkast til reklameplakat ble også laget.

7.5.7 Oppsummering

Sett prosjektet i sin helhet er vi veldig fornøyd med jobben vi har gjort. Vi har totalt sett klart å utføre de mål vi hadde satt oss i denne tiden. Det er selvfølgelig ting vi kunne ha gjort annerledes men enkelte beslutninger og avgrensninger måtte bare tas. Vanskelighetsgraden har også til tider vært høy, men det var noe vi som helhet var innstilt på ved prosjektstart så dette gikk greit.

Kapittel 8 Referanser

8.1 Litteraturliste

Bøker:

Software Engineering, Sixth Edition

Ian Sommerville, Addison Wesley

ISBN: 0-2013-9815-X

Mastering Perl 5

Eric C. Herrmann, Sybex

ISBN 0-7821-2200-0

Perl 5 for dummies

Paul Hoffman, IDG Books Worldwide

ISBN 0-7645-0044-9

Artikler og kompendier

Innføring i Perl

Kompendiet utlevert ved HiG høsten 2002

[13] Linux Magasinet januar 2003

Internettsider:

[1] Nagios

http://www.nagios.org

[2] Big brother

http://www.bb4.com

[3] The Angel Network Monitoring

http://www.paganini.net/angel/

[4] Snort

http://www.snort.org/

[5] Spong

http://spong.sourceforge.net/

[6] Mon

http://www.kernel.org/software/mon/

[7] LTSP Terminal Project

http://www.ltsp.org

[8] Analysis Console for Intrusion Databases

http://acidlab.sourceforge.net

[9] HiG, Høgskolen i Gjøvik

http://www.hig.no

[10] Mail liste for Skolelinux

linuxiskolen@skolelinux.no

[11] Bugzilla

bugzilla@skolelinux.no

[12] GNU GPL

http://www.gnu.org/

[14] Skolelinux

http://www.skolelinux.no/

Kapittel 9 - Appendiks

Innholdsfortegnesle for vedlegg

Appendiks A1. 78

Referat av tur til EDB TEAMCO 17. mars 2003. 78

Appendiks A2. 79

KJAPP INTRO I BRUK AV CVS. 79

Appendiks A3. 81

GNU GENERAL PUBLIC LICENSE. 81

Appendiks A4. 87

INKREMENTELL UTVIKLINGSMODELL.. 87

Appendiks A5. 90

Skolelinux-samling på Bryne i Time-kommune helga. 90

21-23 feb. 2003. 90

Appendiks B1. 92

Gannt skjema før prosjektstart. 92

Appendiks B2. 93

Gannt skjema etter prosjektslutt. 93

Appendiks D1. 94

Installering av Nagios med tar.gz filer. 94

Installasjon av NRPE plugin på filtjener. 107

Installasjon av NRPE-plugin med tar.gz-filer på LTSP-tjener. 109

Installasjon av NRPE plugin med deb-pakke på LTSP-tjener. 111

Appendiks D2. 112

Installation.. 112

Installing Nagios with tar.gz files. 113

Appendiks D3. 122

Installation of the NRPE-plugin (deb-package) on each LTSP-server. 122

Appendiks D4. 123

Installasjon av NRPE-plugin med tar.gz-filer på LTSP-tjener. 123

Appendiks E1. 125

Howto configure Nagios. 125

Appendix E2. 128

Howto configure Nagios to notify errors by e-mail 128

Appendix E3. 134

pingscriptTKS.pl: 134

hostgroups.pl 137

pingscriptFS.pl: 140

tks_fs.pl: 141

hosts.pl 142

autoconfig_nagios.pl 146

Appendiks E4. 147

User manual Nagios. 147

Appendix E5. 165

Dynamiske cfg filer. 165

command.cfg: (generated by pingscriptTKS.pl) 165

hostgroups.cfg: (generated by hostgroups.pl) 165

hosts.cfg (generated by hosts.pl) 166

Appendiks E6. 168

Statiske cfg filer. 168

cgi.cfg. 168

checkcommands.cfg. 170

contactgroups.cfg. 172

contacts.cfg. 173

nagios.cfg. 174

services.cfg. 177

Appendiks F1. 181

Appendiks G1. 182

UKEREFERATER.. 182

Appendiks G2. 195

Statusrapporter. 195

Appendiks A1

Referat av tur til EDB TEAMCO 17. mars 2003

Tirsdag 17. mars ble gruppa invitert på omvisning hos EDB TEAMCO på Skøyen. Dette er et firma som driver drift i STOR skala. De har nå ca 90 % av driftsansvaret til norske banker, i tillegg til Statoil, norsk skog og mange flere.

De har for det meste driftsansvaret for stormaskinene til disse bedriftene, og har ca 10 haller på størrelse med fotballbaner med utstyr.

Vi hadde avtalt møte med Tor Erik Neuberg, som er ansatt hos EDB TEAMCO som drifter.

Han har Linux som hobby, og har derfor latt seg friste av Skolelinux prosjektet. Vi kom i kontakt med han på den første utviklersamlingen i Oslo, og han var villig til å hjelpe til viss vi trengte hjelp.

Målet med turen var å få noen tips angående overvåkningssystemet vi skal tilpasse til Skolelinux-prosjektet. Dessverre strakte ikke tiden til, så det ble ikke så mye utbytte av turen med tanke på prosjektet, men det var særdeles interessant med tanke på at vi snart er driftere selv.

Det vi kom frem til var at vi burde begrense systemet mest mulig, og få det vi lager til å fungere. De verktøyene vi benytter er “open source”, noe som gjør at det er lett for andre å gjøre endringer og utvide systemet senere. Han hadde også noen viktige forslag mht DHCP problemet våres.

Da vi er avhengige av å ha en automatisert konfigurering av maskiner når de blir koblet til, så er det også viktig å finne en sikker løsning som ser forskjell på om en maskin er koblet fra eller bare er skrudd av.

Appendiks A2

KJAPP INTRO I BRUK AV CVS

Hva må du skaffe deg før du kan sette i gang:

- Eget bruker navn

- Eget passord

For å starte tilgang til CVS:

Skriv følgende kommandoer i konsoll vinduet:

// cvs-rsh=ssh <tast_enter>

// export cvs-rsh <tast_enter>

Deretter er det klart til å kjørre en check-out (kommando ”co”)

Det er her viktig at du vet hvilken katalog eller fil du er interessert i å laste ned, slik at du slipper å laste ned alt som ligger på serveren, gå derfor inn på hjemmesiden for utviklere på [14] for og finne den bestemte katalogen. På Skolelinux sidene finner du dette under ”skrivetilgang til CVS” og deretter ”viewcvs”

Nå er du klar for å starte nedlastning /co:

Følgende kommando for å kjøre Check-Out/nedlasting.

(kommandoer merket ” ” må du fylle ut etter eget oppsett)

//cvs –d :ext:”brukernavn”@cvs.skolelinux.no:/var/lib/cvs co skolelinux/www/info/”osv. avhengig av hvilken katalog du skal laste ned”

Du må nå taste inn ditt unike passord

Du får så lastet ned alle katalogene til den katalogen du selv står i.

Gjøre endringer:

Du kan nå gå hele stien gjennom /skolelinux/www/info/ ”osv.” for å komme til den respektive fil du vil endre.

La oss si dette er en .txt fil.

Kjør så kommandoen

// vi ”filnavn.txt”;

Du får deretter vist filas innhold og det er her viktig at du ikke gjør andre endringer enn det du absolutt må, for eksempel ikke rett på linjeskift eller lignende i andre linjer, da du personlig vil stå som ansvarlig for de linjer som er blitt editert av deg.

Etter at endringen er gjort:

Trykk ”Esc”, kolon og skriv ”wq”for å lagre endringer. Fila ligger nå kun redigert på din maskin og ikke på CVS serveren.

Legg til Endringer mot CVS ved bruk av ADD:

Stå nå i katalogen hvor fila ligger og skriv følgende kommando:

// CVS add ”filnavn.txt”

Du må igjen taste inn ditt unike passord.

Nå er endringene ”addet” opp mot cvs, det gjenstår nå kun å kjøre en comitt slik at fila blir sendt tilbake til katalogen du tidligere gjorde endringer i fra.

COMITT (sender fila endelig opp til server hos Skolelinux):

Kjør så kommando fra samme ståsted som ved add:

1. // CVS comitt ”filnavn.txt”;

ELLER

2. //CVS comitt ”filnavn.txt”-m ”(”kommentar”)”;

Du må også her taste inn ditt unike passord.

Dersom du bruker metode1, vil du komme inn i et shell der du må legge til en kort kommentar på hva du har gjort:

Gjør som følger:

Tast (insert), legg til din korte kommenter, tast Esc og kolon, skriv deretter ”wq”for å lagre.

Dersom du bruker metode2, må du bytte ut (”kommentar”), med din egen korte kommentar til hva du har gjort for slags endringer.

Alle endringer vil komme på mail lista til cvs.

Endringen er nå gjort og du kan gå inn på www.skolelinux.no [14] etter noen få minutter å se at dine endringer nå ligger på CVS serveren.

Appendiks A3

GNU GENERAL PUBLIC LICENSE

  Version 2, June 1991
 
 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
 
  Preamble
 
 The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
 
 When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
 
 To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
 
 For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
 
 We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
 
 Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
 
 Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary.  To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
 
 The precise terms and conditions for copying, distribution and modification follow.
 
 
  GNU GENERAL PUBLIC LICENSE
 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
 
 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
 
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
 
 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
 
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
 
 2. You may modify your copy or copies of the Program or any portion of 
it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
 
 a) You must cause the modified files to carry prominent notices 
 stating that you changed the files and the date of any change.
 
 b) You must cause any work that you distribute or publish, that in
 whole or in part contains or is derived from the Program or any
 part thereof, to be licensed as a whole at no charge to all third
 parties under the terms of this License.
 
 c) If the modified program normally reads commands interactively
 when run, you must cause it, when started running for such
 interactive use in the most ordinary way, to print or display an
 announcement including an appropriate copyright notice and a
 notice that there is no warranty (or else, saying that you provide
 a warranty) and that users may redistribute the program under
 these conditions, and telling the user how to view a copy of this
 License. (Exception: if the Program itself is interactive but
 does not normally print such an announcement, your work based on
 the Program is not required to print an announcement.)
 
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
 
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
 
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
 
 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
 
 a) Accompany it with the complete corresponding machine-readable
 source code, which must be distributed under the terms of Sections
 1 and 2 above on a medium customarily used for software interchange; or,
 
 b) Accompany it with a written offer, valid for at least three
 years, to give any third party, for a charge no more than your
 cost of physically performing source distribution, a complete
 machine-readable copy of the corresponding source code, to be
 distributed under the terms of Sections 1 and 2 above on a medium
 customarily used for software interchange; or,
 
 c) Accompany it with the information you received as to the offer
 to distribute corresponding source code. (This alternative is
 allowed only for noncommercial distribution and only if you
 received the program in object code or executable form with such
 an offer, in accord with Subsection b above.)
 
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
 
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
 
 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will utomatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
 
 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
 
 6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
 
 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
 
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
 
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
 
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
 
 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
 
 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
 
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
 
 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
 
  NO WARRANTY
 
 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
 
 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
 
  END OF TERMS AND CONDITIONS
 
  How to Apply These Terms to Your New Programs
 
 If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
 
 To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
 
 <one line to give the program's name and a brief idea of what it does.>
 Copyright (C) <year> <name of author>
 
 This program is free software; you can redistribute it and/or modify 
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version.
 
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU General Public License for more details.
 
 
 
You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 
 
Also add information on how to contact you by electronic and paper mail.
 
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
 
 Gnomovision version 69, Copyright (C) year name of author
 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
 This is free software, and you are welcome to redistribute it
 under certain conditions; type `show c' for details.
 
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
 
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
 
 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
 `Gnomovision' (which makes passes at compilers) written by James Hacker.
 
 <signature of Ty Coon>, 1 April 1989
 Ty Coon, President of Vice
 
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

Referanse [12].

Appendiks A4

Inkrementell utviklingsmodell

Gruppa har benytter seg av inkrementell utviklings modell fordi den ser ut til å passe best for vårt opplegg under prosjektet. Har delt prosjektet inn i 8 inkrementer.

1. Inkrement: Sette oss inn i Skolelinux distribusjonen.

2. Inkrement: Etablering utviklingsmiljø: Hjemmeside o.l.

3. Inkrement: Analysere eksisterende programvare

4. Inkrement: Konfigurere og installere manuelt

5. Inkrement: Testing manuelt

6. Inkrement: Automatisering og scripting

7. Inkrement: Testing av automatisering

8. Inkrement: Sluttføre rapport

Hva er inkrementell utvikling?

Inkrementell utvikling er en måte å strukturere et prosjektarbeid på. Hvert inkrement er uavhengig av hverandre, men inkrementene er veldefinerte, testbare og leverbare i forhold til et ferdig produkt. De forskjellige inkrementene kan være stegvise, parallelle eller serielle. Hvert inkrement legger til ny funksjonalitet i systemet og danner ofte et grunnlag for nye inkrementer.

Hva er egentlig inkrementell utviklingsmodell?

Som vist i figuren over går inkrementell utviklingsmodell i korte trekk ut på å hele tiden ferdigstille og teste hver enkelt modul.

Fordeler med inkrementell utvikling er at oppdragsgiver dvs. Skolelinux til enhver tid kan ha nytte av utviklingen vår. Skolelinux vil også kunne bruke tidlige trinn som prototyper og vi senker risikoen for at prosjektet munner ut i en total fiasko.

Problemer med inkrementell utvikling er at hvert trinn ikke bør være større enn 20 000 linjer kode, og hver enkelt modul må inneholde funksjonalitet og det kan da bli vanskelig å dele inn hver enkelt modul.  

Noen av fordelene med inkrementell utviklingsmodell er:

· Krav og prioriteringer kan endres underveis

· Passer dermed når det er vanskelig å lage en komplett kravspesifikasjon

· Tidlig implementasjon av deler av systemet

1. Gir økt forståelse

2. Reduserer risiko, ved tidlig å prøve ut arkitektur og tekniske valg

3. Gjør det mulig å få tilbakemelding på om man bygger det riktige produktet.

Hvorfor inkrementell utvikling?

Ved å benytte inkrementell utviklingsmodell slipper man lange start- og avslutningsfaser. I et slikt prosjekt får man bedre tid til analyse, implementasjon og testing. Hver enkelt del av prosjektet blir mindre, men mer håndterlig og oversiktlig. I tillegg til dette får man rask tilbakemelding på kvalitet, og tidlig testing av programmene som blir utviklet.

Prosjektmedlemmene identifiserer seg lettere med oppgaven, og blir mer inspirerte ved en slik utviklingsform. Produktet kan vises for kunde på et tidlig stadium i prosessen. Kompetanse vil bygge seg opp for hvert inkrement, og selv om prosjektet avsluttes vil alle ha opparbeidet seg verdifull kompetanse å bygge videre på.

Appendiks A5

Skolelinux-samling på Bryne i Time-kommune helga

21-23 feb. 2003

Gruppa ble invitert til Time kommune på Jæren til en kombinert utviklersamling og kurshelg for lærere og IT-ansatte i kommunen. På samlingen var det ca 20 utviklere, 5-10 oversettere, 4 pedagogisk tilretteleggere og ellers 35 lærere og It-ansatte fra Time.

Fredag:(Reiste fra Gjøvik med buss til Gardermoen og Fly til Sola.)

Da vi ankom Bryne-barneskole ble vi møtt av prosjektlederen for Skolelinux Knut Yrvin, som satte oss i sving med å koble opp nettverket for utviklerne. Hovedsakelig gikk dette ut på å bære maskiner på plass og koble dem opp mot en svitsj som igjen var koblet til tynnklienttjeneren. Da tynnklientene var ferdig oppsatt med pxe, som gjør slik at nettverkskortet booter automatisk mot tynnklient serveren, slapp vi å lage boot disketter for alle de tynne klientene.

Dette viste seg å bli vanskeligere enn antatt siden det var mangel på lange nettverkskabler. Men etter litt tenking og omorganisering fikk vi løst problemene og nettverket virket som planlagt.

Det skulle settes opp to rom med tynnklientnettverk, og to rom som skulle brukes som undervisningslokaler for installasjon, printing, brukeradministrering og brannmur. Vi hadde fått i oppgave å holde kurs om brannmurer, så vi begynte allerede fredagskvelden å forberede oss til dette foredraget.

Vi brukte også litt av tiden til å bli kjent med forskjellige personer som er involvert i skolelinux-prosjektet.

Lørdag:

Hørte på foredrag med it-leder/lærer fra Birkenlund Barneskole i Arendal, Tom Stiansen. Der han la frem sine positive og negative erfaringer ved innføring av Skolelinux på Birkenlund.

Fortsatte deretter å forberede foredraget vi skulle holde på søndag. Tok litt tid, for å få ordnet en del praktiske gjøremål, da vi ikke hadde tilgang til Ltsp server før alle lærerne hadde tatt kvelden.

Ble også diverse tull seint om kvelden, da serverene var nede i ny og ned (Mista mye data, fordi vi ikke lagret hvert minutt).

Søndag:

Skrev ferdig og skrev ut en manual for å sette opp en floppy-firewall. Dette skulle være så enkelt som over hodet mulig(kokebok oppskrift). Vi begynte foredraget med en kjapp intro om følgende punkter:

Hva er en brannmur?

Hvilke typer brannmur har vi?

Hvorfor bør vi ha en brannmur?

Hva beskytter en brannmur imot?

Hva beskytter ikke en brannmur imot?

Hvor gjør en brannmur minst skade, minst nytte?

Trygghetsfølelsen

Etter å ha kjørt introen satte vi i gang med den praktiske delen, der grupper på 3 og 3 skulle laste ned, konfigurere og teste sin egen firewall. Vi gikk rundt og hjalp til der det var behov. Dette gikk over all forventning, med unntak av de som ikke husket å lese oppskriften (manualen) punkt for punkt.

Drev på i 1-2 timer. Deretter var det fly til Gardermoen og buss tilbake til Gjøvik

Konklusjon:

Dette var en interessant og lærerik samling. Og var også en veldig god erfaring å ta med seg videre for oss som gruppe og personlig med tanke på seinere arbeidsliv. Da vi selv måtte forberede og holde foredrag for 15 ukjente It-ansvarlige.( Man vokser på slikt...)

Appendiks B1

Gannt skjema før prosjektstart

Appendiks B2

Gannt skjema etter prosjektslutt

Appendiks D1

Installering av Nagios med tar.gz filer

Følgende pakker blir lastet ned fra [15] og installert :

Nagios-1.0

Nagios-plugins-1.3.0

NRPE-1.8

libpng-dev (apt-get install libpng-dev)

For å få med alle bibliotekene som Nagios trenger måtte vi legge til følgende i filen /etc/ld.so.conf:

/usr/lib

Deretter kjørte vi ldconfig for at det også pekte mot biblioteket /usr/lib

Deretter pakket vi ut Nagios versjon 1.0.

tar xvzf nagios-1.0.tar.gz

Lagde katalogen /usr/local/nagios

mkdir /usr/local/nagios

Konfigurerte nagios:

nagios@tjener:~/nagios-1.0$ ./configure

--prefix=/usr/local/nagios --with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/ --with-nagios-user=nagios

--with-nagios-grp=nagios

creating cache ./config.cache

checking for a BSD compatible install... /usr/bin/install -c

checking for gcc... gcc

checking whether the C compiler (gcc ) works... yes

checking whether the C compiler (gcc ) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking whether make sets ${MAKE}... yes

checking for strip... /usr/bin/strip

checking how to run the C preprocessor... gcc -E

checking for ANSI C header files... yes

checking whether time.h and sys/time.h may both be included... yes

checking for sys/wait.h that is POSIX.1 compatible... yes

checking for ctype.h... yes

checking for dirent.h... yes

checking for errno.h... yes

checking for fcntl.h... yes

checking for getopt.h... yes

checking for grp.h... yes

checking for limits.h... yes

checking for math.h... yes

checking for pwd.h... yes

checking for signal.h... yes

checking for strings.h... yes

checking for string.h... yes

checking for syslog.h... yes

checking for unistd.h... yes

checking for uio.h... no

checking for sys/types.h... yes

checking for sys/time.h... yes

checking for sys/resource.h... yes

checking for sys/wait.h... (cached) yes

checking for sys/stat.h... yes

checking for sys/ipc.h... yes

checking for sys/msg.h... yes

checking for working const... yes

checking whether struct tm is in sys/time.h or time.h... time.h

checking for tm_zone in struct tm... yes

checking for mode_t... yes

checking for pid_t... yes

checking for size_t... yes

checking return type of signal handlers... void

checking for uid_t in sys/types.h... yes

checking type of array argument to getgroups... gid_t

checking for strdup... yes

checking for strstr... yes

checking for strtoul... yes

checking for initgroups... yes

checking for type of socket size... size_t

checking for mail... /usr/bin/mail

Init script directory: /etc/init.d

We'll use default routines (in xdata/xsddefault.*) for status data I/O...

We'll use default routines (in xdata/xcddefault.*) for comment data I/O...

We'll use template-based routines (in xdata/xedtemplate.*) for extended data I/O...

We'll use default routines (in xdata/xrddefault.*) for retention data I/O...

We'll use template-based routines (in xdata/xodtemplate.*) for object data I/O...

We'll use default routines (in xdata/xpddefault.*) for performance data I/O...

We'll use default routines (in xdata/xdddefault.*) for scheduled downtime data I/O...

checking for gdImagePng in -lgd (order 1)... no

checking for gdImagePng in -lgd (order 2)... no

checking for gdImagePng in -lgd (order 3)... no

*** GD, PNG, and/or JPEG libraries could not be located... *********

Boutell's GD library is required to compile the statusmap, trends

and histogram CGIs. Get it from http://www.boutell.com/gd/, compile

it, and use the --with-gd-lib and --with-gd-inc arguments to specify

the locations of the GD library and include files.

NOTE: In addition to the gd-devel library, you'll also

need to make sure you have the png-devel and jpeg-devel libraries installed on your system.

NOTE: After you install the necessary libraries on your

system:

1. Make sure /etc/ld.so.conf has an entry for

the directory in which the GD, PNG, and JPEG libraries are installed.

2. Run 'ldconfig' to update the run-time linker

options.

3. Run 'make clean' in the Nagios distribution

to clean out any old references to your

previous compile.

4. Rerun the configure script.

NOTE: If you can't get the configure script to recognize the GD libs on your system, get over it and move on to other things. The CGIs that use the GD libs are just a small part of the entire Nagios package. Get everything else working first and then revisit the problem. Make sure to check the nagios-users mailing list archives for possible solutions to GD library problems when you resume your troubleshooting.

*********************************************************

checking for traceroute... /usr/bin/traceroute

checking for snprintf... yes

checking for type va_list... yes

checking for perl... /usr/bin/perl

updating cache ./config.cache

creating ./config.status

creating Makefile

creating subst

creating pkginfo

creating base/Makefile

creating common/Makefile

creating contrib/Makefile

creating cgi/Makefile

creating html/Makefile

creating xdata/Makefile

creating daemon-init

creating html/index.html

creating html/side.html

creating common/config.h

creating common/snprintf.h

creating base/nagios.h

creating cgi/cgiutils.h

Creating sample config files in sample-config/ ...

*** Configuration summary for nagios 1.0 11-24-2002 ***:

General Options:

-------------------------

Nagios executable: nagios

Nagios user/group: nagios,nagios

Command user/group: nagios,nagios

Embedded Perl: no

Install ${prefix}: /usr/local/nagios

Lock file: ${prefix}/var/nagios.lock

Init directory: /etc/init.d

Web Interface Options:

------------------------

HTML URL: http://localhost/nagios/

CGI URL: http://localhost/nagios/cgi-bin/

Traceroute (used by WAP): /usr/bin/traceroute

External Data Routines:

------------------------

Status data: Default (text file)

Object data: Template-based (text file)

Comment data: Default (text file)

Downtime data: Default (text file)

Retention data: Default (text file)

Peformance data: Default (external commands)

Extended info data: Template-based (text file)

Review the options above for accuracy. If they look okay, type 'make all' to compile the main program and CGIs.

La til apt-kilder i sources.list (fjernet hash foran de som var der fra før). Libpng-dev ligger ikke på skolelinux cden, så den måtte installeres fra debian distribusjonen. Pga. av manglende gdlib måtte vi legge til libpng-dev, den inneholder header filer og c filer.

tjener:/home/nagios/nagios-1.0# apt-get update

tjener:/home/nagios/nagios-1.0# apt-get install libpng-dev

Reading Package Lists... Done

Building Dependency Tree... Done

The following extra packages will be installed:

zlib1g-dev

The following NEW packages will be installed:

libpng-dev zlib1g-dev

0 packages upgraded, 2 newly installed, 0 to remove and 7 not upgraded.

Need to get 451kB of archives. After unpacking 975kB will be used.

Do you want to continue? [Y/n] y

Get:1 http://security.debian.org stable/updates/main libpng-dev 1.2.1-1.1.woody.3 [233kB]

Get:2 ftp://ftp.skolelinux.no woody/main zlib1g-dev 1:1.1.4-1 [218kB]

Fetched 451kB in 0s (506kB/s)

Reading changelogs... Done

Selecting previously deselected package zlib1g-dev.

(Reading database ... 74711 files and directories currently installed.)

Unpacking zlib1g-dev (from .../zlib1g-dev_1%3a1.1.4-1_i386.deb) ...

Selecting previously deselected package libpng-dev.

Unpacking libpng-dev (from .../libpng-dev_1.2.1-1.1.woody.3_i386.deb) ...

Setting up zlib1g-dev (1.1.4-1) ...

Setting up libpng-dev (1.2.1-1.1.woody.3) ...

Nå som vi fikk installert libpng-dev kunne vi kjøre konfigureringen av nagios på nytt. Men først måtte vi rydde i gammel konfigurasjon med denne kommandoen:

nagios@tjener:~/nagios-1.0$ make clean

nagios@tjener:~/nagios-1.0$ ./configure

--prefix=/usr/local/nagios --with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/ --with-nagios-user=nagios

--with-nagios-grp=nagios --with-gd-lib=/usr/lib

--with-gd-inc=/usr/include

creating cache ./config.cache

checking for a BSD compatible install... /usr/bin/install -c

checking for gcc... gcc

checking whether the C compiler (gcc ) works... yes

checking whether the C compiler (gcc ) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking whether make sets ${MAKE}... yes

checking for strip... /usr/bin/strip

checking how to run the C preprocessor... gcc -E

checking for ANSI C header files... yes

checking whether time.h and sys/time.h may both be included... yes

checking for sys/wait.h that is POSIX.1 compatible... yes

checking for ctype.h... yes

checking for dirent.h... yes

checking for errno.h... yes

checking for fcntl.h... yes

checking for getopt.h... yes

checking for grp.h... yes

checking for limits.h... yes

checking for math.h... yes

checking for pwd.h... yes

checking for signal.h... yes

checking for strings.h... yes

checking for string.h... yes

checking for syslog.h... yes

checking for unistd.h... yes

checking for uio.h... no

checking for sys/types.h... yes

checking for sys/time.h... yes

checking for sys/resource.h... yes

checking for sys/wait.h... (cached) yes

checking for sys/stat.h... yes

checking for sys/ipc.h... yes

checking for sys/msg.h... yes

checking for working const... yes

checking whether struct tm is in sys/time.h or time.h... time.h

checking for tm_zone in struct tm... yes

checking for mode_t... yes

checking for pid_t... yes

checking for size_t... yes

checking return type of signal handlers... void

checking for uid_t in sys/types.h... yes

checking type of array argument to getgroups... gid_t

checking for strdup... yes

checking for strstr... yes

checking for strtoul... yes

checking for initgroups... yes

checking for type of socket size... size_t

checking for mail... /usr/bin/mail

Init script directory: /etc/init.d

We'll use default routines (in xdata/xsddefault.*) for status data I/O...

We'll use default routines (in xdata/xcddefault.*) for comment data I/O...

We'll use template-based routines (in xdata/xedtemplate.*) for extended data I/O...

We'll use default routines (in xdata/xrddefault.*) for retention data I/O...

We'll use template-based routines (in xdata/xodtemplate.*) for object data I/O...

We'll use default routines (in xdata/xpddefault.*) for performance data I/O...

We'll use default routines (in xdata/xdddefault.*) for scheduled downtime data I/O...

checking for gdImagePng in -lgd (order 1)... no

checking for gdImagePng in -lgd (order 2)... yes

GD library was found!

checking for traceroute... /usr/bin/traceroute

checking for snprintf... yes

checking for type va_list... yes

checking for perl... /usr/bin/perl

updating cache ./config.cache

creating ./config.status

creating Makefile

creating subst

creating pkginfo

creating base/Makefile

creating common/Makefile

creating contrib/Makefile

creating cgi/Makefile

creating html/Makefile

creating xdata/Makefile

creating daemon-init

creating html/index.html

creating html/side.html

creating common/config.h

creating common/snprintf.h

creating base/nagios.h

creating cgi/cgiutils.h

Creating sample config files in sample-config/ ...

*** Configuration summary for nagios 1.0 11-24-2002 ***:

General Options:

-------------------------

Nagios executable: nagios

Nagios user/group: nagios,nagios

Command user/group: nagios,nagios

Embedded Perl: no

Install ${prefix}: /usr/local/nagios

Lock file: ${prefix}/var/nagios.lock

Init directory: /etc/init.d

Web Interface Options:

------------------------

HTML URL: http://localhost/nagios/

CGI URL: http://localhost/nagios/cgi-bin/

Traceroute (used by WAP): /usr/bin/traceroute

External Data Routines:

------------------------

Status data: Default (text file)

Object data: Template-based (text file)

Comment data: Default (text file)

Downtime data: Default (text file)

Retention data: Default (text file)

Peformance data: Default (external commands)

Extended info data: Template-based (text file)

Review the options above for accuracy. If they look okay, type 'make all' to compile the main program and CGIs.

nagios@tjener:~/nagios-1.0$ make all

*** Compile finished ***

If the main program and CGIs compiled without any errors, you can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install

- This installs the main program, CGIs, and HTML

files

make install-init

- This installs the init script in /etc/init.d

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in

/usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

*** Support Notes****************************************

If you have questions about configuring or running Nagios, please make sure that you:

- Look at the sample config files

- Read the HTML documentation

- Read the FAQs online at http://www.nagios.org/faqs

before you post a question to one of the mailing lists.

Also make sure to include pertinent information that could help others help you. This might include:

- What version of Nagios you are using

- What version of the plugins you are using

- Relevant snippets from your config files

- Relevant error messages from the Nagios log file

For those of you who are interested in contract support or

consulting services for Nagios, please visit:

http://www.nagios.org/contractsupport

*********************************************************

Enjoy.

nagios@tjener:~/nagios-1.0$ su

Skriv passord for root:

tjener:/home/nagios/nagios-1.0# make install

*** Main program, CGIs and HTML files installed ***

You can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install-init

- This installs the init script in /etc/init.d

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in /usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

tjener:/home/nagios/nagios-1.0# make install-init

*** Init script installed ***

You can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in /usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

tjener:/home/nagios/nagios-1.0#

cd /usr/local/nagios

Lager eksempler på nagios konfigurasjonsfiler:

tjener:/home/nagios/nagios-1.0# make install-config

*** Sample config file installed ***

Remember, these are *sample* config files. You'll need to read the documentation for more information on how to actually define services, hosts, etc. to fit your particular needs.

If you have questions about configuring Nagios properly, please:

- Look at the sample config files

- Read the HTML documentation

- Read the FAQs online at http://www.nagios.org/faqs

*BEFORE* you post a question to one of the mailing lists.

tjener:/home/nagios/nagios-1.0#

Gå til /usr/local/nagios/etc

Bytt navn på filene til xxxx.cfg

Satte check_external_commands=1 i filen nagios.cfg

Opprettet katalogen /usr/local/nagios/var/rw

tjener:/home/nagios/nagios-1.0#

mkdir /usr/local/nagios/var/rw

Satte rettigheter på denne katalogen:

tjener:/home/nagios/nagios-1.0# chmod 777

Lagde filen command.cmd

tjener:/home/nagios/nagios-1.0# touch command.cmd

Se nagios manual for diverse innstillinger i nagios.cfg og cgi.cfg.

Opprettet autentifikasjon for brukere av nagios.

Gikk til katalogen /usr/local/nagios/sbin

Opprettet filen .htaccess med følgende innhold:

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

require valid-user

Gikk til katalogen /usr/local/nagios/share

Opprettet filen .htaccess med følgende innhold:

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

require valid-user

Opprettet autentifikasjon for brukere av nagios:

nagios@tjener:/usr/local/nagios$ htpasswd -c /usr/local/nagios/etc/htpasswd.users nagios

New password:

Re-type new password:

Adding password for user nagios

Pakker ut nagios-plugins:

nagios@tjener:~$ tar xvzf nagios-plugins-1.3.0.tar.gz

nagios@tjener:~/nagios-plugins-1.3.0$ ./configure

--prefix=/usr/local/nagios --with-nagios-user=nagios

--with-nagios-group=nagios -–with-cgiurl=/nagios/cgi-bin

nagios@tjener:~/nagios-plugins-1.3.0$ make all

nagios@tjener:~/nagios-plugins-1.3.0$ su

tjener:/home/nagios/nagios-plugins-1.3.0# make install

Installasjon av NRPE plugin på filtjener

tjener:/usr/local/src# lynx http://telia.dl.sourceforge.net/sourceforge/

nagios/nrpe-1.8.tar.gz

tjener:/usr/local/src# tar xvzf nrpe-1.8.tar.gz

tjener:/usr/local/src# cd nrpe-1.8

tjener:/usr/local/src/nrpe-1.8# ./configure

tjener:/usr/local/src/nrpe-1.8# make all

Flytt check_nrpe plugin til plugin katalogen for nagios:

tjener:/usr/local/src/nrpe-1.8# mv src/check_nrpe/usr/local/nagios/libexec

Legg til følgende i /usr/local/nagios/etc/checkcommands.cfg:

define command{

command_namecheck_nrpe

command_line/usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

}

Legg til tjenesten som du konfigurerte på remote host til din lokale Nagios host:

define service{

host_name dhcp-000

service_description Ledig diskplass /hda1 LTSP-server

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_disk1!20!10!/dev/hda1

}

define service{

host_name dhcp-000

service_description Ledig diskplass /hda5 LTSP-server

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_disk2!20!10!/dev/hda5

}

Last Nagios konfigurasjonsfiler på nytt med denne kommandoen:

tjener:/etc/init.d# ./nagios reload

Installasjon av NRPE-plugin med tar.gz-filer på LTSP-tjener

Legg til 'nagios' gruppe i /etc/group

nagios:*:1000:nagios

Legg til nagios bruker i /etc/passwd

nagios:*:1000:1000::0:0:Nagios:/nonexistent:/sbin/nologin

Lag katalogene for nagios:

mkdir -p /usr/local/nagios/libexec

mkdir /usr/local/nagios/bin

mkdir /usr/local/nagios/etc

cd /usr/local src

Last ned og installer nagios-plugin og nrpe:

ragnar@dhcp-000:/usr/local/src$ lynx http://telia.dl.sourceforge.net/ sourceforge/nagiosplug/nagios-plugins-1.3.0.tar.gz

ragnar@dhcp-000:/usr/local/src$ tar xvzf nagios-plugins-1.3.0.tar.gz

ragnar@dhcp-000:/usr/local/src$ cd nagios-plugin-1.3.0

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ ./configure

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ make all

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ make install

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ lynx http://telia.dl.sourceforge.net/ sourceforge/nagios/nrpe-1.8.tar.gz

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ tar xvzf nrpe-1.8.tar.gz

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ cd nrpe-1.8

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ ./configure

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ make all

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ mv src/nrpe /usr/local/nagios/bin

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ mv nrpe.cfg /usr/local/nagios/etc

Sjekk at det er riktige rettigheter på nagios katalogen:

ragnar@dhcp-000:/usr/local/src$ chown -R nagios:nagios /usr/local/nagios

Editer filen /usr/local/nagios/etc/nrpe.cfg for å se om disse sjekkene ligger inne:

command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20

command[check_swap]=/usr/local/nagios/libexec/check_swap -w 75% -c 90%

command[check_smtp]=/usr/local/nagios/libexec/check_smtp –H localhost

command[check_disk1]=/usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/hda1

command[check_disk2]=/usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/hda5

kommentar: Hvis harddiskene er av type SCSI, må hda1 og hda5 byttes ut med sda1 og sda5.

Gå til:

cd /etc/init.d

Lagde scriptet som skal kjøres i oppstart av maskinen for å få nrpe deamon til å fungere fra oppstart:

dhcp-000:/etc/init.d# vi nrpe.sh

#!/bin/sh

case "$1" in

start)

/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg --daemon && echo -n ' nrpe'

;;

stop)

killall nrpe && echo -n ' nrpe'

;;

*)

echo "Usage: `basename $0` {start|stop}" >&2

;;

esac

exit 0

Kopierte check_xxx fra Filtjener til /usr/local/nagios/libexec på LTSP-tjeneren.

scp -r /usr/local/nagios/libexec root@10.0.2.100:/usr/local/nagios/libexec

Linker filer så de kjøres automatisk ved oppstart av maskinen:

dhcp-000:/etc/rc2.d# ln -s ../init.d/nrpe.sh S90nrpe

Starter nrpe daemonen:

dhcp-000:/etc/init.d# ./nrpe.sh start

Installasjon av NRPE plugin med deb-pakke på LTSP-tjener

dhcp-000:/# apt-get install netsaint-nrpe-server

Svarer yes på spørsmålet som kommer opp.

Kommer det en feilmelding, så er det trolig ikke satt opp noen apt-sourcer i sources.list. I utgangspunktet er disse bortkommentert i Skolelinux. Man må da gå inn i /etc/apt/sources.list og fjerne # foran de sourcene som har dette. Lagrer så fila og skriver: apt-get update. Prøv så på nytt.

Når installeringa er ferdig, må det editeres to filer for å programmet til å starte. Gjør følgende:

dhcp-000:/etc# vi inetd.conf

Legg til følgende linje under #:OTHER: Other services:

nrpe stream tcp nowait root /usr/sbin/tcpd /usr/sbin/nrpe –i /etc/netsaint/command.cfg

dhcp-000:/etc# vi services

Legg til følgende linje der det passer inn med nummeret:

nrpe 5666/tcp #nrpe

dhcp-000:/etc/init.d# ./inetd restart

Appendiks D2

Installation

When manually installing the Nagios application on the Skolelinux system, there are three packages we have to relate to; The Nagios core program, the Nagios-plugin module and the NRPE-plugin. Some libraries must also be included if all of the Nagios applications should work properly. The Nagios-core and the Nagios-plugin are installed on the FileServer. The NRPE-plugin and the Nagios-plugin are installed on the LTSP-server. The NRPE is a remote plugin executer. Some of the packages can be found at [15], which is the official website of Nagios. Others can be manually installed by executing the “apt-get install <package>” command.

In this chapter, we have illustrated step by step how to manually install Nagios and all of its dependent programs. We have used a lot of time manually installing and configuring Nagios, for the main purpose of getting knowledge of the structure and how the application is build up from scratch.

Nagios depend on some libraries to work properly with all of its functions. To name a few, we have GD, PNG, and JPEG. Since Nagios automatically will be installed on the system with debian packages, these libraries will also be included automatically when installing the operating system (Debian, SkoleLinux) on the different servers.

Installing Nagios with tar.gz files

We had to link all of the libraries in such a way that Nagios are working properly with all of its functions. We had to add the following line in /etc/ld.so.conf:

/usr/lib

Then we executed the command ldconfig, because ldconfig also points to the library /usr/lib

The next step was to unpack the nagios-1.0.tar.gz file with the following command:

tar xvzf nagios-1.0.tar.gz

Created a new directory: /usr/local/nagios

mkdir /usr/local/nagios

We had to add apt-sources in sources.list ( and removed ”#” from the beginning of every line in sources.list). Libpng-dev is not implemented in the SkoleLinux cd, so we had to install it from the debian distribution. Because we did not have gdlib, we had to add libpng-dev, which contains header files and c files.

tjener:/home/nagios/nagios-1.0# apt-get update

tjener:/home/nagios/nagios-1.0# apt-get install libpng-dev

Reading Package Lists... Done

Building Dependency Tree... Done

The following extra packages will be installed:

zlib1g-dev

The following NEW packages will be installed:

libpng-dev zlib1g-dev

0 packages upgraded, 2 newly installed, 0 to remove and 7 not upgraded.

Need to get 451kB of archives. After unpacking 975kB will be used.

Do you want to continue? [Y/n] y

Get:1 http://security.debian.org stable/updates/main libpng-dev 1.2.1-1.1.woody.3 [233kB]

Get:2 ftp://ftp.skolelinux.no woody/main zlib1g-dev 1:1.1.4-1 [218kB]

Fetched 451kB in 0s (506kB/s)

Reading changelogs... Done

Selecting previously deselected package zlib1g-dev.

(Reading database ... 74711 files and directories currently installed.)

Unpacking zlib1g-dev (from .../zlib1g-dev_1%3a1.1.4-1_i386.deb) ...

Selecting previously deselected package libpng-dev.

Unpacking libpng-dev (from .../libpng-dev_1.2.1-1.1.woody.3_i386.deb) ...

Setting up zlib1g-dev (1.1.4-1) ...

Setting up libpng-dev (1.2.1-1.1.woody.3) ...

Libpng-dev is now installed properly, and it is in order to run a new configuration of Nagios. But first we must clean our first configuration. This is done by the following commands:

nagios@tjener:~/nagios-1.0$ ./configure --prefix=/usr/local/nagios

--with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/

--with-nagios-user=nagios --with-nagios-grp=nagios

--with-gd-lib=/usr/lib --with-gd-inc=/usr/include

creating cache ./config.cache

checking for a BSD compatible install... /usr/bin/install -c

checking for gcc... gcc

checking whether the C compiler (gcc ) works... yes

checking whether the C compiler (gcc ) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking whether make sets ${MAKE}... yes

checking for strip... /usr/bin/strip

checking how to run the C preprocessor... gcc -E

checking for ANSI C header files... yes

checking whether time.h and sys/time.h may both be included... yes

checking for sys/wait.h that is POSIX.1 compatible... yes

checking for ctype.h... yes

checking for dirent.h... yes

checking for errno.h... yes

checking for fcntl.h... yes

checking for getopt.h... yes

checking for grp.h... yes

checking for limits.h... yes

checking for math.h... yes

checking for pwd.h... yes

checking for signal.h... yes

checking for strings.h... yes

checking for string.h... yes

checking for syslog.h... yes

checking for unistd.h... yes

checking for uio.h... no

checking for sys/types.h... yes

checking for sys/time.h... yes

checking for sys/resource.h... yes

checking for sys/wait.h... (cached) yes

checking for sys/stat.h... yes

checking for sys/ipc.h... yes

checking for sys/msg.h... yes

checking for working const... yes

checking whether struct tm is in sys/time.h or time.h... time.h

checking for tm_zone in struct tm... yes

checking for mode_t... yes

checking for pid_t... yes

checking for size_t... yes

checking return type of signal handlers... void

checking for uid_t in sys/types.h... yes

checking type of array argument to getgroups... gid_t

checking for strdup... yes

checking for strstr... yes

checking for strtoul... yes

checking for initgroups... yes

checking for type of socket size... size_t

checking for mail... /usr/bin/mail

Init script directory: /etc/init.d

We'll use default routines (in xdata/xsddefault.*) for status data I/O...

We'll use default routines (in xdata/xcddefault.*) for comment data I/O...

We'll use template-based routines (in xdata/xedtemplate.*) for extended data I/O...

We'll use default routines (in xdata/xrddefault.*) for retention data I/O...

We'll use template-based routines (in xdata/xodtemplate.*) for object data I/O...

We'll use default routines (in xdata/xpddefault.*) for performance data I/O...

We'll use default routines (in xdata/xdddefault.*) for scheduled downtime data I/O...

checking for gdImagePng in -lgd (order 1)... no

checking for gdImagePng in -lgd (order 2)... yes

GD library was found!

checking for traceroute... /usr/bin/traceroute

checking for snprintf... yes

checking for type va_list... yes

checking for perl... /usr/bin/perl

updating cache ./config.cache

creating ./config.status

creating Makefile

creating subst

creating pkginfo

creating base/Makefile

creating common/Makefile

creating contrib/Makefile

creating cgi/Makefile

creating html/Makefile

creating xdata/Makefile

creating daemon-init

creating html/index.html

creating html/side.html

creating common/config.h

creating common/snprintf.h

creating base/nagios.h

creating cgi/cgiutils.h

Creating sample config files in sample-config/ ...

*** Configuration summary for nagios 1.0 11-24-2002 ***:

General Options:

-------------------------

Nagios executable: nagios

Nagios user/group: nagios,nagios

Command user/group: nagios,nagios

Embedded Perl: no

Install ${prefix}: /usr/local/nagios

Lock file: ${prefix}/var/nagios.lock

Init directory: /etc/init.d

Web Interface Options:

------------------------

HTML URL: http://localhost/nagios/

CGI URL: http://localhost/nagios/cgi-bin/

Traceroute (used by WAP): /usr/bin/traceroute

External Data Routines:

------------------------

Status data: Default (text file)

Object data: Template-based (text file)

Comment data: Default (text file)

Downtime data: Default (text file)

Retention data: Default (text file)

Peformance data: Default (external commands)

Extended info data: Template-based (text file)

Review the options above for accuracy. If they look okay, type 'make all' to compile the main program and CGIs.

nagios@tjener:~/nagios-1.0$ make all

*** Compile finished ***

If the main program and CGIs compiled without any errors, you can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install

- This installs the main program, CGIs, and HTML files

make install-init

- This installs the init script in /etc/init.d

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in

/usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

*** Support Notes****************************************

If you have questions about configuring or running Nagios, please make sure

that you:

- Look at the sample config files

- Read the HTML documentation

- Read the FAQs online at http://www.nagios.org/faqs

before you post a question to one of the mailing lists.

Also make sure to include pertinent information that could help others help you. This might include:

- What version of Nagios you are using

- What version of the plugins you are using

- Relevant snippets from your config files

- Relevant error messages from the Nagios log file

For those of you who are interested in contract support or

consulting services for Nagios, please visit:

http://www.nagios.org/contractsupport

*********************************************************

Enjoy.

nagios@tjener:~/nagios-1.0$ su

Type the root-password:

tjener:/home/nagios/nagios-1.0# make install

*** Main program, CGIs and HTML files installed ***

You can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install-init

- This installs the init script in /etc/init.d

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in /usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

tjener:/home/nagios/nagios-1.0# make install-init

*** Init script installed ***

You can continue with installing Nagios as follows (type 'make' without any arguments for a list of all possible options):

make install-commandmode

- This installs and configures permissions on the

directory for holding the external command file

make install-config

- This installs *SAMPLE* config files in /usr/local/nagios/etc

You'll have to modify these sample files before you can use Nagios. Read the HTML documentation for more info on doing this. Pay particular attention to the docs on object configuration files, as they determine what/how things get monitored!

tjener:/home/nagios/nagios-1.0# cd /usr/local/nagios

The next step is to create samples of the configuration files (cfg-sample-files):

tjener:/home/nagios/nagios-1.0# make install-config

*** Sample config file installed ***

Remeber, these are *sample* config files. You'll need to read the documentation for more information on how to actually define services, hosts, etc. to fit your particular needs.

If you have questions about configuring Nagios properly, please:

- Look at the sample config files

- Read the HTML documentation

- Read the FAQs online at http://www.nagios.org/faqs

*BEFORE* you post a question to one of the mailing lists.

tjener:/home/nagios/nagios-1.0#

Enter the directory /usr/local/nagios/etc

Change the file names in this directory to xxxx.cfg

Changed the “check_external_commands” to the attribute 1 in the nagios.cfg file

Created a new directory rw at this location: /usr/local/nagios/var/rw

tjener:/home/nagios/nagios-1.0# mkdir /usr/local/nagios/var/rw

Access rights for the directory were modified by the following command:

tjener:/home/nagios/nagios-1.0# chmod 777 /usr/local/nagios/var/rw

Created the file command.cmd

tjener:/home/nagios/nagios-1.0# touch

/usr/local/nagios/var/rw/command.cmd

Read the manual for setting up nagios.cfg og cgi.cfg.

Next step is to create authentication for users of Nagios.

Go to the directory /usr/local/nagios/sbin

Make a new file named .htaccess, and add the following lines in the file :

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

require valid-user

Go to the directory /usr/local/nagios/share

Added a new file named .htaccess that contains these commands:

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

require valid-user

Make new users for Nagios:

nagios@tjener:/usr/local/nagios$ htpasswd -c

/usr/local/nagios/etc/htpasswd.users nagios

New password:

Re-type new password:

Adding password for user nagios

Unpacking Nagios-plugins:

nagios@tjener:~$ tar xvzf nagios-plugins-1.3.0.tar.gz

nagios@tjener:~/nagios-plugins-1.3.0$ ./configure

--prefix=/usr/local/nagios --with-nagios-user=nagios

--with-nagios-group=nagios -–with-cgiurl=/nagios/cgi-bin

nagios@tjener:~/nagios-plugins-1.3.0$ make all

nagios@tjener:~/nagios-plugins-1.3.0$ su

tjener:/home/nagios/nagios-plugins-1.3.0# make install

Appendiks D3

Installation of the NRPE-plugin (deb-package) on each LTSP-server

First we had to alter the file /etc/sources.list to remove all the # at the beginning of each apt-source. Then we updated the apt-cache by:

dhcp-000:/# apt-get update

Then we could install NRPE:

dhcp-000:/# apt-get install netsaint-nrpe-server

To start the daemon we had to add the following line in the file /etc/services:

nrpe 5666/tcp #nrpe

and in /etc/inetd.conf:

nrpe stream tcp nowait root /usr/sbin/tcpd /usr/sbin/nrpe –i /etc/netsaint/command.cfg

Then it is time to restart the inetd superserver by

dhcp-000:/etc/init.d/# ./inetd restart

Appendiks D4

Installasjon av NRPE-plugin med tar.gz-filer på LTSP-tjener

Legg til 'nagios' gruppe i /etc/group

nagios:*:1000:nagios

Legg til nagios bruker i /etc/passwd

nagios:*:1000:1000::0:0:Nagios:/nonexistent:/sbin/nologin

Lag katalogene for nagios:

mkdir -p /usr/local/nagios/libexec

mkdir /usr/local/nagios/bin

mkdir /usr/local/nagios/etc

cd /usr/local src

Last ned og installer nagios-plugin og nrpe:

ragnar@dhcp-000:/usr/local/src$ lynx http://telia.dl.sourceforge.net/ sourceforge/nagiosplug/nagios-plugins-1.3.0.tar.gz

ragnar@dhcp-000:/usr/local/src$ tar xvzf nagios-plugins-1.3.0.tar.gz

ragnar@dhcp-000:/usr/local/src$ cd nagios-plugin-1.3.0

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ ./configure

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ make all

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ make install

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ lynx http://telia.dl.sourceforge.net/ sourceforge/nagios/nrpe-1.8.tar.gz

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ tar xvzf nrpe-1.8.tar.gz

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0$ cd nrpe-1.8

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ ./configure

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ make all

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ mv src/nrpe /usr/local/nagios/bin

ragnar@dhcp-000:/usr/local/src/nagios-plugins-1.3.0/nrpe-1.8$ mv nrpe.cfg /usr/local/nagios/etc

Sjekk at det er riktige rettigheter på nagios katalogen:

ragnar@dhcp-000:/usr/local/src$ chown -R nagios:nagios /usr/local/nagios

Editer filen /usr/local/nagios/etc/nrpe.cfg for å se om disse sjekkene ligger inne:

command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20

command[check_swap]=/usr/local/nagios/libexec/check_swap -w 75% -c 90%

command[check_smtp]=/usr/local/nagios/libexec/check_smtp –H localhost

command[check_disk1]=/usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/hda1

command[check_disk2]=/usr/local/nagios/libexec/check_disk -w 10% -c 5% -p /dev/hda5

Kommentar: Hvis harddiskene er av type SCSI, må hda1 og hda5 byttes ut med sda1 og sda5.

Gå til:

cd /etc/init.d

Lagde scriptet som skal kjøres i oppstart av maskinen for å få nrpe deamon til å fungere fra oppstart:

dhcp-000:/etc/init.d# vi nrpe.sh

#!/bin/sh

case "$1" in

start)

/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg --daemon && echo -n ' nrpe'

;;

stop)

killall nrpe && echo -n ' nrpe'

;;

*)

echo "Usage: `basename $0` {start|stop}" >&2

;;

esac

exit 0

Kopierte check_xxx fra Filtjener til /usr/local/nagios/libexec på LTSP-tjeneren.

scp -r /usr/local/nagios/libexec root@10.0.2.100:/usr/local/nagios/libexec

Linker filer så de kjøres automatisk ved oppstart av maskinen:

dhcp-000:/etc/rc2.d# ln -s ../init.d/nrpe.sh S90nrpe

Starter nrpe daemonen:

dhcp-000:/etc/init.d# ./nrpe.sh start

Appendiks E1

Howto configure Nagios

To get information about different hosts and install custom-made configuration-files of the network to the Nagios core, we have developed several perl-scripts which automatically handle these jobs. One script on each LTSP-server must be executed to collect information about LTSP-clients on that particular network. The result of these files is then transferred to the Fileserver for further modification. On the Fileserver there is one script which must be executed, and this script contains links which automatically executes perl-script who emerge all into a final result.

The idée behind these scripts was to make it as simple as possible to configure Nagios. The scripts are custom-made for the Skolelinux network, and are not fitted for any other purpose.

It is important that you follow these steps in the following order.

1. Before you begin configuring Nagios:

There is some information about the network you have to gather before you can begin configuring Nagios.

* You have to know the root-password on the Fileserver, and all of the LTSP-servers

* All of the following commands (italic and bold) must be executed from the born again shell (bash)

How to open a shell:

The command-shell can be located at the start menu. Click on the "K-icon" at the bottom-left on your screen, then move the mouse to "system", a new menu will appear. On the new menu there is a icon called "skall" (shell), click on this icon and a shell will appear.

* For each LTSP-server and Fileserver do the following:

Log in as root on the LTSP-servers, and the Fileserver

Username: root

Password: xxx ( xxx is set under installation)

* Make sure every LTSP-clients are configured with their respective mac-address in webmin

* Location of the perlscripts:

* Last but not least remember to turn on all of the hosts (LTSP-server(s), Fileserver, LTPS-clients, workstations, firewall) on the network before you begin running any scripts on the servers. This is vital because the scripts only configure hosts that are alive.

2. For each LTSP-server:

Run /sbin/ifconfig (or simply ifconfig, since you are root of the system) and write down/remember the inet addr (10.0.x.x). x.x are variables that vary for each LTSP-server. These addresses will be used as argument when executing the script on the LTSP-server. You will also see the address 10.0.3.255. This is the broadcast-address, just ignore this one. Go to /usr/confignagios/ and

run the command perl pingscriptTKS.pl "ARGUMENT" on the LTSP-server with the IP-address of the LTSP-server as argument (this is the inet addr). An argument is something (a string and/or integer) which you add at the end of the execute command. The purpose of this argument is to tell the script that the respective LTSP-server is the parent of each of its LTSP-clients.

Example: Executing the perlscript on a LTSP-server with inet addr 10.0.2.100

perl pingscriptTKS.pl 10.0.2.100

After you run this command, you will be asked to type in the password for the root-user on the Fileserver. This question pops up because the file hosterTKSx.txt is going to be transferred to the Fileserver for further modification. This requires a password because the file is transferred over a secure protocol (ssh).

After the script on the LTSP-server has been executed, the Fileserver have all the information about the LTSP-server and LTSP-clients it needs. It is essential to run the script on all of the LTSP-servers before you go to step 3.

PS!! You do not need to run any scripts on the workstations; the script on the Fileserver takes care of this by its own.

3. Running perl-script on Fileserver:

Go to /usr/confignagios/ and run the command perl autoconfig_nagios.pl on the Fileserver.

This script executes several other scripts automatically and moves the final result into the Nagios configuration directory (/usr/local/nagios/etc/).

Nagios should now have all of its updated and custom-made configuration files. You can now open Opera or another web-browser program, and go to the URL "http://localhost/nagios/".

Comments: This “howto” is a manual that you should follow every time a new host is plugged into or removed from the network.

Appendix E2

Howto configure Nagios to notify errors by e-mail

Manual configuration

Because we want to make the configuration as automatic as possible, you have to add a user with the name “nagios-admin” in Webmin before you start to configure.

If the configuration is already done, like it should be, you just need to set up a local k-mail account.

To configure Nagios to send you a mail when something go wrong, you have to edit two files, contacts.cfg and contactgroup.cfg in /usr/local/nagios/etc/

1. Go to the file contacts.cfg in /usr/local/nagios/etc/ and explore it, then edit this file so it look like the figure 1

figure1. The file contacts.cfg is supposed to look like this.

The directive email tells Nagios which user it should send error reports to. You may change this if you want it to send to another user. (It has to be a local user). It is not possible to send error reports to another network, without configuring a relay server for emails. Sadly we did not have time to try this.

When your file looks like figure 1, you can store it and go to the next point.

2. Now you have to configure the file contactgroups.cfg in /usr/local/nagios/etc , and edit this like figure 2

figure2. The file contactgroups.cfg.

Then you just have to store this file too, and set up a mail account in k-mail, where you can read your messages.

So, login as nagios-admin and type your password, then go to the configuration of k-mail.

How to configure K-mail? So you can get notified when something goes wrong.

Open the K-mail icon in the bottom of you screen and follow the manual step by step.

1. Your first window has to be like this. When it is, click at the button “Bruk/Use”, and then go to “No:Nettverk/ Eng:Network” (figure 3)

figure3.

2. Nettverk/Network

In this page you also have to edit some parameters. In figure4 there is a button called “legg til../Add..”, click on this one.

figure4.

3. Now you’ve got a text box whit 3 choices, choose “Lokal e-postkonto” and “OK”!( figure 5)

figure5

4.

Then you just have to do the same configuration as shown in figure 6.

figure 6

If this went wrong, a solution is to change the address from nagios-admin@localhost, to root@localhost in the figure1 under “Howto configure Nagios to notify errors by e-mail”. And then reconfigure the mail agent exim, so every message to root is redirected to your local mail as nagios-admin user. (This can be a problem because you will get all the mails addressed to root on this mail account, but it’s safer)

To do that, you have to explore and run the eximconfiguration.pl script in /usr/sbin/… (You have to be root).

Then you start this script typing: ./eximconfig Then some questions will pop up on your screen.

There you have to choose number (4) “Local delivery only: You are not on a network mail for local user.”

And then enter “nagios-admin” after “enter a value:”.

After this you just have to reload exim in /etc/init.d/

Just type: “./exim reload”

Now everything is ok and you will get mail!

Appendix E3

Script documentation

pingscriptTKS.pl:

This script is executed on each LTSP-server.

The script collects information about all of its LTSP-clients. For each LTSP-client it will generate a line in a file (hosterTKSxxx.txt) that contains the LTSP-clients IP-address, hostname, its parents IP and its parent’s hostname. The IP-address of the parent is typed in as an argument when the script is executed. There will be generated a file called command.cfg (This file is used by the NRPE (Nagios Remote Plug-in Executor) to define which checks the fileserver can do on the LTSP-server), based on how many LTSP-clients it found. That is because one of the check commands (check_dead) in NRPE needs to know how many LTSP-clients there is on its LTSP-server. After generating the file "command.cfg", it will be copied to /etc/netsaint/.

Nagios itself does not need the information about the LTSP-clients, but the script hostgroups_services.pl uses this to find out if a machine is a LTSP-server or a workstation. (A workstation will not have any LTSP-clients connected to it). That is why it is vital that a LTSP-server has at least one LTPS-client connected to it when the script is executed. If this is not the case, the script will fail writing to its result file. So if you have a LTPS-server without any LTSP-clients you don't need to run this script. The host will then be initialized as a workstation in Nagios. One of the result files made by this script is transferred to the fileserver over the SSH protocol. This requires the root password at the fileserver. At the end it tries to install fping which is used by the NRPE. If it is already installed it will only tell you that the newest version is already installed.

An example of the syntax to run the script:

dhcp-000:/home/nagios# perl pingscriptTKS.pl 10.0.2.100

An example of the file hosterTKSxxx.txt:

192.168.0.10.ltsp-010.10.0.2.100.dhcp-000

192.168.0.11.ltsp-011.10.0.2.100.dhcp-000

The script:

#!/usr/bin/perl

#Made by Vidar Grønland and Tarjei Westrum at HiG 2003

#

($a, $b, $c, $d) = split (/\./, $ARGV[0]); #Spilt the IP-address, which is the argument to the script, into 4 peaces

if ($d < "110") { #The following three checks generates hostname extracted from the IP-address

$tmp = ($d - 100);

$parent = "dhcp-00$tmp";

}

elsif ($d <"200" && $d >"109") {

$tmp = ($d - 100);

$parent = "dhcp-0$tmp";

}

elsif ($d > "199" && $d < "255") {

$tmp = ($d - 100);

$parent = "dhcp-$tmp";

}

print `ping -c 2 192.168.0.255 > pingresTKS.txt`; #Ping broadcast at the LTSP-net, and write the result to the file (pingresTKS.txt)

sleep(2); #Avoid conflict between read/write in the file pingresTKS.txt

print `rm -f hosterTKS$d.txt`; #Delete the file hosterTKSxxx.txt, if it already exists

open(INFILE, "<pingresTKS.txt") || die "ERROR, unable to open file pingresTKS.txt\n"; #Open the file pingresTKS.txt

while (<INFILE>) { #As long as the file contains any data

chomp; #Remove \n at the end of the line

if (m/(\d+)\.(\d+)\.(\d+)\.(\d+)/) { #If it finds an IP-address, do the following:

$ipadr = "$1.$2.$3.$4"; #Put the IP-addr in the variable $ipadr

if (($4 != "255") && ($4 != "254")) { #Checking if the IP-addr do not end at 254/255

#(irrelevant addresses)

if ($4 < 100) { #If the last segment in the IP address is less than 100 do:

$e = "0$4"; #$e => 0xx, xx is the same as the xx in 192.168.0.xx

}else {$e = $4;} #If the last segment is larger than 100 do:

#ltsp-xxx, where xxx is the xxx in 192.168.0.xxx

$hostname = "ltsp-$e"; #$hostname => ltsp-0xx or ltsp-xxx

#Writes to a new file for each LTSP-server. $d is the last segment of the IP address of the server.

open(OUTFILE, ">>hosterTKS$d.txt") || "ERROR, unable to write to file

hosterTKS$d.txt)\n";

print OUTFILE "$ipadr.$hostname.$ARGV[0].$parent\n"; #Writes to file

close(OUTFILE);

}

}

}

close(INFILE);

print `rm -f pingresTKS.txt`; #Deletes the file pingresTKS.txt since this is not needed any more

#**************************************NRPE config**************************************************************

#This part generates the command.cfg file used by the NRPE daemon. The main purpose of this part is

#to find out the IP addresses of the first and last LTSP-client, and put this in as an argument for

#the check_dead plug-in

#

open(INFILE, "<hosterTKS$d.txt") || die "ERROR, unable to open file hosterTKS$d\n"; {

$n = 0;

while(<INFILE>) {

chomp;

($aa, $bb, $cc, $dd, $ee, $ff, $gg, $hh, $ii, $jj) = split (/\./, $_, 10);

$tkIP = "$aa.$bb.$cc.$dd";

$ipnr{$tkIP}++;

}

}

close(INFILE);

@keys = sort keys %ipnr; #Sorts the hash table $ipnr in increasing order

print "Thin clients found on server $ARGV[0]\n";

foreach (@keys) { #Prints out all the LTSP-clients which lies in @keys

print ($_);

print "\n";

}

$first = @keys[0]; #$first => the LTSP-client with the lowest IP address

$rr = $#keys; #$rr => the length of array @keys (number of elements)

$last = @keys[$rr]; #$last => the LTSP-client with the highest IP address

print `rm -f command.cfg`; #Deletes command.cfg in case it already exists

open(OUTFILE, ">>command.cfg") || "ERROR, unable to write to file (command.cfg)\n"; {

print OUTFILE "# Plug-in Configuration for netsaint.

#

# Ben Bell <bjb@debian.org> 20/11/01

#

# Debian doesn't use this file by default. Instead, the command definitions

# for have been split into separate files in /usr/share/netsaint/pluginconfig

# and are automatically merged into /etc/netsaint/plugins-auto.cfg by

# update-netsaint(8)

# The original upstream version of this file can be found in

# /usr/share/doc/netsaint-plugins/examples

#

# Feel free to add local plug-in definitions to this file.

#

command[check_disk1]=/usr/lib/netsaint/plugins/check_disk -w 10% -c 5% -p /dev/hda1

command[check_disk2]=/usr/lib/netsaint/plugins/check_disk -w 10% -c 5% -p /dev/hda5

command[check_load]=/usr/lib/netsaint/plugins/check_load -w 15,10,5 -c 30,25,20

command[check_smtp]=/usr/lib/netsaint/plugins/check_smtp -H localhost

command[check_dead]=/usr/lib/netsaint/plugins/check_dead -w 1 -c 2 -r $first:$last

command[check_swap]=/usr/lib/netsaint/plugins/check_swap -w 75% -c 90%

";

}

close(OUTFILE);

print `rm -f hosterTKS$d.txt`; #Deletes hosterTKSxxx.txt

print `apt-get install fping`; #Installs fping used by the NRPE daemon

print "NOTE!! If you use SCSI disks, you need to edit the file /etc/netsaint/command.cfg\n";

print "On the first two lines you must change /dev/hda1 with /dev/sda1 and /dev/hda5 with /dev/sda5\n";

sleep(1);

print `cp check_dead /usr/lib/netsaint/plugins`; #Copies the check_dead plug-in to a new catalogue

print `chmod 555 /usr/lib/netsaint/plugins/check_dead`; #Changes access-rights on the plug-in (read and eXecute)

print `cp command.cfg /etc/netsaint`; #Copies command.cfg to /etc/netsaint

print `/etc/init.d/./inetd restart`; #Restarts the inetd superserver

print "You will now have to enter the root password for the main file server\n";

print `scp hosterTKS$d.txt root\@10.0.2.2:/home/test/`; #Copies hosterTKSxxx.txt to the fileserver

hostgroups.pl

This script is executed on the fileserver

The aim for this script is to generate the Nagios configuration file:

- hostgroups.cfg

The hostgroups.cfg file contains information about how the hosts are grouped. The script uses information from the file hoster.txt made by the script tks_fs.pl. This file contains all the hosts on the network with each hosts IP, hostname, parent IP and parent hostname.

An example of the file hoster.txt:

10.0.2.101.dhcp-001.10.0.2.2.tjener

10.0.2.100.dhcp-000.10.0.2.2.tjener

192.168.0.10.ltsp-010.10.0.2.100.dhcp-000

192.168.0.11.ltsp-011.10.0.2.100.dhcp-000

The script sorts LTSP-servers and workstations into two arrays. One array for LTSP-servers and one array for workstations. This is sorted (for the example file over) by comparing the hostname on the two first lines in hoster.txt with the parent’s hostname on the two last lines. If it is a match the hostname is a LTSP-server. The LTSP-server array is then printed out under "members" in a predefined hostgroup, named "tynnklientservere", separated by commas. The workstation array is printed out under "members" in a predefined hostgroup, named "arbeidsstasjoner", also separated by commas. When we now have grouped similar hosts into separate groups depending on what kind of machine it is, Nagios is fairly simple to configure.

The script:

#!/usr/bin/perl

#Made by Tarjei Westrum and Vidar A. Grønland at HiG 2003

#

#The aim for this script is to generate the Nagios configuration

#file hostgroups.cfg based on information collected by other scripts

#

print `rm -f hostgroups.cfg`; #Removes hostgroups.cfg if it already exist

$date = `date`; #The date the script was executed (used later)

open ( INFILE1, "<hoster.txt" ) || die "ERROR, unable to open hoster.txt\n";

$u=0; #Counter

while(<INFILE1>) { #As long as there is something in the file do:

chomp;

#Splits one line into several variables

($a, $b, $c, $d, $e, $f, $g, $h, $i, $j) = split (/\./, $_, 10);

$hostname = "$e"; #Makes it easier to follow the code but not necessary

open (INFILE2, "<hoster.txt" ) || die "ERROR, unable to open hoster.txt";

while(<INFILE2>) { #Open the file again

chomp;

($k, $l, $m, $n, $o, $p, $q, $r, $s, $t) = split (/\./, $_, 10);

$parentname = "$t"; #Makes it easier to follow the code but not necessary

if ($hostname eq $parentname) {

@tkservere[$u] = "$e"; #Puts all LTSP-servers into a array called tkservere

}

}

if(@tkservere[$u] eq '') { #Removes empty elements in the tkserver-array

$u--;

}

$u++; #Moves the pointer to the next element in array tkservere

close(INFILE2); #Closes INFILE2

}

close(INFILE1); #Closes INFILE1

#

#The next INFILE is just to put all of the hosts on the 10.0.0.0 net into an array

#

$xx=0;

open (INFILE3, "<hoster.txt" ) || die "ERROR, unable to open hoster.txt\n";

while (<INFILE3>) { #While not end of file do:

chomp;

($a, $b, $c, $d, $e, $f, $g, $h, $i, $j) = split (/\./, $_, 10);

if ($a != '192') { #If the IP-address doesn't start with 192 then:

@temp[$xx] = "$e"; #Puts the hostname into a array called temp

$xx++; #Moves the array-pointer to the next element

}

}

close(INFILE3);

#

#This sequence is to sort all workstations into a array, by comparing the array that contains all of the hosts on the

#10.0.0.0 net with the array of LTSP-servers (@tkservere). If a host in the array @temp is not represented in the array

#@tkservere it must be a workstation

#

$k = 0;

for ($i=0; $i < $xx; $i++) { #Counts up the elements in @temp

$status = 0; #Status variable used later

for ($j=0; $j < $u; $j++) { #Counts up the elements in @tkservere

if ( @temp[$i] eq @tkservere[$j]) { #Checks if one element in @temp exists in any of the elements in the

# array @tkservere

$status = 1; #If it does, status is set to 1

}

}

if ($status == 0 ) { #If the hostname do not match any of the elements in the array

#@tkservere

@arbeidsstasjoner[$k] = @temp[$i]; #it is a workstation, and they are put in a array named

#@arbeidsstasjoner

$k++;

}

}

my $listSeparator = $"; #This is a function to separate elements in an array with comma when they are printed out

$" = ',';

#Writing the result to the file hostgroups.cfg

open(OUTFILE, ">>hostgroups.cfg") || "ERROR, unable to write to file (hostgroups.cfg)\n";

#*****************Making hostgroups.cfg********************************************************

print OUTFILE "################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: $date#

################################################################################

################################################################################

# HOST GROUP DEFINITIONS

#

# SYNTAX:

#

################################################################################

# 'linux-boxes' host group definition

define hostgroup{

hostgroup_name tynnklientservere

alias Intern nett

contact_groups nagios

members @tkservere

}

define hostgroup{

hostgroup_name arbeidsstasjoner

alias Arbeidsstasjoner

contact_groups nagios

members @arbeidsstasjoner

}

";

close(OUTFILE);

print `rm -f hoster.txt`; #Delete the file hoster.txt, we don't need it any more!

pingscriptFS.pl:

Executed on the fileserver.

This script pings all the hosts on the 10.0.0.0 nett.

It then generates a file called "hosterFS.txt" which contains information of all the hosts on the 10.0.0.0 net. The format of the file is the same as for the file "hosterTKSxxx.txt.

Ex. 10.0.2.100.dhcp-000.10.0.2.2.tjener

10.0.2.101.dhcp-001.10.0.2.2.tjener

The script:

#!/usr/bin/perl

#Made by Tarjei Westrum and Vidar Grønland at Høgskolen i Gjøvik 2003

#

$temp = "10.0.2.2"; #The fileserver has always the IP-address 10.0.2.2

($a, $b, $c, $d) = split (/\./, $temp); #Splits the IP-address which is the argument to the script, into 4 peaces

$parent = "tjener"; #Set $parent to "tjener"

print `ping -c 2 10.0.3.255 > pingFS.txt`; #Ping the broadcast address, and writes the result to (pingFS.txt)

sleep(2); #To insure that all of the pingresults written to the file pingFS.txt is done writing,

#before we can read from the file

print `rm -f hosterFS.txt`; #Delete the file hosterFS.txt, if it already exists

open(INFILE, "<pingFS.txt") || die "ERROR, unable to open pingFS.txt\n"; { #Open the file pingFS.txt

while (<INFILE>) { #While there is something in the file

chomp; #Remove \n at the end of the line

if (m/(\d+)\.(\d+)\.(\d+)\.(\d+)/) { #If it finds an IP-address, do:

$ipadr = "$1.$2.$3.$4"; #Puts the IP-address in a variable named $ipadr

if (($4 != "255") && ($4 != 1) && ($4 != 2)) { #Checks if the $ipadr do not end at

#255/1/2(irrelevant)

if ($4 < 110) { #If the last digits in the IP-address is less than

#110

$tmp = ($4 - 100);

$e = "$tmp"; #Set the format in hostname to: ltsp- 0xx,

$hostname ="dhcp-00$e"; #where xx is taken from 10.0.2.xx

}

elsif ($4 < 200) {

$tmp = ($4 - 100);

$e = $tmp;

$hostname = "dhcp-0$e";

}

elsif ($4 < 254) {

$tmp = ($4 - 100);

$e = $tmp;

$hostname = "dhcp-$e";

}

open(OUTFILE, ">>hosterFS.txt") || "ERROR, unable to write to file (hosterFS.txt)\n";

print OUTFILE "$ipadr.$hostname.$temp.$parent\n"; #Prints the result

#to the file hosterFS.txt

close(OUTFILE);

}

}

}

}

close(INFILE); #Close the file pingFS.txt

print `rm -f pingFS.txt`; #Delete the file pingFS.txt

tks_fs.pl:

Executed on the fileserver

The script merges the all the hosterTKSxxx.txt and the hosterFS.txt into a new file called hoster.txt. This file now contains information about all the machines on your network, both the 10.0.0.0 net and all the 192.168.0.0 nets.

Example on how the "hoster.txt" looks like:

10.0.2.100.dhcp-000.10.0.2.2.tjener

10.0.2.101.dhcp-001.10.0.2.2.tjener

192.168.0.10.ltsp-010.10.0.2.100.dhcp-000

192.168.0.11.ltsp-011.10.0.2.100.dhcp-000

The script:

#!/usr/bin/perl

#

#Made by Vidar Grønland and Tarjei Westrum at HiG 2003

#This script merges several other files into one new file. This file

#will then contain all the hosts on the network

#

print `rm -f hoster.txt`; #Deletes the file hoste.txt if it already exists (-f to not get error reports)

open(INFILE, "<hosterFS.txt") || die "ERROR, unable to open file hosterFS.txt\n"; { #Opens the file ping.txt

while (<INFILE>) { #while not end of file, do:

chomp; #Removes newline at end of line

open(OUTFILE, ">>hoster.txt") || "Error, unable to write to file (hoster.txt)\n";

print OUTFILE "$_\n"; #Writes the line to a new file called hoster.txt

close(OUTFILE);

}

}

close(INFILE);

#************************************************************************************************

#Add LTSP-clients#

#LTSP-clients are stored in different files depending on which LTSP-server they belong to.

#These files is named i.e. hosterTKS100.txt if they belong to LTSP-server dhcp-000.

#The script will not work if there is a LTSP-server that has hostname higher than dhcp-150.

#

for ($i=100;$i<150;$i++) {

if (-e "hosterTKS$i.txt") { #If the file exists

open(INFILE, "<hosterTKS$i.txt") || die "Finished!\n"; #Open the file hosterTKS$i.txt

while (<INFILE>) { #While not end of file

chomp; #Removes newline at end of line

open(OUTFILE, ">>hoster.txt") || "ERROR, unable to write to file (hoster.txt)\n";

print OUTFILE "$_\n"; #Adds the line to the file hoster.txt

close(OUTFILE);

}

}

}

close(INFILE);

hosts.pl

Executed on the fileserver.

This script makes the file "hosts.cfg". It contains information about each host on the network except LTSP-clients. It uses the file "hoster.txt" to generate this file.

Nagios uses this file to see which hosts it can perform checks on. In this file you can specify several options i.e.; alias, hostname etc

# 'linux2' host definition

define host{

use generic-host ; Name of host template to use

host_name firewall #the hostname

alias Brannmur #an alias you can specify

address 10.0.2.1 #the hosts IP-address

parents tjener #the name of its parent

check_command check-host-alive

max_check_attempts 10 #number of check attempts

notification_interval 120 #120 min

notification_period 24x7 #24h a day, 7 days a week

notification_options d,u,r #d=down, u=unreachable, r=recovering

}

host_name:

This directive is used to define a short name used to identify the host. It is used in host group and service definitions to reference this particular host. Hosts can have multiple services (which are monitored) associated with them. When used properly, the $HOSTNAME$ macro will contain this short name.

alias:

This directive is used to define a longer name or description used to identify the host. It is provided in order to allow you to more easily identify a particular host. When used properly, the $HOSTALIAS$ macro will contain this alias/description.

address:

This directive is used to define the address of the host. Normally, this is an IP address, although it could really be anything you want (so long as it can be used to check the status of the host). You can use a FQDN to identify the host instead of an IP address, but if DNS services are not available this could cause problems. When used properly, the $HOSTADDRESS$ macro will contain this address. Note: If you do not specify an address directive in a host definition, the name of the host will be used as its address. A word of caution about doing this, however - if DNS fails, most of your service checks will fail because the plugins will be unable to resolve the host name.

parents:

This directive is used to define a comma-delimited list of short names of the "parent" hosts for this particular host. Parent hosts are typically routers, switches, firewalls, etc. that lie between the monitoring host and a remote hosts. A router, switch, etc. which is closest to the remote host is considered to be that host's "parent". Read the "Determining Status and Reachability of Network Hosts" document located here for more information. If this host is on the same network segment as the host doing the monitoring (without any intermediate routers, etc.) the host is considered to be on the local network and will not have a parent host. Leave this value blank if the host does not have a parent host (i.e. it is on the same segment as the Nagios host). The order in which you specify parent hosts has no effect on how things are monitored.

check_command:

This directive is used to specify the short name of the command that should be used to check if the host is up or down. Typically, this command would try and ping the host to see if it is "alive". The command must return a status of OK (0) or Nagios will assume the host is down. If you leave this argument blank, the host will not be checked - Nagios will always assume the host is up. This is useful if you are monitoring printers or other devices that are frequently turned off. The maximum amount of time that the notification command can run is controlled by the host_check_timeout option.

max_check_attempts:

This directive is used to define the number of times that Nagios will retry the host check command if it returns any state other than an OK state. Setting this value to 1 will cause Nagios to generate an alert without retrying the host check again. Note: If you do not want to check the status of the host, you must still set this to a minimum value of 1. To bypass the host check, just leave the check_command option blank.

notification_interval:

This directive is used to define the number of "time units" to wait before re-notifying a contact that this server is still down or unreachable. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will not re-notify contacts about problems for this host - only one problem notification will be sent out.

notification_period:

This directive is used to specify the short name of the time period during which notifications of events for this host can be sent out to contacts. If a host goes down, becomes unreachable, or recoveries during a time which is not covered by the time period, no notifications will be sent out.

notifications_options:

This directive is used to determine when notifications for the host should be sent out. Valid options are a combination of one or more of the following: d = send notifications on a DOWN state, u = send notifications on an UNREACHABLE state, and r = send notifications on recoveries (OK state). If you specify n (none) as an option, no host notifications will be sent out. Example: If you specify d,r in this field, notifications will only be sent out when the host goes DOWN and when it recovers from a DOWN state.

The script:

#!/usr/bin/perl

#Implemented by Vidar Grønland and Tarjei Westrum, year: spring 2003 at #Høgskolen i Gjøvik

#hosts.cfg is a file used by Nagios to define hosts in the network

#The ide behind this script, is to create or delete hosts in the Nagois configuration file #(hosts.cfg),

#each time a new host is added or removed from the network

print `rm -f hosts.txt`; #If the file hosts.txt exists, delete it

$date = `date`; #The date the script was executed

open(OUTFILE, ">>hosts.cfg") || "Error, unable to write to file (hosts.cfg)\n"; #Write the result to the file hosts.cfg

#*********************Making hosts.cfg***********************************************

print OUTFILE"################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: $date#

##################################################################################

##################################################################################

# HOST DEFINITIONS

#

# SYNTAX:

#

##################################################################################

# Generic host definition template

define host{

name generic-host ; The name of this host template - referenced

in other host definitions, used for template recursion/resolution

notifications_enabled 1 ; Host notifications are enabled

event_handler_enabled 1 ; Host event handler is enabled

flap_detection_enabled 1 ; Flap detection is enabled

process_perf_data 1 ; Process performance data

retain_status_information 1 ; Retain status information across program restarts

retain_nonstatus_information 1 ; Retain non-status information across program

restarts

register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL

HOST, JUST A TEMPLATE!

}

# 'linux1' host definition

define host{

use generic-host ; Name of host template to use

host_name tjener

alias Filserver

address 10.0.2.2

check_command check-host-alive

max_check_attempts 10

notification_interval 60

notification_period 24x7

notification_options d,u,r

}

# 'linux2' host definition

define host{

use generic-host ; Name of host template to use

host_name firewall

alias Brannmur

address 10.0.2.1

parents tjener

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

";

#If the file hoster.txt exists, open it

open(INFILE, "<hoster.txt") || die "Error, unable to open pingscriptFS.pl\n";

$n = 2;

$r = 0;

while(<INFILE>) { #While the file is not empty, do the following:

chomp;

#Splits the content of each line in hoster.txt

#with period (.), and puts it in variables

($a, $b, $c, $d, $e, $f, $g, $h, $i, $j) = split (/\./, $_, 10);

$hostname = "$e";

$hostip = "$a.$b.$c.$d";

$n++;

$r++; #Variable that counts up the alias of a host.The

#alias should be given names,

#not numbers, but our code do not suport this (due

#to lack of time)

if ($a != "192") { #Rule out LTSP-clients!

print OUTFILE "\n# 'linux$n' host definition\n";

print OUTFILE "define host{\n";

print OUTFILE "\tuse generic-host; Name of host template to use\n";

print OUTFILE "\thost_name $hostname\n";

print OUTFILE "\talias $r\n";

print OUTFILE "\taddress $hostip\n";

print OUTFILE "\tparents tjener\n";

print OUTFILE "\tcheck_command check-host-alive\n";

print OUTFILE "\tmax_check_attempts 10\n";

print OUTFILE "\tnotification_interval 120\n";

print OUTFILE "\tnotification_period 24x7\n";

print OUTFILE "\tnotification_options d,u,r\n";

print OUTFILE "\t}\n";

}

}

close(INFILE);

close(OUTFILE);

autoconfig_nagios.pl

This script is executed on the fileserver

This script is the only script the user has to execute. It will run all the necessary scripts on the fileserver in the correct order. All configuration files is copies to the catalogue Nagios uses for these kind of files. At the end of the script it reloads Nagios with its new configuration files.

The script:

#!/usr/bin/perl

#

#Made by Tarjei Westrum and Vidar Grønland at HiG 2003.

#This script is written to simplify the execution of several

#scripts into just one command (perl autoconf_nagios.pl

#

print `perl pingscriptFS.pl`; #Runs the script pingscriptFS.pl which pings all the hosts on the 10.0.0.0 net

print `perl tks_fs.pl`; #Merges the resultfiles hosterTKSxxx.txt and hosterFS.txt into one file named hoster.txt

print `perl hosts.pl`; #Makes the file hosts.cfg based on the info from hoster.txt

print `perl hostgroups_services.pl`; #Makes the files hostgroups.cfg and services.cfg

print `rm *.txt`; #Deletes all .txt files from the disk

print `cp *.cfg /usr/local/nagios/etc/`; #Moves all of the .cfg files to /usr/local/nagios/etc/ catalogue

print `rm *.cfg`; #Deletes all .cfg files in the catalogue you stand in now

print `/etc/init.d/./nagios reload`; #Reloads Nagios with the new .cfg files

Appendiks E4

User manual Nagios

Start the browser (Opera or Konquer) and write the following URL in the browser:

http://localhost/nagios/

Then the authentication window should come up on the screen. Write this as username and password:

Username: nagios

Password: xxxx

Figure 1. Log in to Nagios (Authentication)

This is the first picture after the authentication. This is a welcome message to users of Nagios. The site contains information about Nagios and some links to documentation and different things that has been added since the previous version and information about updates

Figure 2.First picture after authentication.

Documentation

Under this link it is a manual about nagios in electronic format, with links to differnet chapters. This is the first picture you can see after you have clicked on the link documentation.

Figure 3.Nagios documentation in electronic format.

Tactical Overview

The column at the left side, show you all possible links to different picture of the system. It show statistics about all hosts, services and network at the system. In this case it shows that it is monitored 6 hosts, and every one of them is OK. Under services we can see that it is 1 critical alert and 2 alerts which are unknown.

Each problem has a link to the specific host(s)/service(s) which has a problem.

Figure 4.Nagios Tactical Overview.

Service detail

Service detail gives information about different services which is running at a specific host. At the LTSP server (dhcp-000), we have 4 services. This is services for checking disk space on disks, check if the host is alive and system load. The status column displays the status of a service, which can be OK, WARNING or CRITICAL. You can also see the last check of the service, how long the service has been running and information about the specific service. Attempt shows how many times Nagios have checked the critical or warning state. It tests for three times before it sends mail about the fault.

Figure 5. Service Detail.

Host detail

Host detail gives an overview over hosts which being monitored at the system. It displays also the state of each host (UP, DOWN or PENDING). Status information has information about packages which have been lost after running the ping command. If all is OK you should see a text like this: PING OK – Packet loss=0%

Figure 6. Host detail.

Status overview

It is a summary for all hosts in different host groups. Each group have their own name and give information about the hosts in the group. This example is in 3 sections (Arbeidsstasjoner, Intern nett and Tynnklienter). Each host and service has a link to more information about the fault. In this case there are 2 unknown services at host dhcp-000 and 1 critical service at tjener.

Figure 7.Status Overview

Status grid

Status grid is more specified by the faults than the previous Status overview. Here it gives you information of which service that has a unknown, warning or critical state, and on which host that has this fault. Also here, the hosts are representing in sections of host groups.

Figure 8.Status grid.

Service problems

Here can you look at the different services which have failed, and what error message Nagios have generated. This you will find in the last column, under status information and you can see when the service was last checked, and how long the host have been running.

Figure 9.Service Problems

Host problems

This window show you which host that is DOWN or UNREACHABLE. In this example there are empty in the host problems window, but if there had been a fault on a machine, it will have been shown here.

Figure 10.Host Problems

Network outages

This window will produce a listing of "problem" hosts on your network that are causing network outages. This can be particularly useful if you have a large network and want to quickly identify the source of the problem. Hosts are sorted based on the severity of the outage they are causing.

Figure 11.Network outages.

Comments

Comments are a field where the administrator can add some comments to different hosts or services at the system, which have been done some work at. This will make it easier to find out what have been done the last time it was a similar fault.

Figure 12.Comments.

Downtime

Here the administrator can plan downtime of the system because of necessary maintenance or an upgrade. That avoid the system to give alerts when operations like this is going on. When the period is over, Nagios will delete the note which has been set and work as normal.

Figure 13.Downtime.

Process info

Status for all processes can be found here. In the table to the left we can see when the program was started, total time Nagios has been running and when last external command was checked. At the table to the right is an overview of which states processes could be. At the bottom of the page it will display the process status, like in this case is OK.

Figure 14.Process Info.

Performance info

This page displays information about different checks which have been executed. The pages are in two parts, one for active checks and one for passive checks. If you look at passive checks you can see the percentages of checks in last minute, five minute etc. To the right you can see how long each check has been executed.

Figure 15. "Performance Info"

Scheduling queue

It shows when next check will be executed and on which host. You can also see when the last check was executed on several hosts. It is only active checks that are enabled, and checks will be executed in specific periods, i.e. every 5 minutes.

Figure 16. "Scheduling Queue"

Reporting

Under the category reporting, you can find some useful information. Every links here can give you a specific report on what you want to be reported. You only choose which host or service you will have a report on, and this can be viewed at a monitor, write to a file or get a printout. One example of a report could be the Alert histogram, and it look like this: (Step1 - Step 3):

Figur 17. "Reporting"

Figur 18. "Reporting"

Figur 19. "Reporting"

At the end you can klick ”Create Report” and it will be created a report like that you specified.

Appendix E5

Dynamiske cfg filer

command.cfg: (generated by pingscriptTKS.pl)

# Plugin Configuration for netsaint.

#

# Ben Bell <bjb.org> 20/11/01

#

# Debian doesn't use this file by default. Instead, the command definitions

# for have been split into seperate files in /usr/share/netsaint/pluginconfig

# and are automatically merged into /etc/netsaint/plugins-auto.cfg by

# update-netsaint(8)

# The original upstream version of this file can be found in

# /usr/share/doc/netsaint-plugins/examples

#

# Feel free to add local plugin definitions to this file.

#

command[check_disk1]=/usr/lib/netsaint/plugins/check_disk -w 10% -c 5% -p /dev/hda1

command[check_disk2]=/usr/lib/netsaint/plugins/check_disk -w 10% -c 5% -p /dev/hda5

command[check_load]=/usr/lib/netsaint/plugins/check_load -w 15,10,5 -c 30,25,20

command[check_smtp]=/usr/lib/netsaint/plugins/check_smtp -H localhost

command[check_dead]=/usr/lib/netsaint/plugins/check_dead -w 1 -c 2 -r 192.168.0.10:192.168.0.11

command[check_swap]=/usr/lib/netsaint/plugins/check_swap -w 10% -c 20%

hostgroups.cfg: (generated by hostgroups.pl)

################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: Mon May 5 19:31:36 CEST 2003

#

################################################################################

################################################################################

# HOST GROUP DEFINITIONS

#

# SYNTAX:

#

################################################################################

# 'linux-boxes' host group definition

define hostgroup{

hostgroup_name tynnklientservere

alias Intern nett

contact_groups nagios

members dhcp-000,dhcp-006

}

define hostgroup{

hostgroup_name arbeidsstasjoner

alias Arbeidsstasjoner

contact_groups nagios

members dhcp-001

}

hosts.cfg (generated by hosts.pl)

##################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: Mon May 5 19:31:36 CEST 2003

#

##################################################################################

##################################################################################

# HOST DEFINITIONS

#

# SYNTAX:

#

##################################################################################

# Generic host definition template

define host{

name generic-host ; The name of this host template - referenced

in other host definitions, used for template

recursion/resolution

notifications_enabled 1 ; Host notifications are enabled

event_handler_enabled 1 ; Host event handler is enabled

flap_detection_enabled 1 ; Flap detection is enabled

process_perf_data 1 ; Process performance data

retain_status_information 1 ; Retain status information across program restarts

retain_nonstatus_information 1 ; Retain non-status information across program

restarts

register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL

HOST, JUST A TEMPLATE!

}

# 'linux1' host definition

define host{

use generic-host ; Name of host template to use

host_name tjener

alias Filserver

address 10.0.2.2

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

# 'linux2' host definition

define host{

use generic-host ; Name of host template to use

host_name firewall

alias Brannmur

address 10.0.2.1

parents tjener

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

# 'linux3' host definition

define host{

use generic-host ; Name of host template to use

host_name dhcp-006

alias 1

address 10.0.2.106

parents tjener

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

# 'linux4' host definition

define host{

use generic-host ; Name of host template to use

host_name dhcp-000

alias 2

address 10.0.2.100

parents tjener

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

# 'linux5' host definition

define host{

use generic-host ; Name of host template to use

host_name dhcp-001

alias 3

address 10.0.2.101

parents tjener

check_command check-host-alive

max_check_attempts 10

notification_interval 120

notification_period 24x7

notification_options d,u,r

}

Appendiks E6

Statiske cfg filer

cgi.cfg

#################################################################

#

# CGI.CFG - Sample CGI Configuration File for Nagios 1.0

#

# Last Modified: 10-29-2002

#

#################################################################

# MAIN CONFIGURATION FILE

# This tells the CGIs where to find your main configuration file.

# The CGIs will read the main and host config files for any other

# data they might need.

main_config_file=/usr/local/nagios/etc/nagios.cfg

physical_html_path=/usr/local/nagios/share

url_html_path=/nagios

show_context_help=0

/usr/local/nagios/var/status.log 5 '/usr/local/nagios/bin/nagios'

use_authentication=1

#default_user_name=guest

authorized_for_system_information=nagios

authorized_for_configuration_information=nagios

authorized_for_system_commands=nagios

authorized_for_all_services=nagios

authorized_for_all_hosts=nagios

authorized_for_all_service_commands=nagios

authorized_for_all_host_commands=nagios

#hostextinfo[es-eds]=/serverinfo/es-eds.html;novell40.gif;novell40.jpg;novell40.gd2;IntranetWare 4.11;100,50;3.5,0.0,-1.5;

#hostextinfo[rosie]=/serverinfo/rosie.html;win40.gif;win40.jpg;win40.gd2;NT Server 4.0;;;

#serviceextinfo[es-eds;PING]=http://www.somewhere.com?tracerouteto=$HOSTADDRESS$;;PING rate

#serviceextinfo[rosie;Security Alerts]=;security.gif;Security alerts

#statusmap_background_image=smbackground.gd2

default_statusmap_layout=5

default_statuswrl_layout=4

#statuswrl_include=myworld.wrl

ping_syntax=/bin/ping -n -U -c 5 $HOSTADDRESS$

refresh_rate=60

#host_unreachable_sound=hostdown.wav

#host_down_sound=hostdown.wav

#service_critical_sound=critical.wav

#service_warning_sound=warning.wav

#service_unknown_sound=warning.wav

#normal_sound=noproblem.wav

#xeddb_host=somehost

#xeddb_port=someport

#xeddb_database=somedatabase

#xeddb_username=someuser

#xeddb_password=somepassword

#xsddb_host=somehost

#xsddb_port=someport

#xsddb_database=somedatabase

#xsddb_username=someuser

#xsddb_password=somepassword

#xcddb_host=somehost

#xcddb_port=someport

#xcddb_database=somedatabase

#xcddb_username=someuser

#xcddb_password=somepassword

#xdddb_host=somehost

#xdddb_port=someport

#xdddb_database=somedatabase

#xdddb_username=someuser

#xdddb_password=somepassword

checkcommands.cfg

################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: 06-09-2002

#

################################################################################

################################################################################

# COMMAND DEFINITIONS

#

# SYNTAX:

#

# define command{

# template <templatename>

# name <objectname>

# command_name <commandname>

# command_line <commandline>

# }

#

# WHERE:

#

# <templatename> = object name of another command definition that should be

# used as a template for this definition (optional)

# <objectname> = object name of command definition, referenced by other

# command definitions that use it as a template (optional)

# <commandname> = name of the command, as recognized/used by Nagios

# <commandline> = command line

#

################################################################################

################################################################################

#

# SAMPLE SERVICE CHECK COMMANDS

#

# These are some example service check commands. They may or may not work on

# your system, as they must be modified for your plugins. See the HTML

# documentation on the plugins for examples of how to configure command definitions.

#

################################################################################

# 'check_tcp' command definition

define command{

command_name check_tcp

command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$

}

# 'check_tcp' command definition

define command{

command_name check_swap

command_line $USER1$/check_swap -w $ARG1$ -c $ARG2$

}

# 'check_udp' command definition

define command{

command_name check_udp

command_line $USER1$/check_udp -H $HOSTADDRESS$ -p $ARG1$

}

# 'check_ftp' command definition

define command{

command_name check_ftp

command_line $USER1$/check_ftp -H $HOSTADDRESS$

}

# 'check_pop' command definition

define command{

command_name check_pop

command_line $USER1$/check_pop -H $HOSTADDRESS$

}

# 'check_smtp' command definition

define command{

command_name check_smtp

command_line $USER1$/check_smtp -H $HOSTADDRESS$

}

# 'check_nntp' command definition

define command{

command_name check_nntp

command_line $USER1$/check_nntp -H $HOSTADDRESS$

}

# 'check_http' command definition

define command{

command_name check_http

command_line $USER1$/check_http -H $HOSTADDRESS$

}

# 'check_telnet' command definition

define command{

command_name check_telnet

command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 23

}

# 'check_ping' command definition

define command{

command_name check_ping

command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5

}

# 'check_dns' command definition

define command{

command_name check_dns

command_line $USER1$/check_dns -H www.yahoo.com -s $HOSTADDRESS$

}

# 'check_hpjd' command definition

define command{

command_name check_hpjd

command_line $USER1$/check_hpjd -H $HOSTADDRESS$ -C public

}

# 'check_local_disk' command definition

define command{

command_name check_local_disk

command_line $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$

}

# 'check_local_users' command definition

define command{

command_name check_local_users

command_line $USER1$/check_users -w $ARG1$ -c $ARG2$

}

# 'check_local_procs' command definition

define command{

command_name check_local_procs

command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$

# 'check_local_load' command definition

define command{

command_name check_local_load

command_line $USER1$/check_load -w $ARG1$ -c $ARG2$

}

# 'check_nrpe' command definition

define command{

command_name check_nrpe

command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

}

################################################################################

#

# SAMPLE HOST CHECK COMMANDS

#

################################################################################

# This command checks to see if a host is "alive" by pinging it

# The check must result in a 100% packet loss or 5 second (5000ms) round trip

# average time to produce a critical error.

# Note: Only one ICMP echo packet is sent (determined by the '-p 1' argument)

# 'check-host-alive' command definition

define command{

command_name check-host-alive

command_line $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 1

}

contactgroups.cfg

###############################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: 10-03-2002

#

################################################################################

################################################################################

# CONTACT GROUP DEFINITIONS

#

# SYNTAX:

#

################################################################################

# 'linux-admins' contact group definition

define contactgroup{

contactgroup_name nagios

alias Nagios Admin

members nagios-admin

}

contacts.cfg

################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: 03-07-2002

#

################################################################################

################################################################################

# CONTACT DEFINITIONS

#

# SYNTAX:

#

################################################################################

# 'nagios' contact definition

define contact{

contact_name nagios-admin

alias Nagios boss

service_notification_period 24x7

host_notification_period 24x7

service_notification_options w,u,c,r

host_notification_options d,u,r

service_notification_commands notify-by-email

host_notification_commands host-notify-by-email

email nagios-admin@localhost

}

timeperiods.cfg

Not edited

dependencies.cfg

Not edited

escalations.cfg

Not edited

misccommands.cfg

Not edited

resource.cfg

Not edited

nagios.cfg

##############################################################################

#

# NAGIOS.CFG - Sample Main Config File for Nagios 1.0

#

# Read the documentation for more information on this configuration

# file. I've provided some comments here, but things may not be so

# clear without further explanation.

#

# Last Modified: 07-04-2002

#

##############################################################################

log_file=/usr/local/nagios/var/nagios.log

cfg_file=/usr/local/nagios/etc/checkcommands.cfg

cfg_file=/usr/local/nagios/etc/misccommands.cfg

cfg_file=/usr/local/nagios/etc/contactgroups.cfg

cfg_file=/usr/local/nagios/etc/contacts.cfg

cfg_file=/usr/local/nagios/etc/dependencies.cfg

cfg_file=/usr/local/nagios/etc/escalations.cfg

cfg_file=/usr/local/nagios/etc/hostgroups.cfg

cfg_file=/usr/local/nagios/etc/hosts.cfg

cfg_file=/usr/local/nagios/etc/services.cfg

cfg_file=/usr/local/nagios/etc/timeperiods.cfg

resource_file=/usr/local/nagios/etc/resource.cfg

status_file=/usr/local/nagios/var/status.log

nagios_user=nagios

nagios_group=nagios

check_external_commands=1

#command_check_interval=1

#command_check_interval=15s

command_check_interval=-1

command_file=/usr/local/nagios/var/rw/nagios.cmd

comment_file=/usr/local/nagios/var/comment.log

downtime_file=/usr/local/nagios/var/downtime.log

lock_file=/usr/local/nagios/var/nagios.lock

temp_file=/usr/local/nagios/var/nagios.tmp

log_rotation_method=d

log_archive_path=/usr/local/nagios/var/archives

use_syslog=1

log_notifications=1

log_service_retries=1

log_host_retries=1

log_event_handlers=1

log_initial_states=0

log_external_commands=1

log_passive_service_checks=1

#global_host_event_handler=somecommand

#global_service_event_handler=somecommand

inter_check_delay_method=s

service_interleave_factor=s

max_concurrent_checks=0

service_reaper_frequency=10

sleep_time=1

service_check_timeout=60

host_check_timeout=30

event_handler_timeout=30

notification_timeout=30

ocsp_timeout=5

perfdata_timeout=5

retain_state_information=1

variable is set to 1.

state_retention_file=/usr/local/nagios/var/status.sav

retention_update_interval=60

use_retained_program_state=0

interval_length=60

use_agressive_host_checking=0

execute_service_checks=1

accept_passive_service_checks=1

enable_notifications=1

enable_event_handlers=1

process_performance_data=0

#host_perfdata_command=process-host-perfdata

#service_perfdata_command=process-service-perfdata

obsess_over_services=0

#ocsp_command=somecommand

check_for_orphaned_services=0

check_service_freshness=1

freshness_check_interval=20

aggregate_status_updates=1

status_update_interval=15

enable_flap_detection=0

low_service_flap_threshold=5.0

high_service_flap_threshold=20.0

low_host_flap_threshold=5.0

high_host_flap_threshold=20.0

date_format=euro

illegal_object_name_chars=`~!$%^&*|'"<>?,()=

illegal_macro_output_chars=`~$&|'"<>

admin_email=nagios

admin_pager=pagenagios

services.cfg

################################################################################

# Sample object config file for Nagios 1.0

#

# Read the documentation for more information on this configuration file. I've

# provided some comments here, but things may not be so clear without further

# explanation, so make sure to read the HTML documentation!

#

# Last Modified: Mon May 5 19:31:36 CEST 2003

#

################################################################################

################################################################################

# SERVICE DEFINITIONS

#

# SYNTAX:

#

################################################################################

# Generic service definition template

define service{

name generic-service ; The 'name' of this service template,

referenced in other service definitions

active_checks_enabled 1 ; Active service checks are enabled

passive_checks_enabled 1 ; Passive service checks are enabled/accepted

parallelize_check 1 ; Active service checks should be parallelized

(disabling this can lead to major performance

problems)

obsess_over_service 1 ; We should obsess over this service (if necessary)

check_freshness 0 ; Default is to NOT check service 'freshness'

notifications_enabled 1 ; Service notifications are enabled

event_handler_enabled 1 ; Service event handler is enabled

flap_detection_enabled 1 ; Flap detection is enabled

process_perf_data 1 ; Process performance data

retain_status_information 1 ; Retain status information across program restarts

retain_nonstatus_information 1 ; Retain non-status information across program restarts

register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL

SERVICE, JUST A TEMPLATE!

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name firewall

service_description PING

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_ping!100.0,20%!500.0,60%

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description HTTP

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options w,u,c,r

check_command check_http

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description SMTP

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options w,u,c,r

check_command check_smtp

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description DNS

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options w,u,c,r

check_command check_dns

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description FileServer Free Diskspace /hda1

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_local_disk!10%!5%!/dev/hda1

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description FileServer Free Diskspace /hda5

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_local_disk!10%!5%!/dev/hda5

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description FileServer Free Diskspace /hda7

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_local_disk!10%!5%!/dev/hda7

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description FileServer Free Diskspace /hda9

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_local_disk!10%!5%!/dev/hda9

}

# Service definition

define service{

use generic-service ; Name of service template to use

host_name tjener

service_description FileServer System-Load

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_local_load!8.50,8.25,8.00!10.00,9.50,9.00

}

define service{

host_name tjener

service_description FileServer SwapSpace

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_swap!75%!90%

}

# Service definition

define service{

use generic-service ; Name of service template to use

hostgroup_name arbeidsstasjoner

service_description PING

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_ping!100.0,20%!500.0,60%

}

define service{

hostgroup_name tynnklientservere

service_description LTSP-server Free Diskspace /hda1

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_disk1

}

define service{

hostgroup_name tynnklientservere

service_description LTSP-server Free Diskspace /hda5

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_disk2

}

define service{

hostgroup_name tynnklientservere

service_description LTSP-server System-Load

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_load

}

define service{

hostgroup_name tynnklientservere

service_description LTSP-clients status

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_dead

}

define service{

hostgroup_name tynnklientservere

service_description LTSP-server SwapSpace

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups nagios

notification_interval 120

notification_period 24x7

notification_options c,u,r

check_command check_nrpe!check_swap

}

Appendiks F1

Test 1

Test 2

Appendiks G1

Ukereferater

GRUPPE 7

Møtereferat: 1

Dato: Mandag 13.01.03

Tid: 10.00-14.00

Sted: Holumskogen Barneskole i Nittedal

Til stede:

Gruppe7: Tarjei Westrum, Sven Are Finnevolden, Vidar Grønnland og

Ragnar Haugland

Veileder: Erik Hjelmås

Sjåfør: Tom Audun Seljeflot

Skolelinux: Knut Yrvin og Frode Jemtland

Data ansvarlig Bibliotekar: Marit

Fikk invitasjon fra Knut og Frode om å komme en dag til Holumskogen Barneskole, for å se hvordan Skole Linux fungerer i praksis.

Ble introdusert med Skole Linux i dens omgivelser, hvordan nettstrukturen skulle se ut og hva slags maskin kapasitet som kreves av en serverpark for å få alt opp å gå. Deretter hadde vi et langt foredrag fra Knut Yrvin om hvordan Skole Linux konseptet er bygd opp og hvordan utviklingen foregår på frivillig basis (dugnad). Fikk også en kort introduksjon fra Bibliotekaren Marit om pedagogisk programvare og erfaringer hun hadde om og rundt prosjektet. Ettersom dette er et prosjekt som i førsteomgang ser ut til å rette seg mot de lavere alderstrinn i skolen (Barne og Ungdomskole)

Fikk ikke helt alt på plass ang. oppgave beskrivelse, men regner med å ha det på plass til neste uke.

Ble oppfordret til å møte på et Skole Linux utvikling seminar 31. jan-2. februar, og melde oss på maillista for Skolelinux. (muligheter for å stille spørsmål og få svar av alle..)

Vår oppdragsgiver for prosjektet ble Frode Jemtland.

Ref1 16.01.03 RH

GRUPPE 7

Møtereferat: 2

Dato: Mandag 27.01.03

Tid: 10.00-11.00

Sted: Grupperom A113

Til stede: Tarjei Westrum, Sven Are Finnevolden, Vidar Grønnland og

Ragnar Haugland

Ny uke, nettverket er nesten oppe og går etter litt trøbbling for å komme oss gjennom firewallen/routeren. Da dette gikk i orden viser det seg at kommunikasjonen mellom tynnklientteneren og tynnklientene ikke er helt i orden, planen er at dette skal være på K innen vi reiser til Oslo til helga.

Agendaen for uka, i tillegg til å få nettet på topp er å sette seg inn seg inn i å analysere, eksisterende programvare. Tarjei har fått lastet ned programvare etter tips fra en svoger i Forsvaret (netsaint.org). Programvare de bruker til lignende oppgaver under overvåkning. Ser at forrige ukes agenda ha r blitt litt forskyvet pga. plunder med Nettverksoppsettet. Vi subnettet ut fra egne ip-adresser, noe ikke Skolelinux oppsettet taklet, pga. ferdige konfigurasjoner. Har bestemt at uke referatene skal legges ut på web fortløpende. To av oss(Vidar og Ragnar) reiser til Ulsrud Vgs. i Oslo på lørdag, for å delta i Skolelinux utviklersamling, har vel ikke all verdens å bidra med foreløpig, men håper det blir lærerikt og spennende.

Ref.2. 28.01.03 RH

GRUPPE 7

Møtereferat: 3

Dato: Mandag 03.02.03

Tid:10.00-11.00

Sted: Grupperom A113

Til stede: Tarjei Westrum, Sven Are Finnevolden, Vidar Grønnland og

Ragnar Haugland

Ny uke, nettverket er oppe går!! Problemene har vært at Ltsp oppstart har vært feil, måtte også konfigurere lts.conf. Da vårt skjermkort (gammelt S-3 kort) ikke er støttet av xserver-Xfree86, implementerte derfor (ltsp_core-3.0.4) x-kjernen og byttet ut ”auto” med ”ltsp_x336_s3” lts.conf.

” Utdrag av fila lts.conf.

// Endring [ltsp-010] (ws001)

// Endring XSERVER = ltsp_x336_s3 (auto)

// Ingen endr. X_MOUSE_PROTOCOL = "Microsoft"

// Ingen endr. X_MOUSE_DEVICE = "/dev/ttyS1"

// Ingen endr. X_MOUSE_RESOLUTION = 50

// Ingen endr. X_MOUSE_BUTTONS = 3

// Ingen endr. X_MOUSE_BAUD = 1200

Vidar og Ragnar var på Utviklingsseminar på Ulsrud vgs. helga (31-2 feb.) i regi av Skolelinux. Meget interessant, fikk intro i bruk av CVS og klarlagt mer rundt oppgaven vi skal jobbe med. Viser seg også at en annen gruppe ved NITH skal jobbe med samme oppgave som oss. Er ikke helt klarlagt om vi skal kjøre to uavhengige prosjekter eller om vi prøver oss på en parallell jobbing med Dem, da emnet egentlig er vanvittig stort. Begge grupper, HIG og NITH skal nå kjøre en behovsanalyse for å kartlegge hva som er ønsket og reelt for Skolelinux i dens omgivelser. Planen er deretter å opprette kontakt med disse for å klarlegge eventuelle fordelinger.

Felles er det bestemt at vi jobber med utgangspunkt i freeware programmet Nagios [15]. Nagios er en nyere utgave av programmet vi tidligere har sett på, nemlig Netsaint. Behovsanalyse samt analyse av Nagios er dermed neste ukes agenda. Samt starte med kravspesifikasjonen.

Ref.3. 04.02.03 RH

Gruppe 7

Møtereferat 4-5

Dato : 18.02.03/13.02.03

Tid:

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden og

Ragnar Haugland

Veileder: Erik Hjelmås

Drifter hos Opera Norge: Jonny Birkelund

*Godkjenning av forrige ukereferat - -> ok

Gruppa hadde møte med Jonny Birkelund fra Opera, angående overvåkningssystemet Bigbrother i forbindelse med brukeranalyse og erfaringer rundt bruken av Bigbrother.

Ellers har de siste ukene gått med til å jobbe med kravspesifikasjon og forberedelse til foredrag i Stavanger først kommende helg.

Tarjei, Vidar og Ragnar reiser til Time Kommune på Jæren.

Agenda for videre jobbing er at gruppen deler seg i to, Tarjei og Vidar, tar seg av utforskning av programmet Nagios, mens Ragnar og Sven Are tar for seg Bigbrother.

Håpet er å få til et møte med Bigbrother ansvarlig hos Opera og Nagios ansvarlig i Forsvaret ved Kolsås leir.

Frist for avklaring av hvilket verktøy vi bruker er satt til 1.mars

Ellers er parallell jobbing med kravspesifikasjon, på Agendaen.

Ref4-5 18.02.03 RH

GRUPPE 7

Møte referat: 6

Dato: Mandag 24.02.2003

Tid: 13.00-13.30

Sted: A113

Tilstede: Vidar Grønland, Tarjei Westrum, Ragnar Haugland, Sven Are

Finnevolden

· Ukens tema er å finne ut hvilket overvåkningssystem vi skal bruke. I nåværende situasjon så holdes det en knapp på Nagios istedenfor BigBrother. BigBrother har en håpløs lisens, samtidig som Nagios ligger som egen installerbar debian-pakke på internett. Derfor anser vi at vi kommer til å bruke Nagios, noe vi også fikk støtte fra Sverre Stoltenberg i Opera.

· Sette seg inn i installasjonsmanualen til Nagios og systemet generelt.

· Avtale møte med Jon Magnus Dullerud i Forsvaret (Kolsås). Rette spørsmål angående Nagios og hvilke muligheter den har.

Ref6 24.02.03 RH

GRUPPE 7

Møte referat: 7

Dato: Mandag 03.03.2003

Tid: 13.00-13.30

Sted: A113

Tilstede: Vidar Grønland, Tarjei Westrum, Ragnar Haugland,

Sven Are Finnevolden

Vi har brukt uka på å analysere eksisterende overvåkningsprogrammer ved å se på demoer og testet programmer. Dette for bedre å kunne dokumentere det valget vi gjør i forhold til valg av overvåkningssystem.

Har startet installasjon av Nagios, og vil fortsette med dette til den fungerer skikkelig.

Ref7: 03.03.03 VG

Gruppe 7

Møtereferat 8

Dato: 10.03.03

Tid:11.30-12.00

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden og

Ragnar Haugland

Uken har gått med til videre installasjon av Nagios, har hatt en del trøbbel med oppsettet i forhold til web-server som har ført til en del lengre tid enn beregnet. Har også begynt å se på plugins i forhold til behovsanalyse.

Neste uke satser vi på et møte med Oslo gruppa, samt reinstallere labben til vers.37 av Skolelinux. Og parallell jobbing med prosjekt rapporten.

Ref8 10.03.03 RH

Gruppe 7

Møterefarat 9

Dato: 17.03.03

Tid: 10.30-11.00

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden og

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Gruppa jobbet med nagiois, leste dokumentasjon og installererte plugins, samt at vi avtalte, forberedte oss til og arrangerte møte med Oslo gruppa som jobber med samme oppgave som oss. Møte ble avholdt ved Høgskolen i Gjøvik på torsdag og det kom 6 studenter fra NITH på besøk. Møte gikk i sin helhet ut på å avklare hvordan vi skal klare å dele opp oppgaven slik at vi i fellesskap skal få til et komplett produkt. Ettersom oppgaven er relativt stor, har vi klart å komme til en grei fordeling slik at vi ikke jobber med de samme problemene

Neste ukes holdepunkter er fordelt som følger:

- Reinstallere hele test labben til nyeste versjon av skolelinux vers. 37

- Installere Nagios fra grunnen av og dokumenter hvert skritt.

- Ferdigstille kapittel 1 i Rapporten.

Ref9 17.03.03 RH

Gruppe 7

Møterefarat 10

Dato: 24.03.03

Tid: 11.30-12.00

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Det vi kom frem til var at vi burde begrense systemet mest mulig, og få det vi lager til å fungere. De verktøyene vi benytter er “open source”, noe som gjør at det er lett for andre å gjøre endringer og utvide systemet senere. Vi har jobbet med å finne en løsning på å automatisere konfigurering av Nagios mhp DHCP.

Vi er avhengige av å ha en automatisert konfigurering av maskiner når de blir koblet til, men vi må også finne en sikker løsning som ser forskjell på om en maskin er koblet fra eller bare er skrudd av.

I slutten av forrige uke satte vi i gang reinstallasjon av hele systemet for å få den nyeste versjonen av Skolelinux. Vi ville også reinstallere Nagios for å få dokumentert bedre.

Denne uken er det satt opp følgende plan:

Mandag: Nagios skal fungere i løpet av dagen

Kap 1 på rapporten + møtereferat

Tirsdag: Nagios

Kap 1 og 2 på rapporten

Onsdag: Automatisering av Nagios

Kap 2 på rapporten

Torsdag: Automatisering av Nagios

DHCP problemet

Fredag: Automatisering av Nagios

DHCP problemet

Ref10 24.03.03 VG

Gruppe 7

Møterefarat 11

Dato: 01.04.03

Tid: 11.30-12.00

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Vi har blitt enige om at vi skal prøve å få en liten del av systemet til å fungere ordentlig, før vi tar oss av resten. Vi vil derfor avgrense oppgaven ytterligere da vi begynner å få knapt med tid igjen. Hovedprioriteten er nå å få automatisert installasjonen av Nagios, og å få konfigurert tynnklientene automatisk inn i Nagios sine konfigurasjonsfiler. Ragnar og Vidar vil se på muligheten for å lage et script som finner ut hvor mange tynnklienter en tynnklientserver har. Sven Are og Tarjei vil se på Nagios installasjon.

Vi har brukt mye tid foregående uke på å få installert Nagios på en enklest mulig måte, men har hatt problemer med å få diverse bibliotek til å fungere. Dette har dessverre tatt opp mye av vår dyrebare tid.

Ref11 01.04.03 VG

Gruppe 7

Møterefarat 12

Dato: 07.04.03

Tid: 11.00-11.30

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

I forrige uke fikk vi beskjed av Erik Hjelmås om å gå tilbake på stabile tar.gz filer for nagois istedenfor ustabile deb pakker. Dette fordi ustabile deb pakker kan gjøre systemet ustabilt. Derfor har vi reinstallert filtjener og konfigurert nagios på nytt med tar.gz filer. Dette har ført til at vi har mindre tid enn vi hadde planlagt og medfører hard jobbing den siste uka før påske.

I løpet av uken skal vi ha et system som overvåker Filtjener, LTSP-tjener (disk, load, etc), overvåkning av tynnklientene og arbeidsstasjonene. Vi skal også utvikle script for å kunne legge inn maskiner i nagios konfigurasjonsfiler automatisk ved å finne ut hvor mange maskiner som er tilkoblet tynnklientnettet.

All dokumentasjon vi har til nå skal leveres til Erik Hjelmås i slutten av uka, for å få en tilbakemelding på hva vi trenger av dokumentasjon og hva vi kan ta bort. Derfor blir det også en del rapport skriving denne uka.

Programmering bør være ferdig i løpet av uka, men kan utsettes til første uka etter påske, som en absolutt siste frist. Noen vil også jobbe med prosjektet i påskeuka, dvs. dokumentasjon av hovedprosjektet.

Ref12 07.04.03 SAF

Gruppe 7

Møterefarat 13

Dato: 14.04.03

Tid: 11.00-11.30

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Gruppa har tatt seg en velfortjent påskeferie og har ladet batteriene for innspurten.

Fikk tilbakemelding fra Erik på hva vi skulle gjøre annerledes i dokumentasjonen, dvs. at vi starter opp for fullt med å skrive hovedkapittelet i Rapporten denne uken.

Samtidig gjenstår en del på å få automatisert overvåkningen, dette skal jobbes med utover. Helhetlig testing er også noe vi starter med i løpet denne og neste uke.

Ellers blir det en tur til Ulsrud Vgs. i Oslo på utvikler samling helga 25-27 april. Der det skal gåes igjennom hva de enkelte gruppene har gjort, for vårt vedkommende blir det en mini samling med Skolelinux og den andre HiG gruppen i slutten av mai, ettersom vi ikke er ferdige enda.

Scriptingen er i rute og fungerer sånn noenlunde, skal jobbes mer med den neste uken det også.

Ref13 14.04.03 RH

Gruppe 7

Møterefarat 14

Dato: 28.04.03

Tid: 11.00-11.30

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Dette blir siste uke med automatisering av Nagios og installasjonen. Samtidig som rapporten skal utformes og settes sammen. Rapporten skal inneholde de punktene som skal være med i en rapport i slutten av uka. Dette er helt i forhold til fremdriftsplanen, noe som er et mål for oss å følge. Alle på gruppa er innstilt på å jobbe hardt de neste ukene for å få ferdig en bra rapport. Vi skal også ha et møte med intern veileder tirsdag, for å høre hva vi mangler i våres rapport, og for å få synspunkter på det vi har skrevet.

Ref15 28.04.03 SAF

Gruppe 7

Møterefarat 15

Dato: 05.05.03

Tid: 11.00-11.30

Sted: Høgskolen i Gjøvik

Til Stede: Tarjei Westrum, Vidar A. Grønland, Sven Are Finnevolden,

Ragnar Haugland

*Godkjenning av forrige ukereferat - -> ok

Etter forrige, hvor vi hadde mål om å bli ferdig med programmeringen, kom ikke helt i mål. Derfor må vi forsette noen dager til denne uka her. Siste frist for dette har vi satt på tirsdag. Vi har nå begynt å sette sammen rapporten, og finpusser på enkelte kapitler. I tillegg utarbeides det brukermanualer og installasjonsmanualer på engelsk, siden dette var ønsket fra Skolelinux. Målet denne uka er å få ferdig prosjektrapporten til søndag, noe gruppa er innstilt på. Dette er noe i forkant av fremdriftsplanen våres, men dette gjøres for å få tid til å lese på en eksamen vi har den 15.mai. Innleveringen av hovedprosjektet skal skje den 19.mai innen kl. 12.00.

Dette medfører at vi også må bruke kvelder å arbeide på for å bli ferdig innen tidsfristen vi har satt oss.

Ref16 05.05.03 SAF

Appendiks G2

Statusrapporter

Statusrapport 1 (27.02.03)

Strategi:

Vi er snart ferdig med strategi delen, der vi skulle tilegne oss nødvendige kunnskaper og finne løsninger for å gi svar på problemstillingen.

Alle på gruppa er engasjert i å analysere eksiterende programvare for nettverks overvåkning.

For å tilegne oss disse kunnskapene har vi benyttet oss av Internet, skolelinux`s mail liste, Jonny Birkelund (Opera), Sverre Stoltenberg (Opera), Tor Erik Neuberg (Drifter en av Norges største maskinparker), Jon Magnus Dullerud (Forsvarets datasentral på Kolsås).

Vi vil enda fortsette en tid med analyse og vil starte opp med en egen rapport, som begrunner valget av programvare og hvilke forutsetninger/avgrensninger vi har gjort.

Kommende måned vil også inneholde installasjon, testing og videreutvikling av det programmet vi finner mest hensiktsmessig å benytte.

Organisering:

Vi har delt gruppa i to, for å effektivisere arbeidet rundt testing og analyse. Den ene gruppa jobber med analyserapporten, mens den andre gruppa installerer og tester. Til slutt vil det foreligge et felles møte der vi diskuterer oss frem til den applikasjonen som tilfredsstiller våre krav og ønsker.

Motivasjon:

Oppdragsgiveren vår (Skolelinux) er meget flinke til å få oss mest mulig inn i prosjektet. Vi har til nå vært på to utvikler seminarer som har gitt oss følelsen av at vi er med i ”gjengen”. Dette gir oss en god følelse av at det vi gjør er viktig. Problemet med Skolelinux er at det er mange personer å forholde seg til, samtidig som de har forskjellige ønsker og krav til prosjektet vårt. Dette medførte litt frustrasjon under utviklingen av kravspesifikasjonen. Vi fikk da problemer med å avgrense oppgaven ut i fra det vi trodde var realsistisk å få til, kontra det Skolelinux ville ha med. Men etter et møte med Jonny Birkelund (Opera), ble ting litt klarere. Han mente vi skulle avgrense det til et minimum, og heller gjøre litt ekstra hvis tiden skulle strekke til.

Motivasjonen er nå på tur opp, da vi ser en mulighet for å få gjennomført oppgaven på en tilfredsstillende måte.

Gruppa som helhet fungerer bra, men har forbedringspotensial når det gjelder punktlighet.

Hvordan ligger vi an i forhold til Gannt skjema:

Totalt sett ligger vi bra an i forhold til fastsatte punkter i Gannt-skjemaet, men ser at vi har begynt litt seinere enn planlagt under punktene innhenting av litteratur og forskning. Vi ligger ca 2 uker bak her, men det skyldes at vi har omprioritert punktet kravspekk. Slik at den er flyttet 2 uker tidligere enn planlagt. Vi brukte også litt lenger tid enn planlagt på oppsett av nettverk pga. problemer og mangel på hardware.

Forsinkelses faktorer:

Gruppen brukte en del tid på forberedelser til utvikler seminar i Stavanger, helgen

21-23 feb. Der gruppa hadde i oppgave å forelese i hva en firewall er/gjør og hvordan man setter opp en firewall på et Skolelinux nettverk. Forelesningen var i forbindelse med opplæring av 15 IT- ansatte i Time kommune på Jæren i regi av Skolelinux.

Statusrapport 2 (30.03.03)

Strategi:

Strategi delen går ut på å fortsette automatiserings programmeringen, samt gjøre klart dokumentasjons materiale for innlevering til veileder før påske.

Gruppa tar da en velfortjent ferie, for å lade opp batterier til innspurten.

Organisering:

Vi har fortsatt inndelingen av gruppen med noen omrokeringer for å få en jevn parallell jobbing. To jobber fortsatt med Nagios, automatisering og testing, mens de to resterende jobber dokumentasjon.

Motivasjon:

Begynner å se lyset i enden av tunnelen, så ting skjer litt raskere denne perioden, samtidig møtes gruppen en gang i uken for å sette klare mål, slik at hver enkelt kan prioritere å vite hva man skal gjøre til enhver tid. Noe som hjelper på motivasjonen innad i gruppa. Har også satt i gang med ”dead line” datoer slik at vi ser at ting faktisk skjer og hver enkelt har et individuelt press.

Et punkt vi på dette tidspunkt ser skulle vært gjort tidligere som en motivasjons faktor.

Motivasjonen er nå enda på tur opp, da vi ser en mulighet for å få gjennomført oppgaven på en tilfredsstillende måte.

Gruppa som helhet fungerer bra, men har fortsatt forbedringspotensial når det gjelder punktlighet, selv om det tapte taes igjen på kveldstid.

Hvordan ligger vi an i forhold til Gannt skjema:

Som nevnt i tidligere status rapport er det gjort omrokkeringer i Gannt , så totalt sett ligger vi bra an, men ser at små feil tar kort tid å lage og lenger tid å fikse. Samtidig har det kommet en ny versjon av Skolelinux v. 37 som vi var avhengig av å installere på vår test nettverk, for å holde tritt med Skolelinux utviklingen. En operasjon som tok en del av nattesøvnen i fra oss. Når det gjelder hovedtesting blir nok dett litt forskyvet i forhold til fastsatt plan.

Forsinkelses faktorer:

Har som sagt tidligere brukt en del tid på å installere en stabil versjon av Nagios, samt at Skolelinux cd 37 har kommet ut på test markedet, slik at vi måtte reinstallere test laben.

Statusrapport 3 (30.04.03)

Strategi:

Strategien denne måneden har vært å få dokumentert så mye som mulig. Automatiseringen av Nagios har også fortsatt denne måneden, noe vi skal være ferdig i begynnelsen av mai. Fra nå av blir det å få skrevet det vi har av dokumentasjon og organisert dette i forhold til den endelige prosjektrapporten.

Organisering:

Vi har delt gruppa i to og arbeider ut fra at to jobber med automatisering og to med dokumentasjon. Det byttes av og til slik at alle på gruppa får et innblikk av hva som skjer. Når automatiseringen er ferdig, vil alle på gruppa jobbe med rapport skrivingen. Dette tar litt tid, siden den skal organiseres etter en angitt mal. Siden det går mot slutten av prosjektet, må vi legge vekt på å skrive rapport og få den så bra som mulig.

Motivasjon:

Det begynner å gå mot slutten av prosjektperioden, og alle gjør sitt beste for å få til et bra helhetlig resultat. Gruppa har satt seg klare mål om hva som må gjøres, og når disse skal være utført. Det har oppstått noen små problemer med skriptene, siden vi hadde en klar tankegang på hvordan skriptene skulle være. Dette medførte noen forandringer i skriptene, noe som gjorde at gruppa fikk litt dårligere motivasjon. Men dette har bedret seg og vi er i full gang med innspurten. For å få alle til å jobbe maksimalt med prosjektet har vi satt opp oppgaver som hver enkelt skal gjøre innenfor en bestemt tidsfrist. Dette har ført til meget bra jobbing på gruppa. Motivasjonen er stigende med tanke på at vi snart er i mål med prosjektet som har gått over vårsemesteret, og at vi får et bra resultat.

Arbeidsmessig fungerer gruppa meget bra, men at fremmøte til fastsatt tid ikke alltid blir fulgt. Men den tapte tiden må vi ta inn igjen på kveldsjobbing.

Hvordan ligger vi an i forhold til Gant skjema:

Testingen kom litt senere i gang enn vi hadde planlagt i Gannt skjemaet, siden det oppstod noen problemer med Nagios som vi ikke hadde forutsett. For øyeblikket er testingen i full gang, og forbedringer blir daglig. Rapportskrivingen er også godt i gang, noe som er i henhold til fremdriftsplanen. Siden det begynner å gå mot slutten, er også testing og kvalitetssikring av programvaren et viktig tema. Dette jobbes det med kontinuerlig, og det skal være ferdig i begynnelsen av mai.

Forsinkelses faktorer:

Som nevnt tidligere har det oppstått noen problemer med skriptene vi har laget i forhold til det vi hadde tenkt. Dette har tatt noen timer ekstra å ordne, så vi er litt forsinket med tanke på hvor vi skulle vært i testprosedyren våres.