NAME

sysconf - Systemkonfiguration

SYNOPSIS

 sysconf [options] action subsystem machine

DESCRIPTION

Eine Aktion ist in natürlicher Sprache formuliert von dem Aufbau: 'Führe Aktion X mit Subsysteme Y auf Rechner Z aus.' Aktionen werden per Kommandozeile übergeben, wobei:

 action    := init | update | remove | start | stop | documentation |
              listhosts | listinterfaces | lisreposfiles | listrevision | none
 subsystem := <subsystem-name>{,<subsystem-name>}* | ALL
 machine   := <machine-name>{,<machine-name>}*     | ALL
 'ALL' steht dabei für 'alle Subsysteme' oder 'alle Rechner'.

 init:          Subsystem erstmalig installieren (alle File einschliesslich
                'initfiles')
 update:        Subsystem updaten (Files aus 'initfiles' nicht kopieren!)
                Wenn es das Subsystem nicht gibt, dann 'init' vorher durchführen
 remove:        Subsystem entfernen.
 start:         Subsystem starten.
 stop:          Subsystem stoppen.
 documentation: Dokumentation erzeugen
 listhosts:     Liste aller Rechner (aus hosts.sc) ausgeben.
                Dabei wird der SUBSYSTEM-Parameter ignoriert und MACHINE muss
                ALL sein, also: sysconf listhosts xxx ALL
 listinterfaces: Liste aller Interfaces der Rechner (aus hosts.sc) ausgeben.
                Dabei wird der SUBSYSTEM-Parameter ignoriert und MACHINE muss
                ALL sein, also: sysconf listinterfaces xxx ALL
 listreposfiles: Liste aller Files im Repository für das angegebene Betriebs-
                system. Dabei wird der MACHINE-Parameter ignoriert. Beispiel:
                sysconf listreposfiles AIX-5.1 xxx
 listrevision:  Liste aller Rechner (aus hosts.sc das Feld REVISION) mit der
                Revisionsnummer ausgeben.
                Dabei wird der SUBSYSTEM-Parameter ignoriert und MACHINE muss
                ALL sein, also: sysconf listrevision xxx ALL
 none:          Keine Aktion.

 Optionen:
 -wX: mit X=1-31 gibt den LOG-Level an. X ergibt sich als Summe der folgenden
      möglichen Werte (Bitmaske):
      1:  alle Fehler (Genaue Fehlerbeschreibungen)
      2:  alle Warnungen (sollte man beachten)
      4:  alle Informationen (ganz informativ)
      8:  alle Debug-Informationen (ausführlicher Status, etc.)
      16: alle Remote-Shell-Aufrufe und Sysconf-Client-Aufrufe
      (Default ist 7, also 1+2+4)
 -b : Erstellt Backup-Dateien auf dem Zielrechner, wenn Änderungen
      stattgefunden haben. Die Backup-Dateien enden mit einem Zeitstempel:
      '.JJJJMMTTHHMMSS.SC' z.B. '.20011019121531.SC'
 --logfile=FILENAME : Logging erfolgt in die Datei LOGFILE.
                      Es kann auch ein Pipe angegeben werden, z.B.
                      --logfile=\"|/bin/cronolog /var/log/sysconf/\%Y/\%m/\%d\"
 --sysconf_root=DIRNAME : Angabe des Verzeichnisses in dem sich das Sysconf-
                          Repository befindet.
 --dry-run : Trockenlauf, d.h. es wird alles ausgeführt nur die Client-Zugriffe
             nicht, also weder ssh-, rsh- noch Sysconf-Client-Zugriffe.
 --list_hosts_per_os=OS : Listet alle Rechner mit dem Betriebssystem OS auf.
                          z.B.: --list_hosts_per_os=Gentoo2007 none none none
 --list_hosts_subsys : Listet alle Rechner mit den zugeordneten Subsystemen auf.
                       z.B.: --list_hosts_subsys none ALL ALL
 --list_subsys_hosts : Listet alle Subsysteme und welche Rechner sie bekommen.
                       z.B.: --list_subsys_hosts none ALL ALL
 --list_variable=VAR : Listet die Variable VAR für alle angegebenen Rechner auf.
                          z.B.: --list_variable=SYSCONF_INTERFACE none none ALL

 Beispiele:
 'Führe einen Update von Sendmail auf den Rechner zeus durch':
 sysconf update sendmail zeus
 'Führe einen Update von allen Subsystemen auf den Rechner osiris durch':
 sysconf update ALL osiris
 'Verteile alle Subsysteme auf alle Rechner':
 sysconf update ALL ALL
 'Initialisiere alle Subsysteme auf hugo':
 sysconf init ALL hugo
 'Führe einen Update von Sendmail und Syslog auf die Rechner zeus, osiris und
 hugo durch':
 sysconf update sendmail,syslog zeus,osiris,hugo
 Repository auf Konsistenz testen, ohne die Client-Rechner zu verändern:
 sysconf --dry-run update ALL ALL

Hauptkonfigurationsdatei

