Installations- og driftsvejledning til Stamdatamodulet KOMBIT

Installations- og driftsvejledning til Stamdatamodulet KOMBIT

1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Generelt... 4 3.1 Systemkrav... 4 3.2 Portering... 4 3.3 Skalering... 5 4 Konfiguration af database - MySQL... 5 5 Konfiguration af Applikationsserver - JBoss... 5 5.1 "Åbning" for trafik udefra... 6 5.2 Fjernelse af RestEasy... 6 5.3 Opsætning af applikation... 6 5.4 Yderligere opsætnings-muligheder... 7 6 Konfiguration af FTP-overførsel af cpr-data... 9 6.1 Kørsel af CPR-etablerings-udtræk fra CSC... 9 6.2 "Nulstilling af data"... 10 6.3 Daglig opdatering af CPR data fra CSC... 10 7 Konfiguration af Trafficmanager... 11 7.1 SSL decryption... 11 7.2 Validering af klient certifikat... 11 8 Konfiguration af Netværk... 11 8.1 Kundens adgangspunkter... 12 8.2 Arkitektur og infrastruktur... 13 8.3 Firewallregler... 13 9 Konfiguration af hardware... 15 9.1 Produktion... 15 9.2 Test/Udvikling... 15 10 Installationslog... 15 10.1 Installations log for prod01.kombit.netic.dk... 15 10.2 Installations log for stage01.kombit.netic.dk... 18 11 Backup... 19 11.1 Rollback/Gendannelse af backup... 19 12 Deployment & verifikation... 19 12.1 Deployment... 20 12.2 Verifikation... 20 13 Dataudtræk til klient... 20 14 Overvågning... 20 14.1 Service level... 20 14.2 Alarmering... 21 14.3 Tjenester... 21 14.4 isalive-overvågning... 22 14.5 Rejected... 22 14.6 Overdue... 22 14.7 Timeout... 23 14.8 Logfiler... 23 14.9 Andre overvågninger... 24

2 Historik Dato Version Ændring Ansvarlig 6. maj 2011 1.0 SEF, AHJ, OFO 19. maj 2011 1.1 Rettelser efter KOMBIT review AHJ, SEF 10. juni 2011 1.2 Rettelser efter 2. KOMBIT review SEF, OFO 20. juni 2011 1.3 CPR-opslagskomponent tilføjet FRJ, OFO

3 Generelt Installation af stamdatamodulet forudsætter erfaring/kompetence som normalt opfyldes af en database- hhv. systemadministrator. Derfor indeholder denne vejledning ikke alle specifikke instrukser. Specielle forhold er dog beskrevet. En release består af følgende: schema.sql importer.war (web-modul til CPR-import) replication.war (web-modul til replikering af CPR data samt GUI Administrator) lookup.war (web-modul til enkeltpersons-cpr-opslag) importer.default.properties replication.default.properties lookup.default.properties For at kunne installere løsningen kræves ovenstående filer, denne installationsvejledning samt evt. specielle konfigurationsfiler (hvis man ikke anvender default). Foldere på serveren er markeret med fed skrift fx input Default installation er i /pack/stamdata/input (konfigurerbar i propertyfil). Herunder (i samme filsystem) er der foldere for hver register der overføres data fra fx /pack/standata/input/cpr Indhold er denne folder er ikke konfigurerbar og indeholder tre foldere hhv. input, processing og rejected. Data placeres i input. Når løsningen begynder at behandle data flytter den filerne til processing. Ved fejl flytter den filerne til rejected. 3.1 Systemkrav OS: Solaris, Linux, Windows 64 bit der understøtter nedennævnte database og applikationsserverkrav. Database: MySQL 5.1.55+ 64 bit med InnoDB som backend-db. Applikationsserver: JBoss AS6 på Java, JRE 1.6_25+ 64 bit Løsningen er i Test og Produktion installeret på Sun Solaris 10 64-bit Der er ingen særlige installationsvalg for ovenstående som installeres ifgl. leverandørens standard installationsinstrukser. For konkret installation henvises til afsnittet der omhandler log for installation af basissoftware. 3.2 Portering

database benyttes MySQL. Løsningen benytter ikke MySQL-specifikke features, men databaseschemaet skal tilpasses hvis løsningen skal deployes på andre databaser. Applikationen deployes i JBoss, der er en J2EE-applikationsserver. Der anvendes dog ingen JBoss-specifik funktionalitet. Applikationen bør derfor kunne deployes i en hvilken som helst Servlet container der understøtter minimum version 2.4 af servlet specifikationen. Løsningen er afprøvet på JBoss, Trifork T4, Tomcat og Jetty. 3.3 Skalering Systemet baserer sig på infrastruktur, som i udgangspunktet er skalerbar. Database, Importeren, Replikeringstjenensten og CPR-opslagskomponenten behøver ikke køre på samme maskine. Importeren, Replikeringstjenesten og CPR-opslagskomponenten kan konfigureres til at anvende en ikke-lokal database. Det er muligt at koble flere replikeringstjenester eller CPR-opslagskomponenter til den samme database, og på denne måde skalere modulerne horisontalt. Modulerne er stateless. MySQL understøtter master-slave replikering, som kan anvendes hvis man ønsker at skalere databasen horisontalt. Systemets arkitektur understøtter dette på en hensigtsmæssig måde, da replikeringstjenesten og CPR-opslagskomponenten kun læser data, og dermed kan nøjes med readonly adgang til en MySQL slave. Kun administrations-gui en kræver skrive-adgang til databasen og skal derfor være koblet på masteren. Der henvises til MySQL dokumentationen for hvordan masterslave replikering sættes op. Importeren er ikke umiddelbart horisontalt skalerbar. 4 Konfiguration af database - MySQL Der skal oprettes en database i MySQL med navnet "sdm_warehouse". Desuden skal der oprettes en specifik bruger med adgang til netop denne database (skal kunne udføre select, insert, update og delete). Der anvendes ingens stored procedures. Konkret opsætning af databasens tabeller, index mv. findes i "schema.sql", som leveres med releasen. se evt. dokumentation for MySQL http://dev.mysql.com/doc/refman/5.1/en/adding-users.html Databasen oprettes herefter med de nødvendige tabeller på følgende måde:% mysqladmin create sdm_warehouse % mysql -u USERNAME sdm_warehouse < schema.sql

5.1 "Åbning" for trafik udefra JBoss skal startes op med "-b 0.0.0.0", ellers kan den ikke tilgås udefra. 5.2 Fjernelse af RestEasy Opslagskomponenten benytter Jersey-frameworket som ikke fungerer sammen med RestEasy. Sidstnævnte kommer med JBoss, og skal derfor fjernes. Fjern derfor mappen (JBoss home)/server/default/deployers/resteasy.deployer 5.3 Opsætning af applikation 5.3.1 Importer Opret (JBoss home)/server/default/conf/stamdata-importer.properties, definér følgende properties: db.user=(database-brugernavn) db.pwd=(database-password) spooler=cpr jobspooler= spooler.cpr.halt.on.date.errors=true #cpr are overdue after 12 days by default spooler.cpr.overduehours=26 spooler.cpr.file.pattern.person=hernin\\.d.{6}.l44930[12] spooler.cpr.file.pattern.person.delta=hernin\\.d.{6}l449302 (jf. Aftale med CPR-kontoret starter filnavne med HERNIN idet der er tale om data for borgere I Herning commune.) 5.3.2 Replikeringstjenesten Opret (JBoss home)/server/default/conf/stamdata-replication.properties, definér følgende properties: db.connection.username=(database-brugernavn) db.connection.password=(database-password) security=twowayssl security.ssl.test=false gui.security=twowayssl security.ssl.termination.method=zeusloadbalancer security.ssl.test skal sættes til true hvis der skal bruges OCES-testcertifikater. I udviklingsmiljøet sættes den

5.3.3 Opslagskomponenten Opret (JBoss home)/server/default/conf/stamdata-lookup.properties, definér følgende properties: db.connection.username=(database-brugernavn) db.connection.password=(database-password) security.ssl.test=false security.ssl.termination.method=zeusloadbalancer security.authorized.clients=cvr:20921897-fid:1305269840643,cvr:31569648- RID:1249470221794security.authorized.clients=CVR:19435075-FID:1305202773432 security.ssl.test skal sættes til true hvis der skal bruges OCES-testcertifikater. I udviklingsmiljøet sættes den til "true", mens den sættes til "false" i produktionsmiljøet. security.authorized.clients skal sættes til en komma-separeret liste af subject-serial-numbers for OCES-certifikater der skal have adgang til opslagskomponenten. I produktionsmiljøet skal det sættes til CVR:19435075-FID:1305202773432. 5.3.4 Administrator-GUI Al adgang til administrations GUI er beskyttet af et medarbejdercertifikat (MOCES). Den første administrator oprettes direkte i databasen af driftsoperatøren med følgende SQL: INSERT INTO User (name, cvr, rid) VALUE ("<navn>", "00000000", "1111111111");...hvor parametrene rettes til for at passe med administratorens navn (valgfrit) samt CVR og RID fra administratorens MOCES. Navn benyttes i Revisionsloggen. Herefter kan man i Administrator GUI oprette flere administratorer. 5.4 Yderligere opsætnings-muligheder Om nødvendigt kan et antal properties ændres for både importeren og replikeringstjenesten. Kun de ovenfor nævnte behøver dog ændres. Der kan ændres på følgende properties i importeren: db.url: URL på databasen. db.user: Database-brugeren. db.pwd: Database-brugerens password. db.database: Navnet på databasen. db.housekeepingdatabase: Skal sættes til det samme som db.database. spooler.rootdir: Mappen hvor stamdata-inputfiler lægges. spooler: Liste af spoolere der slås til.

jobspooler: Liste af job-spoolere der slås til. inputfile.polling.interval: Interval i sekunder mellem hvert check af input-mappen. spooler.cpr.file.pattern.person: Regulært udtryk for input-filers navne til cpr-parseren med persondata (både intielt og delta-udtræk) overholder spooler.cpr.file.pattern.person.delta: Regulært udtryk for input-filer til cpr-parseren, som kun matcher delta-udtræk spooler.cpr.halt.on.date.errors: Hvorvidt parseren skal gå i fejltilstand, hvis der er en dato som ikke kan parses spooler.cpr.overduehours: Antal timer, før cpr-parseren er overdue I alt findes følgende properties der kan defineres for replikeringstjenesten: db.connection.driverclass: Udpeger MySQL-driveren. db.connection.jdbcurl: URL på databasen. db.connection.sqldialect: SQL-dialekten som benyttes over JDBC-forbindelsen. db.connection.username: Database-brugeren. db.connection.password: Database-brugerens password. rid2cpr.endpoint: URL'en på DanID's RID-tjeneste. rid2cpr.keystore: Keystore med certifikat til identifikation over for RID-tjenesten. rid2cpr.keystorepassword: Password til RID-keystore. rid2cpr.calltimeout: Timeout for kald til RID-tjenesten. whitelist: Kommasepareret liste af CVR-numre som administratorer i administrator-gui'en kan tilknyttes. whitelistnames: Kommasepareret liste af firmanavne. Skal svare til den kommaseparerede liste angivet under "whitelist". security: "none", "twowayssl" eller "dgws", alt efter om der ønskes hhv. ingen sikkerhed, 2-vejs-SSL eller Den Gode Webservice som sikkerhed til replikeringstjenestens REST-service. security.ssl.test: "true" eller "false", alt efter om der benyttes test- eller produktions-certifikater fra OCES. Kun relevant hvis "security" er sat til "twowayssl". gui.security: "none", "twowayssl" eller "saml", alt efter om der ønskes hhv. ingen sikkerhed, 2-vejs- SSL eller SAML som sikkerhed til administrator-gui'en. security.ssl.termination.method: "container" eller "zeusloadbalancer" alt efter om containeren selv terminerer SSL eller om en zeus load balancer terminerer SSL. I alt findes følgende properties der kan defineres for opslagskomponenten: db.connection.driverclass: Udpeger MySQL-driveren. db.connection.jdbcurl: URL på databasen. db.connection.sqldialect: SQL-dialekten som benyttes over JDBC-forbindelsen. db.connection.username: Database-brugeren.

db.connection.password: Database-brugerens password. security.ssl.test: "true" eller "false", alt efter om der benyttes test- eller produktions-certifikater fra OCES. security.ssl.termination.method: "container" eller "zeusloadbalancer" alt efter om containeren selv terminerer SSL eller om en zeus load balancer terminerer SSL. security.authorized.clients: Komma-separeret liste af "SubjectSerialNumbers" fra OCES-certifikater der skal have adgang til opslagskomponenten. Defaultværdier findes i importer.default.properties, replication.default.properties og lookup.default.properties, som er en del af de to war-filerne løsningen består af. Hvis man ønsker en speciel konfiguration oprettes (kopier evt. fra default filerne) stamdata-importer.properties hhv. stamdata-replication.properties i /pack/jboss/server/default/conf/. Ændres properties i disse filer skal JBoss genstartes. 6 Konfiguration af FTP-overførsel af cpr-data Cpr-data skal lægges (via FTP) i mappen /pack/stamdata/input/cpr/input/ Driftsleverandøren etablerer sikker opkobling til CPR i samarbejde med CPR-kontorets leverandør, CSC og schedulerer jobs til automatisk at hente filer Følgende IP'er er angivet til Kombit som udgående IP-Addresser mod FTP: Prod - 77.243.51.74Stage - 77.243.51.66 Datakilder for CPR. Kombit har bestilt et initielt udtræk pr. 12.05.2011 samt efterfølgende deltaudtræk frem til 30.06.2011. Filer har kundenummer 4493. 6.1 Kørsel af CPR-etablerings-udtræk fra CSC Et etableringsudtræk består af én fil navngivet HERNIN.D<dato YYMMDD>.L<kn>01 hvor <kn> er kundenummer. Et etableringsudtræk startes ved at: 1. Etableringsudtræks filen hentes fra CSC og en kopi gemmes under /pack/stamdata/archive. 2. Give serveren 4GB memory og JVM 1 GB samt genstarte JBoss. 3. Trunker databærende tabeller for CPR: Person, Haendelse, ForaeldreMyndighedRelation, MorOgFaroplysninger, Udrejseoplysninger, AktuelCivilstand, Statsborgerskab, Foedselsregistreringsoplysninger, Folkekirkeoplysninger, BarnRelation, Valgoplysninger, KommunaleForholdog UmyndiggoerelseVaergeRelation, Civilstand (SQL TRUNCATE <tabelnavn>;) 4. Kopier etableringsfilen ind i CPR spooler dir /pack/stamdata/input/cpr/input 5. Vent til filerne er importeret. Dette checkes lettest via webgui'en http://prod01.kombit.netic.dk:8080/importer/status. Hvis der står 'Processing' er importeren igang med at importere data. Når import er færdig vil der stå aktuel dato/tid for seneste import samt tidspunkt for forventet næste import.

6. Check at spooleren ikke er gået i fejl (jf. Driftsvejledning) 7. Efter initielt udtræk kan memory sættes til 2GB og JBoss genstartes. 6.2 "Nulstilling af data" KOMBIT forventer hvert andet år at "nulstille" data ved at modtage et nyt initialudtræk fra CPR. Idet løsningen allerede kan håndtere at et nyt initialudtræk bliver lagt oveni eksisterende data, så "nulstilles" data blot ved at følge vejledning for import af etableringsudtræk fra CPR. Data bliver hermed opdateret til nyeste indhold fra CPR med en gyldighedsdato der svarer til det nye etableringsudtræk. 6.3 Daglig opdatering af CPR data fra CSC Der kører et cronjob tirsdag til lørdag kl. 0:15 som henter en ny datafil fra CSC. Filen er navngivet HERNIN.D<dato YYMMDD>.L<kn>02 hvor <kn> er kundenummer. Cronjob scriptet hedder /pack/stamdata/bin/fetch-cpr.sh og det gør følgende: 1. Henter seneste datafil fra CSC og gemmer en kopi under /pack/stamdata/archive. 2. Flytter datafilen ind under /pack/stamdata/input/cpr/input og giver jboss ejerskab over filen. #!/bin/sh # # Fetch CPR delta data from CSC # FTPUSER=WHERNIN FTPPASSWD=<PASSWORD> # Add 22 hours to timezone to get date of yesterday (also just after midnight when daylight-saving-time is active). DATE=`TZ=CET+22 date '+%y%m%d'` cd /pack/stamdata/download FILE=HERNIN.D$DATE.L449302 /usr/sfw/bin/ncftpget -a -u $FTPUSER -p $FTPPASSWD 147.29.11.10. "'$FILE'" if [ $? -ne 0 ]; then echo "ERROR Couldn't fetch CPR delta data from CSC" exit 1 fi

mv \'$FILE\' $FILE cp $FILE /pack/stamdata/archive mv $FILE /pack/stamdata/input/cpr/input chown jboss:jboss /pack/stamdata/input/cpr/input/$file fi Hvis cron-jobbet ikke afslutter korret logges fejlen, hvilket resulterer I en alarm til overvågningen. Driftsoperatøren skal undersøge og afhjælpe fejlen. Hvis der er hul imellem de modtagne filer (fx. Som følge af at cronjobbet ikke har kørt og der ikke er hentet fen opdateringsfil så vil importeren dedektere dette ud fra datoer, stoppe importen, logge fejlen og resultere I en alarm I overvågningen). 7 Konfiguration af Trafficmanager Foran løsningen er der en trafficmanager af fabrikatet Zeus (www.zeus.com) - efterfter betegnet som Zeus, som håndterer trafikken mellem Internet og JBoss Applikationsserver. Zeus er konfigureret til at håndtere flere ting som beskrevet herunder: 7.1 SSL decryption Mellem Internet og Zeus er trafikken krypteret med SSL (HTTPS) med en selfsigned certifikat. Certifikatet er installeret på Zeus og denne dekrypterer trafikken så den kan håndteres i cleartext inde i Zeus efterfølgende. Trafikken mellem Zeus og Applikationen er derfor ikke krypteret, men da denne trafik kun er rent internt i Netic's VLAN vurderes dette sikkert nok. 7.2 Validering af klient certifikat Efter HTTPS forbindelsen etableres, så kræver Zeus, at klienten sender et klientcertifikat. Dette certifikat valideres i form af, at det er udstedt af TDC OCES CA, hvis rodcertifikat er installeret på Zeus. Kun såfremt klientcertifikatet er udstedt af denne CA, så vil trafikken komme igennem og blive sendt videre til applikationen. Applikationen ser dermed slet ikke trafik, hvis klienten ikke medsender et valid OCES CA certifikat. Inden trafikken sendes videre til JBoss, udtrækker Zeus en række parametre fra klientcertifikatet og sender disse som HTTP-headers til brug for applikationen. Det samlede klientcertifikat medsendes også i form af en HTTP-header så certifikatet kan analyseres yderligere af applikationen. Der er mulighed for at validere certifikatet op mod CRL (Certifikat Revocation List), men dette check er i POC fravalgt og ansvaret overlades i stedet til applikationen som selv laver CRL checks (spærret hhv. udløbet) 8 Konfiguration af Netværk

Test/udvikling og produktionsmiljøerne er adskilte på egen VLAN's og på egne firewall interfaces. Der er både ind og udgående firewall regler til de enkelte VLAN's. Ligeledes er TrafficManager, Overvågnings og Splunkserver placeret på firewall beskyttede VLAN's. Kundens adgang til systemerne går altid via TrafficManageren, som håndterer SSL kryptering. I et større produktionssetup ville selvsamme TrafficManager også håndtere loadbalancing og fungere som failover manager i et to-center setup. Applikationsservernes adgang til CPR registret er åbnet specifikt i firewall og går således ikke gennem TrafficManager. Sikkerhedsmæssigt er der ingen forbindelser mellem test/udvikling og produktion. 8.1 Kundens adgangspunkter Kunden har adgang til applikationsserverne via TrafficManageren: Miljø URL IP adresse port

