Universitätsrechenzentrum
Funktionsadmins

Hinweise für LINUX-Funktionsadmins

Funktionsadmins teilen sich die Gesamtverantwortung für einen Host mit den Sysadmins und Softwareadmins. Im Regelfall sind die Sysadmins für die Konfiguration und die unten beschriebene Bereitstellung der Konfigurations-Prototypen verantwortlich. In bestimmten Situationen ist es aber sinnvoll, wenn der Funktionsadmin selbst in der Lage ist, die Konfiguration zu verändern.

Nachfolgende Erläuterungen und Hinweise gehen von einem (fiktiven) Beispiel-Szenario aus:
  • Hostname: magog
  • System-Plattform: SL_6.5_x86_64
    • der Bezeichner für eine Systemplattform setzt sich zusammen aus: <distribution>_<bs-version>_<architektur>
  • Funktionsklasse: FU_REFERENZ_SERVER
    • der Bezeichner für ein Funktionsklasse fasst alle Hosts mit identischer Funktionalität zusammen übliche Konvention für solche Bezeichner: FU_[<institution>_]<functionname>_{SERVER | WS | DEVEL_MISC}
  • Funktionsadmin: Nutzerkennzeichen abcxyz

ROOT-Repos für Konfigurations-Prototypen

Konfigurationsfiles werden nicht direkt auf dem System gepflegt, sondern indirekt über Prototypen, die sich in geeigneten ROOT-Repositories befinden.

Demzufolge ergibt sich die Änderung eines Konfigurationsfiles im Systemfilesystem durch eine Folge von Aktionen:
  • Erzeugen oder Ändern des Prototypen im ToSCA-Repo
  • Cfengine -Wartungslauf, um den Prototyp im System zu speichern:
    • entweder direkt durch Ausführen des Kommandos /usr/local/bin/sys_update oder
    • indirekt durch turnusmäßig per cron gestartete Wartungsläufe
  • evtl. muss die von der Konfigurationsänderung betroffene Systemkomponente neu gestartet werden (ist meist automatischer Bestandteil eines Cfengine -Wartungslaufes)
ROOT-Repos befinden sich im AFS unterhalb von
/afs/tu-chemnitz.de/ToSCA/ROOTS
und bilden die Struktur des Systemfilesystem nach, soweit erforderlich. Es existieren verschiedene solcher Repos, z. B. pro Funktionsklasse 
$ cd /afs/tu-chemnitz.de/ToSCA/ROOTS
$ ls -d */FU_REFERENZ_SERVER
 LINUX/FU_REFERENZ_SERVER
 SL_6/FU_REFERENZ_SERVER
 SL_6_x86_64/FU_REFERENZ_SERVER
 SL_6.5_x86_64/FU_REFERENZ_SERVER
sowie für jeden Host 
$ cd /afs/tu-chemnitz.de/ToSCA/ROOTS
$ ls -d */magog
 SL_6.5_x86_64/magog
In welches Repository legt man Prototypen für Konfigurationsfiles ab?
Repo-Verzeichnis geeignet für Prototypen, die gültig sein sollen
LINUX/FU_REFERENZ_SERVER für alle LINUX-Hosts dieser Funktionsklasse
SL_6/FU_REFERENZ_SERVER für alle SL_6-Hosts dieser Funktionsklasse (unabhängig von der Minor-SP-Klasse bzw. Architektur)
SL_6_x86_64/FU_REFERENZ_SERVER für alle SL_6_x86_64-Hosts dieser Funktionsklasse (unabhängig von der Minor-SP-Klasse)
SL_6.5_x86_64/FU_REFERENZ_SERVER für alle SL_6.5_x86_64-Hosts dieser Funktionsklasse
SL_6.5_x86_64/magog nur für diesen Host

Spezielle LINUX-Konfigurationsfiles, die für Funktionsadmin von Bedeutung sind

Alle nachfolgend aufgeführten Konfigurationsfiles werden von den Systemplattformadmins des URZ gepflegt. Die Funktionsadmins sollten aber das Grundprinzip kennen, da in einzelnen Fällen eine Kommunikation zwischen Funktions- und Systemplattformadmin notwendig sein kann.

