Posts Tagged ‘monit’

Sonntag, 26. März 2023

Die Log-Syntax zu geöffneten root sessions in auth.log hat sich geändert

Ich verwende monit extensiv, um viele Aspekte meines Linux-Server Fuhrparks zu überwachen.

Ein detektivischer „Sicherheitscheck“, den ich mit monit abdecke, sind Alarme zu frisch geöffneten root Sessions (der Informationssicherheits-Mensch in mir erhofft sich damit, irgendeines Tages so einen Angreifer zu entdecken):

check file su_root with path /var/log/auth.log
  if match "session opened for user root by" then alert

Ich kriege jedes Mal ein Email, wenn jemand eine root-Session eröffnet. Denn in auth.log findet sich dann jeweils folgender Eintrag:

Mar 26 13:33:16 localhost sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)

Seit einiger Zeit sind diese Emails für einige meiner Debian-Server verstummt (konkret: die x86er, während die Raspberry Pis fröhlich vor sich hermelden).

Heute machte ich mich daran, das Problem zu erforschen und zu lösen.

Erkenntnis: Die Syntax hat sich leicht geändert:

Mar 26 13:33:05 SERVER su: pam_unix(su-l:session): session opened for user root(uid=0) by mario(uid=0)

Deshalb habe ich die monit-Konfiguration angepasst:

check file su_root with path /var/log/auth.log
  if match "session opened for user root" then alert

Jetzt kommen die Alarme wieder …

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 26. Mai 2022

HomePods reagieren nicht mehr auf ICMP Pings

Im heimischen LAN erhalten alle Geräte basierend auf ihrer MAC-Adresse eine fixe IP.

Dies erlaubt mir diejenigen Geräte, welche permanent ansprechbar sein sollen, mittels monit ICMP Pings zu überwachen.

Seit einigen Tagen kriege ich andauernd Alarme, dass einige meiner Apple HomePods und HomePod minis offenbar offline seien. Am 24. Mai 18 solcher Emails, am 25. Mai dieselbe Zahl. Notabene: Ich pinge von drei Standorten aus.

Begonnen hat alles am 8. Mai, als ich das erste Mal seit dem 3. April eine solche Warnmeldung erhalten habe. Zuerst betraf dies nur einen einzigen HomePod mini, und trotz mehrmaliger Neustarts mittels USB-C Kabel aus dem Netzteil rausziehen und wieder einstecken konnte ich das Problem nicht lösen. Später traf es kurz einen originalen HomePod, aber hier funktionierte der erzwungene Neustart temporär. Seit dem 22. Mai sind neben diese zwei HomePods noch ein weiterer betroffen. Alle sind AppleTVs gepaart sind (ein HomePod mit dem AppleTV im Schlafzimmer, zwei HomePod minis mit dem AppleTV im Fitness-Zimmer). Mysteriös!

Was die Ursache des Problems ist, kann ich derzeit nicht sagen — ein UniFi-Update? Oder doch das HomePod 15.5-Update?

Nachtrag

Apple hat vor ein paar Stunden HomePod OS 15.5.1 veröffentlicht, welches ich jetzt gerade auf der gesamten HomePod-Flotte installiere. Mal kucken.

Tags: , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Montag, 5. April 2021

Mit upower den Batteriestatus von Linux-Laptops überwachen und aufzeichnen

upower ist ein sehr nützliches Kommandozeilen-Tool, wenn man sich für den Batteriestatus seiner Linux-Laptops interessiert (Linux-Server meiner Wahl: Lenovo Thinkpads).

