Statusmøte for NIKE

Tidspunkt: Torsdag 26. september 2013 14:00 - 15:45 Tilstades: jazz, jsama, iv, baardj, jokim

Referent: jokim

Agenda

Statusmøte for NIKE.

  • Over-all status for Cerebrum-aktiviteter v/Jasmina

  • Status for postmaster-aktiviteter v/Ingar & Bård

    Vi trenger å vite om evt. snags/endringer i tidsplan, samt om funksjonalitetetsendringer. Hper dere har mulighet til å gi oss en slik oppsummering.

  • Avslutning valg av kommunikasjonsform v/Jo

  • Gjennomgang API-funksjoner (det Cerebrum må støtte for å kunne gjøre oppdateringer på Exchange) v/Jasmina

  • Arbeidsflyt (kort diskusjon)

  • Plan uke 40 + 41

  • Kvoter

  • Eventuelt

Status frå jazz

Prosjektet er 9 dagar på etterskot, grunna sjukdom, og avgjersler som har tatt lenger tid enn planlagt.

Vart spurd om det kan gjerast noko for å hente igjen denne tapte tida. Det ser ikkje ut til at det er noko mulighet for det. Vi må gå gjennom og revurdere planen om to veker.

Aktiviteten rundt hendelseslogg er utsatt til neste veke.

Status frå iv

  • martbo har jobba vidare med e-post-infrastrukturen.

  • Notes-integrasjon ser ut til å bli meir og meir komplisert enn tidlegare antatt. Dette er grunna kompleksitet i e-postsystemet og ikkje integrasjonsløysinga.

  • Servermaskinene begynner å komme i neste veke. Veit ikkje kor lang tid det vil ta med første synkroniseringa av all e-post, men ser ut til å ta 2 til 4 veker. USIT i første runden er ikkje så stor andel i total storleik, men har ein stor del når ein tel antal e-postar - USIT har mange, men små e-postar.

    Minne var billegare enn antatt, så har kjøpt mykje minne for maskinene. Det betyr at Exchange vert kjappare, då det bruker minne effektivt.

    Ser for seg å bruke ein DAG for alle 8 maskiner. Dette har ingen konsekvensar for Cerebrum.

    Passord for brukarane i AD, kva skjer med dei? Cerebrum skal ikkje trenge å måtte sette passord på brukarane til mailboksane.

  • Besluttinga om å ha eige ressursdomene skal bli tatt opp (på nytt?), så vi har det "offisielt".

  • Har vore ein diskusjon rundt studentar, om dei skal i skya eller ikkje. NIKE-prosjektet sitt svar er at vi ikkje kan bruke sky-løysing då det vil koste for mykje og kreve for mykje ressursar, og er lite ønske om det. Øker kompleksiteten i løysinga, men ikkje for administrasjonen. Studentar skal difor ikkje i skya, i alle fall enn så lenge. Midlertidig konklusjon no er også at alle skal migrerast til Exchange, og ikkje berre ansatte. iv planlegger difor ikkje meir om konføderasjon og anna som er relatert til dette.

Status frå jsama

Jo har utreda om vi skal bruke ssh eller winrm. Vi kan bruke ssh, men trur ikkje det er noko lurt. Det virka lite robust, og var vanskeleg å få det opp skikkeleg. Det vert ein grisete transport, spesielt fordi vi ikkje får returkodar, men må leite etter output i svar.

I test tok det i gj.sn. litt over 2 sekund å opprette mailboks med ssh, men 1.84 sekund med winrm.

Har også testa med tråding av WinRM, då tok det 0.5 til 0.6 sekund per brukar når det var 10 opprettingar i parallell.

For å køyre i parallell for python2.5 trengs det å installerast ein python-modul. jokim kan høyre med trondham om å få dette på plass.

Springbrettmaskina er ei virtuell maskin. Denne kan spekkast opp etter behov.

Vi konkluderer med å ikkje lenger sjå på SSH, men gå for WinRM. Så bruker vi ikkje meir tid på dette.

Cerebrum Exchange-API

WinRM.py er litt for hardkoda, så har vurdert å refaktorere den til å vere meir likt som resten av Cerebrum-koden - snakke med andre system på Cerebrum sin standard måte. Vart vurdert fram og tilbake, og det er ønskeleg å refaktorere, men prosjektet har ikkje tid til det. Enkle metodar i modulen kan bytte namn, men har ikkje tid til meir avanserte endringar. Dette må settast på kontoen "teknisk gjeld". Om vi ein gang skulle kunne få ein powershell-modul, veit vi uansett ikkje korleis den vil fungere, så må uansett tilpasse då.

Diskuterte gruppetyper: Blant anna skopet - lokal, global og universell. Diskuterer ikkje dette her.

Spørsmål om det er meir Cerebrum skal vite om Exchange. Er mange ting som kan vere ønskeleg, men er utanfor skopet i dag, men kanskje i framtida. Kan vere ønskeleg i framtida å ha behov for å styre rettigheter på rom - skal styre dette via grupper, ser det ut til. Vart også nemnd noko søkefunksjonalitet som Cerebrum kunne populert.

Jasmina spurde om funksjonane som trengdes på Exchange-sida. baardj og iv svarer:

  • Ny brukar: treng ikkje fornamn og etternamn, slikt skal hentast frå hovuddomenet.

  • Ny adresse/alias: Er nokre utfordringar rundt primær og resten av adressene. Usikkerhet rundt bordet kva som er riktig. Dette må sjekkast først.

  • Koble mailboks til/frå brukar: Kan det oppstå to mailboksar for ein brukar? Ja, det kan skje, og vi må hindre dette. Ved oppretting må difor Cerebrum sjekke om det finnast ein disabled mailbox før den oppretter ein mailbox. Denne funksjonen skal berre brukast ved disable/enable.

  • Kvoter: Fungerer som i dag. Finnast ikkje unlimited som eit valg, skal heller ikkje ha dette. Vil at alle skal ha eksplisitt kvote, for å unngå at nokon kan ødelegge for andre i samme datatabase.

    Sidesprang: Dersom ein database vert full vert e-post køa.

  • Synlighet: Er eit ønske å gjere alle som ikkje er primærbrukarar usynlege. Konsekvensen er berre at dei andre brukarane ikkje vert med i adressebøkene, men du kan framleis sende e-post til alle brukarane om du har adressene.

    Skal det vere noko samanheng mellom synlighet og reservasjonar frå synlighet? Bård seier ja, han har spurd oppover, og skal ta hensyn til dette i denne katalogen. Er klar over at dette gjer det forvirrange for folk, men vi må enn så lenge vi har reservasjonsopplegget gjere det slik.

  • Deaktiver bruker: Betyr å koble frå mailboks? Det betyr at Cerebrum må kalle ein kommando som postmaster har. Ein postmaster-modul.

    "Deaktivering" betyr flytting av mailboksen - kan ikkje "deaktivere" mailboksar.

    Dette skal skje når brukaren har blitt avvikla eller har mista spread til Exchange. Sjølve slettinga skal gjerast av postmaster, inkludert backup, det skal Cerebrum ikkje gjere noko med anna enn å deaktivere.

    Kva med forwards? Gjere som i dag? iv og baardj litt uenige om dette, så vart diskutert. Skal forwards leggast inn både i MX og Exchange? Usikker. Kan ikkje ha forwarding to stader i systemet, så må fjerne forwards frå LDAP (MX) og berre ha det i Exchange. Om det ligg begge stader vil vidaresendingar, i følge iv, bli sendt to ganger til brukaren. Cerebrum må difor patche LDAP-mail-eksporten.

    Når ein mailboks vert sletta kan vi opprette ein mailboks med samme brukarnamn utan at det er noko samanheng med den gamle mailboksen.

Grupper

Funksjonalitet for grupper.

Kan ikkje snakke om grupper, det er for stor skilnad i Exchange. Treng då å snakke om distribusjonsgrupper og sikkerhetsgrupper som to forskjellige ting.

  • Ny gruppe: Ønsker å ha to forskjellige funksjonar, ein for dist.gr. og ein for sikkerhetsgrupper.

  • Tillate å skifte adresse på ei gruppe? Postmaster trur det, men jazz er skeptisk til konsekvensane av å endre adresser til objekt. Postmaster endrer adressene til lister i dag - gjer det ofte før listene vert tatt i bruk, men også ved omorganiseringar. Gjer kanskje ei slik endring annakvar veke.

    Må då ha mulighet til å endre adresser til grupper.

    Gruppenamnet vil vere ein av adressene til gruppa, men vil også ha behov for alias.

  • Kan ikkje koble mailboks til/frå grupper. Grupper i ressursdomenet er native, så har ikkje slike koblingar, det er berre i Cerebrum.

    Har rundt 25 "custom" attributtar som kan brukast til det vi vil.

  • Endre gruppestatus: Open og closed. Closed betyr at folk ikkje kan melde andre inn og ut av gruppene. Vi bør likevel ha det tilgjengeleg som ein funksjon for å seinare kunne tillate dette. Gruppene har basis listefunksjonalitet, som kan brukast av brukarar.

    Heng litt saman med rom.

    Treng å diskutere dette meir.

    Må ha ein spesifikasjon på dette før vi kan gjere noko meir om dette. Til dømes kva det betyr å vere moderator, eigar og administrator av ei gruppe.

    Årsaken til å ha grupper her er for å gjere det enklare å kalle inn folk til møter. Det er ikkje meininga at gruppene skal bytte ut Sympa, men det kan hende at folk likevel bruker det annleis enn det vi ønsker. Dersom vi går for langt må vi kanskje utsette å ta distribusjonsgrupper.

    Tek det tekniske no, men det med policy kan vi ikkje ta her, i dette møtet.

    Bør vi ta dette opp litt oppover i ledelsen, då det kan vere ønskeleg å vite meir om grupper, td. kor dei høyrer til. Det er ikkje noko vi kan ta oss av.

    baardj trur vi treng ein eigen mail-moderator i Cerebrum, for å moderere grupper i Exchange.

  • OU: Skal grupper kunne flyttast mellom OU-ar i Exchange? Nei.

  • Deaktivering: postmaster gir Cerebrum eit skript som skal køyrast.

  • Ingen kvoter på grupper, då dei har ingen mailboks. Har heller ikkje noko arkiv - det er sympa.

Oppsummert: Begynner å nærme oss ferdig med API-et, kanskje 80%.

Arbeidsflyt og kvoter

Har ikkje tid til å gå i detalj her, då vi ikkje hadde meir tid.

Kort fortald, lager ein "fattigmanns event-løysing" ved å logge til ein annan tabell og bruke denne. Skal ha eit eige møte på dette i neste veke. Kjem fort inn i espegro- og felton-mat, så dei skal vere med på møtet. baardj er på haustferie, men går greit at han ikkje er med på akkurat det møtet.

Publisert 4. okt. 2013 17:16