Pixilab Blocks
Serversoftwaren kjører på en Linux-server (Versjoner for Windows og Mac finnes også).
Rollefordeling
ITI-APP har ansvaret for OS og applikasjonen. KHM og utstillingsleverandør har ansvaret for innholdet. ITI-AVB er koordinator og teknisk rådgiver.
Servere
Pixilabservere som er i drift ved UiO:
- pixilab-prod.uio.no (w3prod-pixilab02.uio.no) - Produksjonsserver KHM
- pixilab-utv.uio.no (w3utv-pixilab01.uio.no) - Utviklingsserver
Tilganger
Gruppen Pixilab-Core har admin-tilgang på server.
Leverandørbrukere registreres i GREG på KHM, og legges inn med rolle «MANAGER» via server-gui av en adminbruker - dette gir tilgang til å legge til spots og blocks. De omdefineres så til «STAFF» når utstillinger er ferdig utformet, for å ta vekk skrivetilgang.
Ekstern bruker meldes inn i tilgangsgruppe (i "Remote Desktop Users"): it-khm-utstilling-ts for tilgang til terminalserveren av-khm-ts-p01.uio.no til KHM.
Bruker veiledes til å melde seg inn i Guacamole. RDP tilkobling til terminalserver legges til Guacamole-bruker.
Behov om opprettelse av brukere meldes til pixilab@usit.uio.no.
Infrastruktur
- Prodnett: VLAN 214
- Utviklingsnett: VLAN 215 (brannmuret mot å snakke med prod-klienter, men ikke ACL-sperret)
- Nettene har samme ACL.
Målet er å ha to servere, prod + utv. Ideelt sett bør det kjøre en klonejobb fra prod-serveren slik at utviklingsserveren kan laste dette klonede datasettet under oppstart og gi et bilde av hvordan prodservern ser ut. Merk at de klonede dataene kun er selve innholdet og ikke inneholder klientinformasjon, prod-klientene SKAL IKKE røres av utviklingsserveren.
Vi bør også ta vare på det klonede datasettet fra prodserveren regelmessig og teste restore. Snapshots på VM-nivå kan diskuteres med virt-core.
Oppgraderinger
Testes på utv med klonede data. Rulles ut på mandager på prodserveren dersom det ser bra ut (les: serveren starter og man ikke får noen feil). Oppdateringer er planlagt å gjøres manuelt per nå. På sikt kan man automatisere ting, spesielt lage et wrapper-script som:
- laster ned en gitt versjon (vi må potensielt holde rede på versjoner selv)
- stopper tjenesten
- flytter kjørende jar til en backup-lokasjon (datostemplet)
- flytter den nye versjonen inn som aktiv versjon
- starter tjenesten
Tips
- Omstart av serveren (sw, ikke hw): sudo systemctl restart blocks