Ich verwende es auf zwei Arten (Anleitung zum Schnellstart):

  • Alarm wenn auf Batteriebetrieb geschaltet wird Ein cron-Script schreibt den Status der Batterie alle fünf Minuten in eine Datei. Die Datei wird von monit überwacht. Wenn das Gerät (1) auf Batteriebetrieb schaltet (wegen Stromausfall, oder weil das Stromkabel ausgezogen wurde) und (2) die Ladung der Batterie unter einen vordefinierten Grenzwert sinkt (aktuell: weniger als 80 Prozent), erhalte ich von monit regelmässig eine Meldung per Email. In einem Fall konnte ich so aus der Ferne zuschauen wie die Batterieladung kontinuierlich abnahm, bis dass Gerät offline ging.
  • Aufzeichnung mit cacti Die von upower ausgegebenen Vitaldaten speise ich in cacti ein, um den Verlauf der Vitaldaten darstellen zu können. Was ich derzeit aufzeichne: Verbleibende Maximalkapazität der Batterie in Prozent der Design Capacity, Ladung Batterie in Prozent, Ladung der Batterie in Wh, Ausgangsspannung, Ausgangsleistung („Draw“).

Problem

Der Parameter energy-rate (Dokumentation) …

Amount of energy being drained from the source, measured in W. If positive, the source is being discharged, if negative it’s being charged.

… enthält bei einigen Laptops plausible Werte …

...
# OPENVPN 1
energy-rate:         4.761 W
...
# OPENVPN 2
energy-rate:         3.298 W
...
# ELK (Elasticsearch Lucene Kibana)
energy-rate:         21.288 W
...

… bei anderen Laptops nicht:

...
# Web-Server
energy-rate:         0.00409639 W
...

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 16. September 2020

fr24feed 1.0.26-4 hat Probleme mit IPs, IPv6 und dem Web-Server

Kürzlich wurde auf meinem Pi24-Horchposten die neueste Version von fr24feed installiert: 1.0.26-4, Built on Sep 14 2020 08:32:40 (HEAD-bd20105.git/Linux/static_armel).

Umgehend reagierten meine monit Netzwerksensoren:

Connection failed Service pi24.domain.tld 

	Date:        Mon, 14 Sep 2020 19:03:03
	Action:      alert
	Host:        HOST
	Description: failed protocol test [HTTP] at [10.1.2.3]:8754 [TCP/IP] -- HTTP error: Regular expression doesn't match: No match

Your faithful employee,
Monit

Als ich auf das Web-Interface zugreifen wollte erschien auch tatsächlich folgende Fehlermeldung:

For security reasons the web interface is only availble from private class networks or after you have manually specified the bind-interface setting in /etc/fr24feed.ini

Please set it to bind-interface="0.0.0.0" to accept traffic from all interfaces or to the IP address of your preferred network interface!

For further assistance please contact support@fr24.com

Komisch! Nun gut, ich fügte also bind-interface="0.0.0.0" ans Ende der Datei /etc/fr24feed.ini und bootete den Pi24 neu. Das schaffte keine Abhilfe.

Selbst wenn ich auf dem Pi24 selber ein wget localhost:8754 respektive wget 127.0.0.1:8754 machte, erschien die Fehlermeldung.

Ich tüftelte noch eine Weile lang herum, und entdeckte dabei folgendes: Die neuste Version von fr24feed bindet sich aus irgendeinem Grund nur an IPv6:

$ netstat -tulpn
...
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp6       0      :::8754                   :::*                    LISTEN      -                   
...

Ein Eintrag für denselben Port beginnend mit tcp fehlte.

Das CHANGELOG zeigt auf, dass die Kollegen aktuell an den Netzwerkfunktionalitäten von fr24feed rumbasteln und dabei bereits mehrere Male nachbessern mussten. Offenbar ist auch die neuste Version noch nicht ganz koscher.

Ein Blick in das Log von fr24feed zeigte folgende Einträge:

2020-09-14 20:10:02 | ______  _  _         _      _                    _              _____    ___ 
2020-09-14 20:10:02 | |  ___|| |(_)       | |    | |                  | |            / __  \  /   |
2020-09-14 20:10:02 | | |_   | | _   __ _ | |__  | |_  _ __  __ _   __| |  __ _  _ __`' / /' / /| |
2020-09-14 20:10:02 | |  _|  | || | / _` || '_ \ | __|| '__|/ _` | / _` | / _` || '__| / /  / /_| |
2020-09-14 20:10:02 | | |    | || || (_| || | | || |_ | |  | (_| || (_| || (_| || |  ./ /___\___  |
2020-09-14 20:10:02 | \_|    |_||_| \__, ||_| |_| \__||_|   \__,_| \__,_| \__,_||_|  \_____/    |_/
2020-09-14 20:10:02 |                __/ |                                                         
2020-09-14 20:10:02 |               |___/                                                          
2020-09-14 20:10:02 | [main][i]FR24 Feeder/Decoder
2020-09-14 20:10:02 | [main][i]Version: 1.0.26-4/generic
2020-09-14 20:10:02 | [main][i]Built on Sep 14 2020 08:32:40 (HEAD-bd20105.git/Linux/static_armel)
2020-09-14 20:10:02 | [main][i]Running on: pi24-raspbian9
2020-09-14 20:10:02 | [main][i]Local IP(s): 
2020-09-14 20:10:02 | [main][i]Copyright 2012-2020 Flightradar24 AB
2020-09-14 20:10:02 | [main][i]https://www.flightradar24.com
2020-09-14 20:10:02 | [main][i]DNS mode: PING
2020-09-14 20:10:03 | [main][i]Automatic updates are ENABLED
2020-09-14 20:10:04 | ERROR: rmmod: ERROR: Module dvb_usb_rtl28xxu is not currently loaded
2020-09-14 20:10:04 | info | [httpd]Server started, listening on ::2020-09-14 20:10:04 | [e]PacketSenderConfiguration::fetch_config(): Unable to fetch configuration for yoda receiver
2020-09-14 20:10:06 | [d]TLSConnection::ctor(): Enable verify_peer in production code!
2020-09-14 20:10:06 | [main][i]Reader thread started
2020-09-14 20:10:06 | [main][i]Socket server started
2020-09-14 20:10:06 | [main][i]MLAT data feed started
2020-09-14 20:10:06 | [reader][i]Initializing reader
2020-09-14 20:10:06 | [reader][i]Connecting to DVBT receiver via (exe:///usr/bin/dump1090-mutability  --raw --mlat)
2020-09-14 20:10:06 | [bs][i]Initializing server
2020-09-14 20:10:06 | [bs][i]Starting server on 0.0.0.0:30003
2020-09-14 20:10:06 | [mlat][i]Waiting for MLAT configuration
2020-09-14 20:10:06 | [master][i]Starting processing thread
2020-09-14 20:10:06 | [reader][i]Connected to the receiver, configuring
2020-09-14 20:10:06 | [reader][i]Configured, processing messages
2020-09-14 20:10:07 | terminate called after throwing an instance of 'char const*'

Interessant sind folgende Zeilen:

...
2020-09-14 20:10:02 | [main][i]Local IP(s): 
...
2020-09-14 20:10:04 | info | [httpd]Server started, listening on ::
...
2020-09-14 20:10:07 | terminate called after throwing an instance of 'char const*'

Komisch! Dem Problem konnte ich nicht auf den Grund gehen, wieso fr24feed die IP des Raspberry Pis nicht herausfinden konnte. strace könnte hier wohl weiterhelfen, doch das ging mir dann doch etwas zu weit. Schlussendlich hatte ich genug und entschied ich mich für ein Downgrade auf eine „last known good“ Version:

$ wget "https://repo.feed.flightradar24.com/rpi_binaries/fr24feed_1.0.25-3_armhf.deb" --no-check-certificate
# dpkg -i fr24feed_1.0.25-3_armhf.deb

Damit die neueste Version am nächsten Tag nicht erneut installiert wird, habe ich auch noch /etc/cron.d/fr24feed_updater angepasst:

47 9 1 * * root /usr/lib/fr24/fr24feed_updater.sh >> /var/log/fr24feed_update.log 2>&1

Hoffen wir, dass es bis zum 1. Oktober eine neue Version gibt, die mein Problem behebt.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 7. Mai 2020

monit Prozesscheck ohne PID-Datei

Wieder einmal ein Beitrag zu einem meiner Linux-Lieblingstools: monit.

Wenn man einen Prozess überwachen will, der keine PID-Datei schreibt (welche die Process ID enthält), hilft monit auch hier weiter:

check process homebridge matching "homebridge"
    start program = "/usr/local/bin/homebridge/start.sh"
    stop program = "/usr/bin/pkill -f homebridge"

Läuft auf dem System ein Prozess, der „homebridge“ enthält, ist monit zufrieden. Ansonsten wird das Start-Script ausgeführt.

Das Beste: Im zu suchenden String kann man auch reguläre Ausdrücke unterbringen. Leider funktionierte aber folgende Zeichenfolge nicht:

"^homebridge$"

Auch die leicht vereinfachte Version führte zu andauernden Neustarts des Prozess, obwohl er bereits lief (d.h. monit konnte keinen laufenden Prozess finden, der auf den folgenden Ausdruck passte):

"homebridge$"

Schlussendlich half mir eine Antwort auf superuser auf den richtigen Pfad. Um interaktiv zu überprüfen, ob und wie viele Prozesse erkannt werden, loggt man sich auf das Linux-System ein und verwendet dann folgenden Befehl, um den regulären Ausdruck zu testen:

$ monit procmatch "homebridge$"

0 Prozesse. Herrje! Dabei müsste das doch anschlagen:

$ ps ax | grep -i homebridge
12345 pts/1    S+     0:00 grep --colour=auto -i homebridge
98765 ?        Sl     1:25 homebridge
43210 ?        Sl     0:13 homebridge-config-ui-x

Schlussendlich brachte ich den Check folgendermassen zum Laufen:

check process homebridge matching "homebridge\s*$"

Aus irgendeinem Grund scheint der Prozessname von einem Leerzeichen, Tabulator oder dergleichen gefolgt zu werden.

Nebenbemerkung: Wieso ich überhaupt einen regulären Ausdruck verwende? Weil ich manchmal zu Debuggingzwecken auf den Linux-Server einlogge und folgendes Kommando ausführe:

$ tail -f /var/log/homebridge.log

Wenn man monit nun die Prozesse nach „homebridge“ durchsuchen lässt, wird tail von monit als homebridge-Prozess erkannt, und das abgestürzte Homebridge eben nicht neu gestartet, solange der Befehl läuft.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 27. April 2020

Debian-Pakete melden bei der Installation ‚unknown option „–skip-systemd-native“‚

Ich betreibe hier noch mehrere Debian Stretch-Instanzen, installiere aber gelegentlich bereits (aktuellere) Buster-Pakete mit folgendem Befehl: apt-get install -t testing %PAKET%

Gestern erschien ein Update eines meiner Lieblingstools, monit. Doch bei der Installation passierte folgendes

...
invoke-rc.d: syntax error: unknown option "--skip-systemd-native"
dpkg: error processing package monit (--configure):
 subprocess installed post-installation script returned error exit status 1
...

Was nun? Heute fand ich die Lösung nach einer kurzen Recherche. Das Problem behebt man (unter Debian Stretch) folgendermassen:

# apt-get install -t testing init-system-helpers

Ab sofort kennt invoke-rc.d nun das Flag --skip-systemd-native. Die Lösung fand ich in folgendem Beitrag, zu welchem ich über ein Github-Issue rüberstolperte:

[…] init-system-helpers >= 1.54 which supports the required option.

Bis dahin war unter Debian Stretch nur init-system-helpers 1.48 vorhanden. Jetzt läuft apt-get wieder durch.

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. Juni 2017

monit bei einem HTTP-Fehler keinen Alarm absetzen lassen

In der Standardkonfiguration meldet monit einen Alarm, wenn ein HTTP-Check eines Web-Servers eine HTTP-Response grösser/gleich 400 zurück gibt:

If not used, the http protocol test will fail if the status code returned is greater than or equal to 400. You can override this behaviour by using the status qualifier.

Quelle: Monit Version 5.23.0 — HTTP

Was aber, wenn eine HTTP-Response mit einem solchen Code das korrekte Funktionieren eines Web-Servers signalisiert und deshalb keinen Alarm generieren soll? Es gibt Abhilfe:

...
check host web.server.strasse.emeidi.local with address 10.10.10.10
if failed
   port 80
   protocol http
   request "/non/existent.php"
   status = 404
then alert
...

Quelle: Monit monitor http status with 404 page

Mittels des Keywords status = 000 gibt man an, was der tatsächlich erwartete Wert ist.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. Juni 2017

Wenn Embedded Linux-Geräte kein HTTP HEAD verstehen

Netzwerkgeräte in meinem Intranet überwache ich mit der quelloffenen Software monit. Seit ich einen meiner monit-Server auf Debian Stretch upgegradet habe, häuften sich „Geister“-Fehlermeldungen — immer in Bezug auf Checks, welche die Verfügbarkeit von Web-Oberflächen abfragen. Dies in folgender Form:

...
check host web.server.strasse.emeidi.local with address 10.10.10.10
    if failed port 80 protocol http for 10 cycles then alert
...

Mit dem Upgrade auf Debian Stretch wird auch monit von Version 5.9-1+deb8u1 auf Version 5.20.0-6 aktualisiert.

Ich wartete also den Moment ab, in welchem ich per E-Mail die Fehlermeldung erhielt, loggte mich per SSH auf den Server ein und führte zu Debugging-Zwecken eine Abfrage aus — die Idee war, auf dem selben Server die Abfrage zu simulieren, die monit gegen das entfernte System laufen lässt:

$ wget --server-response "http://10.10.10.10/"
--2017-06-22 22:05:25--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html                   [ <=>                              ]   7,66K  --.-KB/s    in 0,01s   

2017-06-22 22:05:25 (754 KB/s) - »index.html« gespeichert [7841]

Dies funktioniert problemlos. Was Cheibs?

Als ich mir die Dokumentation zu monit genauer anschaute, realisierte ich eine feine, aber entscheidende Option:

PROTO(COL) HTTP
     [USERNAME "string"]
     [PASSWORD "string"]
     [REQUEST "string"]
     [METHOD <GET|HEAD>]
     [STATUS operator number]
     [CHECKSUM checksum]
     [HTTP HEADERS list of headers]
     [CONTENT < "=" | "!=" > STRING]

Quelle: Monit Version 5.23.0 — HTTP

Mit [METHOD ] entscheidet man, ob man einen normalen HTTP-Request („GET“) versendet, oder aber nur einen „HEAD“-Request, der nur nach dem Header einer Web-Site frägt. Das spitzfindige an der Sache:

METHOD set the HTTP request method. If not specified, Monit prefers the HTTP HEAD request method to save bandwidth, unless a response content or response checksum is tested. As some webservers may not support the HEAD method, one may want to set the method explicitly.

Dann lass uns das doch mal so simulieren. wget verfügt über die entsprechende Option --spider, die HEAD-Requests versendet:

$ wget --spider --server-response "http://10.10.10.10/"
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:04:36--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 501 Not Implemented
  Server: Router Webserver
  Connection: close
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
  Content-Type: text/html
--2017-06-22 22:04:37--  (Versuch: 2)  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: Wget HEAD request?

Et voilà, das war das Problem: Der Embedded Web Server auf dem zu überwachenden Gerät hat Probleme, wenn aus dem nichts ein HEAD-Request kommt. Beim zweiten Anlauf dann ist die Web-Seite offenbar gerendert und der HEAD-Request kann beantwortet werden.

monit scheint nun aber offenbar so programmiert zu sein, dass nach dem ersten Versuch und einer Antwort mit Fehlern kein zweiter Versuch lanciert wird. Deshalb auch die sporadischen Fehlermeldungen.

Wie löst man das Dilemma? Ich wandelte den Test folgendermassen um:

...
check host web.server.strasse.emeidi.local  with address 10.10.10.10
    if failed
	port 80
	protocol http
	with content = "Willkommen"
	for 10 cycles
    then alert
...

Die Anweisung with content = "Zeichenkette" forciert monit, einen GET-Request abzusetzen und keinen HEAD (da nur beim GET-Request ein HTTP-Body mitgeliefert wird). Und schwup, Problem gelöst.

Erweitert

Übrigens: Wem die Ausgabe von wget noch nicht ausreicht, da sie zu wenig geschwätzig ist, kann auch die Debug-Option verwenden:

$ wget --debug --spider --server-response "http://10.10.10.10/"
Setting --spider (spider) to 1
Setting --server-response (serverresponse) to 1
DEBUG output created by Wget 1.19.1 on darwin15.6.0.

Reading HSTS entries from /Users/user/.wget-hsts
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:02:44--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc231e0 (new refcount 0).
Deleting unused 0x00007ff99bc231e0.

---request begin---
HEAD / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
---response begin---
HTTP/1.1 501 Not Implemented
Server: Router Webserver
Connection: close
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Content-Type: text/html

---response end---

  HTTP/1.1 501 Not Implemented
  Server: Router Webserver
  Connection: close
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
  Content-Type: text/html
Closed fd 4
--2017-06-22 22:02:48--  (Versuch: 2)  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc23110 (new refcount 0).
Deleting unused 0x00007ff99bc23110.

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
---response begin---
HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"

---response end---

  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Closed fd 4
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: What headers are automatically send by wget?

Sackgassen

Initial befürchtete ich, dass der Web-Server des Zielsystems sich am User-Agent des Requests verschluckt. Doch dies war eine falsche Vermutung. Nichtdestotrotz könnte man monit so konfigurieren, dass es einen alternativen User-Agent sendet:


‚User-Agent‘ header can not be set via ‚http headers‘ array

Und noch ein anderes Beispiel: Trying to configure monit to use https protocol but it sticks with http

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 27. August 2016

SNMPd schreibt standardmässig kein PID-Datei mehr

Ein kürzlich erfolgtes Update des SNMPd-Pakets auf meinem Debian-Server hatte zur Folge, dass meine monit-Installation den Service fälschlicherweise als offline meldete.

Dies, weil monit nach der PID-Datei des SNMP-Daemons Ausschau hält, um dessen Prozess-ID auszulesen und auf Existenz zu prüfen. Bei Debian liegt diese Datei unter /var/run/snmpd.pid.

Folgendermassen re-aktivierte ich die PID-Datei:

/etc/systemd/system/multi-user.target.wants/snmpd.service

Vor der Anpassung …

...
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f
...

… und nach der Anpassung:

...
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f -p /var/run/snmpd.pid
...

Anschliessend folgte noch ein Neustart des Daemons:

# systemctl stop snmpd
Warning: snmpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# systemctl stop snmpd
# systemctl start snmpd

Und prompt meldete mir monit, dass der Service wieder online sei.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 2. April 2016

monit mit MacPorts unter OS X El Capitan installieren (mit angeblich fehlenden OpenSSL-Headern)

Vor einigen Tagen habe ich mich entschieden, mein MacBook Air (Late 2010) komplett platt zu machen und OS X El Capitan darauf zu installieren.

Nach der Neuinstallation musste ich auch alle meine MacPorts-Packages neu installieren. Leider gab es Probleme bei der Installation des Pakets monit:

$ sudo port install monit
Password:
---> Computing dependencies for monit
---> Configuring monit
Error: Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
Error: org.macports.configure for port monit returned: configure failure: command execution failed
Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets
Error: Processing of port monit failed

Ein Blick in /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log zeigte folgende detailliertere Fehlermeldung:

...
:info:configure checking for static SSL support... disabled
:info:configure checking for SSL support... enabled
:info:configure checking for SSL include directory... Not found
:info:configure 
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
:info:configure 
:info:configure Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1" && ./configure --prefix=/opt/local 
:info:configure Exit code: 1
:error:configure Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
:error:configure org.macports.configure for port monit returned: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
   while executing
"portconfigure::configure_main org.macports.configure"
   ("eval" body line 1)
   invoked from within
"eval $procedure $targetname"
:info:configure Warning: targets not executed for monit: org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
:notice:configure Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log

Der relevante Teil des Logs:

...
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
...

MacPorts openssl war aber installiert und die Header-Files fanden sich im Pfad /opt/local/include/openssl. Den Pfad hatte ich mit einer Suche nach ssl.h ausgemacht.

Nach mehr als einer Stunde Google-Suche war ich immer noch nicht weiter. Da kam mir der Geistesblitz: Das configure-Script von monit wird die SSL-Headers wohl im Standardverzeichnis suchen. Offenbar gibt es dieses Verzeichnis nicht, weshalb die Installation scheitert … wenn ich aber herausfinde, wie das Standardverzeichnis lautet, kann ich dieses mit einem Symlink auf das MacPorts-Verzeichnis umbiegen und die Installation sollte durchlaufen.

Gesagt, getan. Als erstes startete ich in einem Terminal-Fenster die Installation von monit:

$ sudo port install monit

In einem zweiten Tab führte ich dann folgenden Befehl aus, um alle Zugriffe auf das Dateisystem zu loggen:

$ sudo fs_usage

Nachdem das Tab mit dem MacPorts-Befehl wieder „bash“ als Titel anzeigte, stoppte ich fs_usage mit Ctrl-C. Anschliessend kopierte ich den ganzen Text in eine Textdatei, speicherte diese auf dem Desktop ab und begann, den Text zu greppen.

Ganz am Schluss der Aktivitäten kam heraus:

...
18:17:53  stat64            /usr/include/sys/_pthread/_pthread_key_t.h                                 0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsblkcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsfilcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /opt/local/include                                                         0.000013   clang       
18:17:53  stat64            /usr/local/include                                                         0.000005   clang       
18:17:53  stat64            /usr/local/include                                                         0.000004   clang       
18:17:53  stat64            /Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include    0.000013   clang       
18:17:53  stat64            .app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include    0.000007   clang       
18:17:53  stat64            /usr/include                                                               0.000005   clang

/usr/local/include tönte vielversprechend nach einem Standardpfad … und Bingo:

$ cd /usr/local/include
-bash: /usr/local/include: No such file or directory

Tönt wie ein Volltreffer. Dann versuchen wir es doch einmal damit:

$ sudo mkdir /usr/local/include
$ cd /usr/local/include
$ sudo ln -s /opt/local/include/openssl .

Alles bereit für den Versuch? Dann los — et voilà:

$ sudo port install monit
--->  Computing dependencies for monit
--->  Configuring monit
--->  Building monit
--->  Staging monit into destroot
--->  Creating launchd control script
###########################################################
# A startup item has been generated that will aid in
# starting monit with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo port load monit
###########################################################
--->  Installing monit @5.12.1_1
--->  Activating monit @5.12.1_1
--->  Cleaning monit
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

Die Jungs von homebrew haben die Problematik übrigens direkt im config-File gefixt, und zwar mit dem Parameter --with-ssl-dir, welches auf den openssl-Pfad zeigt:

...
def install
    system "./configure", "--prefix=#{prefix}",
                          "--localstatedir=#{var}/monit",
                          "--sysconfdir=#{etc}/monit",
                          "--with-ssl-dir=#{Formula["openssl"].opt_prefix}"
    system "make", "install"
    (share/"monit").install "monitrc"
...

Quelle: homebrew/monit.rb at master

Tags: , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen