Prosjektrapport - student.cs.hioa.nostudent.cs.hioa.no/hovedprosjekter/data/2013/04/doc/Prosjekt... · SpareBank 1 Gruppen AS, heretter SpareBank 1, står for den daglige driften

Prosjektrapport

PySniff: Et system for nettverksbasert applikasjonsovervåking

Skrevet av: Lars Haugan;Ole Henrik Paulsen;Tim Sæterøy;Anders Struksnæs

Filnavn: Prosjektrapport.docx

Status: Ferdig

Versjon: 1.0 Sist endret: 27.05.2013 07:57:00

Sider: 71

Filnavn: Prosjektrapport.docx Side: 2 av 71


HOVEDPROSJEKT

HOVEDPROSJEKTETS TITTEL

Nettverksbasert applikasjonsoveråking

DATO

28. mai 2013

ANTALL SIDER / BILAG

71 / 59

PROSJEKTDELTAKERE

Anders Struksnæs

Lars Haugan

Ole Henrik Paulsen

Tim Sæterøy

INTERN VEILEDER

Torunn Gjester

OPPDRAGSGIVER

SpareBank 1 Gruppen AS

KM IT og Innkjøp

KONTAKTPERSON

Martin Jensen

SAMMENDRAG

Prosjektet «Nettverksbasert applikasjonsovervåking» har bestått i å utvikle et rammeverk for overvåking av

applikasjoner, som kommuniserer over et nettverk. Systemet legger til rette for innhenting, behandling og

presentasjon av nettverkstrafikk til overvåkede applikasjoner. Hensikten med overvåkingen er å oppdage

feilsituasjoner i kommunikasjonen mellom applikasjoner.

Systemet er designet som et rammeverk med utvidelsesmuligheter. Muligheten for utvidelser var et krav fra

oppdragsgiver. Dette for at sluttproduktet kunne utvides med spesifikk overvåking av deres systemer.

Vi har over et semester utviklet et rammeverk for overvåking for SpareBank 1. Dette er dokumentasjonen

for systemet vi har kommet frem til. Dokumentasjonen er delt inn i en prosjektrapport hvor systemet er

dokumentert, og en prosessrapport hvor prosjektets prosess er dokumentert.

Prosjektsiden for gruppen finnes på adresseen http://student.iu.hio.no/hovedprosjekter/data/2013/04/

Passordet for kildekode er: hioa2013

3 STIKKORD

Overvåking

Applikasjonsutvikling

Nettverk

Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

Gruppe 4

TILGJENGELIGHET

Åpen

Telefon: 22 45 32 00

Telefaks: 22 45 32 05


FORORD

Moderne bankdrift baserer seg på nettverksbaserte tjenester. Tjenestene kan være beregnet på intern bruk i

banken, men det kan også være tjenester som kundene kan bruke. Nettbank og minibank er kjente eksempler

på det siste. For å ivareta pålitelig drift, er det viktig å kunne overvåke aktiviteten i bankens nettbaserte

tjenester. SpareBank 1 har ønsket å utvikle en applikasjon som skal overvåke bankens nettverksbaserte tjenester som

til enhver tid blir brukt i banken. Vi har fått dette oppdraget som vårt bachelorprosjekt. I denne rapporten skal vi beskrive både designet og implementasjonen av den applikasjonen vi har utviklet.

Vi presenterer oppbygning og de valg som er tatt for å oppnå den ønskede funksjonaliteten. Rapporten tar innledningsvis for seg hvordan applikasjonen i sin helhet er designet, og utdyper de spesielle

underpunktene videre, ved å presentere dette som delapplikasjoner. Det presenteres også vesentlige

elementer for utviklingen, da spesielt med tanke på de forskjellige applikasjonsmiljøene som sluttproduktet

skal fungere i. Vedleggene til rapporten er ment som oppslag og referanser, hvor mer informasjon om spesielle deler av

prosjektet og applikasjonen er spesifisert. Her kommer også kravspesifikasjonen som er relevant for

prosjektet, som lister krav til løsningen fra oppdragsgiver. Vi har valgt å navngi applikasjonen PySniff. «Py» er inspirert av navnestandarden som ofte er brukt i

applikasjoner skrevet i Python. «Sniff» er basert på ordet sniffing som i IT-sammenheng er en teknikk for å

se på nettverkstrafikk. Vi vil rette en takk til oppdragsgiver SpareBank 1 ved Martin Jensen som veileder med god oppfølging og

støtte. Vi vil også takke Torunn Gjester som veileder ved Høgskolen i Oslo og Akershus (HiOA).


1. INNHOLD

1. INNHOLD 5

2. INTRODUKSJON 7

2.1 OM BEDRIFTEN 7 2.2 BAKGRUNN FOR PROSJEKTET 7 2.3 PROSJEKTETS MÅL 7 2.3.1 BEDRIFTENS MÅL 7 2.3.2 GRUPPENS MÅL 8

3. DESIGN AV PYSNIFF 9

3.1 HVA ER PYSNIFF 9 3.2 LAGDELING AV PYSNIFF 9

4. APPLIKASJONSMILJØER 11

4.1 INTRODUKSJON AV APPLIKASJONSMILJØER 12 4.2 OPPSETT AV TESTMILJØET 13 4.3 BRUKSOMRÅDE 17 4.4 ANSVAR OG SIKKERHET 17 4.5 HARDWARE 17

5. DELAPPLIKASJONENE 18

5.1 SENSOR 19 5.1.1 INTRODUKSJON TIL SENSOR 20 5.1.2 KRAV TIL SENSOR 20 5.1.3 APPLIKASJONSDESIGN 21 5.1.4 IMPLEMENTASJON AV SENSOR 24 5.2 DATABASE 27 5.2.1 KRAV TIL DATABASE 28 5.2.2 APPLIKASJONSDESIGN 28 5.2.3 OPPSETT AV DATABASEN 30 5.3 CORE 32 5.3.1 INTRODUKSJON TIL CORE 33 5.3.2 KRAV TIL CORE 33 5.3.3 APPLIKASJONSDESIGN 33 5.3.4 IMPLEMENTASJON 34 5.4 WEBSERVICE 40 5.4.1 INTRODUKSJON TIL WEBSERVICE 41 5.4.2 KRAV TIL WEBSERVICE 41 5.4.3 APPLIKASJONSDESIGN 41 5.4.4 UFORDRINGER 45 5.4.5 KONFIGURASJON 45 5.5 FRONTEND 46 5.5.1 INTRODUKSJON AV FRONTEND 47 5.5.2 KRAV TIL FRONTEND 47 5.5.3 APPLIKASJONSDESIGN 47 5.5.4 UTVIKLING AV FRONTEND 48 5.5.5 UTFORDRINGER 57 5.5.6 KONFIGURASJON 57 5.5.7 LOGGING AV FRONTEND 59 5.5.8 PRODUKTET 60


6. KONKLUSJON 63

6.1 MÅLOPPNÅELSE 64 6.1.1 BEDRIFTENS MÅL 64 6.1.2 LÆRINGSMÅL 64 6.2 UTVIDELSESMULIGHETER 64 6.3 KONKLUSJON AV PRODUKTET 65

7. PROSESSRAPPORT 66

7.1 KRAV TIL PROSJEKTET 66 7.2 PLANLEGGING OG METODE 66 7.2.1 UTVIKLINGSMODELL 66 7.2.2 FREMDRIFT OG ARBEIDSPLAN 66 7.3 VERKTØY 69 7.4 SAMMARBEID 69 7.5 VEILEDNING 69

8. REFERANSER 70

8.1 VEDLEGG 70 8.2 DATAORDBOK 70 8.3 REFERANSER 70


2. INTRODUKSJON

2.1 OM BEDRIFTEN

SpareBank 1 Gruppen AS, heretter SpareBank 1, står for den daglige driften av IT-løsningene til

datterselskapene og bankene i SpareBank 1 Alliansen. SpareBank 1 Gruppen inngår i Alliansesamarbeidet

SpareBank 1 DA, og er ansvarlig for nettbankløsningene, Nettbank og Mobilbank, samt de fleste

kontorapplikasjonene som benyttes av bankene. Dette innebærer at SpareBank 1 Alliansen har oppdraget om

applikasjonsutvikling, overvåking og drift av de mest sentrale applikasjonene. Origo Alliansen er en avdeling under Kompetansesenter IT og innkjøp (KM IT og innkjøp) som jobber med

overvåking og support på mange av SpareBank 1 sine applikasjoner. Avdelingen jobber kontinuerlig med

feilsøking på applikasjoner, og har ansvaret for varsling, feilsøking og koordinering ved driftsproblemer.

Avdelingen fungerer også som tredjelinjesupport for kundesentre i alliansebankene når det gjelder feil i

nettbankløsningene, eller kontorapplikasjonene som krever nærmere analyse for å finne feil. Applikasjonene

som supporteres av Origo er for det meste basert på Linux og det er derfor et godt samarbeid med

driftsavdelingen for systemer på Linux. Linuxmiljøene i SpareBank 1 driftes av Drift Alliansen. Drift er ansvarlig for den daglige driften av

maskinvare og programvare som benytter Linux som operativsystem. Avdelingen er oppdragsgiver for

prosjektet, som skal kunne benyttes av flere av avdelingene innenfor IT-operasjoner i banken.

2.2 BAKGRUNN FOR PROSJEKTET

I SpareBank 1 består det interne nettverket av mange applikasjoner som kommuniserer for å levere nettsider

til både kunder og kundebehandlere. I nettbanken er det for eksempel en applikasjon som kjører i

bakgrunnen for å kunne levere den tjenesten kunden møter når de logger seg inn. For å overvåke disse applikasjonene er det i dag flere avdelinger som benytter allerede eksisterende og

etablerte overvåkingsystemer. De mest sentrale avdelingene for bruk av PySniff er Origo Alliansen og Drift

Alliansen, da de viktigste systemene blir overvåket av disse. I dagens løsninger er det overvåkingssystemer som baserer seg på to metoder. Den ene metoden er å se på

applikasjonene, og informasjonen som genereres av disse. For å gjøre dette brukes det mest

applikasjonslogger. Den andre metoden er såkalt ende-til-ende overvåking, som baserer seg på

«webscraping». Webscraping er en teknikk for å simulere hvordan en bruker benytter en nettside. Fordelen

med dette er at man vil kunne oppdage om sidene man besøker samsvarer med det som forventes, og varsle

hvis det oppdages avvik. Disse to metodene er viktige for å kunne overvåke den daglige driften, og gir et bilde av driftsituasjonen som

gjør det mulig å detektere feil, og hjelpe til med å finne feilkilder. Det de etablerte overvåkingsystemene derimot ikke kan gjøre, er å se på nettverkstrafikken som går mellom

applikasjoner i et nettverk. Ettersom alle applikasjonene i linuxmiljøene kommuniserer over nettverk, er det

å se på nettverkstrafikk en god måte å utvide overvåkingen på. Ved å se på nettverkstrafikken er det mulig å

lage en fleksibel overvåkingsløsning som benytter informasjonen som finnes i nettverket til å lage et bilde av

situasjonen. Ved å overvåke nettverkstrafikken vil det være mulig å oppdage feil som det ikke har vært

mulig å oppdage med de eksisterende overvåkingssystemene.

2.3 PROSJEKTETS MÅL

2.3.1 BEDRIFTENS MÅL

Målet med dette prosjektet er å utvikle et rammeverk for overvåking av nettverkstrafikk mellom

applikasjoner i et vilkårlig nettverk. Hensikten med overvåkingen er å oppdage feilsituasjoner som ellers


ville vært vanskelig å oppdage. Dagens overvåkingsløsninger i SpareBank 1 har ikke funksjonalitet for overvåking av applikasjoner ved å se

på nettverkstrafikk. Derfor ønskes det en løsning som kan analysere nettverkstrafikken for feil ved å

analysere nettverksprotokollenes feilmeldinger. Dette vil gi et godt tillegg til dagens overvåking, og gjøre

feilsøkingen ved driftsproblemer enklere. Løsningen som skal utvikles, vil være et utvidbart rammeverk som legger til rette for videreutvikling internt

hos SpareBank 1. Sammen med rammeverket skal det være et eksempel på en implementasjon av

overvåking av HTTP.

2.3.2 GRUPPENS MÅL

Hovedmålet for gruppen er å designe, implementere og dokumentere en nettverksbasert

overvåkingsapplikasjon i tråd med krav fra SpareBank 1. For at prosjektet skal få en god gjennomføring og et godt læringsutbytte er det nødvendig å tilegne seg

kunnskap innenfor flere områder som er nye for prosjektgruppen. Mange av SpareBank 1 sine interne applikasjoner er utviklet med programmeringsspråket Python. Python er

et objektorientert programmeringsspråk med fokus på fleksibel, men lesbar kode. Språket kan benyttes til

scripting, større applikasjoner og webutvikling, noe som gjør det egnet for utviklingen vår applikasjon

PySniff. Da Python er mye brukt hos SpareBank 1, gjør utviklingen av PySniff i Python det mulig for andre

ansatte å videreutvikle løsningen etter prosjektets slutt. Et av målene for gruppen har derfor vært å tilegne

seg kunnskap i pythonprogrammering som er nødvendig for å kunne utvikle en applikasjon i samsvar med

oppdragsgivers krav. Prosjektet krever innsikt i applikasjonene til SpareBank 1 og hvordan disse kommuniserer. Dette er

nødvendig for å kunne utvikle et universelt rammeverk som vil fungere uavhengige av applikasjonene. Dette

skal gjøre at rammeverket ikke bare skal kunne benyttes hos SpareBank 1, men også andre steder hvor

applikasjonene kommuniserer på samme måte. For å kunne utvikle applikasjonen må det derfor settes opp et testmiljø. Prosjektgruppen har derfor hatt som

mål å sette opp, og administrere et slikt miljø for testing av PySniff. Dette testmiljøet skal være så likt

oppsettet til SpareBank 1 som mulig, noe som inkluderer at Python må være installert. Installasjonen av

testmiljøet er beskrevet i kapittelet 4 om applikasjonsmiljøer i denne rapporten. For å kunne håndtere de menger med data som skal behandles, har vi måttet tilegne oss kunnskap om hva

som er optimal lagringsløsning for potensielt store mengder data og informasjon. Hvordan dette er løst er

beskrevet i kapittelet om database.


3. DESIGN AV PYSNIFF Ved utvikling av denne applikasjonen har det blitt lagt vekt på et solid design for løsningen. Design er i

denne sammenhengen hvordan applikasjonen er bygget opp. Designet av rammeverket er et meget vesentlig element i prosjektet. Dette er viktig for å gjøre applikasjonen

fleksibel og ikke minst robust. Med fleksibel menes det at løsningen skal være utvidbar og kunne ligge til

grunn for bruk i forskjellige applikasjonsmiljøer. Med bakgrunn i dette er det valgt å dele opp PySniff i flere applikasjoner. Disse delapplikasjonene

representerer adskilt funksjonalitet, og de utfører hver en viktig del av det helhetlige produktet.

3.1 HVA ER PYSNIFF

PySniff er et rammeverk for overvåking av applikasjoner som kommuniserer over et nettverk. Data samles inn ved å se på nettverkstrafikken som går mellom applikasjoner. De innsamlede dataene blir

analysert for deretter å bli presentert i et webgrensesnitt. Applikasjonsdataene blir samlet inn ved bruk av en sensor. En sensor er en del av PySniff og er et program

som kjører på en eller flere maskiner i et nettverk. Sensor samler informasjon sendt over nettverk og lagrer

disse i en sentral database. De innsamlede dataene i databasen legger til rette for presentasjon og analyse. Et webgrensesnitt presenterer

disse dataene, slik at innsamlet informasjon kan illustreres grafisk. Situasjonen kan også overvåkes i sanntid

da databasen kontinuerlig oppdateres med nye data. Analysen vil bestå av å aggregere innsamlede data. Dette for å presentere informasjon som går over lengre

perioder. Aggregering er å kombinere data ved å slå de sammen i større grupper eller tidsperioder. Ved å

aggregere data vil dette ta mindre plass ved lagring av større perioder.

3.2 LAGDELING AV PYSNIFF

PySniff skal som tidligere beskrevet være et fleksibelt og solid rammeverk. Fleksibilitet oppnås gjennom

struktureringen av rammeverket. Dette gjøres ved å dele opp den adskilte funksjonaliteten. PySniff er delt inn i fem forskjellige delapplikasjoner. Sensor er en delapplikasjon som henter inn

applikasjonsdata fra nettverkstrafikk. Applikasjonsdataene sendes videre til databasen for lagring.

Databasen inneholder ubehandlede applikasjonsdata fra sensor, og behandlede fra Core. Delapplikasjonen

Core aggregerer applikasjonsdataene i databasen. De dataene som er i databasen presenteres av Frontend.

Frontend er et webgrensesnitt som er tilgjengelig for bruk i vanlig nettleser eller på overvåkingsskjermer.

For at dataene skal kunne brukes i Frontend gjøres disse tilgjengelig via Webservice. Webservicen leverer

data fra databasen og gjør det mulig å legge til flere enheter, som en mobilapplikasjon.


Figur 1: Dataflytdiagram for PySniff med delapplikasjonene som kommuniserer.

Alle delapplikasjonene kan byttes ut, uten at dette endrer forholdet mellom dem. Funksjonaliteten og

relasjonene til de forskjellige delapplikasjonene er ikke avhengig av implementasjonen, noe som gjør at en

del godt kan skrives i et annet programmeringsspråk. Core og Webservice deler et pluginbibliotek som inneholder funksjonalitet for behandling og spørring på

data fra databasen. Bakgrunnen for det delte biblioteket er at deler av funksjonaliteten for Core og

Webservice kan være den samme. Core og webservice er delt på en slik måte at det er mulig å benytte den samme koden. Det er fortsatt mulig

å kjøre en delapplikasjon separert, og det gjør det lettere å vedlikeholde applikasjonen. Webservice fungerer

også som et såkalt «Business Logic Layer». Dette betyr at logikk i form av funksjonalitet er sentralisert.

Hvis Frontend skal bytte ut, er funksjonaliteten i PySniff fortsatt tilgjengelig, og gjør det mulig å utvide med

flere Frontend-applikasjoner. Ved å dele PySniff er det også mulig å plassere delapplikasjonene på forskjellige deler i et nettverk. Dette

kan være ønskelig der man har et nettverk som er delt inn i forskjellige sikkerhetssoner. Dette er spesielt

aktuelt for SpareBank 1. Alle delapplikasjonene er så fleksible at de kan stå på separate maskiner, eller på én enkelt maskin. Det er

også mulig å sette inn flere av en delapplikasjon for å øke kapasitet og skalerbarhet.


4. APPLIKASJONSMILJØER

Dette kapittelet inneholder en introduksjon og innsikt til de forskjellige applikasjonsmiljøene som PySniff

skal kjøre i. Applikasjonsmiljøer er miljøer hvor applikasjoner kommuniserer med hverandre. Dette

benyttes blant annet for å sikre at programvare som kjører i produksjon er stabil og ikke inneholder feil.

Figur 2 er en illustrasjon av et testmiljø. Dette har likheter til testmiljøet som er benyttet i dette prosjektet,

med unntak av at det ikke kjører applikasjoner som Nettbank eller Mobilbank.

Figur 2: Eksempel på et miljø der sensoren kan plasseres inn, og sende data videre.


4.1 INTRODUKSJON AV APPLIKASJONSMILJØER

For å kvalitetssikre applikasjonene har SpareBank 1 stilt krav om å teste applikasjonene i to

applikasjonsmiljøer, før de installeres i produksjonsmiljøet.

Nettverkstrafikken i SpareBank 1 sine applikasjonsmiljøer inneholder konfidensiell informasjon. Dette er

data som for eksempel personnummere, kontodetaljer, IP-adresser og liknende. Det er viktig at disse dataene

ikke kommer på avveie, og det er derfor strenge krav for hvordan disse skal håndteres. For å unngå å komme

i konflikt med krav til konfidensialitet ble det i prosjektet tatt i bruk et privat testmiljø der følsomme data

ikke ble brukt.

Dette medførte at to av miljøene ville ligge hos SpareBank 1, og det private testmiljøet ville driftes av

prosjektgruppen selv. De to miljøene som ligger hos SpareBank1 er Quality Assurance (QA) og

produksjonsmiljøet. QA er et kvalitetssikringsmiljø som er helt likt som produksjonsmiljøet, med unntak av

data som for eksempel personnummer og kontodetaljer som er fiktive. QA skal fortsatt følge retningslinjene

for hvor stabile applikasjonene skal være. Produksjonsmiljøet er miljøet som kjører alle selvbetjente

applikasjoner som nettbank, mobilbank og forsikringstjenester, og betjente applikasjoner som rådgivnings-

og administrasjonsapplikasjoner.

Det var tidlig i prosjektet klart at prosjektgruppen selv skulle ta det fulle ansvaret for det private testmiljøet. I

starten førte dette til en del drifts-relaterte oppgaver som prosjektgruppen ikke hadde vært borte i før. Drift

var en stor oppgave i starten av prosjektet, dette innebar en del daglige oppgaver en driftsavdeling i en stor

bedrift gjør på daglig basis. En del av denne driften inkluderte oppsett av maskinvare, som fysisk oppsett av

maskinvaren og kabling av nettverk og strøm. Det var også behov for å installere operativsystem, og å

konfigurere maskinen, slik at denne var tilgjengelig fra internett. For at dette skulle være mulig var det

nødvendig å endre brannmurkonfigurasjonen i de allerede eksisterende brannmurene i nettverket.

Systemadministrasjon har vært en oppgave som har pågått gjennom hele prosjektet. Dette begrenser seg til å

omfatte installasjon av nødvendig programvare, og installasjon og drift av PySniff sine delapplikasjoner.

Drift omfatter feilsøking, samt starting og stopping av PySniff sine delapplikasjoner.

Det private testmiljøet bestod av en fysisk server som hadde tre virtuelle maskiner installert. En virtuell

maskin er en programvaresimulert, fullverdig datamaskin som kjører på en fysisk datamaskin. En vanlig

forkortelse for en virtuell maskin er «VM»

Konfidensiell data: Driftes av: Systemadministrasjon Virtuelt

Privat testmiljø Nei Prosjektgruppen Prosjektgruppen Ja

QA (Quality Assurance) Ja SpareBank1 Prosjektgruppen Nei

Produksjon Ja SpareBank1 SpareBank1 Nei Tabell 1: Tabellen viser de forskjellige miljøene og ansvarsområder for disse.


4.2 OPPSETT AV TESTMILJØET

I oppsettet av det private testmiljøet ble det brukt KVM

(Kernel-Based Viritual Machine), som er programvare

for å installere og kjøre virtuelle datamaskiner. Valget av

KVM ble tatt etter arbeidsgivers erfaring med

programvaren. KVM hadde støtte for «VirtIO /

Paravirtualization» som er å kunne kjøre virtuell hardware så likt som mulig. Tabell 2 viser

ytelsesforbedring med bruk av «VirtIO / Paravirtualization».

Kompilering av Python

Uten VirtIO/ Paravirtualization 6-7 Timer

Med VirtIO / Paravirtualization 4-5 Minutter Tabell 2: Ytelsesforbedringer ved forskjellige typer virtualisering.

Prosjektgruppen var ikke kjent med teknologien rundt «VirtIO / Paravirtualization» fra prosjektstart, men da

dette ble kjent ble de virtuelle maskinene i det private testmiljøet mer likt miljøet i SpareBank1 i form av

ytelse.

Koden i Figur 3viser hvordan installasjonskommandoen for en virtuell maskin med «VirtIO /

Paravirtualization» ser ut. For videre installasjonsdokumenter av KVM kan dette sees i vedlegg C.

virt-install --connect qemu:///system -n CoreRAW4 -r 4256 --disk

/home/kvmvm/coredisk.img,device=disk,bus=virtio --boot hd --cpu host --vnc --noautoconsole --os-type linux --accelerate --bridge=br0

Figur 3: Installasjonskode for en virtuell maskin i KVM.

De virtuelle maskinene i det private testmiljøet ble etter oppsett administrert av «Virtuell Machine Manger»

som er et grensesnittprogramvare til Linux for å administrere virtuelle maskiner, se Figur 4. I dette

grensesnittet kan man gjøre de fleste nødvendige operasjoner. Man kan for eksempel slå av, på og restarte

maskinene, og legge til hardware, noe som ble gjort for å legge til en «Public IP adresse». Dette er altså

unike IP adresser som kan aksessers fra verden over, se Figur 5.

Figur 4: Virtuell Machine Manager


Virtuell Machine Manger ble også brukt til å installere operativsystemene på de virtuelle maskinene i

testmiljøet. Operativsystemet som ble kjørt på disse virtuelle maskinene var CentOS, som er det samme som

vil bli brukt i SpareBank1.

Figur 5: Kontrollpanel for maskinvarekonfigurasjon. Her vises konfigurasjonen av et virtuelt nettverkskort.


Figur 6: Installasjon CentOS via terminalen i Virtual Machine Manger.

CentOS (Community Enterprise Operating System) er en gratis Linux-distribusjon som har 100%

kompatibilitet med Red Hat Enterprise Linux sine pakker. CentOS ble installert uten desktop, da det bare var

brukt for terminal tilgang til de virtuelle maskinene. Figur 7 viser terminalene via Virtual Machine Manger.

Dette ble brukt for å sette opp nettverket. Disse terminalene vil være tilgjengelig uansett om de virtuelle

maskinene hadde nettverksfeil eller annen type feil som gjorde at de ikke var mulig å koble seg på dem. Det

kan sammenliknes med en fysisk skjerm til en datamaskin.


Figur 7: Virtuell Machine Manger terminaler


4.3 BRUKSOMRÅDE

Testmiljøets hovedfunksjon var å kunne teste applikasjonen før det ble installert i SpareBank 1 sine miljøer.

Det private testmiljøet var altså det laveste miljøet koden skulle testes på. Når det var en klar og stabil

funksjon i testmiljøet kunne denne overføres til QA-miljøet i SpareBank 1 som er neste nivå.

Det private testmiljøet ble også brukt til å eksperimentere med ny funksjonalitet, nye versjoner av

rammeverk og lignende. Det ble for eksempel kjørt flere versjoner av koden for å teste funksjonalitet,

stabilitet og ytelse. Dette hadde ikke latt seg gjøre i neste nivå (QA-miljøet) da eksperimenter av denne typen

for eksempel kan gjøre at applikasjoner ikke kjører, eller skaper problemer for resten av QA-miljøet.

4.4 ANSVAR OG SIKKERHET

Serveren som prosjektgruppen brukte til testing var plassert hos Oslo Sportslager. Prosjektgruppen fikk lov

til dette under forutsetning at vi sto for driften selv. Dette innebar en rekke regler bedriften hadde for it-

systemer, blant annet innenfor nettverk- og brannmurkonfigurasjon.

4.5 HARDWARE

Den fysiske maskinen som disse VMene står på er en HP ProLiant G6 rack-server har følgende

spesifikasjoner:

Maskinvare Størrelse

Harddisk 4 x 100GB SCSI-disker

Ram 10GB Ram

Prosessor Intel Xeon E3120

Båndbredde 20mbit opp/ned SHDSL linje fra PowerTech.

Figur 8: HP ProLiant G6 server som benyttes i testmiljøet.


5. DELAPPLIKASJONENE

Delapplikasjonene er de separate underapplikasjonene som er nødvendige for at PySniff skal fungere. Disse

er delt inn i følgende applikasjoner Sensor

Database

Core

Webservice

Frontend

Disse delapplikasjonene danner dataflyten i PySniff, og sørger for at data blir innhentet, prosessert og levert

for presentasjon. Disse delkapittelene inneholder informasjon om de forskjellige delapplikasjonene, og de

valg som er tatt for å produsere og koble sammen PySniff Illustrasjonen viser hvordan data flyter gjennom delapplikasjonene og gjør at det blir én helhetlig

applikasjon. Denne illustrasjonen vil være gjeldende gjennom hele dette kapittelet. Denne viser dataflyten i

PySniff, fra sensor henter inn data, til det presenteres i Frontend.

Figur 9: Dataflytdiagram som illustrer koblingen mellom delapplikasjonene.


5.1 SENSOR

Dette delkapittelet inneholder en introduksjon til sensoren i PySniff. Sensoren sin hovedoppgave er

datainnsamling fra klienten, eller nettverket den er plassert i.

Figur 10: Dataflytdiagram som uthever applikasjonsnettverket hvor sensoren er plassert.


5.1.1 INTRODUKSJON TIL SENSOR

Sensoren er kjernen i datainnsamling i PySniff. Denne henter inn nettverksdata lagrer dette for bruk i resten

av applikasjonen. Sensoren er i stand til å plukke opp nettverkstrafikken som går på transportlaget i OSI-

modellen.

OSI-Modellen Lag Navn Eksempel

7 Applikasjonslaget HTTP, FTP, DNS, SNMP, Telnet…

6 Presentasjonslaget SSL, TLS…

5 Sesjonslaget NetBIOS, PPTP…

4 Transportlaget TCP, UDP, NTP, RTP, SCTP…

3 Nettverkslaget IP, ARP, ICMP, IPsec..

2 Data link laget PPP, ATM, Ethernet…

1 Fysiske laget Eterneth, USB, Bluetooth, WIFI… Figur 11 OSI-modellen [1]

Det har blitt brukt flere rammeverk i utviklingen, da det allerede finnes kraftige rammeverk for å utføre