Test/udvikling https://stage.kombit.netic.dk/ 77.243.49.63 443 Der er kun åbnet for bestemte IP adresser fra kunden ind mod TrafficManageren. Ligeledes skal kunde sørge for at have åbnet for adgang til at kunne tilgå ovennævnte IP adresser og porte. Kunden har adgang til opsamlede logfiler vi en central Splunk logopsamlingsserver hos Netic. Splunk interfacet tilgåes ligeledes gennem TrafficManager og kræver bruger authorisation således at den enkelte brugere kun har adgang til relevante logdata. Splunk logopsamlingsserver https://splunk.netic.dk/ 8.2 Arkitektur og infrastruktur Løsningen er implementeret på en virtuel server med 2CPU, 2GB memory, 30 GB storage. Serveren vil køre Unix Solaris som operativsystem. De virtuelle servere er hosted i et temmeligt stort shared virtuelt miljø der kører VMware vsphere. Serverne er fra Sun Microsystems (nu Oracle). Storage er ligeledes baseret på Sun Unified Storage med fuld redundans (clusteret løsning med raid diske). Netværksudstyr er Cisco, firewalls er Cisco ASA og trafficmanagers er fra Zeus Technologies. Alle komponenter er redundante. 8.3 Firewallregler Alle andre sider end statussider er beskyttet af SSL og benytter port 443. Loadbalancer forwarder gyldige requests (certifikat er gyldigt og udstedt af en OCES CA) på port 8080 til stamdataserveren. Port 8080 skal være åben udadtil (for de whitelistede ip adresser), idet den benyttes til importerens statussider samt til de forwardede SSL-terminerede requests fra load-balanceren. Udefrakommende requests med en SSLClientCert header bør afvises. 8.3.1 Produktion Eksterne åbninger: Type Source Destination port FTP adgang til CPR data prod01.kombit.netic.dk 147.29.11.10 tcp/21 OCES CA spærrelister prod01.kombit.netic.dk dir.certifikat.dk tcp/389 Webservice adgang fra Kombit Kombit IPs prod.kombit.netic.dk tcp/443 Webservice adgang fra Trifork Trifork IPs prod.kombit.netic.dk tcp/443 Loadbalancer <-> jboss Loadbalancer prod01.kombit.netic.dk tcp/8080 Interne driftsmæssige åbninger: Type Source Destination port Splunk logopsamling prod01.kombit.netic.dk Splunk server tcp/9997

SSH adgang til drift Netic drift prod01.kombit.netic.dk tcp/22 Overvågning Overvågningsserver prod01.kombit.netic.dk udp/161, tcp/22, tcp/8080 Backup Backup server prod01.kombit.netic.dk tcp/20031-20099 Syslog prod01.kombit.netic.dk Syslog server udp/514 DNS resolver prod01.kombit.netic.dk DNS resolvere udp/53 NTP prod01.kombit.netic.dk NTP servere udp/123 Udgående mail prod01.kombit.netic.dk Smarthost tcp/25 8.3.2 Test Eksterne åbninger: Type Source Destination port OCES test CA spærrelister stage01.kombit.netic.dk test.dir.certifikat.dk tcp/389 Webservice adgang fra Kombit IPs stage.kombit.netic.dk tcp/443 Kombit Webservice adgang fra Trifork Trifork IPs stage.kombit.netic.dk tcp/443 Loadbalancer <-> jboss Loadbalancer stage01.kombit.netic.dk tcp/8080 SSH adgang Kombit Kombit IPs stage01.kombit.netic.dk tcp/22 SSH adgang Trifork Trifork IPs stage01.kombit.netic.dk tcp/22 Interne driftsmæssige åbninger: Type Source Destination port Splunk logopsamling stage01.kombit.netic.dk Splunk server tcp/9997 SSH adgang til drift Netic drift stage01.kombit.netic.dk tcp/22 Overvågning Overvågningsserver stage01.kombit.netic.dk udp/161, tcp/22, tcp/8080 Backup Backup server stage01.kombit.netic.dk tcp/20031-20099 Syslog stage01.kombit.netic.dk Syslog server udp/514 DNS resolver stage01.kombit.netic.dk DNS resolvere udp/53 NTP stage01.kombit.netic.dk NTP servere udp/123 Udgående mail stage01.kombit.netic.dk Smarthost tcp/25

9 Konfiguration af hardware 9.1 Produktion Hostname prod01.kombit.netic.dk Customer ID 521 Service Level Gold Backup CPU 2 Memory 2048 Network VLAN(360) Disk 1 8 GB Disk 2 22 GB VMWare Guest Sun Solaris 10 (64-bit) VMWare Tools guesttoolscurrent Comment Kombit prod server 9.2 Test/Udvikling Hostname stage01.kombit.netic.dk Customer ID 521 Service Level Bronze Backup CPU 1 Memory 2048 Network VLAN(359) Disk 1 8 GB Disk 2 22 GB VMWare Guest Sun Solaris 10 (64-bit) VMWare Tools guesttoolscurrent Comment Kombit stage/udvikling/test server 10 Installationslog 10.1 Installations log for prod01.kombit.netic.dk Serveren er oprette som en klon af solaris-10u9-template og efterfølgende konfigureret op med IP adresse og brugerstyring.

10.1.1 Disk Der er tilføjet en virtuel disk på 22GB til serveren. Denne benyttes til Zpool pool01. Der oprettes ZFS filsystemerne pool01/home, pool01/pack og pool01/data som monteres som hhv. /home, /pack og /data. Evt. data under tidligere /home og /pack flyttes til nyt zpool. 10.1.2 Brugere til software Der oprettes brugere til software pakkerne MySQL og Jboss: /etc/passwd mysql:x:501:501:mysql:/pack/mysql:/bin/bash jboss:x:502:502:jboss:/pack/jboss:/bin/bash /etc/group mysql::501: jboss::502: Køre pwconv for at lave tilsvarende entries i /etc/shadow. 10.1.3 Java development kit (JDK) Seneste Java JDK hentes til Solaris 10 32 og 64-bit og installeres under /pack/jdk1.6.0_24. Der laves link til /pack/jdk. 10.1.4 MySQL Seneste MySQL 5.1 hentes og installeres under /pack/mysql-5.1.56-solaris10-x86_64 og links til /pack/mysql. Der oprettes seperat ZFS under /data/mysql (pool01/data/mysql) og recordsize sættes til 16kb. Folderne databases, innodb og logs oprettes under /data/mysql og MySQL initialiseres med default data under /data/mysql/databases. my.cnf oprettes under /pack/mysql. 10.1.5 JBoss Seneste JBoss version 6.0 FINAL hentes og installeres under /pack/jboss-6.0.0.final og links til /pack/jboss. Server Configuration cd $JBOSS_HOME/server rm -rf all jbossweb-standalone minimal standard Patch for bug 8786 Fjerne Webapps cp $PATCH_DIR/jboss-as-server.jar $JBOSS_HOME/common/lib/jboss.jar cd $JBOSS_HOME/server/default/deploy rm -rf ROOT.war rm -rf http-invoker.sar rm jmx-console-activator-jboss-beans.xml rm jbossws-console-activator-jboss-beans.xml rm admin-console-activator-jboss-beans.xml

rm -rf admin-console.war rm -rf jbossws-console.war rm -rf jmx-console.war cd $JBOSS_HOME/server/default/conf/props rm jbossws-* rm jmx-console-* Fjerne JMS (HornetQ) cd $JBOSS_HOME/server/default/deploy rm -rf hornetq cd $JBOSS_HOME/server/default/deployers rm -rf hornetq-deployers-jboss-beans.xml Tilpasset conf Sæt ejerskab af filer chown -R root:jboss $JBOSS_HOME chown -R jboss:jboss $JBOSS_HOME/server/default/data chown -R jboss:jboss $JBOSS_HOME/server/default/work chown -R jboss:jboss $JBOSS_HOME/server/default/tmp chown -R jboss:jboss $JBOSS_HOME/server/default/log Start JBoss under SMF cp svc-jboss /lib/svc(method/svc-jboss cp jboss.xml /var/svc/manifest/network/jboss.xml svccfg import /var/svc/manifest/network/jboss.xml 10.1.6 Splunk forwarder Udpak splunk forwarder software under /pack cd /pack gtar xvfz ~/splunk-4.2.1-98164-sunos-i386.tar.z mv splunk splunkforwarder-4.2 ln -s splunkforwarder-4.2 splunkforwarder Initalisering af splunk forwarder cd /pack/splunkforwarder/bin./splunk start --accept-license./splunk add forward-server splunk01.netic.dk:9997 Splunk username: admin Password:./splunk disable webserver

Konfigurer splunk ipnuts /pack/splunkforwarder/etc/system/local/inputs.conf [default] host = prod01.kombit.netic.dk [monitor:///var/log/stamdata/] index = kombit [monitor:///pack/jboss/server/default/log/] index = kombit [monitor:///data/mysql/logs/mysql-slow.log*] index = kombit Genstart splunk /etc/init.d/splunk restart 10.2 Installations log for stage01.kombit.netic.dk Serveren er oprette som en klon af solaris-10u9-template og efterfølgende konfigureret op med IP adresse og brugerstyring. 10.2.1 Disk Der er tilføjet en virtuel disk på 22GB til serveren. Denne benyttes til Zpool pool01. Der oprettes ZFS filsystemerne pool01/home, pool01/pack og pool01/data som monteres som hhv. /home, /pack og /data. Evt. data under tidligere /home og /pack flyttes til nyt zpool. 10.2.2 Brugere til software Der oprettes brugere til software pakkerne Trifork T4, MySQL og Jboss: /etc/passwd mysql:x:501:501:mysql:/pack/mysql:/bin/bash jboss:x:502:502:jboss:/pack/jboss:/bin/bash /etc/group mysql::501: jboss::502: Køre pwconv for at lave tilsvarende entries i /etc/shadow. 10.2.3 Java development kit (JDK)

/pack/jdk. 10.2.4 MySQL Seneste MySQL 5.1 hentes og installeres under /pack/mysql-5.1.56-solaris10-x86_64 og links til /pack/mysql. Der oprettes seperat ZFS under /data/mysql (pool01/data/mysql) og recordsize sættes til 16kb. Folderne databases, innodb og logs oprettes under /data/mysql og MySQL initialiseres med default data under /data/mysql/databases. my.cnf oprettes under /pack/mysql. 10.2.5 JBoss Seneste JBoss version 6.0 FINAL hentes og installeres under /pack/jboss-6.0.0.final og links til /pack/jboss. 10.2.6 Brugere og sudo De brugere som skal have access til serveren oprettes i Ldap/kerberos og tildeles access til staging miljø. SSH åbnes for portforwarding.i Cfengine disables distribution af visudo tilserveren og visudo tilføjes manuelt de personer som skal have adgang til at bruge sdo på serveren. 11 Backup Der tages daglig backup af database til tape med retentiontid på 26 uger. Ydermere er der backup af de virtuelle maskiner til disaster-recovery. CPR filer kopieres efter modtagelse fra CPR til /pack/stamdata/archive som der også tages daglig backup af. Backup er beskrevet i Netic Backuppolitik. Der tages kun backup af produktionsserver. 11.1 Rollback/Gendannelse af backup Ved uoprettelige fejl i en release (n) kan løsningen føres tilbage til en tidligere release (n-1). Se den konkrete Releasedokumentation for hvilke ændringer den aktuelle release har medført. 1. Adgang til applikationsserveren lukkes i Trafic Manager 2. war-filer fra release n-1 deployes til applikationsserveren som genstartes. 3. Hvis seneste release har haft databaseændringer eller seneste release har medført at data i databasen er fejlbehæftet skal databasen genskabes fra en tidligere backup 4. Applikationsserver startes og statussider kontrolleres 5. CPR data indlæses i løsningen ved at kopiere nyere filer end backup fra backuparkivet til input 6. Når importeren er færdig med at importere data kontrolleres log 7. Adgang til applikationsserveren åbnes i Trafic Manager Hvis en klient/serviceaftager allerede har fået fejlagtige data bør de slette data og starte forfra med et nyt udtræk. 12 Deployment & verifikation

12.1 Deployment Kopier både importer.war, replication.war og lookup.war ind under (JBoss home)/server/default/deploy/ Foretag evt. ændringer beskrevet i releasenote. Genstart jboss. 12.2 Verifikation 12.2.1 Importer Gå ind på http://(maskine):8080/importer/status Alle felter på hjemmesiden bør være grønne, på nær ét som er gult og siger at visse spoolers er 'overdue'. Dette skyldes at der endnu ikke ligger data i databasen. 12.2.2 Replikeringstjeneste Importér et certifikat i browseren der svarer til det der er angivet for den første administrator-bruger. Gå ind på https://(loadbalancer)/replication/admin Siden bør vise netop den tidligere oprettede administrator-bruger. Gå ind på https://(loadbalancer)/replication/admin Der bør blot stå "200 OK" på siden. 12.2.3 CPR-opslagskomponent Gå ind på https://(loadbalancer)/lookup/personclient og slå et CPR nummer på en person der findes i systemet op. Personens navn og detaljer skal fremgå af siden. 13 Dataudtræk til klient For at tilgå data skal klienten benytte et gyldigt klientcertifikat (FOCES) som er whitelisted (CVR/FID) af en administrator i Administrator GUI'en (se Administrator GUI brugerguiden). Importeres FOCES i en browser kan man kontrollere adgangen ved at benytte https://prod.kombit.netic.dk/replication/stamdata/usage/client/v1 (forudsat at aministratoren har givet klienten/serviceaftageren adgang til dette view) 14 Overvågning 14.1 Service level Serviceniveauet på Testserveren er jf. Netic Bronze niveau, og produktionsserveren på Guld niveau. Disse servicelevels udløser en række parametre omkring SLA og kapacitet, som er beskrevet i Netic Servicemål. Produktiosserveren driftes og overvåges fra 8-17. Der tages ikke backup af testserveren, der laves ikke

af diske, memory, hard-reset etc. For KOMBIT er der defineret følgende tidsvinduer. * dog kl. 17 jf. Netic Guld niveau. Type Tidsinterval Beskrivelse Almindeligt adgangsvindue Batchvindue Servicevindue Mandag til fredag fra 08:00 til 18:00* Mandag til søndag fra 22:00 til 04:00 Mandag til fredag fra 18:00 til 22:00 og fra 04:00 til 08:00, samt lørdag og søndag Almindelig driftsperiode, hvor Løsningen er tilgængeligt for Kundens Anvendersystem. Driftsperiode, hvor Løsningen kan opdateres med registerudtræk eller registerændringsudtræk fra CPR-registret. Det tidsrum, hvor Leverandøren må påvirke miljøet, herunder medføre at elementer heraf er midlertidigt utilgængelige. 14.2 Alarmering Vælg Zenoss Group Ingen Hosted Servers-mailonly Network-mailonly SMS alamering 7-23 alle dage (SLA-7-23) SMS alamering 24-7 alle dage (SLA-24-7) 14.3 Tjenester Udover alm. (NETIC:Standard OS overvågning) overvåges nedenstående. Severity: Warning eller Error. Ved Warnings vil der aldrig blive til SMS udenfor dagtid, det vil Errors hvis ellers devicen er i passende alarmgruppe. Tjeneste/ Beskrivelse Spooler DB Overdue CPR Rejected CPR URL/URI/Path/Parameter Severity Fix http://prod01.kombit.netic.dk:8080/importer/status?isali ve=spoolers http://prod01.kombit.netic.dk:8080/importer/status?isali ve=db http://prod01.kombit.netic.dk:8080/importer/status?ove rdue=cpr http://prod01.kombit.netic.dk:8080/importer/status?reje ctedfiles=cpr Error Error Error Error Se Overvågning Se Overvågning Se Overvågning Se Overvågning

Importer applikationen importerer CPR data som hentes med FTP fra CSC en gang i døgnet. Hvis disse data udebliver vil det resultere i overdue alarm. 14.4 isalive-overvågning importer.war udstiller følgende isalive-overvågnings-url'er: /importer/status?isalive=spoolers /importer/status?isalive=db De skal begge kaldes periodisk med et tidsinterval der afspejler den aftalte SLA. Når de giver HTTP-status 200, er de oppe. Hvis de giver noget andet - fx http status 500 - er de nede. Kig i systemloggen efter ERROR for at se konkrete fejlbeskeder og fejlret jf. disse. Hvis spoolere er nede, skal JBoss genstartes. Hvis det ikke hjælper, så kontaktes Trifork-support på 28182410. Hvis databaseforbindelsen er nede, skal MySQL og forbindelsen hertil fra JBoss fejlsøges. Der bør opsættes overvågning på Trafic Manager så en evt. utilgængelighed bliver registreret og en alarm trigges i overvågningen. 14.5 Rejected importer.war udstiller følgende overvågnings-url til at tjekke for rejectede filer: /importer/status?rejectedfiles=<spoolernavn> Spoolernavn svarer tid de registre der er implementeret dataimport fra. For Kombit vil det være "cpr" Hvis der ikke kommer http-status 200, så skal der oprettes en alarm. Det er muligt at se begrundelsen for at importen fejlede. I /pack/stamdata/input/cpr/rejected vil der være en folder hvor navnet er et tidsstempel for hvornår importen blev startet, f.eks..../rejected/2009-09-04t13-13-02. I folderen vil der også være en tekstfil, RejectReason, hvori der er en beskrivelse af fejlen. Hvis fejlen er en åbenlys systemfejl, f.eks. netværksfejl, kan filerne (minus RejectReason-filen) flyttes tilbage til input, hvorefter en ny import automatisk vil starte. Husk at slette folderne i rejected-folderen for at fjerne alarmen. Er fejlen ikke åbenlys, ringes til Trifork-support på 28182410. 14.6 Overdue importer.war udstiller følgende overvågnings-url til at tjekke for om de enkelte spoolers har modtaget input filer inden for et given tidsinterval.

/importer/status?overdue=cpr Tidsgrænsen er konfigurerbar pr. spooler og default sat til 12 dage for cpr. I KOMBIT er der lavet en specialkonfiguration på 26 timer (jf. installationsguide). Dette bevirker at der i weekenden og på helligdage vil være overdue status som skal håndteres af driften. 14.7 Timeout importer.war overvåger input-folderen for nye datafiler der skal importeres. Tiden der går, fra et nyt filset lægges i input, indtil både input og processing er tomme, skal overvåges ad Driftsoperatøren. Hvis der går mere end fx 4 timer, skal der trigges en "Timeout"-alarm. Hvis miljøet ellers virker normalt - dvs. mysql, JBoss, filsystem, netværk mv. kører som det skal: 1. JBoss stoppes 2. Alle filer under input og processing flyttes til rejected 3. JBoss skal startes igen 4. Triggering af "rejected"-alarm. Hvis der er identificeret problemer i miljøet: 1. Udbedr problemer med MySQL, JBoss, filsystem, netværk eller andet. 2. Genstart JBoss, hvorved importeren forsøger processering forfra 14.8 Logfiler Der er lavet Splunk logopsamling på både test- og produktionsserver. Alle kombit brugere er oprettet til Splunk. Logdata i produktion kan ses ved at logge på her: splunk.netic.dk Man skal benytte samme brugernavn som til server login, men før man kan logge ind skal I have sat et LDAP password. Det gør man ved at gå ind på denne side og bede om et 'password reset' for jeres bruger: changepw.netic.dk Når man vælge 'password reset' vil man få genereret et password og få det tilsendt pr. mail. Man kan herefter skifte det til noget selvvalgt på samme side. For konfiguration af Splunk henvises til leverandøren http://www.splunk.com/base/documentation/latest/admin/aboutconfigurationfiles Følgende logfiler overvåges af Splunk: /pack/jboss/server/default/log/server.log: Generelle JBoss-logninger. /var/log/stamdata/importer.log: Audit- og fejllog fra importeren.

/var/log/stamdata/lookup.log: Audit- og fejllog fra CPR-opslagskomponenten. Der benyttes standard log4j-funktionalitet. Konfiguration ses i log4j.xml for de enkelte moduler. INFO, WARN og ERROR logges med tidspunkt, tråd samt ip-adr. Et eksempel på en linje i en logfil ses her (linjen er brudt af pladshensyn): INFO requestid=463280980, ip=172.30.121.101 {PersonResource [http-8443-1] - Opslag på ikke-eksisterende cpr-nummer. cpr=0709614126, subject-serialnumber='cvr:20921897- FID:1305269840643' MySQL slowlog (log over lange transaktioner) overvåges og sættes til 2 sek. 14.9 Andre overvågninger Derudover overvåges operativsystemet ift. normal funktionalitet (disk, cpu, netværk etc.). OBS: Det er forventeligt at importer.war under import kører med max CPU i flere minutter - dette er ikke en fejlsituation. Initielt dataudtræk for Herning tager ca. 20 minutter at indlæse.