Studieren in Chemnitz. Wissen, was gut ist.






  • Anmelden

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-Scenario aus:
  • Hostname: attila
  • System-Plattform: SL_5.5_X86
    • 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ässig 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

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_5/FU_REFERENZ_SERVER
 SL_5_X86/FU_REFERENZ_SERVER
 SL_5.5_X86/FU_REFERENZ_SERVER

sowie für jeden Host 

$ cd /afs/tu-chemnitz.de/ToSCA/ROOTS
$ ls -d */attila
 SL_5.5_X86/attila

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_5/FU_REFERENZ_SERVER für alle SL_5-Hosts dieser Funktionsklasse (unabhängig von der Minor-SP-Klasse bzw. Architektur)
SL_5_X86/FU_REFERENZ_SERVER für alle SL_5_X86-Hosts dieser Funktionsklasse (unabhängig von der Minor-SP-Klasse)
SL_5.5_X86/FU_REFERENZ_SERVER für alle SL_5.5_X86-Hosts dieser Funktionsklasse
SL_5.5_X86/attila 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.
https://twiki.tu-chemnitz.de/bin/view/System

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ässig 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_5/FU_REFERENZ_SERVER/etc/daemon.conf
...
afs:rc
...
sshd:xinetd
...

Die Aktivierung/Deaktivierung passiert 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_5/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_5.5_X86/attila/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 ausschliesslich der Softwareadmin der BS-Familie verantwortlich. Details siehe Policy zur Konfiguration von SW-Paketen (rpm, wpm) in ToSCA

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_5.5_X86/attila/etc/crontab*

Die Minuten-Angaben in diesem File werden automatisch generiert, so dass gesichert ist, dass sich die Cronjobs aller administierten Hosts über den Zeitraum einer Stunde gleichmässig 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_5.5_X86/attila/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_5.5_X86/attila/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_5.5_X86/attila

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.
    • etc_grub.conf
    • etc_fstab

Eine ausgewählte Menge dieser Informationen wird einmal am Tag aufbereitet und auf dem Monitoring-Server ins Web gestellt. Bei einem Server lautet der URL:
http://bb.hrz.tu-chemnitz.de/notes/attila.html
Bei allen anderen Systemen finden man die Host-Informationen unter:
http://bb1.hrz.tu-chemnitz.de/notes/attila.html

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_5.5_X86)
/etc/yum.repos.d/urz_updates.repo        # Repo für freigegebene SW-Updates der Distribution (z.B. SL_5.5_X86)
/etc/yum.repos.d/urz_contrib_major.repo  # URZ_CONTRIB-Repo (unabhängig von der Minor-Release, z.B: für alle SL_5_X86)
/etc/yum.repos.d/urz_contrib.repo        # URZ_CONTRIB_REPO für die Minor-Release, z.B: SL_5.5_X86

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. Der URZ_CONTRIB-Mechanismus ist beschrieben unter Policy für URZ_CONTRIB-Softwarebereitstellung in ToSCA

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 und Pflegemassnahmen 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