Mai 2015 – Constey's Blog

MonitorPi – Nagios, Centreon, Check_MK, Nagvis auf dem Raspberry Pi 2

4. Mai 2015 von Constantin Lotz

raspberry-pi-2-770x577 Es ist mal wieder so weit, es gibt ein Update in Sachen Monitoring. Viele kennen mit Sicherheit den kleinen Raspberry Pi, eigentlich als dritte Welt-PC gedacht – aber unter den Bastlern ebenfalls ein Hit geworden. Ich habe ja schon mehrere Beiträge zum Pi hier geschrieben, aber seit dem Raspberry Pi 2 gibt es noch ganz andere Anwendungsfelder die durch die größere Leistung möglich werden.
So auch das Projekt „MonitorPi“, dass den RaspberryPi in eine Überwachungszentrale verwandelt, die inklusive Zubehör preislich auch unter 100€ liegt.
MonitorPi ist eine fertige Appliance von mir – die mit den beliebtesten Monitoring-Tools vorinstalliert ist.
Was ist alles enthalten und vorinstalliert ? (Ready 2 use)
– Nagios 3.5.1
– Centreon 2.6.0
– Centreon-Broker 2.8.2
– Check_MK (Livestatus) 1.2.6.p2
– Nagvis 1.8.2
– Nagios Plugins 2.0.3
Was wird benötigt ?
– Raspberry Pi 2
– mind. 8 GB Speicherkarte (Je schneller desto besser. Class 10 = top)
– Win32DiskImager
[stextbox id=“info“]MonitorPi basiert auf der aktuellen Debian Wheezy Distribution die es auch via raspberrypi.org zum Download gibt. (2015-02-16-raspbian-wheezy.img)
Nur habe ich sie noch vollständig aktualisiert. Stand: 04.05.2015[/stextbox]
Wie wird MonitorPi installiert ?
Ganz einfach: Ihr ladet euch die aktuelle Image-Datei herunter und bespielt diese auf eine micro-SD-Karte.
Dies geht mit dem Win32DiskImager wie im Bild beschrieben:

[stextbox id=“alert“]Achtung: Alle Daten auf der SD Karte werden gelöscht![/stextbox]
Anschließend den Rasperry Pi 2 mit der SD-Karte booten, er versucht automatisch eine IP via DHCP zu beziehen, und zeigt diese nach dem Boot an.
Wie sehen die unterschiedlichen Monitoring-Tools aus ?

Die Centreon Übersicht immer sehr detailiert

Eine grafische Nagvis Übersicht der Leitungsauslastung

Wie erreiche ich die Tools ?
Alle Tools sind Web-Applikationen, die per Browser aufgerufen werden. Die Url’s sind wie folgt:

Nagios	Url: http://%IP%/nagios Benutzername: nagiosadmin Passwort: constey
Nagvis	Url: http://%IP%/nagvis Benutzername: admin Passwort: admin
Centreon	Url: http://%IP%/centreon Benutzername: admin Passwort: constey
Check_MK	Url: http://%IP%/check_mk Benutzername: nagiosadmin Passwort: constey
phpMyAdmin (Mysql)	Url: http://%IP%/phpmyadmin Benutzername: root Passwort: constey

Die Zugangsdaten zum Anmelden an der Konsole oder via SSH sind:
Benutzername: pi
Passwort: raspberry
Ansonsten ist das Passwort immer „constey“, also zum Beispiel für die einzelnen Benutzer oder Mysql-Datenbank-Benutzer.
Download:
Hier gibt es das Image in gezippter Form zum Download 2015-05-04-wheezy-monitorPI-constey-2 (ca. 1.8 GB)
[EXPAND Prüfsummen-Information]—————————
Prüfsummen-Information
—————————
Name: 2015-05-04-wheezy-monitorPI-constey-2.zip
Größe: 1872300662 Bytes (1785 MB)
CRC32: 9ACC060B
CRC64: CC7A670EBC2EF5E0
SHA256: 71D79E6F9FBD9BD68618029F008C77AE488FCE251932B2754D76B2CB2FB5D483
SHA1: FF7AD402D6116BEC4B8D8528223D265D6BB1700A
[/Expand]
FAQ:
Warum ist nicht Nagios 4 installiert?
Zum einen gibt es noch die ein oder anderen Kompatibilitätsprobleme mit Centreon, wer auch noch andere Module benutzen möchte, stößt eventuell ebenfalls auf Kompatibilitätsprobleme. Wer dennoch aktualisieren will kann das natürlich gerne tun.
Wo liegen die Quelldateien ?
Alle Quelldateien liegen unter /home/pi/sources.

Wo liegen die wichtigsten Programme ?
Ich habe die Anwendungen in der Regel immer mit Standardwerten kompiliert. Aber hier einige Pfade:
Nagios: /usr/local/nagios
Nagios Plugins: /usr/local/nagios/libexec
Centreon: /usr/local/centreon/

Zerifikatsvalidy period erhöhen

1. Mai 2015 von Constantin Lotz

Kurz und knapp: Wenn man bei seiner Windows Zertifizierungsstelle keine Zertifikate mit längerer Gültigkeit ausstellen kann, obwohl es in den entsprechenden Templates konfiguriert ist, muss man prüfen was die generelle Gültigkeitsdauer ist.
Dazu auf dem CA-Server folgende Einstellungen prüfen:

H:\&gt;certutil -getreg ca\ValidityPeriod
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\ValidityPeriod:
ValidityPeriod REG_SZ = Years
CertUtil: -getreg command completed successfully.
H:\&gt;certutil -getreg ca\ValidityPeriodUnits
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\ValidityPeriodUnits:
ValidityPeriodUnits REG_DWORD = 2
CertUtil: -getreg command completed successfully.

Über die Werte kriegt man zum einen raus, in was für Perioden gerechnet wird (i.d.R. Jahre), sowie wie lange die max. Gültigkeit ist. (ValidityPeriodUnits)
Um den Wert nun zu erhöhen wie folgt ausführen:

H:\&gt;certutil -setreg ca\validityperiodunits 4
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\ValidityPeriod
Units:
Old Value:
ValidityPeriodUnits REG_DWORD = 2
New Value:
ValidityPeriodUnits REG_DWORD = 4
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Abschließend den Zertifikatsdienst neustarten:

H:\&gt;net stop certsvc
The Active Directory Certificate Services service is stopping.
The Active Directory Certificate Services service was stopped successfully.
H:\&gt;net start certsvc
The Active Directory Certificate Services service is starting.
The Active Directory Certificate Services service was started successfully.

Anschließend kann man über den CA-Server in den Zertifikatstemplates die Gültigkeit erhöhen:

Und siehe da, die Zertifikate sind nun länger gültig:

owncloud Server erfolgreich aktualisieren

1. Mai 2015 von Constantin Lotz

Ich beschreibe hier kurz wie man seine bestehende Owncloud Version aktualisieren kann. Als Betriebssystem benutze ich ein Ubuntu 14.04.
Schritt 1: Aktuelle Owncloud Version herunterladen

cd /tmp/
wget https://download.owncloud.org/community/owncloud-8.0.2.tar.bz2
tar xjv owncloud-8.0.2.tar.bz2

Schritt 2: Owncloud in Maintenance Modus versetzen

cd /var/www
vi owncloud/config/config.php
# Set Maintenance Mode TRUE
'maintenance' =&gt; true,

Schritt 3: Webserver stoppen

# Stop Webserver / Apache2
service apache2 stop

Schritt 4: Owncloud Installation verschieben, neue Owncloud Version in richtige Stelle kopieren und Config kopieren

mv owncloud owncloud-old
mv /tmp/owncloud /var/www
cp owncloud-old/config/config.php owncloud/config/
chown www-data:www-data owncloud -R

Schritt 5: Owncloud Upgrade durchführen

cd owncloud
sudo -u www-data php occ upgrade
Turned on maintenance mode
Checked database schema update
Checked database schema update for apps
Updated database
Disabled 3rd-party app: calendar
Disabled 3rd-party app: contacts
Disabled 3rd-party app: documents
Disabled 3rd-party app: search_lucene
Updated &lt;files_pdfviewer&gt; to 0.7
Updated &lt;activity&gt; to 1.2.0
Updated &lt;files_sharing&gt; to 0.6.1
Updated &lt;gallery&gt; to 0.6.0
Turned off maintenance mode
Update successful

Schritt 6: Webserver starten

service apache2 start

[stextbox id=“info“]Ich bin zuerst der offiziellen Upgrade Doku gefolgt, doch dort wurden die Berechtigungen nicht neu gesetzt (chown). Daraufhin hatte ich nach dem Upgrade nur eine weiße Seite und folgende Fehlermeldung im apache2 error.log:

[Fri Mar 13 10:44:25.692970 2015] [:error] [pid 9759:tid 139709684631296] [client 62.153.223.62:34329] FastCGI: server "/usr/lib/cgi-bin/php5.fcgi" stderr: PHP message: PHP Warning: flock() expects parameter 1 to be resource, boolean given in /var/www/owncloud/lib/private/config.php on line 178, referer: https://cloud.constey.de/
[Fri Mar 13 10:44:25.693061 2015] [:error] [pid 9759:tid 139709684631296] [client 62.153.223.62:34329] FastCGI: server "/usr/lib/cgi-bin/php5.fcgi" stderr: PHP message: PHP Fatal error: Call to a member function getValue() on a non-object in /var/www/owncloud/lib/private/legacy/config.php on line 46, referer: https://cloud.constey.de/

Nach dem „chown www-data:www-data owncloud -R“ lief aber alles wie geschmiert.[/stextbox]

Offline Installation von .Net 3.5 via GPO korrekt einrichten

1. Mai 2015 von Constantin Lotz

Ich habe vor längerer Zeit schon mal mit dem Problem gekämpft, dass die .Net 3.5 Installation unter Windows 8 im Firmenumfeld fehlschlägt. Eine Alternative zur Installation über „Programme und Features hinzufügen“ hatte ich hier beschrieben.
Allerdings bekomme ich neuerdings hier öfter auch einen Fehler, was die Installation fast unmöglich macht:

The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information about specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077.

Um Dot Net nun doch installiert zu bekommen gibt es 2 Lösungen:
1. Offline Installer verwenden (Weg für die Faulen :p)
Ihr findet hier eine Offline-Version zum Installieren von .Net die unter Windows 8, Windows 10, Windows 2012 Server etc. funktioniert.
2. Gruppenrichtlinien anpassen
Als erstes benötigt man die aktuellen ADMX-Templates für Windows 8.1/2012, die es hier zum herunterladen gibt, ansonsten sieht man evtl. die Einstellungen im Gruppenrichtlinieneditor nicht.
Nun kann man über den Gruppenrichtlinieneditor die folgende Einstellung setzen:
Computer Configuration\Administrative Templates\System -> Specify settings for optional component installation and component repair

a) Entweder man macht den Haken wie im Bild rein, d.H. dass alle Features über Windows Update aus dem Internet heruntergeladen werden
oder:
b) Man gibt einen Alternativen Quell-Pfad der Windows Dateien auf einem Netzwerkpfad an
Dies können auch mehrere sein, wie zum Beispiel folgende Einstellung:

\\netzlaufwerk\wsus\Win81\sources\sxs;\\netzlaufwerk\wsus\Win2012\sources\sxs;

In diesem Fall werden die Features aus dem lokalen Lan installiert, geht bei den meisten dann schneller 😉
(via)