Posts Tagged ‘Debug’

Sonntag, 3. April 2022

imapfilter debuggen

Link zu diesem Artikel

Kürzlich spammte ein via Cron alle fünf Minuten laufendes imapfilter-Script meine INBOX mit der folgenden Meldung voll:

imapfilter: IMAP (3): 1014 BAD Could not parse command

Wie debuggen? Gar nicht so kompliziert. Man führt das „Rezept“ einfach manuell auf der Kommandozeile aus.

$ imapfilter -l /tmp/log.txt -d /tmp/debug.txt -c recipe.lua

Anschliessend schaut man sich debug.txt an, sucht nach der Nummer des Befehls (hier: 1014) und schaut einige Zeilen davor an, um den Filterbefehl zu isolieren, der zur Fehlermeldung geführt hat. Das kann einige Zeilen vorher gewesen sein, weil imapfilter im Debug-Modus jede Aktion gegen den Mailserver aufführt. Das Gute: Jeder Befehl wird fortlaufend nummeriert. Beispiel:

1013 OK SEARCH completed (Success)
...
sending command (5):
1014 UID COPY
...
getting response (5):
1014 OK [COPYUID 100
...
sending command (5):
1015 UID STORE
...
getting response (5):
1015 BAD Could not parse command

In meinem Fall schienen alte Emails von Batmaid das Problem auszulösen. Ich passte den Filterbefehl an (indem ich jetzt neu gegen das Subject filtere, anstelle gegen den From-Header), und danach verschob ich die Emails auch noch manuell in den Unterordner.

Seither tritt die Fehlermeldung nicht mehr auf.

Vermutung: Irgendein nicht konformer Header im Email.

Tags: ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 16. Dezember 2021

g.fast SFP in Turris Omnia debuggen (leider erfolglos)

Link zu diesem Artikel

Grosser Nachtrag

vom 12. Februar 2022

Ich habe mir in der Zwischenzeit bei Engitech einen zweiten SFP bestellt.

Heute pröbelte ich mehrere Stunden mit dem Router herum. Auch der neue SFP konnte keine Verbindung aufbauen.

Beim Durchstöbern des irgendwie völlig neu ausschauenden Foris GUIs blieb ich auf der Unterseite Snapshots hängen. Und was sieht mein Auge da: Am 15. Dezember gab es Update-Aktivitäten! Und zwar wurde um 16:26 Uhr ein „Automatic pre-update snapshot“ angefertigt, und um 16:34 Uhr ein „Automatic post-update snapshot (TurrisOS 5.3.3)“. Also genau dann, als meine Internetverbindung gekappt wurde.

Eine böse, böse Vorahnung beschlich mich — und tatsächlich, nachdem ich auf TurrisOS 3.11.23 downgegradet hatte („Rollback“, dann Reboot), lief der SFP wieder und ich konnte eine Internet-Verbindung herstellen.

Da ich ein Problem mit 5.3.3 vermutete, installierte ich daraufhin TOS 5.3.5 (per SSH auf den Router einloggen, dann updater.sh ausführen). Doch das Problem bestand bei dieser neueren Version weiter.

Doch jetzt hatte ich die nötigen Indizien, mich in den Turris-Foren nach anderen Opfern herumzuschauen, und tatsächlich: No SFP connectivity after upgrade from 3.x, und sogar ein Init7-Kunde.

Wenn ich die Bemerkung Turris OS 5.0+ no longer supports switching between SFP and metallic in runtime im Artikel zum Upgrade TOS 3.x auf 5.x richtig verstehe, wird beim Update der SFP deaktiviert und stattdessen die mit dem SFP „geteilte“ Ethernetschnittstelle reaktiviert. KEIN WUNDER GEHT DANN (BEI MIR, UND ANDEREN SFP-BENUTZERN) GAR NICHTS MEHR. Heise hat einen Leser schon vor zwei Jahren darauf hingewiesen, wie er das Problem beheben kann.

Ah, und auch das Rätsel ist gelöst: WAN interface that was originally labeled in the system as eth1 is now eth2.

Morgen Sonntag, während Stephanie am Brunchen ist, werde ich also den Router erneut lüpfen, den Device Tree Blob (dtb) umbiegen und so hoffentlich den SFP wieder hochkriegen. Bye bye FrickelBox, eh Fritz!Box.

Heute am 15. Dezember 2021 um 16:34 Uhr fiel bei uns das Internet aus: Copper7 über g.fast (meine vom 1. Oktober bis heute, dem 15. Dezember 2021, verwendeten Komponenten sind hier beschrieben).

Zuerst war ich der Meinung, dass es sich um einen Ausfall von Swisscom oder Copper7 handelt, doch als die Internetverbindung auch nach einer Stunde und einem Reboot des Turris Omnia immer noch getrennt war, machte ich mich ans Debugging.

Leider habe ich die Internetverbindung mit dem g.fast SFP im Turris Omnia bis jetzt nicht mehr zum Laufen gebracht. Wie im oben verlinkten Artikel beschrieben hatte ich die von Init7 gelieferte AVM Fritz!Box 7582 noch im Lager, und diese hat nun (leider) den Turris Omnia ersetzt. Ich hoffe nur temporär …

Derzeit sehe ich zwei Möglichkeiten:

  • Swisscom hindert diesen spezifischen SFP seit heute an der Verbindungsaufnahme
  • Der SFP hat nach 75 Tagen Dauerbetrieb (teilweise) den Geist aufgegeben

Um den Fehler einzugrenzen habe ich die letzten Stunden noch etwas rumgepröbelt, nachdem unsere Wohnung wieder ans Netz kam.

  • Das Turris Omnia OS (TOS) ist 5.3.3
  • Der Turris Omnia SFP-Port heisst eth2 (mysteriös, denn auf den Screenshots vom Oktober habe ich eth1 mit PPPoE konfiguriert)
  • Ohne den SFP eingeschoben zu haben, gibt ethtool folgendes aus (MII = Media Independent Interface?): 
    # ethtool eth2
Settings for eth2:
	Supported ports: [ MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 10Mb/s
	Duplex: Half
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: d
	Wake-on: d
	Link detected: no
  • Mit eingeschobenen SFP sieht die Ausgabe folgendermassen aus (TP = Twisted Pair?): 
    # ethtool eth2
Settings for eth2:
	Supported ports: [ TP ]
	Supported link modes:   1000baseX/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseX/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: d
	Wake-on: d
	Link detected: no
  • Informationen über das SFP-Modul gibt man folgendermassen aus (werden Informationen angezeigt, bedeutet das gleichzeitig auch, dass der SFP erkannt wurde und funktioniert): 
    # ethtool -m eth2
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x22 (RJ45)
	Transceiver codes                         : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : Ethernet: 1000BASE-SX
	Encoding                                  : 0x01 (8B/10B)
	BR, Nominal                               : 1300MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF,km)                           : 0km
	Length (SMF)                              : 0m
	Length (50um)                             : 0m
	Length (62.5um)                           : 0m
	Length (Copper)                           : 255m
	Length (OM3)                              : 0m
	Laser wavelength                          : 0nm
	Vendor name                               : PROSCEND
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : 190-T
	Vendor rev                                : V7.3
	Option values                             : 0x08 0x00
	Option                                    : Retimer or CDR implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : XXXXXXXXXXXXXXXX
	Date code                                 : 210528__
  • Wenn kein SFP eingesteckt ist: 
    # ethtool -m eth2
Cannot get Module EEPROM data: No such device or address
  • Wenn es sich um keinen SFP Slot handelt: 
    # ethtool -m eth0
Cannot get module EEPROM information: Not supported
  • Wird der SFP eingesteckt, findet man unter /var/log/messages folgende Mitteilung: 
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.802636] sfp sfp: module PROSCEND         190-T            rev V7.3 sn XXXXXXXXXXXXXXXX dc 28-05-21
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.811981] sfp sfp:   unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.820179] sfp sfp:   1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.830301] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.836590] sfp sfp:   Wavelength 0nm, fiber lengths:
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.841657] sfp sfp:     9µm SM    : unsupported
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.846371] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.852135] sfp sfp:    50µm MM OM2: unsupported/unspecified
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.857893] sfp sfp:    50µm MM OM3: unsupported/unspecified
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.863657] sfp sfp:    50µm MM OM4: 2.540km
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.868023] sfp sfp:   Options: retimer
Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.871871] sfp sfp:   Diagnostics:
  • Mittels ip a sieht man noch weitere Infos — interessant ist NO-CARRIER (zu dem Zeitpunkt war das ADSL-Kabel nicht eingesteckt): 
    ...4: eth2:  mtu 1500 qdisc mq state DOWN group default qlen 532
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
  • Den SFP kann man über den i2c Bus abfragen. Bei mir ist der SFP unter /dev/i2c-5 ansprechbar. XXX ist die Seriennummer, YYY ist die MAC-Adresse: 
    # i2cdump 5 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-5, address 0x50, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 03 04 22 00 00 00 01 00 00 00 00 01 0d 00 00 00    ??"...?....??...
