PySniff: Et system for nettverksbasert applikasjonsovervåking

Transkript

1 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: :57:00 Sider: 71

2 Filnavn: Prosjektrapport.docx Side: 2 av 71

3 PROSJEKT NR. Gruppe 4 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL DATO 28. mai 2013 Nettverksbasert applikasjonsoveråking 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 Passordet for kildekode er: hioa STIKKORD Overvåking Applikasjonsutvikling Nettverk Filnavn: Prosjektrapport.docx Side: 3 av 71

4 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: 4 av 71

5 1. INNHOLD 1. INNHOLD 5 2. INTRODUKSJON OM BEDRIFTEN BAKGRUNN FOR PROSJEKTET PROSJEKTETS MÅL BEDRIFTENS MÅL GRUPPENS MÅL 8 3. DESIGN AV PYSNIFF HVA ER PYSNIFF LAGDELING AV PYSNIFF 9 4. APPLIKASJONSMILJØER INTRODUKSJON AV APPLIKASJONSMILJØER OPPSETT AV TESTMILJØET BRUKSOMRÅDE ANSVAR OG SIKKERHET HARDWARE DELAPPLIKASJONENE SENSOR INTRODUKSJON TIL SENSOR KRAV TIL SENSOR APPLIKASJONSDESIGN IMPLEMENTASJON AV SENSOR DATABASE KRAV TIL DATABASE APPLIKASJONSDESIGN OPPSETT AV DATABASEN CORE INTRODUKSJON TIL CORE KRAV TIL CORE APPLIKASJONSDESIGN IMPLEMENTASJON WEBSERVICE INTRODUKSJON TIL WEBSERVICE KRAV TIL WEBSERVICE APPLIKASJONSDESIGN UFORDRINGER KONFIGURASJON FRONTEND INTRODUKSJON AV FRONTEND KRAV TIL FRONTEND APPLIKASJONSDESIGN UTVIKLING AV FRONTEND UTFORDRINGER KONFIGURASJON LOGGING AV FRONTEND PRODUKTET 60 Filnavn: Prosjektrapport.docx Side: 5 av 71

6 6. KONKLUSJON MÅLOPPNÅELSE BEDRIFTENS MÅL LÆRINGSMÅL UTVIDELSESMULIGHETER KONKLUSJON AV PRODUKTET PROSESSRAPPORT KRAV TIL PROSJEKTET PLANLEGGING OG METODE UTVIKLINGSMODELL FREMDRIFT OG ARBEIDSPLAN VERKTØY SAMMARBEID VEILEDNING REFERANSER VEDLEGG DATAORDBOK REFERANSER 70 Filnavn: Prosjektrapport.docx Side: 6 av 71

7 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 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: 7 av 71

8 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 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: 8 av 71

9 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: 9 av 71

10 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: 10 av 71

11 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: 11 av 71

12 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ådgivningsog 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: 12 av 71

13 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». Uten VirtIO/ Paravirtualization Med VirtIO / Paravirtualization Kompilering av Python 6-7 Timer 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 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: 13 av 71

14 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: 14 av 71

15 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: 15 av 71

16 Figur 7: Virtuell Machine Manger terminaler Filnavn: Prosjektrapport.docx Side: 16 av 71

17 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 itsystemer, 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: 17 av 71

18 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: 18 av 71

19 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: 19 av 71

20 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 OSImodellen. 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 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: 20 av 71

21 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 APPLIKASJONSDESIGN 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 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 prosessor. Dette er en svak server i forhold til hva som blir brukt hos oppdragsgiver 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: 21 av 71

22 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: 22 av 71

23 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 OK Installasjon gikk uten problemer 5.8 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: 23 av 71

24 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 = 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: 24 av 71

25 :28:23,289 dev INFO PySniff Sensor started :28:23,289 dev INFO Sensor have hostname: Stress :28:38,797 dev INFO Sniff_packets done :28:47,809 dev INFO Sniff_packets done :28:56,009 dev INFO Sniff_packets done :29:03,310 dev INFO Sniff_packets done :08:50,312 dev INFO PySniff Sensor stopped :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: \r\n', u'location': None, u'date': ' :13:55', u'useragent': 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ 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: 25 av 71

26 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: 26 av 71

27 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: 27 av 71

28 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 APPLIKASJONSDESIGN 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: 28 av 71

29 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 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 Trafikk 1 Link 2 Link 3 Link 4 Link Figur 22: Trafikk fordelt på antall linker 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. Filnavn: Prosjektrapport.docx Side: 29 av 71

30 Figur 23: Dataflyt i og imellom databaselaget 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 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: 30 av 71

31 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:password4@ :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: 31 av 71

32 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: 32 av 71

33 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 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 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 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: 33 av 71

34 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 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 Pythonmodul 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: 34 av 71

35 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 Linuxsystemer. 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 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: 35 av 71

36 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 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: 36 av 71

37 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 frequency ; 24 hour format = 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: 37 av 71

38 # 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 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 :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 Loggnivået, beskriver hva logglinjen inneholder og brukes for å DEBUG skille på viktighetsgraden i logglinjen. ERROR Tabell 4: Representasjon av innholdet i en logglinje. Logglinjene presentert under er et eksempel på normal oppførsel av Core :25:50,592 dev INFO PySniff Core started :00:00,093 dev INFO Aggregate process starting :00:00,093 dev INFO Aggregate process complete :00:00,094 dev DEBUG Checking if old data in layer1 should be deleted :00:00,094 dev INFO Cleaning up old data in layer1 starting :00:01,265 dev INFO Cleaning up old data in layer1 complete :00:00,068 dev INFO Aggregate process starting :00:00,068 dev INFO Aggregate process complete :00:00,069 dev DEBUG Checking if old data in layer1 should be deleted :00:00,069 dev DEBUG Not cleaning time. Continuing. Figur 31 Et sett med normale logglinjer for Core. Filnavn: Prosjektrapport.docx Side: 38 av 71

39 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 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: 39 av 71

40 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: 40 av 71

41 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 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 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: 41 av 71

42 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: 42 av 71

43 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 :8080/plugin/http/hostname_count/5/ T15:11:00/0 Figur 39:Viser et kall fra Frontend til Webservice Del av webadresse Beskrivelse :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 / T15: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 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) \ session.close() result = [{.label('count')).filter(http.date>=start, HTTP.date<=end) \.group_by(http.host).order_by(desc('count')).limit(limit) '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: 43 av 71

44 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, T15:11:00,0) VALG AV RAMMEVERK RAMMEVERK furl 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[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: 44 av 71

45 cornice 0.12 cornice 14 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 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 UFORDRINGER 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 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 KONFIGURASJON INSTALLASJON For å kunne kjøre webservice, kreves det at Python 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 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: 45 av 71

46 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: 46 av 71

47 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 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 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: 47 av 71

48 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 NVD3 og D3.js Requests 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. 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. 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 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: 48 av 71

49 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 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: 49 av 71

50 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 « 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-Zaz] 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 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: 50 av 71

51 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å 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 « på frontend siden vil adressen « 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: 51 av 71

52 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 + " function="+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 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: 52 av 71

53 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 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> </body> <script src="{{static_url}}bootstrap/js/bootstrap.min.js"></script> </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 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: 53 av 71

54 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: 54 av 71

55 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 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: 55 av 71

56 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: 56 av 71

57 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 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( :22 );». Dette viste seg derimot ikke å fungere i alle nettlesere, og det måtte produseres en egen metode for å rette på dette 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: 57 av 71

58 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: 58 av 71

59 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 = " 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 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: 59 av 71

60 /var/log/pysniff/frontend/httpd/frontend-access.log [19/Apr/2013:10:43: ] "GET /api/plugin/http/hostname_count/15 HTTP/1.1" " "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" [22/Apr/2013:12:28: ] "GET / HTTP/1.1" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ 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 :57:12 INFO [main:75] Getting data from webservice :57:12 INFO [main:111] Webservice connection plugin=http function=statusline_date params=500 response= :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 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: 60 av 71

61 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 1xx (100, 101, 102) 2xx 3xx 4xx 5xx Betydning Informasjon om at forespørsel er motatt og at data skal sendes Vellykket forespørsel. 200 er OK og er den vanligste koden Videresending. Kan bety at dataene er flyttet og ikke eksisterer, og kan gjøre at data ikke blir returnert. 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. 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: 61 av 71

62 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: 62 av 71

63 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: 63 av 71

64 6.1 MÅLOPPNÅELSE 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 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: 64 av 71

65 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: 65 av 71

66 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 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 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: 66 av 71

67 Filnavn: Prosjektrapport.docx Side: 67 av 71

68 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: 68 av 71

69 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: 69 av 71

70 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 HTTP HTTPS Sniffe Parse Bugs TCP Host ORM Caching Raspberry Pi Aggregering Baselining Grensesnitt URL groupby, having, extract, count Plugin Terminal Daemon Forklaring Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Se på / speile nettverks trafikk. Er å analysere, lese, sette sammen en rekke med symboler. Logiske feil Transmission Control Protocol/Internet Protocol En datamaskin / server Object Role Modeling(method for designing and querying database models) Mellomlagring av data Liten datamaskin Å kombinere eller slå sammen data for en representasjon av data i gruppering og/eller over tid. Å 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, eller interface, er en abstraksjon for kommunikasjon mellom to systemer eller konsepter Uniform resource locator, webadresse SQL-funksjoner En plugin, eller programvareutvidelse, er en tilleggsmodul som tilbyr ekstrafunksjonalitet til et program. Ofte synonymt brukt med en kommandolinje, en terminal er et program som kommuniserer med et operativsystem i form av tekst. En bakgrunnsprosess, i stedet for å kontrolleres direkte av en interaktiv bruker. 8.3 REFERANSER [1] Artikkel om OSI: (sist lastet ned 26/5) [2] Nettsiden til progammet scapy: (sist lastet ned 26/5) [3] Nettsiden til SQLAlchemy (sist lastet ned 26/5) [4] Utregining av kapasitet på nettverk: (sist lastet ned 26/5) Filnavn: Prosjektrapport.docx Side: 70 av 71