sentrale deler av sensoren sine oppgaver. Følgende tabell beskriver de forskjellige rammeverkene som er

benyttet.

Rammeverk Beskrivelse

Scapy[2] er et rammeverk for å håndtere nettverkspakker. Scapy er i stand til å for eksempel sette sammen, sende, svare og fange opp nettverkspakker med enkle kommandoer. Sensoren bruker Scapy til å fange opp og filtrere ut nettverkstrafikken den er interessert i.

SQLAlchemy[3] er et Pythonrammeverk for å håndtere Structered Query Language (SQL). SQL er et spørrespråk som gjør det mulig å hente, og sette inn data i databaer. Dette benytter SQLAlchemy for å kommunisere med databasen. SQLAlchemy er designet for effektivitet og høy ytelse. Sensoren bruker SQLAlchemy til å sette inn nettverkspakkene i databasen. SQLAlchemy er en såkalt Object Realtion Mapper (ORM), som baserer kommunikasjonen til databasen på Pythonobjekter.

Figur 12 illustrerer måten pakkene blir fanget opp i TCP-laget, før det søkes gjennom etter HTTP-pakker,

som deretter blir satt sammen til Pythonobjekter. Pythonobjektene kan da settes inn i databasen med

SQLAlchemy.

Figur 12 Sensor: Dataflyt fra transportlaget til databasen

5.1.2 KRAV TIL SENSOR

Listen under er et utdrag av de viktigste kravene som er stilt til sensoren i kravspesifikasjonen. Resten av

kravene er beskrevet i vedlegg A.

Sensor skal være uavhengig av resten av applikasjonen.

Hvis det skal brukes flere sensorer, skal disse være uavhengig av hverandre.


Sensoren skal sniffe TCP, men det skal være mulig å legge til andre protokoller fra transportlaget i

OSI-modellen.

Sensoren skal ikke forstyrre eller «stjele» kapasiteten, eller ressursene til andre applikasjoner på

serveren den står på.

Sensoren skal bare videresende pakker som er definert i filteret.

5.1.3 APPLIKASJONSDESIGN

5.1.3.1 RESSURSBRUK

Ressursbruk har vært i fokus under utviklingen av sensoren, fordi det var viktig at sensoren skulle ta så lite

ressurser som mulig.

RAM- og CPU-bruk skal være minimalt, og ubetydelig for en produksjonsserver hos oppdragsgiver. Dette

var viktig da kostnadene ved å plassere disse sensorene rundt på egne dedikerte servere i produksjonsmiljøet

ville være betydelige.

Tidlig i utviklingsfasen ble det utviklet en funksjon i sensoren som kunne lese inn data fra fil. Denne var i

starten brukt til å simulere nettverkstrafikk. Funksjonen har også enda en funksjonalitet, nemlig at den kan

bli brukt til å lese inn «tapt» data. Tapt data kan for eksempel være hvis ikke databasen har vært tilgjengelig,

og man har lagret til fil istedenfor. Sensoren har ikke funksjonalitet til å skrive til fil, men dette kan gjøres

med ferdige programmer på nettet som for eksempel Wireshark.

5.1.3.2 DATAMENGDE

Testmiljøet vårt har hatt høy nettverkstrafikk i tidsrommet 08:00 – 18:00. Denne nettverkstrafikken har vært

på maksimalt 12 Mbps ut og 3 Mbps inn. Grafen i Figur 13 viser nettverkstrafikken i mai.

Figur 13: Graf fra Cacti der sensoren står i testmiljøet vårt

Gjennomsnittlig CPU- og RAM-bruk ved typisk nettverkstrafikk nevnt ovenfor var på 4% prosessorkraft og

10% RAM. Sensoren er installert på en virtuell maskin med 1GB RAM, med intel® Xeon® CPU E3120

@3.10GHz prosessor. Dette er en svak server i forhold til hva som blir brukt hos oppdragsgiver.

5.1.3.3 AVHENGIGHETSPERSPEKTIV

Sensoren er avhengig av å ha en database å koble seg til. Den vil slutte å fungere når databasen ikke er

tilgjengelig, men den vil også starte igjen så fort databasen blir tilgjengelig igjen. Dette blir logget i loggen

til sensoren


5.1.3.4 DATAFLYT

Det var i starten av prosjektet tenkt at sensoren skulle koble seg til Core, og at alle logiske operasjoner skulle

utføres der. Dette ble raskt endret fordi det ville ta ekstra ressurser i form av mer datatrafikk, som ville bli

sendt fra sensoren til Core. For å løse dette ble det lagt på et filter på sensoren. Før dette kunne benyttes som

en løsning var det derfor nødvendig å se på resursbruken av å kjøre logikk på sensor. Det viste seg å være

svært lite. Derfor kunne data sendes direkte til databasen, uten å gå via Core. Dette resulterte i at sensoren nå

kommuniserer direkte med databasen.

Figur 14 viser dataflyten for sensoren fra den fanger opp nettverkstrafikken til den blir sendt til databasen.

De røde linjene er normal nettverkstrafikk som blir generert når man for eksempel besøker en nettside. De

blå linjene er flyten i hvordan sensoren sender data til databasen.

Rekkefølgen i flytdiagrammet (Figur 14) er:

1. Nettbanken, mobilbanken eller databaseserveren skaper trafikk på nettverket, slik at disse pakkene

blir sendt igjennom switch og router til internett.

2. Routeren sender data videre til PySniff sensoren, som plukker opp dataene.

3. Den logiske delen i PySniff sensoren vil trekke ut TCP pakker, og sette disse sammen til HTTP

pakker.

4. HTTP pakkene blir sendt videre til databaselag 1 der de lagres.

Figur 14 dataflyt diagram for sensoren. Blå linjer er sensor-trafikk. Røde er prosessen sin nettverkstrafikk.


5.1.3.5 PORTABILITET

Siden sensoren er skrevet i programmeringsspråket Python, som støttes av de store operativsystemene;

Linux, Windows og OSX, er det mulig å installere sensoren på de fleste plattformene. Vi ønsket at sensoren

skal være portabel, da denne lett skal kunne plasseres på ulike applikasjonservere.

Figur 15: Figuren illustrerer at sensoren som her er presentert med Windows og Linux bokser kan kommunisere opp mot en og

samme database.

Tabell 3 viser hvilke operativsystemer sensoren har blitt forsøkt installert på og utfallet av installasjonen.

Operativsystem Testresultat Kommentar

Linux Centos 5.8

OK Installasjon gikk uten problemer

Windows 7 Fungerte, men litt trøblete under installasjonen.

Under installasjonen måtte vi nedgradere til Python2.6, ved å gjøre dette slapp vi å patche Scapy med forskjellige patcher for å få ting til å fungere.

Linux Debian OK Installasjonen gikk uten problemer

Arch Linux ARM OK Installasjonen gikk uten problemer. Installasjonen ble utført på en Raspberry Pi.

Tabell 3: Tabell over operativsystemer sensoren er forsøkt installert på.


5.1.4 IMPLEMENTASJON AV SENSOR

Figur 16 viser uttrekk av en konfigurasjonsfil brukt av sensorkoden. I denne filen setter man variabler

sensoren bruker til å utføre sine oppgaver. Count og timeout er verdier som hjelper sensoren i form av at den

vet når den skal sende dataen til databasen. Sensoren vil enten søke gjennom tusen nettverkspakker og sende

innholdet den er interessert i videre, eller samle nettverkspakker i 45 sekunder før den sender de til

databasen. IP og database er variabler som blir brukt til å koble til databasen. I filter variabelen kan man

filtrere på hvilken trafikk man vil at sensoren skal søke gjennom. Trafikken må være trafikk definert i

transportlaget i OSI-modellen (Figur 11).

[Sensor] count = 1000 filter = tcp timeout = 45 ip = 77.40.217.204 database = layer1

Figur 16: Uttrekk fra av konfigurasjonsfilen dev.ini som hører til sensoren.

Figur 17 tar for seg bakgrunnsprosessen til sensoren. Funksjonen «Sniffer.sniff_packets(hostname)» er

kjernefunksjonen i sensoren, som tar for seg sniffingen. Resten av kodeutdraget tar for seg loggingen i

sensoren. I Figur 18 er det tatt med et uttrekk fra loggfilen som blir generert av bakgrunnsprosessen.

def run(self): """Main daemon loop""" try: logger.info("PySniff Sensor started.") hostname = socket.gethostname() logger.info("Sensor have hostname: " + hostname) while True: try: sniffer.sniff_packets(hostname) logger.info("Sniff_packets done") except Exception as er: logger.exception("Unexpected error: " + str(er))

except SystemExit: logger.info("PySniff Sensor stopped.") logging.shutdown() sys.exit(1)

except: logger.exception("Unexpected error: ") logging.shutdown() sys.exit(1)

Figur 17: Utrekk av bakgrunnsprosessoren til sensoren.


