nach einem unsauberen Herunterfahren der RC100 V11 heute morgen funktioniert das Cloud Backup nicht mehr - es kann weder auf bestehende zugegriffen werden, noch neue Konfigurationen hochgeladen werden. Es erscheint ein AJAX Popup mit "ERROR : backup_store: curl_easy_perform() failed: Couldn't resolve host name".
-> Wo kann man denn den Cloud Backup Dienst/Server konfigurieren und was muss da rein?
Edit:
hier noch ein paar auszüge aus /var/log
boot.msg
--------
mtrr: your BIOS has configured an incorrect mask, fixing it.
mtrr: your BIOS has configured an incorrect mask, fixing it.
mtrr: your BIOS has configured an incorrect mask, fixing it.
mtrr: your BIOS has configured an incorrect mask, fixing it.
mtrr: your BIOS has configured an incorrect mask, fixing it.
mtrr: your BIOS has configured an incorrect mask, fixing it.
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock: 32/8 (20140214/tbfadt-603)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/8 (20140214/tbfadt-603)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/PmTimerBlock: 32/8 (20140214/tbfadt-603)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/8 (20140214/tbfadt-603)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aEventBlock: 8, using default 32 (20140214/tbfadt-684)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 8, using default 16 (20140214/tbfadt-684)
ACPI BIOS Warning (bug): Invalid length for FADT/PmTimerBlock: 8, using default 32 (20140214/tbfadt-684)
init.msg
--------
mount: none already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts [FAILED]
Cloud Backup funktioniert nicht mehr
Moderator: Securepoint
host v11.cloudbackup.securepoint.de
v11.cloudbackup.securepoint.de has address 62.201.160.21
-> ja kann sie. Daher ja meine erste Idee, dass der Eintrag für den Cloud-Server "beschädigt" ist und da müll drin steht -> deshalb die Frage wo ich das eintragen kann...
Wir sind übrigens noch auf der v11.5.0
v11.cloudbackup.securepoint.de has address 62.201.160.21
-> ja kann sie. Daher ja meine erste Idee, dass der Eintrag für den Cloud-Server "beschädigt" ist und da müll drin steht -> deshalb die Frage wo ich das eintragen kann...
Wir sind übrigens noch auf der v11.5.0
Sie können ja mal schauen, ob die DNS-Anfragen für den Backupserver überhaupt beantwortet werden. Melden Sie sich dazu mit dem root-User an der SSH-Konsole an und führen aus:
Wenn Sie dann in einer zweiten Konsole versuchen die verfügbaren Backups anzuzeigen (spcli system cloudbackup get) , sollten DNS-Anfragen für "v11.cloudbackup.securepoint.de" im tcpdump zu sehen sein. Da ist zum einen interessant, wo die hingehen und zum anderen, ob der fragliche Server sie beantwortet.
Code: Alles auswählen
# tcpdump -i any -nnp port 53
13:56:41.208597 IP 127.0.0.1.48737 > 127.0.0.1.53: 60239+ A? v11.cloudbackup.securepoint.de. (48)
13:56:41.209089 IP 127.0.0.1.48737 > 127.0.0.1.53: 11511+ AAAA? v11.cloudbackup.securepoint.de. (48)
13:56:41.209423 IP 127.0.0.1.46215 > 127.0.0.1.53: 60239+ A? v11.cloudbackup.securepoint.de. (48)
13:56:41.209641 IP 127.0.0.1.46215 > 127.0.0.1.53: 11511+ AAAA? v11.cloudbackup.securepoint.de. (48)
13:56:41.209915 IP 127.0.0.1.49255 > 127.0.0.1.53: 49841+ A? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210119 IP 127.0.0.1.49255 > 127.0.0.1.53: 23916+ AAAA? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210385 IP 127.0.0.1.38671 > 127.0.0.1.53: 49841+ A? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210576 IP 127.0.0.1.38671 > 127.0.0.1.53: 23916+ AAAA? v11.cloudbackup.securepoint.de.de. (51)
eine Antwort kann ich nicht finden. "host [host] 127.0.0.1" gibt auch zurück das kein Server erreichbar ist. In der Konfiguration ist auch unser Nameserver eingetragen und die Auflösung mittels "host [host]" funktioniert ja auch - warum will er dafür den localhost als Nameserver nehmen?
Edit: jetzt hab ich den Nameserver der UTM mal gestartet und Cloud geht - eigentlich soll die UTM das aber gar kein DNS machen sondern den eingetragenen Server nutzen (für alles)
13:56:41.209089 IP 127.0.0.1.48737 > 127.0.0.1.53: 11511+ AAAA? v11.cloudbackup.securepoint.de. (48)
13:56:41.209423 IP 127.0.0.1.46215 > 127.0.0.1.53: 60239+ A? v11.cloudbackup.securepoint.de. (48)
13:56:41.209641 IP 127.0.0.1.46215 > 127.0.0.1.53: 11511+ AAAA? v11.cloudbackup.securepoint.de. (48)
13:56:41.209915 IP 127.0.0.1.49255 > 127.0.0.1.53: 49841+ A? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210119 IP 127.0.0.1.49255 > 127.0.0.1.53: 23916+ AAAA? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210385 IP 127.0.0.1.38671 > 127.0.0.1.53: 49841+ A? v11.cloudbackup.securepoint.de.de. (51)
13:56:41.210576 IP 127.0.0.1.38671 > 127.0.0.1.53: 23916+ AAAA? v11.cloudbackup.securepoint.de.de. (51)
eine Antwort kann ich nicht finden. "host [host] 127.0.0.1" gibt auch zurück das kein Server erreichbar ist. In der Konfiguration ist auch unser Nameserver eingetragen und die Auflösung mittels "host [host]" funktioniert ja auch - warum will er dafür den localhost als Nameserver nehmen?
Edit: jetzt hab ich den Nameserver der UTM mal gestartet und Cloud geht - eigentlich soll die UTM das aber gar kein DNS machen sondern den eingetragenen Server nutzen (für alles)
In der /etc/resolv.conf steht als letzter Nameserver immer 127.0.0.1. Wenn alle anderen DNS-Server nicht geantwortet haben, wird dieser befragt. Warum der jetzt auch nicht geantwortet hat, kann man so jetzt nicht sagen. Vielleicht steht (stand) dazu was schlaues im Log.
root@********:/etc# cat resolv.conf
nameserver 192.168.181.21
nameserver 127.0.0.1
root@********:/etc# host v11.cloudbackup.securepoint.de 192.168.181.21
Using domain server:
Name: 192.168.181.21
Address: 192.168.181.21#53
Aliases:
v11.cloudbackup.securepoint.de has address 62.201.160.21
Der antwortet...
und:
root@********:/etc# curl -v v11.cloudbackup.securepoint.de
* About to connect() to v11.cloudbackup.securepoint.de port 80 (#0)
* Trying 62.201.160.21...
Edit: muss das so sein:
root@********:/etc# cat curl.conf
root@********:/etc#
Edit2: was wird fürs logging auf der UTM verwendet, kann kein syslogd finden....(spsyslogd steht für securepointsyslogd? -> nur die conf dafür bleibt mir verborgen...)
nameserver 192.168.181.21
nameserver 127.0.0.1
root@********:/etc# host v11.cloudbackup.securepoint.de 192.168.181.21
Using domain server:
Name: 192.168.181.21
Address: 192.168.181.21#53
Aliases:
v11.cloudbackup.securepoint.de has address 62.201.160.21
Der antwortet...
und:
root@********:/etc# curl -v v11.cloudbackup.securepoint.de
* About to connect() to v11.cloudbackup.securepoint.de port 80 (#0)
* Trying 62.201.160.21...
Edit: muss das so sein:
root@********:/etc# cat curl.conf
root@********:/etc#
Edit2: was wird fürs logging auf der UTM verwendet, kann kein syslogd finden....(spsyslogd steht für securepointsyslogd? -> nur die conf dafür bleibt mir verborgen...)
Der Backup-Server ist nur auf Port 443 erreichbar. Nehmen Sie zum Testen folgenden Befehl:
Der spsyslogd hat keine Konfigurationsdatei. Sie können nur einstellen, ob eine Logdatei gespeichert werden soll oder nicht:
Das sorgt dafür, dass durch 10 Logfiles mit jeweils 10 MB Größe rotiert wird. Die heißen dann /data/syslog/messages{.1,.2,...}
Code: Alles auswählen
# curl --cert /rootdisk/securepoint/license --cacert /etc/ssl/certs/sp-license-ca.pem https://v11.cloudbackup.securepoint.de/read
Code: Alles auswählen
# echo 1 > /data/syslog/file.enabled
# echo 10 > /data/syslog/file.rotate
# echo 10000000 > /data/syslog/file.maxsize
# sv restart spsyslogd
root@*********:~# curl --cert /rootdisk/securepoint/license --cacert /etc/ssl/certs/sp-license-ca.pem https://v11.cloudbackup.securepoint.de/read
{"success":true,"msg":"OK","data":{"num":5,"files":[{"file_id":"*","cfgName":null,"createdtime":1437641978},{"file_id":"*","cfgName":null,"createdtime":1437631314},{"file_id":"*","cfgName":null,"createdtime":1435235341},{"file_id":"*","cfgName":null,"createdtime":1435042212},{"file_id":"*","cfgName":null,"createdtime":1431324404}]}}root@******:~#
Das Message logfile durchzusehen wird etwas dauern....
glaub aber nicht das da etwas drin steht. Der TCPdump hat ja gezeigt das er gar nicht unseren Nameserver fragt, sondern gleich und ausschließlich 127.0.0.1 anfragt...
Edit: das ist ja das Log von der Weboberfläche (da hab ich natürlich schon reingeschaut als erstes)...schöner wäre natürlich ein syslogd mit curl.warn in der conf
Edit2: was ich oben zeigen wollte war das der Aufruf von curl mit v11.cloudbackup.securepoint.de erfolgreich auflöst, egal ob er auf 80 verbinden kann oder nicht, die IP bekommt er. Nur eben nicht wenn die Weboberfläche das auslöst, da fragt er den nameserver einafch nicht
{"success":true,"msg":"OK","data":{"num":5,"files":[{"file_id":"*","cfgName":null,"createdtime":1437641978},{"file_id":"*","cfgName":null,"createdtime":1437631314},{"file_id":"*","cfgName":null,"createdtime":1435235341},{"file_id":"*","cfgName":null,"createdtime":1435042212},{"file_id":"*","cfgName":null,"createdtime":1431324404}]}}root@******:~#
Das Message logfile durchzusehen wird etwas dauern....
glaub aber nicht das da etwas drin steht. Der TCPdump hat ja gezeigt das er gar nicht unseren Nameserver fragt, sondern gleich und ausschließlich 127.0.0.1 anfragt...
Edit: das ist ja das Log von der Weboberfläche (da hab ich natürlich schon reingeschaut als erstes)...schöner wäre natürlich ein syslogd mit curl.warn in der conf
Edit2: was ich oben zeigen wollte war das der Aufruf von curl mit v11.cloudbackup.securepoint.de erfolgreich auflöst, egal ob er auf 80 verbinden kann oder nicht, die IP bekommt er. Nur eben nicht wenn die Weboberfläche das auslöst, da fragt er den nameserver einafch nicht