Vedlegg E2 Produksjonssettingsrapport milepæl 1 Dokumentet inneholder beskrivelse av andre del av produksjonssetting av milepel 1 den 16.03.2013.
INNHOLDSFORTEGNELSE INNHOLDSFORTEGNELSE 2 1. INNLEDNING 3 2. OPPSUMMERING 3 3. PRODSETTINGEN 3 3.1 INSTALASJONSSTATUS 4 4. ÅRSAK TIL AVVIK 4 4.1 DIREKTE KONTAKT TIL FRONTEND PÅ PORT 80 4 4.2 MANGLENDE SQLITE PAKKER TIL FRONTEND 4 4.3 MANGLENDE TILKOBLING TIL DATABASE PÅ ORIGO5 4 4.4 FEILKONFIGURASJON AV MOD_WSGI 5 Rapport prodsetting M1 2013-03-16.docx Side: 2 av 5
1. INNLEDNING Denne rapporten beskriver produksjonssettingen i SpareBank1 sitt testmiljø. Rapporten beskriver også eventuelle avvik og tiltak for å ungå disse problemene. Denne produksjonsettingen er i SpareBank 1 sitt testmiljø. Serverene programvaren skal kjøre på har installert CentOS som følger SpareBank 1 sin standard for test. 2. OPPSUMMERING Etter feilet produksjonsetting 9/3 ble det gjennomført ny produksjonsetting helgen 16/3 17/3. Hele applikasjonen skulle installeres på testservere i SpareBank 1 sitt testmiljø. Installasjonen gikk ok og alle de planlagte delene ble produksjonsatt. 3. PRODSETTINGEN Etter feilet produksjonsetting 9/3 ble det besluttet å utføre feilretting og ny produksjonsetting helgen 16/3 17/3. Grunnlaget for dette var innhenting av mer informasjon og tilegning av kunnskap rundt oppsett og rutiner ved bruk av testmiljøet til SpareBank 1. Ved første forsøk på produksjonsetting var det generelle grunnlaget for installasjon basert på tilkobling til internet. Dermed måtte dette løses for å gjøre det mulig å installere applikasjonen. Installasjon av standardpakker feilet også, og dette vil være løst i denne leveransen. For å installere applikasjonen ble det først igangsatt instalasjon av Python. For installasjon av Python er det laget et script for å automatisere installasjonen, med navnet «python273_install.sh». Dette scriptet installerer Python 2.7.3 på CentOS versjon 5.x. Scriptet er avhengig av pakker fra det lokale pakke-repositoriet og vil installere nødvendige utviklingspakker nødvendig for kompilering av Python. Selve applikasjonene krever at Python er installert med riktige komponenter for at alle delene av applikasjonen skal fungere optimalt. Ettersom det ikke er mulighet for å koble til internett i dette miljøet, ble all nødvendig programvare lastet ned til en annen maskin, som står i et sikret nettverk før de ble videresendt til applikasjonserverene. Det som ble lastet ned var all kode som ligger i git repositoriet, samt tilleggspakker til python fra nettsiden pypi.python.org. Databasen ble først satt opp på maskin origo5. Etter at dette var gjort ble det forsøkt å koble mot denne databasen fra origo4, men dette var ikke mulig på grunn av brannmurinstillinger. Derfor ble databasen også satt opp til å midlertidig stå på origo4. Det ble i etterkant ordnet med databaseåpning slik at det er mulig å koble til databasen på origo5 fra origo4. Da det var gjort en endring i utviklingen som gjorde at det ble byttet databasemotor fra SQLite til PostgrSQL ble det samtidig gjort en endring i installasjonscriptet til Python for å fjerne de overflødige pakkene. Dette viste seg derimot å være et problem da frontend benytter seg av SQLite til lokal database. Dette gjorde at python måtte rekompileres med denne pakken, men dette var ikke noe stort problem. Deretter måtte mod_wsgi installeres, som er en modul til apache webserveren som gjør det mulig å kjøre python programmer som websider. Dette gikk ok, men det var mangler i konfigurasjonen som førte til at bruken av apache i denne versjonen ikke ble godtatt. Derfor ble frontend kjørt av den midlertidige webserveren. For å etterfølge oppdragsgivers standarder ble applikasjonene flyttet til filstien /opt/pysniff/. Underliggende for denne mappen er de induviduelle delene installert. Etter at applikasjonene var flyttet til sine respektive mapper ble applikasjonen startet. Alt fungerte her ok, ref installasjonstatus. Det ble i etterkant oppdaget at det kjørte en feil versjon av databasen. Dette gjorde at det var manglende data. Det ser i etterkant ut til at dette har vært manglende opplastning til git som gjorde at dette scriptet var i en gammel versjon. Dette ble rettet opp, ramdatabasen ble unmountet for å kunne sette den opp på nytt, og ny installasjon av tabellene ble gjennomført ok. Rapport prodsetting M1 2013-03-16.docx Side: 3 av 5
3.1 Instalasjonsstatus Delapplikasjon Python Database (PostgreSQL) Frontend Webservice Core Sensor Status Ikke installert (ikke ferdig i denne versjonen) 4. ÅRSAK TIL AVVIK Det var enkelte avvik ved installasjonen som må endres til neste produksjonsetting. Noen av disse manglene ble også rettet under produksjonsetting, men var ikke forutsett på forhånd. Direkte kontakt til serveren på port 80 Manglende SQLite pakker til frontend Manglende tilkobling til origo5 for database Feilkonfigurasjon av mod_wsgi 4.1 Direkte kontakt til frontend på port 80 Ettersom serveren som applikasjonen kjører på står i et sikkert nett er det ofte behov for brannmuråpninger for å gjennomføre tilkoblinger til serverene. Dette gjelder spesielt fra det vanlige nettet og mot serveren. I dette tilfellet var det ikke mulig å koble på serveren med vanlig http (port 80), noe som i dette tilfellet gjorde at vi var nødt til å benytte ssh-tunnelering mot serveren for å kunne emulere trafikk til port 80. Vi fikk da verifisert at tjenestene fungerer som de skal, men manglende mulighet for å koble direkte til. Dette ble rettet etter samtale med driftsavdelingen, da det måtte konfigureres en firewall fil som inneholdt hvilke porter som skulle åpnses i iptables. 4.2 Manglende SQLite pakker til frontend Da frontend benytter en lokal database, som er vesentlig for oppstarten av selve frontend var det ikke mulig å starte selve applikasjonen etter installasjon. Ved å se på logger kommer det tydelig frem at dette er grunnet manglende installasjon av SQLite. Rettere sagt er det en patch av SQLite som må kompileres sammen med installasjonen av Python for å gjøre det mulig for python applikasjoner å benytte seg av SQLite databaser. Dette ble rettet ved å endre installasjonscriptet for python, og det foretatt en rekompilering. Dette ble rettet i løpet av kort tid og installasjonen av applikasjonen var vellykket. 4.3 Manglende tilkobling til database på origo5 Dette problemet er relatert til tilkoblingsproblemer på port 80. PostgrSQL kjører på port 5432 som standard, men etter installasjon og kjøring av databasen på origo5 var det ikke mulig å koble til denne. En måte å løse dette på er å kjøre tunell via serverene, noe som ble gjort mot origo4 for å kunne koble til webserveren på port 80. Dette er derimot ikke ønskelig når det gjelder database og servere innenfor samme miljø. For å løse dette problemet midlertidig ble databasen installert på origo4 slik at alle applikasjonene etter denne leveransen ville kjøre på samme server. På dette distribusjonsnivået av installerte sensorer er det ingen praktiske problemer ved å ha disse applikasjonene på samme server. Dette ble løst i neste leveranse med å legge til firewall.conf fil for port 5432 på origo5. Rapport prodsetting M1 2013-03-16.docx Side: 4 av 5
4.4 Feilkonfigurasjon av mod_wsgi For at mod_wsgi skal kunne benyttes er det nødvendig å ha flere konfigurasjonsfiler i orden for å kunne starte apache (httpd) som server for frontend. Det ble skrevet en virtualhost configurasjon for apache, som peker videre på standard wsgi config i frontend prosjektet. Dette fungerte derimot ikke optimalt, og ettersom det ikke var noen god løsning på å fikse dette uten å endre all konfigurasjonen ble det besluttet å avvente kjøring av frontend med mod_wsgi. Dette ikke minst for å sørge for at applikasjonen først kjører optimalt med apache, men også for ikke å endre på konfig som ikke bør endres. Det ble derfor gjennomført flere tester på development miljøet som igjen kunne produksjonsettes i testmiljøet til oppdragsgiver ved neste leveranse. Rapport prodsetting M1 2013-03-16.docx Side: 5 av 5