Denne siden er arkivert, og kan inneholde utdatert, gammel eller feil informasjon.

Kortsys 2

[VIKTIG, LES]: HISTORISK, IKKE BRUK DENNE!!!111

Kortsys er systemet som sørger for at RiTA (Windows-systemet som er koblet opp mot kort-undersentralene og i tur dermed dørene) inneholder omtrent samme informasjon som MDB2 (MedlemsDB2). Dokumentasjonen her gjelder Kortsys 2.1; vi har ingen rigid releaseprosess på Kortsys (som med resten av MedlemsDB), men versjonsnummeret bounces nå og da hvis man føler man har gjort en viktig nok strukturell endring.

Kortsys 1 fungerte ved en haug triggere som sørget for å markere ting til oppdatering i RiTA. Kortsys 2 fungerer annerledes; KS2 vedlikeholder en liste i PostgreSQL over hvordan den tror RiTAs interne tilstand ser ut, genererer en liste over hvilke tilganger folk skal ha ihht. MDB2, og sørger så for å dytte ut endringer nok slik at RiTA- tilstanden blir lik som MDB2.

De to metodene har fordeler og ulemper; diskutér. Minst fem sider. Til mandag.

Generell virkemåte

RiTA (som er et VB3-program med abnorme mengder kompleksitet og omvendt proporsjonal mengde ytelse og brukervennlighet) har ingen direkte måte å oppdatere på; ARX skal få et HTTP/XML-basert grensesnitt og man kan i teorien nevle direkte i Btrieve-databasen tingen er bygget på, men vi bruker heller «inn/ut»-modulen til import. (Vi har dog måter å hente data tilbake på for debugging – se ATIR.)

Inn/ut-modulen henter to spesielle CSV-filer fra et Samba-share (i ~rita/mdb2/kortsys2) hvert N. minutt, der N=5 for tiden. Den behandler deretter filene, oppdaterer databasen, sørger for å køe opp endringer til undersentralene og sletter filene. (Dersom den bruker lenger enn N minutter på faktisk å prosessere filene, får man – i noen tilfeller – merkelig oppførsel. KS2 begrenser antall oppdateringer per runde for å prøve å unngå dette.)

Det er to forskjellige filer som har forskjellig oppførsel, og leses i rekkefølge:

person.csv: Sørger for å legge til nye personer i databasen.
kort.csv: Sørger for å fjerne personer (og automatisk alle tilhørende kort) fra databasen (operasjonen B), legge til tilganger på kort ( C, som også automatisk oppretter et kortet dersom det ikke finnes) samt fjerne tilganger fra kort ( D )

person.csv leses før kort.csv, så man kan ikke både fjerne en person og legge til vedkommende på nytt i samme runde.

For mer detaljert informasjon om hva de forskjellige feltene betyr, se RITA inntil videre (dvs. permanent). :-)

Kortsys 2

Kortsys 2 kjøres hvert minutt som brukeren rita fra cirkus (siden den er databasetjener; det kunne dog fint kjørt på cassarossa om vi hadde ønsket). For å unngå å miste data, avslutter den umiddelbart om person.csv eller kort.csv allerede finnes. (Det er dog ett unntak – hvis filene finnes men bare inneholder dummy-data, overskrives de allikevel. Dummy-data er nødvendig å dytte ut når man ikke har noen endringer, da inn/ut-modulen stopper opp med en dialogboks om den ikke finner filene.)

Kortsys 2 er formulert i en kombinasjon av Perl og SQL; med noen få unntak er Perl-scriptet og tilhørende modul en tynn wrapper rundt SQL-viewene (som ligger i SQL-skjemaet _kortsys2_; det kan refereres til .sql-filene i Arch for mer dokumentasjon om det skulle være ønskelig).

Begynnelsen av det hele er en PL/PgSQL-funksjon med det velklingende navnet mdb_gruppekobling_transitiv_tillukning som beregner hva som arver fra hva (dvs. løser opp i arv) – dette er ikke mulig å gjøre i ren SQL, så det kan ikke være et view. Denne leser fra tabellen gruppekobling og finner den transitive tillukningen av gruppegrafen, dvs. sørger for at hvis stien A -> B -> C finnes (der "->" betyr "er undergruppe av"), finnes også kanten A -> C.

Funksjonens output kobles sammen med gruppe, adgangsskjema og adgangsskjema_gruppe_kobling i viewet mdb_gruppetilgang. Dette viewer sier hvilke grupper som skal ha tilgang til hvilke dører, etter at arv er tatt hensyn til, og etter at inaktive grupper er luket ut.

Dataene fra mdb_gruppetilgang slås så sammen med data fra tabellen verv for å gjøre om fra «hvilke grupper har tilgang hvor» til «hvilke personer har tilgang hvor». På dette tidspunktet fases også eksterne kort (f.eks. vaskekort, glassrydderkort, osv.) inn i systemet, og det gjøres en sjekk mot mdb_personer (et annet view, som er generert på basis av kort, verv og viewet gyldige_medlemskap, som igjen er basert på medlem, kort og oblat) for å sikre at alle som har tilgang faktisk er berettiget til det, mht. at de trenger et gyldig kort å ha dørtilgang på, at de har en PIN-kode og at de har et gyldig medlemskap. Alt dette tas inn for å beregne en utløpsdato for hver tilgang, og det mates ut i viewet mdb_tilgang.

Dataene fra mdb_tilgang kjøres så over i viewet mdb_effektiv_tilgang, som inneholder akkurat samme informasjon, men uten duplikater. Man kan f.eks. fint ha tilgang til 4. etasje både i kraft av å være ITK-funk og UKA-IT, og mdb_tilgang vil gi to forskjellige linjer her, med hver sin start- og sluttdato. mdb_effektiv_tilgang plukker den av tilgangene som varer lengst, og dytter ut den.

Når man så har både ønsket liste over personer (mdb_personer) og tilganger (mdb_effektiv_tilgang), kan man sammenligne med RiTAs tilstand og dytte ut riktige linjer i person.csv og kort.csv. Dette er i prinsippet en ren diff, bortsett fra at startdatoer i fortiden regnes som like uansett. (Dersom du har vært med i UKA-IT siden 2003 og ITK siden 2004, og UKA-IT plutselig ikke lenger har tilgang til 4., er det strengt tatt ikke så veldig interessant å oppdatere startdatoen din for tilgangen til 4. fra 2003 til 2004 i RiTA, så det gjøres ingen oppdateringer der.) Diffingen skjer i viewene personer_skal_eksporteres, personer_skal_slettes og tilganger_skal_endres. (Av ytelseshensyn beregnes innsetting og fjerning av tilganger i ett view i stedet for to, men ettersom innsetting og fjerning av medlemmer skjer i to pass er dette i to views og ikke ett.)

Filene dyttes så ut til RiTA-katalogen, som nevnt over, og den interne tilstanden oppdateres i håp om at RiTA faktisk vil oppføre seg som man forventer. :-)

Anoreksia (Når rita dør)

Det er ikke fint når rita dør på seg. Hun kommer ikke opp av seg selv, og trenger hjelp. For at noen skal bli oppmerksomme på at rita har det vondt, sjekker en cronjobb på cassarossa om filen kort.csv finnes, og om den er eldre enn en time. I såfall er det rimelig å tro at rita har det vondt, og vi får e-post. (Om RiTA trenger mer tid enn de oppsatte fem minuttene på å tygge dumpen, vil hun gå i frø uansett, siden hun vil begynne å tygge den samme dumpen på nytt før den første er ferdig.)

Lenker: Start, gammel dokumentasjon