Posts Tagged ‘Debug’

Dienstag, 1. März 2016

monit 5.16-2 strauchelt bei HTTP-Checks

Seit einem apt-get dist-upgrade auf einem meiner Debian-Server meldete die Überwachungslösung monit Probleme mit dem periodischen Check der Verfügbarkeit von HTTP-Servern:

...
[CET Mar 1 19:28:18] error : 'printer.schloesslistrasse.local' failed protocol test [HTTP] at [10.1.2.3]:80/script/cookieCode.js [TCP/IP] -- HTTP: Error receiving data -- Resource temporarily unavailable
...

(Die URL hatte ich im Zuge des Debugging ergänzt, da ich zuerst nicht sicher war, ob monit eine allfällige HTTP 403er-Meldung sauer aufstossen würde — ohne aktiviertem Browser-JavaScript wird die Seite im wwwroot aber anstandslos ausgeliefert)

Ein zweiter Debian-Server hatte mit exakt denselben Checks keine Probleme. Der kleine, aber feine Unterschied: monit 5.9-1+deb8u1 (jessie, stable) zeigt das Fehlverhalten nicht, während 5.16-2 (sid, unstable) mit HTTP-Checks strauchelt. Doch das realisierte ich leider erst viel, viel später.

Zuerst machte ich mich im Quellcode der Anwendung schlau:

static void check_request(Socket_T socket, Port_T P) {
        int status, content_length = -1;
        char buf[512];
        if (! Socket_readLine(socket, buf, sizeof(buf)))
                THROW(IOException, "HTTP: Error receiving data -- %s", STRERROR);

Quelle: Monit / src / protocols / http.c

Das half dann doch weniger als erwartet zur Problemlösung bei.

Als nächste schraubte ich die Geschwätzigkeit der Installation hoch, indem ich in /etc/init.d/monit die Konfigurationsoption MONIT_OPTS anpasste:

...
DAEMON=/usr/bin/monit
CONFIG=/etc/monit/monitrc
NAME=monit
DESC="daemon monitor"
#MONIT_OPTS=
MONIT_OPTS="-vv"
PID="/run/$NAME.pid"
...

Viel mehr gab das Log unter /var/log/monit dann aber doch nicht preis:

...
[CET Mar 1 19:33:55] debug : Socket test failed for [10.1.2.3]:80 -- HTTP: Error receiving data -- Resource temporarily unavailable
[CET Mar 1 19:33:55] error : 'printer.schloesslistrasse.local' failed protocol test [HTTP] at [10.1.2.3]:80/script/cookieCode.js [TCP/IP] -- HTTP: Error receiving data -- Resource temporarily unavailable
[CET Mar 1 19:33:55] debug : -------------------------------------------------------------------------------
[CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x8062c37]
[CET Mar 1 19:33:55] debug : /usr/bin/monit(LogError+0x27) [0x8063097]
[CET Mar 1 19:33:55] debug : /usr/bin/monit(Event_post+0x243) [0x805f573]
[CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x807373f]
[CET Mar 1 19:33:55] debug : /usr/bin/monit(check_remote_host+0x16b) [0x8075bfb]
[CET Mar 1 19:33:55] debug : /usr/bin/monit(validate+0x2e9) [0x8073e99]
[CET Mar 1 19:33:55] debug : /usr/bin/monit(main+0x505) [0x8051d95]
[CET Mar 1 19:33:55] debug : /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xde) [0xb728670e]
[CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x8052293]
[CET Mar 1 19:33:55] debug : -------------------------------------------------------------------------------
...

Nach viel Pröbeln hatte ich dann doch endlich die Erkenntnis, dass es wohl nicht die beste Idee war, ein als unstable markiertes Paket zu verwenden. Doch wie downgraden? Ganz einfach:

# apt-get install monit=1:5.9-1+deb8u1

Quelle: How to Downgrade a Package via apt-get?

Damit das Paket aber beim nächsten apt-get dist-upgrade nicht mit der fehlerhaften Version überschrieben wird, musste ich noch folgenden Befehl ausführen:

# apt-mark hold monit

Quelle: PinningHowto

Seither wird meine INBOX nicht mehr mit Warnungen geflutet.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 26. März 2015

monit unter Mac OS X neu starten

Vor einigen Tagen meldete mir die monit-Instanz aus einem anderen Subnet, dass die Web-Oberfläche der monit-Instanz auf meinem Mac mini nicht mehr ansprechbar war. Heute, nach unzähligen Warnmeldungen, habe ich mich um das Problem gekümmert.

Wie sich herausstellte, liess sich das Problem beheben, indem ich monit schlicht neu startete. Auf der Mac OS X-Kommandozeile geht dies so:

$ sudo launchctl unload /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist
$ sudo launchctl load /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist

Via: Monit

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 12. Januar 2015

IPP-Druckserver debuggen