71 [5] Correct deamon behavior (sist lastet ned 26/5) [6] PEP-3143: (sist lastet ned 26/5) [7] ISO 8601 datoformat: (Lastet ned 20/5-2013). (sist lastet ned 26/5) [8] Nettsiden til rammeverket flask: (sist lastet ned 26/5) [9] Nettsiden til rammeverket cherrypy: (sist lastet ned 26/5) [10] Hvilke webrammeverker for bruk i webservice. (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: (sist lastet ned 26/5) [13] Twisted: (sist lastet ned 26/5) [14] Cornice: (sist lastet ned 26/5) [15] Tim Berners-Lee om formen på en URI (sist lastet ned 26/5) [16] The Django Book om regulære utrykk og url config (sist lastet ned 26/5) [17] Hvordan strukturere store django applikasjoner: (sist lastet ned 26/5) [18] «Django Project Structure» (sist lastet ned 26/5) [19] Stackoverflow artikkel om hvordan man bør strukturere Django. (sist lastet ned 26/5) Filnavn: Prosjektrapport.docx Side: 71 av 71

72 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.

73 1. PRESENTASJON PROSJEKTTITTEL Nettverksbasert applikasjonsovervåking APPLIKASJONSTITTEL OPPGAVE PySniff 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 Oslo origo@sparebank1.no 1.3 KONTAKTPERSON SpareBank 1 Gruppen AS Martin Jensen Martin.Jensen@sparebank1.no 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 ITtjenestene 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: 2 av 7

74 Innholdsfortegnelse 1. PRESENTASJON MEDLEMMER I PROSJEKTET OPPDRAGSGIVER KONTAKTPERSON VEILEDER BAKGRUNN 2 2. FORORD 2 3. SYSTEMKRAV FUNKSJONSKRAV KRAV TIL SENSOR KRAV TIL DATABASE KRAV TIL CORE KRAV TIL WEBSERVICE KRAV TIL FRONTEND TEKNISKE KRAV KRAV TIL DATALAGRING FUNKSJONELLE KRAV IKKE FUNKSJONELLE KRAV 6 4. KRAV TIL DESIGN FUNKSJONELLE KRAV IKKE FUNKSJONELLE KRAV 6 5. KRAV TIL KODE KODESTANDARD VARIABLER OG FUNKSJONER FUNKSJONELT IKKE FUNKSJONELLE KRAV KOMMENTERING SPRÅK 6 6. KRAV TIL DOKUMENTASJON OBLIGATORISK DOKUMENTASJON STYRINGSDOKUMENTER SLUTTDOKUMENTASJON GENERELLE KRAV TIL DOKUMENTASJON VERSJONSKONTROLL FUNKSJONELLE KRAV IKKE FUNKSJONELLE KRAV 7 7. UTVIDELSER 7 8. FREMMEDORD OG DEFINISJONER 7 3. SYSTEMKRAV 3.1 FUNKSJONSKRAV Filnavn: Kravspesifikasjon.docx Side: 3 av 7

75 3.1.1 KRAV TIL SENSOR 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 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 KRAV TIL DATABASE 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 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 KRAV TIL CORE 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 KRAV TIL WEBSERVICE FUNKSJONELLE KRAV Webservice skal gjøre kall mot databaselag 1 og databaselag 2. Feilsituasjoner og statusinformasjon skal logges til fil Filnavn: Kravspesifikasjon.docx Side: 4 av 7

76 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 IKKE FUNKSJONELLE KRAV Kall mot database skal ikke ta over to sekunder KRAV TIL FRONTEND 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 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 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 KRAV TIL DATALAGRING FUNKSJONELLE KRAV Gruppen skal bruke Dropbox, Google Docs og Git Alle på prosjektgruppen skal ha tilgang til overnevnte lagringsplasser Filnavn: Kravspesifikasjon.docx Side: 5 av 7

77 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 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 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 FUNKSJONELT Flere ord i variabelnavn skal settes sammen med bruk av underlinje (_). Flere ord i funksjoner skal settes sammen med bruk av underlinje (_) IKKE FUNKSJONELLE KRAV Variabelnavn skal være logisk i sammenhengen. 5.3 KOMMENTERING 5.4 SPRÅK Funksjoner skal alltid kommenteres med beskrivende tittel og returverdi. Variabler trenger ikke å kommenteres. Klasser skal kommenteres med hva de skal brukes. 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: 6 av 7

78 Følgende obligatoriske dokumenter skal utformes i løpet av prosjektets periode: STYRINGSDOKUMENTER Prosjektskisse Forprosjektrapport Arbeids- og fremdriftsplan Kravspesifikasjon 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 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 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 Trending Sensor - Kombinere eller slå sammen data. F.eks minke data over lengre tidsperioder. - Det normalet i en gitt tidsperiode. - En applikasjon som leser av nettverkstrafikk eller eksempelvis tekstfiler. Filnavn: Kravspesifikasjon.docx Side: 7 av 7

79 Vedlegg B Brukermanual

80 Innholdsfortegnelse 1. INTRODUKSJON 3 2. UTVIKLING PLUGINBIBLIOTEKET SENSOR DATABASE CORE WEBSERVICE FRONTEND INNHENTING AV DATA FRA WEBSERVICE GRAFER 7 3. BRUK PLUGINBIBLIOTEK LOAD_SESSION GET_STATUSCODES IP_SEARCH SOURCEPORT DESTPORT STATUSLINE_COUNT STATUSLINE_ALL STATUSLINE_DATE HOSTNAME_COUNT USERAGENT_COUNT SENSOR DATABASE CORE WEBSERVICE 11 Filnavn: Brukerdokumentasjon.docx Side: 2 av 11

81 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: except: metadata = Base.metadata Session = sessionmaker(bind=engine) session = Session() logger.info('db session loaded') return session 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: 3 av 11

82 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 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 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: 2.2 Sensor session = self.load_session() query = session.query(http.host, func.count(http.host) \ session.close() result = [{.label('count')).filter(http.date>=start, HTTP.date<=end) \.group_by(http.host).order_by(desc('count')).limit(limit) 'hostname':res.host, 'count':res.count }for res in query] return result except Exception, err: logger.error(err) return [] 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: 4 av 11

83 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:password@ :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: 5 av 11

84 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 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: 6 av 11

85 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(); 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 load_session Filnavn: Brukerdokumentasjon.docx Side: 7 av 11

86 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 get_statuscodes def get_statuscodes(self): Beskrivelse: Funksjonen returnerer alle de forskjellige HTTP-feilkodene som finnes i databasen. Returverdi: JSON-streng med HTTP-feilkoder 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 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 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 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 statusline_all def statusline_all(self, status): Beskrivelse: Funksjonen returner alle datoer/tidspunkter til en gitt statuskode Filnavn: Brukerdokumentasjon.docx Side: 8 av 11

87 Parametere: status: Hvilken statuskode som skal søkes etter, f.eks. 200 Returverdi: JSON-streng med dato/tidspunkt og statusline 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: t19:00:00 end: tidspunkt den skal søke til format: t19:00:00 grouping: hva den skal gruppere på gyldige verdier: second, minute, hour, day, month Returverdi: JSON-streng med dato/tidspunkt og antall 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: t19:00:00 end: tidspunkt den skal søke til format: t19:00:00 Returverdi: JSON-streng med hostname og antall 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: t19:00:00 end: tidspunkt den skal søke til format: t19:00:00 Returverdi: JSON-streng med user-agent og antall 3.2 Sensor sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniffsensor/sensor/pysniff_sensord.py start sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniffsensor/sensor/pysniff_sensord.py stop Filnavn: Brukerdokumentasjon.docx Side: 9 av 11

88 sudo /opt/pysniff-sensor/py_env/bin/python /opt/pysniffsensor/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 /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: 10 av 11

89 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 stdout_path stderr_path pidfile_path pidfile_timeout = 5 = /dev/null = /dev/tty = /dev/tty = /var/run/pysniff/core.pid 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: :8080/plugin/http/hostname_count/5/0/0 En fullstendig oversikt over funksjoner i HTTP-pluginen finnes i kapittel 3.1 i dette dokumentet. Filnavn: Brukerdokumentasjon.docx Side: 11 av 11

90 Vedlegg C Dokumentasjon av privat testmiljø

91 Innholdsfortegnelse 1. DOKUMENTASJON INNLEDNING ANSVAR TEKNISK OVERSIKTSBILDE SPESIFIKASJONER AV HARDWARE SPESIFIKASJONER AV NETTVERK SPESIFIKASJONER AV SIKKERHET BRUKERMANUAL FOR OPPSETT AV TESTMILJØET KVM (KERNEL BASED VIRITUAL MACHINE) INSTALLASJON AV CENTOS KONFIGURASJON AV CENTOS 9 Filnavn: Dokumentasjon av privat testmiljø.docx Side: 2 av 9

92 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ø 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 Oversiktsbilde Figur 1 - Virtuelt servermiljø Spesifikasjoner av hardware 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: 3 av 9

93 Figur 2 HP ProLiant DL380 G 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 Sensor1 Public IP: Intern IP: RAM: 256mb Disk: Sensor2 Public IP: (eth1) Intern IP: (eth0) RAM: 256mb Disk: Software: ingen utenom felles. Core Public IP: (eth1) Intern IP: (eth0) RAM: 4256mb Disk: Software: git, PostgreSQL, SQLite3, SQLAlchemy, Django, tmux 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: 4 av 9

94 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 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 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 Filnavn: Dokumentasjon av privat testmiljø.docx Side: 5 av 9

95 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 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 Konfigurasjon virt-install --connect qemu:///system -n Core -r 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 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: 6 av 9

96 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 network netmask broadcast gateway bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 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: 7 av 9

97 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: 8 av 9

98 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 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= IPADRESS= PEERNTP=no Når dette er på plass er CentOS klart til å brukes. Filnavn: Dokumentasjon av privat testmiljø.docx Side: 9 av 9

99 Vedlegg D Dokumentasjon av Installasjon Dette dokumentet tar for seg detaljert informasjon vedrørende installasjon nødvendig for delapplikasjonene i PySniff.

100 Innholdsfortegnelse 1. INTRODUKSJON 3 2. PYTHON INSTALLERING AV VIRTUALENV I PYSNIFF 4 3. SENSOR LINUX AVHENGIGHETER PYTHON-PAKKER PSYCOPG SCAPY SQLALCHEMY PYTHON-DAEMON 6 4. DATABASE INSTALLASJON AV CENTOS PAKKER INSTALLASJON AV LAYER1 OG LAYER LAYER CORE PYTHON-PAKKER SQLALCHEMY PSYCOPG PYTHON-DAEMON 8 6. WEBSERVICE PYTHON-PAKKER CHERRYPY SQLALCHEMY PSYCOPG FRONTEND 10 Filnavn: Dokumentasjon av Installasjon.docx Side: 2 av 10

101 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 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: 3 av 10

102 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 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 tar.bz2 Kildekoden til Python sqlite3_int64_v2.patch fra distribute tar.gz Python-modulen Distribute, nødvendig for Pip og Virtualenv pip tar.gz Pakkebehandler for Python virtualenv tar.gz Kildekode for Virtualenv-modul i Python 2.1 Installering av Virtualenv i PySniff Tekniske installasjonskommandoer for distribute wget 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: 4 av 10

103 #!/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 tar.bz2 cd Python # Patch for _sqlite module - 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 - echo "/usr/local/lib" >> /etc/ld.so.conf /sbin/ldconfig # Install distribute - cd /tmp/python273 tar -xzvf distribute tar.gz /usr/local/bin/python2.7 distribute /setup.py install # Install pip, because easy_install is deprecated # /usr/local/bin/easy_install-2.7 pip tar.gz # Install virtualenv and other interesting packages # will be added to /usr/local/bin/ /usr/local/bin/pip install virtualenv tar.gz # Clean up rm -rf /tmp/python273 # Done! echo "Installation of Python Done!" Figur 1: Installasjonsscript for Python på CentOS 5. Filnavn: Dokumentasjon av Installasjon.docx Side: 5 av 10

104 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 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: CentOS: sudo apt-get install postgresql-dev 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: psycopg2 Pakken gjør støtte kobling mot PostgrSQL-database. Sensoren er testet med versjon Manuell kommando for å innstalere denne pakken er: pip install Windows avhengighet I Windows må man installere Psycopg med følgende kommando: pip install 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 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 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 Filnavn: Dokumentasjon av Installasjon.docx Side: 6 av 10

105 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 Layer 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: 7 av 10

106 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 SQLAlchemy Pakke for kobling mot database pip install 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 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 Filnavn: Dokumentasjon av Installasjon.docx Side: 8 av 10

107 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 CherryPy Pakke for rammeverk og webserver pip install tar.gz SQLAlchemy Pakke for kobling mot database pip install 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 Filnavn: Dokumentasjon av Installasjon.docx Side: 9 av 10

108 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 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. Filnavn: Dokumentasjon av Installasjon.docx Side: 10 av 10

109 Vedlegg E1 Produksjonssettingsrapport milepæl 1 Dokumentet inneholder beskrivelse av første del av produksjonssetting av milepel 1 den

110 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 M docx Side: 2 av 4

111 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 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 M docx Side: 3 av 4

112 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 Mirror Repository Git Python ITIL Test QA Prod Miljø Beskrivelse Lokalt bilde av et eksternt pakkerepository med installasjonsfiler Datastruktur hvor pakker eller kode er lagret. For eksempel kode lagret i et versjonskontrolleringssystem som git. Versjonskontrolleringsystem Programmeringsspråk «Information Technology Infrastructure Library». Et strukturert rammeverk for kvalitetssikring av IT tjenester. SpareBank 1 benytter en modifisert versjon av ITIL. Et miljø for testing av IT-tjenester og applikasjoner Et miljø for å kvalitetssikre IT-tjenester og applikasjoner. Produksjonsmiljøet hvor alle IT-tjenester og applikasjoner kjører. 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. Rapport prodsetting M docx Side: 4 av 4

113 Vedlegg E2 Produksjonssettingsrapport milepæl 1 Dokumentet inneholder beskrivelse av andre del av produksjonssetting av milepel 1 den

114 INNHOLDSFORTEGNELSE INNHOLDSFORTEGNELSE 2 1. INNLEDNING 3 2. OPPSUMMERING 3 3. PRODSETTINGEN INSTALASJONSSTATUS 4 4. ÅRSAK TIL AVVIK DIREKTE KONTAKT TIL FRONTEND PÅ PORT MANGLENDE SQLITE PAKKER TIL FRONTEND MANGLENDE TILKOBLING TIL DATABASE PÅ ORIGO FEILKONFIGURASJON AV MOD_WSGI 5 Rapport prodsetting M docx Side: 2 av 5

115 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 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 M docx Side: 3 av 5

116 3.1 Instalasjonsstatus Delapplikasjon Python Database (PostgreSQL) Frontend Webservice Core Sensor Status OK OK OK OK Ikke installert (ikke ferdig i denne versjonen) 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 M docx Side: 4 av 5

117 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. Rapport prodsetting M docx Side: 5 av 5

118 Vedlegg E3 Produksjonssettingsrapport milepæl 2 Dokumentet inneholder beskrivelse produksjonssetting av milepel 2 den

119 INNHOLDSFORTEGNELSE INNHOLDSFORTEGNELSE 2 1. INNLEDNING 3 2. OPPSUMMERING 3 3. PRODSETTINGEN BRANNMURÅPNINGER INSTALLASJON AV SENSOR UTRULLING AV NY DATABASEKONFIGURASJON INSTALLASJON AV FRONTEND, WEBSERVICE OG CORE INSTALASJONSSTATUS 6 Rapport prodsetting M docx Side: 2 av 6

120 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 M docx Side: 3 av 6

121 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 M docx Side: 4 av 6

122 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 M docx Side: 5 av 6

123 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 Python Database (PostgreSQL) Frontend Webservice Core Sensor Status OK OK OK OK OK OK Rapport prodsetting M docx Side: 6 av 6

124 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.

125 Innholdsfortegnelse 1. INTRODUKSJON HENSIKT HVA ER GIT OG VERSJONSKONTROLL GIT REPOSITORY GITHUB 4 2. DATAFLYTMODELL 5 3. STABILITET OG PÅLITELIGHET DATAORDBOK REFERANSER 7 Filnavn: Dokumentasjon av Git.docx Side: 2 av 7

126 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: 3 av 7

127 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 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: 4 av 7

128 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: 5 av 7

129 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: 6 av 7