login.access

In login.access wird die Zugangskontrolle zu den Host dieser Funktionsklasse spezifiziert, d.h. wer darf sich anmelden und von welchen anderen Hosts (Details siehe man login.access).

Z.B. sollen sich alle URZ-Mitarbeiter (Netzgruppe @urz_mitarbeiter), der Spezialnutzer not (sog. Notfall-Nutzer) sowie der Nutzer abcxyz von überall anmelden können: 
...
+ : @urz_mitarbeiter not abcxyz : ALL
...
Der Prototyp von login.access wird pro Funktionsklasse und LINUX identisch gepflegt:
/afs/tu-chemnitz.de/ToSCA/ROOTS/LINUX/FU_REFERENZ_SERVER/etc/login.access

hosts.allow

Das File hosts.allow dient der Zugangskontrolle von Nutzern/Diensten anderer Hosts. Für bestimmte Hosts/Netzwerke kann hier der Zugriff auf bestimmte lokale Dienste explizit gestattet werden (Details siehe man hosts.allow).

Der Prototyp von hosts.allow wird pro Funktionsklasse und LINUX identisch gepflegt:
/afs/tu-chemnitz.de/ToSCA/ROOTS/LINUX/FU_REFERENZ_SERVER/etc/hosts.allow

daemon.conf

Beim Booten des Systems werden Dienste (Daemons) automatisch gestartet. Im sog. rc -Script wird festgelegt, in welchen Run-Levels und mit welcher Priorität der Daemon standardmäßig gestartet werden soll. Zum Beispiel soll der Daemon afs im rc -Script /etc/rc.d/init.d/afs in den Run-Levels 3,4 und 5 gestartet werden. Die Startpriorität soll 35 und die Stop-Priorität 88 sein. Entsprechend müssen folgende Zeilen im rc -Script enthalten sein: 
# chkconfig: 345 35 88
# description:  OpenAFS is a distributed filesystem.
Im File daemon.conf sind alle Daemons enthalten, die beim nächsten Booten des Systems automatisch gestartet werden müssen. Alle dort nicht enthaltenen Daemons werden automatisch deaktiviert und demzufolge auch nicht beim nächsten Booten gestartet. Zum Beispiel soll der Daemon afs als rc -Script (/etc/rc.d/init.d/afs) direkt gestartet sowie sshd über xinetd aktiviert (/etc/xinetd.d/sshd) werden: 
$ cat .../SL_6/FU_REFERENZ_SERVER/etc/daemon.conf
...
afs:rc
...
sshd:xinetd
...
Die Aktivierung/Deaktivierung erfolgt beim nächsten Wartungslauf durch das Script /afs/tu-chemnitz.de/ToSCA/SCRIPTS/LINUX/daemon_config.sh.
Bei einer Änderung von daemon.conf erfolgt das Aktivieren bzw. Deaktivieren von Daemons, jedoch nicht automatisch das Beenden bzw. Starten der betreffenden Daemons im laufenden Betrieb.
Der Prototyp von daemon.conf wird pro Funktionsklasse und AI-SP-Klasse identisch gepflegt:
/afs/tu-chemnitz.de/ToSCA/ROOTS/SL_6/FU_REFERENZ_SERVER/etc/daemon.conf

daemon.local.conf

Als Erweiterung zu daemon.conf existiert für jeden Host ein Prototyp von daemon.local.conf.
/afs/tu-chemnitz.de/ToSCA/ROOTS/SL_6.5_x86_64/magog/etc/daemon.local.conf
Dieses File muss existieren, ist aber im Normalfall leer. Dort können all jene Daemons eingetragen werden, die zusätzlich zum o.g. daemon.conf -File für diesen Host gestartet werden soll.

Definition der Paketmenge

in folgenden Konfigurationsfiles wird der Paketbestand festgelegt:
  • rpm_accept.global.conf
  • rpm_accept.spec.conf (optional)
  • rpm_accept.local.conf
Für den Inhalt dieser Files ist ausschließlich der Softwareadmin der BS-Familie verantwortlich.
In diesen Files wird definiert, welche RPM-Pakete auf einem virtuellen oder realen Hosts installiert sein sollen. Für jedes zu installierende Paket existiert eine Zeile in der Notation <paketname>.<architektur>
Auf diesem Wege erfolgt keine Versionsverwaltung. Die Version eines RPM-Paketes wird durch zentrale SW-Repositories gesteuert. Grundsätzlich werden nur die jeweils aktuellen Versionen installiert.
Für jeden Host existiert der Prototyp von rpm_accept.local.conf als Ergänzung zu rpm_accept.global.conf. Ggf. ist das Konfigurationsfile leer.

crontab

In crontab wird festgelegt, welche Cronjobs zu welchen Zeitpunkten gestartet werden sollen. Für jeden Host existiert der Prototyp von crontab .
/afs/tu-chemnitz.de/ToSCA/ROOTS/SL_6.5_x86_64/magog/etc/crontab
Die Minuten-Angaben in diesem File werden automatisch generiert, so dass gesichert ist, dass sich die Cronjobs aller administrierten Hosts über den Zeitraum einer Stunde gleichmäßig verteilen.

sudoers.global

Dieses File enthält standardisierte sudoers -Spezifikationen entsprechend der im URZ festgelegten Management-Policies. Für jeden Host wird sudoers.global automatisch generiert.
/afs/tu-chemnitz.de/ToSCA/ROOTS/SL_6.5_x86_64/magog/etc/sudoers.global
sudoers.global File darf nicht von Hand modifiziert werden.

sudoers.local

Dieses File enthält evtl. notwendige Erweiterungen, die nur für diesen Host gelten sollen. Für jeden Host existiert der Prototyp von sudoers.local als Ergänzung zu sudoers.global.
/afs/tu-chemnitz.de/ToSCA/ROOTS/SL_6.5_x86_64/magog/etc/sudoers.local
sudoers.local muss existieren und ist normalerweise leer.
Per Script werden suders.global und sudoers.local gemischt und als sudoers -Konfigfile unter /etc/sudoers abgelegt.

sysctl.d/*.conf

Diese Files enthalten Einstellungen für Kernel-Parameter. In den meisten Fällen werden diese Files nicht benötigt.
Das Format der Files entspricht dem Aufbau von /etc/sysctl.conf. Einstellungen von Kernel-Parametern sollten in einzelnen Files (entsprechend einer konkreten Anwendung) vorgenommen werden. Die Einstellungen werden während des Boot-Vorgangs durch das Script /etc/rc.d/init.d/sysctl in den laufenden Kernel übernommen. Auf diesem Wege vorgenommene Einstellungen haben Vorrang vor den Einstellungen in /etc/sysctl.conf, was deshalb immer unverändert bleiben sollte.

resolv.conf

/etc/resolv.conf wird zentral für alle Linux-Systeme verteilt. Deshalb können keine eigenen individuellen Prototypen für einzelne Rechner oder die zur Funktionsklasse gehörenden Rechner konfiguriert werden. Wird ein spezieller search -Pfad gewünscht, so kann das durch Setzen der Environment-Variable LOCALDOMAIN erfolgen.
siehe: man resolv.conf

LOG-Repos für Host-spezifische Daten

Für jeden Host wird ein LOG-Verzeichnis eingerichtet.
/afs/tu-chemnitz.de/ToSCA/LOGS/SL_6.5_x86_64/magog
Hier werden alle den Host betreffenden Informationen gespeichert, die für die Systemadministration von Bedeutung sein können, z. B.
  • Logfiles von cron -Jobs
  • Informationen über den aktuellen HW- und SW-Bestand des Systems
  • Kopien von Konfigurationsfiles, die dynamisch während des Betriebes von bestimmten Systemkomponenten verändert werden und deshalb nicht über Prototypen gepflegt werden können, z. B.
    • etc_grub.conf
    • etc_fstab

Eine ausgewählte Menge dieser Informationen wird einmal am Tag aufbereitet und auf dem Monitoring-Server ins Web gestellt.

Abhängig von Funktionalität und Einrichtung gelten folgende URLs zu den Monitoringsystemen.
(Detailinformationen sind nur den Funktionsverantwortlichen der Systeme zugänglich.)

Server Entwicklungssysteme
  alle anderen Einrichtungen UBC und URZ
http://bb.hrz.tu-chemnitz.de/ https://bb1.hrz.tu-chemnitz.de/ https://bb2.hrz.tu-chemnitz.de/

Software-Bereitstellung und Software-Repos

zentrale SW-Repos für vom URZ administrierte Systeme

Es gibt eine Vielzahl von Paket-Repositories für RPM-Pakete für Red Hat- bzw. Fedora-basierte Linux-Systeme. Die Installation aus diesen Repos ist meist einfach über yum möglich, kann aber problematisch sein, was die Verträglichkeit mit den anderen installierten RPM-Paketen betrifft. Systeme, die durch das URZ administriert werden, erhalten ihre SW-Pakete aus zentralen ToSCA-SW-Repos, die durch die Softwareadmins des URZ gepflegt, überwacht und konsistent gehalten werden.
Dies sichert insbesondere, dass
  • kritische SW-Pakete vor der Freigabe in die zentralen Repos gezielt getestet werden können, bevor sie auf Systeme automatisch verteilt werden
  • die Konsistenz der Gesamtmenge aller SW-Pakete gewährleistet ist
  • die Systeminstallationen reproduzierbar sind, z. B. bei Ausfall oder Wechsel des Hosts
Die zentralen SW-Repos werden einheitlich für jede Distribution konfiguriert und auf jedem System einheitlich per cfengine bereitgestellt. 
/etc/yum.repos.d/base.repo               # Basisrepo der Distribution (z. B. SL_6.5_x86_64)
/etc/yum.repos.d/urz_updates.repo        # Repo für freigegebene SW-Updates der Distribution (z. B. SL_6.5_x86_64)
/etc/yum.repos.d/urz_contrib_major.repo  # URZ_CONTRIB-Repo (unabhängig von der Minor-Release, z. B: für alle SL_6_x86_64)
/etc/yum.repos.d/urz_contrib.repo        # URZ_CONTRIB_REPO für die Minor-Release, z. B: SL_6.5_x86_64

URZ_CONTRIB-Repos

Über die URZ_CONTRIB-Repos ist es möglich, spezielle zusätzliche SW-Pakete bereitzustellen. Das ist insbesondere für SW-Pakete sinnvoll, die von allgemeinem Interesse sind und auf mehreren (vielen, allen) Systemen installiert werden sollen. Falls RPM-Pakete installiert werden sollen, die nicht in der betreffenden Distribution enthalten sind, so muss dies unter Beachtung folgender Regeln geschehen:
  • zusätzliche Pakete müssen verträglich zu den Paketen der Distribution sein
  • die Installation der Pakete darf nur aus den dafür vorgesehenen ToSCA-SW-Repos erfolgen

dienstspezifische Software für Serversysteme

Unter gewissen Voraussetzungen kann durch einen Funktionsadmin beantragt werden, zusätzliche RPM-Pakete aus speziellen SW-Repos zu installieren:
  • es handelt sich um ein virtuelles bzw. reales Systemen, das als Produktionsserver (FU_*_SERVER) oder Entwicklungssystem (FU_*_DEVEL_MISC) klassifiziert ist
  • die SW-Pakete sind zur Erbringung der Dienste erforderlich
  • die SW-Pakete stehen nicht in Konflikt zu den RPM-Paketen der Distribution bzw. den aus URZ_CONTRIB bereitgestellten Paketen
  • die System- und Softwarewartungs- sowie Pflegemaßnahmen durch den Auftragnehmer (einschließlich System-Upgrade) werden nicht beeinträchtigt
  • der Auftraggeber übernimmt die inhaltliche Verantwortung für den Betrieb der zusätzlichen SW

Hinweise für WINDOWS-Funktionsadmins bzw. Selfadmins

Nachfolgende Ausführungen beziehen sich auf die BS-Familie WIN7 (d.h. die Systemplattformen W2008_6.1_x86_64 und W7_6.1_X86).

Funktionsadmins teilen sich die Gesamtverantwortung für einen Host (Windows-PC oder -Server) mit den Selfadmins und den Sysadmins.

Im Regelfall sind die Sysadmins für die Konfiguration und die unten beschriebene Bereitstellung der Konfigurations-Prototypen verantwortlich, Funktions- bzw. Selfadmins sollten die Prinzipien zumindest kennen und verstehen. In bestimmten Situationen kann es sinnvoll sein, wenn der Funktions- bzw. Selfadmin selbst in der Lage ist, die Konfiguration zu verändern.

Nachfolgende Erläuterungen und Hinweise gehen von einem (fiktiven) Beispiel-Szenario aus:
  • Hostname: moser
  • System-Plattform: W2008_6.1_x86_64
    • der Bezeichner für eine Systemplattform setzt sich zusammen aus: <distribution>_<bs-version>_<architektur>
  • Funktionsklasse: FU_UB_LIBERO_TS_SERVER
    • der Bezeichner für ein Funktionsklasse fasst alle Hosts mit identischer Funktionalität zusammen übliche Konvention für solche Bezeichner: FU_[<institution>_]<functionname>_{SERVER | WS | DEVEL_MISC}
  • ein oder mehrere Funktionsadmins für alle Hosts der gleichen Funktionsklasse
  • beim SelfADM?-Diensten: ein oder mehrere Selfadmins die lokale Administrationsverantwortung für jeweils einen Host der Funktionsklasse.

ROOT-Repos für Konfigurations-Prototypen

Konfigurationsfiles werden nicht direkt auf dem System gepflegt, sondern indirekt über Prototypen, die sich in geeigneten ROOT-Repositories befinden. Demzufolge ergibt sich die Änderung eines Konfigurationsfiles im Systemfilesystem durch eine Folge von Aktionen:
  • Erzeugen oder Ändern des Prototypen im ToSCA-Repo
  • Cfengine -Wartungslauf, um den Prototyp im System zu speichern:
    • entweder Stoppen/Starten des Dienstes cfengine oder
    • indirekt durch turnusmäßig per cron gestartete Wartungsläufe
  • evtl. muss die von der Konfigurationsänderung betroffenene Systemkomponente neu gestartet werden (ist meist automatischer Bestandteil eines Cfengine -Wartungslaufes)
ROOT-Repos befinden sich im AFS unterhalb von
\\afs\tu-chemnitz.de\ToSCA\ROOTS
bzw.
u:\tu-chemnitz.de\ToSCA\ROOTS
und bilden die Struktur des Systemfilesystem nach, soweit erforderlich. Es existieren verschiedene solcher Repos, z.B. pro Funktionsklasse 
$ U:
$ cd tu-chemnitz.de/ToSCA/ROOTS
$ ls -d */FU_UB_LIBERO_TS_SERVER
 WIN7/FU_UB_LIBERO_TS_SERVER
 W2008_6.1_x86_64/FU_UB_LIBERO_TS_SERVER
sowie für jeden Host 
$ U:
$ cd tu-chemnitz.de/ToSCA/ROOTS
$ ls -d */moser
 W2008_6.1_x86_64/moser
In welches Repository legt man Prototypen für Konfigurationsfiles ab?
Repo-Verzeichnis geeignet für Prototypen, die gültig sein sollen verantwortlich
WIN7/FU_UB_LIBERO_TS_SERVER für alle WIN7-Hosts dieser Funktionsklasse Sysadmin, Funktionsadmin
W2008_6.1_x86_64/FU_UB_LIBERO_TS_SERVER für alle W2008_6.1_x86_64-Hosts dieser Funktionsklasse Sysadmin, Funktionsadmin
W2008_6.1_x86_64/moser nur für diesen Host Sysadmin, Funktionsadmin, Selfadmin

Spezielle WIN7-Konfigurationsfiles, die für Funktionsadmins von Bedeutung sind

Alle nachfolgend aufgeführten Konfigurationsfiles werden von den Sysadmins bzw. Softawareadmins des URZ gepflegt. Die Funktions- bzw Selfadmins sollten aber das Grundprinzip kennen, da in einzelnen Fällen eine Kommunikation zwischen Funktions-, Self- und Sysadmins notwendig sein kann.

Definition der Paketmenge

