Dokumentasjonen er ment for systemutviklere i NAV. Men kan også leses av NAV-adminstratorer.
Innholdsfortegnelse:
Eksterne dokumenter som hører til dokumentasjonen:
NAVuser er en del av NAV fra og med versjon 3. NAVuser er et delsystem som håndterer brukerdatabasen og et system for varslingsprofiler for brukere. NAVuser bruker en postgresql database med navn navuser. Grensesnittet for å administrere brukerdatabasen og varslingsprofilene er webbasert og skrevet i php. Hver bruker kan logge inn med sitt brukernavn og passord, og definere sine egne profiler for varsling, og spesifisere grupper av utstyr man ønsker varsling på, til hvilke tider man ønsker varsling og på hvilket medium man ønsker å bli varslet (eks: mail og sms).
Filene som inngår i delsystemet NAVuser er delt inn i: www-filer, dokumentasjon og databaseinitialiseringsskript.
Dokumentasjonen er plassert under navme/doc/navuser/.
Databaseinitialiseringsskriptet er plassert her: navme/etc/conf/db/navuser.sql.
Her følger en beskrivelse av alle php-filene som inngår i www-delen av NAVuser. Siden administreringen er webbasert er dette hoveddelen av NAVuser.
drwxrwxrwx 6 andrs staff 204 Jan 10
18:38 css
drwxrwxrwx 33 andrs staff 1122 Jan 10 18:41 icons
drwxrwxrwx 8 andrs staff 272 Jan 10 18:46 images
css inneholder stylesheetsfiler, som definerer utseende på sidene. icons er en katalog med alle ikonene. images inneholder andre bilder, som topplogo med mer.
-rw-r--r-- 1 andrs staff 5803 Jan 9 11:46 index.php
Alle undersidene i webgrensesnittet aksesseres via hovedfilen index.php. Det er en sesjonsvariabel $action i php som holder styr på hvilke seksjon man jobber med, altså hvilke av php-filene som lastes inn i hovedvinduet i webgrensesnittet. Disse seksjonene kan deles inn i flere sekvenser, som spesifiseres med variabelen $subaction. Siden disse variablene blir lagret i sesjonen på serversiden, husker serveren hvilke seksjon man jobber på slik at man bare oppgir $action parametre når man ønsker å endre seksjon. Dette ser man typisk på lenkene i menyen i venstremargen som typisk kan være index.php?action=admin.
-rw-r--r-- 1 andrs staff 7687 Jan 9
16:04 admin.php
-rw-r--r-- 1 andrs staff 4618 Oct 30 10:00 adress.php
Filen admin.php har med administreringen av brukere å gjøre.
-rw-r--r-- 1 andrs staff 3213 Jan 9 07:56 auth.php
Kalles ifra index.php hver gang og sjekker sesjonsvariabelen om brukeren er korrekt innlogget, og itillefelle hvilke admin-nivå brukeren har. I databasetabellen Bruker er et heltall kalt admin som kan være mellom 0 og 100. 0 er avslått brukerkonto. 1 er vanlig bruker. 100 er hovedadministrator. Verdier mellom 1 og 100 er ikke brukt i dagens løsning, men hvis man ønsker å differensiere administrator-tilgangen så er det tilrettelagt for det.
-rw-r--r-- 1 andrs staff 54060 Jan
9 15:23 databaseHandler.php
-rw-r--r-- 1 andrs staff 28 Aug 17 22:29 dbclose.php
-rw-r--r-- 1 andrs staff 10 Aug 17 22:29 dbinit.php
dbinit.php skal initialisere databaseforbindelsen og en handle eller peker til koblingen er tilgjenglig i resten av systemet gjennom $dbh. Per idag ligger vel oppkoblingen mot databasen i auth.php men den skal flyttes.
dbclose.php lukker databasekoblingen.
databaseHandler.php inneholder en funksjon for hver "type" av spørringer som gjøres mot databasen. Dette er med hensikt samlet i samme filen, for å få det mer oversiktlig. Spørringene er laget med linjeskift og innrykk så de skal være så lesevennlige som mulig.
Gjennomgående har jeg benyttet nøstede spørringer der det har vært naturlig for å øke hastigheten, og for å gjøre koden mer oversiktlig. Noen steder har dette ført til ganske komplekse spørringer, men jeg har forsøkt å gjøre det så lesbart som mulig.
På de fleste listevisningene i webgrensesnittet har jeg forsøkt å få med så mye info som mulig, for å gjøre administreringen lettere. Slik at man for eksempel ser hvor mange brukere som er medlem i brukergrupper også videre. Disse "tellingene" har også medført at spørringene har blitt litt komplekse.
-rw-r--r-- 1 andrs staff 4745 Jan 9
10:30 fellesutstyr.php
-rw-r--r-- 1 andrs staff 4856 Jan 9 09:40 utstyr.php
-rw-r--r-- 1 andrs staff 5008 Nov 6 18:33 utstyrgrp.php
I utstyr.php kan man opprette og endre på utstyrsgrupper knyttet til sin private bruker. I fellesutstyr.php administrerer man utstyrsgrupper som er felles for administratorene og som kan brukes som standardgrupper som knyttes til brukergrupper og vil være tilgjengelig for alle brukere som er medlem av den gitte brukergruppen.
Når man skal endre på en bestemt utstyrgruppe er det i utstyrgrp.php hvor man knytter utstyrsfiltre sammen og til utstyrsgruppe. Her endrer man prioritet og rekkefølge.
-rw-r--r-- 1 andrs staff 4236 Nov 6
16:23 filter.php
-rw-r--r-- 1 andrs staff 0000 --- - --:-- fellesfilter.php
-rw-r--r-- 1 andrs staff 7388
Nov 6 17:15 match.php
I filter.php kan man opprette og slette filtre til sin private bruker. Tilsvarende gjelder fellesfilter.php administreringen av filtre som er tilgjenglig bare for administratorer og brukes til å lage felles utstyrsgrupper som kan knyttes til brukergrupper.
I match.php endrer man hvilke betingelser eller matcher som må være oppfylte for at en hendelse skal kunne validere som sann igjennom et definert utstyrfilter.
-rw-r--r-- 1 andrs staff 464 Oct 2 10:21 hjelp.php
I menyen i venstremargen er det et menyvalg som heter hjelp, her er det meningen at man skal finne all brukerdokumentasjon som skal være tilgjengelig for brukeren. Dette kan være FAQ, ikonforklaringer og brukermanualer, og kanskje systembeskrivelser.
-rw-r--r-- 1 andrs staff 3582 Aug 17
22:29 image.php
-rw-r--r-- 1 andrs staff 5608 Jan 8 12:30 profil.php
-rw-r--r-- 1 andrs staff 10499 Nov 6 16:52 periode.php
-rw-r--r-- 1 andrs staff 3452 Aug 17 22:29 timeplan.php
En bruker kan igjennom profil.php definere sine egne brukerprofiler og aktivisere en som skal være gjeldende. Videre kan man i periode.php definere en timeplan for en gitt profil under periode.php. I denne visningen får man en grafisk visning av en timeplan og dette bildet blir generert i filen timeplan.php.
image.php er tidligere versjon av timeplan.php og vil bli fjernet fra cvs.
-rw-r--r-- 1 andrs staff 677 Aug 17 22:29 kunnskap.php
Filen er ikke i bruk. Den er ment å være en klasse for kobling mot kunnskapsdatabasen for håndtering av match-menyene. Dette er vel forøyeblikket implementert rett inn i match.php for UNINETT sitt vedkommende.
-rw-r--r-- 1 andrs staff 4269 Oct 30 13:50 listing.php
listing.php er et bibiliotek for å lage en listevisning. den tar inn overskrifter, alignment, og rader hver for seg og genererer en fin tabell html tilbake. Denne er gjennomgående brukt overalt, slik at hvis man ønsker å endre utseende eller måte tabellene er bygd opp på, kan man enkelt gjøre det i dette biblioteket.
-rw-r--r-- 1 andrs staff 176 Oct 23 14:10 loginordie.php
Seksjoner som krever innlogging (stort sett de fleste) kaller funksjonen loginordie() i denne filen, den sjekker om man er korrekt innlogget og skriver ut en feilmelding hvis man ikke er det. Dette vil bare skje hvis noen forsøker å omgå innloggingsmekanismen for å få tilgang til seksjoner i webgrensesnittet.
Denne sjekker bare om man er innlogget eller ikke. En videreføring som er nødvendig er å gjøre en dobbeltsjekk mot brukerens administrasjonsnivå og sammenligne denne med nivået som seksjonen krever. Denne mekanisken skal legges inn i index.php, der seksjonene kalles. Når det er gjort blir denne filen overflødig og fjernet.
-rw-r--r-- 1 andrs staff 3491 Jan 8 09:41 oversikt.php
Når man logger inn får man en oversikt over alle brukergrupper man er medlem i og hvilke ustyrsgrupper man har tilgang til som følge av gruppemeldemskapene sine.Man kan også se aktiv profil og endre aktiv profil i denne oversikten. Man får også listet opp fullt navn på brukeren som er innlogget.
-rw-r--r-- 1 andrs staff 344 Oct 23 10:54 session.php
Bibliotek for håndtering av sesjonsvariabler. Denne filen er ikke i bruk i gjeldene versjon.
-rw-r--r-- 1 andrs staff 3064 Jan 9 15:49 velgbrukergrupper.php
Når man oppretter en ny bruker eller endrer en bruker kan man krysse av for alle brukergrupper denne brukeren skal meldes inn i.
-rw-r--r-- 1 andrs staff 579 Sep 30 10:01 velkommen.php
Denne inneholder teksten som vises på fremsiden.
-rw-r--r-- 1 andrs staff 1457 Oct 30 14:25 wap.php
Her kan man slå av å på mulighet for wap-administrering av sin bruker. Det blir generert en nøkkel som man bruker når man logger seg inn via wap.
Databasen heter navuser, og befinner seg på samme maskin som NAV-installasjonen. Det ligger et initialiseringsskript i cvs som sletter alle tabellene med innhold og oppretter de på nytt.
For å få oversikt over databasen kan databasemodellen (UML) være til hjelp.
Databasen kan gjerne deles inn i 3 hoveddeler. Det er:
Utstyret blir gruppert med en slags matching mekanisme. Alt utstyr som matcher et uttrykk er med i en gruppe. På den måten vil automatisk nytt ytstyr bli tilordnet riktig gruppe uten noe manuell og tungvindt administrasjon.
Brukergruppene og brukerne kan tilordnes rettigheter til grupper av utstyr.
Og hver enkelt bruker kan så selv gå inn å opprette sine egne profiler og grupper via webgrensesnittet.
En bruker kan ha et vilkårlig antall alarmadresser. Alarmadressene tilordnes typer. Disse typene kan f.eks være: 1 mail, 2 sms, 3 icq, 4 irc, 5 web, 6 sip(ip-telefoni). Da kan adressen f.eks være tilsvarende: 1 bruker@uninett.no, 2 99664433, 3 23456567, 4 Nick!ident@server, 5 -, 6 sip:bruker@uninett.no. I utgangspunktet vil systemet ha muligheten for Mail og SMS varsling, men denne måten å lagre adressene på åpner for utvidelser i framtiden. Hvis en bruker ønsker å sette opp SMS alarmer må administrator gi brukeren rettighet til dette.
En bruker kan være medlem i vilkårlig mange grupper. Gruppene vil angi hvilke rettigheter brukeren har til å sette opp alarmer. Samtidig vil den gi et sett med standard utstyrsgrupper, som brukeren enkelt kan bruke i sine profiler. Disse ferdiglagde brukergruppene kan brukes på tvers av organisasjoner - og vil bli automatisk tilpasset, siden de vil bli satt sammen med den enkelte bruker sine rettigheter. F.eks kan vi tenke oss en utstyrsgruppe som har navn "Webservere", denne er standard for alle brukere som er med i brukergruppen "WebUtviklere". La oss tenke oss to forskjellige webutviklere, en som jobber for Uninett og en som jobber for ITEA. Webutvikleren som jobber for ITEA er i tillegg til gruppen WebUtviklere medlem av gruppen ITEA-ansatt. Når vedkommende ønsker å lage seg en varslingsprofil som varsler når en webserver går ned, krysser han for varlsing til ønskede adresser koblet til utstyrsgruppen "Webservere". Utstyrsgruppen Webservere vil for vedkommende innebære alle webservere som vedkommende har tilgang til og det vil kanskje bety alle webservere til ITEA.
Selv om brukergruppene i utgangspunktet ikke er definert hierarkisk, kan man enkelt definere en hiearkisk struktur med brukergruppene. Man kan ha brukergrupper som for eksempel, NTNU, Fakultet IME, Institutt Telematikk. En student kan da være medlem av alle disse tre gruppene. En student på et annet fakutet kan f.eks være medlem bare av NTNU-gruppen.
Når man knytter varslingsprofiler til hvilket utstyr man skal overvåke, angir man et sett med grupper av ustyr, og et sett med alarmtyper man ønsker varsling på. Gruppene bestemmes i to nivåer. Utstyrsgrupper som er en samling med Utstyrsfiltre. Et utstyrsfilter er en samling med parametre og verdier som er en betingelse for at en enhet skal være medlem i en gruppe.
For eksempel kan man definere følgende filter:
(stedsid = 34) AND (orgid = 54)
Dette filteret vil være realisert som et Utstyrsfilter, med to relaterte FilterMatch
rader. Disse radene vil ha matchtype lik eksakt, og matchfelt vil være henholdsvis
stedsid og orgid.
Merk at FilterMatch'ene danner et AND utrykk, som tilsammen bestemmer filteret. I eksempelet over hadde vi utrykket (stedsid = 34) AND (orgid = 54).
For å danne en utstyrsgruppe kan man sette sammen en prioritert liste med Utstyrsfiltre, hvor hver enkelt er merket med inkluder eller ekskluder. På denne måten kan man lage grupper som inneholder alle mulige kombinasjoner av utstyr. Her er et eksempel på hvordan en gruppe kan bli bygget opp.
Dette var bare et eksempel og sansynligvis et ganske dårlig et, men det viser hvordan man kan bygge opp ganske spesielle filtre på en oversiktlig og enkel måte.
Brukerne kan definere sine egne profiler for varslinger. Eksempler på brukerprofiler kan være:
Brukerne har til enhver tid akkurat en brukerprofil aktiv. Brukerne kan sette hvilken brukerprofil som er aktiv via webgrensesnittet.
En brukerprofil kan ha flere tidsperioder. Tabellen tidsperiode har feltet helg, dette kan være f.eks: 0 alle dager, 1 man-fre, 2 lørdag og søndag.
Innenfor hver tidsperiode kan man for hver enkelt definert utstyrgrupper spesifisere et antall alarmadresser, og om hver alarmadresse skal legges i kø eller sendes med en gang. Den kan legges i forskjellige typer kø. Den kan legges i døgnlig kø. Den sendes ut et bestemt tidspunkt hver dag, dette tidspunktet bestemmes for hver enkelt profil. Likeledes kan den legges i ukentlig kø, brukeren kan også spesifisere dag og klokkeslett som den ukentlige køen tømmes. Den kan også legges i en kø "inntil videre", da blir den liggende på vent, til brukeren bytter aktiv profil en profil som kvalifiserer for utsendelse av den aktuelle alarmen. For at alarmer ikke skal bli liggende i denne køen for alltid, er det knyttet en makstid til hver enkelt bruker som bestemmer hvor mange dager brukeren har lov til å ha alarmer liggende i køen. Når en alarm har ligget over denne fristen, blir alarmen sendt ut.
Andreas Åkre Solberg
UNINETT AS
Andreas.Solberg@uninett.no