- Tid: 27. juni 2013 15:00 - 16:10
- Tilstade: baardj og jokim
Telefonmøte for å gå gjennom dokumenta for utgreiing og overordna spesifikasjon for integrasjon mellom Cerebrum og Exchange for UiO. Overordna spesifikasjon er ikkje ferdig endå, men går gjennom det som er fullført, og ser på nokre avklaringar som trengs.
Agenda for møtet vart inndelt etter dei forskjellige dokumenta som er utarbeida.
Dokument: Eksisterande funksjonalitet i Cerebrum for e-post og Exchange
baardj: Er greit at vi berre har eitt target per brukar, men treng då ein måte å markere brukarar for migrering, td. ein bofh-kommando. Dette kan til dømes vere ein trait på brukaren eller spread. Må kanskje tillate at brukaren får ei e-postadresse, trur ikkje vi kan opprette mailboks i Exchange utan e-postadresse, men det skal baardj sjå på. Alternativt kan vi gje ei e-postadresse i eit eige domene berre for exchange sine mailtargets som ein workaround.
Treng eit eige Exchange-spread, i tillegg til vanleg AD-spread. Er usikker på når vi skal sette spread, før eller etter migreringa.
Postmaster treng uansett bofh-kommandoar:
For å markere ein brukar som under migrering.
Denne kommandoen bør avviklast rundt jul, når migreringa er fullført.
For å sei at ein brukar skal bytte mailtarget til Exchange.
Skal avviklast rundt jul, når migreringa er fullført og alle er over på Exchange.
Ein eigen kommando for å opprette ein ny mailboks for dei som ikkje har det. Eventuelt gjerast på samme måte som spread add for IMAP i dag, men då med ein annan synk.
Bård ønsker å avvikle BofhdRequest sidan køing vert vanskeleg for avhengigheter i e-postsystemet, og dei veit ikkje når ting vil skje eller har skjedd. I staden for treng kommandoane å bli eksekvert direkte, dvs. kommandoen utfører kall mot Exchange. Dette vil føre til at ein kommando tek lenger tid, og det vil då eventuelt vere mulig med ein eigen bofhd for postmaster. Bård ønsker sterkt at bofh-kommandoar skal snakke med Exchange direkte.
Kommentarar frå Bård
- EmailDoman: Er FQDN.
- email_add_domain_affiliation og email_remove_domain_affiliation gir knyttinga mellom affiliation og domenet.
Alias
Håpet er framleis å bruke smart-host, så slepp då å legge alias i Exchange, men berre la MX-en ta seg av dette. Ser ikkje ut til å vere teknisk umulig, men må kanskje gjere nokre innstillingar i Exchange.
Konsekvensen er ingen alias for brukarar, men det er framleis likevel sterkt ønskeleg for grupper, sidan dette trengs i adressebøker. Aliasar skal uansett berre leggast i eitt felt, proxyAddresses, som ikkje er komplisert når vi først har eit mailtarget. Likevel, det betyr at Exchange må oppdaterast kvar gang slike adresser endrast (jokim, etter møtet: Men dette kan vel fullsynken ta seg av, og ikkje måtte gå direkte).
Vi legg difor inn alias i Exchange uansett, for både grupper og brukarar, uavhengig av korleis opplegget rundt MX og smart-host vert. Det er visstnok ikkje noko problem om aliasar eksisterer i Exchange utan at dei skal brukast.
Oppdateringsskript
baardj vil ikkje bruke Update-Recipient, men heller New-Mailbox og relaterte kommandoar direkte. Eventuelt kan vi kalle på eigne skript hos postmaster. Postmaster kan då definere kva dei vil at skal køyrast, utan å måtte involvere Cerebrum, og det vert mindre arbeid for Cerebrum.
Distribusjonsgrupper
Må gå nokre runder til for å finne ut av kva namn vi skal sette.
Må også sjå på policy rundt slike grupper, til dømes antal brukarar. Til dømes at grupper med ein viss storleik må modererast. Kor stor skal ei gruppe vere, eller kor i strukturen skal den vere?
Ønsker at Cerebrum gjer dette og ikkje postmaster sine eigne skript. AD veit ikkje kva gruppe som er moderator, så postmaster kan ikkje gjere innstillingane (jokim, etter møtet: eventuelt kan postmaster kalle på ein cerebrum-kommando for å markere ei gruppe for moderering? Så kan dei ta seg av algoritmen for avgjersla, medan Cerebrum gjer berre det som trengs i AD). Moderatorgruppa i Cerebrum må då også vere distribusjonsgruppe, eventuelt må medlemma leggast til i Exchange for moderering som ei liste eller som enkeltbrukarar.
Moderatorar er i AD lista ut som brukarar, men forum på nettet seier at vi likevel kan sette grupper, og då få oppdatert moderatorlista dynamisk på bakgrunn av gruppemedlemma.
Dokument: Notatar om Exchange 2013
Update-Recipient er nok ikkje vegen å gå, men er nok riktig veg å gå å heller køyre powershell-skript for oppdatering.
Attributtar kan oppdaterast som i dag, men må sjå meir på korleis linked attributes fungerer.
Vi må nok utvide hovud-AD-en med ekstra attributtar. Må nok utvide den eksisterande AD-synken med slike attributtar, vi kan ikkje vente på at hovuddomenet skal få ny AD-synk, då verken UAIT eller KIA har ressursar til dette med det første.
Alt av rom bortfaller.
Adressebøker bortfaller mest sannsynleg også, men må komme tilbake til det seinare. Årsaken er at postmaster ikkje er sikker på korleis det skal gjerast endå, til dømes veit ikkje korleis Department skal kunne gjerast hierarkisk nok, for UiO. Kva subsett av vår OU-struktur skal vi ha adressebøker? Kan vurderast å ha eit tal på dette, til dømes 200. Dette må vurderast, vil alltid vere avvik mot dette, så må ta det vidare. Vil ha mange adressebøker, men kan ikkje ha for mange, som då vert rotete.
Dokument: Overordna spesifikasjon for innføring av Exchange for Cerebrum-UiO
Alt med Data Availability Group (DAG) skal ut, det var noko heilt anna enn det postmaster trudde.
Namnekollisjonar: Går for ei mellomløysing mellom alternativ 1, alle distribusjonsgrupper får i utgangspunktet ei adresse i domenet @grupper.uio.no, men postmaster skal ha muligheten til å gje gruppene aliasar. Vi unngår då namnekollisjonar for gruppenamna, men postmaster har samtidig muligheten til å gje gruppene andre adresser i tillegg.
Det vil då ikkje lenger behov for å begrense grupper sitt namnerom eller e-postlister, som er bra for grupperommet. Namnekollisjonar i e-postadresser behandlast akkurat som i dag. Det er likevel behov for EmailTarget for grupper, sidan vi treng alias.
Det er nokre utfordringar med å få satt EmailTarget for grupper. Det finnast litt funksjonalitet i e-postmodulen som berre kan brukast for brukarar, og vi må gjere litt endringar her. jokim har ikkje funne ut korleis det skal løysast, om vi lager ein eigen MailTarget-type eller kan gjenbruke mailtarget for vanlege brukarar.
Må framleis sjå på eventuelle kollisjonar for pipe og andre typar.
Treng ikkje sjå på namn på e-postlister ved oppretting, fordi vi har eige domene for gruppene, og aliasar vert behandla som alle andre for kollisjonar, som er på databasenivå, evt. også i API-et.
Maildatabasar: Spørsmål om korleis mdb skal administrerast, dynamisk vha. ein kommando, eller hardkoda i cereconf. Det er ønskeleg, og minst arbeid, for Cerebrum å legge dette i cereconf. Cerebrum drift må då bli bedt om å legge til og fjerne databasar ved behov. Dette kan vere godt nok, sidan det ser ut til at mdb-ar ikkje vert oppdaterte så altfor ofte, med unntak av i startfasen. Andre kan likevel ha meiningar om at dette må skje meir dynamisk, til dømes iv. Må komme tilbake til dette.
MailServer ser ut til å ikkje lenger trengast for AD. Det trengs likevel eit servername i EmailTarget, som sendast til mail-LDAP, dvs. til MX-en.
Opplegget skal vere slik at MX-en berre snakker med ein tilfeldig CAS-server, som tek seg av e-posten vidare til riktig server. I EmailTarget kan vi då berre sette opp den første CAS-serveren, og set opp MX-en til å ignorere dette feltet. Bård gir oss ein verdi vi kan sette.
Alt om kvoter gjenbrukast direkte frå cyrus, utan endringar.
Treng å sjå på vising av kvoter i bofh/Brukerinfo. Powershell er treigare enn Cyrus, så det vil gjerne ikkje vere brukbart å hente dette direkte i email info lenger. Må sjå på korleis vi gjer dette for Exchange.
Dokument: Spesifikasjon av AD-synk for brukarar i Exchange ved UiO
Det meste skal køyrast via powershell mot ressursdomenet.
Vi vil også måtte utvide den gamle, eksisterande AD-synken, med fleire attributtar, som td. OU. Dette må også spesifiserast, men det bør helst ligge i eit eige dokument, sidan dette dokumentet berre skal omhandle ein synk.
Cerebrum gjer ingenting med sjølve migreringa av mailboksane, heldigvis. Det vert tatt på postmaster-sida. Altså kopieringa av data frå cyrus til Exchange, og seinare frå ein stad i Exchange til ein anna mdb.