Posts Tagged ‘Error’

Donnerstag, 20. Juli 2017

Apache nervt mit Warnmeldungen, dass das DAV-Modul bereits geladen sei

Seit Jahr und Tag nerve ich mich ab Log-Zeilen in der folgenden Form, welche im syslog und in E-Mail-Nachrichten zu cron-Jobs auftauchen:

[Mon Jul 17 06:25:06.171427 2017] [so:warn] [pid 724] AH01574: module dav_module is already loaded, skipping

Und zwar immer dann, wenn Apache 2.4 neu gestartet wird (bspw. mittels apache2ctl graceful).

Lustigerweise findet sich im Netz keine Lösung des Problems — ein Novum, das mich daran zweifeln lässt, ob neben mir überhaupt noch jemand mit diesem nervigen Problem zu kämpfen hat.

Ich habe bereits mehrere Anläufe genommen, um im Netz eine Lösung zu dem Problem zu finden. Doch erst beim gefühlten Dutzendsten Versuch fand ich tief versteckt in den Google-Resultaten dann doch noch die Lösung:

# error at apache2 startup
    AH01574: module dav_module is already loaded, skipping
# solution; edit /etc/apache2/mods-available/dav.load
    <IfModule !mod_dav.c>
        LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
    </IfModule>

Quelle: adrhc’s blog (ACHTUNG: Zertifikatsfehler!)

Geniale Idee des Kollegen aus Rumänien (der TLD nach zu urteilen): Indem man den Inhalt der Datei /etc/apache2/mods-available/dav.load in eine IfModule-Abfrage packt, verhindert man, dass mod_dav ein zweites Mal geladen wird.

Seither ist Ruhe.

Was ich hingegen immer noch nicht weiss: Wo mod_dav zum ersten Mal geladen wird. Ich fand keine zweite Lade-Anweisung irgendwo in den Konfigurationsdateien unterhalb von /etc/apache2.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: Race Condition mit resolv.conf und WiFi

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Dank ELK fand ich auf Grund von postfix Log-Meldungen bald einmal heraus, dass mein Raspberry Pi 3, welcher ein Dashboard in unserer Wohnung antreibt, keine E-Mails versenden kann. postfix konnte den Hostnamen meines Mail-Providers nicht auflösen:

DASHBOARD postfix/error[1234]: ABCDEF: to=<log@domain.tld>, orig_to=<root@dashboard>, relay=none, delay=40662, delays=40584/78/0/0.27, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=server41.cyon.ch type=A: Host not found, try again)

Nach einer längeren Debugging-Session dann die Erkenntnis:

The problem is that Postfix checks /etc/resolv.conf before the WiFi is connected. Therefore, /var/spool/etc/postfix/resolv.conf stays empty after the boot and mails cannot be sent.

Quelle: Postfix error: Host or domain name not found

Genau das war das Problem. Während der Kommentator auf Superuser empfiehlt, postfix erst nach der erfolgreichen WiFi-Verbindung zu starten, löste ich das Problem anderweitig, indem ich einen Cron-Job einrichtete:

...
*/1 * * * *	root	cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
...

Sicherlich nicht sexy, aber es löst das Problem (und schafft eventuell einige andere).

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: snmpd: Cannot statfs

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Heute geht es um snmpd und Mounts, deren Attribute der Daemon nicht auslesen kann. Dies äussert sich auf ELK mit folgenden Log-Meldungen:

... snmpd[1234] Cannot statfs /var/lib/docker/containers/: Permission denied ...
... snmpd[1234] Cannot statfs /var/lib/docker/aufs/mnt/: Permission denied ...
... snmpd[1234] Cannot statfs /run/docker/netns/: Permission denied ...
... snmpd[1234] Cannot statfs /run/user/1000/gvfs: Permission denied ...
... snmpd[1234] Cannot statfs /sys/kernel/debug/tracing: Permission denied ...

