Admin-Toolkit: Difference between revisions

Latest revision as of 18:13, 4 January 2018

Admin-Toolkit ^stable

Debian / Arch Linux Admin Helpers
Beteiligt	derf, mxey
Quelltext	chaosdorf-admin-toolkit

There is an English version of this page

Zur einfacheren Verwaltung der Chaosdorf-Server und weiterer Hosts existiert das Chaosdorf-Admin-Toolkit.

Dieses ist ein in git getracktes Debian-Paket, welches einfach auf jedem von uns administrierten Host installiert wird und somit einen Teil der nötigen zusätzlichen Konfigurationsdateien, Skripte etc. bereitstellt. Im Vergleich zu manuellem Rumgefrickel in /usr/local senkt dies den Administrationsaufwand deutlich. Vor allem muss man sich nicht mehr darum sorgen, dass diese Dateien auf den verschiedenen Hosts auf dem gleichen Stand sind.

Das Repository auf GitHub

Fabric[edit | edit source]

Zum Ausrollen des neuesten Admin-Toolkit-Releases benutzen wir fabric. Die Software hat leider noch ein paar Macken, aber insgesamt ist "fab configs deploy:2011.09.07" deutlich angenehmer zu tippen, als jedes mal die entsprechenden Befehle aus der Shell-History zu fischen und anzupassen.

fabfile.py

NSCA-Helfer[edit | edit source]

Unsere Nagios-Checks werden lokal per cron ausgeführt und dann per nsca-ng auf den Monitoringserver geschoben. Damit wir nicht die gemeinsamen Checks doppelt definiert haben, sind sie zentral konfiguriert und werden dann von einem weiteren kleinen Perlskript ausgeführt.

Nagios Checkskripte[edit | edit source]

Diverse nicht in Debian enthaltene und ein paar eigene. Zum Beispiel:

check_cert_expire erinnert uns rechtzeitig, unsere SSL-Zertifikate zu erneuern. Deutlich komfortabler als Kalendereinträge.
check_git_status überprüft, ob in "/etc" (etckeeper) oder "/usr/local" (normales git-repo) irgendwelche Änderungen liegen, die noch nicht commitet wurden. Durch ausreichend hohe Check- und Retry-Intervalle in der Icinga-Config stört es auch nicht bei üblichen Adminarbeiten.
check_websites überprüft auf Basis einer Config,ob diverse URLs auf unseren diversen vhosts den richtigen Status liefern (401 Authorization required, 200 OK oder 301 Redirect auf spezifische andere URL).

Icinga-Goodies[edit | edit source]

Wir haben einen Bot mit dem Namen icinga in #chaosdorf. Es ist ein simples, an das Icinga angeschlossenes Perlskript, welches uns sofort mit irgendwelchen Meldungen versorgt. Einerseits weiß dann sofort jeder Bescheid, und andererseits entstehen dadurch so schöne Situationen wie diese:

20:59           <--  mete!~mete@shells.chaosdorf.de [Remote host closed the connection]
20:59           <--  penma_!~penma@shells.chaosdorf.de [Read error: Connection reset by peer]
20:59           <--  muzy!~muzy@shells.chaosdorf.de [Remote host closed the connection]
[ ... und noch ein paar mehr ... ]
21:09        icinga  PROBLEM host alert: shells.chaosdorf.de is DOWN

O'RLY? :-)

(for the record: Es war eine geplante Downtime, die wir nur nicht im Icinga eingetragen hatten)

checkrestart-Hook[edit | edit source]

Nach jedem Systemupdate wird über einen dpkg-Hook nachgeschaut, ob noch Daemons mit veralteten Libraryversionen laufen, so dass man diese ggf. neustarten kann.

Backups[edit | edit source]

Auch Backups werden über das Debianpaket geregelt. Sie werden von backup_external lokal generiert, komprimiert und verschlüsselt, anschließend per SFTP auf einen anderen Host übertragen.

Die Backups sind mit einem speziellen Adminkey verschlüsselt. Geplant ist, sie in Zukunft auf mehreren Hosts zu speichern. Das vorhandene Skript ist darauf bereits ausgelegt.

Dependencies[edit | edit source]

Als Hilfe zum Aufsetzen neuer Systeme gibt's noch ein paar Dependencies auf Debianpakete, u.a. etckeeper, git, vim und zsh.

@@ Line 1: / Line 1: @@
-[[File:Admin_Icinga.png]]
+{{Project
+|name=Admin-Toolkit
+|description=Debian / Arch Linux Admin Helpers
+|project category=Software
+|image=Admin_Icinga.png
+|status=stable
+|people=derf, mxey
+|source=https://github.com/chaosdorf/chaosdorf-admin-toolkit{{!}}chaosdorf-admin-toolkit
+}}
+{{English version}}
-Zur einfacheren Verwaltung der Chaosdorf-Server (und in Zukunft weiterer
+Zur einfacheren Verwaltung der Chaosdorf-Server und weiterer Hosts existiert das Chaosdorf-Admin-Toolkit.
-Hosts) existiert das Chaosdorf-Admin-Toolkit.
-Dieses ist ein in [http://git-scm.com/ git] getracktes Debian-Paket, welches
+Dieses ist ein in [http://git-scm.com/ git] getracktes Debian-Paket, welches einfach auf jedem von uns administrierten Host installiert wird und somit einen Teil der nötigen zusätzlichen Konfigurationsdateien, Skripte etc. bereitstellt. Im Vergleich zu manuellem Rumgefrickel in /usr/local senkt dies den Administrationsaufwand deutlich. Vor allem muss man sich nicht mehr darum sorgen, dass diese Dateien auf den verschiedenen Hosts auf dem gleichen Stand sind.
-einfach auf jedem Host installiert wird und somit einen Teil der nötigen
-zusätzlichen Konfigurationsdateien, Skripte etc. bereitstellt. Im Vergleich zu
-manuellem Rumgefrickel in /usr/local senkt dies den Administrationsaufwand
-deutlich. Vor allem muss man sich nicht mehr darum sorgen, dass diese Dateien
-auf den verschiedenen Hosts auf dem gleichen Stand sind.
-[http://github.com/chaosdorf/chaosdorf-admin-toolkit Das Repository auf GitHub]
+[https://github.com/chaosdorf/chaosdorf-admin-toolkit Das Repository auf GitHub]
-= Inhalt =
+== Fabric ==
-== Fabric ==
+Zum Ausrollen des neuesten Admin-Toolkit-Releases benutzen wir [http://fabfile.org/ fabric]. Die Software hat leider noch ein paar Macken,
+aber insgesamt ist "fab configs deploy:2011.09.07" deutlich angenehmer zu tippen, als jedes mal die entsprechenden Befehle aus der Shell-History zu
+fischen und anzupassen.
-Zum Ausrollen des neuesten Admin-Toolkit-Releases benutzen wir
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/fabfile.py fabfile.py]
-[http://fabfile.org/ fabric]. Die Software hat leider noch ein paar Macken,
-aber insgesamt ist `fab configs deploy:2011.04.07` deutlich angenehmer zu
-tippen, als jedes mal die entsprechenden Befehle aus der Shell-History zu
-fischen und anzupassen. [[!gh_at fabfile.py]]
 == NSCA-Helfer ==
-Unsere Nagios-Checks werden lokal per cron ausgefühl und dann per `nsca_send`
+Unsere Nagios-Checks werden lokal per cron ausgeführt und dann per nsca-ng auf den Monitoringserver geschoben. Damit wir nicht die gemeinsamen Checks doppelt definiert haben, sind sie zentral konfiguriert und werden dann von einem weiteren kleinen Perlskript ausgeführt.
-auf unseren Monitoringserver geschoben. Damit wir nicht die gemeinsamen Checks
-doppelt definiert haben, sind sie zentral [[!gh_at_np passive_checks.cfg
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-passive/passive_checks.cfg passive_checks.cfg]
-desc="konfiguriert"]] und werden dann von einem weiteren kleinen [[!gh_at_np
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-passive/submit_checks submit_checks]
-submit_checks desc="Perlskript"]] ausgeführt.
-== Checkskripte ==
+== Nagios Checkskripte ==
 Diverse nicht in Debian enthaltene und ein paar eigene. Zum Beispiel:
-[[!gh_at_nl check_cert_expire desc="check\_cert\_expire"]]
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-checks/local/check_cert_expire check_cert_expire] erinnert uns rechtzeitig, unsere SSL-Zertifikate zu erneuern. Deutlich komfortabler als Kalendereinträge.
-erinnert uns rechtzeitig, unsere SSL-Zertifikate zu erneuern. Deutlich
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-checks/local/check_git_status check_git_status] überprüft, ob in "/etc" (etckeeper) oder "/usr/local" (normales git-repo) irgendwelche Änderungen liegen, die noch nicht commitet wurden.  Durch ausreichend hohe Check- und Retry-Intervalle in der Icinga-Config stört es auch nicht bei üblichen Adminarbeiten.
-komfortabler als Kalendereinträge.
+* [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-checks/remote/check_websites check_websites] überprüft auf Basis einer [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/nagios-checks/remote/chaosdorf_websites.ini Config],ob diverse URLs auf unseren diversen vhosts den richtigen Status liefern (401 Authorization required, 200 OK oder 301 Redirect auf spezifische andere URL).
-[[!gh_at_nl check_git_status desc="check\_git\_status"]]
-überprüft, ob in `/etc` (etckeeper) oder `/usr/local` (normales git-repo)
-irgendwelche Änderungen liegen, die noch nicht commitet wurden.  Durch
-ausreichend hohe Check- und Retry-Intervalle in der Icinga-Config stört es auch
-nicht bei üblichen Adminarbeiten.
-Insbesondere die CGI- und Git-Wrapper von Ikiwiki sind eine beliebte
-Fehlerquelle (falsche Berechtigungen, nicht richtig geupdated etc.).
-[[!gh_at_nl check_ikiwiki desc="check_ikiwiki"]]
-liest daher die Configs unserer ikiwiki-Instanzen aus und überprüft, ob darin
-denn auch alles mit rechten Dingen zugeht.
-[[!gh_at_nr check_websites desc="check_websites"]]
-überprüft auf basis einer [[!gh_at_nr chaosdorf_websites.ini desc="Config"]],
-ob diverse URLs auf unseren diversen vhosts den richtigen Status liefern (401
-Authorization required, 200 OK oder 301 Redirect auf spezifische andere URL).
 == Icinga-Goodies ==
@@ Line 63: / Line 46: @@
 andererseits entstehen dadurch so schöne Situationen wie diese:
 :59           <--  mete!~mete@shells.chaosdorf.de [Remote host closed the connection]
 :59           <--  penma_!~penma@shells.chaosdorf.de [Read error: Connection reset by peer]
 :59           <--  muzy!~muzy@shells.chaosdorf.de [Remote host closed the connection]
-    [ ... und noch ein paar mehr ... ]
+ [ ... und noch ein paar mehr ... ]
 :09        icinga  PROBLEM host alert: shells.chaosdorf.de is DOWN
 O'RLY? :-)
-(for the record: Es war eine geplante Downtime,
+(for the record: Es war eine geplante Downtime, die wir nur nicht im Icinga eingetragen hatten)
-die wir nur nicht im Icinga eingetragen hatten)
 == checkrestart-Hook ==
-Nach jedem Systemupdate wird über einen `dpkg`-Hook nachgeschaut, ob noch
+Nach jedem Systemupdate wird über einen dpkg-Hook nachgeschaut, ob noch Daemons mit veralteten Libraryversionen laufen, so dass man diese ggf. neustarten kann.
-Daemons mit veralteten Libraryversionen laufen, so dass man diese ggf.
-neustarten kann.
 == Backups ==
-Auch Backups werden über das Debianpaket geregelt. Sie werden von [[!gh_at
+Auch Backups werden über das Debianpaket geregelt. Sie werden von [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/backup/backup_external backup_external] lokal generiert, komprimiert und verschlüsselt, anschließend per SFTP auf einen anderen Host übertragen.
-backup/backup_external]] lokal generiert, komprimiert und verschlüsselt,
-anschließend per SFTP auf einen anderen Host übertragen.
-Geplant ist, sie in Zukunft mit einem speziellen Adminkey zu verschlüsseln und
+Die Backups sind mit einem speziellen Adminkey verschlüsselt. Geplant ist, sie in Zukunft auf mehreren Hosts zu speichern. Das vorhandene Skript ist darauf bereits ausgelegt.
-auf mehreren Hosts zu speichern. Das vorhandene Skript ist darauf bereits
-ausgelegt.
 == Dependencies ==
@@ Line 94: / Line 70: @@
 Als Hilfe zum Aufsetzen neuer Systeme gibt's noch ein paar Dependencies auf
 Debianpakete, u.a. etckeeper, git, vim und zsh.
-= Pläne =
-* Bei Installation automatisch den Nagios-User anlegen
 [[Category:Projects]]