Installation von Mosshe
From NJH-Wiki
- Autor
- Frank Prößdorf
Contents |
Was ist das?
ist ein SSH-basiertes Monitoringtool. Es unterstützt die Client/Server-Architektur. Server und Client werden nacheinander installiert.
Vorgehensweise
- Auf dem Server wird ein Benutzer mosshe eingerichtet.
- In dessen Home-Directory werden zunächst die Quellen gezogen und entpackt.
- Weiterhin wird dort ein DSA-basierter SSH-Key erstellt.
ssh-keygen -t dsa
- Auf dem Client wird ebenfalls ein Benutzer mosshe eingerichtet. Dieser erhält in der /etc/passwd als Shell anstatt der /bin/bash die /home/mosshe/localcheck.
- Auf den Client werden jetzt die Dateien Checks/localcheck, Checks/localcheck.funtions, .ssh/id_dsa.pub an die entsprechenden Stellen im Home-Directory des mosshe-Benutzers kopiert.
- Die Datei localcheck wird an den Client angepasst, so das nur die Checks ausgeführt werden, die beim Client benötigt werden.
- Auf dem Server kann durch
ssh mosshe@client
überprüft werden, ob auf dem Client alles richtig installiert wurde.
- Ist der Client eingerichtet, so kann er im Server in die Datei servers.conf mit eingetragen werden. Hierbei wird als Check mosshe_ssh verwendet.
- Wird auf dem Server nun das Kommando mosshe gestartet, werden von allen Clients die Informationen eingesammelt.
- Das Kommando sollte regelmäßig aufgerufen werden um den aktuellen Stand zu halten. Hierzu kann das Kommando mosshe_cron, welches im Paket mitgeliefert wurde, einfach in die crontab des Benutzers mosshe eingetragen werden.
- Über das Webinterface können die Ergebnisse angesehen werden. Hierzu ist es eventuell sinnvoll einen eigenen VirtualHost (beim Apache) auf das webinterface-Verzeichnis von mosshe zeigen zu lassen. Der Webserver muss hierzu Python unterstützen.
Anpassungen
Um mosshe noch ein wenig zu verbessern habe ich folgende Änderungen vorgenommen:
- HTML-Code CSS fähig machen. Hierbei könnten die CSS-Klassen nach dem Status benannt und dann dementsprechend eingefärbt werden. Beispielsweise so:
print '<td class="%s"><a href="server.py?server=%s">%s</a></td>' % (stat,lastserver,lastserver)
- Die Option SetupTimeout in der Datei Checks/mosshe_ssh existiert bei dem SSH (OpenSSH_3.9p1) von SLES10 nicht. Diese habe ich komplett rausgenommen.
- Das SSH (OpenSSH_3.6.1p2) vom ESX liefert anstatt der Kurzfassung den vollständigen Host. Das hat Probleme mit dem Webinterface bei der Nutzung von Server[lastserver] zur Folge. Den Teil habe ich aus dem Code gelöscht, weil er meiner Meinung nach an der Stelle nicht nötig war.
Syslog-Änderungen
Da sich der mosshe über ssh einloggt und jedes mal eine Meldung über einen erfolgreichen Login in der /var/log/messages auftaucht:
Aug 1 11:13:13 ilxww09 sshd[18347]: Accepted publickey for mosshe from 192.168.114.200 port 58760 ssh2
sollen nur noch alle Meldungen ab Level warn in die /var/log/messages.
syslog
Folgender Ausschnitt aus der /etc/syslog.conf, der die nötigen Einstellungen übernimmt:
auth.warning -/var/log/messages authpriv.warning -/var/log/messages cron.* -/var/log/messages daemon.* -/var/log/messages kern.* -/var/log/messages lpr.* -/var/log/messages mark.* -/var/log/messages news.* -/var/log/messages security.warning -/var/log/messages syslog.* -/var/log/messages user.* -/var/log/messages uucp.* -/var/log/messages # # angepasst fuer mosshe sys-status # auth.* -/var/log/auth.log authpriv.* -/var/log/auth.log
Nun werden alle Standard auth Meldungen nach /var/log/auth.log geschrieben.
syslog-ng
Von syslog wurde eine neue Version rausgebracht, die sich syslog-ng nennt. Die Konfiguration erfolgt hier objektorientiert und detailierter. Zunächst werden zwei Filter erstellt, die den Bereich und das Level einschränken. Die folgenden zwei Filter teilen sich also alle Meldungen die an auth und authpriv gehen:
filter f_authwarn { level(warn, err, crit) and facility(auth, authpriv); };
filter f_authnotice { level(info, notice, debug) and facility(auth, authpriv); };
Danach legen wir eine Datei fest, in die alle Meldungen, die keine Warnungen oder Fehler sind, geloggt werden sollen:
destination auth { file("/var/log/auth.log"); };
Und nun die aktiven Teile der Konfiguration, die die tatsächliche Weiterleitung der Meldungen in die entsprechenden Dateien übernehmen:
log { source(src); filter(f_authwarn); destination(messages); };
log { source(src); filter(f_authnotice); destination(auth); };
src und messages sind dabei in der Konfiguration vordefiniert und brauchen nicht geändert werden.
Die Datei /var/log/auth.log sollte nun noch ins logrotate mit übernommen werden.
