Innhold
1 Bakgrunn
Informasjon tilknyttet DNS, DHCP, subnett, VLAN og CFEngine kan lagres og vedlikeholdes i Cerebrum. Subnett-data kan importeres, og det meste av DNS-relatert informasjon eksporteres i ulike jobber. Løsningen ble opprinnelig laget for bruk i Cerebrum på UiO, under navnet DNSInfo.
Løsningen har blitt utvidet og endret på over tid, hvor en av endringene var å ta i bruk løsningen også i TSD. På UiO har DNSInfo og tilhørende funksjonalitet blitt erstattet med mreg, mens TSD fortsatt benytter seg av Cerebrum for dette.
2 Oversikt over DNS-funskjonalitet i Cerebrum
2.1 Host
Nesten helt fra start har Cerebrum hatt støtte for å lagre informasjon om hostnavn i Cerebrum. Dette er en del av kjernefunksjonaliteten i Cerebrum, og fremdeles i bruk, bl.a. for å registrere hoster som benyttes til f.eks. nettverksdisker og epost-tjenere.
Informasjonen er ikke DNS-relatert, og blir kun registrert for å knytte sammen:
- brukerkonto til hjemmeområde/disk-tjener
- epostkonto til innboks/epost-tjener (mod_email)
2.2 E-postdomener
mod_email inneholder også en oversikt over domemenavn som (kan) benyttes i e-postadresser. Denne funksjonaliteten er ikke direkte knyttet til hverken DNS eller Host.
Domener eksporteres til to ldap-trær.
2.2.1 mail-domains
- LDAP
- cn=domains,cn=mail,dc=uio,dc=no
- LDIF
- mail-domains.ldif
- Script
- contrib/generate_mail_domains_ldif.py
Inneholder en liste over domener for e-post i Cerebrum. Denne eksporten vil ikke påvirkes av endringer i DNS.
2.2.2 mail-dns
- LDAP
- ou=mail-dns,dc=uio,dc=no
- LDIF
- mail-dns.ldif
- Script
- contrib/generate_mail_dns_ldif.py
Inneholder informasjon tilsvarende mail-domains, men med noen ulikheter:
- Gruppering
- LDAP-objekter grupperes, slik at alle CNAMEs samles i samme LDAP-objekt som hostnavn.
- Filtrering
Alle LDAP-objekter blir sjekket mot DNS - dersom et domene mangler gyldig MX-record vil eksporten stanse opp, og ingen endring skjer i LDAP-treet.
Alle MX-record sjekkes mot domene - dersom det finnes en MX-record uten tilhørende domener vil det logges et varsel.
Merk at DNS-data her ikke hentes fra Cerebrum, men hentes med zone transfer fra navnetjenerene for uio.no, usit.no, og ifi.uio.no!
Heller ikke her vil endring/fjering av DNS-moduler ha noen innvirking, men vi bør kanskje snakke med postmaster om veien videre for e-postdata i Cerebrum.
Det skjer oftere at mail-dns og DNS er ute av synk etter at mreg har tatt over ansvar for DNS-data. Dette er noe vi bør ta tak i, men har ingen videre konsekvens for utfasing av DNS fra Cerebrum. Se CRB-3124.
2.3 DNS
Databasemodulen mod_dns er modellert etter sonefiler - et sone-objekt kan ha flere dns-owners (labels i sonefil), som igjen kan ha flere records (dns_a_record, dns_aaaa_record, dns_mx_record). I tillegg er alle IP-adresser egne objekter som knyttes opp mot subnett-objekter.
DNS-data blir i hovedsak eksportert med contrib/dns-info/build_zone.py, som bygger sonefiler og reverssonefiler.
DNS-data kan opprettes, leses, oppdateres og slettes gjennom egne bofh-kommandoer i Cerebrum.modules.dns.bofhd_dns_cmds/BofhdExtension.
2.3.1 DHCP
Cerebrum har også mulighet for å registrere en MAC-adresse per IP-adresse for bruk til DHCP. Disse mappingene eksporteres til en tekstfil med contrib/dns-info/generate_dhcp_dump.py.
2.3.2 Subnett og DNS på UiO
Subnett på UiO levde i utganspunktet utenfor Cerebrum, og ble importert i contrib/dns-info/import_subnet_info.py. Informasjon om subnett var i utgangspunktet brukt for å gruppere og automatisk finne ledige IP-addresser.
I tillegg er det støtte for å lagre berikende informasjon om subnett, som VLAN og tekstlig beskrivelse. Denne informasjonen synliggjøres i en egen eksport til et subnett-tre i LDAP.
En subnett-modul for bofh gir innsyn i subnett, samt mulighet for å berike subnett-data med VLAN, beskrivelser o.l. i Cerebrum.modules.dns.bofhd_dns_subnet_cmds/BofhdExtension.
2.3.3 Subnett og DNS i TSD
TSD sine subnett lever i Cerebrum, og ingen subnett-import benyttes. TSD har egne bofhd-kommandoer for å opprette og fjerne subnett.
Videre knyttes subnett til prosjekter ved at hvert prosjekt får et eget VLAN som registreres på prosjektet med et VLAN-trait. Alle subnett tilhørende et prosjekt benyttert VLAN-verdien som er registrert i dette traitet.
På samme måte benyttes traits til å knytte dns-owners til prosjekt.
TSD benytter seg av Active Directory sine tjenester for DNS og DHCP, som medfører at AD-synk i TSD er blitt utvidet med støtte for å synkronisere dette.
2.4 Hostpolicy
Databasemodulen mod_hostpolicy er en utvidelse av mod_dns hvor dns-owners (hostnavn/dns-labels) kan knyttes opp mot en eller flere CFEngine policies. Selve policy-objektet med tilhørende roller og atomer lever i egner datamodeller som hostpolicy-modulen implementerer.
3 TSD
Før DNS-moduler kan fjernes helt, må all bruk avvikles, som igjen betyr at TSD må ha en ny løsning på plass.
TSD har en plan om å få på plass mreg, samt et eget system for å opprettholde kobling mellom prosjekt og DNS-data.
- Knytning mellom prosjekt og subnett, VLAN og DNS-labels (dns-owner i Cerebrum)
- Sync av DNS-data til TSD-gateway
- Sync av DNS-data og hostpolicies til Active Directory
- Automatikk for å opprette subnett, VLAN og default hosts ved oppsett av prosjekt.
- Automatikk for å fjerne subnett, VLAN og hosts ved terminering av prosjekt.
3.1 Automatisk vedlikehold av DNS-data
TSD gjenbruker OU-entiteten i Cerebrum som TSD-prosjekt. Her knyttes prosjekt-data sammen ved bruk av bl.a. traits. Videre finnes det mye automatikk som knyttes til OU/Prosjekt, bl.a. oppretting av subnett, vlan og default hosts for et gitt prosjekt.
Denne automatikken skal TSD selv implementere i et eget system, men styring av DNS fra Cerebrum kan ikke avvikles før dette er på plass.
3.2 Manuelt vedlikehold av DNS-data
TSD har funksjonalitet for vedlikehold av DNS-data i bofhd.
Det meste her vil også kunne gjøres i mreg, med unntak av kommandoen project_affiliate_entity. Denne kobler bl.a. DNS-data til prosjekt. Dette vil ikke lenger være relevant, og kan enkelt fjernes. Utfordringen her er hvordan TSD skal løse kobling mellom prosjekt og DNS-data utenfor Cerebrum/mreg.
Annen dns-funksjonalitet er i hovedsak gjort gjennom Automatisk vedlikehold av DNS-data.
3.3 DNS-data til Active Directory
TSD har funksjonalitet for å synke DNS-data til Active Directory. Det kan være verdt å merke seg at:
- Det finnes egne jobber for å skrive brukerdata og host-data som AD-synken ser til /addumps/ på Cerebrum-maskinen. Dette er antakeligvis en form for debug-funksjonalitet. Hvorvidt dette brukes, eller skal videreføres må avklares med TSD.
- TSD genererer CSV-filer for hostpolicy i tillegg til å eksportere dette til AD.
All eksport av DNS-relaterte data må re-implmeneteres i mreg, eller en mreg-utvidelsespakke. Dette skal TSD selv implementere.
3.4 DNS-data til Gateway
TSD har en XMLRPC-integrasjon med en egenutviklet Gateway-tjeneste som inkluderer synk av DNS-data.
Denne tjenesten skal avvikles i TSD.
4 Overordnet plan
For å fase ut DNS-funksjonalitet helt på en gitt instans må vi:
- Ta backup av data
- Skru av all DNS-funksjonalitet i produksjon
- Fjerne DNS-data fra produksjon (entiteter)
- Rydde i kode knyttet til DNS-funksjonalitet.
- Fjerne DNS-moduler fra schema.
Før dette kan skje, må vi først forsikre oss om at all bruk av DNS-data og DNS-funksjonalitet har opphørt, slik at steg 2. kan gjennomføres uten konsekvenser.
4.1 Funksjonalitet som ikke er i bruk
Det finnes en del funskjonalitet som ikke er i bruk i Cerebrum, og som kan fjernes uten videre konsekvenser.
4.1.1 hosts.ldif
hosts.ldif kommer fra mreg, så all funskjonalitet knyttet til eksport av denne kan fjernes:
- contrib/no/uio/generate_hosts_ldif.py
- cereconf.LDAP_HOSTS
- Rydde bort gamle filer i prod? Hvor ble disse syncet? ~pmbraat snakket om at denne hadde noe med Zabbix å gjøre? Eller var det hostpolicies?
4.1.2 dns-info
Følgende script i contrib/dns-info/ er ikke lenger i bruk noe sted:
- generate_dhcp_dump.py
- generate_subnet_ldif.py
- import_dns.py
- import_subnet_info.py
- populate_extra_info.py
- strip4cmp.py
- test_utils.py
- uio_tmp_tasks.sh
Viktig
build_zone.py må beholdes - dette er i bruk i TSD.
4.1.3 host_info hos UiO
UiO sin egen overstying av bofhd-kommandoen host_info kan fjernes. Merk at den også nevnes i bofhd_uit_cmds.
4.1.4 Maskingrupper
Maskingrupper er nettgrupper hvor medlemmer er host-objekter (dns-owner?) fra DNS-modulen.
- LDAP
Disse gruppene eksporteres ikke lenger fra Cerebrum til LDAP med contrib/generate_posix_data.py. Dette scriptet er også det eneste som bruker Cerebrum.modules.posix.host_ng_export.
Her er det mye som burde ryddes i som ikke nødvendigvis har med DNS eller hostpolicy å gjøre. cereconf.LDAP_POSIX, posixconf, Cerebrum.modules.posix vs Cerebrum.modules.NISUtils.
- NIS maps
Tidligere ble disse gruppene også eksportert som NIS maps med contrib/nis/generate_groups.py.
Dette er ikke lenger tilfelle, og funksjonalitet for maskingrupper (nettgrupper med hosts som medlemmer) kan avvikles. Merk at øvrig funksjonalitet for å bygge NIS maps med nettgrupper må beholdes - funksjonalitet for dette er fremdeles i bruk enkelte steder.
- Gamle maskingrupper
Grupper som har blitt opprettet utelukkende for å gruppere hosts bør ryddes i. Dette kan f.eks. gjennomføres ved å lage et script som:
- Leter etter alle gruppemedlemsskap for hosts
- Samler opp hvilke grupper som berøres
- Melder ut host
- Gjør noe med berørte grupper dersom de er tomme etter at alle hosts er meldt ut.
Noe i dette tilfellet kan f.eks. være å avvikle gruppen, eller å makere gruppene på et vis for å merke at de ikke er vedlikeholdt og ikke skal brukes (dersom navnet må reserveres). Vi bør høre med unix-core og mreg hva som er riktig å gjøre her - hva skjer om det finnes en nettgruppe i både Cerebrum og mreg med samme navn?
4.2 Funksjonalitet som er i bruk
TSD benytter fremdeles DNS- og hostpolicy-data i Cerebrum. Dette inkluderer:
- Automatikk for oppretting og vedlikehold av hostpolicy- og DNS-data per prosjekt
- Manuelt vedlikehold av hostpolicy- og DNS-data gjennom bofhd
- Eksport av DNS- og hostpolicy-data til AD
- Eksport av hostpolicy-filer til CFEngine
- Eksport av DNS-data til TSD-gateway.
4.2.1 TSD og dns-automatikk
Ved avvikling av DNS-modul i TSD må vi få løsrevet OU/Prosjekt fra DNS-data.
Dette gjelder i hovedsak:
- OU.setup_project - kalles kun gjennom bofhd - oppretter subnet, vlan, hosts
- OU.terminate - avslutter prosjekt og sletter alle prosjekt-data - med tilhørende subnett, vlan, hosts.
TODO: Avklare hvordan dette skal fungere
Her må vi avklare med TSD hva som skal skje ved oppsett og terminering av prosjekt. Hvordan skal TSD sin egen automatikk få med seg at et prosjekt startes/avsluttes?
4.2.2 TSD og dns-funksjonalitet i bofh
Det meste av DNS-funksjonalitet i bofhd kommer fra egne moduler som kan fjernes med config.
- Cerebrum.modules.dns.bofhd_dns_cmds/BofhdExtension
- Cerebrum.modules.dns.bofhd_dns_subnet_cmds/BofhdExtension
- Cerebrum.modules.hostpolicy.bofhd_hostpolicy_cmds/HostPolicyBofhdExtension
Unntak:
- project_info henter subnett/vlan - men dette kan fjernes ganske enkelt
- project_affiliate_entity kobler bl.a. DNS-data til prosjekt. Dette vil ikke lenger være relevant, og kan enkelt fjernes fra kommando-implementasjonen.
- project_list_hosts vil ikke lenger være relevant når Cerebrum ikke har DNS-data.
- Rene TSD-spesifikke subnet-kommandoer vil ikke lenger være relevante: subnet_list, subnet_create, subnet_search.
Annen dns-funksjonalitet er i hovedsak gjort gjennom Automatisk vedlikehold av DNS-data.
4.2.3 TSD og AD
Funksjonalitet knyttet til sync av hostpolicy- og DNS-data må fjernes fra AD-synk.
4.2.4 TSD-gateway
Tjenesten skal avvikles, så her kan hele integrasjonen fjernes.
4.3 Backup
- Eksport av DNS-historikk
- Cerebrum har historikk på DNS-endringer gjort frem til mreg-overgang. Denne historikken er ikke importert i mreg, og bør kanskje lagres for fremtidig feilsøking, og for audit-formål.
- Eksport av øyeblikkstilstand
- Cerebrum har fremdeles DNS-data slik som DNS såg ut før overgang til mreg. Det kan ha forekommet feil ved overgang til mreg som enda ikke er oppdaget - og historiske DNS-data kan være nyttig for eventuell sammenligning med mreg-tilstand og -historikk i forbindelse med feilsøking.
Dersom vi henter ut all data knyttet til DNS i form av database-backup eller som eksporter på maskinlesbart format, så vil vi stå fritt til å slette all DNS-relaterte data i Cerebrum.
Alternativt kan vi basere oss på backup av database - vi må bare sjekke at vi har backup fra det aktuelle tidsvinduet, og sørge for at akkurat denne backupen vil bestå i en gitt periode.
4.4 Skru av
Før data fjernes, er vi nødt til å skru av all DNS-funksjonalitet i produksjon. Dette er typisk jobber som kjører i job runner, og kommandoer i bofhd.
Dersom tiltak for å separere ut DNS-funksjonalitet fra annen funksjonalitet har blitt gjort, vil dette være konfigurasjonsendring.
4.5 Fjerne DNS-data
Alle DNS-relaterte data må fjernes fra database. Dette må gjøres før tabeller droppes fra database, slik at også entity_info fjernes, med tilhørende referanser (f.eks. traits).
Dette bør typisk gjøres med egne oppryddingsscripts som må lages. Scriptene må ta høyde for at det gjerne finnes traits og andre data knyttet til hosts, og at normal sletting kanskje gjør en soft delete, mens vi her trenger en hard delete.
Vi må passe på å fjerne data som ikke nødvendigvis er hardt knyttet til DNS-entiteter:
- Endringer: changelog, auditlog, eventlog, events
- Bofhd-auth: AuthOpTargets, Opsets
4.6 Rydde i kode
Straks alle data er fjernet, kan moduler og scripts knyttet til hostpolicies og DNS fjernes.
- contrib/hostpolicy/
- contrib/dns-info/
- Cerebrum.modules.dns
- Cerebrum.modules.hostpolicy
I tillegge vil en måtte fjerne funsksjonalitet fra:
- Cerebrum.modules.bofhd.access
- Kommandoene access dns, access global_dns, access list
- Cerebrum.modules.bofhd.auth
- I _has_target_permissions er det implementert funskjonalitet for å sjekke auth_target_type_dns og auth_target_type_global_dns
4.7 Fjerne data og datamodeller
- makedb.py --drop design/mod_hostpolicy.sql
- makedb.py --drop design/mod_dns.sql
4.8 Fjerne alle spor av DNS
- makedb.py - Fjerne referanser til hostpolicy og dns
- Fjerne migrasjoner for hostpolicy og dns i contrib/migrate_cerebrum_database.py
- Fjerne dns-relaterte referanser i contrib/migrate/?
- Fjerne generiske konstanter knyttet til dns og hostpolicy - auth_grant_dns - auth_target_type_dns - auth_target_type_global_dns - EntityType for DNS-entiteter - TraitCode knyttet til DNS-entiteter - ChangeTypeCode knyttet til endringer i DNS
- Fjerne bruk av mod_hostpolicy og mod_dns i testopsett (servers/cis/testsuite/test_individuationservice.py, testsuite/)
4.8.1 Fjerne all DNS-relatert konfigurasjon
- dbcl_conf - fjerne konfig for db_clean av dns-changes
- adconf: fjerne dns-relaterte sync-types i TSD
- cereconf.DNS_DEFAULT_MX_SET
- cereconf.DNS_DEFAULT_ZONE
- cereconf.DNS_EMAIL_REGEXP
- cereconf.DNS_HOST_A_ADD_ACCEPT_MISSING_IPV6_SUBNET
- cereconf.DNS_SUBNETIMPORT_ERRORDOC_URL
Vi må også passe på å fjerne fra default config (Cerebrum.default_config, Cerebrum.default_dbcl_conf)