Ich versuchte mit verschiedenen Einträgen in /etc/snmp/snmpd.conf das auslesen dieser Mounts zu verhindern. Zuerst mittels der Direktive ignoredisk:

...
ignoredisk /run/user/*
ignoredisk /var/lib/docker/containers/*
ignoredisk /var/lib/docker/aufs/mnt/*
ignoredisk /run/docker/netns/*
ignoredisk /sys/kernel/debug/tracing
...

Das Blacklisting hatte leider keine Wirkung.

Auch der umgekehrte Weg, das Whitelisting, funktionierte nicht:

...
#includeAllDisks 10%
disk / 10%
...

Nach längeren Recherchen im Netz musste ich zum Schluss kommen, dass man solche Meldungen nicht mit Anpassungen an der SNMP-Konfiguration unterdrücken kann. Der Grund:

Because as I wrote in comment #2, snmpd reads /proc/mounts and runs statfs on each entry there. If any statfs call fails it logs an error. So, either stafs must not fail (i.e. no „net:[4026532288]“ entries in /proc/mounts) or snmpd must be fixed to log something more useful and only once.

Quelle: Bug 1314610 – snmpd complaining twice „Cannot statfs net:[********]#***: No such file or directory“ every 10 minutes

snmpd iteriert über die Einträge in /proc/mounts und führt ein statfs auf jeden Mountpoint durch. Das ist der Moment, in dem die Fehlermeldung geloggt wird.

Eine potentielle Lösung:

There needs to be an option to just make snmpd not try to look at these sort of mount points. The problem is that ignoreDisk only works for the devices, not mount points and a tmpfs has no „device“ name to match it by.

Quelle: snmpd storage reports all tmpfs and floods logfile

Dem Problem begegne ich nun, indem ich mit rsyslog solche snmpd-Fehlermeldungen ausfiltere und nicht zu Logstash übermittle. Der Filter dazu lautet:

...
if $programname == 'snmpd' and $msg contains 'statfs' then {
    stop
}
...

Tags: , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. Juni 2016

StatusCake funktioniert mit Hostpoint nicht mehr

Vor einigen Monaten wurde ich durch die Ankündigung einer Preiserhöhung beim schwedischen Pingdom aufgeschreckt und sah mich deshalb etwas genauer auf dem Markt für Web-Site-Monitoring herum.

Fündig wurde ich beim us-amerikanischen StatusCake, welches kostenloses Monitoring einer unlimitierten Zahl an Web-Sites bietet — sofern man damit leben kann, das Checks nur alle fünf Minuten erfolgen. Im Nu hatte ich um die 50 Tests eingerichtet — von SSH, OpenVPN, PPTP über ordinäres HTTP/S bis hin zu Dashboards, welche Laufzeitdaten zusammenziehen und mich mittels von 200 abweichenden HTTP-Codes bei Problemen warnen.

Das Monitoring funktionierte wunderprächtig, bis Hostpoint letzte Woche damit begann, von Apache 2.2 auf Apache 2.4 zu migrieren:

Apache Update

21.06.2016, 00:00 Uhr – 31.07.2016, 00:00 Uhr

Wir aktualisieren derzeit auf sämtlichen Server die Apache Version von 2.2 auf 2.4. Dieses Update ist grösstenteils transparent, nur in den unten aufgeführten Szenarien muss eine Anpassung vorgenommen werden. Für das Update wird es eine Unterbrechung von wenigen Sekunden geben.

HTTP/2

Neu Unterstützen wir mit Apache 2.4 das Protokoll HTTP/2. Dieses steigert die Effizienz bei der Kommunikation zwischen Browser und Server: Mehr Durchsatz, mehr Parallelität, weniger Latenz. Vor allem moderne web-2.0-typische Webseiten mit vielen kleinen Resourcen profitieren davon. Voraussetzung für HTTP/2 ist eine TLS geschützte Verbindung (SSL Zertifikat). Dieses steht dank FreeSSL all unseren Kunden zur Verfügung.

Quelle: Hostpoint – Statusseite

Wahrscheinlich seit der Migration auf die neue Web-Server-Version meldete StatusCake für jede meiner bei Hostpoint gehosteten Web-Sites Folgendes:

StatusCake - Geschichtstage Down
image-6773

Die konkreten Ausfallzeiten sind:

bibliothek-neuenegg.ch
2016-06-21 13:02:54 (Server: sl51.web.hostpoint.ch / s20)
sek-neuenegg.ch
2016-06-21 13:09:48 (Server: sl58.web.hostpoint.ch / s27)
geschichtstage.ch
2016-06-27 12:41:58 (Server: sl103.web.hostpoint.ch / s36)
ahc-ch.ch
2016-06-27 12:44:38 (Server: sl103.web.hostpoint.ch / s36)

Erste Anlaufstelle: Hostpoint

Zuerst dachte ich mir: Klarer Fall, da hat Hostpoint geschludert.

Ich kontaktierte dementsprechend deren Support am 28. Juni um 14:51 Uhr, um 17:22 Uhr erhielt ich die fachkundige Antwort von Jonas. Mittels eines Auszugs aus dem Domain Log legte er mir glaubwürdig dar, dass die StatusCake Probes den Server der Bibliothek Neuenegg bis heute alle fünf Minuten anpingen:

...
107.170.219.46 - - [28/Jun/2016:16:45:57 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
107.170.227.23 - - [28/Jun/2016:16:51:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
217.148.43.202 - - [28/Jun/2016:16:56:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
37.235.48.42 - - [28/Jun/2016:17:01:29 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
46.101.110.32 - - [28/Jun/2016:17:06:37 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
...

Eine manuelle Kontrolle meinerseits zeigte, dass dies auch bei allen anderen oben genannten Servern der Fall war.

Der Web-Server antwortet auf die HTTP/1.1-Anfrage mittels des HTTP-Codes 200 und liefert 8770 Bytes an Daten zurück. Ein kurzer Test mit wget von soeben zeigt, dass das durchaus hinkommt (wget erhält „nur“ 8697 Bytes zurück, also ca. 100 Bytes weniger — dies auf Grund einer Anpassung im Inhalt der Homepage; sprich: vernachlässigbar):

$ wget bibliothek-neuenegg.ch
--2016-06-29 19:34:30--  http://bibliothek-neuenegg.ch/
Auflösen des Hostnamens »bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://bibliothek-neuenegg.ch/ [folgend]
--2016-06-29 19:34:31--  https://bibliothek-neuenegg.ch/
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html            [ <=>                ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:34:31 (49,4 MB/s) - »index.html« gespeichert [8697]

Zweite Anlaufstelle: StatusCake

Nun gut. Dementsprechend stellte ich alle wichtigen Infos zusammen, die einem Second-Level-Supporter nützlich erscheinen könnten und kontaktierte am selben Tag um 19:09 Uhr Schweizer Zeit den Support von StatusCake. Dan antwortete mir am folgenden Tag um 11:07 Uhr morgens, ging aber wie von us-amerikanischem Support-Personal gewohnt überhaupt nicht auf mein Anliegen ein. Stattdessen erhielt ich wohl einen Knowledge-Base-Artikel als Standardantwort:

We use a large global network of testing servers, it’s looking to me like you may need to whitelist our IPs on these servers, you can grab our full lists here – https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/

9 Minuten später hatte ich ihm bereits geantwortet (wenn man einen Supporter schon mal „dran“ hat, sollte man ihn nicht mehr gehen lassen): Ich wies ihn darauf hin, dass die Apache Access Logs zeigen, dass die Server alle fünf Minuten Besuch von der Probe bekämen, Whitelisting also definitiv nicht das Problem sei.

Um 15:43 Uhr schrieb mir Dan zurück:

Had a look into this one. The only thing I can see that might be causing this is the introduction of HTTP/2, we don’t currently support this and will be giving a down result for any HTTP/2-only enabled sites.

Immerhin schien er die Status-Seite von Hostpoint aufgerufen und dort gelesen zu haben, dass HTTP/2 eingeführt wurde. Das wäre durchaus ein Ansatz, doch wieso taucht die Probe dann mit HTTP/1.1 in den Logs auf? Ich habe Dan zurückgeschrieben, doch bis jetzt ist noch keine weiterführende Antwort eingetrudelt. Ich bleibe dran!

Test mit wget

In der Zwischenzeit kam mir nun auch noch die Idee, dass der Web-Server vielleicht auf Grund des StatusCake User-Agents plötzlich meint, dass die Gegenseite fähig ist, HTTP/2 zu sprechen — und die Verbindung auf HTTP/2 upgradet.

Mit meinem lokal installierten wget probierte ich es aus:

$ wget --server-response --user-agent="Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" https://www.bibliothek-neuenegg.ch/
--2016-06-29 19:47:56--  https://www.bibliothek-neuenegg.ch/
Auflösen des Hostnamens »www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Date: Wed, 29 Jun 2016 17:47:56 GMT
  Server: Apache/2.4
  X-Powered-By: PHP/7.0.7
  Set-Cookie: PHPSESSID=dbneu9nses8n52ge8i4esj72b1; path=/
  Expires: Thu, 19 Nov 1981 08:52:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate
  Pragma: no-cache
  Upgrade: h2,h2c
  Connection: Upgrade, Keep-Alive
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Keep-Alive: timeout=5, max=100
  Transfer-Encoding: chunked
  Content-Type: text/html; charset=utf-8
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html                   [ <=>                              ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:47:56 (30,9 MB/s) - »index.html« gespeichert [8697]

Wie man sieht antwortet der Hostpoint-Server brav mit HTTP/1.1 200 OK (wget spricht KEIN HTTP/2; hätte der Server also — nicht-standardkonform notabene — mit HTTP/2 geantwortet, hätte wget mir einen Fehler angezeigt.).

Dritte Reaktion: Hostpoint entdeckt Blog-Post

Heute (1. Juli 2016) trudelte kurz nach 11 Uhr morgens eine neue Nachricht zu meinem eigentlich als geschlossen geglaubten Support-Ticket bei Hostpoint ein: Jessica nahm Bezug auf meinen kürzlich veröffentlichten Blog-Artikel und teilte mir mit, dass die Angelegenheit intern noch einmal genauer angeschaut worden war. Sie war es, welche mir in diesem E-Mail den entscheidenden Hinweis gab:

StatusCake scheint NodeJS zu verwenden. Dieses hat einen Bug, wenn Apache einen Upgrade Header mitschickt. Dies ist HTTP-Konform und ist so korrekt.

Sie können die Details in folgendem Threads nachlesen:

NodeJS unable to make https requests when h2 enabled in Apache 2.4.18 #73
http: do not emit `upgrade` on advertisement #4337

Hostpoint hatte mit ein wenig Recherche herausgefunden, dass ältere Versionen von NodeJS HTTP/HTTPS-Verbindungen zu Web-Servern abbrechen, wenn dieser mit einer HTTP/2-Upgrade-Anforderung antwortet. Und irgendwie hatte Hostpoint weiter bemerkt, dass StatusCake höchstwahrscheinlich NodeJS für die Abfragen einsetzt.

Klasse, genau solches Debugging liebe ich an meinem Beruf so sehr — und umso mehr freut es mich, wenn sich Dienstleister in einen Bug verbeissen und alles tun möchten, um diesen zu beheben.

Ich bedankte mich bei Jessica und wendete mich anschliessend gleich Dan von StatusCake zu.

Vierte Reaktion: StatusCake

Da ich von Dan seit meiner Rückmeldung nichts mehr gehört hatte, antwortete ich erneut auf sein letztes Mail und beschrieb ihm auf Englisch die von Hostpoint vermutete Ursache hinter dem Problem. Ich hatte ehrlich gesagt nicht viel Hoffnung, dass ich jemals wieder von StatusCake hören würde (Kunde, der (noch) keinen Umsatz generiert, und mit komischen Problemen nervt) — doch ich täuschte mich auch hier.

Um 11:35 Uhr ging meine Anfrage an Dan raus, um 11:44 Uhr (innert 9 Minuten!) lag bereits seine Antwort in der INBOX. Und dieses Mal nichts aus der Büchse, sondern eine tatsächlich auf meine Anfrage Bezug nehmende Antwort.

Dies wahrscheinlich aus verschiedenen Gründen:

  • Ich teilte ihm mit, dass Hostpoint der grösste Hoster in der Schweiz sei
  • Ich erwähnte NodeJS
  • Ich erwähnte die Nachricht von Jessica von Hostpoint und fügte die Links auf die NodeJS-Bugs ein
  • Ich erwähnte, dass auf Grund der weltweit laufenden Upgrades auf Apache 2.4 dieses Problem exponentiell zunehmen würde

Dan schrieb mir:

[…] this has been escalated to our engineers. We are working on this and we will have it sorted asap, it’s a big job so you’ll appreciate that the resolution will not be instant. Sorry if I wasn’t great at troubleshooting this at first – the results we were seeing did not make sense.

Dann warten wir also geduldig, bis StatusCake ihre NodeJS-Installation upgegradet hat …

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 15. Juni 2016

Ein Avocent DSR1031 meldet „Network Connect Error“

Heute fand per Post ein gebrauchter Avocent DSR1031 IPKVM-Switch den Weg zu mir nach Hause. Ich werde den IP-fähigen KVM-Switch im Elternhaus installieren, um im Notfall einen Linux-Server fernsteuern zu können.

Erste Ernüchterung bereits umgehend bei der Verbindung auf die IP-Adresse des Switches: Leider ist das von Acovent auf dem KVM-Switch verbaute Zertifikat im letzten Jahr abgelaufen:

Avocent DSR1031 Certificate Expired
image-6747

Als erstes aktualisierte ich das Firmware des Geräts auf Version 03.07.01.20, welche ich von der Web-Site des Herstellers heruntergeladen hatte (ich musste den FTP-Link manuell in CyberDuck einfügen; der Download mittels Web-Link klappte partout nicht).

Leider löste dies die Problematik des abgelaufenen Zertifikats nicht — so viel zu Hersteller-Support im SSL/TLS-Umfeld.

Anschliessend musste ich auf Firefox ausweichen, um ein Verbindungsfile hinter einem Link namens „KVM Session“ unter einem vom Vorbesitzer erfassten Device herunterzuladen — Safari zeigte einen Download an, die Datei fand sich aber nicht im Download-Ordner.

Der Klartext der heruntergeladenen Datei zeigte, dass es sich um ein sogenanntes Java Network Launch Protocol JNLP-File handelt:

<?xml version="1.0" encoding="utf-8"?>

<!-- JNLP File for Java Video Viewer Application -->

<jnlp spec="1.0+" codebase="http://10.0.1.227/webstart2">
   <information>
      <title>Video Session Viewer</title>
      <vendor>Avocent</vendor>
      <description>Video Session Viewer</description>
      <description kind="short">Video Viewer</description>
   </information>

   <security>
      <all-permissions/>
   </security>

   <resources>
      <j2se version="1.5+"/>
      
      <jar href="avctVideo.jar"/>
      <jar href="avctVM.jar"/>
      <nativelib href="avctWin32Lib.jar"/>
      <nativelib href="avmWin32Lib.jar"/>
      <nativelib href="avctLinuxLib.jar"/>
      <nativelib href="avmLinuxLib.jar"/>
      <nativelib href="avctSolarisLib.jar"/>
      <nativelib href="avmSolarisLib.jar"/>
      <nativelib href="avctMacOSXLib.jar"/>
      <nativelib href="avmMacOSXLib.jar"/>
      <nativelib href="jpcscdll.jar"/>
      <nativelib href="jpcscso.jar"/>
   </resources>
...

Diese Datei startet man folgendermassen:

$ javaws -verbose kvm.cgi

Leider erhielt ich mit J2SE Version 8 Update 91 folgende Fehlermeldung zu Gesicht:

Avocent Network Connect Error
image-6748

Nach einigen Recherchen im Internet fand ich im Support-Forum des Herstellers im Beitrag „AutoView 3016 Java network connect error“ die Lösung.

In der Datei /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/java.security müssen zwei Parameter für den Umgang mit verschlüsselten Verbindungen angepasst werden:

...
#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.certpath.disabledAlgorithms=
...
#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
jdk.tls.disabledAlgorithms=
...

Danach klappte die Verbindungsaufnahme:

Avocent Video Viewer Channel not found
image-6749

Leider habe ich so meine Java-Installation extrem unsicher gemacht. Die Browser-Plugins habe ich seit längerem allesamt deaktiviert, was das Risiko etwas senkt.

Nachtrag

Mittlerweile habe ich — selbstverständlich mittels Internet-Resourcen — herausgefunden, wie man die Java-Einstellungen ausschliesslich nur für einen bestimmten Prozess abändert. Hierzu habe ich mir ein Script geschrieben, mit welchem ich den Avocent Viewer starten kann:

#!/bin/bash
...
SCRIPTDIR="/path/to/script/dir"
...
JAVAWS=$(which javaws)
JNLP="$SCRIPTDIR/kvm.jnlp"
JAVASECURITY="$SCRIPTDIR/java.security"

# http://stackoverflow.com/questions/1047154/java-webstart-options
CMD="$JAVAWS -J\"-Djava.security.properties=$JAVASECURITY\" $JNLP &"
echo $CMD
eval $CMD
echo ""

exit 0

Im Verzeichnis, in welchem das Bash-Script liegt, habe ich eine Kopie der oben genannten Datei java.security abgelegt und die Anpassungen an der lokalen Kopie vorgenommen (die globale Datei java.security führt nur die sicheren Ciphers auf). Den Pfad zur lokalen Datei übergebe ich Java Web Start mittels einer Kommandozeile -J, in welcher eine Java-Argument verschachtelt ist -D.

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Mai 2016

MariaDB (MySQL) meldet „ERROR 1436 (HY000) at line 574: Thread stack overrun“

Damit die Migration von MySQL nach MariaDB sauber abläuft, ist es wichtig, nach der De-Installation von MySQL und der erfolgreichen Installation von MariaDB folgendes Kommando auszuführen (Anstoss war eine Fehlermeldung in mysql.log):

# mysql_upgrade
...
ERROR 1436 (HY000) at line 574: Thread stack overrun:  5904 bytes used of a 131072 byte stack, and 0 bytes needed.  Use 'mysqld --thread_stack=#' to specify a bigger stack.

Blöd nur, wenn diese Fehlermeldung erscheint. Nach einer kurzen Google-Suche stellte sich heraus, dass mein Konfigurationstuning in /etc/mysql/my.cnf einen Kollateralschaden verursacht hatte. In der Konfigurationsdatei hatte ich nämlich eingestellt:

...
[mysqld]
...
thread_stack		= 128K

Dieser Wert berechnet sich für jedes System basierend auf dessen Eigenschaften und es macht deshalb keinen Sinn, den Wert in my.cnf hartzukodieren, wie der Artikel MySQL error 1436: Thread stack overrun, with simple query aufzeigt.

Das Problem löste sich in Luft auf, indem ich den Eintrag auskommentierte …

#thread_stack		= 128K

… und den Datenbankserver neu startete:

# systemctl restart mysql

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. Januar 2016

MySQL meldet Fehler 2049

Vor einigen Wochen habe ich im Zuge eines apt-get upgrade MySQL auf meinem Linux-Server zu Hause aktualisiert. Wie gelegentlich der Fall resultierte das Update in einem Kollateralschaden. In meinem PHP Error-Log las ich nach dem Update für einige meiner Web-Applikationen folgendes:

MySQL returned error #2049: Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

Nach etwas Googeln stellte sich heraus, dass einige meiner MySQL-Benutzer ihr Passwort noch mit einem uralten MySQL-Hash in der Datenbank liegen hatten:

Support for pre-4.1 password hashes is removed in MySQL 5.7.5. This includes removal of the mysql_old_password authentication plugin and the OLD_PASSWORD() function.

Quelle: 6.1.2.4 Password Hashing in MySQL

Nachdem ich die Klartext-Passwörter im PHP-Code der Applikationen ausfindig gemacht hatte, änderte ich diese mittels phpMyAdmin in den MySQL-Benutzertabelle und verwendete dafür die PASSWORD()-Funktion.

Noch ein FLUSH PRIVILEGES, und die Web-Applikationen funktionierten wieder ohne Murren.

Tags: , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Das Mac OS X Home-Verzeichnis mit rsync über SSH auf eine Synology Diskstation sichern

Nachdem ich den schlüsselbasierten Login hingekriegt hatte, stand ich bereits wieder vor dem nächsten Problem: Mein rsync-Script zur Sicherung meines Mac OS X Home-Verzeichnis in einen Unterordner auf meinem Home-Verzeichnis auf dem Synology NAS brach mit folgender Fehlermeldung ab:

...
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only
...

Wieso denn das? Mit dem Synology-Konto meines Raspberry Pi klappt die ganze Chose problemlos!

Mit den Hinweisen unter Rsync over ssh: “ERROR: module is read only” suddenly appeared wurde ich auf den richtigen Pfad gelenkt: Ich musste meinem Benutzer mittels des Synology Web-GUIs Schreibrechte auf den Homes-Ordner geben:

  1. Control Panel
  2. Users
  3. %BENUTZER% auswählen
  4. Edit
  5. Privileges Setup
  6. homes
  7. [x] Read/Write
  8. OK

Seither klappt die rsync-Synchronisierung. Ob ich aber damit eine Sicherheitslücke geöffnet habe?

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

Sonntag, 7. Oktober 2012

Syntax eines PHP-Scripts auf der Kommandozeile überprüfen

Nicht immer produziere ich auf dem lokalen Mac Code in einem Verzeichnis, welches über den lokalen Web-Server angesprochen werden kann. Wenn ich den Code auf den Server des Kunden kopiert habe und mir dort eine gähnende Leere entgegenblickt, ist die Vermutung in der Regel ein Syntax-Problem, welches den PHP-Parser zum Abbruch bewegt. So genau weiss man das natürlich nicht, da man als guter Entwickler display_errors auf einem Produktivsystem auf 0/off/false gesetzt hat und Fehlermeldungen nur in das error_log ablegt.

Entweder öffnet man das error_log via FTP, oder aber man lässt die Syntax auf dem Mac selber von der Kommandozeilenversion von PHP überprüfen:

php -l <Pfad zum syntaktisch defekten PHP-Script>

Dies führt entweder zur Absolution mit

No syntax errors detected in <Pfad zum syntaktisch defekten PHP-Script>

oder aber im unglücklicheren Fall zur folgenden oder ähnlichen Fehlermeldung:

Parse error: parse error in <Pfad zum syntaktisch defekten PHP-Script> on line 146
Errors parsing <Pfad zum syntaktisch defekten PHP-Script>

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen