sysconf - Systemkonfiguration
sysconf [options] action subsystem machineEine 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 ALLIn 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_USBeispiel 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_DEEs 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: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/sudoersWie 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.Beispielsweise enthält zeus.var Variablen speziell für den Rechner "zeus". Escapes ("\n") in Variablen werden nicht interpretiert! Aufbau:
variable=wertoder
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.scAlle 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.incBeispiel:
[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
endpatternDie genaue Syntax lautet:
[subsys]
<fileentry>
<patternblock>
[subsys]: Beginn Beschreibung Subsystem namens "subsys"
<fileentry>: <type> <filename> <zielfilename> <attribute ...>
<patternblock>: hat folgenden Aufbau:
beginpattern
<pattern>
endpatternDie 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.
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_localshellEs 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.
In den Dateien
dependencies.sc
dependencies-soft.sc
exclusions.sc
hosts.sc
classes.scsind Kommentare möglich: Alle Zeilen, die mit '#' beginnen werden ignoriert.
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 gcc295Klassen können optional in der Datei classes.sc definiert werden:
CLASSDEF Basissystem
SUBSYSTEMS syslog tcpwrapper ssh
CLASSDEF Server
SUBSYSTEMS adsm audit nisDie 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-clientdiese Klasse definieren:
CLASSDEF Entwicklung
SUBSYSTEMS gcc2723 gmake ddd lex yacc perlund sich dann in der hosts.sc entsprechend kurz fassen:
HOST neptun
OS Linux-SuSE-7.0
CLASSES Entwicklung
SUBSYSTEMS mailclient adsm-clientEine Subsystem-Negierung (alles ausser "ddd") würde dann so aussehen:
HOST neptun
OS Linux-SuSE-7.0
CLASSES Entwicklung
SUBSYSTEMS mailclient !ddd adsm-clientDabei 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, NewsclientIn 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\ndann 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)/eErwä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/eDabei 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//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 inetdDie 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 : ldapDie Datei "exclusions.sc" hat den Aufbau:
S1 S2Bedeutung: Subsystem "S1" und Subsystem "S2" schliessen sich gegenseitig aus. Beispiele:
mailclient mailserver
gcc2723 egcs1111
sendmail qmailDie 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_dsaSysconf 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) aufgetretenKeine Rückgabewerte.
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.tmpund im reconfigcmd etwas in der Art:
rm /usr/local/sbin/mydaemon && \
mv /usr/local/sbin/mydaemon.tmp /usr/local/sbin/mydaemonUmgehen kann man diese Problematik durch die Verwendung von rsync.
Hey! The above document had some coding errors, which are explained below:
Non-ASCII character seen before =encoding in 'natürlicher'. Assuming UTF-8