Apr 13

Heute hatten wir ein kurioses Problem mit einem Apache 2.2.22 Server.
Es ging um eine Domain, welche zwei Sub-Domains hat, wovon eine korrekt funktionierte und die andere nicht, sprich diese immer wieder zur Hauptdomain umleitete.

Der Aufbau der Verzeichnisstrucktur ist wie folgt:

/srv/www/webseite <- Hauptdomain www.muster.de
/srv/www/webseite/TEST <- Sub-Domain Nr. 1 test.muster.de
/srv/www/webseite/DEMO <- Sub-Domain Nr. 2 demo.muster.de

Der Nameserver ist korrekt konfiguriert:

muster.de. IN SOA ns1.nameserver.de. dns.ns.de. (
20170413
1800
3600
3600000
1800 )
muster.de. IN NS ns1.ns.de.
muster.de. IN NS ns2.ns.de.

muster.de. IN A 80.80.80.80
www IN A 80.80.80.80
demo IN A 80.80.80.80
test IN A 80.80.80.80
ftp IN CNAME ftp.ns.de.

mail IN CNAME mail.ns.de.
muster.de. IN MX 10 mx1.ns.de.
muster.de. IN MX 20 mx2.ns.de.

Und auch der Apache war korrekt konfiguriert:

<VirtualHost 80.80.80.80:80>

ServerName www.muster.de
ServerAlias muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName demo.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/DEMO
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName test.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/TEST
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

Zum Test lag in den beiden Unterverzeichnissen DEMO und TEST jeweils eine Datei test.html!

Der Aufruf test.muster.de/test.html erfolgte korrekt, sprich in der Webbrowser-Adress-Zeile stand dann auch noch test.muster.de/test.html und im Apache Log:
200.200.200.200 - - [13/Apr/2017:14:20:23 +0200] "GET /test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 439 491

Im Gegensatz zum Aufruf demo.muster.de/test.html, denn hier erfolgte eine 301-Weiterleitung nach www.muster.de/DEMO/test.html, was dann auch in der Webbrowser-Adress-Zeile angezeigt wurde und im Apache Log folgendes stand:
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /test.html HTTP/1.1" 301 203 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 421 658
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /DEMO/test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 443 491

Leider konnte mir Google & Co. hier nichts wirklich weiterhelfen, so das ich begann, die beiden Verzeichnisse vom Inhalt her zu vergleichen.

Die Lösung lag in der fehlenden .htaccess Datei im Verzeichniss /srv/www/webseite/DEMO

Vom TEST-Verzeichniss die Datei .htaccess ins DEMO-Verzeichniss kopiert und es lief sofort. Warum ist mir zwar nicht ganz klar und für einen entsprechenden Kommentar wäre ich auch dankbar aber ich hoffe zumindest anderen mit dem gleichen Problem weiterhelfen zu können.

Tagged with:
Jun 06

Fehlerbild

Das folgende Fehlerbild brachte ein paar lange Abende und schlaflose Nächte:

WLAN-Netz 1:

WLan Netzstruktur 1

Alle drei Geräte können problemlos ins Internet ohne Einschränkungen, sprich haben demzufolge eine funktionierende WLAN-Verbindung.

  • Vom Laptop zum Android-Tablet ist eine Kommunikation über WLAN nicht möglich, getestet mit der App AirDroid.
  • Eine Verbindung über WLAN zwischen Android-Tablet und dem Smartphone ist nicht möglich
  • Zwischen dem Smartphone und dem Laptop ist ebenfalls keine Kommunikation über WLAN möglich

WLAN-Netz 2:

WLan Netzstrucktur 2

Ebenfalls sind alle drei Geräte per WLAN mit dem Router Speedport Entry verbunden und können ins Internet.

  • Das Canon Tool findet den Drucker per WLAN Direktverbindung, danach wird der Drucker aber über den WLAN-Router nicht mehr gefunden
  • Das Nexus 4 kann über die Canon App den Canon Drucker ebenfalls nicht finden
  • Der Laptop kann nicht das Nexus 4 über die App AirDroid erreichen

Das Fehlerbild in beiden Netzen trat „plötzlich“ auf, sprich zuvor funktionierte die WLAN-Interne Gerätekommunikation.

Hinweis: Alle WLAN-Geräte waren unter Heimnetzwerk im Router Speedport Entry mit IP und MAC-Adresse sichbar und als Aktiv angemeldet!

Fehlersuche

Es wurde zunächst sogar im Falle von WLAN-Netz 2 ein Problem mit dem Drucker vermutet und dieser wurde vom Hersteller ausgetauscht.
Nachdem der ausgetauschte Drucker aber die gleichen Symptome aufwies und weder vom Laptop noch vom Nexus 4 gefunden werden konnte, mußte die Fehlersuche fortgesetzt werden.

Dadurch das jetzt Querversuche vom Tablet und Smartphone vorgenommen wurden, konnten Virenscanner, Windows/Laptop-Probleme eigentlich ausgeschlossen werden.
Auch ein Router-Neustart und das durchschauen der überschaubaren Einstellungsmöglichkeiten im Router Speedport Entry brachte keine Hilfe.

Also bei der Telekom Hotline angerufen, leider erfolglos, denn hier wurde nur mitgeteilt, das der Router KEINE Möglichkeit hat die WLAN-Interne Kommunikation der WLAN-Geräte untereinander zu blockieren, wie es bei anderen Routern möglich ist. Und es wurde behauptet, das NICHT der Router Speedport Entry die Wurzel des Übels ist.

Die Lösung: Werksreset

Irgendwo im Internet laß ich dann bei einem ganz anderem Router-Problem, das der Besitzer hier durch ein Werksreset sein Problem lösen konnte.
Als letzten Versuch für diesen zweiten Abend dann wurden die Zugangsdaten rausgesucht und der Router-Werksreset durchgeführt.
Die Zugangsdaten neu eingegeben und die Canon Setup unter Windows fand den Drucker sofort, natürlich die App auf dem Nexus 4 ebenso!

Tagged with:
Jan 04

Beim Versuch mit dem Perl Modul Selenium::Firefox und einem vorhandem Perl-Script welches letztes Jahr noch problemlos funktionierte, heute wieder eine Webseite zu generieren, kam leider nur der Fehler
Unable to connect to the /usr/bin/firefox binary on port 9090 at /usr/local/share/perl/5.18.2/Selenium/CanStartBinary.pm line 126.

Also auf zu Google und suchen… die ersten Versuche nach obiger Fehlermeldung zu suchen brachten keine sinnvollen Ergebnisse…

Erst als ich nach „Bug Firefox port 9090“ suchte, fand ich unter den Ergebnissen Selenium Bug Meldung welche als letzten Kommentar von Frédéric Buclin, den passenden Hinweis gab:

Workaround for Firefox 43:

After Selenium::Remote::Driver is installed, edit Selenium/Firefox/webdriver_prefs.json and add

„xpinstall.signatures.required“: false

at the end of the „frozen“ list.

Die Datei webdriver_prefs.json fand ich in meinem System unter:
/usr/local/share/perl/5.18.2/Selenium/Firefox
dort im ersten „Block“
"frozen": {
ganz am Ende
"xpinstall.signatures.required": false
einfügen, wobei darauf zu achten ist, in der Zeile darüber das Komma am Ende der Zeile nicht zu vergessen!

Perl-Script starten und alles funktioniert! 🙂

Update Firefox 47: (25.07.2016)

Nachdem Ubuntu den Firefox auf Version 47.0 aktualisiert hatte, kam wieder obiger Fehler zustande, sprich es funktioniert wieder nicht mehr. Auf den folgenden Seiten fand ich die Hinweise für die passende Lösung:
Stackoverflow.com, Selenium-Remote-Driver auf Github und SeleniumHQ auf Github

Ubuntu 14.04.4 LTS (Stand: 25.07.2016) enthält den Firefox Version 47.0 und nicht den Firefox Version 47.0.1 welcher wieder mit dem Selenium-Driver 2.53.1 zusammenarbeitet, weshalb zunächst ein Update für den Firefox zwingend notwendig ist!

Firefox 47.0.1 wird in den 3rd Party Repository: Ubuntu Mozilla Security angeboten:

sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
sudo apt-get update
sudo apt-get install firefox

Anschließend muß das Selenium Server Standalone 2.53.1 JAR-Paket herruntergeladen und entpackt werden.

Jetzt die beiden Dateien
webdriver.xpi und webdriver_prefs.json
aus dem JAR-Paket unter
selenium-server-standalone-2.53.1.jar/org/openqa/selenium/firefox/
in das Selenium-Verzeichniss kopieren, welches bei mir unter:
/usr/local/share/perl/5.18.2/Selenium/Firefox
zu finden ist und die beiden vorhandenen Dateien überschreibt!

Perl Script starten und freuen, das es wieder funktioniert.

Tagged with:
preload preload preload