20
Timeout bei HTTPS bzw. SSL (443), HTTP (80) geht einwandfrei
Hallo.
Hier läuft ein Debian (lenny) Server mit Apache2. Alles funktioniert einwandfrei ... bis auf
Verbindungen über HTTPS / SSL (Port 443) werden mit einem Timeout abgebrochen.
Nach dem Neustart des Servers heute morgen ging es für einen kurzen Moment.
DIe gleiche URL über HTTP (Port 80) aufgerufen kommt sofort und ohne ein Problem.
Was ist das ?
In den Error-Logs sind keine Einträge zu finden (die protokollieren sonst jeden Mist - sind also auf "fein" eingestellt).
Danke,
Snoopy
Hier läuft ein Debian (lenny) Server mit Apache2. Alles funktioniert einwandfrei ... bis auf
Verbindungen über HTTPS / SSL (Port 443) werden mit einem Timeout abgebrochen.
Nach dem Neustart des Servers heute morgen ging es für einen kurzen Moment.
DIe gleiche URL über HTTP (Port 80) aufgerufen kommt sofort und ohne ein Problem.
Was ist das ?
In den Error-Logs sind keine Einträge zu finden (die protokollieren sonst jeden Mist - sind also auf "fein" eingestellt).
Danke,
Snoopy
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 138428
Url: https://administrator.de/forum/timeout-bei-https-bzw-ssl-443-http-80-geht-einwandfrei-138428.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo Snoopy,
ist SSL überhaupt aktiviert? Wie sehen die VirtualHosts aus?
Ist ein Key erzeugt?
Grüße
André
ist SSL überhaupt aktiviert? Wie sehen die VirtualHosts aus?
Ist ein Key erzeugt?
Grüße
André
Hallo FrY,
ja. SSL ist aktiviert. Natürlich
Ein Key ist erzeugt. Mehrfach kontrolliert. Er ist auf den Domainnamen (sub.domain.de) abgestimmt.
VirtualHosts:
Die beiden SSL Datei sind am Pfad auch vorhanden.
Zugriff auf die Dateien möglich.
Ein "netstat -tap" liefert auch nur einen Port 443 (also kein Squid etc aktiv):
Nachtrag:
Lokal (https://192.168.0.200/) geht es. Der Router ist aber richtig eingerichtet und leitet alle 443 Anfragen wie auch 80 an die IP weiter.
Zudem hat es heute morgen für einen Moment gut funktioniert und am Router etc. wurde nicht verändert.
Das Einzige kann also dieser verd** Apache2 sein.
ja. SSL ist aktiviert. Natürlich
Ein Key ist erzeugt. Mehrfach kontrolliert. Er ist auf den Domainnamen (sub.domain.de) abgestimmt.
VirtualHosts:
<VirtualHost 192.168.0.200:443>
SuexecUserGroup "#1001" "#1002"
ServerName sub.domain.de
ServerAlias www.sub.domain.de webmail.sub.domain.de admin.sub.domain.de
DocumentRoot /home/domains/sub.domain.de/public_html
ErrorLog /var/log/virtualmin/sub.domain.de_error_log
CustomLog /var/log/virtualmin/sub.domain.de_access_log combined
ScriptAlias /cgi-bin/ /home/domains/sub.domain.de/cgi-bin/
ScriptAlias /awstats /home/domains/sub.domain.de/cgi-bin
DirectoryIndex index.html index.htm index.php index.php4 index.php5
<Directory /home/domains/sub.domain.de/public_html>
Options -Indexes +IncludesNOEXEC +FollowSymLinks
allow from all
AllowOverride All
</Directory>
<Directory /home/domains/sub.domain.de/cgi-bin>
allow from all
</Directory>
RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.sub.domain.de
RewriteRule ^(.*) https://sub.domain.de:20220/ [R]
RewriteCond %{HTTP_HOST} =admin.sub.domain.de
RewriteRule ^(.*) https://sub.domain.de:2222/ [R]
<Files awstats.pl>
AuthName "sub.domain.de statistics"
AuthType Basic
AuthUserFile /home/domains/sub.domain.de/.awstats-htpasswd
require valid-user
</Files>
SSLEngine on
SSLCertificateFile /home/domains/sub.domain.de/ssl.cert
SSLCertificateKeyFile /home/domains/sub.domain.de/ssl.key
</VirtualHost>Die beiden SSL Datei sind am Pfad auch vorhanden.
Zugriff auf die Dateien möglich.
Ein "netstat -tap" liefert auch nur einen Port 443 (also kein Squid etc aktiv):
tcp 0 0 192.168.0.100:www *:* LISTEN 10807/apache2
tcp 0 0 192.168.0.100:https *:* LISTEN 10807/apache2Nachtrag:
Lokal (https://192.168.0.200/) geht es. Der Router ist aber richtig eingerichtet und leitet alle 443 Anfragen wie auch 80 an die IP weiter.
Zudem hat es heute morgen für einen Moment gut funktioniert und am Router etc. wurde nicht verändert.
Das Einzige kann also dieser verd** Apache2 sein.
Hallo nochmal!
Würde eine Fehlkonfiguration der Firewall in Frage kommen?
Mir fällt oben auf, dass du ServerAliase's gesetzt hast. Diese gibt es bei SSL jedoch nicht, hier müsstest du einen neuen VirtualHost anlegen.
Dieser wird dir aber, da es sich sicherlich um die gleiche IP handelt, ein warning auswerfen (macht er bei mir auch), aber es wird weiterhin funktionieren.
Grüße
André
Würde eine Fehlkonfiguration der Firewall in Frage kommen?
Mir fällt oben auf, dass du ServerAliase's gesetzt hast. Diese gibt es bei SSL jedoch nicht, hier müsstest du einen neuen VirtualHost anlegen.
Dieser wird dir aber, da es sich sicherlich um die gleiche IP handelt, ein warning auswerfen (macht er bei mir auch), aber es wird weiterhin funktionieren.
Grüße
André
Hallo André,
danke für Deine Unterstützung !
In den Logs (ich habe den LogLevel mal auf "debug" gesetzt) finde ich auch keine nützlichen Infos auf Probleme.
Die Firewall ist lt. VirtualMin derzeit aus - die Fehlerquelle wollte ich ausschalten.
Richtig - es ist alles eine IP.
Gruß,
Snoopy
danke für Deine Unterstützung !
In den Logs (ich habe den LogLevel mal auf "debug" gesetzt) finde ich auch keine nützlichen Infos auf Probleme.
Die Firewall ist lt. VirtualMin derzeit aus - die Fehlerquelle wollte ich ausschalten.
Richtig - es ist alles eine IP.
Gruß,
Snoopy
Hallo Snoopy,
was mich wundert ist eigentlich, dass es intern funktioniert, aber von außen nicht.
Kann es ein Routing-Problem sein?
Gruß
André
was mich wundert ist eigentlich, dass es intern funktioniert, aber von außen nicht.
Kann es ein Routing-Problem sein?
Gruß
André
Hallo.
Genau deshalb bekomme ich die grauen Haare. Der Server an-sich versteht mich ja - von außen komme ich auch durch und nur dann klemmt da was :o(
Die Routingtabelle ist unspektakulär:
Die 201 und 202 sind zwei virtuelle Maschinen, die aber seit Wochen unverändert und völlig problemlos laufen.
Mir gehen hier die Ideen aus ...
Genau deshalb bekomme ich die grauen Haare. Der Server an-sich versteht mich ja - von außen komme ich auch durch und nur dann klemmt da was :o(
Die Routingtabelle ist unspektakulär:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.0.202 0.0.0.0 255.255.255.255 UH 0 0 0 venet0
192.168.0.201 0.0.0.0 255.255.255.255 UH 0 0 0 venet0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0Die 201 und 202 sind zwei virtuelle Maschinen, die aber seit Wochen unverändert und völlig problemlos laufen.
Mir gehen hier die Ideen aus ...
Es wird immer merkwürdiger ...
Nun habe ich weder in der access_log noch in der error_log eine Reaktion, wenn ich die Seite aufrufe (von außen). Von Innen arbeitet alles wie ich es erwarte.
Die Firewall / Router (NAT) habe ich jetzt schon das x-te Mal geprüft.
Der Router (im Log) erkennt den Zugriff auf Port 443 und leitet in auf die interne Server IP weiter. Soweit ja auch gut und richtig.
Wie kann ich denn feststellen, was mein Server mit dieser speziellen Anfrage macht ?
Alle anderen Domains (auf Port 80) laufen parallel fehlerfrei.
Nun habe ich weder in der access_log noch in der error_log eine Reaktion, wenn ich die Seite aufrufe (von außen). Von Innen arbeitet alles wie ich es erwarte.
Die Firewall / Router (NAT) habe ich jetzt schon das x-te Mal geprüft.
Der Router (im Log) erkennt den Zugriff auf Port 443 und leitet in auf die interne Server IP weiter. Soweit ja auch gut und richtig.
Wie kann ich denn feststellen, was mein Server mit dieser speziellen Anfrage macht ?
Alle anderen Domains (auf Port 80) laufen parallel fehlerfrei.
Das sieht mir schon arg danach aus, dass Port 443 nicht "erlaubt" ist. Sehr merkwürdig.
"Listen 443" ist sicherlich eingetragen, sonst würds von innen nicht gehen.
Haste mal einem anderen Inet-Anschluss versucht?
Zum Routing: Sieht ja eigentlich gut aus. Wichtig wäre nur, dass der 192.168.0.1 auch wirklich was annimmt. Vielleicht routet der nicht richtig zum server xy durch...
"Listen 443" ist sicherlich eingetragen, sonst würds von innen nicht gehen.
Haste mal einem anderen Inet-Anschluss versucht?
Zum Routing: Sieht ja eigentlich gut aus. Wichtig wäre nur, dass der 192.168.0.1 auch wirklich was annimmt. Vielleicht routet der nicht richtig zum server xy durch...
Hallo FrY,
stimmt. Listen 443 ist eingetragen. Aktuell habe ich es mal auf beide IPs gemacht:
Listen 192.168.0.200:443 und
Listen [FesteIP]:443
Von einem anderen PC (steht extern) habe ich es auch per VNC getestet.
Gleiches Ergebnis / Problem.
Wie kann ich denn 'raus bekommen, ob mein Server überhaupt etwas auf 443 empfängt ?
In irgendeinem Log muss doch etwas zu finden sein !?
Als ich mich intern auf 443 verbunden habe, spuckte das Log seitenweise Infos aus.
Also habe ich mich sofort extern verbunden... völlige Stille in den Logs (s.o.)
Was mich am meisten wurmt, ist: Heute morgen ging es einen Moment.
Seitdem habe ich nichts am Router verändert. Das bestätigt mich in meinen Tests mit dem Router.
stimmt. Listen 443 ist eingetragen. Aktuell habe ich es mal auf beide IPs gemacht:
Listen 192.168.0.200:443 und
Listen [FesteIP]:443
Von einem anderen PC (steht extern) habe ich es auch per VNC getestet.
Gleiches Ergebnis / Problem.
Wie kann ich denn 'raus bekommen, ob mein Server überhaupt etwas auf 443 empfängt ?
In irgendeinem Log muss doch etwas zu finden sein !?
Als ich mich intern auf 443 verbunden habe, spuckte das Log seitenweise Infos aus.
Also habe ich mich sofort extern verbunden... völlige Stille in den Logs (s.o.)
Was mich am meisten wurmt, ist: Heute morgen ging es einen Moment.
Seitdem habe ich nichts am Router verändert. Das bestätigt mich in meinen Tests mit dem Router.
Schau mal in
/var/log/apache2/
da gibts ja die access. und ne error.log. Zusätzlich ist da meist eine für die Vhosts (bei mir z. B. other_vhosts_access.log). Dort stehen auch die Anfragen mit Port.
Wobei du oben ja andere Logs definiert hast. Ist die Frage, ob man die mal kurz auskommentiert und schaut, was der Apache so anlegt und da mal nachschaut.
Vielleicht macht das ja einen Unterschied.
Nimm mal nur
Listen 443
Ohne IP davor. Vielleicht kann der interne Router nichts mit der öffentlichen IP in diesem Falle anfangen bzw. der Apache!?
/var/log/apache2/
da gibts ja die access. und ne error.log. Zusätzlich ist da meist eine für die Vhosts (bei mir z. B. other_vhosts_access.log). Dort stehen auch die Anfragen mit Port.
Wobei du oben ja andere Logs definiert hast. Ist die Frage, ob man die mal kurz auskommentiert und schaut, was der Apache so anlegt und da mal nachschaut.
Vielleicht macht das ja einen Unterschied.
Nimm mal nur
Listen 443
Ohne IP davor. Vielleicht kann der interne Router nichts mit der öffentlichen IP in diesem Falle anfangen bzw. der Apache!?
Hallo.
Vielleicht sehe ich den Wald ja vor Bäumen nicht.
Nun habe ich das SSL Log geleert und den Apache2 restartet.
Error Log:
OK - es ist mein eigenes Zertifikat. Aber das sollte hier nur Hinweise ausgeben und nicht zum o.a. Problem werden (?)
Das ebenfalls geleerte access_log ist und bleibt leer. Im error_log erscheint nur die o.a. Meldung, dann ist auch (trotz weiterer Zugriffsversuche) Ruhe.
Vielleicht sehe ich den Wald ja vor Bäumen nicht.
Nun habe ich das SSL Log geleert und den Apache2 restartet.
Error Log:
[Wed Mar 17 15:12:55 2010] [info] Loading certificate & private key of SSL-aware server
[Wed Mar 17 15:12:55 2010] [debug] ssl_engine_pphrase.c(469): unencrypted RSA private key - pass phrase not required
[Wed Mar 17 15:12:56 2010] [info] Configuring server for SSL protocol
[Wed Mar 17 15:12:56 2010] [debug] ssl_engine_init.c(384): Creating new SSL context (protocols: SSLv3, TLSv1)
[Wed Mar 17 15:12:56 2010] [debug] ssl_engine_init.c(577): Configuring permitted SSL ciphers [HIGH:MEDIUM:!ADH]
[Wed Mar 17 15:12:56 2010] [debug] ssl_engine_init.c(705): Configuring RSA server certificate
[Wed Mar 17 15:12:56 2010] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed Mar 17 15:12:56 2010] [warn] RSA server certificate wildcard CommonName (CN) `*.domain.de' does NOT match server name!?
[Wed Mar 17 15:12:56 2010] [debug] ssl_engine_init.c(744): Configuring RSA server private keyOK - es ist mein eigenes Zertifikat. Aber das sollte hier nur Hinweise ausgeben und nicht zum o.a. Problem werden (?)
Das ebenfalls geleerte access_log ist und bleibt leer. Im error_log erscheint nur die o.a. Meldung, dann ist auch (trotz weiterer Zugriffsversuche) Ruhe.
Und wenn du intern zugreifst, siehste dann Quell-IP und Port?
Nach internem Zugriff:
Die error_log
Und die access_log bleibt leer :o(
Das mag aber daran liegen, dass ich bei der Sicherheitsnachfrage des Browsers schon aufhöre. Die reicht mir ja auch - denn damit hatte ich schon Kontakt zum Server.
Wenn die Frage auch von extern kommen würde, dann wäre das Problem ja wahrscheinlich behoben.
Die error_log
[Wed Mar 17 15:30:15 2010] [info] [client 192.168.0.94] Connection to child 2 established (server domain.de:443)
[Wed Mar 17 15:30:15 2010] [info] Seeding PRNG with 656 bytes of entropy
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1738): OpenSSL: Handshake: start
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: before/accept initialization
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1832): OpenSSL: read 11/11 bytes from BIO#17e9920 [mem: 17f1010] (BIO dump follows)
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1765): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1804): | 0000: 16 03 01 00 89 01 00 00-85 03 01 ........... |
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1810): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1832): OpenSSL: read 131/131 bytes from BIO#17e9920 [mem: 17f101b] (BIO dump follows)
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1765): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1804): | 0000: 4b a0 e7 5e c9 b5 18 4d-c3 49 c0 f1 e6 c4 ec cf K..^...M.I...... |
[...]
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1804): | 0080: 23 # |
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1808): | 0131 - <SPACES/NULS>
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1810): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 read client hello A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write server hello A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write certificate A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1149): [client 192.168.0.94] handing out temporary 1024 bit DH key
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write key exchange A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write server done A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 flush data
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1832): OpenSSL: read 5/5 bytes from BIO#17e9920 [mem: 17f1010] (BIO dump follows)
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1765): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1804): | 0000: 15 03 01 00 02 ..... |
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1810): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1832): OpenSSL: read 2/2 bytes from BIO#17e9920 [mem: 17f1015] (BIO dump follows)
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1765): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1804): | 0000: 02 30 .0 |
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_io.c(1810): +-------------------------------------------------------------------------+
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1751): OpenSSL: Read: SSLv3 read client certificate A
[Wed Mar 17 15:30:15 2010] [debug] ssl_engine_kernel.c(1770): OpenSSL: Exit: failed in SSLv3 read client certificate A
[Wed Mar 17 15:30:15 2010] [info] [client 192.168.0.94] SSL library error 1 in handshake (server domain.de:443)
[Wed Mar 17 15:30:15 2010] [info] SSL Library Error: 336151576 error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
[Wed Mar 17 15:30:15 2010] [info] [client 192.168.0.94] Connection closed to child 2 with abortive shutdown (server domain.de:443)Und die access_log bleibt leer :o(
Das mag aber daran liegen, dass ich bei der Sicherheitsnachfrage des Browsers schon aufhöre. Die reicht mir ja auch - denn damit hatte ich schon Kontakt zum Server.
Wenn die Frage auch von extern kommen würde, dann wäre das Problem ja wahrscheinlich behoben.
Gibts da noch andere Files?
Ansonsten irritiert mich:
[Wed Mar 17 15:30:15 2010] [info] SSL Library Error: 336151576 error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Ansonsten irritiert mich:
[Wed Mar 17 15:30:15 2010] [info] SSL Library Error: 336151576 error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Ich habe hier gerade einen mächtigen Ärger mit Hansenet / Alice !!
Wenn ich einen Portscan auf meine eigene (feste) IP bei denen mache, dann komme ich mit allen Ports durch. Bis auf 443 !!
Natürlich bei entsprechend freigegebenem Router.
Sperre ich dort alle anderen Ports wieder ist der Portscan entsprechend negativ - aber auch weiterhin bei Port 443.
Das darf doch nicht wahr sein :o(
Nun haben die Techniker dort ein Störungsticket aufgenommen.
Bin mal gespannt, wann das behoben sein wird.
Hintergrund:
Ich hatte mir die Zeit genommen und ein XAMPP auf einem XP Rechner aufgesetzt. Dort dann eine SSL Seite aktiviert.
Die lokalen Tests waren (wie beim Server auch) gut. Dann habe ich im Router den Port 443 auf den XP PC verbogen und von extern getestet.
Dabei fiel auch der Versuch durch und ich machte mehrere Portscans ...
Was mich dabei besonders ärgert ist, dass es heute morgen definitiv ging und keine Probleme gab.
Also scheint dort irgendwie der Wurm beim Provider zu stecken.
Wenn ich einen Portscan auf meine eigene (feste) IP bei denen mache, dann komme ich mit allen Ports durch. Bis auf 443 !!
Natürlich bei entsprechend freigegebenem Router.
Sperre ich dort alle anderen Ports wieder ist der Portscan entsprechend negativ - aber auch weiterhin bei Port 443.
Das darf doch nicht wahr sein :o(
Nun haben die Techniker dort ein Störungsticket aufgenommen.
Bin mal gespannt, wann das behoben sein wird.
Hintergrund:
Ich hatte mir die Zeit genommen und ein XAMPP auf einem XP Rechner aufgesetzt. Dort dann eine SSL Seite aktiviert.
Die lokalen Tests waren (wie beim Server auch) gut. Dann habe ich im Router den Port 443 auf den XP PC verbogen und von extern getestet.
Dabei fiel auch der Versuch durch und ich machte mehrere Portscans ...
Was mich dabei besonders ärgert ist, dass es heute morgen definitiv ging und keine Probleme gab.
Also scheint dort irgendwie der Wurm beim Provider zu stecken.
Zuerst nochmals herzlichen Dank für Eure Unterstützung !!
Zur Info:
Alice hatte "versehentlich" bei unserer festen IP einen Fehler. Nachdem der behoben war, kamen Einträge im Router Log an (er erhielt also endlich Anfragen).
Aber auch nun wollte er diese partout nicht an den Server weitergeben.
Also hab ich das Mistding (sorry für meine Ausdrucksweise) auf den Auslieferungsstand zurückgesetzt.
Dann das direkt vorher gemachte Backup der Einstellungen wieder eingespielt - et voila: Es geht.
Bitte fragt mich nicht, was sich da verkantet hatte.
Zur Info:
Alice hatte "versehentlich" bei unserer festen IP einen Fehler. Nachdem der behoben war, kamen Einträge im Router Log an (er erhielt also endlich Anfragen).
Aber auch nun wollte er diese partout nicht an den Server weitergeben.
Also hab ich das Mistding (sorry für meine Ausdrucksweise) auf den Auslieferungsstand zurückgesetzt.
Dann das direkt vorher gemachte Backup der Einstellungen wieder eingespielt - et voila: Es geht.
Bitte fragt mich nicht, was sich da verkantet hatte.
Solche Sachen kenn ich aus unserer Firma.. manchmal könnten hier 100 Server nebeneinander installiert werden und jeder hat nen anderen, unbekannten Fehler
Beruhigend :o)
Ich kann doch nicht bei jedem Problem(chen) einen Full-Reset aller Geräte machen.
Die Kür in der Firma ist die Frage hinterher:
"Und für diesen kleinen Fehler haben Sie 6 Stunden gebraucht ?? Das hätte ich in 2 Minuten gemacht !!"
... jo, ist klar
(Meist von Kollegen, die einen Switch nicht vom Server unterscheiden können)
Ich kann doch nicht bei jedem Problem(chen) einen Full-Reset aller Geräte machen.
Die Kür in der Firma ist die Frage hinterher:
"Und für diesen kleinen Fehler haben Sie 6 Stunden gebraucht ?? Das hätte ich in 2 Minuten gemacht !!"
... jo, ist klar
(Meist von Kollegen, die einen Switch nicht vom Server unterscheiden können)
Ach das kenn ich. Jeder Dienstleister, der hier was installiert sagt zu 90%iger Wahrscheinlichkeit den Satz:
"Also das hatte ich auch noch nicht."
Ist aber merkwürdig... wird sicherlich anders zu lösen sein, aber bis man das raushat, ist ein Fullreset wahrscheinlich doch schneller
"Also das hatte ich auch noch nicht."
Ist aber merkwürdig... wird sicherlich anders zu lösen sein, aber bis man das raushat, ist ein Fullreset wahrscheinlich doch schneller
Aber auf alle Fälle vielen Dank für die super Hilfe !!
Es immer schön, wenn man bei solchen Problemen fachkundige Unterstützung hat, die nicht sofort mit "Das hatte ich auch noch nie" das Handtuch werfen.
Bei Problemen gerne einfach melden.
Ich versuche mich dann zu revanchieren.
