Eksisterende konfigurasjon
Med unntak av logg-konfigurasjon og konfigurasjon for lasting av bofhd-moduler, er alle konfigurasjonsfiler python-moduler. Dette har flere ulemper, og noen få fordeler.
Konfigurasjon består (i de fleste tilfeller) av en standardkonfigurasjon (python-modul med standard-verdier og noe dokumentasjon i kommentarer), pluss en modul som henter ut standardkonfigurasjon og overstyrer innstillinger fra denne.
Fordeler
- Finne konfigurasjon
- Slipper å oppgi path til konfigurasjon. Konfigurasjon søkes opp i python sin sys.path.
- Overstyre konfigurasjon
- Relativt enkelt å overstyre konfigurasjon, man trenger bare å endre/legge til en path i python sin sys.path.
Ulemper
- Ingen formkrav i konfigurasjon
Ulike konfigurasjonsfiler er implementert ulikt.
Det er heller ingen standard for gruppering av innstillinger som berører et felles område.
- Lite oversikt
- Vi har lite oversikt over hva som kan konfigureres. Det er også vanskelig å se hva som er konsekvens av ulike innstillinger, og hva som er gyldig verdi for ulike innstillinger.
- Innstillinger er modul-attributter
- Uthenting av attributtverdier gjøres ulikt i Cerebrum-koden. Enkelte steder er det verktøy for å hente ut konfigurasjonsverdier, noe som gjør det vanskelig å søke etter bruk av konfigurasjonsverdier i koden.
- Feilsøking
Fordi konfigurasjon kommer fra moduler, kan det være vanskelig å vite hvilken konfigurasjon som faktisk brukes. Vi har flere ganger støtt på problemer hvor en gammel konfigurasjon blir lastet inn av ulike årsaker.
I tillegg har vi ikke noe mulighet for å feilsjekke konfigurasjonsfiler utover å se at python-modulen ikke inneholder syntaksfeil.
- Innlasting av ny konfigurasjon
- Vi må starte på nytt tjenester (bofh, cis, …) for å laste inn ny konfigurasjon.
- For tett kobling mellom kode og konfigurasjon
Konfigurasjonsfiler inneholder innstillinger som ikke burde være konfigurerbare. Dette inkluderer bl.a. klasseoppbygging.
Dette gjør at man fort kan lage 'gyldig konfigurasjon' som ikke vil kjøre, eller ikke vil fungere som tiltenkt.
Eksisterende konfigurasjon
cereconf
- Generell Cerebrum-konfigurasjon.
- Python-modul
- Henter default-verdier fra Cerebrum.default_config
- Inneholder veldig mye instans- og modul-spesifik konfigurasjon
- Stor og uoversiktlig konfigurasjon
- Bygging av klasser i konfigurasjon
adconf
- Konfigurasjon av AD2-sync
- Python-modul
- Henter default-verdier fra Cerebrum.config.adconf
- Bygging av klasser i konfigurasjon.
- Eget konfigurasjonsrammeverk
config.dat
- Konfigurasjon av innlasting av bofhd-moduler
- Linje-separert liste over modul-klasser
cisconf
- Konfigurasjon av CIS (SOAP-WS) i Cerebrum
- Python-pakke
- Henter default-verdier fra Cerebrum.modules.cis.default_config
- Ulik en del annen Cerebrum-konfigurasjon, mye bruk av "arv"
eventconf
- Konfigurasjon av EventLog i Cerebrum
- Python-modul
- Henter default-verdier fra Cerebrum.config.eventconf
guestconfig
- Konfigurasjon av Cerebrum.modules.guest/bofhd_guest_cmds (begrenset gjestebruker)
- Python-modul
- Henter default-verdier fra Cerebrum.modules.guest.default_guestconfig
changepassconf
- Konfigurasjon av passordvarsel og sperring av brukere
- Python-modul
- Henter default-verdier fra Cerebrum.modules.PasswordNotifier.default_config
posixconf
- Python-modul
- Oppdaterer cereconf.LDAP_POSIX
- Pussig hack
scheduled_jobs
- Konfigurasjon av jobber i job_runner
- Stor og uoversiktlig
- Mye "kode som konfigurasjon"
- Eget konfigurasjonsrammeverk
opset_config
- Konfigurasjon av tilganger i bofhd
- Brukes til å legge inn, fjerne og oppdatere opsets i database.
- Python-modul?
Flere, sære config-moduler
Det finnes også enkelte andre moduler, f.eks. for opprydding av logger, opprydding i changelog, etc...
Ønsker og krav til konfigurasjon
- Konfigurasjonsfiler, ikke python-moduler
- Vi må likevel sørge for at Fordeler fra dagens konfigurasjon ikke mistes. Det må være enkelt å laste inn konfigurasjon, og det må være enkelt å overstyre konfiguarsjon.
- Namespacing i konfigurasjon
Det må være mulighet og standard for namespacing av innstillinger.
- Navnerom for funksjonalitet
- Navnerom for konfigurasjon av LDAP-eksport
- Navnerom for konfigurasjon av AD-eksport
- Navnerom for moduler
- Navnerom for posix-innstillinger
- Navnerom for innstilling av gjestefunksjonalitet
- Splitte konfigurasjon
- Det må være enkelt å dele opp konfigurasjon i flere, ulike filer – gjerne i en fil per. modul eller målsystem.
- Mulighet for validering av konfigurasjon
I stedet for en 'default config', bør det finnes en spesifikasjon som oppgir:
- Hvilke innstillinger som eksisterer
- Hvilke innstillinger som er obligatoriske
- Hva som er standardverdi for innstillinger
- Hvilke verdier som er gyldige for innstillinger.
En slik spesifikasjon må kunne utvides av eller oppgies i moduler.
Ved innlasting av konfigurasjonsfil bør det være mulig å kjøre en 'sanity-check' på konfigurasjonen:
- Er alle obligatoriske innstillinger konfigurert?
- Finnes det ulovlige verdier for innstillinger?
- Mulighet for maskinlesbar dokumentasjon
- Det bør være mulighet for å dokumentere innstillinger. Det bør gjerne kunne gjøres i en spesifikasjon, som nevnt over.
Forslag
- Ett globalt konfigurasjonsobjekt
- Navneromsfunksjonalitet
- All konfigurasjon hentes ut via objekt
- Støtte for å validere konfigurasjon
- Abstrakt modul-spesifikasjon
- Støtte for spesifikasjon
- Støtte for dokumentasjon
- Støtte for standardverdier
- Støtte for validering
- Implementasjon av modul-spesifikasjon
- Inneholder spesifikasjon
- Inneholder standard-filnavn
- Kan overstyre abstrakt modul-spesifikasjon
- Konfigurasjonssøk
- Lete etter konfigurasjon på gitte steder
- Unngå å måtte oppgi konfigurasjonsfil
- Mulighet for å oppgi egen konfigurasjon for relevant navnerom ved kjøring av script eller oppstart av tjeneste.
Ved innlasting av modul, vil modul-spesifikasjonen legges inn i det globale konfigurasjonsobjektet.
I tillegg bør det gjøres en gjennomgang av konfigurasjonsinnstillinger:
- Trengs innstillingen?
- Har vi gode default-verdier?