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
Filnavn: Prosjektrapport.docx Side: 3 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
Filnavn: Prosjektrapport.docx Side: 4 av 71
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).
Filnavn: Prosjektrapport.docx Side: 5 av 71
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
Filnavn: Prosjektrapport.docx Side: 6 av 71
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
Filnavn: Prosjektrapport.docx Side: 7 av 71
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
Filnavn: Prosjektrapport.docx Side: 8 av 71
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.
Filnavn: Prosjektrapport.docx Side: 9 av 71
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.
Filnavn: Prosjektrapport.docx Side: 10 av 71
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.
Filnavn: Prosjektrapport.docx Side: 11 av 71
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.
Filnavn: Prosjektrapport.docx Side: 12 av 71
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.
Filnavn: Prosjektrapport.docx Side: 13 av 71
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
Filnavn: Prosjektrapport.docx Side: 14 av 71
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.
Filnavn: Prosjektrapport.docx Side: 15 av 71
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.
Filnavn: Prosjektrapport.docx Side: 16 av 71
Figur 7: Virtuell Machine Manger terminaler
Filnavn: Prosjektrapport.docx Side: 17 av 71
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.
Filnavn: Prosjektrapport.docx Side: 18 av 71
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.
Filnavn: Prosjektrapport.docx Side: 19 av 71
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.
Filnavn: Prosjektrapport.docx Side: 20 av 71
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.
Filnavn: Prosjektrapport.docx Side: 21 av 71
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
Filnavn: Prosjektrapport.docx Side: 22 av 71
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.
Filnavn: Prosjektrapport.docx Side: 23 av 71
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å.
Filnavn: Prosjektrapport.docx Side: 24 av 71
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.
Filnavn: Prosjektrapport.docx Side: 25 av 71
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.
Filnavn: Prosjektrapport.docx Side: 26 av 71
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
Filnavn: Prosjektrapport.docx Side: 27 av 71
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.
Filnavn: Prosjektrapport.docx Side: 28 av 71
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 APPLIKASJONSDESIGN
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
Filnavn: Prosjektrapport.docx Side: 29 av 71
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
Filnavn: Prosjektrapport.docx Side: 30 av 71
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.
Filnavn: Prosjektrapport.docx Side: 31 av 71
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.
Filnavn: Prosjektrapport.docx Side: 32 av 71
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.
Filnavn: Prosjektrapport.docx Side: 33 av 71
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.
5.3.3 APPLIKASJONSDESIGN
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.
Filnavn: Prosjektrapport.docx Side: 34 av 71
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.
Filnavn: Prosjektrapport.docx Side: 35 av 71
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.
Filnavn: Prosjektrapport.docx Side: 36 av 71
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
Filnavn: Prosjektrapport.docx Side: 37 av 71
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.
Filnavn: Prosjektrapport.docx Side: 38 av 71
# 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.
Filnavn: Prosjektrapport.docx Side: 39 av 71
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.
Filnavn: Prosjektrapport.docx Side: 40 av 71
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.
Filnavn: Prosjektrapport.docx Side: 41 av 71
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.
5.4.3 APPLIKASJONSDESIGN
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.
Filnavn: Prosjektrapport.docx Side: 42 av 71
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.
Filnavn: Prosjektrapport.docx Side: 43 av 71
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.
Filnavn: Prosjektrapport.docx Side: 44 av 71
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.
Filnavn: Prosjektrapport.docx Side: 45 av 71
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.
Filnavn: Prosjektrapport.docx Side: 46 av 71
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.
Filnavn: Prosjektrapport.docx Side: 47 av 71
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.
5.5.3 APPLIKASJONSDESIGN
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.
Filnavn: Prosjektrapport.docx Side: 48 av 71
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
Filnavn: Prosjektrapport.docx Side: 49 av 71
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].
Filnavn: Prosjektrapport.docx Side: 50 av 71
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('^api/plugin/(?P<plugin>\w+)/(?P<function>\w+)/(?P<param>.*)$', views.api_plugin),
url('^api/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.
Filnavn: Prosjektrapport.docx Side: 51 av 71
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.
Filnavn: Prosjektrapport.docx Side: 52 av 71
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
Filnavn: Prosjektrapport.docx Side: 53 av 71
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.
Filnavn: Prosjektrapport.docx Side: 54 av 71
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.
Filnavn: Prosjektrapport.docx Side: 55 av 71
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.
Filnavn: Prosjektrapport.docx Side: 56 av 71
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.
Filnavn: Prosjektrapport.docx Side: 57 av 71
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.
Filnavn: Prosjektrapport.docx Side: 58 av 71
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.
Filnavn: Prosjektrapport.docx Side: 59 av 71
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.
Filnavn: Prosjektrapport.docx Side: 60 av 71
/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.
Filnavn: Prosjektrapport.docx Side: 61 av 71
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
Filnavn: Prosjektrapport.docx Side: 62 av 71
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.
Filnavn: Prosjektrapport.docx Side: 63 av 71
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.
Filnavn: Prosjektrapport.docx Side: 64 av 71
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.
Filnavn: Prosjektrapport.docx Side: 65 av 71
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.
Filnavn: Prosjektrapport.docx Side: 66 av 71
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.
Filnavn: Prosjektrapport.docx Side: 67 av 71
Filnavn: Prosjektrapport.docx Side: 68 av 71
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.
Filnavn: Prosjektrapport.docx Side: 69 av 71
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.
Filnavn: Prosjektrapport.docx Side: 70 av 71
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)
Filnavn: Prosjektrapport.docx Side: 71 av 71
[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)
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
SpareBank 1 Gruppen AS
KMIT & Innkjøp
Hammersborggata 2
0191 Oslo
1.3 KONTAKTPERSON
SpareBank 1 Gruppen AS
Martin Jensen
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.
Filnavn: Kravspesifikasjon.docx Side: 3 av 7
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
Filnavn: Kravspesifikasjon.docx Side: 4 av 7
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
3.1.2.1 FUNKSJONELLE KRAV
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.
3.1.2.2 IKKE FUNKSJONELLE KRAV
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
3.1.3.1 FUNKSJONELLE KRAV
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
3.1.4.1 FUNKSJONELLE KRAV
Webservice skal gjøre kall mot databaselag 1 og databaselag 2.
Feilsituasjoner og statusinformasjon skal logges til fil
Filnavn: Kravspesifikasjon.docx Side: 5 av 7
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.
3.1.4.2 IKKE FUNKSJONELLE KRAV
Kall mot database skal ikke ta over to sekunder
3.1.5 KRAV TIL FRONTEND
3.1.5.1 FUNKSJONELLE KRAV
Støtte nye nettlesere, som siste versjon av Chrome, Firefox og Internet Exolorer.
Presentere data fra webservicen som grafer.
Benytte data fra webservice
3.1.5.2 IKKE FUNKSJONELLE KRAV
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
Filnavn: Kravspesifikasjon.docx Side: 6 av 7
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
4.1.1 FUNKSJONELLE KRAV
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.
4.1.2 IKKE FUNKSJONELLE KRAV
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 (_).
5.2.2 IKKE FUNKSJONELLE KRAV
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
Filnavn: Kravspesifikasjon.docx Side: 7 av 7
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
6.3.1 FUNKSJONELLE KRAV
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.
6.3.2 IKKE FUNKSJONELLE KRAV
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
Filnavn: Brukerdokumentasjon.docx Side: 3 av 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()»:
Filnavn: Brukerdokumentasjon.docx Side: 4 av 11
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
Filnavn: Brukerdokumentasjon.docx Side: 5 av 11
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()
Filnavn: Brukerdokumentasjon.docx Side: 6 av 11
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.
Filnavn: Brukerdokumentasjon.docx Side: 7 av 11
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
Filnavn: Brukerdokumentasjon.docx Side: 8 av 11
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
Filnavn: Brukerdokumentasjon.docx Side: 9 av 11
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
sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniff-
sensor/sensor/pysniff_sensord.py stop
Filnavn: Brukerdokumentasjon.docx Side: 10 av 11
sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniff-
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
Filnavn: Brukerdokumentasjon.docx Side: 11 av 11
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
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 3 av 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.
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 4 av 9
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)
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 5 av 9
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.
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 6 av 9
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 `id -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.
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 7 av 9
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
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 8 av 9
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”
Filnavn: Dokumentasjon av privat testmiljø.docx Side: 9 av 9
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
Filnavn: Dokumentasjon av Installasjon.docx Side: 3 av 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.
Filnavn: Dokumentasjon av Installasjon.docx Side: 4 av 10
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
Filnavn: Dokumentasjon av Installasjon.docx Side: 5 av 10
#!/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.
Filnavn: Dokumentasjon av Installasjon.docx Side: 6 av 10
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
installeres med følgende kommando:
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
Filnavn: Dokumentasjon av Installasjon.docx Side: 7 av 10
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
Filnavn: Dokumentasjon av Installasjon.docx Side: 8 av 10
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
pip install https://pypi.python.org/pypi/SQLAlchemy/0.8.1
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
installeres med følgende kommando:
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
Filnavn: Dokumentasjon av Installasjon.docx Side: 9 av 10
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
pip install https://pypi.python.org/pypi/SQLAlchemy/0.8.1
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
installeres med følgende kommando:
sudo apt-get install libpq-dev python-dev
Deretter kan psycopg2 installeres: pip install https://pypi.python.org/pypi/psycopg2/2.5
Filnavn: Dokumentasjon av Installasjon.docx Side: 10 av 10
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.
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
Rapport prodsetting M1 2013-03-09.docx Side: 3 av 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
Rapport prodsetting M1 2013-03-09.docx Side: 4 av 4
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
Produksjonssettings-
rapport milepæl 1
Dokumentet inneholder beskrivelse av andre del av produksjonssetting av milepel 1 den 16.03.2013.
Rapport prodsetting M1 2013-03-16.docx Side: 2 av 5
INNHOLDSFORTEGNELSE
INNHOLDSFORTEGNELSE 2
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
Rapport prodsetting M1 2013-03-16.docx Side: 3 av 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.
Rapport prodsetting M1 2013-03-16.docx Side: 4 av 5
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.
Rapport prodsetting M1 2013-03-16.docx Side: 5 av 5
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
Produksjonssettings-
rapport milepæl 2
Dokumentet inneholder beskrivelse produksjonssetting av milepel 2 den 07.04.2013.
Rapport prodsetting M2 2013-04-07.docx Side: 2 av 6
INNHOLDSFORTEGNELSE
INNHOLDSFORTEGNELSE 2
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
Rapport prodsetting M2 2013-04-07.docx Side: 3 av 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 å
Rapport prodsetting M2 2013-04-07.docx Side: 4 av 6
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.
Rapport prodsetting M2 2013-04-07.docx Side: 5 av 6
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.
Rapport prodsetting M2 2013-04-07.docx Side: 6 av 6
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
Filnavn: Dokumentasjon av Git.docx Side: 3 av 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
Filnavn: Dokumentasjon av Git.docx Side: 4 av 7
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.
Filnavn: Dokumentasjon av Git.docx Side: 5 av 7
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
Filnavn: Dokumentasjon av Git.docx Side: 6 av 7
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.
Filnavn: Dokumentasjon av Git.docx Side: 7 av 7
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