in folgenden Konfigurationsfiles wird der Paketbestand festgelegt:
  • wpm_accept.global.conf
  • wpm_accept.spec.conf (optional)
  • wpm_accept.local.conf
Für den Inhalt dieser Files ist ausschließlich der Softwareadmin der BS-Familie verantwortlich. In diesen Files wird definiert, welche wpm-Pakete auf einem virtuellen oder realen Host installiert sein sollen. Für jedes zu installierende Paket existiert eine Zeile in der Notation <paketname>
Auf diesem Wege erfolgt keine Versionsverwaltung. Die Version eines wpm-Paketes wird durch zentrale SW-Repositories gesteuert. Grundsätzlich werden nur die jeweils aktuellen Versionen installiert.
Für jeden Host existiert der Prototyp von wpm_accept.local.conf als Ergänzung zu wpm_accept.global.conf. Ggf. ist das Konfigurationsfile leer.

crontab

In crontab wird festgelegt, welche Cronjobs zu welchen Zeitpunkten gestartet werden sollen. Für jeden Host existiert der Prototyp von crontab .
\\afs\tu-chemnitz.de\ToSCA\ROOTS\W2008_6.1_x86_64\moser\Programme\cygwin\etc\crontab
Die Minuten-Angaben in diesem File werden automatisch generiert, so dass gesichert ist, dass sich die Cronjobs aller administrierten Hosts über den Zeitraum einer Stunde gleichmäßig verteilen.

LOG-Repos für Host-spezifische Daten

Für jeden Host wird ein LOG-Verzeichnis eingerichtet.
\\afs\tu-chemnitz.de\ToSCA\LOGS\W2008_6.1_x86_64\moser
Hier werden alle den Host betreffenen Informationen gespeichert, die für die Systemadministration von Bedeutung sein können, z.B.
  • Logfiles von cron -Jobs
  • Informationen über den aktuellen HW- und SW-Bestand des Systems
  • Kopien von Konfigurationsfiles, die dynamisch während des Betriebes von bestimmten Systemkomponenten verändert werden und deshalb nicht über Prototypen gepflegt werden können, z.B.
  • Ereignisprotokolle
Eine ausgewählte Menge dieser Informationen wird einmal am Tag aufbereitet und auf dem Monitoring-Server ins Web gestellt.

Abhängig von Funktionalität und Einrichtung gelten folgende URLs zu den Monitoring-Systemen.
(Detailinformationen sind nur den Funktionsverantwortlichen der Systeme zugänglich.)

Server Entwicklungssysteme
  alle anderen Einrichtungen UBC und URZ
http://bb.hrz.tu-chemnitz.de/ https://bb1.hrz.tu-chemnitz.de/ https://bb2.hrz.tu-chemnitz.de/

Software-Repos für speziell bereitgestellte Software

Die Menge der SW-Pakete wird zunächst durch die Distribution bestimmt. Es ist möglich, darüber hinaus spezielle SW-Pakete auf einem System zu installieren. Aus verschiedenen Gründen kann es sinnvoll sein, solche SW in zentrale Repos abzulegen:
  • damit solche Installationen reproduzierbar sind, z.B. bei Ausfall oder Wechsel des Hosts
  • weil die SW von allgemeinem Interesse ist und auf mehreren (vielen, allen) Systemen installiert werden soll
Für solche Fälle existieren sog. URZ_CONTRIB-SW-Repos für jede BS-Familie bzw. Systemplattform.