In der Datei "/etc/sysconfrc" bzw. "./sysconfrc" bzw. "~/.sysconfrc" sind die Standardeinstellungen gespeichert. Mit SYSCONF_ROOT wird das Verzeichnis angegeben, in dem sich die "Konfigurationsdatenbank" befindet. SYSCONF_ROOT kann auch an der Kommandozeile durch "--sysconf_root=DIRNAME" angegeben werden. Mit HTMLDIR wird das Verzeichnis für die HTML-Dokumentation, die mit der Aktion 'documentation' erstellt wird, festgelegt.

Die nachfolgenden Einstellungen können optional angegeben werden:

Mit STYLESHEET kann ein Stylesheet und mit STYLESHEET_CLASS eine Stylesheet-Klasse für die HTML-Dokumentation angegeben werden.

Durch STOP_ON_ERROR=TRUE oder STOP_ON_ERROR=FALSE kann eingestellt werden, ob Sysconf bei einem Fehler abbrechen soll (Standard) oder nicht.

Mit LOGLEVEL kann der LOG-Level analog zum Kommandozeilenparameter w angegeben werden (Standard ist 7, d.h. alle Fehler, Warnungen und Infos ausgeben) aber die Angabe auf der Kommandozeile hat Vorrang. Der LOG-Level ergibt sich als Bitmaske mit den möglichen Bits:

 1:  alle Fehler (Genaue Fehlerbeschreibungen)
 2:  alle Warnungen (sollte man beachten)
 4:  alle Informationen (ganz informativ)
 8:  alle Debug-Informationen (ausführlicher Status, etc.)
 16: alle Remote-Shell-Aufrufe und Sysconf-Client-Aufrufe
 (Default ist 7, also 1+2+4)

So gibt beispielsweise 16 nur rsh-Meldungen aus, 2 nur Warnungen und 18 (=2+16) rsh-Meldungen und Warnungen. 9 (=1+8) würde z.B. nur Fehler und Debug-Meldungen ausgeben und 31 (=1+2+4+8+16) gibt alles aus.

Durch LOGFILE kann der Ort des Logfiles bestimmt werden. (Standard: /tmp/sysconf.log) Diese Einstellung kann auch per Option "--logfile=FILENAME" auf der Kommandozeile angegeben werden, wobei die Angabe auf der Kommandozeile höhere Priorität hat. Es kann auch ein Pipe angegeben werden, z.B. --logfile="|/bin/cronolog /var/log/sysconf/%Y/%m/%d"

Die Option CLIENT_PORT gibt die Portnummer an, über die Sysconf versuchen soll, zu dem optionalen sysconf-client-Programm Kontakt aufzunehmen.

Die Option CLIENT_PORT_SSL gibt die Portnummer an, über die Sysconf versuchen soll, zu dem optionalen sysconf-client-ssl-Programm Kontakt aufzunehmen. Dazu müssen dann auch noch die beiden Optionen für SSL eingetragen werden: SSL_CERT_FILE SSL_KEY_FILE

Mit der Option LANGUAGE kann zwischen folgenden Sprachen umgeschaltet werden:

  de_DE
  en_US

Beispiel für die Hauptkonfigurationsdatei:

 SYSCONF_ROOT=/var/adm/sysconf
 HTMLDIR=/http/htdocs/sysconf
 STYLESHEET=/styles/corporate-design.css
 STYLESHEET_CLASS=text
 STOP_ON_ERROR=TRUE
 LOGLEVEL=7
 LOGFILE=/var/log/sysconf.log
 CLIENT_PORT=3456
 LANGUAGE=de_DE

Es wird automatisch ermittelt, welche Kommandos zu Rechneransteuerung verwendet werden sollen. Zur Auswahl stehen: sysconf-client-ssl, sysconf-client, rsh/rcp, ssh/scp, rsync/rsh und rsync/ssh.

Sysconf-Client ist die optimale Methode. Dazu muss man nur das Programm sysconf-client auf den Rechnern starten, die von Sysconf verwaltet werden. Für sysconf-client muss der Rechner, auf dem Sysconf läuft, als authorisierter Rechner angegeben werden und natürlich die gleiche Portnummer wie bei Sysconf in CLIENT_PORT.

Es gibt auch eine SSL Variante von Sysconf-Client. Dazu bitte diese Optionen verwenden: CLIENT_PORT_SSL SSL_CERT_FILE SSL_KEY_FILE

Sysconf probiert bei jedem Start alle Möglichkeiten Kontakt zu einem Rechner herzustellen automatisch durch und zwar in dieser Reihenfolge: sysconf-client-ssl, sysconf-client, rsync/ssh, rsync/rsh, ssh/scp, und rsh/rcp. Mit dem Schalter -w7 kann man beobachten, welche Methode verwendet wird. rsh und ssh funktionieren nur, wenn es ohne Kennworteingabe möglich ist auf den anderen Rechner zuzugreifen. Es sollte also soetwas ohne Benutzereingaben funktionieren: "ssh rechner date".