2013-05-21 23:28:23,289 dev INFO PySniff Sensor started. 2013-05-21 23:28:23,289 dev INFO Sensor have hostname: Stress 2013-05-21 23:28:38,797 dev INFO Sniff_packets done 2013-05-21 23:28:47,809 dev INFO Sniff_packets done 2013-05-21 23:28:56,009 dev INFO Sniff_packets done 2013-05-21 23:29:03,310 dev INFO Sniff_packets done 2013-05-22 01:08:50,312 dev INFO PySniff Sensor stopped. 2013-05-22 01:13:55,307 dev ERROR Unexpected error: (OperationalError) could not receive data from server: Bad file descriptor 'select nextval(\'"HTTP_id_seq"\'::regclass)' {} (original cause: OperationalError: (OperationalError) could not receive data from server: Bad file descriptor 'select nextval(\'"HTTP_id_seq"\'::regclass)' {}) 'INSERT INTO "HTTP" (id, hostname, date, src, dst, len, sport, dport, method, host, useragent, statusline, location, server, load) VALUES (%(id)s, %(hostname)s, %(date)s, %(src)s, %(dst)s, %(len)s, %(sport)s, %(dport)s, %(method)s, %(host)s, %(useragent)s, %(statusline)s, %(location)s, %(server)s, %(load)s)' [{u'load': None, u'src': '00:27:0c:ab:b8:c0', u'statusline': None, u'dst': '00:0c:29:f6:6d:a1', u'hostname': 'Stress', u'len': 366, u'server': None, u'dport': 80, u'host': 'Host: 77.40.217.204\r\n', u'location': None, u'date': '2013-05-22 01:13:55', u'useragent': 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31\r\n', u'sport': 57436, u'method': 'GET /favicon.ico HTTP/1.1\r\n'}]

Figur 18: Uttrekk fra pysniff_sensor.log

Figur 19 er en pythonfunksjon som henter ut nettverkstrafikk, setter den sammen og sender den videre til

databasen.


try: import scapy.all as scapy except ImportError: import scapy import http_plugin import postgres_handler import config as cfg

def sniff_packets(hostname): cfgcounter = cfg.config.getint('Sensor', 'count') cfgfilter = cfg.config.get('Sensor', 'filter') cfgtimeout = cfg.config.getint('Sensor', 'timeout')

#Filter is indicating type of traffic snifffed from the network.

#Count is how many packets before sniff returns

#timeout is how many secunds before sniff returns packets = scapy.sniff(filter=cfgfilter,count=cfgcounter,timeout=cfgtimeout)

#This is the code to only take out HTTP packeges from the TCP stream. http=packets.filter(lambda(s): http_plugin.HTTPrequest in s or

http_plugin.HTTPresponse in s) for p in http.filter(lambda(s): http_plugin.HTTPrequest in s):

postgres_handler.insert_into(hostname,p.src,p.dst,p.len,p.sport,p.dport,p.Method,

p.Host,p.UserAgent) for p in http.filter(lambda(s): http_plugin.HTTPresponse in s):

postgres_handler.insert_respons(hostname,p.src,p.dst,p.len,p.sport,p.dport,p.Stat

usLine,p.Location,p.Server)

#Helping python garbage collector to keep the memory use down. del packets

Figur 19: Sniff_packets funksjonen


5.2 DATABASE

Dette delkapittelet inneholder en introduksjon til databasedelen av PySniff. Databasen består av to separate

databaser. De blir kalt databaselag 1 og databaselag 2.

Figur 20: Dataflytdiagram som uthever applikasjonsnettverket hvor databasen er plassert.


5.2.1 KRAV TIL DATABASE

Listen under er et utdrag av de viktigste kravene som er stilt til databasen i kravspesifikasjonen. Resten av

kravene er beskrevet i vedlegg A.

Databaselag 1 skal inneholde all data sensoren sender til databasen.

Databaselag 1 skal være lagret i RAM.

Databaselag 2 skal kun inneholde aggregert data hentet fra databaselag 1.

Det skal være et logisk skille mellom databaselag 1 og databaselag 2 i form av egen instans av

databasemotoren.

Det er kun Webservice og Core som skal ha lese rettigheter til databaselagene.

Det er kun Sensoren som har skriverettigheter til databaselag 1.

Det er kun Core som har skriverettigheter til databaselag 2.


5.2.2.1 YTELSE OG KAPASITET

Valget av PostgreSQL som databaselag 2 var enkelt, siden dette allerede er tatt i bruk i mange andre interne

applikasjoner hos SpareBank 1.

Valget av type database for databaselag 1 resulterte i mye testing og feiling. Kravet som var stilt av

SpareBank 1, var at databasen skulle lagres i RAM, da kostnadene dette ville medføre ved lagring til disk

ville være betydelige. Hvis det hadde blitt benyttet vanlige magnetiske disker, ville dette medføre betydelig

slitasje på maskinvaren, og redusere levetiden for disse. Da magnetiske disker er dyrt, er dette lite ønskelig.

I starten av prosjektperioden ble det brukt SQLite som databaselag 1. Denne databaseprogramvaren hadde

direkte støtte for lagring direkte på RAM. SQLite oppfylte kravspesifikasjonen helt til databasen skulle bli

flyttet over til en ekstern server. Det viste seg at SQLite ikke hadde noen god måte å håndtere innkommende

spørringer via nettverk på. Grunnen til SQLite ble valgt i utgangspunktet var at dette var en

databaseprogramvare som ikke tar mye ressurser, krever lite konfigurasjon, og har direkte støtte for lagring

til RAM. Siden SQLite ikke lot seg flytte over til ekstern server, måtte vi lete etter en ny programvare for å

kunne tilfredsstille kravspesifikasjonen.

Det ble vurdert flere databaseprogramvarer. Et eksempel er Redis som er en ren RAM database som skriver

direkte til RAM. Det negative med Redis var at SQLAlchemy, som ble brukt til innsetting av verdier på

sensoren, ikke støttet Redis. Vurderingen resulterte i gjenbruk av PostgreSQL på databaselag 1.

PostgreSQL manglet støtte i programvaren til å sette opp lagring på RAM. For å løse dette problemet er det

derfor mulig å benytte RAM som en vanlig harddisk. Dette kalles RAMdisk.

Oppsettet av RAMdisken og databasen ble derfor satt sammen til ett installasjonsscript. Figur 21

viser installasjonsscriptet for hvordan man gjør dette.

/etc/init.d/postgresql stop TMPDIR=/var/ramdatabase; [ -d $TMPDIR ] || mkdir $TMPDIR; sudo mount -t tmpfs -o size=27G,nr_inodes=10k,mode=0777 tmpfs $TMPDIR; sudo cp /opt/pysniff/database/ramdisk/postgresql /etc/rc.d/init.d/postgresql; sudo cp /opt/pysniff/database/ramdisk/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf sudo mkdir -p /var/ramdatabase/pgdata sudo chown postgres:postgres /var/ramdatabase/pgdata su - postgres -c "initdb -D /var/ramdatabase/pgdata" #cd /var/ramdatabase #sudo /usr/sbin/setenforce 0 sudo /etc/init.d/postgresql start #print "RamDisk Up.."

Figur 21: Installasjonsscript for RAM-database


5.2.2.2 RESSURSBRUK

Kravene til maskinvaren til databaselag 1 og databaselag 2 er forskjellige. Databaselag 1 bruker kun RAM

som lagringsmedium, mens databaselag 2 bruker magnetiske harddisker. Dette medfører at begge lagene kan

kjøre på én og samme server uten å bruke av hverandre sine ressurser. Lagene kan også fordels over flere

servere, der den ene kan ha mer minne, mens den andre kan ha større harddisk.

5.2.2.3 DATAMENGDER

Trafikken sensoren sender til databaselag 1, indikerer hvor mange sensorer databaseserveren takler. En

databaseserver har gjerne en eller flere nettverkskabler koblet til, og hver enkelt har en maksimal

overføringshastighet de kan håndtere. En nettverkskabel som binder serveren sammen med et nettverk blir

gjerne kalt en link. Serverne som er brukt i dette prosjektet har kun en link, og denne er på 1 Gigabit. Dette

betyr at denne linken kan teoretisk håndtere 125MB/s[4] med nettverkstrafikk. Når linken(e) til

databaseserveren er fylt opp med trafikk, vil dette også skape problemer for spørringer mot databasen. Disse

spørringene kan for eksempel være spørringer fra Webservice, eller Sensor. Det er derfor viktig å ha god nok

nettverkskapasitet tilgjengelig for å håndtere trafikken. Figur 22 illustrerer hvor mye trafikk man maksimalt

kan ha fordelt på linker.

Figur 22: Trafikk fordelt på antall linker.

5.2.2.4 DATAFLYT

Databasen skal kunne håndtere tre funksjoner ved et svar, eller ved lagring av innkommende verdier. Den

første funksjonen er når databasen mottar nye innsamlede data fra sensoren. Disse dataene vil lagres i

databaselag 1. Den andre funksjonen er når det skal flyttes data fra databaselag 1 til databaselag 2. Den siste

funksjonen er når Webservice spør på data for fremvisning i Frontend. Dette er illustrert i Figur 23.

Funksjonene er i samme rekkefølge som nevnt ovenfor hvis man leser figuren fra venstre til høyere ved

piler.

0

100

200

300

400

500

600

700

Trafikk

1 Link

2 Link

3 Link

4 Link


Figur 23: Dataflyt i og imellom databaselaget.

5.2.2.5 UTVIDBAR OG STABIL DATABASEDRIFT

Det er viktig med høy grad av stabilitet på databasen. Uten databasen vil ikke Sensoren kunne samle inn

nettverkstrafikk å lagre disse. Dette vil gjøre at data for tidsrommet databasen er nede mangler. Databasen

må også være tilgjengelig for at Webservicen skal kunne levere data til Frontend. Nedetid på databasen vil

resultere i at det mangler data i hele PySniff.

Stabiliteten kan økes ved å sette inn flere databaseservere, der disse kan inneholde forskjellige typer

nettverkstrafikk. Dette kan gjøres ved at for eksempel HTTP-trafikk lagres på en server, mens SQL-trafikk

på en annen server.

5.2.3 OPPSETT AV DATABASEN

Oppsett av nye tabeller i databasen gjøres via et pythonscript. I dette scriptet må kollonene reflektere feltene

som hentes ut av nettverkspakkene. Feltene som er obligatoriske i alle tabellene er «Hostname», som

inneholder navnet på sensor som har hentet inn dataene. Datofeltet «Date» er også et obligatorisk datafelt, da

dette benyttes for å utføre operasjoner på dataene. Dette er for eksempel ved visning av data som grafer.

Figur 24 er et eksempel på hvordan et script for å opprette tabellen for HTTP i databaselag 1. For hvordan

man setter opp selve databasen, kan man se i vedlegg D.


import sqlalchemy.types as types from sqlalchemy import DateTime, create_engine, Table, Column, Integer, String, MetaData from sqlalchemy.sql.expression import bindparam from sqlalchemy.sql import select, text from sqlalchemy.interfaces import PoolListener from sqlalchemy.orm import create_session, relation import datetime import psycopg2

#Connect string to posggressql db = create_engine('postgresql+psycopg2://username:[email protected]:5432/layer1') db.echo = False

#Meta data does that everything before metada.create_all() is including in the command metadata = MetaData(db) session = create_session() #metadata.drop_tables()

#This is the table of layer1 HTTP. table_http = Table('HTTP', metadata, Column('id', Integer, primary_key=True), Column('hostname', String), Column('date', DateTime), Column('src', String), Column('dst', String), Column('len', String), Column('sport', String), Column('dport', String), Column('method', String), Column('host', String), Column('useragent', String), Column('statusline', String), Column('location', String), Column('server', String), Column('load', String), ) metadata.create_all()

Figur 24: Script for å opprette databaselag 1 for HTTP.


5.3 CORE

Dette delkapittelet tar for seg delapplikasjonen Core. Core er ansvarlig for behandling av applikasjonsdata

innhentet av sensor, og brukt av Frontend.

Dens hovedoppgave er å legge til rette for analyse og aggregering av applikasjonsdata, slik at Webservice

kan tilgjengeliggjøre disse for presentasjon i Frontend. Core jobber som en bakgrunnsprosess og utfører

behandlingen av data etter gitte tidsintervaller.

Figur 25: Dataflytdiagram som uthever hvor core er plassert.


5.3.1 INTRODUKSJON TIL CORE

Core er en adskilt delapplikasjon i PySniff som er ansvarlig for aggregering av data i databasen. Ingen av de

andre delapplikasjonene benytter Core, men Core er avhengig av en kjørende database. Core kjører som en

bakgrunnsprosess, som på tidsintervall jobber med data i databasen. Dette gjør den ved å aggregere og slette

data som er lagret i databaselag 1.

5.3.2 KRAV TIL CORE

I henhold til kravspesifikasjonen, vedlagt i vedlegg A, skal Core:

Legge til rette for aggregering av applikasjonsdata.

Et tidsintervall skal styre når aggregeringen skal utføres.

Core skal slette eventuell gammel data i databaselag 1, slik at databasen ikke blir full.

Aggregeringen skal bruke et felles pluginbibliotek, og legge til rette for utvidelser i form av flere

plugins.

Core skal kjøre i bakgrunnen og ikke påvirke andre prosesser.

Skal ikke være tilknyttet noen brukerøkt styrt av en bruker.

Funksjonalitet i Core skal være konfigurerbar.

Core skal logge handlinger slik at det er mulig å vite når og hva som utføres. Feilsituasjoner skal

også logges, brukt for feilsøking.


Core er designet med modularitet i fokus slik at den legger til rette for gode utvidelsesmuligheter som resten

av delapplikasjonene i PySniff. Det betyr at det er lett å legge til ny funksjonalitet i form av nye plugins i

pluginbiblioteket som Core kan benytte seg av. I tillegg er det i designet av Core lagt grunnlag for gode

konfigurasjonsmuligheter.

Core legger til rette for å arbeide på applikasjonsdata i både databaselag 1 og databaselag 2. Grunnlaget for

Core er aggregering av applikasjonsdataene som ligger i databasen, og all funksjonalitet utover dette er kun

for å legge til rette for aggregeringen. Selve aggregeringsfunksjonaliteten er i et delt pluginbibliotek.

Core kjører som en bakgrunnsprosess, dette kalles en daemon, og er ikke avhengig av andre programmer.

Dette gjør at Core kan startes og stoppes uavhengig av resten av PySniff.

Kjernefunksjonaliteten i Core er delt i inn i koden for daemon som legger grunnlaget for kjøring av annen

programkode, og egendefinert funksjonalitet i et pluginbibliotek. Applikasjonen er designet slik at

funksjonalitet utover Cores hovedkode kan legges til uten å måtte endre eller integrere med resten av koden i

Core.

Designet til PySniff gjør at Core er selvstendig, og er ikke avhengig av at de andre delapplikasjonene kjører,

bortsett fra databasen. Selv om Core er selvstendig har den ingen funksjonalitet uten en database, og dette

gjør den avhengig av databasen.

5.3.3.1 PLUGINBIBLIOTEK

Core deler mye felles funksjonalitet med Webservice for behandling og kall på data i databasen.

Pluginbiblioteket innholder plugins for forskjellige type nettverksdata. I dette prosjektet er det fokusert på

implementering av HTTP, og det er derfor en plugin for HTTP.

Grunnlaget for å ha et delt pluginbibliotek er mulighet for å samle logikk for arbeid på databasen, slik at

vedlikehold blir effektivisert. Dette hindrer også duplisering av kode som ellers ville vært i både Webservice

og Core.

En plugin inneholder et sett av funksjoner for behandling av data mot databasen. De forskjellige funksjonene

er beregnet for bruk av enten Webservice eller Core, men bruker felles funksjoner for kommunikasjon mot

databasen.


5.3.4 IMPLEMENTASJON

Core består av en bakgrunnsprosess, en daemon, som etter faste tidsintervaller utfører en

aggregeringsprosess. Aggregeringsprosessen behandler og sletter gammel data. Cores daemon holder rede på

tidsintervall, konfigurasjon og loggføring.

For utviklingen av Core er det brukt en rekke forskjellige programvarebibliotek som allerede utgjør deler av

Core, eksempelvis for å håndtere logging eller konfigurasjon. Arbeidet har derfor vært mer i å knytte

sammen løsningen og implementere bruken av allerede utviklede biblioteker. Unntaket er vårt eget bibliotek,

pluginbiblioteket.

Aggregeringsprosessen er et sett av funksjoner som utføres på et tidsintervall. Dette tidsintervallet er definert

i konfigurasjonen, og Cores daemon er ansvarlig for å starte prosessen. Aggregeringsprosessen bruker

pluginbiblioteket for å aggregere data.

5.3.4.1 DAEMON

Hovedprosessen til Core er en bakgrunnsprosess kalt en daemon. Grunnen til dette er at Core skal jobbe

uavhengig av andre applikasjoner og ikke ha noen tilknytning til en brukerøkt styrt av en bruker.

Cores sentrale oppgave er å utføre aggregering av data etter gitte tidsintervall. Det er derfor nødvendig med

en bakgrunnsprosess som jevnlig sjekker tiden, og utfører funksjoner når tiden er inne. Det er ønskelig at en

denne ikke er avhengig av å være tilknyttet en brukerøkt styrt av en bruker, men blir sendt til bakgrunnen

hvor den kjører i stillhet.

Cores daemon er implementert ved bruk av programvarebiblioteket python-daemon», som er en Python-

modul som gir et generelt grunnlag for en implementasjon av en daemon. Ved hjelp av funksjonaliteten

denne gir formes daemonen etter kravene. Daemonen brukt i Core er også i bruk av Sensor, men er ikke like

sentral i dens funksjonalitet som i Core.

Som et alternativ til å implementere en daemon selv, ble det valgt å bruke det som anses som standarden for

en implementasjon av en daemon i Python; modulen «python-daemon». For at en prosess skal kunne sies å

være en daemon, må den oppfylle en rekke betingelser [5],[6]:

Kjøre i bakgrunnen, ikke direkte kontrollert eller tilknyttet en tradisjonell brukerkonto eller

brukerøkt. Det vil si at den kan startes av en bruker, men etter start kjører den uten noen relasjoner

til brukeren.

Det er ingen vanlige grensesnitt til prosessen i form av en terminal, og kan heller ikke kontrolleres

direkte med inndata fra en bruker, og skriver heller ikke ut tekst til en terminal utover start og stopp.

Det finnes flere betingelser som er å finne i «Correct deamon behaviour» [5] og «PEP 3143» [6].

Figur 26 presenterer daemonens hovedløkke, hvor funksjonalitet i Core blir utført. I dette tilfellet består dette

av å kjøre aggregeringsfunksjonalitet ved hjelp av aggregeringsprosessen. Når denne er utført venter

daemonen så lenge som konfigurasjonen angir. Dette betyr at aggregeringen kan utføres hver hele time. Hvis

det oppstår feilsituasjoner, blir dette fanget opp logget via denne funksjonen.


def run(self): """Main daemon loop""" try: cfg.logger.info("PySniff Core started.")

while True: # Sleep remaining time until next frequency freq = cfg.config.getint('Aggregate', 'frequency') time.sleep(freq - (time.time() % freq))

aggregate.process()

# Delete old data in layer1 aggregate.clean_layer1()

except SystemExit: print "PySniff Core stopped." cfg.logger.info("PySniff Core stopped.")

except: cfg.logger.exception("Unexpected error: ")

# Clean up after yourself. cfg.logger.info("PySniff Core shutting down.\n\n\n") cfg.logging.shutdown() sys.exit(1) Figur 26: Uttrekk av kode fra Core sin daemon-løkke.

Et alternativ til å kjøre bruke en daemon er å bruke jobbplanleggeren Cron, som er tilgjengelig på alle Linux-

systemer. Cron gir mulighet til å planlegge såkalte «jobber», eller handlinger, som utføres periodisk og kan

kjøre kommandoer eller scripts. Funksjonaliteten i Core som utføres jevnlig kunne vært gjort med et script

uten daemon og heller brukt Cron, men ved å implementere Core som en daemon har man fullstendig

kontroll i samme program. Dette oppnår man ikke ved bruk av Cron, hvor konfigurasjon og programkode

må deles.

5.3.4.2 AGGREGERING

En sentral del av PySniff er dens evne til å kjøre analyse på sanntidsdata som ligger i databaselag 1.Ved

hjelp av disse dataene vil det være mulig å beregne trender eller normaler for ett system over en gitt

tidsperiode. Teknikken brukt for å analysere og bearbeide data kalles aggregering, og består av å kombinere

eller slå sammen data i grupper eller tidsperioder. Aggregering innebærer også at mengden informasjon

reduseres, slik at historiske data kan tas vares på uten at de tar uhåndterlige mengder med plass.

Aggregeringen består av kall på funksjonalitet i det felles pluginbibliotek bruk av både Core og Webservice.

Funksjonalitet utføres til fastsatte tidsintervaller definert i konfigurasjonen. Aggregeringsprosessen er kalt

«aggregate.py» og er å finne i hovedmappen til Core.

Aggregeringsprosessen startes av Cores daemon. Grunnen til dette er at implementasjonen av daemon, er så

generell at den også kan brukes av Sensor.

I tillegg til å kjøre funksjonalitet til plugins inneholder aggregeringsprosessen en rensefunksjon som sletter

gammel data i databaselag 1. Databaselag 1 inneholder sanntidsdata som kun er ment for bruk i en kort

periode. Dataene som ligger her tar også stor plass da de ikke er aggregert. Det er derfor nødvendig at

utdatert data slettes jevnlig, og dette gjøres da av Core. Tidspunkt for sletting og hva som er for gammel data

defineres i konfigurasjonen.


def clean_layer1():

"""Deletes data older than period from PySniff's layer1

Returns:

True/False depending on success

"""

# Is it cleaning time yet?

cfg.logger.debug("Checking if old data in layer1 should be deleted.")

curr_hour = datetime.datetime.now().strftime('%H')

if curr_hour != cfg.config.get('Aggregate', 'cleaning_time'):

cfg.logger.debug("Not cleaning time. Continuing.")

return False

# Let's clean!

cfg.logger.info("Cleaning up old data in layer1 starting...")

engine = create_engine(cfg.config.get('Database', 'layer1_conn'))

meta = MetaData()

meta.reflect(bind=engine)

too_old = cfg.config.getint('Aggregate', 'too_old')

outdated = datetime.datetime.today() - datetime.timedelta(hours=too_old)

# Reversed so that children are deleted before parents in relations

for table in reversed(meta.sorted_tables):

engine.execute(table.delete().where(table.c.date <= outdated))

cfg.logger.info("Cleaning up old data in layer1 complete.")

return True Figur 27: Programkode for å slette gammel data i databaselag 1.

Figur 28 tar for seg bruken av aggregeringsprosessen i Core. Denne viser aggregeringsprosessen blir kalt av

Core daemon i et tidsintervall. Aggregeringsprosessen som benytter pluginbiblioteket som behandler data i

databasen. Slettingen av gammel data utføres direkte mot databasen.

Figur 28 Bruk av aggregeringsprosessen i Core, og dens relasjoner til andre deler i PySniff.

5.3.4.3 KONFIGURASJON

Cores funksjonalitet er konfigurerbar ved hjelp av en sentral konfigurasjonsfil. I denne defineres innstillinger

som brukes for å styre Cores oppførsel. Det er ønskelig med konfigurasjonsbasert oppsett slik at det legges


til rette for endringer uten at programkoden må endres direkte. Å manuelt endre innstillinger i form av å

endre på programkoden er vanskelig å vedlikeholde.

Ved å skille innstillingene ut i en konfigurasjonsfil, er det mulig å gjøre endringer selv om programmet

kjører i et produksjonsmiljø. Dette gjør det også mulig å ha forskjellige konfigurasjonsfiler for de

forskjellige applikasjonsmiljøene.

I disse konfigurasjonsfilene kan felles definisjoner og innstillinger lagres, slik at de kan benyttes i

funksjonaliteten i Core. Dette kan for eksempel være konfigurasjon for tilkobling til database.

Konfigurasjon for Core daemon inneholder blant annet tidsdefinisjoner nødvendige for å styre

aggregeringsfunksjonalitet. Dette innebærer hvor ofte aggregering skal utføres, hva som er å beregne som for

gammel data og når disse skal slettes.

Konfigurasjonsfilen leses av Core daemon ved oppstart, hvor innstillingene gjøres tilgjengelig for

funksjonaliteten. Implementasjonen av konfigurasjonsfilen bruker en standardmodul i Python ved navn

ConfigParser. Innstillingene er definert i den kjente konfigurasjonsstandarden INI som er brukt både på

Windows- og Linux-plattformer. INI er lett å arbeide med sett fra en utviklers ståsted, men er også lett å lese

for mennesker. Figur 29 viser konfigurasjon til Core på formatet INI.

[Aggregate] cleaning_time = 03 ; 24 hour format frequency = 3600 ; seconds too_old = 24 ; hours

[Daemon] stdin_path = /dev/null stdout_path = /dev/tty stderr_path = /dev/tty pidfile_path = /var/run/pysniff/core.pid pidfile_timeout = 5

[Database] layer1_conn = postgresql+psycogp2://user:password@host:port/layer1 layer2_conn = postgresql+psycogp2://user:password@host:port/layer2

[Logging] logconfig = log.ini logger = dev Figur 29 Hovedkonfigurasjonsfilen i Core. [] representerer kategori eller gruppering, og innstillingene er på formen

"nøkkelnavn=verdi".

Det ble vagt å benytte ConfigParser siden denne tilbyr en fleksibel løsning for å håndtere konfigurasjon og

konfigurasjonsfiler. Siden dette er en standardmodul i Python er det ikke behov for å måtte installere eller

sette opp noe ekstra. Alternativet hadde vært å finne opp hjulet på nytt og håndtert innlesing og definering av

konfigurasjonsfilen selv, men dette er unødvendig. Ved å følge standarden er det også lettere for andre å

sette seg inn i programmet.

ConfigParser har ansvar for å lese konfigurasjonsfilen og gjøre innholdet tilgjengelig i resten av Core. For

forklaringens skyld er Figur 30 forenklet og modifisert, for å gjøre den lettere å lese.


# Inkluderer modulen for ConfigParser

import ConfigParser

# ConfigParser startes og leser konfigurasjonsfil

config = ConfigParser.ConfigParser()

config.read('dev.ini')

# Eksempel på oppkobling til databaselag 1, hvor adressen hentes

# fra konfigurasjonsfilen. Funksjonene brukt her er fra SQLAlchemy.

engine = create_engine(config.get('Database', 'layer1_conn'))

meta = MetaData()

meta.reflect(bind=engine) Figur 30: Konfigurasjon startes, leses og brukes for et parameter for å koble til en database.

Adressene til databaselagene er listet i konfigurasjonsfilen, slik at de gjøres tilgjengelige for all

funksjonalitet i Core og aggregeringsfunksjoner den utfører. Alternativet ville vært at adressene skrives

direkte i hver funksjon, noe som ville være vanskelig å både utvikle og vedlikeholde.

Til slutt er det også en peker til konfigurasjonsfilen for logging i Core.

5.3.4.4 LOGGING

Logging av status og hendelser i en applikasjon som PySniff er utrolig viktig, også for Core. Dette er

nødvendig slik at det er mulig å sjekke hva og når ting utføres. Hvis det skulle komme en feilsituasjon, vil

dette også logges og være til hjelp ved feilsøking. Det utføres logging i både Cores daemon og

aggregeringsprosessen.

For loggføring er det valgt å bruke en standardmodul for logging i Python kalt «logging”. Denne gir all

funksjonalitet som en skulle ønske, med forskjellige loggnivåer og separat konfigurasjonsfil.

Core logger status og hver ting den gjør. Informasjonen er delt opp i loggnivå slik at det er mulig å skille på

hva som er informasjon, feil eller for debugging. Figur 31 er et uttrekk av loggfilen som Core logger til.

Tabell 4 beskriver disse linjene, og hva de separerte kolonnene representerer.

Innhold Beskrivelse

2013-04-09 03:25:50,592 Timestamp, dato og tid på standardformat for Python.

dev Navnet på loggkonfigurasjonen brukt. Benyttes forskjellig for forskjellige bruksområder, eksempelvis en for utvikling og en for bruk i produksjon.

INFO DEBUG ERROR

Loggnivået, beskriver hva logglinjen inneholder og brukes for å skille på viktighetsgraden i logglinjen.

Tabell 4: Representasjon av innholdet i en logglinje.

Logglinjene presentert under er et eksempel på normal oppførsel av Core.

2013-04-09 03:25:50,592 dev INFO PySniff Core started. 2013-04-09 04:00:00,093 dev INFO Aggregate process starting... 2013-04-09 04:00:00,093 dev INFO Aggregate process complete. 2013-04-09 04:00:00,094 dev DEBUG Checking if old data in layer1 should be deleted. 2013-04-09 04:00:00,094 dev INFO Cleaning up old data in layer1 starting... 2013-04-09 04:00:01,265 dev INFO Cleaning up old data in layer1 complete. 2013-04-09 05:00:00,068 dev INFO Aggregate process starting... 2013-04-09 05:00:00,068 dev INFO Aggregate process complete. 2013-04-09 05:00:00,069 dev DEBUG Checking if old data in layer1 should be deleted. 2013-04-09 05:00:00,069 dev DEBUG Not cleaning time. Continuing.

Figur 31 Et sett med normale logglinjer for Core.


Figur 32 viser hvordan loggeren benyttes i koden. I dette tilfelle logges en infolinje til fil med tekst om at

Core er startet.

logger.info("PySniff Core started.")

Figur 32: Eksempel på hvordan man benytter loggeren.

Core logger også feilsituasjoner med denne loggeren, og har fordelen at den tar med seg fulle feilmeldinger,

såkalte traceback. Traceback representerer gangen i programkoden, og hjelper med feilsøking.

Feilmeldinger logges også, og har fordelen at den tar med seg fulle feilmeldinger, såkalt traceback som

representerer gangen i programkoden. Dette hjelper for feilsøking under utvikling samt vise eller varsle hvis

eksempelvis databasen skulle gå ned.

5.3.4.5 DATAFLYTDIAGRAM FOR CORE

Figur 33 viser hvordan Core fungerer som en applikasjon. Det er fra Core daemon hvor alle de andre

prosessene startes opp. Aggregeringsprosessen bruker pluginbiblioteket som igjen behandler data i

databasen. Denne aggregeringsprosessen er startet av daemon, og bruker daemon sin konfigurasjon og

logging.

Figur 33: Illustrasjon av flyten til Core.


5.4 WEBSERVICE

Dette delkapittelet gir en oversikt over webservicen i PySniff. Webservicen er den delen av applikasjonen

som henter ut data fra databasen, for deretter å sende dataene videre til for eksempel visning i Frontend.

Kapittelet tar for seg arkitekturen i detalj. Det vil være til hjelp når man skal ta webservicen i bruk, og gi

nødvendig kunnskap for å kunne utvikle nye plugins.

Videre blir det gitt en oversikt over de ulike rammeverkene som har blitt benyttet, samt alternativene som

har blitt forkastet i prosessen. Utfordringer underveis i prosjektet i forbindelse med utvikling av

webservicen, er også dokumentert her.

Figur 34: Dataflytdiagram som uthever hvor webservice er plassert.


5.4.1 INTRODUKSJON TIL WEBSERVICE

Webservicen er den delen av PySniff som sørger for at data alltid er tilgjengelig for presentasjon i frontend.

Webservice er avhengig av en database med nettverkspakker, noe som sensor, beskrevet tidligere, sørger for.

Webservicen er pluginbasert, det vil si at det skrives plugins for ulik type nettverkstrafikk. I vårt prosjekt er

det en plugin for HTTP-trafikk som er aktuelt, men på sikt ønskes det flere plugins, som for eksempel SQL.

5.4.2 KRAV TIL WEBSERVICE

I henhold til kravspesifikasjonen, vedlagt i vedlegg A, skal webservice

Webservice skal gjøre kall mot databaselag 1 og databaselag 2.

Feilsituasjoner og statusinformasjon skal logges til fil

Et kall mot webservice skal resultere med serialiserte data som JSON.

Webservice skal benytte plugins for ulike typer nettverkstrafikk

o Hver enkelt plugin skal kun være beregnet for en spesifikk type nettverkstrafikk

o Disse skal ligge i en egen mappe, lib/plugins

Variabler som IP, port, osv skal ligge i konfigurasjonsfiler.


Webservice har ikke noe brukergrensesnitt, så alle som benytter Webservice gjør dette via HTTP-kall. Dette

vil typisk være fra Frontend. Webservicen er bygget opp slik at det er mange forskjellige funksjoner som

håndterer HTTP-kallene. For at det kan utføres operasjoner for å returnere ønsket data, må Webservice

oversette dette til type, plugin, funksjon og eventuelle parametere fra HTTP-kallet.

For at Frontend skal kunne vise data, må disse hentes fra databasen. For å gjøre dette på en god og effektiv

måte, fungerer webservice som et bindeledd mellom Database og Frontend. Frontend sender en forespørsel, i

form av en link, og Webservice sender data tilbake til Frontend fra Databasen. Webservice vil kunne

kommunisere både databaselag 1 og databaselag 2. Databaselag 1 vil inneholde all HTTP-trafikk for en

kortere periode, mens databaselag 2 vil inneholde aggregerte data for en lengre periode.

Figur 35: Flyt hvor kall kommer fra Frontend til Webservicen, før data blir returnert fra Databasen til Frontend.


5.4.3.1 STRUKTUR

Webservicen består i hovedsak av to deler. Selve webservice-klassen, webservice.py, og dens plugins, som

ligger i mappen lib/plugins. Plugins i lib/plugins er felles for webservice og core. I pluginene er

databasetilknytningen felles, mens metodene ellers ikke nødvendigvis benyttes av begge. Alle filer i denne

mappen blir automatisk importert som plugins av webservice.py, og skal navngis med hva slags

nettverkstrafikk den håndterer, for eksempel http.py. I tillegg kommer konfigurasjonsfiler for logging og

webservice. Etter hvert vil hver enkelt plugin ha sin egen konfigurasjonsfil.

Oppgaven til webservice.py består i å definere hvordan URLene skal se ut, importere plugins, og starte

webservicen.

Figur 36: Illustrasjon over filstrukturen til webservice.

For å importere plugins i webserivce.py benyttes koden vist i Figur 37. Den første linjen legger til lib/plugins

i «stien», slik at webservice kan finne de. Deretter kommer en linje for å spesifisere hvilke plugins som skal

lastes. Dette er gjort av praktiske, og sikkerhetsmessige årsaker. Det kan være plugins som ikke er

kompatible, eller det ikke er lagt inn støtte for i andre deler av applikasjonen. Dette legger også til et ekstra

sikkerhetstrinn slik at det ikke er mulig å laste opp ondsinnede filer, som igjen blir lastet inn av webservice.

Deretter importeres pluginene som både ligger i lib/plugins, og er spesifisert i valid_plugins.

sys.path.append("../lib/plugins/")

valid_plugins = ['http', 'sql'] # Plugins that will be imported

plugins = map(__import__, valid_plugins)

Figur 37: Kode som benyttes for å importere plugins

For å «montere» pluginene i CherryPy brukes koden i Figur 38. Denne går gjennom variabelen «plugins»,

opprettet i Figur 37. For alle pluginene i plugins, monteres disse i CherryPy sitt filtre, i mappen plugin.

URL’en denne genererer for å nå funksjonene i for eksempel HTTP-pluginen vil bli /plugin/http/, og alle

funksjonene som har «@cherrypy.expose» og «@tools.json_out()» foran seg vil gjøres tilgjengelig.

for idx, p in enumerate(plugins): # for loop for loading the plugins cherrypy.tree.mount(p.get_class(), "/plugin/" \ + valid_plugins[idx], config)

Figur 38: Uttrekk av kode som monterer plugins i CherryPy-koden.


5.4.3.2 IMPLEMENTASJON AV MODULER

Hver enkelt plugin må inneholde kode for tilkobling til databaselaget. Det er fordi det kan eksistere egne

tabeller i databasen for forskjellige typer nettverkstrafikk. Hver enkelt funksjon i pluginen, som skal være

tilgjengelig utenfra, må inneholde «@cherrypy.expose» og «@tools.json_out()». Dette er for at CherryPy

skal oppdage funksjonen, og vite hva slags data som blir returnert fra denne, som i dette tilfellet er JSON.

For å ta for oss hvordan en modul benyttes tar vi for oss en forespørsel som kunne vært sendt fra Frontend.

Denne er vist i Figur 39 og er formulert som en webadresse. Denne webadressen inneholder all

informasjonen som er nødvendig for at funksjonen skal kunne hente data som blir etterspurt. Webadressen er

beskrevet i detalj i Tabell 5.

127.0.0.1:8080/plugin/http/hostname_count/5/2013-04-14T15:11:00/0 Figur 39:Viser et kall fra Frontend til Webservice

Del av webadresse Beskrivelse

127.0.0.1:8080 Adressen til webservicen

/plugin/ Beskriver at den skal sendes til en plugin i webservicen, og ikke en funksjon som finnes direkte i Webserivce.

/http/ Beskriver at det er pluginen «http» som skal benyttes

/hostname_count/ Dette er funksjonen som befinner seg i http-pluginen

/5/ Dette er antallet med returverdier som man ønsker

/2013-05-14T15:11:00/ Datoformatet som beskriver hvilken dato som data skal hentes fra. Dette er strukturert på ISO 8601[7] format.

/0 Dette er sluttidspunktet, og sier at all data fra starttidspunktet til nå skal hentes.

Tabell 5: Tabell som beskriver de delene som er presentert i webadressen.

Webadressen som her er beskrevet vil bli sendt videre til en funksjon i HTTP-pluginen. Denne funksjonen,

som er illustrert i Figur 40 er et eksempel hvordan slike plugins skrives. Denne funksjonen får inn

parameterene «limit», «start» og «end», og vil ut i fra dette generere en spørring til databasen ved bruk av

SQLAlchemy.

@tools.json_out() @cherrypy.expose def hostname_count(self, limit,start="0", end="0"): start = self.format_start(start) end = self.format_end(end) try: session = self.load_session() query = session.query(HTTP.host, func.count(HTTP.host) \ .label('count')).filter(HTTP.date>=start, HTTP.date<=end) \ .group_by(HTTP.host).order_by(desc('count')).limit(limit) session.close() result = [{ 'hostname':res.host, 'count':res.count }for res in query] return result except Exception, err: logger.error(err) return [] Figur 40: Funksjon som henter antall forskjellige hostname, og returnerer antallet.


Hver enkelt funksjon i de ulike pluginene skal returnere data for grafisk visning i Frontend. Det er viktig at

strukturen på disse holder seg til en standard, for at det skal bli enklest mulig å ta i bruk funksjonene i

Frontend. Dataene som returneres vil være i form av JSON-strenger, JSON-objekter var en stund

foretrukket, men ble forkastet. Grunnen til dette er beskrevet i avsnittet om utfordringer. Figur 41 viser hva

som returneres fra Figur 40 når kallet ser ut som det gjør i Figur 39. Som man kan se av Figur 41, starter og

avslutter JSON-strengen med «[]», og innenfor disse klammene ligger dataene i kommaseparerte

krøllparanteser.

[ { "count": 3801, "hostname": "Host: direkte.vg.no\r\n" }, { "count": 1431, "hostname": "Host: logc189.xiti.com\r\n" }, { "count": 260, "hostname": "Host: notify4.dropbox.com\r\n" }, { "count": 224, "hostname": "Host: fil.nrk.no\r\n" }, { "count": 144, "hostname": "Host: ur8c.tidsbanken.net\r\n" } ] Figur 41: Returverdier fra hostname_count(5, 2013-04-14T15:11:00,0)

5.4.3.3 VALG AV RAMMEVERK

RAMMEVERK BESKRIVELSE

Flask[8] er et mikrorammeverk for Python, med en innebygd server. Som rammeverk er Flask et godt valg, men når det kommer til serverdelen, er ikke denne stabil nok til å kjøre kontinuerlig. Dette fordi det er en utviklingsserver. Siden det er ønskelig å samle server og rammeverk i ett, blir derfor Flask valgt bort. Hvis ikke kunne vi brukt Flask som rammeverk, og kombinert dette med serverfunksjonaliteten til for eksempel CherryPy.

CherryPy[9] er et minimalistisk rammeverk for Python. Dette har også en innebygd webserver, akkurat som flask. Det har i skrivende stund eksistert i syv år, og er godt utprøvd, både til utvikling og i produksjon. I tillegg til å være raskt og stabilt, er det også svært enkelt å bruke. Oppbygging av URL’er er tett knyttet opp til strukturen av koden, og derfor enkel å strukturere. Valget av denne ble blant annet basert på anbefalinger fra stackoverflow.com[10], og en sammenligning av ulike webservere gjort av nichol.as[11].

furl 0.3.3

Furl[12] er et pythonbibliotek for manipulering av URL’er. Dette var et alternativ tidlig i prosjektperioden, og ble vurdert brukt på grunn av måten den kan endre URL’er på. Det ble etter hvert klart at dette ikke var nødvendig, siden CherryPy sin håndtering og generering var akkurat det vi trengte.

Twisted[13] er et kraftig og omfattende rammeverk. Det støtter mye funksjonalitet utover kravene vi stiller, og er dermed større enn nødvendig for vårt prosjekt. Siden det er så omfattende, har det en bratt læringskurve. Det er hovedgrunnen til at dette ble valgt bort. En annen grunn er at testene gjort av nichol.as [11] viser at Twisted ikke helt klarer å holde følge med CherryPy når presset på webserveren øker i form av antall forespørsler.


cornice 0.12

cornice14 skal på samme måte som CherryPy, være enkelt å sette seg inn i. Det er relativt nytt, og det har vist seg å være vanskelig og finne tilstrekkelig dokumentasjon på stabilitet, noe som er svært viktig i produksjonsmiljøet for vårt prosjekt. Samtidig er det relativt nytt, første versjon kom mot slutten av 2011, og nyeste versjon er fra 2012. På tidspunktet cornice ble nevnt som et alternativ, hadde allerede utviklingen av webservice startet med CherryPy som rammeverk/webserver.

Tabell 6: Tabell over rammeverk som har blitt undersøkt for bruk av webservice.

5.4.4 UFORDRINGER

5.4.4.1 SQLITE VS. POSTGRESQL

Da arbeidet med spørringene mot databasen startet, var databaselag 1 en SQLitedatabase. Spørringene med

SQLAlchemy ble skrevet mot denne databasemotoren. Da det ble klart at SQLite måtte byttes ut til fordel

for PostgreSQL, førte dette til at spørringene ikke fungerte.

Dette gjorde det utfordrende å skrive spørringene som var tenkt til første produksjonssetting. PostgreSQL

har andre formuleringer for enkelte funksjoner enn det SQLite har. På grunn av dette var ikke de første

spørringene kompatible med PostgreSQL. PostgreSQL krever at alle kolonner i spørringen må være med i

enten groupby eller having. Det betydde endringer i hva funksjonene returnerer, noe som førte til at

applikasjoner som benytter Webservice måtte endre hvordan data ble håndtert.

5.4.4.2 JSON OBJEKTER VS. JSON STRENGER

På grunn av store variasjoner på output, har det vært mest hensiktsmessig å returnere data i form av JSON

strenger i stedet for JSON objekter. Hvis returverdier bare hadde bestått av kolonner fra databasen, ville det

ikke vært noe problem å bruke objekter, men siden det her brukes aggregeringsfunksjoner, som for eksempel

count, er det vanskelig å lage en universal metode for å opprette objekter av spørringene.

5.4.5 KONFIGURASJON

5.4.5.1 INSTALLASJON

For å kunne kjøre webservice, kreves det at Python 2.3.7 at er installert på maskinen. I tillegg til dette er det

behov for å ha installert de nødvendige pakkene for å benytte CherryPy og SQLAlchemy. Installasjonen av

dette er beskrevet i vedlegg D.

5.4.5.2 KONFIGURASJON

Filen server.conf er delt opp i ulike deler, som kan refereres til. Delen «global» inneholder IP og port hvor

Webservice skal kjøre, disse er det CherryPy som benytter seg av når den skal starte webserveren.

Det er også en egen konfigurasjonsfil for logging, som blant inneholder hva som skal logges, når for

eksempel funksjonen «logger.info» kalles. Figur 42 viser et uttrekk av hvordan konfigurasjonsfilen for

logging i webservice er strukturert.

[logger_prod]

level=INFO

handlers=webserviceHandler

qualname=prod

propagate=0 Figur 42: Uttrekk av konfigurasjonen til loggingen i Webservice.


5.5 FRONTEND

Dette delkapittelet tar for seg delapplikasjonen Frontend. Frontend er den delen som presenterer, og gjør

innhentet data tilgjengelig for sluttbruker.

Frontend er avhengig av resten av PySniff, da data blir tilgjengeliggjort av Webservice, som er beskrevet i

forrige delkapittel. Produktet som sluttbruker benytter seg av er presentert i dette delkapittelet.

Figur 43: Dataflytdiagram som uthever hvor Frontend er plassert.


5.5.1 INTRODUKSJON AV FRONTEND

Etter at sensorene i nettverket har hentet inn og sendt data til databasen, skal dataene være tilgjengelig for å

kunne presenteres. Frontend har som oppgave å gjøre disse dataene synlige for sluttbruker.

Ettersom data hentes inn via Webservice, ligger ikke den mest avanserte prosesseringen av dataene på

Frontend. Dette er fordi dataene allerede skal være prosessert, og tilgjengeliggjort for presentasjon. Dette

gjør at Frontend effektivt kan generere grafisk presentasjon av data.

Meningen med Frontend er å gjøre det mulig og sette illustrasjon av nettverkstrafikken i produksjonsmiljøet.

I dette prosjektet er det fokusert på HTTP kall i oppdragsgivers nettverk. Dette gjør det mulig å illustrere

trafikk i fra oppdragsgivers applikasjoner, som både kan være selvbetjente systemer, som nettbank, eller

betjente systemer hvor kundebehandlere jobber.

Figur 44: Illustrasjon av de avanserte komponentene i Frontend, og hvordan dette er i relasjon til de andre delapplikasjonene.

5.5.2 KRAV TIL FRONTEND

I henhold til kravspesifikasjonen, vedlagt i vedlegg A, skal Frontend

Vise statistikk i from av kall som feiler.

Oppdateres automatisk med nye data minimum hvert minutt.

Støtte nye nettlesere som siste versjon av Chrome, Firefox og Internet Explorer.

Benytte data fra webservice

Innlasting av sider skal ta mindre enn 5 sekunder, og bør ta mindre enn 2 sekunder.


Frontend skal være et tilgjengelig verktøy for alt driftspersonell som overvåker driftssituasjonen hos

oppdragsgiver. Det skal ikke være behov for å ha programvare installert på maskinen for at dette skal virke.

Som følge av dette er implementasjonen av Frontend designet som en webapplikasjon. Denne

webapplikasjonen skal kunne plasseres i et lukket nettverk uten direkte tilgang til internett. Det gjør at alle

nødvendige ressurser, som rammeverk og grafikk, må være tilgjengelig lokalt.

Da PySniff er en intern applikasjon, er det behov for å gjøre Frontend så fleksibelt som mulig når det gjelder

videre utvikling og vedlikehold. Dette har vært bakgrunnen for mange av designvalgene som har blitt tatt

under planleggingen av Frontend.

Oppdragsgiver har også flere andre applikasjoner som benyttes til kontinuerlig overvåking av

driftsituasjonen. Hovedforskjellen fra Frontend til disse applikasjonene er mulighetene for å implementere

ny funksjonalitet, da dette ikke er mulig i de andre eksisterende overvåkingssystemene. Dette er et av

punktene som skal effektiviseres med designet til Frontend, og ikke være til hinder for å perfeksjonere

driftsovervåkingen.


5.5.3.1 BRUK AV RAMMEVERK

Det er mange grunner til å benytte rammeverk i dette prosjektet. En av de fundamentale grunnene er ønsket

om å benytte et av de støttede programmeringsspråkene til oppdragsgiver, nemlig Python. Python benyttes

også i resten av prosjektet, og det er derfor en fornuftig avgjørelse å benytte dette også for Frontend.

Det er mange alternativer til webrammeverk for bruk med Python. De største er Pyramid (tidligere Pylons)

og Django. Vi benytter i dette prosjektet Django, da dette er et rammeverk med mye innebygget

funksjonalitet.

Tabell 7 beskriver de forskjellige rammeverkene som er benyttet.

Rammeverk Beskrivelse

Dette er et høynivå webrammeverk, som er designet for å kunne utvikle dynamiske websider på en effektiv måte. Django er skrevet i, og benytter Python, og er på mange måter tilsvarende ASP.NET MVC, som er Microsoft sitt webrammeverk. Valget av Django er basert på tidligere bruk hos oppdragsgiver, samtidig som det har meget god dokumentasjon, i forhold til andre rammeverk som Pyramid.

Bootstrap er et front-end rammeverk med mottoet «Sleek, intuitive, and powerful front-end framework for faster and easier web development». Det er skrevet av Twitter, holder meget høy kvalitet, og er benyttet i veldig mange webprosjekter. Bootstrap er valgt da dette ikke overkjører gjeldende standarder, og må eksplisitt aktiveres for HTML elementer. Alternativet er Flat UI, men ble valgt bort grunnet stilen på designet.

jQuery er et rammeverk skrevet i JavaScript. Dette er et veldig utbredt rammeverk som benyttes i stor grad i web 2.0 applikasjoner. jQuery har støtte for de fleste nettlesere, samtidig som det er veldig lite i størelsesmessig orden. Det gjør det til et meget effektivt og fornuftig JavaScript-bibliotek. jQuery kan benyttes til å hente data dynamisk til brukeren, og skape en bedre brukeropplevelse.

NVD3 og D3.js

Både Nvd3.js og D3.js er Github prosjekter for «data-driven documents». Nvd3.js er et tillegg til D3.js, som er et grafikkbibliotek skrevet og drevet med JavaScript. D3 er et kraftig verktøy for å kunne presentere data dynamisk i nettleseren, men det er omfattende å sette opp grafer som det er mulig å benytte flere ganger med forskjellige type data. Dette gjør Nvd3 noe med, og gjør det enklere å sette opp grafer som kan ta flere forskjellige typer data og gjenbruke samme graf. Det er mange andre rammeverk for JavaScript grafer som er blitt undersøkt, men felles for de alle er at de gode er bundet av lisens.

Requests Request er et HTTP bibliotek til Python som gjør det mulig å hente data fra websider over HTTP på en enkel og god måte. Dette benyttes da standardbiblioteket til Python er utdatert på dette området.

Tabell 7: Tabell som tar for seg de benyttede rammeverkene i Frontend.

Rammeverket Django er benyttet for å legge grunnlaget for hele webapplikasjonen, mens de andre

rammeverkene er et tillegg for å utbedre funksjonaliteten både til klientsiden, og server siden.

Requests er det eneste tillegget som er et rent Python bibliotek, noe som vil si at det går an å benytte i alle

typer pythonprogrammer. Det Requests gjør er å hente inn websider, på samme måte som en nettleser, og

gjør det mulig å lese innholdet som er på denne siden. Dette gjør at det er mulig å hente data fra

webservicen.

5.5.4 UTVIKLING AV FRONTEND

Det helhetlige designet til PySniff er viktig for hvordan Frontend er strukturert. Frontend er en

webapplikasjon som skal illustrere data, men er av den grunn avhengig av å kunne kommunisere med resten


av PySniff. Dette gjøres med webservicen, men før data kan bli hentet via denne, er det mange andre

komponenter som er nødvendige.

Django som webrammeverk benytter model-view-controller (MVC) arkitetur. Det betyr at det er en

funksjonell lagdeling som da vil definere hvordan Frontend utvikles.

Komponentene i MVC arkitetkruen har følgende funksjoner:

Model: Holder struktur på dataene, som kan relateres og samordnes med databaser. Modellen er et

objekt som har dataene.

View: Presentasjonen av data til brukeren.

Controller: Den essensielle komponenten i applikasjonen. Denne mottar og prosesserer hver

forespørsel som sendes til Frontend. Denne kan hente data fra modellen eller fra en annen

datastruktur og sende disse videre til generering av HTML.

Django har valgt å navngi komponentene i MVC strukturen på en annen måte. Det gjør at i mange prosjekter

hvor Django benyttes er model-view-controller (MVC) oversatt til model-view-template. Forskjellen er at

view har den samme funksjonaliteten som controller og templaten har den samme funksjonaliteten som

viewet. Dette er en fordel å vite om når man tidligere er kjent med andre rammeverk som benytter MVC.

Ved å benytte MVC arkitektur vil logikken og presentasjonen være adskilt og gjøre strukturen av

programmet mer ryddig. Etter designfasen til PySniff innføres leddet mellom Database og Frontend som en

webservice. Dette er en av grunnene til at «model» vil være lite benyttet.

Webservicen fungerer som en abstraksjon av «business logic layer». Business logic layer er en måte å

adskille kritisk funksjonalitet. I PySniff vil dette være prosesseringen av dataene hentet fra Databasen.

Resultatet av dette er at kode for logikk blir samlet på ett sted, og dette minsker duplikering av kode.

Det er fortsatt en del kode som skal implementeres i Frontend for å få Django til å kjøre optimalt, og for å

kunne presentere de data som er tilgjengelig. Figur 45 illustrerer hvordan data blir prosessert fra en

forespørsel blir sendt til Frontend og til den returneres til klienten. Disse punktene blir gjennomgått videre i

dette delkapittelet.

Figur 45: Illustrerer komponenter i Frontend som er vesentlig for dataflyt.

5.5.4.1 KONFIGURASJON AV WEBADRESSER

Konfigurasjon av webadresser er en standard konfigurasjon som kreves av Django. Denne konfigurasjonen

sjekker webadressen mot en liste av regulære utrykk. Et regulært utrykk er en måte å skrive konsise og

fleksible setninger, som gjør det mulig å sammenlikne to tekststrenger for å finne en likhet. Dette gjør at det

er mulig å lage enkle og informative webadresser, som er beskrevet av internetts grunnlegger Tim Berners-

Lee i en artikkel hos w3 [15].


Utdraget av koden under kommer fra urls.py som er konfigurasjonen for disse webadressene. De spesifike

linjene refererer til en funksjon i viewet, som dataene vil bli videresendt til. Hvis adressen som sendes til

Frontend er «http://localhost/api/plugin/http/funksjonsnavn», vil denne bli vil denne bli fanget opp av

funksjonen med plugin=http og function=funksjonsnavn.

Dette gjør at det går an å lage adresser på alle mulige måter, som er enkle og informative.

PySniff/urls.py

from django.conf.urls import patterns, include, url

from PySniff.apps.main import views

urlpatterns = patterns('',

# PySniff spesific

url('^$', views.home),

url('âpi/plugin/(?P<plugin>\w+)/(?P<function>\w+)/(?P<param>.*)$', views.api_plugin),

url('âpi/plugin/(?P<plugin>\w+)/(?P<function>\w+)/$', views.api_plugin),

Figur 46 er et utdrag fra URL konfigurasjonen og illustrerer hvordan en adresse blir sammenliknet for å finne korrekt funksjon for

håndtering av forespørselen.

Tabell 8 beskriver de forksjellige tegnene som er mulig i dette regulære utrykket. Hentet fra «The Django

Book»[16]

Symbol Matcher

. (dot) Ett enkelt tegn \d Ett enkelt tall [A-Z] Bokstaver mellom A til Z i store bokstaver [a-z] Bokstaver mellom A til Z med små bokstaver [A-Za-

z] Bokstaver mellom A til Z med bade store og små bokstaver

+ Ett mer av det forrige utrykket (eksempel: \d+ matcher ett eller flere tall) [^/]+ Matcher alle tegn frem til, men ikke inkludert skråstrek. ? Null eller en av det forrige utrykket (eksempel: \d? matcher ingen eller ett tall) * Ingen eller fler av det forrige utrykket (eksempel: \d* matcher ingen, en eller flere

enn ett tall) {1,3} Tall mellom 1 til 3 inklusivt disse tallene. Tabell 8: Tabell som viser symbolene brukt av de regulære utrykkene i URL konfigurasjonen.

5.5.4.2 VIEW

View er den delen av applikasjonen som håndterer logikken når operasjoner skal utføres. Etter at en

webadresse sendt videre fra url konfigurasjonen blir den sendt videre til den funksjonen som er definert for

den enkelte webadressen. Figur 47 vises et eksempel på en slik funksjon.

Denne funksjonen får paramtere fra webadressen og lagret i de lokale variablene «requests», «plugin»,

«function» og «param». «Param» blir kun fylt ut hvis det er noe data i denne. Det viktige her er at vi

oppretter en stream hvor dataene kan bli hentet fra. «Stream» er en instans av et bibliotek skrevet for

Frontend for å kommunisere med Webservice. I dette eksempelet returneres en HTTP respons med data

hentet fra Webservicen. Dette gjør at funksjonen kan hente data fra websiden, men via et dynamisk

konfigurert «api», som gjør at det ikke må sendes med noen adresser eller konfigurasjon til brukeren.


PySniff/apps/main/view.py

def api_plugin(requets, plugin, function, param=None):

log = logging.getLogger("main")

log.info('Getting data from webservice')

stream = ws.webservice()

if(param==None):

data = stream.api_plugin(plugin, function)

else:

data = stream.api_plugin(plugin, function, param)

return HttpResponse(data, mimetype='application/json')

Figur 47: Viser en funksjon i «view» som sender parametere til webservice funksjonen, som spør webservice. Denne returnerer en

nettside med «json», som er en måte å strukturere serialisert data på.

5.5.4.3 WEBSERVICE

Webservicen blir intergrert i Frontend ved bruk av et bibliotek til Python som heter «Requests». Dette rammeverket gjør det mulig å gjøre spørringer, eller «requests» mot nettsider og hente dataene fra disse. Biblioteket som skal håndtere kommunikasjonen med webservice er lokalisert under en egen mape, «PySniff/libs/ws/». Det er mappestrukturen som avgjør hvordan forskjellige pakker inkluderes i et pythonprogram, og dette er en ryddig måte å si at dette kan benyttes av alle deler av Frontend. Eksempelet illustrert i Figur 48 viser et kall mot webservicen. Denne funksjonen henter data fra webservicen basert på de parametere den får inn, og er en veldig fleksibel funksjon i forhold til disse parametere. Denne funksjonen er en ekstensjon av webservicen, som gjør det mulig å skrive dynamisk kode, med kun én konfigurasjon for å koble til en webservice. Dette gjør at ved å spørre på webadressen «/api» under Frontend. De parametere som kommer etter dette i webadressen sendes videre til webservice. Skriver man inn «http://localhost/api/plugin/http/funksjonsnavn/10» på frontend siden vil adressen «http://webservice/plugin/http/funksjonsnavn/10» sendes videre til webservice. Figur 48 benytter rammeverket Requests til å hente disse dataene fra webservicen, og gjør det da mulig å feilhåndtere i mye større grad, enn med tilkobling direkte til Webservice. Dette gjøres først og fremst ved å sette en timeout på spørringen på 30 sekunder, men også håndtere hvis det ikke er noe data som returneres.


from django.conf import settings # Settings for page

import urllib2 # Std. url lib

import json # Std. json lib

import requests # Requests library from pypi

import logging

class webservice:

log = logging.getLogger("main")

def __init__(self):

def api_plugin(self, plugin, function, parameter=None):

try:

if(parameter != None):

r = requests.get(settings.WEBSERVICE_URL + '/plugin/' + plugin + '/' +

function + '/' + parameter, timeout=settings.WEBSERVICE_TIMEOUT)

else:

r = requests.get(settings.WEBSERVICE_URL + '/plugin/' + plugin + '/' +

function, timeout=settings.WEBSERVICE_TIMEOUT)

if(r.status_code == requests.codes.ok):

self.log.info("Webservice connection plugin=" + plugin + " func-

tion="+function + " params="+parameter + " response="+str(r.status_code))

return r.text

else:

self.log.warn("Error returned from webservice: Statuscode=" +

str(r.status_code) + " /plugin/"+plugin+"/"+function+"/"+parameter)

return r.status_code

except requests.Timeout:

return "Request timed out"

except requests.ConnectionError:

return "Problem with connection"

except ValueError: return "No data" Figur 48: Utdrag av en funksjon som kommuniserer med webservice. Dette er den viktigste funksjonen som kan hente inn data til

Frontend.

5.5.4.4 TEMPLATE

En template er i seg selv en vanlig HTML side. Den store forskjellen er at denne html siden prosesseres med

en «renderer». Dette gjør at det er enkelte såkalt «makro» koder som kan settes inn i HTML-koden og tilføye

et dynamisk element til de ellers statiske sidene. En slik makro ser eksempelvis ut som Figur 49.

«{% block title %}{% endblock %}»

Figur 49: Makroeksempel der «taggene» som benyttes i templaten er illustrert.

Figur 49 viser en makrofunksjon som lager en blokk. En blokk kan i etterkant fylles ut med innhold. Dette er

funksjonalitet som gjør at kode ikke er nødt til å dupliseres, da det gjør det mulig å lage en grunnleggende

mal for websidegrensesnittet.

For at en template skal genereres må den kalles fra en funksjon i viewet. Det er da mulig å sende med data til

templaten som skal genereres, og benytte makrofunksjonene til å sette in data.

For Frontend er det benyttet en standard mal for alle sidene. Denne kaller vi «base.html» og bygger opp

strukturen i nettsiden slik at denne ser lik ut i alle nettlesere, og for hver side. Det er også mange forskjellige

dynamiske JavaScript-rammeverk som skal lastes inn og benyttes på hver side. Derfor lastes disse inn i


base.html filen. Figur 50 viser et utdrag av base.html som danner grunnlaget for malen de andre sidene

benytter.

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>PySniff {% block title %}{% endblock %}</title>

<link href="{{STATIC_URL}}css/style.css" rel="stylesheet"> <link href="{{STATIC_URL}}bootstrap/css/bootstrap.css" rel="stylesheet"> <link href="{{STATIC_URL}}bootstrap/css/bootstrap-responsive.css" rel="stylesheet"> <script src="{{STATIC_URL}}js/jquery-1.9.1.min.js" type="text/javascript"></script>

{% block extrahead %}

{% endblock %}

</head> <body> <div id="toolbar"> <div id="toolbar-left"> <img src="{{STATIC_URL}}images/SB1.png" id="toolbar-image"> </div> <div id="toolbar-center"> <ul class="nav nav-pills"> <li id="linkmain" class="active"><a href="/">Hoved</a></li> <li id="linkgraph"><a href="/graph">Graph</a></li> </ul> </div> <div id="toolbar-right"></div> <div style="clear:both"></div> </div> <div id="content"> {% block content %}

{% endblock %}

</div> <script src="{{STATIC_URL}}bootstrap/js/bootstrap.min.js"></script> </body> </html> Figur 50: Template som inneholder grunnlaget for alle sidene i prosjektet. Viser hvordan template macros benyttes til linking med

«{{STATIC_URL]}} og blokker som {% block content %}.Disse benyttes for undersider som legger inn data i disse.

For å benytte base.html i de andre templatene benyttes koden vist i Figur 51:

{% extends "base.html" %}

{% block title %}Forside{% endblock %} Figur 51: Benyttelse av base.html i andre templates for å beholde samme design om importeringer på alle sider.

5.5.4.5 GRAFER MED NVD3

For å kunne tilby grafer som ser pene ut, og som er dynamiske, er det behov for å benytte et rammeverk. Det

er mye kode som skal til for å utvikle gode dynamiske løsninger som skal fungere i mange forskjellige

nettlesere. Prosessen for å finne et godt rammeverk som har passet våre behov har vært viktig, og det er

mange rammeverk som har blitt vurdert.


Nvd3.js er et rammeverk som bygger på et open source prosjekt med navn d3.js. Utvidelsen med nvd3.js er

da et tillegg til d3.js for å kunne lage dynamiske gjenbrukbare grafer. Dette gjør at grafene som genereres

kan oppdateres med ny data, og fortsatt ha riktig størrelse. Dette kan gjøres da det benyttes et element i

HTML kalt Scalable Vector Graphics (SVG). Det er også mulig å benytte Canvas for å generere grafikk i

nettlesere med HTML 5 og JavaScript. Fordelen med å benytte SVG er at dette benytter vektorer, mens

Canvas benytter piksler. Forskjellen dette utgjør er muligheten for skalering i forskjellige nettlesere og på

forskjellige størrelser.

Figur 52 viser hvordan en graf, i dette tilfellet et piechart med nettlesere, blir generert med bruk av

JavaScript i templatefilen «piechart.html».

<script type="text/javascript">

var chart;

getJsonChart();

window.setInterval(function(){

getJsonChart();

}, 60000);

function setupChart(d){

nv.addGraph(function(){

chart = nv.models.pieChart()

.x(function(d) { return d.useragent })

.y(function(d) { return d.count })

.color(d3.scale.category10().range())

.showLabels(false)

.showLegend(true)

d3.select('#chart1 svg')

.datum(d)

.transition().duration(500)

.call(chart);

nv.utils.windowResize(chart.update);

return chart;

});

}

function getJsonChart(){

d3.json('/api/plugin/http/useragent_count/15', function(inndata){

var data = {};

data.key = "Most used user agends";

data.values = [];

data.values = inndata;

setupChart([data]);

});

} </script> Figur 52: Utdrag av en template fil som bygger opp en enkel graf. Data hentes her inn fra «/api/plugin/http/useragent_count/15», og

settes inn i et kakediagram.

Det dette gjør er først å kalle på funksjonen «getJsonChart()» som henter inn data fra

«/api/plugin/http/useragent_count». Dette vil hente data i form av JSON. JSON er en måte å serialisere data

på, for å sende mellom forskjellige enheter. Dette er et alternativ til XML som har veldig mye overhead data,

samtidig som JSON er laget på grunnlag av JavaScript.


Når dataene har blitt hentet inn kan grafen settes opp med funksjonen «setupChart(data)». Denne setter

elementene til grafen på Nvd3.js sin måte for å oppnå den ønskede grafen.

For at grafen skal oppdateres dynamisk med ny data i et gitt tidsintervall er det i koden benyttet en funksjon i

JavaScript som gjør at man kan sette et intervall for at noe skal skje. Figur 53 er et JavaScript-utdrag som

viser hvordan det gjøres for at grafen skal oppdateres hvert minutt (60000 ms).

window.setInterval(function(){

getJsonChart();

}, 60000); Figur 53: JavaScript som sørger for at grafen oppdareres hvert minutt (60000 millisekunder).

De nevnte komponentene i disse avsnittene danner strukturen for Frontend, og kan illustreres som i Figur 54.

Her vises det fra en nettleser spør etter en nettside fra webserveren, og hvordan webserveren videre spør

Django etter datae. Flyten her er gitt av View (Controller) som kan spørre Webservice om data før dette

populeres inn i Template. Det som blir sendt tilbake til nettleseren er HTML kode, som blir generert på

serversiden. For sluttbrukeren vil dette bli lastet inn som en vanlig webside.

Figur 54: Illustrasjonen viser den totale flyten i Frontend ved bruk av Django.

5.5.4.6 STRUKTUR I FRONTEND

Frontend er designet etter beste praksis for Django. Django er et fritt rammeverk med mange mulige

implementasjoner. Det er derimot ikke noen selvfølge at alle måter er optimale. Det er derfor benyttet mye

tid på å sette seg inn i Djagno, men også hvordan det er best å benytte dette rammeverket. De mest benyttede

artiklene om dette, er et innlegg på stackoverflow.com[17] og en artikkel om «Django Project

Structure»[18]. På grunnlaget av disse artiklene og undersøkelser av andre tilgjengelige prosjekter, har

strukturen på selve Frontend blitt ut som i Figur 55.


Figur 55: Illustrasjon over filstrukturen til PySniff prosjektet. Viser standar Django mapper med orange, Django filer med blått og

filer og mapper som er opprettet kun for PySniff i grønt. Mappen «apps og main» er PySniff spesifikt, men kreves for at Django skal

fungere.

Figur 55 viser inndelingen i mapper benyttet av Frontend. De blå blokkene er filer som kreves av Django for

å kunne fungere optimalt, mens de grønne blokkene er mapper og filer som er laget spesifikt for PySniff.

Nedenfor beskrives figuren mer i detalj med informasjon om de forskjellige punktene.

Config: Mappe hvor alle eksterne konfigurasjonsfiler ligger lagret til prosjektet produksjonsettes.

Requirements: En mappe med spesifikke lister for de forskjellige miljøene. Her skal alle tillegg

som må installeres for at Django skal fungere være listet.

PySniff: Djangoprosjektets hovedmappe. Denne er automatisk generert av Django.

Apps: Inneholder Django-applikasjoner.

Libs: Inneholder pythonbiblioteker som kan benyttes i resten av djangoprosjektet. Ved bruk av en

egen mappe for biblioteker kan det enkelt lages funksjonalitet for å koble Frontend mot andre

applikasjoner hos oppdragsgiver. Eksempelvis muligheten til å sende sms eller e-post via

oppdragsgivers systemer, eller for å generere automatiske saker i oppdragsgivers

saksbehandlingssystem.

Static: Inneholder alle statiske filer som kan inkluderes og sendes til klienten. Dette krever at

mappen er linket riktig i konfigurasjonen til webserveren.


Templates: Mappe for alle templatefilene som er tilgjengelig. Her ligger blant annet base.html som

beskrevet tidligere.

Pysniff.wsgi: En konfigurasjonsfil for koblingen mot webserveren som vil avgjøre hva som gjøres

når webserveren starter.

Urls.py: Standard URL-konfigurasjonen for prosjektet. Det er mulig å dele opp denne til å ha egne

URL-konfigurasjoner i applikasjonene (under apps).

Settings.py: Django sin settings konfigurasjon som kreves for at prosjektet kan kjøres.

Dette utgjør filstrukturen og den generelle strukturen for Django, og er designet på grunnlag av muligheten

for utvidelser og forbedringer.

5.5.5 UTFORDRINGER

Under utviklingen av Frontend har det vært mange utfordringer for å oppnå den ønskede funksjonaliteten.

Det har vært flere grunner til utfordringer, blant annet på grunn av dårlig dokumenterte rammeverk, til

problemer som skyldes lite erfaring med rammeverk.

Det å sette seg inn i Django i første omgang krever mye tid, da dette er et stort og omfattende rammeverk

som bygger på en kompleks MVC struktur. Det å kunne utvikle et produkt basert på et slikt rammeverk, og

sørge for at det fortsatt er utvidbart er en utfordring da det fort kan bli gjort valg som senere vil påvirke hele

designet. Som følge av dette ble det satt av tid til å bygge opp en god struktur fra prosjektstart.

Sluttproduktet bærer også preg av dette i form av at det kan legges til ny funksjonalitet med Django, og ikke

miste den funksjonaliteten som er der i dag.

Nvd3 har vært en utfordring i prosjektet. Dette har i stor grad vært på grunn av dårlig dokumentasjon fra

utviklerne sin side, med kun eksempler med dårlig dokumentering. Rammeverket Nvd3 har også en glidende

overgang som gjør det vanskelig å forstå hva som er D3 og hva som er Nvd3, og dette gjør vanskelig å

feilsøke JavaScript-koden.

Den dårlig dokumenterte nvd3-koden, og vanskelig feilsøking i JavaScript har ført til problematikk rundt å

dynamisk hente inn data til grafene, slik at det er mulig å oppdatere disse uten å laste hele siden på nytt.

Dette ble løst etter tilbakemelding på nettstedet «stackoverflow.com» [19], og skyldtes problemer med

asynkrone kall mot webservicen, hvor data ikke ble tatt med videre inn i grafen.

Det var også en utfordring å få grafene til å bli populert med riktig dato. Datoen som hentes fra webservice

kan ikke benyttes direkte, og det måtte derfor opprettes et objekt i JavaScript med «new Date(”2013-04-20

20:22”); ». Dette viste seg derimot ikke å fungere i alle nettlesere, og det måtte produseres en egen metode

for å rette på dette.

5.5.6 KONFIGURASJON

Ettersom Frontend kan kjøre på forskjellige maskiner, er det flere konfigurasjonsfiler som kreves for at

Frontend skal kjøre korrekt. Mye av funksjonene i Frontend avhenger derfor av konfigurasjon som er gjort i

konfigurasjonsfilene.

Det er tre viktige konfigurasjonsfiler for prosjektet (I rekkefølgen disse blir lastet inn).

Apacheconfig

Pysniff.wsgi

Settings.py

Figur 56 illustrerer flyten for Frontend slik det kjører ferdig installert. Frontend benytter en Apache

webserver for å levere dataene, men krever et tillegg til websereveren som heter mod_wsgi. Mod_wsgi er et

bindeledd mellom webserveren og Django, og gjør det mulig å kjøre pythonprogrammer som websider.


Figur 56: Rekkefølgen av innlasting av konfigurasjoner ved start av Django

Apache konfigurasjonen er filer som kreves for at Apache webserveren kan levere nettsider på gitte

domener. For hver nettside som kjører på en maskin kreves det en spesiell konfigurasjon som forteller

webserveren hvor filene er lagret, og blant annet hvem som skal ha tilgang.

WSGISocketPrefix run/wsgi

<IfModule !mod_wsgi.c>

LoadModule wsgi_module /etc/httpd/modules/mod_wsgi.so

</IfModule>

<VirtualHost *:80>

ServerName origo4.test.sparebank1.no

ServerAlias orito4.test.sparebank1.no

DocumentRoot /opt/pysniff/frontend/PySniff/

WSGIDaemonProcess pysniff

WSGIProcessGroup pysniff

WSGIScriptAlias / /opt/pysniff/frontend/PySniff/pysniff.wsgi

Alias /static /opt/pysniff/frontend/PySniff/static/

ErrorLog /var/log/pysniff/frontend/httpd/fronend-error.log

CustomLog /var/log/pysniff/frontend/httpd/frontend-access.log combined

</VirtualHost> Figur 57: Konfigurasjonsfil for Apache sørger for at Django og Frontend blir presentert.

Pysniff.wsgi er konfigurasjonen for å koble sammen Apache og mod_wsgi med Django. Dette er et

pyhonprogram som setter de nødvendige innstillingene nødvendige for at Django blir startet.


import os

import sys

import site

# Using the virtual environment

site.addsitedir('/opt/pysniff/pysniff_env/lib/python2.7/site-packages')

# Applying the path and settings

sys.path.append('/opt/pysniff/frontend')

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "PySniff.settings")

# Setting up applicationhandler

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler() Figur 58: Konfigurasjonsfilen for tillegget «mod_wsgi» til Apache som gjør at Django blir startet. Legger til riktig filsti til

prosjektmappen for Frontend.

Settings.py inneholder konfigurasjonen for hele djangoprosjektet. I denne filen settes konfigurasjon for

tilkobling til databaser, adresser og andre konfigurasjoner. Denne filen er standard for alle prosjekter som

benytter rammeverket Django. Dette er utnyttet, og ettersom denne filen er tilgjengelig for hele

delapplikasjonen, er alle variable tilgjengelig fra alle disse filene. Dette gjør det mulig å konfigurere

Frontend forskjellig fra applikasjonsmiljø til applikasjonsmiljø. Figur 59 viser en del av konfigurasjonen

som viser hvordan adressen til webservicen ligger lagret, samt andre viktige variabler.

# Django settings for PySniff project.

import os

# System wide variables

SITE_ROOT = os.path.dirname(os.path.realpath(__file__))

WEBSERVICE_URL = "http://localhost:8080"

WEBSERVICE_TIMEOUT = 30

LOGFILE = "/var/log/pysniff/frontend/trace"

Figur 59: Konfigurasjon for Django prosjektet. Dette er en standar konfigurasjon, hvor det er lagt til tillegg som er spesifikt for

PySniff.

5.5.7 LOGGING AV FRONTEND

For å kunne logge feil og feilsituasjoner som skjer ved bruk av Frontend logges mange av operasjonene som

skjer. Dette er for å gjøre det raskt og enkelt å finne feil når de oppstår, og gjøre det mulig å rette disse. Dette

er også viktig da dette skal kjøre på maskiner i et produksjonsmiljø. Hvis det da oppstår en feil er det viktig

at overvåkingspersonell skal kunne se hva som er feil, og kunne videreformidle dette til utviklere.

Ettersom det kan være mange applikasjoner i tillegg til Frontend som kjører på en maskin, må loggene

plasseres på et universelt sted. Dette gjøres på Linux under «/var/log/pysniff/frontend/». Dette er viktig, da

Frontend kjører med webserveren Apache, som er adskilt med en egen bruker på Linux maskinene. Derfor

må webserveren ha tilgang til bare denne mappen, slik at det er mulig å skrive til denne.

Det er to deler av logger som følger bruken av Frontend. Den ene loggen er fra Apache webserveren, som

lagres under «/var/log/pysniff/frontend/httpd/». Her lagres hver forespørsel til webserveren i en fil, og alle

forespørsler som feiler, lagres i en annen fil.


/var/log/pysniff/frontend/httpd/frontend-access.log 84.208.75.77 - - [19/Apr/2013:10:43:45 +0200] "GET /api/plugin/http/hostname_count/15

HTTP/1.1" 200 595 "http://77.40.217.204/" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT

6.1; WOW64; Trident/5.0)"

62.249.186.193 - - [22/Apr/2013:12:28:20 +0200] "GET / HTTP/1.1" 200 2818 "-" "Mozilla/5.0

(Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64

Safari/537.31"

Figur 60: Utdrag fra loggen, som viser ipadresse, tidspunkt, metode (”GET /”), HTTP status kode (200), adresse og hva slags type

nettleser som brukeren benytter.

Meldingene fra Frontend lagres som en «trace.log» fil, og er ment for å kunne spore opp hva som har blitt

utført i bakgrunnen av nettsiden.

/var/log/pysniff/frontend/trace/frontend.log 2013-05-15 14:57:12 INFO [main:75] Getting data from webservice 2013-05-15 14:57:12 INFO [main:111] Webservice connection plugin=http function=statusline_date params=500 response=200 2013-05-15 14:57:13 INFO [main:111] Webservice connection plugin=http function=statusline_date params=502 response=200 Figur 61: Frontend.log som har tidspunktet, alvorlighetsgraden, hvor i koden loggen kommer fra og feilmeldingen.

5.5.8 PRODUKTET

Produktet av Frontend er et resultat av de arbeider som er utført med utvikling av Frontend, men også de

bakenforliggende systemene.

Webgrensesnittet er designet for å kunne gi store og tydelig grafer, som det er mulig å se på lang avstand. De

er også veldig optimalt til å benytte på en vanlig maskin.

Mye av designet dreier seg rundt hovedmenyen som skal gi tilgang til de forskjellige delene av Frontend.

Denne menyen skal gi tilgang til de forskjellige skjermbildene, men må også være anonym slik at den

fungerer godt på en overvåkingsskjerm. Dette er for at den ikke skal bruke store deler av

overvåkingsskjermen, men fortsatt være funksjonabel. Menyen er derfor designet som en linje i toppen av

skjermen illustert i Figur 62.

Figur 62: Menyen til Frontend som gjør de forskjellige skjermbildene tilgjengelig.

Menyen er laget ved bruk av Bootstrap, men fargene er endret for tydelig å vise de forskjellige linkene.

Menyen er også designet for å støtte bruken av «tab» på tastaturet. Dette fungerer også sammen med

nedtrekksmenyen illustrert i Figur 63. Fargevalget er også nøye vurdert, og følger standardene til

oppdragsgiver.

Figur 63: Utsnitt av menyen med nedtrekksmeny menyen.

Menylinjen har også en digitalklokke som er synkronisert mot serveren, da dette vil gjøre at tiden alltid er

korrekt i forhold til de data som vises i grafene. Denne er lett synlig til høyre i menylinjen. Det er viktig å

kunne vise klokken, slik at den som ser på siden ved at dataene er oppdatert, og at personen ser på de riktige

dataene fra riktig klokkeslett.


Figur 64: Klokken på menylinjen

Mye av Frontend baserer seg rundt analogien av navnet «screen». Screen er en skjerm hvor flere grafer

vises. Da det i dette prosjektet er tatt for seg HTTP, er det implementert en screen for HTTP-trafikk. Denne

illustrerer alle de forskjellige HTTP-kodene, og grafene genereres ut i fra disse dataene. Ved å illustrere

HTTP trafikk er det her lett å se om det oppstår problemer som fører til problemer med tjenestene, ved at

tjenestene vil generere HTTP-feilkoder.

Figur 65: Screen for illustrering av HTTP trafikk. Den venstre grafen inneholder data fra den siste uken, mens grafen til høyre viser

data fra den siste timen.

Screen er ment for å være en samleside for å illustrere flere grafer, og presentere data som en helhet. Det er

derimot mange sammenhenger hvor det vil være interessant å kunne se på en enkelt graf.

Dette er mulig ved bruk av «Graph» siden, som kan presentere en graf, med forskjellig data. I Figur 66 er det

generert en graf basert på alle typer HTML-feilkoder som befinner seg i databasen.

For å forstå det som presenteres her kreves det kunnskap om HTTP fra brukeren, og dette er ikke avansert

kunnskap. De forskjellige HTTP-feilkodene, som «HTTP 200», er godt dokumenterte og kan kort

oppsummeres som i Tabell 9.

Statuskode Betydning

1xx (100, 101, 102) Informasjon om at forespørsel er motatt og at data skal sendes

2xx Vellykket forespørsel. 200 er OK og er den vanligste koden

3xx Videresending. Kan bety at dataene er flyttet og ikke eksisterer, og kan gjøre at data ikke blir returnert.

4xx Klient feil. Dette kan bety at klienten ikke har tilgang, eller foretar en handling som ikke er mulig. 404 er for eksempel hvis en side ikke eksister.

5xx Server feil. Denne viser veldig tydelig hvis det er noe på serversiden som ikke fungerer som det skal. Dette er nok også den viktigste indikatoren for å se om alt fungerer som det ska.

Tabell 9: Viser betydningen av de forskjellige feilkodene som kan returneres av HTTP


Figur 66:Dette skjermbildet viser delen som viser en enkelt graf. Denne kan endres til å inneholde annen data, men viser her HTTP

feilkoder. Denne grafen oppdateres dynamisk,og benytter JavaScript for å få bevegelighet inn i dette.


6. KONKLUSJON

Kapittelet tar for seg oppnåelsen av målene til bedriften og prosjektgruppen. Kapittelet inneholder også en

gjennomgang av utvidelsesmuligheter til rammeverket. Kapittelet inneholder en konklusjon av prosjektet i

sin helhet.


6.1 MÅLOPPNÅELSE

6.1.1 BEDRIFTENS MÅL

SpareBank 1 ville ha et tillegg til dagens overvåkingsløsning hvor man kunne se direkte på nettverkstrafikk.

Dette for å sammenligne trafikk over lengre perioder slik at feilsituasjoner kan oppdages raskere. Ønsket til

SpareBank 1 har vært en løsning de ansatte lett kan utvide med mer funksjonalitet. PySniff har derfor blitt

utviklet som et rammeverk. Som en innføring i bruk og utvikling av rammeverket er det implementert støtte

for grunnleggende HTTP-analyse. PySniff har blitt tatt i bruk i kvalitetsikringsmiljøet (QA) til SpareBank 1

og er i en lengre prosess for å godkjennes til produksjon. Rammeverket har blitt introdusert til flere

avdelinger som driver med overvåking hos SpareBank 1. Tilbakemeldingen de ansatte i avdelingene har

kommet med om mulige utvidelser, gjør bedriftens mål oppnådd. Prosjektgruppen og veileder hos SpareBank 1 har hatt minimum ett oppfølgingsmøte hver uke, hvor

prosjektets fremgang har blitt diskutert. SpareBank 1 har vært oppdatert på fremdriften i prosjektet for å

verifisere at kravene er blitt fulgt.

6.1.2 LÆRINGSMÅL

Prosjektgruppen sine tre hovedmål har vært å designe, implementere og dokumentere en nettverksbasert

overvåkingsapplikasjon. Hovedmålene har medført flere delmål for å kunne nå oppnåelsen av disse. For å oppnå hovedmålet og kravene om designet, var det nødvendig at prosjektgruppen fikk innsikt i

hvordan applikasjonene til SpareBank 1 kommuniserer over deres nettverk. Forståelsen rundt nettverket til

SpareBank 1 resulterte i ett kompleks design av PySniff. Designet av PySniff har resultert i et robust og

fleksibelt rammeverk, som består av flere delapplikasjoner. Dette gjør det enkelt å bytte ut hver enkelt

delapplikasjon. Det gjør det også mulig å bestemme hvor i nettverket hver enkelt delapplikasjon skal bli

plassert, basert på nettverkets topologi. Hovedmålet om implementasjon ble påbegynt etter designet av PySniff var på plass. Implementasjonen var

en prosess for å utvikle delapplikasjonene i henhold til kravene i kravspesifikasjonen. Utviklingen av

PySniff ble gjort i programmeringsspråket Python. Det var ingen i prosjektgruppen som tidligere hadde

erfaring med dette programmeringsspråket. Python ble derfor tidlig et sentralt og viktig læringsmål for

hovedmålet om implementasjon. Implementasjonsprosessen var avhengig av et testmiljø for å teste koden, og å kvalitetssikre PySniff sine

delapplikasjoner. Prosjektgruppen tilegnet seg kunnskap om programvare og maskinvare for å sette opp et

slikt testmiljø. Hovedmålet om dokumentasjon har vært en kontinuerlig prosess under utviklingen av PySniff.

Dokumentasjonen har bestått av to hoveddeler: sluttdokumentasjon og styringsdokumentasjon.

Stryingsdokumentasjonen inkluderer dokumenter skrevet i forprosjektet, mens sluttdokumentasjonen

inkluderer dokumenter som er skrevet under utviklingen av PySniff. Stryringsdokumentasjonen har hjulpet

prosjektgruppen med jevn fremgang i prosjektet i form av en fremdriftsplan. Kravspesifikasjon har bidratt til

kvalitetssikring underveis i prosjektperioden, denne er også en del av styringsdokumentasjonen. I denne rapporten fremstilles sluttdokumentasjonen, sammen med rapport om prosessdokumentasjonen.

Dette sammen med de andre vedleggene i denne rapporten utgjør sluttdokumentasjonen i dette prosjektet.

6.2 UTVIDELSESMULIGHETER

Applikasjonsdesignet til PySniff har fra prosjektstart vært et rammeverk bestående av flere delapplikasjoner.

Med rammeverk menes det at funksjonaliteten er enkel å utvide, i form av plugins som kan håndtere for

eksempel SQL-, HTTPS- og FTP-trafikk.


Ressursbruk har vært et viktig under planleggingen av designet, og spesielt for Sensor sin del. Det har derfor

vært et ønske at denne på et senere tidspunkt skal kunne programmeres i et lavnivå programmeringsspråk,

slik at dette vil bruke mindre ressurser.

SpareBank 1 ytret et ønske om mulighet til trending av nettverkstrafikk i rammeverket, men dette inngår

ikke som et krav til prosjektet. Derfor har vi i rammeverket tilrettelagt for dette i form av aggregering av

data, som kan brukes til trending. Med trending menes at det utarbeides en grense på hva som er normalt og

ikke normalt i tidsperioder, for å sammenligne driftsstatus og eventuelle avvik.

Trending gir muligheten til å kunne implementere triggers, som er regler for hvordan nettverkstrafikk bør

være på et gitt tidspunkt i forhold til hva som er normalt. For eksempel om antall feilkoder stiger eller

minsker betraktelig, vil en trigger sende ut varslinger via for eksempel sms eller e-post.

Det er også ønskelig å ha muligheten for å kontrollere hvem som har tilgang til websiden, dette er tenkt løst

med en innlogingsportal til nettsiden. Det er derfor ønskelig å kunne administrere brukere i webgrensesnittet.

Brukerne skal selv, hvis de har tilgang, kunne se hva som er tilgjengelig av funksjoner fra Webservice, og

opprette grafer på grunnlag av dette.

Prosjektgruppen har tenkt på mulighetene til å utvide med en mobilapplikasjon, men prosjektet har vært for

omfattende til å inkludere dette. Det er likevel tilrettelagt for å utvide med en mobilapplikasjon som kan

kommunisere med Webservice.

6.3 KONKLUSJON AV PRODUKTET

PySniff kan benyttes til å indikere feilsitasjoner, i form av grafiske illustrasjoner av HTTP-trafikk som går

mellom SpareBank 1 sine applikasjoner. HTTP-pluginen ble utviklet for å kunne teste og kvalitetssikre

rammeverket underveis. Denne pluginen er starten på den første av flere mulige plugins som SpareBank 1

ønsker å benytte seg av.

Alle målene for prosjektet er nådd, men for at PySniff skal kunne brukes av SpareBank 1, som et fullverdig

overvåkingssystem, kreves det mer funksjonalitet i pluginbiblioteket.

Det visuelle designet av webgrensesnittet til PySniff følger SpareBank 1 sine retningslinjer for design. Dette

vil si at farger, logo og grafiske elementer er i henhold til disse retningslinjene. Dette gjør at SpareBank 1

kan bruke produktet internt, og at det passer inn sammen med resten av oppdragsgivers systemer. Websiden

fungerer både på en overvåkingsskjerm, og som et verktøy på en klientmaskin.

Baksystemet til PySniff er delapplikasjonene som behandler og tilgjengliggjør data for Frontend.

Baksystemet er fleksibelt i den forstand at det kan installeres i de fleste nettverk, uavhengig av størrelse.

Dette betyr at baksystemet passer inn i store og små bedrifter.

Produktet i sin helhet med tilhørende delapplikasjoner laget av prosjektgruppen, har resultert i et rammeverk,

som utgjør en overvåkingsløsning.


7. PROSESSRAPPORT Denne rapporten er for prosessen i prosjektet. Her er det skrevet om progresjon og arbeidsplanlegging,

utviklingen av produktet og samarbeid innad i gruppen.

7.1 KRAV TIL PROSJEKTET

Prosjektet har fra prosjektstart benyttet en flytende kravspesifikasjon. Denne kravspesifikasjonen har vært

flytende da designet til sluttproduktet ikke var klart. Dette har vært en prosess som har utviklet seg i de

første fasene av prosjektet. I denne prosessen har kravspesifikasjonen blitt revidert ettersom det har blitt klart

hva som var nødvendig, ønskelig og mulig å gjennomføre i dette prosjektet. Ved å ha en flytende kravspesifikasjon, og samtidig faste møter med ekstern veileder, har vi vært sikre på at

kravspesifikasjonen følger oppdragsgivers krav og ønsker.

7.2 PLANLEGGING OG METODE

7.2.1 UTVIKLINGSMODELL

Oppdragsgiver hadde et ønske om et system som kunne hjelpe til med feilsøking hos SpareBank 1. Hvordan

problemstillingen skulle løses, var i stor grad opp til prosjektgruppen. På bakgrunn av dette ble det bestemt

at det skulle brukes en flytende kravspesifikasjon, som både oppdragsgiver og prosjektgruppen var enige i. Grunnet det løst definerte kravet om hvordan systemet skulle implementeres, var designfasen en stor del av

prosjektet. I designfasen utforsket vi mulighetene og hvordan vi best skulle løse problemstillingen. Designet

har fra starten av vært viktig, men har også vært tett tilknyttet utviklingen gjennom store deler av prosjektet.

Grunnen til dette har vært utfordringer som etterhvert har blitt klart under utviklingen av systemet. Dette har ført til at prosessen har iterativ og stegvis. Dette har blitt utført ved å designe, implementere og

teste løsningen gjevnlig gjennom hele prosjektet. Vi har ikke fulgt en standardisert utviklingsmodell, da dette ikke føltes naturlig i forhold til prosjektetes

oppbygging. Den nærmeste utviklingsmodellen som har passet vår arbeidsmetodikk har vært agile utvikling.

I agile utvikling er både krav og løsning stadig under utvikling. Arbeid med løsningen har vært en

kontinuerlig prosess, der det både defineres, implementeres og testes ny funksjonalitet gjennom hele

prosjektets gang. For oppdragsgiver har det vært viktig med milepæler, hvor det fra starten av har vært meningen å få et

fungerende system ved hver milepæl. Dette betyr at det også har vært en stegvis prosess rundt milepælene

hvor det har blitt produksjonssatt en ny versjon av løsningen, som inneholder mer funksjonalitet.

7.2.2 FREMDRIFT OG ARBEIDSPLAN

Basis for vår progresjon har vært fastsatte milepæler og delmål underveis, ukesmøter med veiledere og en

overordnet fremdriftsplan. En overordnet oversikt over hovedpunktene i de forskjellige fasene i prosjektet og

utviklingen av produktet er det laget en fremdriftsplan med progresjon for uke til uke. Dette er for å få en

oversikt over hva som skulle gjøres og når de forskjellige gjøremålene skulle være ferdig.



I startsfasen av prosjektet lå prioriteten i planleggingen av prosjektets fremgang slik at vi kunne holde en

jevn progresjon.

For å ha noen større delmål å jobbe mot underveis i prosjektet valgte vi å definere noen milepæler som vi

tidlig definerte under prosjektplanleggingen. I tillegg til at disse representerer viktige punkter under

utviklingen ble det bestemt at hver milepæl skulle det også være en produksjonssetting av produktet så langt

hos oppdragsgiver. Produksjonssettingene består i en ren eller ny installering av systemet i den gjeldende

versjonen. Dette har vært nyttig for å identifisere problemer som ikke nødvendigvis kommer tidlig frem

under utviklingen og minsker risikoen for uforutsette problemer.

På bakgrunn av produksjonssettingene i hver milepæl er det også skrevet produksjonssettingsrapporter.

Disse rapportene inneholder informasjon om hvordan produksjonssettingene er utført og hvilke problemer

som måtte ha oppstått underveis. Dette har vært nyttig for å lære av tidligere uforutsette feil. Rapportene er å

finne under vedlegg E 1-3. Da milepæl 3 er etter leveranse av prosjektrapporten og ment som en endelig

produksjonssetting hos oppdragsgiver er denne rapporten ikke med.

Vi har valgt å ikke har milepæler for dokumentasjon, men kun for systemet. Dette da dokumentasjonen

oppleves som mer flytende, og er jobbet med kontinuelig under prosjektperioden.

Tradisjonelt sett er det vanlig å benytte en dagbok for å dokumentere fremgangen i et hovedprosjekt. Her

beskrives progresjonen, ideer og problemer underveis. Originalt var det også planen våres å benytte en

dagbok, men oppdaget fort at dette var noe som det var unødvendig og ineffektivt å bruke tid på, og tittet

derfor på alternativer. I stedet endte vi opp med å bruke prosjekthåndteringsverktøyet KanbanFlow som er en

komplett løsning for å håndtere oppgaver. KanbanFlow er perfekt for å både planlegge progresjon samt

dokumentere hva som er blitt da den tilbyr full historikk over fullførte gjøremål. KanbanFlow er ment å

gjenspeile fremdriftsplanen, alt etter hva som jobbes med den aktuelle uken eller tidsrommet.

KanbanFlow var spesielt interessant grunnet dens funksjonalitet for å delegere og kategorisere oppgaver,

registrere tidsbruk og kommentere på gjøremålene. Dette verktøyet kan derfor sies å være en fullverdig

erstatning for en dagbok, og vi slapp å bruke tid på å sette oss inn eller utvikle vår egen.

Her er et skjermbilde av webgrensesnittet til KanbanFlow. I tillegg tilbys det en mobilapplikasjon.

Figur 67: KanbanFlow som er prosjektstyringsverktøyet som er benyttet i prosjektet.

I starten av prosjeketet ble det benyttet en egenutviklet prosjektdagbok, men grunnet mangel på

funksjonalitet og tungvint vedlikehold, ble denne byttet ut til fordel for KanbanFlow. Selv om dagboken

tilbød funksjonalitet for å registrere hva som hadde blitt gjort, oppdaget vi at det var vanskelig å følge opp

med både registrering av hva som skulle bli gjort et sted, samt registrere det i dagboken når det ble ferdig.

Ved å benytte KanbanFlow fikk vi samlet dette.


KanbanFlow har også den fordelen at det gir en god oversikt over fremdriften i prosjektet, slik at det er

mulig å se om ting tar veldig mye tid og fange opp oppgaver som blir liggende.

I tillegg til dette har det vært faste møter med både intern og ekstern veileder for prosjektet.

7.3 VERKTØY

Her listes relevante verktøy brukt for håndtering av dette prosjektet og dets dokumentasjon. Verktøy brukt

for utviklingen av produktet er unnlatt da de ikke har vært sentrale for prosjektets prosess.

KanbanFlow - Prosjekthåndteringsverktøy, se 3b.

Git - Versjonskontrollsystem for håndtering av programkode. Mer om denne i vedlegget F om Git.

Dropbox - Fillagring og synkronisering i nettskyen. Brukt for dele mapper med prosjektfiler innad i gruppen

utover programkoden som er lagret i Git.

Word - Tekstbehandlingsprogram brukt for å skrive dokumentasjon. Standard program for å skrive

dokumentasjon hos oppdragsgiver.

Google Docs - Tekstbehandlingsprogram i nettleseren tilbudt gratis av Google. Tilbyr synkronisert skriving

på samme dokument, kjekt for å skrive felles dokumentasjon.

7.4 SAMMARBEID

Vi har alle gått samme studieretning og hatt flere felles fag, i tillegg jobber tre av oss hos oppdragsgiver og

samholdet i gruppen var derfor godt allerede før prosjektstart.

Av arbeidsmetoder har vi jobbet både sammen på gruppemøter og individuelt. Det har ikke vært noe

problem å samhandle progresjonen grunnet bruken av det nevnte prosjekthånderingsverktøyet KanbanFlow,

samt faste ukentlige møter som har naturlig gitt gruppen mål å jobbe sammen mot.

Av kommunikasjon har vi brukt Skype for telefonsamtaler over internett. Dette har senket terskelen for

kommunikasjon innad i gruppen, hvor alternativet er å avtale møter eller aktivt oppsøke hverandre over

telefon eller lignende. Som resultat har dette gjort at ingen i gruppen har falt av eller blitt sittende alene med

arbeidsoppgaver som potensielt kan gi dårlig fremgang.

Alt i alt er alle i gruppen godt fornøyd med samarbeidet og bidraget til hver av gruppemedlemmene.

7.5 VEILEDNING

Vi har hatt faste møter en gang i uken både med intern og ekstern veileder for å gjennomgå hva som er blitt

gjort uke til uke, hvor fokus bør ligge samt tilbakemeldinger på arbeid så langt. Vi ser at de faste møtene har

hjulpet oss med å holde en jevn progresjon og å synkronisere krav fra oppdragsgiver underveis med

prosjektets arbeid.

Intern veileder

Vår interne veileder fra Høgskolen i Oslo og Akershus har vært Torunn Gjester. Veileder har bistått med

tilbakemeldinger på prosjekthåndtering og dokumentasjon, og har holdt oversikt over prosjektarbeidets

fremgang.

Ekstern veileder

Martin Jensen representerte oppdragsgiver SpareBank 1 Gruppen AS, samt fungerte som vår veileder under

prosjektet. Vi så på det som viktig å ha faste møter også med ekstern veileder slik at vi kunne si om vi

arbeidet i riktig retning, noe også Martin Jensen var enig.

I tillegg til å bistå med prosjekthåndteringen, hjalp vår eksterne veileder oss med teknisk innsikt hvor det var

behov. Vi fikk også god oppfølging med produksjonssettingene hvor oppdragsgiver tidlig stilte med

nødvendig maskinvare og kompetanse.


8. REFERANSER

8.1 VEDLEGG

A. Kravspesifikasjon

B. Brukerdokumentasjon

C. Dokumentasjon av privat testmiljø

D. Dokumentasjon av Installasjon

E. Produksjonsettingsrapporter

F. Git

8.2 DATAORDBOK

Forkortelse Forklaring

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

Sniffe Se på / speile nettverks trafikk.

Parse Er å analysere, lese, sette sammen en rekke med symboler.

Bugs Logiske feil

TCP Transmission Control Protocol/Internet Protocol

Host En datamaskin / server

ORM Object Role Modeling(method for designing and querying database models)

Caching Mellomlagring av data

Raspberry Pi Liten datamaskin http://www.raspberrypi.org/

Aggregering Å kombinere eller slå sammen data for en representasjon av data i gruppering og/eller over tid.

Baselining Å finne en normal i noe som varierer av noe som er målbart ved hjelp av historisk analyse. Eksempelvis en normalytelse for en applikasjon til et gitt tidspunkt

Grensesnitt Grensesnitt, eller interface, er en abstraksjon for kommunikasjon mellom to systemer eller konsepter

URL Uniform resource locator, webadresse

groupby, having, extract, count

SQL-funksjoner

Plugin En plugin, eller programvareutvidelse, er en tilleggsmodul som tilbyr ekstrafunksjonalitet til et program.

Terminal Ofte synonymt brukt med en kommandolinje, en terminal er et program som kommuniserer med et operativsystem i form av tekst.

Daemon En bakgrunnsprosess, i stedet for å kontrolleres direkte av en interaktiv bruker.

8.3 REFERANSER

[1] Artikkel om OSI: http://en.wikipedia.org/wiki/OSI_model (sist lastet ned 26/5)

[2] Nettsiden til progammet scapy: http://www.secdev.org/projects/scapy/ (sist lastet ned 26/5)

[3] Nettsiden til SQLAlchemy http://www.sqlalchemy.org/ (sist lastet ned 26/5)

[4] Utregining av kapasitet på nettverk: http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321-

3.html (sist lastet ned 26/5)

http://www.raspberrypi.org/

http://en.wikipedia.org/wiki/OSI_model

http://www.secdev.org/projects/scapy/

http://www.sqlalchemy.org/

http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321-3.html

http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321-3.html


[5] Correct deamon behavior http://www.python.org/dev/peps/pep-3143/#correct-daemon-behaviour (sist lastet ned

26/5)

[6] PEP-3143: http://www.python.org/dev/peps/pep-3143/ (sist lastet ned 26/5)

[7] ISO 8601 datoformat: http://en.wikipedia.org/wiki/ISO_8601 (Lastet ned 20/5-2013). (sist lastet ned 26/5)

[8] Nettsiden til rammeverket flask: http://flask.pocoo.org/ (sist lastet ned 26/5)

[9] Nettsiden til rammeverket cherrypy: http://www.cherrypy.org (sist lastet ned 26/5)

[10] Hvilke webrammeverker for bruk i webservice. http://stackoverflow.com/questions/4419313/are-there-any-web-

server-modules-in-python (sist lastet ned 26/5)

[11] Sammenlikning av python webrammeverkerhttp://nichol.as/benchmark-of-python-web-servers (sist lastet ned

26/5)

[12] URL oversetter: https://github.com/gruns/furl (sist lastet ned 26/5)

[13] Twisted: http://twistedmatrix.com/trac/#webserver (sist lastet ned 26/5)

[14] Cornice: http://pypi.python.org/pypi/cornice (sist lastet ned 26/5)

[15] Tim Berners-Lee om formen på en URI http://www.w3.org/Provider/Style/URI (sist lastet ned 26/5)

[16] The Django Book om regulære utrykk og url config http://www.djangobook.com/en/2.0/chapter03.html (sist lastet

ned 26/5)

[17] Hvordan strukturere store django applikasjoner:

http://stackoverflow.com/questions/2670031/large-django-application-layout (sist lastet ned 26/5)

[18] «Django Project Structure» http://www.deploydjango.com/django_project_structure/index.html (sist lastet ned

26/5)

[19] Stackoverflow artikkel om hvordan man bør strukturere Django.

http://stackoverflow.com/questions/15305479/nvd3-js-will-not-take-data-from-jquery (sist lastet ned 26/5)

http://www.python.org/dev/peps/pep-3143/#correct-daemon-behaviour

http://www.python.org/dev/peps/pep-3143/

http://flask.pocoo.org/

http://www.cherrypy.org/

http://stackoverflow.com/questions/4419313/are-there-any-web-server-modules-in-python

http://stackoverflow.com/questions/4419313/are-there-any-web-server-modules-in-python

http://nichol.as/benchmark-of-python-web-servers

https://github.com/gruns/furl

http://twistedmatrix.com/trac/#webserver

http://pypi.python.org/pypi/cornice

http://www.w3.org/Provider/Style/URI

http://www.djangobook.com/en/2.0/chapter03.html

http://stackoverflow.com/questions/2670031/large-django-application-layout

http://www.deploydjango.com/django_project_structure/index.html

http://stackoverflow.com/questions/15305479/nvd3-js-will-not-take-data-from-jquery

Vedlegg A

Kravspesifikasjon

Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert

applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen og hva som forventes av de

forskjellige lagene i denne, men også krav til hvordan systemet skal designes og dokumenteres.

Filnavn: Kravspesifikasjon.docx Side: 2 av 7

1. PRESENTASJON

PROSJEKTTITTEL Nettverksbasert applikasjonsovervåking

APPLIKASJONSTITTEL PySniff

OPPGAVE Utvikle et rammeverk for overvåking av nettverkstrafikk mellom

applikasjoner i et nettverk.

1.1 MEDLEMMER I PROSJEKTET

Anders Struksnæs

Lars Haugan

Ole Henrik Paulsen

Tim Sæterøy

1.2 OPPDRAGSGIVER


KMIT & Innkjøp

Hammersborggata 2

0191 Oslo

[email protected]

1.3 KONTAKTPERSON


Martin Jensen

[email protected]

40218026

Avdelingsleder KMIT & Innkjøp, Drift Alliansen

1.4 VEILEDER

Torunn Gjester

Seksjon for Informasjonsteknologi

Høgskolen i Oslo og Akershus

1.5 BAKGRUNN

Origo og Drift Alliansen er avdelinger for IT brukerstøtte og drift i SpareBank 1 Gruppen. Avdelingene

leverer tjenester til SpareBank 1 Gruppen AS med datterselskap og bankene i SpareBank 1 Alliansen. Som

en del av oppgavene til Origo og Drift Alliansen jobbes det med monitorering og overvåking av IT-

tjenestene innen SpareBank 1 Gruppen AS.

Hensikten med prosjektet er utviklingen av et nytt overvåkingsverktøy som kan benyttes for overvåking av

applikasjoner som benyttes i SpareBank 1 Gruppen AS. Applikasjonen vil være et supplement til dagens

driftsovervåking og innføre begrepet trending i overvåkingen. Data skal trendes i form av å finne en grense

på hva som er normalt og hva som ikke er normalt i bestemt tidsperiode.

2. FORORD

Denne kravspesifikasjonen er beregnet for utviklere, oppdragsgiver og andre som er med i prosessen med

utvikling av applikasjonen. Kravspesifikasjonen definerer de krav som skal være til prosjektet og

applikasjonen, og er ment som et kontinuerlig verifiseringsdokument for å sikre god utvikling i prosjektet.


Innholdsfortegnelse

1. PRESENTASJON 2

1.1 MEDLEMMER I PROSJEKTET 2 1.2 OPPDRAGSGIVER 2 1.3 KONTAKTPERSON 2 1.4 VEILEDER 2 1.5 BAKGRUNN 2

2. FORORD 2

3. SYSTEMKRAV 3

3.1 FUNKSJONSKRAV 3 3.1.1 KRAV TIL SENSOR 4 3.1.2 KRAV TIL DATABASE 4 3.1.3 KRAV TIL CORE 4 3.1.4 KRAV TIL WEBSERVICE 4 3.1.5 KRAV TIL FRONTEND 5 3.2 TEKNISKE KRAV 5 3.3 KRAV TIL DATALAGRING 5 3.3.1 FUNKSJONELLE KRAV 5 3.3.2 IKKE FUNKSJONELLE KRAV 6

4. KRAV TIL DESIGN 6

4.1.1 FUNKSJONELLE KRAV 6 4.1.2 IKKE FUNKSJONELLE KRAV 6

5. KRAV TIL KODE 6

5.1 KODESTANDARD 6 5.2 VARIABLER OG FUNKSJONER 6 5.2.1 FUNKSJONELT 6 5.2.2 IKKE FUNKSJONELLE KRAV 6 5.3 KOMMENTERING 6 5.4 SPRÅK 6

6. KRAV TIL DOKUMENTASJON 6

6.1 OBLIGATORISK DOKUMENTASJON 6 6.1.1 STYRINGSDOKUMENTER 7 6.1.2 SLUTTDOKUMENTASJON 7 6.2 GENERELLE KRAV TIL DOKUMENTASJON 7 6.3 VERSJONSKONTROLL 7 6.3.1 FUNKSJONELLE KRAV 7 6.3.2 IKKE FUNKSJONELLE KRAV 7

7. UTVIDELSER 7

8. FREMMEDORD OG DEFINISJONER 7

3. SYSTEMKRAV

3.1 FUNKSJONSKRAV


3.1.1 KRAV TIL SENSOR

3.1.1.1 FUNKSJONELLE KRAV

Sensor skal være uavhengig av resten av applikasjonen.

Hvis det skal brukes flere sensorer, skal disse være uavhengig av hverandre.

Sensoren skal sniffe TCP, men det skal være mulig å legge til andre protokoller fra

transportlaget i OSI-modellen

Sensoren skal ikke forstyrre eller «stjele» kapasiteten eller ressursene til andre applikasjoner på

serveren den står på.

Sensoren skal bare videresende pakker som er definert i filteret.

3.1.1.2 IKKE FUNKSJONELLE KRAV

Sensor skal ha en oppetid på minimum 96,0% første året etter prosjektet er avsluttet.

Sensor skal ved bruk på applikasjonsserver ikke benytte mer enn en prosessorkjerne.

3.1.2 KRAV TIL DATABASE


Databaselag 1 skal inneholde all data sensoren sender til databasen.

Databaselag 1 skal være lagret i RAM.

Databaselag 2 skal kun inneholde aggregert data som hentes i fra databaselag 1.

Det skal være et logisk skille mellom databaselag 1 og databaselag 2 i form av egen

databaseprosesser kjørende.

Det er kun Webservice og Core som skal ha leserettigheter til databaselagene.

Det er kun Sensoren og Core som skal ha skriverettigheter til databaselag 1.

Det er kun Core som skal ha skriverettigheter til databaselag 2.


Databaseserveren skal ha en oppetid på minst 90% over ett år i fra prosjektslutt.

Data i databaselag 1 skal ikke være lagret lengere enn maksimalt 14 døgn.

Data i databaselag 1 skal minst være lagret i databaselag 1 i ett døgn.

Data i databaselag 2 skal ikke være lagret i lengere tid enn 27 måneder.

Data i databaselag 2 skal minst være lagret i databaselag 2 i 25 måneder.

Gjennomsnittet på spørre-kall skal være under 2 sekunder ved mindre en 4 klienter tilkoblet

frontend.

Spørring på real-time data skal maksimalt ha en forsinkelse på 5 sekunder i fra spørringen

ankommer databasen til databasen svarer.

3.1.3 KRAV TIL CORE


Legge til rette for aggregering av applikasjonsdata.

Et tidsintervall skal styre når aggregeringen skal utføres.

Core skal slette eventuell gammel data i databaselag 1, slik at databasen ikke blir full.

Aggregeringen skal bruke et felles pluginbibliotek, og legge til rette for utvidelser i form av flere

plugins.

Core skal kjøre i bakgrunnen og ikke påvirke andre prosesser.

Skal ikke være tilknyttet noen brukerøkt styrt av en bruker.

Funksjonalitet i Core skal være konfigurerbar.

Core skal logge handlinger slik at det er mulig å vite når og hva som utføres. Feilsituasjoner skal

også logges, brukt for feilsøking.

3.1.4 KRAV TIL WEBSERVICE


Webservice skal gjøre kall mot databaselag 1 og databaselag 2.

Feilsituasjoner og statusinformasjon skal logges til fil


o Et kall mot webservice skal resultere i en JSON-streng

Webservice skal benytte pluginer for ulike systemer/protokoller

o Hver enkelt plugin skal kun være beregnet på en spesifikk protokoll/system

o Disse skal ligge i en egen mappe, lib/plugins

Variabler som IP, port, osv skal ligge i konfigurasjonsfiler.


Kall mot database skal ikke ta over to sekunder

3.1.5 KRAV TIL FRONTEND


Støtte nye nettlesere, som siste versjon av Chrome, Firefox og Internet Exolorer.

Presentere data fra webservicen som grafer.

Benytte data fra webservice


Systemet skal kunne benyttes på en overvåkingsskjerm for å gjøre det mulig å respondere på

driftshendelser.

Skal benyttes javascript for å gjøre visning og bruk av frontend så responsiv som mulig.

Innlasting av nettsidene skal ta mindre enn 5 sekunder.

Innlasting av nettsidene skal helst lastes på mindre enn 2 sekunder.

Data kan sendes asynkront for å gjøre siden mer responsiv.

Data skal oppdateres minst hvert minutt.

3.1.5.3 MODELL

3.2 TEKNISKE KRAV

Systemet skal kunne kjøre på 64-bits versjon av Linux-distribusjonene som benyttes i

produksjonsmiljøet til SpareBank 1 (CentOS, RedHat).

Systemet skal utvikles og kjøres på Python versjon 2.7.3

3.3 KRAV TIL DATALAGRING

3.3.1 FUNKSJONELLE KRAV

Gruppen skal bruke Dropbox, Google Docs og Git

Alle på prosjektgruppen skal ha tilgang til overnevnte lagringsplasser


3.3.2 IKKE FUNKSJONELLE KRAV

Det skal gjennomføres backup av Dropbox, Google Docs minst 1 gang per uke. (For Git se punkt

eget punkt)

Dokumenter og innhold i overnevnte tjenester skal ikke slettes før minst ett halvt år etter

prosjektslutt.

4. KRAV TIL DESIGN


Nettsiden skal benytte skrifttype (font) som er beregnet for lesing på datamaskin.

Skrifttype brukt på nettsiden skal være åpen og tilgjengelig for bruk på Windows, Mac OS X og

Linux.


Det bør være lett å få oversikt

Det skal være et felles grensesnitt på alle sidene.

Det skal være gode kontraster i fargebruken.

Nettsiden skal være kompatibel med alle moderne nettlesere som Chrome, Firefox, Opera og

Internet Explorer med siste versjon.

5. KRAV TIL KODE

5.1 KODESTANDARD

Koden skal benytte UTF-8 tekst-encoding.

Koden skal være objektorientert.

Feilmeldinger skal alltid håndteres med logging av feilsituasjoner til fil.

Tekst skal aldri skrives stil stdout eller stderr, men til logg.

5.2 VARIABLER OG FUNKSJONER

5.2.1 FUNKSJONELT

Flere ord i variabelnavn skal settes sammen med bruk av underlinje (_).

Flere ord i funksjoner skal settes sammen med bruk av underlinje (_).


Variabelnavn skal være logisk i sammenhengen.

5.3 KOMMENTERING

Funksjoner skal alltid kommenteres med beskrivende tittel og returverdi.

Variabler trenger ikke å kommenteres.

Klasser skal kommenteres med hva de skal brukes.

5.4 SPRÅK

Gjennomgående språk i koden skal være engelsk, dette for å lette arbeidet med å sette seg inn i koden for

andre utviklere på et senere tidspunkt, samt at norske bokstaver (æ, ø og å) har vist seg å skape trøbbel i

tidligere prosjekter.

6. KRAV TIL DOKUMENTASJON

6.1 OBLIGATORISK DOKUMENTASJON


Følgende obligatoriske dokumenter skal utformes i løpet av prosjektets periode:

6.1.1 STYRINGSDOKUMENTER

Prosjektskisse

Forprosjektrapport

Arbeids- og fremdriftsplan

Kravspesifikasjon

6.1.2 SLUTTDOKUMENTASJON

Kravspesifikasjon

Prosessdokumentasjon

Produktdokumentasjon

Installasjonsdokumentasjon

Brukerdokumentasjon

6.2 GENERELLE KRAV TIL DOKUMENTASJON

Dokumentasjon skal følge standard dokumentmal fra SpareBank 1.

Dokumentene skal være skrevet for visning på papir.

6.3 VERSJONSKONTROLL


Alle på prosjektgruppen skal kunne skrive, klone og hente til/fra git-repositoriet.

Ingen skal jobbe direkte på Master branch.

Master branch skal bli brukt til produksjonsetting

Alle som skriver til git-repositoriet skal kommentere dette på norsk.


Git-repositoriet skal være privat, og kun prosjektmedlemmer skal ha tilgang.

Det skal tas backup av git-repositoriet minst én gang per dag.

Git skal være tilgjengelig minst 99% av prosjektperioden.

7. UTVIDELSER

Administrasjonsmuligheter fra frontend.

Illustrering av trender og data som grafer på frontend.

Tilgangskontroll for visning av frontend.

Støtte for flere protokoller

8. FREMMEDORD OG DEFINISJONER

Aggregering - Kombinere eller slå sammen data. F.eks minke data over lengre tidsperioder.

Trending - Det normalet i en gitt tidsperiode.

Sensor - En applikasjon som leser av nettverkstrafikk eller eksempelvis tekstfiler.

Vedlegg B

Brukermanual

Filnavn: Brukerdokumentasjon.docx Side: 2 av 11

Innholdsfortegnelse

1. INTRODUKSJON 3

2. UTVIKLING 3

2.1 PLUGINBIBLIOTEKET 3 2.2 SENSOR 4 2.3 DATABASE 5 2.4 CORE 6 2.5 WEBSERVICE 6 2.6 FRONTEND 6 2.6.1 INNHENTING AV DATA FRA WEBSERVICE 6 2.6.2 GRAFER 7

3. BRUK 7

3.1 PLUGINBIBLIOTEK 7 3.1.1 LOAD_SESSION 7 3.1.2 GET_STATUSCODES 8 3.1.3 IP_SEARCH 8 3.1.4 SOURCEPORT 8 3.1.5 DESTPORT 8 3.1.6 STATUSLINE_COUNT 8 3.1.7 STATUSLINE_ALL 8 3.1.8 STATUSLINE_DATE 9 3.1.9 HOSTNAME_COUNT 9 3.1.10 USERAGENT_COUNT 9 3.2 SENSOR 9 3.3 DATABASE 10 3.4 CORE 10 3.5 WEBSERVICE 11


1. INTRODUKSJON

Dette dokumentet er ment som en brukermanual for de som måtte ønske å ta i bruk, eller utvikle ny

funksjonalitet for de ulike delene i PySniff.

2. UTVIKLING

I dette kapittelet beskrives det som er nødvendig for å utvikle, og legge til rette for ny funksjonalitet i de

ulike delene av PySniff.

2.1 Pluginbiblioteket

Slik ser «skallet» for en tom plugin ut:

import datetime, os

import logging, logging.config

import cherrypy

from cherrypy import tools

logger = logging.getLogger('dev')

def get_class():

return EksempelPlugin()

class EksempelPlugin():

logger.info('Eksempel module loaded') Figur 1: Et skall for en tom plugin.

Denne filen skal lagres som eksempel.py i mappen lib/plugins.

Det første som må gjøres er å skrive en metode for tilkobling til databaselagene. En slik metode returnerer en

databasetilkobling som kan brukes av alle funksjonene som skal kommunisere mot databasen. En slik

funksjon kan se sånn ut:

def load_session(self):

'''

Creates and returnes a database session

'''

try:

metadata = Base.metadata

Session = sessionmaker(bind=engine)

session = Session()

logger.info('db session loaded')

return session

except:

logger.error('Something went terribly wrong' \

'when creating the db session.')

Denne funksjonen bruker noen variabler, disse er gjengitt her, og defineres som globale, ovenfor

«def_class()»:


con = 'postgresql+psycopg2://brukernavn:passord@IP-adresse:port/database' logger = logging.getLogger('dev') engine = create_engine(con, pool_size=50, max_overflow=0) Base = declarative_base(engine)

For eksempelets skyld, er det her ikke brukt konfigurasjonsfiler, men dette bør selvfølgelig brukes der det er

hensiktsmessig.

En funksjon i denne pluginen som skal være tilgjengelig utenfor Webservice, må ha disse to linjene foran

metodedefinisjonen:

@tools.json_out()

@cherrypy.expose

Den første linjen spesifiserer at funksjonen skal returnere gyldig JSON, den andre forteller CherryPy at

denne pluginen skal være tilgjengelig utenfra. Selve funksjonen er det ingen spesielle krav til, rent bortsett

fra at den skal returnere gyldig JSON. Det er likevel ønskelig at den skal følge visse krav til kommentering,

samt feilhåndtering og logging. Her følger et eksempel på en slik funksjon i sin helhet.

@tools.json_out() @cherrypy.expose def hostname_count(self, limit, start="0", end="0"): """Returns the most visited hosts, limited by limit, and optionally specify start and end time. Will return values for the last hour with no times specified

Args: limit: how many hosts that should be returned start (optional): timestamp for start time, format YYYY-mm-ddTHH:MM:SS end (optional): timestamp for end time, format YYYY-mm-ddTHH:MM:SS Returns: the most visited hosts, descending, limited by limit

""" start = self.format_start(start) end = self.format_end(end) try: session = self.load_session() query = session.query(HTTP.host, func.count(HTTP.host) \ .label('count')).filter(HTTP.date>=start, HTTP.date<=end) \ .group_by(HTTP.host).order_by(desc('count')).limit(limit) session.close() result = [{ 'hostname':res.host, 'count':res.count }for res in query] return result except Exception, err: logger.error(err) return []

2.2 Sensor

Sensoren er alt kompatibel til å fange opp nettverkstrafikken i transportlaget i OSI-modellen. Det som må

utvikles i Sensoren er en plugin for å hente ut den trafikken du vil ha av TCP-laget. I

PySniff/sensor/http_plugin.py er en plugin som henter ut HTTP-pakker fra TCP-laget. Denne pluginen


består av en rekke regulære-utrykk og sammensettinger for å returnere en Python pakke med innehold av den

trafikken du har lyst å returnere.

I /PySniff/sensor/sniffer.py som kjører pluginen for å prosessere TCP-strømmen og ta ut pakker av denne må

det evt legge til ny funksjonalitet for den nye pluginen. Dette kan gjøres ved å legge på en ny for løkke som

for eksempel er:

#This is the code to only take out HTTP packeges from the TCP stream.

http=packets.filter(lambda(s): http_plugin.HTTPrequest in s or http_plugin.HTTPresponse in s)

for p in http.filter(lambda(s): http_plugin.HTTPrequest in s):

postgres_handler.insert_into(hostname,p.src,p.dst,p.len,p.sport,p.dport,p.Method,p.Host,p.UserAgent)

Postgres_handler må også inneholde innsettings statementet til databasen. Denne kan se ut som for eksempel

def insert_into(ihostname,isrc, idst, ilen, isport, idport, imethod, ihost, iuserAgent):

session = load_session()

datef = strftime("%Y-%m-%d %H:%M:%S", time.localtime())

ins1 = HTTP(hostname=ihostname, date=datef, src=isrc, dst=idst, len=ilen,

sport=isport,dport=idport,method=imethod,host=ihost,useragent=iuserAgent)

session.add(ins1)

session.commit()

session.close()

2.3 Database

For å utvikle databasen til å inneholde enda en plugin for eksempel HTTP må man lage et nytt script for å

lage tabeller i databaselag 1 og databaselag 2.

Scriptet for http ser ut som for eksempel dette: db=create_engine('postgresql+psycopg2://username:[email protected]:5432/la

yer1')

db.echo = False

#Meta data does that everything before metada.create_all() is including in

the command

metadata = MetaData(db)

session = create_session()

#metadata.drop_tables()

#This is the table of layer1 HTTP.

table_http = Table('HTTP', metadata,

Column('id', Integer, primary_key=True),

Column('hostname', String),

Column('date', DateTime),

Column('src', String),

Column('dst', String),

Column('len', String),

Column('sport', String),

Column('dport', String),

Column('method', String),

Column('host', String),

Column('useragent', String),

Column('statusline', String),

Column('location', String),

Column('server', String),

Column('load', String),

) metadata.create_all()


2.4 Core

For Core sin del er det ikke snakk om videre utvikling av dens hovedfunksjonaliteten. Core er kun ment som

et lag rundt kall på aggregeringsfunksjonalitet som er å finne i pluginbiblioteket.

2.5 Webservice

Webservice er utviklet på en slik måte at den automatisk laster inn plugins. Det eneste kravet for at denne

skal lastes inn er at det ligger en fil i mappen lib/plugins, samt at variabelen valid_plugins inneholder

pluginnavnet. valid_plugins ser slik ut:

valid_plugins = ['http', 'sql']

For at Webservice skal legge til en ny plugin, for eksempel for FTP, skal en fil med navnet ftp.py, kopieres

til mappen lib/plugins, og valid_plugins i webservice.py oppdateres til

valid_plugins = ['http', 'sql', 'ftp']

2.6 Frontend

Frontend er utviklet på en slik måte at det er mulig å implementere ny funksjonalitet på mange måter.

Django benytter såkalte apps som det er mulig å opprette nye av for å implementere ny funksjonalitet. Disse

appene legges under frontend/PySniff/apps/<navn på app> og kan inneholde helt separert kode.

Nye apps vil tilføye muligheten for ny adskilt funksjonalitet, og inneholder egne MVC deler, som modeller,

tester og views. HTML templatene som er beskrevet i prosjektrapporten legges under

frontend/PySniff/template, hvor det kan legges til flere undermapper. Disse må da legges til i

konfigurasjonen pysniff.conf.

Under den nye appen kan nye funskjoner legges inn i viewet. Eksempel på en slik funksjon er gjengitt under.

Dette er en funksjon som henter base templaten og returnerer denne til brukeren.

def hello_world(request):

""" Prints base.html which prints hello world with the loading of static files """

t = get_template('base.html')

c = RequestContext(request, {})

return HttpResponse(t.render(c))

For å kunne benytte denne funksjonen må det enten konfigureres en ny url konfigurasjon for appen, eller

lages en regular expression som kan matches til funksjonen. I urls.py vil dette sett slik ut:

from django.conf.urls import patterns, include, url

from PySniff.apps.<your app name> import <your app name>

urlpatterns = patterns('',

# PySniff spesific

url('^hello_world$', <your app name>.hello_world), Denne url konfigurasjonen ville blitt matchet hvis en bruker hadde spurt etter http://localhost/hello_world.

2.6.1 Innhenting av data fra webservice Henting av data fra webservice er en annen viktig funksjon. Dette gjøres fra viewet. For at det skal være

mulig å benytte funksjonaliteten i webservice rammeverket, som gjør det mulig å koble mot webservicen, er

dette nødvendig å bli importert.

ftp://ftp.py/

http://localhost/hello_world


Dette gjøres ved å skrive følgende linje i viewet. from PySniff.libs.ws import ws

def api_getdata(request):

""" Function for getting data from webservice.

This is usefull since you cant use cross-site javascript requests """

stream = ws.webservice()

data = stream.api_getdata()

return HttpResponse(data, mimetype='application/json') Funksjonen over instansierer webservictilkoblingen og henter data via streamen som opprettes. Funskjonen

som benyttes er funksjonen som heter api_getdata();

2.6.2 Grafer Grafer genereres ved bruk av javascript. Dette skrives i templaten, og kan gjøres ved å opprette nye

templates eller ved å gjenbruke de andre som er benyttet. Nedenfor er et eksempel som oppretter og

genererer grafer. Det eneste som trengs i tillegg til dette er å konfigurere datoformatet, og dataene som skal

hentes.

var chart; var data = []; var model = nv.models.multiBarChart(); var modelname = "multiBarChart"; getJson();

function setupGraph(d) { var format = d3.time.format("%Y-%m-%d %H:%M"); nv.addGraph(function() {

chart = model .x(function(d) { return format.parse(d[0]) }) .y(function(d) { return d[1] }) .color(d3.scale.category10().range()) .clipEdge(false) .showControls(true); chart.xAxis .tickFormat(function(d) { return d3.time.format('%H:%M')( new Date(d)); }); if(modelname == "multiBarChart"){ chart.multibar.stacked(true); } d3.select('#chart1 svg') .datum(d) .transition().duration(500) .call(chart); nv.utils.windowResize(chart.update); return chart; }); }

3. BRUK

I dette kapittelet beskrives hvordan de ulike delene av PySniff kan tas i bruk.

3.1 Pluginbibliotek

3.1.1 load_session


def load_session(self): Beskrivelse: Denne funksjonen har hverken spesifisert json_out eller cherrypy.expose, hvilket betyr at funksjonen ikke skal kunne kalles eksternt. Den skal bare være tilgjengelig for bruk innad i http.py, og dens oppgave er å opprette og returnere en database-tilkobling for bruk i funksjonen som jobber mot databasen. «self» er en referanse til et objekt, og må være med i definisjonen, men ikke når metoden kalles. Returverdi: Databasetilkobling

3.1.2 get_statuscodes def get_statuscodes(self): Beskrivelse: Funksjonen returnerer alle de forskjellige HTTP-feilkodene som finnes i databasen. Returverdi: JSON-streng med HTTP-feilkoder.

3.1.3 ip_search def ip_search(self,loc,ip): Beskrivelse: Funksjonen returnerer alle linjer i databasen som inneholder en spesifikk IP. Parametere: loc: Kan være dst teller src, forteller om det er destinasjons-IP eller kilde-IP ip: Hvilken IP som skal søkes etter Returverdi: JSON-streng med alle feltene i databasen.

3.1.4 sourceport def sourceport(self, port): Beskrivelse: Funksjonen returnerer alle linjer i databasen med en spesifikk kildeport. Parametere: port: Hvilken port det skal søkes etter Returverdi: JSON-streng med alle feltene i databasen.

3.1.5 destport def destport(self, port): Beskrivelse: Funksjonen returnerer alle linjer i databasen med en spesifikk destinasjonsport.

Parametere: port: Hvilken port det skal søkes etter Returverdi: JSON-streng med alle feltene i databasen.

3.1.6 statusline_count def statusline_count(self): Beskrivelse: Funksjonen returnerer hvor mange linjer det er i databasen av hver enkelt statusline Returverdi: JSON-streng med statusline og dets antall.

3.1.7 statusline_all def statusline_all(self, status): Beskrivelse: Funksjonen returner alle datoer/tidspunkter til en gitt statuskode


Parametere: ™status: Hvilken statuskode som skal søkes etter, f.eks. 200 Returverdi: JSON-streng med dato/tidspunkt og statusline

3.1.8 statusline_date def statusline_date(self, status, start="0", end="0", grouping="minute"): Beskrivelse: Funksjonen returnerer antall statuskoder gruppert per minutt, mellom start og end, og gruppert på grouping. Start, end og grouping kan sløyfes om ønskelig. Start settes til tidspunktet for en time siden, og end settes til nå, om disse ikke spesifiseres.

Parametere: status: Hvilken statuskode som skal søkes etter, f.eks. 200 start: tidspunkt den skal søke fra format:2013-04-21T19:00:00 end: tidspunkt den skal søke til

format:2013-04-21T19:00:00 grouping: hva den skal gruppere på gyldige verdier: second, minute, hour, day, month Returverdi: JSON-streng med dato/tidspunkt og antall.

3.1.9 hostname_count def hostname_count(self, limit, start="0", end="0"): Beskrivelse: Funksjonen returnerer mest besøkte hosts, limitert av parameteren limit, og mellom start og end. Start og end kan sløyfes om ønskelig. Start settes til tidspunktet for en time siden, og end settes til nå, om disse ikke spesifiseres. Parametere: limit: antall linjer som skal returneres start: tidspunkt den skal søke fra format:2013-04-21T19:00:00 end: tidspunkt den skal søke til format:2013-04-21T19:00:00 Returverdi: JSON-streng med hostname og antall

3.1.10 useragent_count def useragent_count(self, limit, start="0", end="0"): Beskrivelse: Funksjonen returnerer mest besøkte user_agents, limitert av parameteren limit, og mellom tidspunktene start og end. Start og end kan sløyfes om ønskelig. Start settes til tidspunktet for en time siden, og end settes til nå, om disse ikke spesifiseres. Parametere: limit: antall linjer som skal returneres start: tidspunkt den skal søke fra format:2013-04-21T19:00:00 end: tidspunkt den skal søke til format:2013-04-21T19:00:00 Returverdi: JSON-streng med user-agent og antall

3.2 Sensor

sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniff-

sensor/sensor/pysniff_sensord.py start


sensor/sensor/pysniff_sensord.py stop



sensor/sensor/pysniff_sensord.py restart

Er følgende kommandoer som blir brukt til å styre sensoren. Disse må kjøre med sudo for å få tilgang til

nettverkskortet på maskinen.

3.3 Database

Tilganger til databasen blir gitt i følgende form i pg_hba.conf under pgdata folderen til PostgresSQL.

Disse blir gitt på følgende form: Host all all ip/cidr trust

For eksempel: Host all all 127.0.0.1/32 trust

Her må alle nett som skal få lov å kommunisere med databasen legges til. Dette er en sikkerhetsfunksjon i

PostgreSQL.

Databasen blir stoppet med service funksjoner i /etc/init.d/postgresql start/stop/restart

For å legge til databasebruker og passord til denne må dette gjøres i en tabell som heter template1.

Kommandoene for å opprette en ny bruker med tabell er da: Sudo su postgres

Psql template1

Create user sniffer with password ’password’;

Create database layer1;

Grant all privileges on database layer1 to sniffer;

^D

Exit

3.4 Core

Cores funksjonalitet ligger i å bruke aggregeringsfunksjonalitet i pluginbiblioteket. Hvilke funksjoner som

brukes i pluginbiblioteket defineres i aggregeringsprosessen, og består av kall på funksjoner i

pluginbiblioteket.

def process():

cfg.logger.info("Aggregate process starting...")

# Kall på aggregeringsfunksjon for HTTP i pluginbibliotek

http.aggregate_statuscodes()

cfg.logger.info("Aggregate process complete.")

I tillegg til å legge til kall på aggregeringsfunksjoner er det lagt muligheter for konfigurasjon av Cores

daemon og bruk av aggregeringsfunksjonene. Disse er definert i en egen konfigurasjonsfil, og på

konfigurasjonsformatet INI. Hvilken konfigurasjonsfil som er i bruk er definert i en egen Python-modul for

konfigurasjon i Core, ”config.py”:

config = ConfigParser.ConfigParser()

config.read(os.path.join(os.path.dirname(__file__), 'dev.ini'))

Her vises tidspunktet for når sletting av gammel data, hva som er å betegnes som gammel data, samt

tidsintervall for når aggregering skal utføres. Konfigurasjonen som følger er et utdrag av et eksempel på en

konfigurasjonsfil brukt i Core.

[Aggregate]

cleaning_time = 03 ; 24 hour format

frequency = 3600 ; seconds

too_old = 24 ; hours


Databasetilkoblingene brukt for slettingen av gammel data og annet arbeid på databasen er også å finne i

denne konfigurasjonsfilen.

[Database]

layer1_conn = postgresql+psycogp2://user:password@host:port/layer1

layer2_conn = postgresql+psycogp2://user:password@host:port/layer2

Basis for bruk av aggregeringsfunksjonaliteten i pluginbiblioteket er Cores daemon som håndterer

tidspunkter og tidsintervaller for når funksjonalitet skal utføres. Denne har også en konfigurasjonsbit, hvor

pidfile med prosess ID lagres og inn- og utdata fra programmet.

[Daemon]

stdin_path = /dev/null

stdout_path = /dev/tty

stderr_path = /dev/tty

pidfile_path = /var/run/pysniff/core.pid

pidfile_timeout = 5

Konfigurasjonen definert her benyttes deretter i Core daemonen. Hvordan konfigurasjonen lastes inn er ikke

ment å endres på.

Core har også loggfunksjonalitet som er definert i en egen konfigurasjonsfil for logging. Relevant for bruk

av Core er formatet på logglinjene og filstien til loggfilen.

[handler_coreHandler]

;.. linjer fjernet for eksempelets skyld

args=('core.log', 'a')

[formatter_coreFormatter]

format=%(asctime)s %(name)s %(levelname)s %(message)s

3.5 Webservice

Bruksområdene til webservice er limitert til kall på URLer fra for eksempel Frontend. Et slikt kall vil typisk

se slik ut:

127.0.0.1:8080/plugin/http/hostname_count/5/0/0

En fullstendig oversikt over funksjoner i HTTP-pluginen finnes i kapittel 3.1 i dette dokumentet.

Vedlegg C

Dokumentasjon av privat

testmiljø

Filnavn: Dokumentasjon av privat testmiljø.docx Side: 2 av 9

Innholdsfortegnelse

1. DOKUMENTASJON 3

1.1 INNLEDNING 3 1.1.1 ANSVAR 3 1.2 TEKNISK 3 1.2.1 OVERSIKTSBILDE 3 1.2.2 SPESIFIKASJONER AV HARDWARE 3 1.2.3 SPESIFIKASJONER AV NETTVERK 4 1.2.4 SPESIFIKASJONER AV SIKKERHET 5 1.3 BRUKERMANUAL FOR OPPSETT AV TESTMILJØET 5 1.3.1 KVM (KERNEL BASED VIRITUAL MACHINE) 5 1.3.2 INSTALLASJON AV CENTOS 7 1.3.3 KONFIGURASJON AV CENTOS 9


1. DOKUMENTASJON

1.1 Innledning

Dette dokumentet er ment som en installasjonsveiledning for testmiljøet vi har brukt under utviklingen

av PySniff.

Dokumentet er ment som en rask «bruksanvisning» til oppsett av eget testmiljø.

1.1.1 Ansvar

Vi har selv det fulle ansvaret for serveren. Vi har ingen annen support på serveren.

Dette innebærer drift av nettverk, brannmur, programvare, samt fysisk oppsett av maskinvare og

kabling.

1.2 Teknisk

1.2.1 Oversiktsbilde

Figur 1 - Virtuelt servermiljø

1.2.2 Spesifikasjoner av hardware

1.2.2.1 Hovedserveren

Testmiljøet vårt er hostet virtuelt på en HP ProLilant G6 server med 8GB ram, og 400GB SCSI disker.

Serveren står på 20/20-mbit SHDSL linje fra Powertech.


Figur 2 HP ProLiant DL380 G6

1.2.2.2 Spesifikasjoner for det virtuelle miljøet Det virtuelle miljøet består av CentOS VMer med følgende spesifikasjoner:

Felles for alle:

Centos 5.8

Python 2.7.3

Sensor1

Public IP: 77.40.217.203

Intern IP: 192.168.1.29

RAM: 256mb

Disk:

Sensor2

Public IP: 77.40.217.204 (eth1)

Intern IP: 192.168.1.86 (eth0)

RAM: 256mb

Disk:

Software: ingen utenom felles.

Core

Public IP: 77.40.217.205 (eth1)

Intern IP: 192.168.1.124 (eth0)

RAM: 4256mb

Disk:

Software: git, PostgreSQL, SQLite3, SQLAlchemy, Django, tmux.

1.2.3 Spesifikasjoner av nettverk

Det interne virtuelle nettverket består av to virtuelle switcher som binder det hele sammen. Se figur 1. Disse

er deretter sendt gjennom hosten til en fysisk Cisco switch.

Det eksterne nettet (det som ikke er virtuelt) består av flere komponenter. ( Se bilde under figur 3)


Figur 3 Nettverkskart

Testserveren står oppført med navnet «Rack»

NAS er backupløsningen vår.

Catalyst er kjernen av nettverket.

Deretter og ut er alt redundant.

TechSW er en switch som tar over for IntSW hvis den skulle gå ned.

Stress og Aladin er et «cluster» av brannmurer og gatewayer som balanserer lasten av nettet mellom seg.

Aladin kjører også statistikkløsningene våre ( som dette nettverkskartet, Zabbix og Munin )

Bakcup Gateway er backupløsningen til clusteret over. Denne inneholder også brannmuren.

ExtSW er switchen utenfor brannmur.

ZyXEL DSLAM er routeren og modemet powertech.

Powertech er nettverksleverandøren.

1.2.4 Spesifikasjoner av sikkerhet Brannmur

Testserveren vår kjører bak en Shorewall brannmur. Dette er en softwarebrannmur. Her kjører vi

«whitelisting» av noen IP’er. Dette betyr at vi kun tillater å koble til serveren fra enkelte IP’er. Dette er for å

redusere risikoen for å bli angrepet av uvedkommende.

For å logge på serveren vår må man da gjennom en såkalt hoppserver. Dette er en åpen server som alle i

gruppen har tilgang på fra hvor som helst. Til dette bruker vi for eksempel studentserveren på skolen.

Vi kjører ikke like høy sikkerhet som vi kommer til å gjøre hos SpareBank1, men dette fordi vi ikke har noe

sensitiv informasjon på testserveren.

1.3 Brukermanual for oppsett av testmiljøet

1.3.1 KVM (Kernel Based Viritual Machine)

Dette er dokumentasjon av hvordan du setter opp KVM på en Ubuntuserver. Denne installasjonen er gjort på

serveren spesifisert i punkt 1.2.2.1.


1.3.1.1 BIOS

Turn on Intel Virtualization Technology

Turn on shared memory

Nå kan du sjekke om serveren din vil kjøre optimalt med KVM.

For å sjekke kan du gå igjennom disse punktene:

egrep -c '(vmx|svm)' /proc/cpuinfo – Hvis denne returnerer 0, vil ikke KVM kjøre optimalt

1.3.1.2 Installasjon

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

sudo adduser ìd -un` libvirtd

Nå må du logge inn og ut av brukeren din for å få riktig rettigheter.

For å verifisere om installasjonen har gått bra kan du skrive:

virsh -c qemu:///system list

Outputen du skal få av overnevnt funksjon er: $ virsh -c qemu:///system list

Id Name State

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

$

Hvis det skulle returnere feil om permission denied, har du mest sannsynlig ikke de tilgangene du trenger til

/var/run/libvirt/libvrt-sock eller /dev/kvm

Dette kan fikses ved å skrive:

sudo chown root:libvirtd /dev/kvm

rmmod kvm

modprobe –a kvm

Når overnevnte punkter er fullført, har man mulighet til å sette på guest / virtuellemaskiner på hosten.

1.3.1.3 Konfigurasjon virt-install --connect qemu:///system -n Core -r 4000 --disk /home/kvmvm/coredisk.img, size=12GB -c

/var/lib/libvirt/images/CentOS-5.8-x86_64-bin-DVD1.iso,device=disk,bus=virtio --boot hd --cpu host --vnc

--noautoconsole --os-type linux --accelerate --bridge=br0

Starting install...

Allocating navn på vm' | <størelsen på vmen> GB 00:00

Creating domain... | 0 B 00:00

Domain installation still in progress. You can reconnect to

the console to complete the installation process.

Argument Forklaring

-n Navnet på VM’en du skal opprette

-r Antall MB med ram VM’en får

-disk, size Path til den virituelle harddisken til VMen.

Size er størelsen på hardisken

-c Path til installasjonsfilen til for eksempel CentOS Tabell 1 Variabler som kan endres i virt-install komandoen.

Når kommandoen ovenfor blir kjørt vil oppsettet av VM’en være i orden. Nå må du connecte til VM’en via

virt-manager for å fortsette OS-installasjonen.

1.3.1.4 Nettverk Har du problemer med å få nettverk på VM’ene så kan det være klienten som hoster VM’ene som er

problemet.

I Ubuntu kan du sjekke om du har en ”iface br0” i filen /etc/network/interfaces.


Hvis ikke det er noen linje som inneholder ”iface br0” kan du sette opp denne. Et eksempel på konfigurasjon

av en bridge:

iface br0 inet static

address 192.168.0.10

network 192.168.0.0

netmask 255.255.255.0

broadcast 192.168.0.255

gateway 192.168.0.1

bridge_ports eth0

bridge_stp off

bridge_fd 0

bridge_maxwait 0

1.3.2 Installasjon av CentOS Dette punktet går gjennom de viktigste skjermbildene under installasjonen av CentOS.

1. Trykk Enter

2. Velg å teste media før du installerer CentOS

3. Wizard starter med en ”Next” knapp som du trykker på

4. Velge språk, her kan det være lurt å velge engelsk, da det er lettere å få hjelp på nettet.

5. Velge Basic Storage devices


6. Klikk ”Re-intialize all”

7. Sett inn et hostename som for eksempel er Core.

8. Fyll inn root passord

9. Velg ”Use All Space”

10. Klikk ”Next”

11. Klikk ”Format”


12. Klikk ”Write changes to disk”

13. Merk av ”install boot loader on /dev/sda”

14. Velg minimal

15. Nå installeres CentOS, dette kan ta litt tid.

16. Fullført.

1.3.3 Konfigurasjon av CentOS Det første som burde gjøres når CentOS rebooter etter en installasjon er ferdig, er å skrive: ”yum update”

dette er for å oppdatere alle pakkene på serveren.

Nettverkskonfigurasjon i CentOS ligger i filen: /etc/sysconfig/network. Og denne kan for eksempel se ut

som eksempelet under.

HOSTNAME=Core

NETWORKING=yes

NETWORKING_IPV6=no

GATEWAY=128.192.0.1

IPADRESS= 128.192.1.11

PEERNTP=no

Når dette er på plass er CentOS klart til å brukes.

Vedlegg D

Dokumentasjon av

Installasjon

Dette dokumentet tar for seg detaljert informasjon vedrørende installasjon nødvendig for delapplikasjonene i

PySniff.

Filnavn: Dokumentasjon av Installasjon.docx Side: 2 av 10

Innholdsfortegnelse

1. INTRODUKSJON 3

2. PYTHON 3

2.1 INSTALLERING AV VIRTUALENV I PYSNIFF 4

3. SENSOR 6

3.1 LINUX AVHENGIGHETER 6 3.2 PYTHON-PAKKER 6 3.2.1 PSYCOPG2 6 3.2.2 SCAPY 6 3.2.3 SQLALCHEMY 6 3.2.4 PYTHON-DAEMON 6

4. DATABASE 7

4.1 INSTALLASJON AV CENTOS PAKKER 7 4.2 INSTALLASJON AV LAYER1 OG LAYER2 7 4.2.1 LAYER 1 7

5. CORE 8

5.1 PYTHON-PAKKER 8 5.1.1 SQLALCHEMY 8 5.1.2 PSYCOPG2 8 5.1.3 PYTHON-DAEMON 8

6. WEBSERVICE 9

6.1 PYTHON-PAKKER 9 6.1.1 CHERRYPY 9 6.1.2 SQLALCHEMY 9 6.1.3 PSYCOPG2 9

7. FRONTEND 10


1. INTRODUKSJON

Dette dokumentet tar for seg installasjon av Python 2.7.3, SQLAlchemy, samt det som er nødvendig for å

kjøre delapplikasjonene i PySniff. Dokumentet er svært teknisk, og tar for seg installasjon og konfigurasjon

ned på kommandonivå. Det er ikke meningen å lese dokumentet fra A til Å for å sitte igjen med noe, men

heller et oppslagsverk.

2. PYTHON

Python er et generelt objektorientert programmeringsspråk med fokus på fleksibel, men lesbar kode, og er

egnet for alt fra scripting til større prosjekter samt webutvikling. Python kan brukes på de fleste moderne

operativsystemer, inkludert *nix som er miljøet brukt i oppgaven.

Det ble valgt å benytte Python grunnet gode tilgjengelige biblioteker som løste sentrale deler av vårt

prosjekt. I tillegg var dette språket interessant for læringens skyld da ingen i gruppen hadde bred erfaring

med Python før dette prosjektet. Språket er også mye brukt hos oppdragsgiver SpareBank 1, og det var

derfor ønskelig at PySniff ble skrevet i et språk som de hadde erfaring med.

PySniff bruker Python versjon 2.7.3, som var siste offisielle stabile versjon av Python 2 ved prosjektstart.

Siste versjon av Python er 3, men det ble valgt å benytte versjon 2 som er mer utprøvd og har større

tilgjengelighet av programvarebiblioteker.

Versjon 2.7.3 av Python er ikke nødvendigvis installert på miljøet, eller operativsystemet, applikasjonen

kjører på. Det er heller ikke gitt at de nødvendige komponentene for PySniff som for eksempel Sqlite3 er

brukt for kompileringen av Python. Av denne grunn er det vanligvis nødvendig å installere en egen versjon

av Python hvis dette skal kjøre på produksjonssystemer som også andre applikasjoner skal kjøre på.

Test- og produksjonsservere kjører godt testet, men også eldre installasjoner av Linux-distribusjoner. Dette

er både grunnet at disse systemene vanligvis ikke kan stoppes for oppdatering om de kjører kritiske systemer

som krever høy oppetid, men også fordi man vet at eldre versjoner er godt utprøvd og stabile. Dette

innebærer gjerne også at det er gamle versjoner av programmer installert, noe som også gjelder Python.

Et typisk operativsystem brukt i produksjon er Linux-distribusjonen CentOS versjon 5.8, som er brukt for

både test- og produksjonsmiljøet til PySniff. Her er standard installert versjon på systemet Python 2.4. Man

kan heller ikke oppdatere til en nyere versjon uten å skape trøbbel på systemet, da andre programmer kan

være avhengig av akkurat denne versjonen av Python.


For å løse problemet med forskjellige versjoner av Python på samme system kan en kombinasjon av

”altinstall” og ”virtualenv” benyttes. Altinstall betyr at et program installeres separat fra systemfilene og

påvirker derfor ikke andre installerte versjoner, slik at standard versjon av Python ikke påvirkes av den nye

installeringen. Virtualenv er et verktøy for å lage isolerte, virtuelle Python-miljøer som ikke påvirker eller

påvirkes andre applikasjoner. I et slikt virtualenv kan det installeres Python-moduler som også er separert fra

resten av systemet.

For å effektivisere installeringen av Python på applikasjonsmiljøene PySniff er i bruk er det laget et shell

script i scriptspråket bash for installering av Python 2.7.3 beregnet på CentOS 5. Siden systemet brukt i

produksjon har strenge brannmurregler er det ikke mulighet for å laste ned alle pakkene med kildekode eller

programvarebiblioteker for Python nødvendig for Python eller PySniff fra internett, og disse må manuelt

lastes ned først.

Figur X viser deler av installasjonscriptet. For å korte ned koden er enkelte kommentarer som forklarer

gangen i scriptet og bekreftelse på å fortsette fjernet. Scriptet krever root-rettigheter (admin), samt at

nødvendig kildekode og pakker er lastet ned allerede:

Python-2.7.3.tar.bz2 – Kildekoden til Python

sqlite3_int64_v2.patch – fra http://bugs.python.org/issue14572

distribute-0.6.35.tar.gz – Python-modulen Distribute, nødvendig for Pip og Virtualenv

pip-1.3.1.tar.gz – Pakkebehandler for Python

virtualenv-1.9.1.tar.gz – Kildekode for Virtualenv-modul i Python

2.1 Installering av Virtualenv i PySniff

Tekniske installasjonskommandoer for distribute

wget http://python-distribute.org/distribute_setup.py

sudo python2.7 distribute_setup.py

Tekniske installasjonskommandoer for viritualenv

sudo easy_install-2-7 viritualenv

python2.7 /usr/local/bin/viritualenv-2.7 –distribute pysniff_env

For å aktivere viritualenv:

source ~/ pysniff_env /bin/activate

http://bugs.python.org/issue14572

http://python-distribute.org/distribute_setup.py


#!/bin/bash

# Install required packages for compilation

yum groupinstall "Development tools"

yum install {zlib,bzip2,openssl,ncurses,sqlite}-devel

# Ready for compilation

cd /tmp/python273

tar -xf Python-2.7.3.tar.bz2

cd Python-2.7.3

# Patch for _sqlite module - http://bugs.python.org/issue14572

cat ../sqlite3_int64_v2.patch | patch -p1

# Configure with shared libraries, used by mod_wsgi

./configure --prefix=/usr/local --enable-shared

# Compile and install

make

make altinstall # *NOT* install, very important!

# Fix path to shared lib - http://stackoverflow.com/a/7880519/1076493

echo "/usr/local/lib" >> /etc/ld.so.conf

/sbin/ldconfig

# Install distribute - http://stackoverflow.com/a/10538341/1076493

cd /tmp/python273

tar -xzvf distribute-0.6.35.tar.gz

/usr/local/bin/python2.7 distribute-0.6.35/setup.py install

# Install pip, because easy_install is deprecated

# http://trizpug.org/Members/cbc/wyntkap/img/pip_distribute.png

/usr/local/bin/easy_install-2.7 pip-1.3.1.tar.gz

# Install virtualenv and other interesting packages

# will be added to /usr/local/bin/

/usr/local/bin/pip install virtualenv-1.9.1.tar.gz

# Clean up

rm -rf /tmp/python273

# Done!

echo "Installation of Python 2.7.3 Done!"

Figur 1: Installasjonsscript for Python 2.7.3 på CentOS 5.


3. SENSOR

Installasjon av Sensor er avhengig av at Python2.7 og ViritualEnv er installert på serveren/klientmaskinen

den skal kjøre på. Den er testet på følgende operativsystemer: Linux Debian, Linux Ubuntu, Linux CentOS,

Windows 7.

3.1 Linux avhengigheter

På Linux trenger man å installere postgresql-devel / postgresql-dev pakken før man installerer pakkene inne i

et Virtualenv.

Dette gjøres på CentOS med:

Ubuntu og debian: sudo apt-get install postgresql-dev

CentOS: sudo apt-get install postgresql-devel libpg-dev

3.2 Python-pakker

Under er det listet med Python-pakker som må installeres for at sensoren skal fungere:

3.2.1 psycopg2 Pakken gjør støtte kobling mot PostgrSQL-database. Sensoren er testet med versjon 2.2.5

Manuell kommando for å innstalere denne pakken er:

pip install https://pypi.python.org/pypi/psycopg2/2.5

3.2.1.1 Windows avhengighet

I Windows må man installere Psycopg med følgende kommando: pip install http://www.stickpeople.com/projects/python/win-

psycopg/psycopg2-2.4.win32-pyx.x-pg9.0.3-release.exe

3.2.2 Scapy Pakken Scapy ligger ikke i Pypi sitt pakkebiblotek og må lastes ned fra deres nettsider. Denne kan

installeres med følgende kommando:

pip install http://www.secdev.org/projects/scapy/files/scapy-latest.tar.gz

3.2.3 SQLAlchemy Pakken SQLAlchemy gjør det mulig å bruke ORM’en for å sette inn pakker i databasen. Denne kan


pip install https://pypi.python.org/pypi/SQLAlchemy/0.8.1

3.2.4 Python-daemon Pakken Python-daemon gjør det mulig å kjøre sensoren som en bakgrunnsprosses. Denne innstalerer også

Lockfile automatisk som er en annen pythonpakke som Python-daemon trenger. Disse kan installeres med

følgende kommando:

pip install https://pypi.python.org/pypi/python-daemon/1.6

https://pypi.python.org/pypi/psycopg2/2.5

http://www.stickpeople.com/projects/python/win-psycopg/psycopg2-2.4.win32-pyx.x-‌pg9.0.3-release.exe

http://www.stickpeople.com/projects/python/win-psycopg/psycopg2-2.4.win32-pyx.x-‌pg9.0.3-release.exe

http://www.secdev.org/projects/scapy/files/scapy-latest.tar.gz

https://pypi.python.org/pypi/SQLAlchemy/0.8.1

https://pypi.python.org/pypi/python-daemon/1.6


4. DATABASE

Installasjonen av PostgreSQL er utført på en CentOS server.

4.1 Installasjon av CentOS pakker

Denne innstalerer databasemotoren til PostgreSQL på databaseserveren.

Sudo yum install postgresql

4.2 Installasjon av Layer1 og Layer2

4.2.1 Layer 1 Layer1 kjører som en RAMdatabase og denne trenger dermed tilstrekkelig med ram for å kjøre

PySniff/database/ramdisk/ramdisk.sh er et script du trenger å kjøre


5. CORE

For å kunne kjøre Core, må det være noen spesifikke pakker installert på maskinen der denne skal kjøre. Det

er mest hensiktsmessig å installere disse i et virtualenv:

5.1 Python-pakker

Kommandoer forutsetter at virtualenv er aktivert i henhold til forrige punkt.

5.1.1 SQLAlchemy Pakke for kobling mot database


5.1.2 psycopg2 Pakke for å støtte kobling mot en PostgrSQL-database.

psycopg2 krever at libpq-dev og python-dev er installert på systemet. Dette er utviklingspakker som kan


sudo apt-get install libpq-dev python-dev

Deretter kan psycopg2 installeres: pip install https://pypi.python.org/pypi/psycopg2/2.5

5.1.3 Python-daemon Pakken Python-daemon gjør det mulig å kjøre sensoren som en bakgrunnsprosses. Denne innstalerer også

Lockfile automatisk som er en annen pythonpakke som Python-daemon trenger. Disse kan installeres med

følgende kommando:

pip install https://pypi.python.org/pypi/python-daemon/1.6



https://pypi.python.org/pypi/python-daemon/1.6


6. WEBSERVICE

For å kunne kjøre Webservice, må det være noen spesifikke pakker installert på maskinen der denne skal

kjøre. Det er mest hensiktsmessig å installere disse i et virtualenv:

6.1 Python-pakker

Kommandoer forutsetter at virtualenv er aktivert i henhold til forrige punkt.

6.1.1 CherryPy Pakke for rammeverk og webserver

pip install http://download.cherrypy.org/cherrypy/3.2.2/CherryPy-

3.2.2.tar.gz

6.1.2 SQLAlchemy Pakke for kobling mot database


6.1.3 psycopg2 Pakke for å støtte kobling mot en PostgrSQL-database.

psycopg2 krever at libpq-dev og python-dev er installert på systemet. Dette er utviklingspakker som kan


sudo apt-get install libpq-dev python-dev

Deretter kan psycopg2 installeres: pip install https://pypi.python.org/pypi/psycopg2/2.5

http://download.cherrypy.org/cherrypy/3.2.2/CherryPy-3.2.2.tar.gz

http://download.cherrypy.org/cherrypy/3.2.2/CherryPy-3.2.2.tar.gz




7. FRONTEND

Dette avsnittet tar for seg det som er nødvendig for installasjon av Frontend.

Sjekke om mod_wsgi er installert

rpm –q mod_wsgi

Hvis ikke installert:

yum install mod_wsgi

Installere apxs for å få kompilert wsgi

yum install httpd-devel

/usr/sbin/apxs

./configure –with-apxs

/usr/sbin/apxs=/usr/sbin/axps –with-python=/usr/local/bin/python2.7

#setup

wget http://modwsgi.googlecode.com/files/mod_wsgi-3.4.tar.gz

tar xvfz mod_wsgi-3.4.tar.gz

mod_wsgi-3.4/configure --with-python=/usr/local/bin/python2.7

make

sudo make install

For installasjon av Frontend etter at komponentene over er installert benyttes førlgende fremgang.

Filene skal legges under /opt/pysniff/frontend, slik som de er presentert i prosjektet.

Det skal opprettes et virtualenv med python2.7 under /opt/pysniff/pysniff_env/

Installerer pakker med pip (Django, south og requests) pip install –r /opt/pysniff/frontend/requirements/*

/opt/pysniff/frontend/configuration/ inneholder en standard apache fil som referer til frontend.

Denne flyttes til /etc/httpd/conf.d/

For å starte apache med frontend /etc/init.d/httpd start

Hvis apache kjører;

/etc/init.d/httpd restart.

http://modwsgi.googlecode.com/files/mod_wsgi-3.4.tar.gz

Vedlegg E1

Produksjonssettings-

rapport milepæl 1

Dokumentet inneholder beskrivelse av første del av produksjonssetting av milepel 1 den 09.03.2013.

Rapport prodsetting M1 2013-03-09.docx Side: 2 av 4

INNHOLDSFORTEGNELSE

INNHOLDSFORTEGNELSE 2

1. INNLEDNING 3

2. OPPSUMMERING 3

3. PRODSETTINGEN 3

4. ÅRSAK TIL AVVIK 3

5. TILTAK 4

6. ORDLISTE 4


1. INNLEDNING

Denne rapporten beskriver forløpet ved produksjonssetting i SpareBank1 sitt testmiljø. Rapporten beskriver

også avvik og eventuelle tiltak for å ungå disse problemene.

Hele applikasjonen skulle lørdag 9/3 produksjonssettes i SpareBank 1 sitt testmiljø. Dette etter at systemet

har vært satt i drift i eget testmiljø.

2. OPPSUMMERING

Kravene for at applikasjonen skulle kunne installeres var muligheten for å kompilere python versjon 2.7 og

tilgang til git repository, som ligger på github.

Det oppsto problemer med installasjon av python versjon 2.7 da det benyttes et lokalt «mirror» (kopi av

installasjonspakker) for å installere programvare. Dette må benyttes for å installere programvare, da

SpareBank 1 sin policy ikke tillater installasjon av standard tillegsvare som kommer fra andre steder.

Dette førte til at det var flere ting som var nødt til å avklares med driftsavdelingen før det var mulig å

produksjonsette applikasjonen.

De manglende forutsetningene var kjennskap til policy for installasjon, når programmvaren ikke skal pakkes

på samme måte som det gjøres i SpareBank 1.

3. PRODSETTINGEN

Applikasjonen skulle i denne milepelen produksjonsettes i SpareBank 1 sitt testmiljø. SpareBank 1 følger

ITIL-rammeverket hvor det er satt opp tre miljøer som skal sikre god kontroll over applikasjoner. Disse

miljøene er test, QA (Quality assurance) og prod (production).

Applikasjonen skulle etter denne milepelen produksjonsettes i test. I dette miljøet er det satt opp to servere

til bruk for PySniff, der applikasjonen skal installeres. Serverene er satt opp med et bilde av CentOS som

følger SpareBank 1 sin standard.

Det er flere krav for å installere PySniff på en maskin, der det stilles krav til hvilke pakker som er

tilgjengelig fra mirror og i denne delen tilgang til internet.

Dette viste seg å være et problem da vi ikke hadde nok inngående kunnskap i dette miljøet til å forutse

problemer med vår konfigurasjon til å følge oppsettet.

Vi klarte ikke å få kontakt med internet fra testserverene, men klarte å få kontakt med en annen server som

stod i et anne miljø. Vi gjorde en vurdering ut i fra mulighetene til å sette opp en ssh tunell mellom disse to

miljøene for å kunne tunnelere all trafikken fra internett til internettet. Vi besluttet derimot å avvente svar fra

drift for å sørge for at alle rutiner og prosedyrer ble fulgt.

Etter avklaring med drift ble det klart at det ikke er mulighet for å tunnelere trafikk på disse nettverkene, da

det blant annet kan utgjøre en sikkerhetstrussel for hele nettverket.

For å løse problemet med manglende internettoppkobling ble det gjort et forsøk på å hente ned nødvendige

utviklingspakker fra det lokale «mirroret» til SpareBank 1. Pakkene som kreves av dette er utviklingspakker

til Python og PostgreSQL. Det kreves også tillegg til Python som lastes ned via internet.

Installasjon av de nødvendige pakkene ble avbrutt da det ble oppdaget at man ikke fikk lastet ned en

nødvendig pakke, og etter forsøk på å søke på de andre pakkene som kreves ble ikke disse funnet heller.

Som følge av dette var det heller ikke mulig å knytte kontakt til det eksterne kode-repositoriet github for å

hente innholdet til programmet.

4. ÅRSAK TIL AVVIK

Av årsakene til avvik fra produksjonsettingen var det hovedsakelig rutinefeil som gjorde at

produksjonsettingen måtte avbrytes. Det var ikke forutsett at det ikke var tilgang til internett under


installasjonen av applikasjonen, og heller ikke at de påkrevde filene ikke skulle være i det interne

repositoriet.

Det ble først forsåkt å få tilgang til internett, men da dette er et restriktert miljø er det ikke muligheter for å

koble direkte til internett uten aktive brannmuråpninger. Dette er det ikke mulighet for i dette miljøet. Som et

forsøk på å unngå installasjonsproblemene med manglende tilgang til internett, ble det utredet en rask

mulighet for å tunnelere trafikk over et annet miljø. Dette ble derimot ikke akutelt da det er en grunn til at

det ikke er mulig å koble til internett i første omgang, og det ble besluttet at man skulle avvente

driftsavdelingen for å avklare om dette er aktuelt.

Da det ikke var mulig å koble til internett ble det forsøkt å installere pakker via det lokale «mirror» (speiling

av et online pakkerepository, som kan inneholde ekstra interne pakker) til SpareBank 1.

Dette feilet da det ble forsøkt installert en pakke som ikke er standard i dette mirroret, noe som gjorde at

kommandoen feilet. Det ble da forsøkt å finne de forskjellige utviklingspakkene i det lokale mirroret, men de

så ut til ikke å være til stede.

Grunnen til at dette feilet var i første gang at pakken ikke eksisterte i mirroret, men alle de andre påkrevde

pakkene var tilgjengelig. Da denne først feilet ble det forsøkt å finne de andre pakkene med kommandoen

«yum search python | grep *dev» noe som ikke vil resultere i noen pakker da det blir søkt etter linjer som

inneholder tekststrengen «*dev».

5. TILTAK

Ettersom produksjonssettingen feilet, ble det avgjort at det skulle utføres ny produksjonssetting helgen etter,

da man i mellomtiden kunne avklare rutiner og gjøre klar for den nye typen produksjonssetting.

I tillegg for å kunne installere alle pakker som kommer i tillegg ble det nødvendig å laste ned

tilleggsprogramvare til python som ellers kunne vært installert med kommandoen «pip install

requirements.txt» (da pakkene som er listet i filen blir lastet ned direkte fra internet). Disse pakkene måtte da

lastes ned manuelt og overføres til serveren fra det lokale nettverket.

Det ble også oppdaget noen feil i visningen på frontend som skal rettes til neste leveranse av milepel 1, men

da installasjonen feilet før dette ble et aktuelt tema er dette et mindre tiltak for produksjonsettingen.

6. ORDLISTE

Ord Beskrivelse

Mirror Lokalt bilde av et eksternt pakkerepository med installasjonsfiler

Repository Datastruktur hvor pakker eller kode er lagret. For eksempel kode lagret i et

versjonskontrolleringssystem som git.

Git Versjonskontrolleringsystem

Python Programmeringsspråk

ITIL «Information Technology Infrastructure Library». Et strukturert rammeverk for

kvalitetssikring av IT tjenester. SpareBank 1 benytter en modifisert versjon av

ITIL.

Test Et miljø for testing av IT-tjenester og applikasjoner

QA Et miljø for å kvalitetssikre IT-tjenester og applikasjoner.

Prod Produksjonsmiljøet hvor alle IT-tjenester og applikasjoner kjører.

Miljø Et oppsett av servere og tjenester satt opp med spesielle regler, som sikkerhet,

brukeradministrering og installert programvare, som ikke er standard for alle

miljøer.

Vedlegg E2


rapport milepæl 1

Dokumentet inneholder beskrivelse av andre del av produksjonssetting av milepel 1 den 16.03.2013.


INNHOLDSFORTEGNELSE


1. INNLEDNING 3

2. OPPSUMMERING 3

3. PRODSETTINGEN 3

3.1 INSTALASJONSSTATUS 4

4. ÅRSAK TIL AVVIK 4

4.1 DIREKTE KONTAKT TIL FRONTEND PÅ PORT 80 4

4.2 MANGLENDE SQLITE PAKKER TIL FRONTEND 4

4.3 MANGLENDE TILKOBLING TIL DATABASE PÅ ORIGO5 4

4.4 FEILKONFIGURASJON AV MOD_WSGI 5


1. INNLEDNING

Denne rapporten beskriver produksjonssettingen i SpareBank1 sitt testmiljø. Rapporten beskriver også

eventuelle avvik og tiltak for å ungå disse problemene.

Denne produksjonsettingen er i SpareBank 1 sitt testmiljø. Serverene programvaren skal kjøre på har

installert CentOS som følger SpareBank 1 sin standard for test.

2. OPPSUMMERING

Etter feilet produksjonsetting 9/3 ble det gjennomført ny produksjonsetting helgen 16/3 – 17/3. Hele

applikasjonen skulle installeres på testservere i SpareBank 1 sitt testmiljø.

Installasjonen gikk ok og alle de planlagte delene ble produksjonsatt.

3. PRODSETTINGEN

Etter feilet produksjonsetting 9/3 ble det besluttet å utføre feilretting og ny produksjonsetting helgen 16/3 –

17/3. Grunnlaget for dette var innhenting av mer informasjon og tilegning av kunnskap rundt oppsett og

rutiner ved bruk av testmiljøet til SpareBank 1.

Ved første forsøk på produksjonsetting var det generelle grunnlaget for installasjon basert på tilkobling til

internet. Dermed måtte dette løses for å gjøre det mulig å installere applikasjonen. Installasjon av

standardpakker feilet også, og dette vil være løst i denne leveransen.

For å installere applikasjonen ble det først igangsatt instalasjon av Python. For installasjon av Python er det

laget et script for å automatisere installasjonen, med navnet «python273_install.sh». Dette scriptet installerer

Python 2.7.3 på CentOS versjon 5.x. Scriptet er avhengig av pakker fra det lokale pakke-repositoriet og vil

installere nødvendige utviklingspakker nødvendig for kompilering av Python.

Selve applikasjonene krever at Python er installert med riktige komponenter for at alle delene av

applikasjonen skal fungere optimalt.

Ettersom det ikke er mulighet for å koble til internett i dette miljøet, ble all nødvendig programvare lastet

ned til en annen maskin, som står i et sikret nettverk før de ble videresendt til applikasjonserverene. Det som

ble lastet ned var all kode som ligger i git repositoriet, samt tilleggspakker til python fra nettsiden

pypi.python.org.

Databasen ble først satt opp på maskin origo5. Etter at dette var gjort ble det forsøkt å koble mot denne

databasen fra origo4, men dette var ikke mulig på grunn av brannmurinstillinger. Derfor ble databasen også

satt opp til å midlertidig stå på origo4. Det ble i etterkant ordnet med databaseåpning slik at det er mulig å

koble til databasen på origo5 fra origo4.

Da det var gjort en endring i utviklingen som gjorde at det ble byttet databasemotor fra SQLite til PostgrSQL

ble det samtidig gjort en endring i installasjonscriptet til Python for å fjerne de overflødige pakkene. Dette

viste seg derimot å være et problem da frontend benytter seg av SQLite til lokal database. Dette gjorde at

python måtte rekompileres med denne pakken, men dette var ikke noe stort problem. Deretter måtte

mod_wsgi installeres, som er en modul til apache webserveren som gjør det mulig å kjøre python

programmer som websider. Dette gikk ok, men det var mangler i konfigurasjonen som førte til at bruken av

apache i denne versjonen ikke ble godtatt. Derfor ble frontend kjørt av den midlertidige webserveren.

For å etterfølge oppdragsgivers standarder ble applikasjonene flyttet til filstien /opt/pysniff/. Underliggende

for denne mappen er de induviduelle delene installert. Etter at applikasjonene var flyttet til sine respektive

mapper ble applikasjonen startet. Alt fungerte her ok, ref installasjonstatus.

Det ble i etterkant oppdaget at det kjørte en feil versjon av databasen. Dette gjorde at det var manglende

data. Det ser i etterkant ut til at dette har vært manglende opplastning til git som gjorde at dette scriptet var i

en gammel versjon. Dette ble rettet opp, ramdatabasen ble unmountet for å kunne sette den opp på nytt, og

ny installasjon av tabellene ble gjennomført ok.


3.1 Instalasjonsstatus

Delapplikasjon Status

Python OK

Database (PostgreSQL) OK

Frontend OK

Webservice OK

Core Ikke installert (ikke ferdig i denne versjonen)

Sensor OK

4. ÅRSAK TIL AVVIK

Det var enkelte avvik ved installasjonen som må endres til neste produksjonsetting. Noen av disse manglene

ble også rettet under produksjonsetting, men var ikke forutsett på forhånd.

Direkte kontakt til serveren på port 80

Manglende SQLite pakker til frontend

Manglende tilkobling til origo5 for database

Feilkonfigurasjon av mod_wsgi

4.1 Direkte kontakt til frontend på port 80

Ettersom serveren som applikasjonen kjører på står i et sikkert nett er det ofte behov for brannmuråpninger

for å gjennomføre tilkoblinger til serverene. Dette gjelder spesielt fra det vanlige nettet og mot serveren. I

dette tilfellet var det ikke mulig å koble på serveren med vanlig http (port 80), noe som i dette tilfellet gjorde

at vi var nødt til å benytte ssh-tunnelering mot serveren for å kunne emulere trafikk til port 80. Vi fikk da

verifisert at tjenestene fungerer som de skal, men manglende mulighet for å koble direkte til.

Dette ble rettet etter samtale med driftsavdelingen, da det måtte konfigureres en firewall fil som inneholdt

hvilke porter som skulle åpnses i iptables.

4.2 Manglende SQLite pakker til frontend

Da frontend benytter en lokal database, som er vesentlig for oppstarten av selve frontend var det ikke mulig

å starte selve applikasjonen etter installasjon. Ved å se på logger kommer det tydelig frem at dette er grunnet

manglende installasjon av SQLite. Rettere sagt er det en patch av SQLite som må kompileres sammen med

installasjonen av Python for å gjøre det mulig for python applikasjoner å benytte seg av SQLite databaser.

Dette ble rettet ved å endre installasjonscriptet for python, og det foretatt en rekompilering. Dette ble rettet i

løpet av kort tid og installasjonen av applikasjonen var vellykket.

4.3 Manglende tilkobling til database på origo5

Dette problemet er relatert til tilkoblingsproblemer på port 80. PostgrSQL kjører på port 5432 som standard,

men etter installasjon og kjøring av databasen på origo5 var det ikke mulig å koble til denne.

En måte å løse dette på er å kjøre tunell via serverene, noe som ble gjort mot origo4 for å kunne koble til

webserveren på port 80. Dette er derimot ikke ønskelig når det gjelder database og servere innenfor samme

miljø. For å løse dette problemet midlertidig ble databasen installert på origo4 slik at alle applikasjonene

etter denne leveransen ville kjøre på samme server. På dette distribusjonsnivået av installerte sensorer er det

ingen praktiske problemer ved å ha disse applikasjonene på samme server.

Dette ble løst i neste leveranse med å legge til firewall.conf fil for port 5432 på origo5.


4.4 Feilkonfigurasjon av mod_wsgi

For at mod_wsgi skal kunne benyttes er det nødvendig å ha flere konfigurasjonsfiler i orden for å kunne

starte apache (httpd) som server for frontend.

Det ble skrevet en virtualhost configurasjon for apache, som peker videre på standard wsgi config i frontend

prosjektet. Dette fungerte derimot ikke optimalt, og ettersom det ikke var noen god løsning på å fikse dette

uten å endre all konfigurasjonen ble det besluttet å avvente kjøring av frontend med mod_wsgi. Dette ikke

minst for å sørge for at applikasjonen først kjører optimalt med apache, men også for ikke å endre på konfig

som ikke bør endres.

Det ble derfor gjennomført flere tester på development miljøet som igjen kunne produksjonsettes i

testmiljøet til oppdragsgiver ved neste leveranse.

Vedlegg E3


rapport milepæl 2

Dokumentet inneholder beskrivelse produksjonssetting av milepel 2 den 07.04.2013.


INNHOLDSFORTEGNELSE


1. INNLEDNING 3

2. OPPSUMMERING 3

3. PRODSETTINGEN 3

3.1 BRANNMURÅPNINGER 3

3.2 INSTALLASJON AV SENSOR 3

3.3 UTRULLING AV NY DATABASEKONFIGURASJON 4

3.4 INSTALLASJON AV FRONTEND, WEBSERVICE OG CORE 4

3.5 INSTALASJONSSTATUS 6


1. INNLEDNING

Denne rapporten beskriver produksjonssettingen i SpareBank1 sitt testmiljø. Rapporten beskriver også

eventuelle avvik og tiltak for å ungå disse problemene.

Denne produksjonsettingen er i SpareBank 1 sitt testmiljø. Serverene programvaren skal kjøre på har

installert CentOS som følger SpareBank 1 sin standard for test.

2. OPPSUMMERING

Produksjonsettingen av PySniff milepel 2 ble gjennomført og alt gikk i denne sammehengen bra. Underveis

var det enkelt problematikk som var nødvendig å løse, og deler av produksjonsettingen ble også utsatt til

påfølgene dag for å kunne verifisere tekniske utfordringer med driftspersonalet hos oppdragsgiver før

gjennomført installasjon.

Etter forrige leveranse har mange av de problemene som oppstod blitt rettet, og de korrekte

brannmuråpningene har blir redgjort for slik at det nå er mulig å benytte applikasjonen i den kombinasjonen

som er intensjonelt planlagt. Databasen på origo5 kunne derfor i denne produksjonsettingen bli tatt i bruk og

rekonfigurert for å passe endringene.

Frontend er satt opp til å benytte tilegget til apache webserver, mod_wsgi og inneholder også ny

funksjonalitet som logging, nye grafer og bedre kommunikasjonsflyt med baksystemet.

3. PRODSETTINGEN

Etter forrige leveranse er det en del endringer i alle ledd av applikasjonen. Det er her mange funksjonelle

endringer, og omstruktureringer av kode som gjør det nødvendig med denne nye produksjonsettingen.

3.1 Brannmuråpninger

Etter forrige produksjonsetting ble blant annet databasen installert på begge serverene på grunn av

manglende brannmuråpninger. De manglende brannmuråpningene gjorde også at det ikke var mulig å koble

direkte til origo4 for å vise nettsiden.

Løsningen på dette er å konfigurere iptables til å tillate de korrekte portene. Dette gjøres ved å opprette en fil

i prosjektet med navn /opt/pysniff/firewall.conf som har et innhold som tilsier hvilke porter som skal være

åpnet. For å tillate tilkobling på port 80 for HTTP trafikk er det linjen «tcp 80» som skal være i denne filen.

For å rette brannmurtilgangen til databasen ble det opprettet en fil på origo5 under

/etc/sysconfig/iptables.d/pysniff_firewall.conf som inneholder de respekterte endringene for å tillate

tilkobling på port 5432 tcp.

Etter disse endringene, har applikasjonen alle de nødvendige kravene for å kjøres.

3.2 Installasjon av sensor

Et av hovedmomentene med denne produksjonsettingen var å installere sensoren på en av de

produksjonslike testserverene til SpareBank 1. Målet med dette er å kunne teste applikasjonen i et miljøet

der applikasjonene til oppdragsgiver kjører, da det er viktig å verifisere stabil drift og ikke minst at

applikasjonen ikke påvirker den generelle driften.

På applikasjonserveren til SpareBank 1 ble det opprettet en egen bruker til applikasjonen, slik at det skal

følge oppdragsgivers retningslinjer for applikasjonsdrift. Denne brukeren fikk rettigheter til å kjøre

programmer som root, og også shell. Dette er ikke en god løsning, og det ble i etterkant besluttet at sensoren

må kjøre under brukeren root da det ikke skal være andre brukere med root rettigheter på serveren.

Sensoren krever at det installeres en versjon av python som ikke er standard i CentOS og RedHat

operativsystemet som kjører på serverene, og dette utgjør et problem for installasjon av sensor. Det er eldre

versjoner av programvaren som er nødvendig, men da applikasjonen ikke er testet for bruk på eldre

programvare er det ikke mulig å garantere stabil drift, noe som gjør at vi ikke har muligheten til å


produksjonsette sensoren på en applikasjonserver som er nødvendig for den daglige driften. For også å unå å

risikere driftsavbrudd eller problematikk ved installasjon de nødvendige ekstra pakkene ble det besluttet å

avvente driftsavdelingen for mulighetene rundt dette.

Installasjon og avklaring ble gjennomført etter en del runder med driftsavdelingen vedrørende installasjon,

og de nødvendige prosedyrer påfølgende arbeidsdag.

3.3 Utrulling av ny databasekonfigurasjon

Da problematikk ved åpning av brannmur var rettet er det mulig å benytte databaseserveren som kjører på

origo5 i stedet for den lokale som kjører på origo4. Da det er gjort endringer etter forrige leveranse, som

blant annet skal gjøre det mulig for å aggregere data ved bruk av en ny database ble hele databasen satt opp

på nytt.

Det ble først kjørt script for å opprettet databasen. Deretter ble det opprettet ramdisk som databasen kjører på

for lagring. Ramdisken benyttes kun for lagring av layer1 data som er laget uagreggerte data lagres på.

For at databasen skal være ferdig konfigurert er det nødvendig å sette opp manuelt med brukere og

brukerkonfigurasjon. Dette ble gjennomført ok, og databasen kjørte som normalt.

Det viste seg også at det måtte gjøres endringer i den lokale konfigurasjonen til PostgreSQL som tillater

eksterne klienter for å koble seg opp mot databasen. Dette gjorde at ipadressen til origo4 måtte legges opp i

pg_hba.conf, som er brannmurkonfigurasjonen til PostgreSQL. Dette ble også gjort for subnettet der

sensoren kjører for å tillate direkte kommunikasjon fra denne.

Etter disse konfigurasjonsendringene var databasen oppe og kjørte uten problemer.

3.4 Installasjon av frontend, webservice og core

Etter forrige produksjonsetting ble applikasjonen installert under /opt/pysniff/. Dette er korrekte plassering

etter oppdragsgivers standard. For å følge denne strukturen, og samtidig ha backup fra forrige installasjon

ble det tatt kopi av denne mappen slik at det lett skulle være mulig å rulle tilbake til forrige versjon. Dette er

ingen god løsning, men dette er en mellomting mellom å pakke applikasjonen til pakkesystemet til

centos/redhat, som er en relativt kompisert affære når det kommer til de standardene som skal benyttes, og

det å benytte git med tilkobling til eksternt repository på github. Da det sistnevnte ikke er mulig gjøres det på

denne måten da applikasjonen ikke er satt ut i produksjonmiljøet.

For å rydde opp i installasjonsmappen ble pythons virituelle miljøer slått sammen fra å være et for hver

delapplikasjon, til å være ett for hele applikasjonen. Da det ikke kreves forskjellige versjoner av noen av

pakkene er dette den beste løsningen for å gjøre det mulig å vedlikeholde de installerte pakkene.

Pakkene som var lastet ned fra forrige leveranse ble derfor installert i det virituelle miljøet

/opt/pysniff/pysniff_env.

Dev branch ble lastet ned fra github.com, og inneholder all kode og nødvendige filer i .zip mappen. Denne

ble overført via winscp til origo4. Denne ble pakket ut til /home/sniffer/prod0.2/Pysniff-dev/ for å gjøre det

optimalt å flytte programkoden til /opt/.

Før applikasjonkoden ble flyttet til installasjonplasseringen ble de induviduelle applikasjonene som kjørte

fra før stoppet. Det ble gjort i følgende rekkefølge:

1. Frontend ble stoppet ved å sende SIGINT «Keyboard interrupt» til manage.py som er development

serveren til Django/Frontend. Deretter ble screenen den kjørte i killed.

2. Webservice ble stoppet med «Keyboard interrupt» da den får kjørt ferdig de resterende prosesser og

avsluttes på en god måte. Screenen som den kjørte i ble killed.

3. For å avslutte PostgreSQL ble det forsøkt å benytte «sudo /etc/init.d/postgresql stop», men dette

gikk ikke. Derfor ble først «postmaster» applikasjonen drept ved å finne programmets PID («ps aux |

grep postmaster») før de resterende applikasjonene som kjøres av brukeren «post» ble avsluttet.

Koden som lå i /opt/pysniff ble etter dette fjernet fra mappen slik at den nye koden kunne legges inn, uten å

måtte overskrive gammel kode.


Det viste seg også at sensoren kjørte på denne serveren fra forrige leveranse, og da programfilene ble flyttet

fra /opt/pysniff/ ble denne stoppet på en dårlig måte. Da det skulle installeres en ny versjon som ikke var

avhengig av noen av filene, var derimot ikke dette noe stort problem.

Applikasjoninnholdet ble etter dette flyttet fra /home/sniffer/prod0.2/Pysniff-dev/ til /opt/pysniff/.

Ettersom de nødvendige pakkene allerede var installert i miljøet (environment) kunne applikasjonen startes

uten videre. Derfor ble først webservicen startet i en egen screen. Screenen ble denne gangen startet med

kommandoen «screen –S pysniff_webservice» for å kunne skille de forskjellige screnene fra hverandre når

flere applikasjoner kjører i screen på serveren.

Oppstart av webservicen var etter dette ok, og den returnerte verdier fra helsesjekk.

For oppstart av frontend kreves det litt mer arbeid da applikasjonen benytter en eksensjon til apache,

«mod_wsgi» som gjør det mulig å kjøre python programmer som websider ved bruk av apache webserveren.

Da det ble besluttet å gjøre endringen av python environmentet fra de induviduelle environmentene til

«/opt/pysniff/pysniff_env» var det også nødvendig å skrive om konfigurasjonen fra dev branchen i git til å

refleketere disse endringene. Det som måtte endres var derfor en adresse som refleketerer til python

environmentet i frontend/pysniff.wsgi filen, samt i apache configen til pysniff plassert under

/etc/httpd/conf.d/origo4.test.sparebank1.no.conf. Origo4.test.sparebank1.no.conf ble flyttet fra prosjektet til

httpd mappen slik at denne skulle kunne startes av apache. Denne er testet til å passe til utviklingsmiljøet,

men da det ikke er mulig å teste dette i oppdragsigvers testmiljø, er det nødvendig med enkelte rettelser av

konfigurasjonen.

Etter start av apache, med kommandoen «sudo /etc/init.d/httpd start» startet apache ok, men ved forsøk på å

koble opp mot webserveren feilet denne stille, uten å returnere noe fornufig og uten feilmeldinger i loggene

til apache under «/var/log/httpd/access_log og error_log».

Det ble da oppdaget at filen hadde fått feil navn ved flytting og ikke hadde med postfixen «.conf» som er

nødvendig for å kunne laste inn virtualhost konfigurasjonen til apache.

Da dette var rettet oppstod det et problem ved at det ikke var mulig å laste ned tilleggsfiler fra applikasjonen

ved besøk på url. Årsaken til dette er manglende videresendign av urlen «/static/» som refererer til de

statiske filene konfigurert i djangos urls.py fil. For å rette dette ble det lagt inn et alias til denne plasseringen

i virtualhost konfigurasjonen i apache. Denne ser slik ut «alias /static/ /opt/pysniff/frontend/PySniff/static/».

I tillegg til konfigurasjonedringen til frontend er det også behov for logging spesfikt fra frontend

applikasjonen. Denne er konfigurert til å bli lagret under /var/log/pysniff/, men da apache kjører som

brukeren «apache» er også mappen nødt til å reflektere rettighetene til denne brukeren. Valget er derfor om

brukeren apache skal legges inn i gruppen til «pysniff» eller om det skal opprettes en egen loggruppe for

håndtering av dette. For å utsette denne problematikken og gjøre det mulig for de andre delene av PySniff til

å logge til /var/log/pysniff/ ble loggingen flyttet til /var/log/pysniff/frontend/ med undermappene «trace» og

«httpd» som respektivt inneholder loggingen fra selve applikasjonen og loggene som kommer fra virtualhost

konfigurajsonen til apache.

Etter at disse punktene var rettet kjører delapplikasjonen frontend slik den skal.

Den siste applikasjonen som det i denne leveransen skal settes opp er core. Da snifferen er satt ut i

produksjon på en annen applikasjonserver er det behov for kontroll over dataene som ligger i layer 1 i

databasen. Dette gir core applikasjonen i form av funksjonalitet for å periodisk gjøre operasjoner på

databasen. Resultatet av dette er at dataene som er i lag 1 slettes med et intervall på en dag. Dette gjør også

at oppsettet av agreggering er en enkel sak i neste produksjonsetting.

For oppsett av core kreves det ekstra pakker fra pypi (som er python sin pakkesentral). Det ble derfor

gjennomgått hvile pakker som allerede var installert i virtualenvironmentet, og det ble da oppdaget at av de

pakkene som var installert var det i enkelte tilfeller gamle pakker og betaversjoner. Disse ble derfor lastet

ned på nytt med siste versjon, slik at disse kunne oppdateres.


Etter at disse var oppdatert, hadde i mellomtiden ikke webservicen blitt stoppet, og ettersom webservicen

benytter pakker fra environmentet for å koble mot databasen, hadde denne kræsjet. Derfor måtte

webservicen startes igjen etter installasjonen.

For å starte core applikasjonen er det først behov for å endre konfigurasjonen for å reflektere de riktige

konfigurasjonene for miljøte. Dette inkluderer stien til hvor applikasjonen ligger, hvor loggfiler skal ligge og

hvilken instillingsfil som skal benyttes. Etter at disse endringene var utført ble core startet med kommandoen

«python pysniffd.py start».

3.5 Instalasjonsstatus

Delapplikasjon Status

Python OK

Database (PostgreSQL) OK

Frontend OK

Webservice OK

Core OK

Sensor OK

Vedlegg F

Dokumentasjon av Git

Vedlegg for dokumentasjon av Git, versjonskontrollsystemet brukt i utviklingen av PySniff.

Hvorfor Git er brukt, hvilken modell som er valgt og hvordan vi har kommet frem til denne.

Filnavn: Dokumentasjon av Git.docx Side: 2 av 7

Innholdsfortegnelse

1. INTRODUKSJON 3

1.1 HENSIKT 3 1.2 HVA ER GIT OG VERSJONSKONTROLL 3 1.3 GIT REPOSITORY 4 1.3.1 GITHUB 4

2. DATAFLYTMODELL 5

3. STABILITET OG PÅLITELIGHET 6

3.1 DATAORDBOK 7 3.2 REFERANSER 7


1. INTRODUKSJON

Dette dokumentet gir en oversikt over bruken av versjonskontrollsystemet Git i utviklingen av PySniff og

alle dets undersystemer. Det vil bli forklart hvorfor det er ønskelig med et versjonskontrollsystem i

programutvikling, spesielt utvikling i grupper, og hvorfor akkurat Git er blitt valgt.

1.1 Hensikt

Ved hjelp av dette dokumentet skal det være mulig å forstå Gits posisjon som versjonskontrollsystem under

utviklingen av PySniff. Følgelig vil det bli begrunnet med hvorfor, og hvordan verktøyet er blitt brukt.

1.2 Hva er Git og versjonskontroll

Et versjonskontrollsystem er programvare som holder oversikt over

endringer eller versjoner av datafiler. Endringer lagres i en database,

vanligvis med full historikk med mulighet for kommentering underveis. I

tillegg til identifisering av forskjellige versjoner kan det være mulig med

forskjellige «utviklingsgrener», som gjør utvikling i grupper enklere ved at

man ikke «kræsjer» i andres arbeid, men samtidig kan samarbeide på

grener.

Git er et distribuert versjonskontrollsystem. Ved distribuert menes det at

hver eneste bruker har en lokal kopi av kodebasen på det felles repositoryet,

hvor koden i effekt sendes mellom forskjellige brukere. Dette er til forskjell

fra tradisjonell klient-server tilnærming av versjonskontroll, hvor man

typisk er avhengig av tilgang til en felles sentral.

For å kunne kommunisere med et Git repository trengs en Git klient.

Klienten består enten av kommandolinje eller et brukergrensesnitt. Denne

brukes til å utføre kommandoer for å sjekke endringer i filer, legge de til i et

repository, synkronisere med felles repository m.mer.

Git-klienten installeres lokalt på en maskin, men ved bruk av Github eller

lignende tjenester er det også mulig å kommunisere med et repository

gjennom nettleser.

Figur 1: Versjonskontroll


1.3 Git repository

Hoveddelen av et Git-system er et repository. Git er som nevnt et distribuert versjonskontrollsystem, hvilket

betyr at det er flere repositories brukt for å holde kontroll på kodebasen som stadig synkroniseres med

hverandre.

Bruk av et Git repository består av både en sentral og en lokal klone, hvor brukere av forskjellige

repositories synkroniserer disse mot hverandre.

1.3.1 Github Github er en tilbyder av en komplett løsning for Git repositories og nyttige verktøy rundt dette. Dette

inkluderer, men er ikke begrenset til, hosting av repositories enten offentlig eller privat, statistikk,

brukerhåndtering og et webgrensesnitt med tilgang til kodebaser i repositores.

Det er valgt å bruke Github som tilbyder av privat repository grunnet deres effektive webgrensesnitt og alle

de nyttige verktøyene rundt, som f. eks statistikk og mulighet til å se filer og deres endringer direkte i

nettleser uten å måtte trenge en lokal Git klient.

Gruppen har fått tilgang til et privat repository gjennom en studentordning til Github hvor man får gratis

tilgang til private repositories. Dette vil si at selv om kodebasen ligger på en ekstern server (i tillegg til de

lokale kopiene), er de ikke offentlig tilgjengelig.

Repositoriet er tilgjengelig for nedlastning ved hjelp av HTTP, Zip eller bruk av Git-protokollen.

Synkronisering er alltid tilgjengelig så lenge de nødvendige portene er åpne på den lokale tilkoblingen brukt.

Akkurat dette kan vise seg å være et problem, som forklart i neste punkt.


2. DATAFLYTMODELL

Figur 2: Git branching model

Dette prosjektet broker en modifisert versjon av dataflytdiagram vist ovenfor, men ideen er den samme.

Master branch som inneholder godkjent kode


Figur 3 - Git dataflyt [4]

3. STABILITET OG PÅLITELIGHET

Siden Git er et distribuert versjonskontrollsystem har alle klonene/brukerne av et repository en lokal klone

av repositoriet. Dette gjør at om f. eks man ikke har tilgang til internett, Github som hoster det felles repoet

er nede eller at noen opplever datatap så har man fortsatt tilgang på kopier av koden og mulighet til å sende

inn commits.

Alternativet er gjerne at man har et sentralt repository og at man kun har sine endringer lokalt og/eller ikke

har mulighet til å lagre dine endringer/commits uten tilgang til det sentrale repositoriet. Et eksempel på dette

er SVN. Dette betyr at om man f. eks ikke har tilgang til internett kan man heller ikke arbeide med koden.


3.1 Dataordbok

Forkortelse Forklaring

Versjonskontrollsystem Programvare som holder ordentlig på forskjellige versjoner av en eller flere

datafiler med full historikk.

Repository Et sett med filer og mapper brukt av et versjonskontrollsystem, med historikk

over endringer og pekere på grener.

Commit Et sett av endringer på filer og/eller mapper lagret til et repository. Vanligvis

med en kommentar som beskriver endringen. Har en ID.

SSH En sikker nettverksprotokoll for kommunikasjon mellom klient og tjener, typisk i

form av et shell (kommandolinje) eller andre nettverkstjenester.

Hosting Å hoste noe. Leie/selge lagringsplass og/eller nettkapasitet hos en

serverleverandør, til f. eks å ha lagret et Git repository tilgjengelig via internett.

Pakkebehandler En samling verktøy for å installere/oppdatere/konfigurere programvare på en

datamaskin. Hovedsaklig brukt til å installere pakker (programmer) via

pakkebrønner tilbudt av forskjellige Linux distribusjoner.

Terminal Terminal, eller terminalemulator, er et program for å kommunisere

operativsystemet eller programvare gjennom et shell/kommandolinje i form av

tekst.

3.2 Referanser

Id Referanse Beskrivelse

1 [MAL] SoftwareArchitectureDocument (SAD) fra bussruta.sparebank1.no. Versjon

1.0

2 A successful Git

branching model

http://nvie.com/posts/a-successful-git-branching-model/

3 Revision controlled

project visualization

http://en.wikipedia.org/wiki/File:Revision_controlled_project_visualization-

2010-24-02.svg

4 Git Tutorial – Getting

Started

http://www.javacodegeeks.com/2012/03/git-tutorial-getting-started.html

http://nvie.com/posts/a-successful-git-branching-model/

http://en.wikipedia.org/wiki/File:Revision_controlled_project_visualization-2010-24-02.svg

http://en.wikipedia.org/wiki/File:Revision_controlled_project_visualization-2010-24-02.svg

http://www.javacodegeeks.com/2012/03/git-tutorial-getting-started.html

Documents

Prosjektrapport - student.cs.hioa.nostudent.cs.hioa.no/hovedprosjekter/data/2013/04/doc/Prosjekt... · SpareBank 1 Gruppen AS, heretter SpareBank 1, står for den daglige driften