Spesifikasjon for Hostpolicy-modulen

Spesifikasjon for Hostpolicy-modulen til Cerebrum.

Innhold

1   Bakgrunn

I forbindelse med innføring av Cfengine har det oppstått et behov for i stor skala å kunne definere ulike maskinroller og knytte dem til maskiner.

Siden maskiner allerede er registrert i Cerebrum og fordi Cerebrum allerede har et fungerende grensesnitt som ikke krever store utvidelser for å kunne administrere maskinroller, anses Cerebrum for å være et egnet sted å lagre og administrere data om maskinroller.

Å legge dette til Cerebrum vil også gi bedre kontroll av de ulike dataene som lagres om maskinroller enn f.eks. å vedlikeholde dette i filer sjekket inn i Subversion.

2   Avhengigheter

I tillegg til core, så benytter Hostpolicy-modulen seg av de utvidede host-konseptene som er å finne i DNS-modulen, og er dermed avhengig av den.

3   Autoritative kilder for data om maskinroller

Cerebrum vil være autoritativ kilde for all informasjon relatert til maskinroller.

4   Lagring i databasen

Maskinroller vil fordre fire nye tabeller i Cerebrum-databasen.

4.1   hostpolicy_component

Inneholder informasjon om atomer og roller.

  • entity_type - Vil alltid være entity_hostpolicy_atom eller entity_hostpolicy_role i denne tabellen
  • component_id - Unik entitets-ID; brukes internt i Cerebrum
  • create_date - Dato for opprettelse av komponent
  • description - Tekstlig beskrivelse av komponenten og dets bruksområde, maks 512 tegn
  • foundation - URL - kan være tom
  • foundation_date - Dato for vedtak om opprettelse av komponentet

Navn på komponentet lagres i tabellen entity_name (som for andre entiteter). entity_name skal være unikt, atomer og roller sett under ett, noe som løses ved å definere et felles navnerom for de to i form av en ValueDomainCode ved navn hostpol_comp_ns.

4.1.2   Fremmednøkkel

  • (entity_type, component_id) => entity_info.(entity_type, entity_id)

4.1.3   Constraints

  • entity_type er enten entity_hostpolicy_atom eller entity_hostpolicy_role

4.2   hostpolicy_relationship_code

Kodetabell som skal uttrykke de ulike forholdene policy'er kan ha til hverandre.

  • code - Numerisk ID for koden
  • code_str - Tekstnøkkel som representerer koden
  • description - Beskrivelse av hva koden representerer

4.2.2   Constraints

  • code_str må være unik

Enn så lenge, så er det to forhold det vil være koder for:

  • "Har som medlem" - hostpol_member
  • "Er gjensidig utelukkende med hverandre" - hostpol_mutex

4.3   hostpolicy_relationship

Mapper roller/atomer til hverandre

  • source_policy - Rollen/atomet som har et forhold til et annet
  • relationship - Kode som angir forholdets natur
  • target_policy - Rollen/atomet som source_policy har et forhold til

4.3.1   Primærnøkkel

  • source_policy + relationship + target_policy

4.3.2   Fremmednøkler

  • source_policy => hostpolicy_component.component_id
  • relationship => hostpolicy_relationship_code.code
  • target_policy => hostpolicy_component.component_id

4.3.3   Constraints

  • source_policy må være forskjellig fra target_policy

4.4   hostpolicy_host_policy

Inneholder mapping fra maskinen til rollene/atomene som maskinen har.

  • dns_owner_id - Maskinen som har en gitt rolle
  • policy_id - Rollen/atomet som maskinen er assosiert med

4.4.1   Primærnøkkel

dns_owner_id + policy_id

4.4.2   Fremmednøkler

  • dns_owner_id => dns_owner.dns_owner_id
  • policy_id => hostpolicy_components.component_id

5   Eksport

Data relatert til maskinroller eksporteres til fire ulike filer

Eksporten kjøres ca. hvert 10. minutt, og filene overføres til et passende sted på cfengine-prod01.uio.no.

Datoer eksporteres i ISO-format, dvs YYYY-MM-DD

5.1   atoms.csv

Ett atom per linje, hvor hver linje er på formatet:

atomname;description;foundation;foundation_date

5.2   roles.csv

En rolle per linje, hvor hver linje er på formatet:

rolename;description;foundation;foundation_date;members*
  • Listen med members skal være komma-separert.

5.3   hostpolicies.csv

En linje per host, hvor linje er på formatet:

hostname;policy+
  • Host'er som ikke er tildelt noen roller/atomer taes ikke med.
  • Kun de rollene/atomene som er direkte assosiert med en host listes
  • Listen med policy'er skal være komma-separert.

5.4   policyrelationships.csv

En linje per oppføring i tabellen hostpolicy_relationship, på formatet:

source_policy_name;relationship_code_str;target_policy_name

6   Maskinrollerelaterte BOFH-kommander

6.1   Tilgjengelighet

Rent generelt, så skal alle maskinrolle-relaterte bofh-kommandoer være tilgjengelige kun for DNS-superbrukere. Kommandoer som skal være mer generelt tilgjengelige har det spesifisert nedenfor.

6.2   policy atom_create <ATOMNAME> <DESCRIPTION> <FOUNDATION> [FOUNDATION_DATE]

Legger til et nytt atom i databasen og inkluderer obligatorisk beskrivelse av hvilken tilstand atomet skal representere, en begrunnelse for atomets eksistens samt en dato som default blir date men som kan overstyres til datoen atomet ble vedtatt.

  • Atomnavn kan kun bestå av en kombinasjon av alfanumeriske tegn, samt understrek
  • Atomnavn må være unike og kan heller ikke allerede innehas av noen rolle
  • Øvrige felter kan ikke inneholde semikolon

Dersom en dato ikke er oppgitt, vil dags dato bli brukt.

6.3   policy atom_delete <ATOMNAME>

Sletter et atom fra databasen.

Dersom atomet er del av noen roller og/eller assosiert med noen host'er, så skal feilmelding gis hvor disse rollene/host'ene listes.

6.4   policy role_create <ROLENAME> <DESCRIPTION> <FOUNDATION> [FOUNDATION_DATE]

Legger til en ny rolle i maskin-rolle-samlingen og inkluderer obligatorisk beskrivelse av i hvilke tilfeller rollen er relevant, en begrunnelse for rollens eksistens samt en dato som default blir date men som kan overstyres til datoen rollen ble vedtatt.

  • Rollenavn kan kun bestå av en kombinasjon av alfanumeriske tegn, samt understrek
  • Rollenavn må være unike og kan heller ikke allerede innehas av noe atom
  • Øvrige felter kan ikke inneholde semikolon

Dersom en dato ikke er oppgitt, vil dags dato bli brukt.

6.5   policy role_delete <ROLENAME>

Sletter rollen fra databasen.

Dersom rollen er del av noen roller og/eller assosiert med noen host'er, så skal feilmelding gis hvor disse rollene/host'ene listes.

6.6   policy rename <POLICY> <NEW_NAME>

Bytter namn på ein policy.

Namnet må ikkje eksistere for ein annan policy.

6.7   policy set_description <POLICY> <DESC>

Legg til ein ny beskrivelse for ein policy. Dei samme reglane som ved oppretting gjelder (td. er ikkje semikolon tillatt).

6.8   policy set_foundation <POLICY> <FOUNDATION> [FOUNDATION_DATE]

Sett ein ny foundation for ein policy. Dei samme reglane som ved oppretting gjelder.

Datoen er valfri. Dersom den ikkje vert oppgitt vil den forbli den eksisterande datoen.

6.9   policy add_member <ROLENAME> <ROLEMEMBER>

Legg til en rolle/atom på en rolle.

Dersom rollen/atomet som forsøkes legges til er gjensidig utelukkende med noen av rollene/atomene som allerede er designert i rollen, gis feilmelding i stedet.

Dersom en rolle som forsøkes legges til allerede eksisterer via en annen (super)rolle skal kommandoen feile. Merk at atom kan leggast til sjølv om dei er med via andre roller.

TBD: Burde kommandoen heller heite policy add_relationship og har relasjonstypen som første argument? På den måten kan ein også få lagt til mutex, og evt. også andre typar seinare.

6.10   policy remove_member <ROLENAME> <ROLEMEMBER>

Fjern en rolle/atom sitt "medlemskap" til en en rolle.

6.11   policy list_members <ROLE>

Lister alle roller/atomer som er medlemmer i en rolle, på en oversiktelig, hierarkisk måte.

Kvar policy som listast skal ha A (atom) eller B (rolle) som prefiks.

6.12   policy has_member <MEMBER>

Lister alle roller som har gitt member som medlem.

6.13   host policy_add <HOSTNAME> <POLICY>

Legger til en rolle/atom på en maskin.

Dersom rollen/atomet som forsøkes legges til er gjensidig utelukkende med noen av rollene/atomene som allerede er designert i rollen, gis feilmelding i stedet.

Dersom policy er ei rolle, skal det gis feilmelding om rolla allereie eksisterer for hosten, enten direkte eller indirekte.

6.14   host policy_remove <HOSTNAME> <POLICY>

Fjerner til en rolle/atom fra en maskin.

6.15   host policy_list <HOSTNAME>

Lister hvilke roller/atomer som er assosiert med en maskin på en oversiktelig, hierarkisk måte.

6.16   policy list_hosts <POLICY>

Lister hvilke host'er som er assosiert med denne policy'en. Merk at også indirekte assosiasjoner må listast med, helst så ein ser korleis relasjonane er.

6.17   policy list_atoms <FILTER>

Dumper en liste med alle atomer, representert ved deres navn og beskrivelse. FILTER brukes for å filtrere resultatene etter navn, beskrivelse, foundation_dato eller annet. Fleire filter skal kunne kombinerast. Hjelpeteksten til argumentet skal kunne forklare dette i detalj.

Denne kommandoen er tilgjengelig for alle.

6.18   policy list_roles <FILTER>

Dumper en liste med alle roller, representert ved deres navn og beskrivelse. FILTER brukes for å filtrere resultatene etter navn, beskrivelse, foundation_date eller annet. Fleire filter skal kunne kombinerast. Hjelpeteksten til argumentet skal kunne forklare dette i detalj.

Denne kommandoen er tilgjengelig for alle.

6.19   policy info <POLICY>

Lister info om en policy

  • Navn
  • Hvorvidt det er et atom eller en rolle
  • Beskrivelse
  • Forankring/begrunnelse
  • Hvis rolle, hvilke roller/atomer den inneholder (ikke rekursivt)
  • Hvilke roller den inngår i

Denne kommandoen er tilgjengelig for alle.

6.20   host remove

Utvides til ukritisk å slette alle roller/atomer assosiert med maskinen når en host skal slettes.

6.21   host info <host> [policy]

Utvides til å liste alle roller/atomer som er direkte knyttet til host'en dersom det optional-parameteret policy er lagt til på kommandoen.

7   Testing

7.1   BOFH-kommandoer

TODO: Spesifisere tester

7.2   Eksporter

TODO: Spesifisere tester

8   Produksjonssetting

Filer som trenger å oppdateres (til HEAD):

"cerebrum"-treet:

setup.py
Cerebrum/modules/hostpolicy/*
Cerebrum/modules/dns/*
Cerebrum/modules/no/uio/bofhd_uio_cmds.py
Cerebrum/modules/no/uio/bofhd_uio_help.py
contrib/dns/generate_hostpolicy_dumps.py
design/mod_hostpolicy.sql

"cerebrum_sites"-treet:

etc/uio/scheduled_jobs.py
etc/uio/config.dat

For å gjennomføre oppgradering av databaseskjemaet og sette inn nye konstanter:

python makedb.py --debug design/mod_hostpolicy.sql

Opprett mappen /cerebrum/uio/dumps/DNS/hostpolicy/ så eksportfilene kan lagres.

Sørg for at oppdaterte jobber har blitt lastet inn i job_runner:

/cerebrum/uio/sbin/job_runner.py --reload

9   Veien videre

Det vil være naturlig å evaluere og evt planlegge videreutvikling av denne modulen når den har vært i bruk en stund og vi har fått litt erfaring med hvordan den fungerer i praksis, f.eks. etter et halvt års tid.

Det følgende er momenter som kan taes med inn i en slik prosess

9.1   Kommandoer for behandling av mutex

For no har ein berre tilgang til å kunne legge til relasjonar av typen "contains" (medlem), men ein har ikkje mulighet til å legge inn andre typar. Eit forslag er å bytte om namnet på kommandoen policy add_member til policy add_relationship, og legge til relasjonstypen som første argument (contains/mutex).

9.2   Import av "automatiske" roller

En del roller vil kunne avledes/detekteres utenfor cerebrum, f.eks. hvorvidt en maskin er en Dell eller en HP. Det kan være nyttig å ha en mekanisme (eller flere?) for å importere slik informasjon til cerebrum. Vi vil trenge å vurdere om slike roller skal flagges på noe vis, kanskje til og med at de ikke skal kunne settes via bofh.

9.3   Delegering av rollerettigheter

Det vil være nyttig å kunne gi LITA'er anledning til å sette roller på sine maskiner. Rollene som LITA'er skal kunne sette må nødvendigvis være et subsett av det totale rollesettet, siden f.eks. en del roller vil dreie seg om innloggingsrettigheter.

9.4   Roller som kan "nullstille" andre roller

Det vil kunne være nyttig å kunne si at en gitt rolle tilsier at en annen rolle ikke gjelder, selvom den skulle være satt på maskinen. F.eks. hvis en rolle R inneholder rollen S, og rolle T nullstiller rollen S, så skal en maskin som er tildelt rollene R og T ikke ha rollen S.

Av DNS og Cerebrum
Publisert 4. sep. 2014 16:36
Del på e-post