Wenn der Rechner, der mit sysconf verwaltet wird, "localhost" heisst, dann wird kein Remote-Copy/Shell verwendet, sondern direkt auf dem Rechner gearbeitet, auf dem sysconf läuft.

Links zur erwähnten Software:
rsync
SSH
OpenSSH
SSH-FAQ

Konfigurationsdatenbank

Die Konfigurationsdatenbank enthält die Informationen welcher Rechner welche Files erhält und ist im Dateisystem als Verzeichnis-Struktur abgebildet:

 hosts.sc
 classes.sc
 variables/
     zeus.var
     osiris.var
     hugo.var
     ...
 AIX-4.1.5/
    dependencies.sc            (Abhängigkeiten der Subsysteme)
    dependencies-soft.sc       ("Weiche" Abhängigkeiten der Subsysteme)
    exclusions.sc              (Gegenseitige Ausschlüsse der Subsysteme)
    files.sc                   (Liste der Files pro Subsystem)
    commands.sc                (Optional, Remote-Kommandos mit vollen Pfaden)
    filedir.sc/                (Hier liegen alle Konfigurationsfiles)
       etc/rc.config
       etc/hosts
       etc/issue
       etc/exports
       root/profile
       var/lib/news/active
       var/lib/news/newsgroups
       usr/lib/news/nnrp.access
       usr/lib/news/hosts.nntp
       usr/lib/news/inn.conf
       ...
    syslog/
          installcmd
          removecmd
          testinstallcmd
          startcmd
          stopcmd
          reconfigcmd
          testruncmd
          pre_localshell
          post_localshell
    nfsserver/
          installcmd
          removecmd
          testinstallcmd
          startcmd
          stopcmd
          reconfigcmd
          testruncmd
          pre_localshell
          post_localshell
    newsserver/
    ...
    sendmail/
    ...
 AIX-4.3/
    dependencies.sc            (Abhängigkeiten der Subsysteme)
    dependencies-soft.sc       ("Weiche" Abhängigkeiten der Subsysteme)
    exclusions.sc              (Gegenseitige Ausschlüsse der Subsysteme)
    files.sc                   (Liste der Files pro Subsystem)
    commands.sc                (Optional, Remote-Kommandos mit vollen Pfaden)
    filedir.sc/                (Hier liegen alle Konfigurationsfiles)
       etc/rc.config
       etc/hosts
       ...
    syslog/
          installcmd
          removecmd
          ...
 Linux-SuSE-6.4/
    dependencies.sc            (Abhängigkeiten der Subsysteme)
    dependencies-soft.sc       ("Weiche" Abhängigkeiten der Subsysteme)
    exclusions.sc              (Gegenseitige Ausschlüsse der Subsysteme)
    files.sc                   (Liste der Files pro Subsystem)
    commands.sc                (Optional, Remote-Kommandos mit vollen Pfaden)
    filedir.sc/                (Hier liegen alle Konfigurationsfiles)
       etc/rc.config
       etc/hosts
       ...
    syslog/
          installcmd
          removecmd
          ...

In diesem Verzeichnisbaum können natürlich auch symbolische Links angelegt werden. Das dient dazu, doppelte Datenhaltung zu vermeiden. So kann sicherlich ein /etc/sudoers unter Linux, AIX und Solaris identisch aussehen. Das wäre dann z.B. so:

 lrwxrwxrwx 1 root root 46 Feb 15  2001 AIX_common/filedir.sc/etc/sudoers -> ../../../OS_independent/filedir.sc/etc/sudoers
 lrwxrwxrwx 1 root root 39 Sep 10  2002 AIX-5.1/filedir.sc/etc/sudoers -> ../../../AIX_common/filedir.sc/etc/sudoers
 lrwxrwxrwx 1 root root 46 Oct 20  2003 Linux-2.6/filedir.sc/etc/sudoers -> ../../../OS_independent/filedir.sc/etc/sudoers

Wie man sieht kann eine solche Verlinkung auch mehrstufig sein.

Optional unterstützt Sysconf auch Links in speziellen Dateien. Wenn man normalerweise einen Link von QUELLE nach ZIEL hat, dann legt man einfach statt QUELLE eine Datei QUELLE.LINK an, die als Inhalt den Text ZIEL hat. Die Logik im Sysconf ist folgende: Wenn eine Datei namens XYZ nicht existiert, dann wird nach XYZ.LINK gesucht und deren Inhalt ausgewertet. Der Inhalt von XYZ.LINK wird als neuer Dateiname interpretiert. Das können natürlich auch relative Pfadangaben sein. Das funktioniert auch für Verzeichnisse. Auch mehrstufige Links sind möglich. Durch diesen Verzicht auf symbolische Links wird eine Benutzung von CVS möglich oder die Ablage auf einem Filesystem, das keine symbolischen Links unterstützt. Beispiel:

 AIX_common/filedir.sc/etc/sudoers.LINK
 mit dem Inhalt:
 ../../../OS_independent/filedir.sc/etc/sudoers
 AIX-5.1/filedir.sc/etc/sudoers mit dem Inhalt:
 ../../../AIX_common/filedir.sc/etc/sudoers
 Linux-2.6/filedir.sc/etc/sudoers mit dem Inhalt:
 ../../../OS_independent/filedir.sc/etc/sudoers
 und in OS_independent/filedir.sc/etc/ liegt das eigentliche File.

Dateien variables/xxx.var

Beispielsweise enthält zeus.var Variablen speziell für den Rechner "zeus". Escapes ("\n") in Variablen werden nicht interpretiert! Aufbau:

 variable=wert

oder

 variable include FILENAME1 FILENAME2 ...

Im ersten Fall wird der Variable der Wert zugewiesen. Wenn kein Wert angegeben ist, dann wird die Variable auf den Leerstring gesetzt. Im zweiten Fall werden die angegebenen Dateien eingelesen und in der Inhalt nacheinander in der Variable gespeichert. Diese Files werden im Variablen-Verzeichnis gesucht.

Nachfolgende interne Variablen sind standardmässig definiert. Die Optionen SYSCONF_BACKUP und SYSCONF_BACKUP_EXTENSION werden durch die Backup-Option beeinflusst. Diese können z.B. in *cmd-Files verwendet werden.

 SYSCONF_BACKUP              mit den Werten TRUE und FALSE
 SYSCONF_BACKUP_EXTENSION    enthält die Backup-File-Endung
 SYSCONF_OS                  enthält das Sysconf-Betriebssystem aus hosts.sc
 SYSCONF_INTERFACE           enthält das Interface aus hosts.sc
 SYSCONF_CLASSES             enthält die Sysconf-Klassen aus hosts.sc
 SYSCONF_HOSTS_SC_SUBSYSTEMS enthält die Sysconf-Subsysteme aus hosts.sc
 SYSCONF_SUBSYSTEMS          enthält alle Subsysteme
 SYSCONF_VARFILE             enthält den Inhalt des Variablen-Files
 SYSCONF_REVISION            enthält die Revision aus hosts.sc

Alle mit SYSCONF_ beginnenden Variablen sind für zukünftige Verwendung reserviert und sollten daher nicht benutzt werden.

Beispiel:

 HOSTNAME        =zeus
 HOSTPURPOSE     =NFS-Server
 INITTAB         include inittab/tsm-client.inc
 IPFORWARDING    =0
 CRONTAB         include crontab/node.inc crontab/mksysb.inc

Datei files.sc

Beispiel:

 [boot]
 f etc/rc
 f etc/inittab

 [login]
 f etc/environment owner=root group=system
 F etc/passwd permission=644
 f etc/motd
 c reconfigcmd
 beginpattern
   change s!#BACKUP_SERVER!$BACKUPSERVER!;
 endpattern

 [adsmc]
 f etc/inittab
 f /etc/sendmail.cf

 [INN]
 f var/lib/news/expire.ctl.inn /var/lib/news/expire.ctl

 [CNEWS]
 f var/lib/news/expire.ctl.cnews /var/lib/news/expire.ctl

 INCLDUE files.sc.erweiterung

 [Compiler]
 L /usr/local/bin/rs6000-ibm-aix4.1.4.0-gcc /usr/local/bin/gcc

 [Modem]
 t etc/inittab
 beginpattern
   change s!#PORT!mo:123:respawn:/usr/local/sbin/vgetty $MODEMDEVICE!;
   adduniq m/^5:/6:123:respawn:/sbin/mingetty tty6
 endpattern

Die genaue Syntax lautet:

 [subsys]
 <fileentry>
 <patternblock>

 [subsys]:       Beginn Beschreibung Subsystem namens "subsys"
 <fileentry>:    <type> <filename> <zielfilename> <attribute ...>
 <patternblock>: hat folgenden Aufbau:
 beginpattern
 <pattern>
 endpattern

Die möglichen <pattern> sind im Abschnitt "Patternblock" erklärt.

Wenn der <type> kein Template-Typ ist, dann entfällt der <patternblock>

 <type>:
 instf : Installfile   (Nur bei INIT übertragen, vor installcmd)
 instt : Install-Template (Nur bei INIT übertragen, vor installcmd und
                           Ersetzungen aus dem Patternblock durchführen)
 instL : Install-Link  (Nur bei INIT anlegen, vor installcmd)
 instS : Shellkommando (Nur bei INIT ausführen, vor installcmd)
 initf : Initfile      (Nur bei INIT übertragen, nach installcmd)
 initt : Init-Template (Bei INIT übertragen und Ersetzungen
                        aus dem Patternblock durchführen)
 initL : Init-Link     (Nur bei INIT anlegen, nach installcmd)
 initS : Shellkommando (Nur bei INIT ausführen, nach installcmd)
 f     : File          (Bei UPDATE übertragen)
 t     : Template      (Bei UPDATE übertragen und Ersetzungen
                        aus dem Patternblock durchführen)
 L     : Link          (Bei UPDATE anlegen)
 S     : Shellkommando (Bei UPDATE ausführen)
 c     : Kommando-Template (Ersetzt Textmuster in Kommandofiles)
 lS    : lokales Shellkommando (Bei UPDATE+INIT ausführen)
 m     : Modify

 <filename>:     Kompletter Pfad des Files. Wenn das ein relativer
                 Pfad ist, dann liegt das File unterhalb von
                 files.sc/, sonst wird der absolute Pfad genommen.
 <zielfilename>: Optional. Kompletter Zielpfad+Name des Files.
 <attribute>:    Optional. Es sind folgende Attribute möglich:
                 owner=<Benutzername>
                 group=<Gruppenname>
                 permission=<oktale Datei-Rechte wie bei chmod>
                 hidden=<TRUE oder FALSE>. Default ist FALSE.
                 Mit hidden=TRUE wird verhindert, dass die Datei in der HTML-
                 Dokumentation auftaucht.
                 Wenn keine Attribute angegeben werden, dann werden die
                 Attribute des Files in der Sysconf-Datenbank verwendet.

Bei den Links wird wie auch bei "ln" üblich "Quelle Ziel" angegeben, es entsteht also ein Link von "filename" auf "zielfilename".

Die Shellkommandos sind dazu gedacht, dass man Verzeichnisse, Gerätedateien, Links, etc. anlegen oder entfernen kann. Als Shellkommandos ist alles möglich, was auch per "rsh" möglich ist, z.B.:

 cd /home/user ; ln -sf ../skel/.profile .

In den Shellkommandos werden die Variablen aus Dateien variables/xxx.var expandiert.

Die Kommandotemplates dienen dazu, dass man in den Kommando-Files *cmd (siehe weiter unten) auch Textersetzungen vor der Übertragung durchführen kann. Auf diese Art und Weise ist es möglich Variablen-Inhalte z.B. in das reconfigcmd einzubauen.

Der Modify-Typ dient erstens zur Dokumentation von Dateien, die z.B. durch eines der Kommandos (reconfigcmd) angelegt oder verändert werden und zweitens für die Berücksichtigung bei der Backup-Option. Diese Modify-Dateien existieren nicht im Repository.

Der spezielle Subsystemname "GLOBAL" bedeutet, dass diese Files nicht zu einem bestimmten Subsystem gehören, sondern global sind. Das sind also die Files und Konfigurationsdateien, die jeder (!) Rechner mit diesem Betriebssystem erhalten soll. Dieses Subsystem bekommen alle Rechner als erstes Subsystem.

Analog zu GLOBAL existiert das spezielle Subsystem "LAST", das alle Rechner als letztes Subsystem bekommen.

Mit der Anweisung INCLUDE gefolgt von einem Dateinamen relativ zum Ort der Datei files.sc kann man die files.sc um weitere Dateien erweitern. Im Extremfall besteht die files.sc nur aus INCLUDE-Anweisungen und die Subsystem-Definitionen sind alle in einzelne Dateien ausgelagert.

Kommando-Files *cmd

Es gibt folgende Kommando-Files, die beim Syscon-Lauf für ein Zielsystem ausgeführt werden:

  pre_localshell
  testinstallcmd
  installcmd
  testruncmd
  stopcmd
  reconfigcmd
  startcmd
  post_localshell

Es müssen alle Kommando-Files vorhanden sein. (Ausnahme sind die *_localshell) Wenn ein solches *cmd-Programm die Länge Null hat, dann wird es nicht verwendet! (Man braucht beispielsweise nicht immer ein startcmd.) Wenn Files für verschiedene Betriebssysteme identisch sind, dann kann man einfach einen Link legen. Alle Programme/Shellscripten müssen TRUE oder FALSE auf STDOUT ausgeben. Diese Programme werden auf dem Zielrechner ausgeführt.

Wenn ein solches Programm/Shellscript einen Returncode ungleich 0 liefert, dann bricht Sysconf mit einem "FATAL"-Fehler ab. Bei Ausgabe von FALSE auf STDOUT und Returncode 0 bei z.B. dem installcmd wird nur ein "ERROR"-Fehler protokolliert.

Mit den beiden Optionen CMD_USER und CMD_GROUP im Konfigurationsfile commands.sc (siehe unten) kann festgelegt werden, mit welchem Benutzer und Gruppe die Kommandos der Subsysteme (installcmd, reconfigcmd, etc.) angelegt werden. (Standard ist der effektive User und Gruppe, der Sysconf aufgerufen hat.)

Die Kommando-Files können analog zu den Daten in der "Konfigurationsdatenbank" mit *.LINK-Files verlinkt werden.

Kommentare

In den Dateien

 dependencies.sc
 dependencies-soft.sc
 exclusions.sc
 hosts.sc
 classes.sc

sind Kommentare möglich: Alle Zeilen, die mit '#' beginnen werden ignoriert.

Dateien hosts.sc und classes.sc

Die Datei hosts.sc beschreibt die einzelnen Rechner: In dieser Datei wird festgelegt welche Subsysteme die einzelnen Rechner bekommen sollen. Diese Datei ist in Strophenform aufgebaut, wobei eine Strophe immer mit dem Schlüsselwort HOST beginnen muss. Zur Übersichtlichkeit sollte man die Strophen durch eine Leerzeile trennen. Mit HOST wird der Rechnername angegeben. Dieser Name muss mit dem Namen der Variablendatei im Unterverzeichnis variables/ übereinstimmen. Durch OS wird das Betriebssystem festgelegt. Das ist eine frei wählbare Bezeichnung. Es muss ein gleichnamiges Unterverzeichnis im Sysconf-Hauptverzeichnis geben. Die Einträge hinter CLASSES und SUBSYSTEMS sind optional. Damit wird bestimmt, welche Subsysteme der Rechner erhalten soll. Im SUBSYSTEMS-Eintrag können einzelne Subsysteme auch negiert werden, indem ein "!" vorangestellt wird. Es werden dann alle Subsysteme der angegebenen Klassen und Subsysteme für diesen Rechner definiert ausser den Subsystemen, die mit "!" markiert sind. Optional kann auch mittels INTERFACE das zu verwendende Interface angegeben werden. Beispiel: Der Rechner abc123 hat unter dem Hostnamen abc123giga ein Gigabit-Ethernet. Dann kann man als HOST abc123 angeben unter INTERFACE abc123giga angeben und Sysconf betankt den Rechner über das Gigabit-Ethernet. Das ist auch sehr nützlich bei HACMP-Clustern. Da sollte man nicht den produktiven Hostnamen angeben, sondern den Hostnamen/Adapter, der nicht als Ressource "wandert", sondern immer auf den selben Rechner verweist, wie zum Beispiel ein Adapter im internen Verwaltungsnetz. Wenn man als HOST oder INTERFACE nur localhost angibt, dann wird der Rechner nicht remote angesteuert, sondern es wird direkt der Rechner angesprochen, auf dem Sysconf läuft. Statt Hostnamen können natürlich auch IP-Adressen angegeben werden. Optional kann auch noch mit REVISION ein String oder eine Zahl angegeben werden. Das ist z.B. dazu nützlich, wenn man das Sysconf-Repository unter einer Versionskontrolle wie CVS oder Subversion betreibt und für bestimmte Rechner bestimmte Versions-Stände dokumentieren will. Sysconf selbst verwendet das Feld REVISION überhaupt nicht. Dieser Wert kann nur mittels sysconf listrevision xxx ALL ausgegeben werden. Man kann auch die einzelnen Strophen der hosts.sc als Einzel-Dateien ins Verzeichnis hostsdir.sc legen. Die Dateien müssen alphanumerisch beginnen und mit .inc enden.

Beispiel:

 HOST         zeus
 OS           AIX-4.1.5
 CLASSES      Basissystem Client
 SUBSYSTEMS   sendmail tcpwrapper nfsclient adsm

 HOST         osiris
 INTERFACE    osirisgigabit
 OS           AIX-4.1.5
 CLASSES      Basissystem Server
 SUBSYSTEMS   mailclient newsserver nfsserver

 HOST         neptun
 REVISION     72356
 OS           Linux-SuSE-7.0
 CLASSES      Entwicklung Basissystem
 SUBSYSTEMS   inittab gcc2723 gmake libXpm mailclient adsm-client

 HOST         pinguin
 INTERFACE    localhost
 OS           Linux-SuSE-8.1
 CLASSES
 SUBSYSTEMS   inittab gcc295

Klassen können optional in der Datei classes.sc definiert werden:

 CLASSDEF    Basissystem
 SUBSYSTEMS  syslog tcpwrapper ssh

 CLASSDEF    Server
 SUBSYSTEMS  adsm audit nis

Die Klassen dienen dazu, Subsysteme zusammenzufassen. So kann man z.B. statt

 HOST         neptun
 OS           Linux-SuSE-7.0
 CLASSES
 SUBSYSTEMS   gcc2723 gmake ddd lex yacc perl mailclient adsm-client

diese Klasse definieren:

 CLASSDEF    Entwicklung
 SUBSYSTEMS  gcc2723 gmake ddd lex yacc perl

und sich dann in der hosts.sc entsprechend kurz fassen:

 HOST         neptun
 OS           Linux-SuSE-7.0
 CLASSES      Entwicklung
 SUBSYSTEMS   mailclient adsm-client

Eine Subsystem-Negierung (alles ausser "ddd") würde dann so aussehen:

 HOST         neptun
 OS           Linux-SuSE-7.0
 CLASSES      Entwicklung
 SUBSYSTEMS   mailclient !ddd adsm-client

Dabei sollten die Subsysteme möglichst fein aufgefächert werden, also, z.B.:

 - NIS-Master, NIS-Slave, NIS-Client
 - sendmail f. s_mailout, sendmail f. s_mailbox oder sendmail f. Client
 - ADSM-Server, ADSM-Client
 - Newsserver, Newsclient

Patternblock

In der Datei files.sc können im Patternblock für Templates Ersetzungsregeln angegeben werden nach denen die Template-Files verändert werden bevor sie kopiert werden. In dem Patternblock sind keine Kommentare möglich! Leerzeilen werden ignoriert. Die möglichen Syntax-Konstrukte lauten

 change <substitute>

 add FIRST <text>

 add LAST  <text>

 add <patternmatch>
 <text>

 adduniq FIRST <text>

 adduniq LAST <text>

 adduniq <patternmatch>
 <text>

 <substitute>:   Substitute-Kommando von Perl: s/.../.../
 <patternmatch>: Patternmatch-Kommando von Perl: m/.../.../
 <text>:         Text, der eingefügt werden soll.

Zu beachten: nach dem Patternmatch muss eine neue Zeile beginnen!

Die Variablen, die in variables/rechnername.var definiert wurden können mit vorangestelltem "$" verwendet werden. Escapes ("\n") in Variablen werden nicht interpretiert, aber man kann diese Funktionsweise nachbilden: Wenn man eine Variable mit Newlines hat, z.B.

 VAR=Das\nsind\nviele\nZeilen\ngetrennt\ndurch\nNewlines\n

dann muss man selbst dafür sorgen, dass die Sonderzeichen interpretiert werden:

 change s/suchtext/($VAR=~s!\\n!\n!g,$VAR)/e;

Wenn man aber z.B. sicher sein will, dass eine Variable keine Newlines enthält, dann erreicht man das mit dieser Zeile:

  change s/ROOTDISK/($ROOTDISK=~s:\n::g,$ROOTDISK)/e

Erwähnenswert ist zudem, dass in den "e"-Varianten (s/xxx/xxx/e) auch Variablen ausgewertet werden können, wenn man "eval" benutzt, z.B.:

 change s/suchtext/eval $MY_SPECIAL_PERL_CODE/e

Dabei wird der Inhalt der Variablen $MY_SPECIAL_PERL_CODE als Code ausgeführt und das Ergebnis ersetzt dann "suchtext".

Beispiele:

 Zeilen verändern:
   change s/#MEINE_IP#/10.135.82.54/
   change s/#MEIN_NAME#/$RECHNER/
   change s/#ANWENDUNG#/Rechner Testbetrieb/
   change s/^"START_INN=.*/"START_INN=yes"/
   change s/SC_GESCHWINDIGKEIT/$MODEMSPEED/
 Zeilen löschen:
   change s/^netstat\s+stream\s+tcp//
 Zeilen einfügen:
 Vor der ersten Zeile einfügen:
   add FIRST 127.0.0.1       localhost
 Nach der letzten Zeile einfügen:
   add LAST 129.187.13.89 mailhost mail
 Nach der Zeile, die mit "OVERVIEW" beginnt einfügen:
   add m/^OVERVIEW/
   news/newsserver:*,!junk,!control*:Ap,Tf,Wnm:news
 Zeile nur hinzufügen, wenn sie im File noch nicht vorhanden ist:
   adduniq m/^6:123:respawn:/
   mo:123:respawn:/usr/local/sbin/vgetty modem
 Zeile, die mit TCPWindowsize beginnt komplett löschen:
   change s/^TCPWindowsize.*\n//

dependencies.sc

Die Datei "dependencies.sc" hat den Aufbau:

 S : D1 D2 D3 ...

Bedeutung: Subsystem "S" hängt von Subsystemen "D1", "D2", "D3", ... ab. Das heisst, dass die Subsysteme D1, D2, D3, ... noch in die Liste der Subsysteme mit dazugenommen und noch vor S verteilt werden. Beispiele:

 sendmail : syslog
 nfsserver : tcpwrapper portmap inetd

dependencies-soft.sc

Die Datei "dependencies-soft.sc" hat den Aufbau:

 S : D1 D2 D3 ...

Bedeutung: Subsystem "S" hängt "weich" von Subsystemen "D1", "D2", "D3", ... ab. Das heisst, dass wenn die Subsysteme D1, D2, D3, ... für diesen Rechner erlaubt sind, dann werden sie noch in die Liste der Subsysteme mit dazugenommen und noch vor S verteilt. Beispiele:

 ssh : ldap

exclusions.sc

Die Datei "exclusions.sc" hat den Aufbau:

 S1 S2

Bedeutung: Subsystem "S1" und Subsystem "S2" schliessen sich gegenseitig aus. Beispiele:

 mailclient mailserver
 gcc2723 egcs1111
 sendmail qmail

commands.sc

Die Datei "commands.sc" beschreibt, welche Kommandos remote auzuführen sind. Diese Datei ist optional, aber aus Sicherheitsgründen zu empfehlen. Wenn diese Datei fehlt, dann werden die Kommandos ohne absoluten Pfad ausgeführt. Wenn einzelne Kommandos in dieser Datei nicht aufgeführt sind, werden auch diese ohne Pfad aufgerufen.

Speziell für den cp-Befehl empfiehlt es sich diese Datei zu verwenden, denn cp benötigt unter den verschiedenen Unices unterschiedliche Schalter, um symbolische Links korrekt zu kopieren. Ich empfehle unter Linux "cp -pd", unter AIX "cp -ph" und ab Solaris 10 "cp -rpP".

Mit den beiden Optionen CMD_USER und CMD_GROUP kann festgelegt werden, mit welchem Benutzer und Gruppe die Kommandos der Subsysteme (siehe "Kommando-Files *cmd") wie z.B. installcmd, reconfigcmd, etc. angelegt werden. (Standard ist der effektive User und Gruppe, der Sysconf aufgerufen hat.)

Durch die Option REMOTE_USER kann bestimmt werden, unter welchem Benutzer die rsh/ssh/rsync-Zugriffe erfolgen sollen. (Default: Der Benutzer, unter dem Sysconf gestartet wurde)

Mit der Option USE_SUDO (Default FALSE) kann man einen Zwischenschritt auf dem Client aktivieren. Das ist eigentlich nur sinnvoll, wenn Sysconf nicht als Root läuft oder der Sysconf-Client nicht unter Root gestartet wurde. Normalerweise laufen die Remote-Copy- und Remote-Shell-Funktionen unter dem User, der Sysconf startet. Es wird also beispielsweise, wenn Sysconf als Root läuft, auf dem Client ein Shell-Kommando auch als Root ausgeführt. Wenn man nun aber aus Sicherheitsgründen Sysconf nicht als Root laufen lassen will, aber auf dem Client trotzdem Files verändern muss, die Root gehören, dann kann man mit USE_SUDO=TRUE den Aufruf von sudo zwischenschalten. (Wie das sudo-Programm mit vollem Pfad heisst, kann man natürlich in commands.sc einstellen.) Normalerweise wird ein Remote-Copy so ausgeführt: "rcp sendmail.cf client:/etc/sendmail.cf" und eine Remote-Shell so: "rsh client command". Mit sudo läuft es so: "rcp sendmail.cf client:/tmp ; rsh client sudo mv /tmp/sendmail.cf /etc/sendmail.cf" respektive "rsh client sudo commando". In /etc/sudoers muss man etwas in dieser Art eintragen: "mysysonfuser ALL=NOPASSWD:ALL"

Mit der Option SSH_KEY kann man den Ort eines alternativen SSH-Key angeben. Das braucht man in der Regel immer dann, wenn man auch einen REMOTE_USER angegeben hat.

Beispiel für AIX:

 CP=/usr/bin/cp -ph
 RM=/usr/bin/rm
 LN=/usr/bin/ln
 DIFF=/usr/bin/diff
 CHOWN=/usr/bin/chown
 CHMOD=/usr/bin/chmod
 MKDIR=/usr/bin/mkdir
 MV=/usr/bin/mv
 SUDO=/usr/bin/sudo -H
 CMD_USER=root
 CMD_GROUP=system
 REMOTE_USER=root
 USE_SUDO=FALSE
 SSH_KEY=/home/myotheruser/.ssh/id_dsa

RETURN

Sysconf beendet sich mit folgenden Returncodes:

 0 = kein Fehler aufgetreten
 1 = es sind Warnungen (WARN) aufgetreten
 2 = es sind Fehler (ERROR) aufgetreten
 3 = es sind fatale Fehler (FATAL) aufgetreten

Keine Rückgabewerte.

KNOWN BUGS AND PROBLEMS

Unter AIX kommt es beim Versuch ein ausführbares File, das gerade ausgeführt wird, zu überschreiben zu dieser Fehlermeldung: "Cannot open or remove a file containing a running program." oder "Text file busy". Das lässt sich nur umgehen, indem man durch start- und stop-Skripte sicherstellt, dass das betroffene Progamm durch Sysconf beendet wird. Wenn das, wie bei Dämons, nicht praktikabel ist, so würde ich empfehlen, das File nicht direkt zu überschreiben, sondern ein temporäres File anzulegen und dieses dann durch reconfigcmd umzukopieren, also in files.sc:

  f usr/local/sbin/mydaemon /usr/local/sbin/mydaemon.tmp

und im reconfigcmd etwas in der Art:

  rm /usr/local/sbin/mydaemon && \
  mv /usr/local/sbin/mydaemon.tmp /usr/local/sbin/mydaemon

Umgehen kann man diese Problematik durch die Verwendung von rsync.

AUTHOR

Sysconf wurde geschrieben von Stephan Löscher, loescher@gmx.de, 1998.
Die Idee zu Sysconf wurde angeregt durch: GNU CFEngine, rdist, Michael Mattes, Software Update Protocol (SUP) der Carnegie-Mellon Universität (CMU). Eine ähnliche Software ist Puppet oder Chef.
Mein Dank für Fehlerkorrekturen und neue Features geht an:
Michael Mattes
Andreas Bußjäger

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 6719:

Non-ASCII character seen before =encoding in 'natürlicher'. Assuming UTF-8