Innhold
1 Filer
Relevante filer som treng å oppdaterast:
- adconf.py - Konfigurasjon for AD-synken.
- cereconf.py - For å inkludere AD-modulen for entitetar, samt AD-konstantar.
- config.dat - For å ta i bruk AD-kommandoar i bofh, dvs. Cerebrum.modules.ad2.bofhd_ad_cmds/BofhdExtension.
- logging.ini - Ekstra AD-synkar bør ha eigne log-filer, sidan alle jobbane kan gå i parallell. Legg til nye handlers, og bruk namna i scheduled_jobs.
- scheduled_jobs.py - For å køyre AD-synken regelmessig. Hugs å sette opp både fullsynk og hurtigsynk.
Andre relevante filer:
- contrib/ad/ - Her finn du skripta for AD-synken.
2 Konfigurasjon
2.1 Logging
Dei ulike synkane bør skillast med forskjellige loggar, så det vert enklare å feilsøke. Dette kan gjerast ved å legge til parameteret --logger-name. Døme på scheduled_jobs.py:
contrib/ad/sync.py --logger-name ad_somethingsync
Dette må då gjenspeilast i logging.ini:
[logger_ad_somethingsync]
level=DEBUG
propagate=1
qualname=ad_somethingsync
handlers=hand_ad_somethingsync
[handler_hand_ad_somethingsync]
class=CerebrumRotatingHandler
level=NOTSET
formatter=form_cronjob
args=(os.path.join(cereconf.LOGGING_ROOT_DIR, "ad/"),
'a+', 2*1024*1024, 20, 'utf-8', '', 'somethingsync.log')
2.2 cereconf
AD-klassane treng å bli tatt i bruk, så nokre av CLASS_-variablane må oppdaterast:
CLASS_CONSTANTS.append('Cerebrum.modules.ad.Entity/ConstantsActiveDirectory')
CLASS_ENTITY.append('Cerebrum.modules.ad.Entity/EntityADMixin')
For å ta i bruk passordkryptering med GnuPG må en sette:
PASSWORD_GPG_RECIPIENT_ID = '<key-ID>' PASSWORD_GNUPGHOME = '<gnupg homedir>'
der key-ID er identifikatoren (fingerprint) til offentlige nøkkelen og gnupg homedir er hjemmekatalogen til GnuPG (vanligvis: ~/.gnupg)
Eksempel:
PASSWORD_GPG_RECIPIENT_ID = '5251960EFF43EAF600656B3C4752B4E2DD340B15' PASSWORD_GNUPGHOME = '~/cerebrum/.gnupg'
2.3 adconf
Fila adconf.py er AD-synken si eiga konfig-fil. Denne må oppdaterast i henhold til det instansen spesifiserer.
Sjå Bestilling av ei AD-synkronisering for korleis spesifisere opp AD-synk for ein instans.
Vi har som mål at alle AD2-synkar skal vere spesifiserte opp før første synk går.
Sjå Stash: Cerebrum/config/adconf.py for standard-innstillingar og meir utfyllande forklaringar.
Grovt sett skal fila innehalde ein dict SYNCS, som inneheld eitt element med innstillingar for kvar AD-synk som skal køyre. Døme:
SYNCS['account@ad'] = {
'domain': 'kaos.local',
'search_ou': 'OU=Users,OU=Cerebrum,DC=kaos,DC=local',
...
}
SYNCS['group@ad'] = {
'domain': 'kaos.local',
'search_ou': 'OU=Groups,OU=Cerebrum,DC=kaos,DC=local',
...
}
3 Installasjon
Etter at Cerebrum er ferdigkonfigurert og filer er oppdaterte.
3.1 Før første synk
Oppdater til siste versjon av Cerebrum.
Oppdater konfigurasjonen.
Oppdater databasen for AD2:
python makedb.py design/mod_ad_attributes.sql python makedb.py --only-insert-codes
Restart bofhd og andre webservices.
Du kan sjekke at bofhd har støtte for AD-attributtar ved å logge på og køyre:
ad attributetypes
som skal gje deg ei liste over definerte attributtar som kan settast.
3.2 Ved første fullsynk
Det er då tid for å køyre ein initiell synk mot AD. Denne kan enten køyrast gjennom job_runner, eller så kan den køyrast manuelt utanfor.
Den initielle synken må køyrast litt forskjellig avhengig av om vi skal synke mot eit heilt nytt AD-miljø, som vi då ikkje kan gjere noko skade i endå, eller eit eksisterande AD-miljø der vi står i fare for å ødelegge objekt i produksjon.
3.2.1 Initiell synk mot eit nytt AD-miljø
Eit nytt AD-miljø treng ikkje å sjekkast på førehand.
Avklar at det er ok å synke med instansen.
Køyr synken:
python ~/src/cerebrum/contrib/ad/sync.py --type SPREAD --logger-name SYNCTYPE
Dette vil kunne ta lang tid, avhengig av kor stor instansen er. For større instansar kan dette ta over 24 timar! Ein tommelfingerregel er 3 sekund per entitet.
Send ei liste over kva endringar som er blitt gjort til instansen, og legg ved tal over kor mange entitetar som er lagt over.
Vent på ein ack frå instansen før vi kan godkjenne synken som fungerande. Den kan då settast opp i scheduled_jobs.py.
3.2.2 Initiell synk mot eit eksisterande AD-miljø
I eksisterande AD-miljø må vi trå litt meir varsomt, sidan vi kan risikere å ødelegge produksjon.
Avklar at det er ok å synke med instansen.
Køyr synken i dryrun:
python ~/src/cerebrum/contrib/ad/sync.py --dryrun --type SPREAD --logger-name SYNCTYPE
Send ei liste over kva endringar som ville blitt gjort til instansen, og legg ved tal over kor mange entitetar som skulle blitt lagt over.
Det er spesielt viktig å legge ved alle forsøk på sperring, sletting og flytting. Dette så instansen kan sjekke at vi ikkje får noko til å stoppe opp.
Når instansen har godkjend endringane kan synken køyrast på skikkelig:
python ~/src/cerebrum/contrib/ad/sync.py --type SPREAD --logger-name SYNCTYPE
Send ei liste over kva endringar som er blitt gjort til instansen, og legg ved tal over kor mange entitetar som er lagt over. Instansen kan då sjå over AD-miljøet, og samanlikne med bofh.
Vent på ein ack frå instansen før vi kan godkjenne synken som fungerande. Den kan då settast opp i scheduled_jobs.py.
3.3 Ved første quicksynk
Quicksynken til AD2 henter ut alle hendingar tilbake i antalet dagar som er definert i changes_too_old_seconds. Default er satt til mange dagar, så det vil ta lang tid å køyre første synk, og vil kunne gje ein del feilmeldingar for utdaterte data.
Oppdater change_handler før første køyring:
UPDATE change_handler SET last_id = XXX WHERE evthdlr_key = 'YYY' and first_id = -1;
der XXX settast til første change_log_id du vil at synken skal utføre, og YYY er CL_NAME, altså namnet på den spesifikke change-handleren som synken skal bruke.
Dersom første quicksynk skal gå mot eit eksisterande miljø, må ein også her køyre i dryrun først, og få instansen til å godkjenne endringane.