Nameserver unter Linux administrieren und warten

---

Nameserver administrieren / starten / stoppen

Der GSI-Nameserver wurde 2015 auf das RH6 operations-cluster umgezogen. Der GSI-Nameserver läuft auf einer der Maschinen im 3er-Cluster ( asl330..). Eine einfach zu bedienende Administrationsoberfläche, wie das früher verwendete packControl, steht dort (noch?) nicht zur Verfügung.

Anwendungen, die mit dem Nameserver kommunizieren möchten, erreichen ihn über die Adresse nsrv00a.acc.gsi.de und den Port 52315, egal auf welchem Rechner er gerade läuft. Siehe dazu auch Gut zu wissen.

Das Startscript ist asl330:/common/usr/cscofe/opt/devacc/pro/bin/nameserver-cluster.sh.

Das Exe ist asl330:/common/usr/cscofe/opt/devacc/pro/bin/nameserver.

Die Rechtedatei ist asl330:/common/usr/cscofe/opt/devacc/etc/nameserver/right.xml. Die darin referierte Datei http://www-acc.gsi.de/XMLSchema/right.xsd wird beim mvn deploy des Nameservers dorthin kopiert (siehe .../nameservice/server/src/xml/right.xsd, .../nameservice/server/x86_64/pom.xml und .../nameservice/server/src/SConscript).

Die Persistenz-Datei ist asl330:/common/usr/cscofe/opt/devacc/var/nameserver/accessdata.txt.

Startscript und Executable sind versions-abhängig, da sie unter .../devacc/pro/... liegen. Rechte- und Persistenz-Datei sind versions-unabhängig, da sie unter .../devacc/etc/... bzw. unter .../devacc/var/... liegen.

Logs des Nameservers

Die Logs des Nameservers sind in Logstash/Kibana zu finden. Als Suchkriterium einfach nameserver angeben.

Zugriffsrechte

In /common/usr/cscofe/opt/devacc/etc/nameserver/right.xml auf der asl33x sind die Zugriffsrechte der User spezifiziert. Die Rechtedefinition kann über die Utility nameservercmd bei laufendem Nameserver neu geladen werden.

Weitergehende Informationen sind erhältlich zu Zugriffsrechten im Kontrollsystem sowie zur Spezifikation der Zugriffsrechte in der Rechte-Datei.

Der Aufbau der Datei ist folgendermaßen und erfolgt nach dem XSL-Schema http://www-acc.gsi.de/XMLSchema/right.xsd: Zunächst können Gerätemodellgruppen definiert werden.

   <EQMOD>
      <group name="magnets">
         <element>MX</element>      <!-- 19 -->
         <element>MXRI</element>      <!-- 28 -->
      </group>
      <group name="esrpluscooler">
         <element>PPOS</element>      <!-- 54 -->
         <element>STHV</element>      <!-- 55 -->
         <element>IT</element>      <!-- 21 -->
         <element>CS</element>      <!-- 22 -->
         <element>FBSD</element>      <!-- 24 -->
         <element>ESAU</element>      <!-- 39 -->
         <element>CEHV</element>      <!-- 47 -->
      </group>
   </EQMOD>

Anschließend können Benutzergruppen angegeben werden:

   <USER>
      <group name="operating">
         <element>siszdi</element>
         <!-- VMS console -->
         <element>siskons</element>
         <!-- VMS console -->
         <element>sisodb</element>
         <!-- VMS console -->
      </group>
   </USER>

Geraetegruppen koennen so definiert werden:

<DEVICE>
    <group name="testdevices">
        <element>TEST01</element>
        <elememt>TEST02</element>
    </group>
</DEVICE>

Zukuenftig koennen auch Hosts fuer die Rechtevergabe herangezohen werden. Erhaelt ein Benutzer Rechte fuer einen Host hat er Zugriff auf alle Geraete, die auf diesem Host laufen.

<HOST>
    <group name="testhosts">
        <element>asl722.acc.gsi.de</element>
        <element>asl723.acc.gsi.de</element>
    </group>
</HOST>

Bereichsdefinitionen sind auch möglich:

   <AREA>
      <group name="ionsources">
         <element>ul</element>
         <element>ur</element>
         <element>un</element>
      </group>
      <group name="hfs">
         <element>ts</element>
         <element>hfs</element>
      </group>
   </AREA>

Optional können auch Gruppen mit Geratenamen angegeben werden oder einzelne Namen. Diese Gruppen müssen jedoch zuvor definiert worden sein.

Zu guter letzt werden die Benutzerrechte aufgeführt. Dabei ist es möglich

• einem Benutzer/einer Benutzergruppe ein Recht für ein Gerätemodell oder eine Gerätemodellgruppe zu geben
• einer Benutzer/einer Benutzergruppe ein Recht für ein Gerät oder eine Gerätegruppe zu geben
• Rechte für bestimmte Bereiche zu vergeben
• Rechte gezielt zu verweigern

Ein gültiger Eintrag für die Rechtevergabe ist z.B.

   <RIGHT>
      <user group="ionsource">
         <modify>
            <eqmodelgroup>ionsource</eqmodelgroup>
         </modify>
         <localsystem>
            <eqmodelgroup area="ionsources" areatype="group">diagnostics</eqmodelgroup>
         </localsystem>
      </user>
   </RIGHT>

D.h. die Benutzer, die in der Gruppe ionsource eingetragen sind, haben das Recht modify für Geräte in der Gruppe ionsource. Localsystem-Rechte bestehen für die Gerätegruppe diagnostics, deren Geräte im Bereich ionsources sind.

Editieren und Validieren

Die Rechtedatei laesst sich leicht mit dem Oxygen XML-Editor (Aufruf: oxygen-xml) editieren. Anhand des angegebenen Schemas schlaegt der Editor beim Eingeben die moeglichen Attribute und Elemente vor.
Validiert wird die Rechte-Datei gegen ein Schema, das am Anfang des XML-Dokumentes angegeben ist. Dieses Schema stellt sicher, dass eine bestimmte vom nameserver erwartete Formatierung eingehalten wird. Lässt sich das XML-Dokument nicht richtig validieren, kommt es beim Einlesen in den Nameserver zu Fehlern und die Rechteverwaltung kann nicht richtig funktionieren. Die Validierungs-Funktion ist im Oxygen XML-Editor zu finden im Menu Document>Validate>Validate oder in der Toolbar (roter Haken auf weissem Blatt).

Schema aktualisieren

Der Ort des Schemas wird im XML-Dokument im Wurzelelement als Attribut angegeben:

xsi:noNamespaceSchemaLocation="https://www-acc.gsi.de/XMLSchema/right.xsd"

Aktualisieren lässt sich die Datei über webdav unter Verwendung des Konquerors:

webdavs://www-acc.gsi.de/dav/XMLSchema

Gerätedaten

In /common/usr/production/nameserver/accessdata.txt sind die beim Nameservice aktuell angemeldeten Geräte gespeichert.

Startoptionen

Der Nameserver kann mit verschiedenen Optionen gestartet werden.

-f <DEVFILE>, --acdfile=<DEVFILE>

Pfad und Name der Datei, die die aktuell angemeldeten Geräte verwendet

-r <RIGHTSFILE>, --rightsfile=<RIGHTSFILE>

Pfad und Name der Datei, in der die Zugriffsrechte der Benutzer festgelegt sind

-d, --debug

das Loglevel wird auf LOG_DEBUG gesetzt (Achtung: Die Abfragen dauern nun natürlich länger)

-w, --warning

das Loglevel wird auf LOG_WARNING gesetzt

-i, --info

das Loglevel wird auf LOG_INFO gesetzt

Diese werden auch im Startskript asl330:/common/usr/cscofe/opt/devacc/pro/bin/nameserver-cluster.sh benutzt.

Ob der Nameserver gestartet wurde, kann man am Output im Log erkennen. Beispiel:

Short options

  nameserver -f accessdata.txt -r right.xml -d
  Starting Nameserver...
  ...

Long options

  nameserver --acdfile=accessdata.txt --rightsfile=rights.xml --debug
  Starting Nameserver...
  ...

Gut zu wissen

Host

Die Umgebungsvariable ACC_NAMESERVER_HOST wird in /common/usr/cscofe/opt/devacc/pro/bin/nameserver-cluster.sh mit

export ACC_NAMESERVER_HOST="nsrv00a.acc.gsi.de"

definiert. Man hat sie nach dem Einloggen zur Verfügung.

Für Testzwecke auf dem eigenen Rechner kann man auch

  export ACC_NAMESERVER_HOST=127.0.0.1

definieren.

Portnummer

Die Umgebungsvariable ACC_NAMESERVER_PORT wird ebenfalls in /common/usr/cscofe/opt/devacc/pro/bin/nameserver-cluster.sh mit

  export ACC_NAMESERVER_PORT="52315"

definiert, so dass man sie nach dem Einloggen zur Verfügung hat. 52315 ist auch die Default-Portnummer, wenn ACC_NAMESERVER_PORT nicht definiert sein sollte.

Zum Debuggen kann man z.B. die eigene PLZ verwenden:

  export ACC_NAMESERVER_PORT=64xxx

Rechte neu laden

Mit dem Kommandozeilentool nameservercmd kann die Rechtedatei des Nameservers neu eingelesen werden (ab Version 9):

eqpact
nameservercmd -r

