Admin-Grundlagen: Difference between revisions

From Chaosdorf Wiki
(wiki -> www)
 
m (prettify)
Line 12: Line 12:
werden nicht verwendet. Die SSH-Keys aller Mitglieder des Teams sollten auf
werden nicht verwendet. Die SSH-Keys aller Mitglieder des Teams sollten auf
allen Systemen vorhanden sein. Zu beachten ist, dass auf mehreren Systemen, die
allen Systemen vorhanden sein. Zu beachten ist, dass auf mehreren Systemen, die
Keys nicht in `/root/.ssh/authorized_keys` sondern in `/var/cache/ssh/root` zu
Keys nicht in /root/.ssh/authorized_keys sondern in /var/cache/ssh/root zu
finden sind. Die Beschreibung der Systeme sollte in jedem Fall die genaue
finden sind. Die Beschreibung der Systeme sollte in jedem Fall die genaue
Pfadangabe angeben.
Pfadangabe angeben.
Line 18: Line 18:
su (zu root) ist auf allen Systemen deaktiviert, damit selbst bei Kenntnis des
su (zu root) ist auf allen Systemen deaktiviert, damit selbst bei Kenntnis des
Root-Passworts kein Login ohne SSH-Key möglich ist. Um das zu erreichen ist
Root-Passworts kein Login ohne SSH-Key möglich ist. Um das zu erreichen ist
`pam_wheel.so` in `/etc/pam.d/su` aktiviert. Die Gruppe wheel existiert auf
pam_wheel.so in /etc/pam.d/su aktiviert. Die Gruppe wheel existiert auf
Debian standardmäßig nicht, damit hat sie auch keine Mitglieder ;-)
Debian standardmäßig nicht, damit hat sie auch keine Mitglieder ;-)


Line 27: Line 27:
= Kommunikation (IRC, Mail) =
= Kommunikation (IRC, Mail) =


Die Kommunikation läuft genau wie die normale Vereinskommunikation über
Die [[Communication|Kommunikation]] läuft genau wie die normale Vereinskommunikation über
\#chaosdorf im OFTC.  Dort sollten Veränderungen am System besprochen oder
<nowiki>#chaosdorf</nowiki> im OFTC.  Dort sollten Veränderungen am System besprochen oder
zumindest erwähnt werden.
zumindest erwähnt werden.


Line 39: Line 39:
[https://github.com/chaosdorf/chaosdorf-admin-toolkit Admin-Toolkit]
[https://github.com/chaosdorf/chaosdorf-admin-toolkit Admin-Toolkit]
verwaltet. Ein Debianpaket aus einer "releaseten" Version (korrekter
verwaltet. Ein Debianpaket aus einer "releaseten" Version (korrekter
Changelog und so) kann ganz normal mit `git-buildpackage` gebaut werden; für
Changelog und so) kann ganz normal mit git-buildpackage gebaut werden; für
mal eben schnell was Bauen zum Testen am besten `git-buildpackage
mal eben schnell was Bauen zum Testen am besten git-buildpackage
--git-export=WC --git-ignore-new -us -uc` benutzen.
--git-export=WC --git-ignore-new -us -uc benutzen.


Das resultierende Debian-Paket wird dann auf allen Hosts installiert, dabei
Das resultierende Debian-Paket wird dann auf allen Hosts installiert, dabei
Line 48: Line 48:
= /etc =
= /etc =


Zur Nachverfolgung der Änderungen wird `/etc` in Git mit Hilfe des Werkzeugs
Zur Nachverfolgung der Änderungen wird /etc in Git mit Hilfe des Werkzeugs
etckeeper verwaltet. D.h. jede geänderte Datei in diesem Verzeichnis muss als
etckeeper verwaltet. D.h. jede geänderte Datei in diesem Verzeichnis muss als
Commit mit einer passenden Commitnachricht festgehalten werden.
Commit mit einer passenden Commitnachricht festgehalten werden.


etckeeper ist bei uns so konfiguriert, dass es bei uncomitteten Änderungen in
etckeeper ist bei uns so konfiguriert, dass es bei uncomitteten Änderungen in
`/etc` die Installation oder Entfernung von Paketen unterbindet.
/etc die Installation oder Entfernung von Paketen unterbindet.


= /usr/local =
= /usr/local =
Line 75: Line 75:


Die Checks werden per cron lokal ausgeführt, siehe das Verzeichnis
Die Checks werden per cron lokal ausgeführt, siehe das Verzeichnis
`nagios-passive` im Admin-Toolkit. Sie sind im Icinga entsprechend als passive
nagios-passive im Admin-Toolkit. Sie sind im Icinga entsprechend als passive
checks konfiguriert; wenn sie über 20 Minuten nicht aktualisiert wurden,
checks konfiguriert; wenn sie über 20 Minuten nicht aktualisiert wurden,
gibt's Alarm.
gibt's Alarm.
Line 81: Line 81:
== Checks manuell ausführen ==
== Checks manuell ausführen ==


`sh -x /usr/lib/nagios/run_checks 60` führt sämtliche Checks aus. Das Skript
sh -x /usr/lib/nagios/run_checks 60
wartet dabei (da es eigentlich per cron läuft) bis zu 60 Sekunden.
führt sämtliche Checks aus. Das Skript wartet dabei (da es eigentlich per cron läuft) bis zu 60 Sekunden.


= Wartungsfenster =
= Wartungsfenster =
Line 89: Line 89:
Reboots werden natürlich trotzdem angekündigt.
Reboots werden natürlich trotzdem angekündigt.


Nach einem Reboot sammeln sich aus bisher unerfindlichen Gründen auf `vm`
Nach einem Reboot sammeln sich aus bisher unerfindlichen Gründen auf [[Host:vm|vm]]
sshd-Zombieprozesse; daher bitte manuell dort einloggen und SSH restarten.
sshd-Zombieprozesse; daher bitte manuell dort einloggen und SSH restarten.


[[Category:Administration]]
[[Category:Administration]]

Revision as of 16:21, 16 February 2012

Diese Seite beschreibt Dinge, die für alle Chaosdorf-Systeme gelten.

Betriebssystem

Als Betriebssystem kommt Debian GNU/Linux zum Einsatz. Das jeweils installierte Release sollte bei den Beschreibungen der Hosts vermerkt sein.

Login

Die Administration erfolgt über SSH mit Login direkt als root. sudo oder su werden nicht verwendet. Die SSH-Keys aller Mitglieder des Teams sollten auf allen Systemen vorhanden sein. Zu beachten ist, dass auf mehreren Systemen, die Keys nicht in /root/.ssh/authorized_keys sondern in /var/cache/ssh/root zu finden sind. Die Beschreibung der Systeme sollte in jedem Fall die genaue Pfadangabe angeben.

su (zu root) ist auf allen Systemen deaktiviert, damit selbst bei Kenntnis des Root-Passworts kein Login ohne SSH-Key möglich ist. Um das zu erreichen ist pam_wheel.so in /etc/pam.d/su aktiviert. Die Gruppe wheel existiert auf Debian standardmäßig nicht, damit hat sie auch keine Mitglieder ;-)

Auf einigen Hosts wird PAM für SSH-Login nicht benötigt, daher haben wir es deaktiviert, um Fuckup durch Konfigurationsfehler in PAM zu vermeiden. Die Hostbeschreibung sollte das jeweils spezifieren.

Kommunikation (IRC, Mail)

Die Kommunikation läuft genau wie die normale Vereinskommunikation über #chaosdorf im OFTC. Dort sollten Veränderungen am System besprochen oder zumindest erwähnt werden.

Die Mitglieder richten Anfragen an die Adresse <admin@chaosdorf.de>. Jedes Mitglied des Adminteams sollte auf dieser Mailingliste eingetragen sein.

chaosdorf-admin-toolkit

Diverse zusätzliche Sachen (z.B. Nagioschecks) werden über das Admin-Toolkit verwaltet. Ein Debianpaket aus einer "releaseten" Version (korrekter Changelog und so) kann ganz normal mit git-buildpackage gebaut werden; für mal eben schnell was Bauen zum Testen am besten git-buildpackage --git-export=WC --git-ignore-new -us -uc benutzen.

Das resultierende Debian-Paket wird dann auf allen Hosts installiert, dabei ggf. die etckeeper-Hooks manuell ausführen.

/etc

Zur Nachverfolgung der Änderungen wird /etc in Git mit Hilfe des Werkzeugs etckeeper verwaltet. D.h. jede geänderte Datei in diesem Verzeichnis muss als Commit mit einer passenden Commitnachricht festgehalten werden.

etckeeper ist bei uns so konfiguriert, dass es bei uncomitteten Änderungen in /etc die Installation oder Entfernung von Paketen unterbindet.

/usr/local

Dieses Verzeichnis wird nicht vom Paketsystem kontrolliert, daher verwenden wir hier ebenfalls Git um Änderungen festzuhalten. Bitte vermeidet aber die Verwendung dieses Verzeichnisses und bevorzugt die Installation über Debian-Pakete.

Adminlog

Auf intern befindet sich das adminlog. Dort sind sämtliche, auch marginale, Veränderungen auf den Hosts zu vermerken. Es empfiehlt sich, diese auch im IRC-Channel anzusagen.

Icinga

Alle Systeme werden von derfs Icinga überwacht.

Die Checks werden per cron lokal ausgeführt, siehe das Verzeichnis nagios-passive im Admin-Toolkit. Sie sind im Icinga entsprechend als passive checks konfiguriert; wenn sie über 20 Minuten nicht aktualisiert wurden, gibt's Alarm.

Checks manuell ausführen

sh -x /usr/lib/nagios/run_checks 60

führt sämtliche Checks aus. Das Skript wartet dabei (da es eigentlich per cron läuft) bis zu 60 Sekunden.

Wartungsfenster

Das Wartungsfenster für alle Systeme ist Sonntags, jeweils von 21:00 bis 22:00. Reboots werden natürlich trotzdem angekündigt.

Nach einem Reboot sammeln sich aus bisher unerfindlichen Gründen auf vm sshd-Zombieprozesse; daher bitte manuell dort einloggen und SSH restarten.