10: 00 00 ff 00 50 52 4f 53 43 45 4e 44 20 20 20 20    ....PROSCEND
20: 20 20 20 20 00 00 00 00 31 39 30 2d 54 20 20 20        ....190-T
30: 20 20 20 20 20 20 20 20 56 37 2e 33 00 00 00 fe            V7.3...?
40: 08 00 00 00 31 39 32 30 37 4b 35 38 39 32 31 35    ?... XXXXXXXXXXX
50: 30 30 34 38 32 31 30 35 32 38 00 00 00 00 00 92    XXXXXXXXXX.....?
60: 30 30 30 45 41 44 34 41 30 36 41 38 00 00 00 00    YYYYYYYYYYYY....
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
  • Entfernt man den SFP, erscheint folgender Eintrag in /var/log/messages: 
    Dec 15 23:21:22 TURRIS-OMNIA kernel: [  901.123920] sfp sfp: module removed

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

2 Kommentare | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Turris Omnia: Probleme mit pkgupdate debuggen

Link zu diesem Artikel

Mein Turris Omnia verwendet seit einiger Zeit das Kommandozeilentool pkgupdate, um sich zu aktualisieren (früher hatte diese Aufgabe offenbar ein Script namens updater.sh).

Gegen Ende dieser Woche wurde ich auf Grund eines nicht (mehr) existierenden Paketes regelmässig mit E-Mails eingedeckt, dass beim Update etwas fehlgeschlagen sein.

Beim Debuggen des Problems, welches ich in einem anderen Blog-Post beschreiben möchte, biss ich mir für einige Minute die Zähne an pkgupdater aus.

Gemäss Hilfe kann man mit dem Parameter -e die Verbosität des Tools einstellen:

$ pkgupdate --help
Usage: pkgupdate [OPTION]...
--help, -h			Prints this text.
--version, -V			Prints version of updater.
-R 			Use given path as a root directory. Consider also using --out-of-root option.
--batch				Run without user confirmation.
--state-log			Dump state to files in /etc/updater-state directory.
--ask-approval=	Require user's approval to proceed (abort if --approve with appropriate ID is not present, plan of action is put into the report-file if approval is needed)
--approve=			Approve actions with given ID (multiple allowed, from a corresponding report-file).
-s 		What level of messages to send to syslog.
-e 		What level of messages to send to stderr.
-S 		Under which name messages are send to syslog.
--task-log=		Append list of executed tasks into a log file.
--usign=			Path to usign tool used to verify packages signature. In default /usr/bin/usign.
--no-replan			Don't replan. Install everyting at once. Use this if updater you are running isn't from packages it installs.
--no-immediate-reboot		Don't reboot immediatelly. Just ignore immediate reboots. This is usable if you are not running on target machine.
--out-of-root			We are running updater out of root filesystem. This implies --no-replan and --no-immediate-reboot and is suggested to be used with -R option.

Doch was sind stderr Levels? Über eine Google-Suche stiess ich auch folgenden Kommentar zu einem völlig anderen Software-Produkt — sounds about right:

...
levels: {
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7,
},
...

Quelle: ‚debug‘ level is getting directed to stderr instead of stdout

debug war der Verbositäts-Level, welchen ich gesucht hatte. Versuchen wir es:

$ pkgupdate -e 7
DIE:Unknown log level 7
Aborted

Hmmm. Dann halt ausgeschrieben:

$ pkgupdate -e debug
DIE:Unknown log level debug
Aborted

Och Menno. Vielleicht dann alles in Grossbuchstaben?

$ pkgupdate -e DEBUG
DIE:Unknown log level DEBUG
Aborted

Himmelarsch! Zurück zu Google. Bei einem Gitlab-Checkin der Entwickler des Turris Omnia fand ich im Diff für das vorherige Script folgenden Hilfetext:

...
echo "-e (ERROR|WARNING|INFO|DBG|TRACE)	Message level printed on stderr. In default set to INFO."
...

Quelle: Store only single approved state

Somit lautet die korrekte Schreibweise:

# pkgupdate -e DBG

Und tatsächlich, damit klappte es.

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. März 2016

monit 5.16-2 strauchelt bei HTTP-Checks

Link zu diesem Artikel

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

Link zu diesem Artikel

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

Link zu diesem Artikel

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 …

Link zu diesem Artikel

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

Swiss Adventskalender 2014

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. Juni 2014

Die Chrome-Extension Send to Instapaper zurücksetzen

Link zu diesem Artikel

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

Link zu diesem Artikel

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

Link zu diesem Artikel

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

« Older Entries