Es werden die Rechte aus der Datei neu geladen, die ursprünglich beim Start des Nameservers angegeben wurde. Das Tool kann nach dem Aufruf von eqpact auf jedem Rechner im Beschleunigernetz ausgeführt werden. Siehe dazu Nameserver bedienen.

Loglevel ändern

Mit dem Kommandozeilentool nameservercmd kann das Loglevel des Nameservers umgesetzt werden. Folgender Aufruf setzt das Loglevel auf LOG_DEBUG. Je nachdem, welches Loglevel eingestellt war, sieht man im Log, ob das Loglevel geändert wurde (Diese Mitteilung wird als LOG-INFO ausgegeben).

eqpact
nameservercmd -l 7

Folgende Werte sind möglich (aus sys/syslog.h):

Level	Value	Comment
LOG_EMERG	0	system is unusable
LOG_ALERT	1	action must be taken immediately
LOG_CRIT	2	critical conditions
LOG_ERR	3	error conditions
LOG_WARNING	4	warning conditions
LOG_NOTICE	5	normal but significant condition
LOG_INFO	6	informational
LOG_DEBUG	7	debug-level messages

Bei der Verwendung des Kommandozeilentools sollte die Portnummer in der Umgebungsvariable ACC_NAMESERVER_PORT sowie der aktuell eingetragene Host in der Umgebungsvariable ACC_NAMESERVER_HOST beachtet werden.

eqpact
export | grep ACC_NAMESERVER
declare -x ACC_NAMESERVER_HOST="nsrv00a.acc.gsi.de"
declare -x ACC_NAMESERVER_PORT="52315"

Server-Informationen abfragen

Allgemeine Informationen abfragen

Mit dem Kommandozeilentool nameservercmdim Verzeichnis $libasl64 können Server-Informationen des Nameservers abgefragt werden.

eqpact
nameservercmd -i

User-Informationen abfragen

Mit dem Kommandozeilentool nameservercmdim Verzeichnis $libasl64 können die pro User im Nameserver eingetragenen Rechte abgefragt werden.

eqpact
nameservercmd -u username

Unittest für den Accessserver

Im SVN-Projekt access_unittest befinden sich die Quellen für einen Unittest des Accessservers. Dieser ermöglicht eine wiederholbare Überprüfung der Rechte-Funktionalität des Nameservers. Das Prinzip: es wird eine XML-Rechtedatei sowie eine XML-Datei, die die Testfälle enthält, eingelesen. Anhand der gegebenen Testfälle werden die vergebenen Rechte bestimmt und mit dem erwarteten Testergebnis verglichen. Die Ergebnisse werden in einer Testergebnis-Datei abgelegt. Diese kann wahlweise im XML-Format sein oder eine simple Textdatei. Letzteres ist der default. Bei der Definition der Testfälle ist auf die Formulierung zu achten. Das Soll-Ergebnis wird auf genau-gleich mit dem tatsächlichen Testergebnis verglichen.

Ein typischer Testfall sieht so aus:

   <CASE>
      <username>MOD_USER</username>
      <device>BEREICH*</device>           <!--Angabe notwendig für Abfragen von Bereichen!-->
      <eqmodel>LOC_DEVICEMODEL</eqmodel>
      <right>localsystem</right>
      <result>OK</result>
   </CASE>

Optionen

   * -h                        Hilfe anzeigen
   * -r right_unittest.xml     Angabe der Rechte-Datei
   * -c testcases_strict.xml   Angabe der Testfall-Datei
   * -t testresults.xml        Angabe der Ergebnis-Datei, Datum und Zeit wird angefügt
   * -x                        Test-Output in eine xml-Datei. Sonst: txt-Datei (default)

Ein typischer Aufruf sieht z.B. so aus:

  ./access_unittest -r right.xml -c testcases.xml -t results.txt

Beispiele für die Ergebnisausgabe:
TXT-Datei

  Testfall    Gruppe/Name   Modell/Gerät    Geliefertes Recht    Erwartetes Recht    Testergebnis    Gesamtergebnis
  Testcase_0  giacomini     DPX             system               read                NOK             OK

XML-Datei

  <Testcase_0>
    <username>giacomini</username>
    <eqmodel>DPX</eqmodel>
    <right>system</right>
    <testright>read</testright>
    <result>NOK</result>
    <testresult>OK</testresult>
  </Testcase_0>

Die Testergebnisse können nach Änderungen am Nameserver einfach mit früheren Ergebnissen verglichen werden. Somit sollten Fehler im Nameserver, die sich unabsichtlich eingeschlichen haben, leichter erkannt werden.

Konfigurationsdateien

Die zum Starten des Nameservers notwendigen Konfigurationsdateien sind im Projekt framework/nameservice/server/src/config abgelegt.

Core-Dumps

Coredumps des Nameservers landen unter ???