(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 | 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 | |||
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 | ||
<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 | Changelog und so) kann ganz normal mit git-buildpackage gebaut werden; für | ||
mal eben schnell was Bauen zum Testen am besten | mal eben schnell was Bauen zum Testen am besten git-buildpackage | ||
--git-export=WC --git-ignore-new -us -uc | --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 | 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. | |||
= /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 | |||
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 | |||
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 | 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 15: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.