Kürzlich musste ich zu Hause einen IPP-Druckserver (natürlich Apples CUPS) debuggen. Dabei entdeckte ich folgenden Befehl, um von einem Client-System zu prüfen, ob und wie der IPP-Druckserver auf Anfragen reagiert.

Dank der Fehlermeldung des CUPS-Servers als Antwort auf nachfolgenden Befehl …

$ ipptool -v -4 http://10.10.10.10:631/Laserdrucker get-printer-attributes.test
The printer or class does not exist.
       EXPECTED: STATUS successful-ok (got client-error-not-found)
       status-message="The printer or class does not exist."
       EXPECTED: charset-configured
       EXPECTED: charset-supported
       EXPECTED: compression-supported
       EXPECTED: document-format-default
       EXPECTED: document-format-supported
       EXPECTED: generated-natural-language-supported
       EXPECTED: ipp-versions-supported
       EXPECTED: natural-language-configured
       EXPECTED: operations-supported
       EXPECTED: pdl-override-supported
       EXPECTED: printer-is-accepting-jobs
       EXPECTED: printer-name
       EXPECTED: printer-state
       EXPECTED: printer-state-reasons
       EXPECTED: printer-up-time
       EXPECTED: printer-uri-supported
       EXPECTED: queued-job-count
       EXPECTED: uri-authentication-supported
       EXPECTED: uri-security-supported

… realisierte ich, dass ich meinen Laserdrucker über die URL http://10.10.10.10:631/printers/Laserdrucker ansprechen muss.

Auf dem Druckserver selber zeigt man sich den Status des Druckers mit folgendem Befehl an:

$ lpstat -p
printer Laserdrucker is idle. enabled since Wed 10 Dec 2014 06:56:43 PM CET

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 15. Dezember 2014

Wenn man das SWISS-Osterei partout nicht im Adventskalender 2014 finden kann …

… ja dann hilft nur die gute, alte Web-Entwickler-Konsole:

Swiss Adventskalender 2014
image-6024

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. Juni 2014

Die Chrome-Extension Send to Instapaper zurücksetzen

Vor kurzem habe ich die Passwortsicherheit zweier meiner Online-Accounts verbessert, unter anderem Instapaper.

Unter Google Chrome führte der Passwortwechsel aber zu einem Problem mit der Erweiterung „Send to Instapaper“ (im Chrome Web Store finde ich sie aber irgendwie nicht (mehr) … hier die ID: liamajdghafnpofaconeimppimbdbhgi), mit welcher ich Artikel für eine spätere Lektüre zwischenspeichere: Bei jedem Klick auf den Button änderte sich dieser in ein rotes X, ohne mir die Möglichkeit anzubieten, das Passwort auszutauschen.

Nach einigem Googlen und pröbeln hatte ich dann die Lösung:

  • Unter Windows finden sich die Chrome-Erweiterungen im Verzeichnis C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Extensions\
  • Die besagte Erweiterung fand sich unter C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Extensions\liamajdghafnpofaconeimppimbdbhgi\1.2_0
  • Den „Local Store“, eine SQLite-Datenbank, welche die Erweiterung zur Ablage der Zugangsdaten verwendet, findet sich unter C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Local Storage\chrome-extension_liamajdghafnpofaconeimppimbdbhgi_0.localstorage sowie extension_liamajdghafnpofaconeimppimbdbhgi_0.localstorage-journal

Indem man Chrome schliesst, die zwei Dateien im Local Store löscht und Chrome danach wieder startet, wird man beim nächsten Klick auf den Button zur Eingabe der Zugangsdaten aufgefordert.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

SSH zwingen, sich ausschliesslich mit einem spezifischen Private Key anzumelden

Wer bereits einmal SSH-Verbindungsaufnahmen debuggen musste und dazu den Kommandozeilenparameter -v, -vv oder -vvv verwendet hat, weiss, das der SSH-Agent standardmässig all im .ssh-Ordner vorhandenen private Keys durchprobiert, bis einer passt (oder eben nicht).

Ob dies eine Sicherheitslücke darstellt weiss ich nicht, aber ich finde es ineffizient. Diese Unschönheit lässt sich mit zwei zusätzlichen Parametern IdentityFile sowie IdentitiesOnly in den Host-Definitionen in .ssh/config beheben:

Host shortcut
	Hostname domain.tld
	IdentityFile /Users/mario/.ssh/id_rsa_special
	IdentitiesOnly

Quelle: GitHub / SSH with multiple identities; the slightly-more-definitive guide

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 13. Januar 2014

Das PHP Error-Log von einem Cyon-Server täglich per E-Mail zusenden

Ein guter Web-Entwickler hält das PHP Error-Log seiner Web-Sites und -Applikationen stets im Auge. Ich persönlich habe mir zum Ziel gesetzt, dass nur ein leeres Log ein gutes Log ist. Dies bedeutet demzufolge, dass man auf Produktivsystemen sauberen Code ausliefert. Und sollten doch einmal Fehlermeldungen, Warnungen und Infos im PHP Error-Log auftauchen, gilt es diese zeitnah zu beheben.

Damit man eine Web-Präsenz, welche auf einem Cyon-Server mit SSH-Zugang läuft, überwachen kann, sind folgende Anpassungen nötig:

php.ini

Bei meinen Hostings befindet sich diese Konfigurationsdatei unter ~/etc/php_settings/default/php.ini. In dieser Datei sollten die folgenden Parameter gesetzt sein:

...
error_log = /home/%CYON-ACCOUNT%/var/log/php.err
...
error_reporting = E_ALL # Allenfalls auch & ~E_DEPRECATED
...

Dabei sollte man sicherstellen, dass das Verzeichnis /home/>benutzernamen>/var/log/ existiert und schreibbar ist.

mail-php-error-log.sh

Nachfolgendes Script sorgt dafür, dass der Inhalt der heutigen php.err per E-Mail an eine frei definierbare E-Mail-Adresse gesendet wird. Nach dem Versand wird die php.err kopiert und das Original danach gelöscht. Dem Dateinamen der Kopie wird dabei der aktuelle Tag des Jahres (1 bis 365) angehängt, womit wir eine Art automatisiertes logrotate durchführen:

#!/bin/sh

LOG="/home/%CYON-ACCOUNT%/var/log/php.err"

if [ ! -f "$LOG" ]
then
        echo "File '$LOG' not found"
        exit 1
fi

LINES=`cat "$LOG" | wc -l`

if [ $LINES -lt 1 ]
then
        exit 0
fi

#echo "Since log file is not empty ($LINES lines) I'm now posting its content to the webmaster"
cat "$LOG" | mail -s "php.err" logger@domain.tld
#echo "Would now be sending mail"

# Secret Sauce
DAYOFYEAR=$(date +%j)
cp "$LOG" "$LOG.$DAYOFYEAR"
rm "$LOG"

exit 0

Dieses Script habe ich in meinem Home-Folder abgelegt und mittels chmod 700 für meinen Benutzer ausführbar gemacht.

crontab

Schlussendlich richtet man sich noch einen Eintrag in crontab ein, damit das Script automatisiert einmal im Tag aufgerufen wird:

$ crontab -e

Der Inhalt dieser Datei lautet:

MAILTO="logger@domain.tld"
...
12 23 * * * /home/%CYON-ACCOUNT%/mail-php-error-log.sh

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Schwer zu eruierende LaTeX-Kompilationsfehler debuggen

Kürzlich konnte ich ein Dokument eines aktuellen LaTeX-Projektes nicht mehr kompilieren. pdflatex brach immer mit der folgenden Fehlermeldung ab:

...
! Missing \endcsname inserted.
 
\protect 
l.75 \printbibliography[heading=none]
...

Welcher der über 300 Einträge in der Bibliographie verursachte das Problem? Erst das manuelle Eingrenzen durch radikales Löschen (natürlich mit Sicherheitskopie der .bib-Datei) von Bibliographie-Einträgen brachte schlussendlich den verantwortlichen Eintrag zu Tage: Auf Grund der Overfull \hbox-Meldungen in der Log-Datei wusste ich, zwischen welchen zwei Einträgen das Problem bestand, nicht aber, welcher der circa 30 Einträge effektiv das Problem war. Nach der Löschaktion war der Eintrag isoliert. Meine Analyse ergab, dass ich in JabRef in das Feld Language den Wert Französisch eingetragen hatte, welches beim Abspeichern der Bibliographie zu Franz{\“o}sisch wird. Offenbar mag das Paket biblatex solche Sonderzeichen in diesem Feld gar nicht und bricht stumm ab …

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

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Dezember 2013

syslog-ng motzt über nicht konforme Konfigurationssyntax

Bei den gelegentlichen apt-get dist-upgrades auf meinem Linux-Server motzt syslog-ng bei jedem Neustart des Services über eine inkompatible Syntax von /etc/syslog-ng.conf:

WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode Please update it to use the syslog-ng 3.5 format at your time of convinience, compatibility mode can operate less efficiently in some cases. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file.;

Wie löst man dieses Problem? Ich bin folgendermassen vorgegangen:

  1. Zuerst passe ich die Zeichenkette in /etc/syslog-ng.conf an. Anstelle der Version 3.3 trage ich dort frech wie ich bin einfach probehalber mal folgendes ein:

    @version: 3.5
    ...
  2. Als nächstes prüfe ich, dass syslog-ng mit den restlichen Angaben in der Konfigurationsdatei einverstanden ist — sprich in der Datei keine Syntax-Fehler vorhanden sind:

    # syslog-ng --syntax-only

    Wird hier keine Meldung gemacht, ist alles in bester Ordnung.

  3. Schlussendlich startet man syslog-ng neu:

    /etc/init.d/syslog-ng restart

Und gut is!

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 7. Oktober 2013

Ein PHP-Script so geschwätzig wie möglich machen

<?php
	ini_set('error_reporting',E_ALL);
	ini_set('display_errors',1);

	...
?>

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen