Tags:
create new tag
, view all tags

Realm Synchronisation

momentane produktive Lösung

  • Realms werden im Netsupport-Tool von den Netsupport-Leuten verwaltet
  • Realms werden in nethz als NGROUP gespeichert
  • Änderungen an Realms und ihren Mitgliedern werden in der Tabelle SYNC_NGROUP_DESTINATION festgehalten
  • der DBMS-Job NETHZ.SYNC_REALMS läuft alle 2 Minuten und aktualisiert die Zieltabellen
    • OM.V_NETNG_REALM
    • OM.V_NETNG_REALM-USER
  • diese Zieltabellen sind wiederum Datenquelle für die eigentlichen Radius-Server
  • IDEA! Falls die Daten im Zielsystem gelöscht sind, können diese sehr einfach wieder gefüllt werden:
UPDATE sync_ngroup_destination
SET group_changed = 'insert'
WHERE destination_id IN (
    SELECT destination_id
    FROM destination
    WHERE name = 'Realm'
)
  • … danach die stored procedure NETHZ.SYNC_REALMS laufen lassen

Projektbeschreibung für die Verbesserung der Realm-Synchronisation (August 2014)

Ausgangslage

  • Realms werden im Netsupport-Tool von den Netsupport-Leuten verwaltet
  • sie werden in der nethz-DB in der Tabelle nethz.NGROUP gespeichert ( nethz.NGROUP_INCLUDES, nethz.NGROUP_MEMBER)
  • sie sind vom Gruppentyp «custom» oder «realm» und haben das Flag EXPORT_NETNG=1 gesetzt
  • Änderungen an diesen Tabellen werden von diversen Triggern registriert und in die Synchronisationstabellen nethz.UPDATE_NGROUP und nethz.UPDATE_NGROUP_MEMBER geschrieben
  • die Änderungen werden regelmässig (zur Zeit alle 2 Minuten) vom DBMS-JOB pkg_netrds_sync.run abgearbeitet (SYSDATE/720)
  • die Daten werden aus den Views netradius.V_NETHZ_UPDATE_REALM, netradius.V_NETHZ_UPDATE_REALM_USER und netradius.V_NETHZ_REALM gelesen
  • ...und in die Tabellen netradius.V_NETNG_REALM ( om.NETNG_REALM) sowie netradius.V_NETNG_REALM_USER ( om.NETNG_REALM_USER) geschrieben
  • Zur Zeit (August 2014) sind etwa 180 verschiedene Realms bekannt

Probleme der jetzigen Lösung

  • separate Gruppenadministration im Netsupport-Tool, nur für Realms
  • Duplikate in den Gruppen-Namen (Realm gleichlautend wie Netsupport-Gruppe)
  • separater Gruppentypentyp anstatt einfacher Export
  • Daten werden innerhalb derselben Datenbank mehrfach umkopiert
  • mangelhafte / nicht vorhandene Dokumentation

neuer Lösungsansatz

  • DONE direktes Schreiben in die Tabellen OM.V_NETNG_REALM und OM.V_NETNG_REALM_USER
  • DONE Trigger auf dem Flag EXPORT_NETNG macht einen Eintrag in der Tabelle NGROUP_DESTINATION
  • DONE periodisch (DBMS-Job SYNC_REALMS, alle 2 min wie bisher) die Tabelle SYNC_NGROUP_DESTINATION abarbeiten und die Tabellen im OM-Schema aktualisieren
  • TODO Alle Custom-Gruppen auch Realm-fähig machen (in demselben Tool für Netsupport-Gruppen bearbeitbar)
  • TODO Realm als eigener Gruppentyp? Oder einfach eigene Destination? (Zur Zeit gibt es das Attribut EXPORT_NETNG, welches allerdings nur für Realms setzbar ist)

-- SwenVermeul - 2014-08-19

Topic revision: r6 - 2016-06-01 - SwenVermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback