Virtualization Station und QuTScloud

Per Default wird der VM aus dem Market Place zwei NICs zugeordnet. Je einmal Bridge und User Mode.
Das hat bei mir bis gestern auch funktioniert als ich die User Mode weggenommen habe. Dazwischen lagen mehrere Reboots des Host als auch der VM. Volumen war ok, Lizenz gültig. Heute eingeschaltet und die Lizenz ist weg. Leider kann ich aus dem Market Place auch keine weitere VM ans laufen kriegen. Für mich ist das einfach nur kaputter Schrott.
 
Du hast das NAS doch nicht offen im Internet. Also ist das Umbiegen auf andere Ports auch nicht wirklich Sicherheitsrelevant. Allerdings soll QuTSCloud - zumindest dem Namen nach - ja wohl im Internet sein. Hmm, schon eigenartig.
.
Das ist genau das, worüber ich mich auch gewundert habe.
Nein, natürlich sind meine NAS nicht im Internet ;) , aber ich habe auf allen NAS nicht mehr die default Ports, rein aus Neugier.
In all den Jahren war das auch kein Problem, aber das ausgerechnet die cloud Anwendung...🤬

Ich habe direkt mal eine Mail da an security@qnap.com gesendet, denn ich halte das für ein potentielles Sicherheitsrisiko.
Bin auf die Antwort gespannt.

Gruss
 
Was steht bei Euch in den QLICENSE LOGs?

/etc/config/qlicense
/etc/logs/qlicense
/tmp/.qlicense
/tmp/.qlicense_daemon.log

Bei mir steht nur im qlicense_daemon.log folgendes:
Code:
[1;30m04/01/22 18:32:42: qlicense_daemon_conf.c: 32: qlicense_daemon_display_running_conf():qlicense Daemon starts running with ...[0m
[1;30m04/01/22 18:32:42: qlicense_daemon_conf.c: 35: qlicense_daemon_display_running_conf():Debug level = 3[0m
[1;30m04/01/22 18:32:42: qlicense_daemon_conf.c: 39: qlicense_daemon_display_running_conf():Debug on = standard output[0m
[1;32m04/01/22 18:32:43: qlicense_daemon_core.c: 229: qlicense_check_timer_cb():timer callback: 1648830763[0m
[1;32m04/01/22 18:32:43: qlicense_daemon_core.c: 129: qlicense_proc_event():check qlicense init[0m
[1;32m04/01/22 18:32:43: qlicense_daemon_core.c: 161: qlicense_proc_event():do qlicense_tool floating_init only when first time start[0m
[1;32m04/01/22 18:32:43: qlicense_daemon_core.c: 164: qlicense_proc_event():do qlicense_tool local_recover only when first time start[0m
[1;32m04/01/22 18:32:43: qlicense_daemon_core.c: 167: qlicense_proc_event():do qlicense_tool local_cleanup only when first time start[0m
[1;30m04/01/22 18:32:43: qlicense_daemon_core.c: 174: qlicense_proc_event():check qlicense after 3600.000000 seconds[0m

Auch im Kernel.log mal nachgesehen? Auf die Schnelle sehe ich bei mir hier nur dies:
Code:
2022-04-01 18:37:50 +02:00 <4> [  266.201679] ---- qlicense_cpu_count=0 (licensed)

Sollte hingegen so etwas stehen:
Code:
2022-03-26 11:09:53 +01:00 <4> [  992.788708] ---- wait qlicense, retry=56
2022-03-26 11:10:05 +01:00 <4> [ 1003.883583] ---- wait qlicense, retry=57
2022-03-26 11:10:17 +01:00 <4> [ 1015.990920] ---- wait qlicense, retry=58
2022-03-26 11:10:29 +01:00 <4> [ 1028.096010] ---- wait qlicense, retry=59
2022-03-26 11:10:41 +01:00 <4> [ 1040.208108] ---- wait qlicense, retry=60
dürfte wohl wieder ein Internetproblem in irgend einer Form vorliegen.

>> Edit <<
Dieser Teil ist vor allem spannend:
Code:
check qlicense after 3600.000000 seconds
 
Ich schau auch später nach, bin unterwegs. Gab übrigens gestern wieder ein Update der VS.

Gruss
 
Die /tmp/qlicense_daemon.log sieht bei mir ziemlich ähnlich aus ;) :

Code:
04/02/22 12:54:34: qlicense_daemon_conf.c: 32: qlicense_daemon_display_running_conf():qlicense Daemon starts running with ...
04/02/22 12:54:34: qlicense_daemon_conf.c: 35: qlicense_daemon_display_running_conf():Debug level = 3
04/02/22 12:54:34: qlicense_daemon_conf.c: 39: qlicense_daemon_display_running_conf():Debug on = standard output
04/02/22 12:54:35: qlicense_daemon_core.c: 229: qlicense_check_timer_cb():timer callback: 1648896875
04/02/22 12:54:35: qlicense_daemon_core.c: 129: qlicense_proc_event():check qlicense init
04/02/22 12:54:35: qlicense_daemon_core.c: 161: qlicense_proc_event():do qlicense_tool floating_init only when first time start
04/02/22 12:54:35: qlicense_daemon_core.c: 164: qlicense_proc_event():do qlicense_tool local_recover only when first time start
04/02/22 12:54:35: qlicense_daemon_core.c: 167: qlicense_proc_event():do qlicense_tool local_cleanup only when first time start
04/02/22 12:54:36: qlicense_daemon_core.c: 174: qlicense_proc_event():check qlicense after 3600.000000 seconds
04/02/22 13:21:10: qlicense_daemon_conf.c: 32: qlicense_daemon_display_running_conf():qlicense Daemon starts running with ...
04/02/22 13:21:10: qlicense_daemon_conf.c: 35: qlicense_daemon_display_running_conf():Debug level = 3
04/02/22 13:21:10: qlicense_daemon_conf.c: 39: qlicense_daemon_display_running_conf():Debug on = standard output
04/02/22 13:21:11: qlicense_daemon_core.c: 229: qlicense_check_timer_cb():timer callback: 1648898471
04/02/22 13:21:11: qlicense_daemon_core.c: 129: qlicense_proc_event():check qlicense init
04/02/22 13:21:11: qlicense_daemon_core.c: 161: qlicense_proc_event():do qlicense_tool floating_init only when first time start
04/02/22 13:21:11: qlicense_daemon_core.c: 164: qlicense_proc_event():do qlicense_tool local_recover only when first time start
04/02/22 13:21:12: qlicense_daemon_core.c: 167: qlicense_proc_event():do qlicense_tool local_cleanup only when first time start
04/02/22 13:21:12: qlicense_daemon_core.c: 174: qlicense_proc_event():check qlicense after 3600.000000 seconds

Ich habe der VM den Zugriff ins Internet untersagt, mal schauen, was beim nächsten Lizenzcheck passiert. :LOL:

Gruss
 
Habe das TS-473A inzwischen auf QTS 5.0.0.1986 und VS 3.6.21 aktualisiert. Scheint bei mir immer noch alles ohne Probleme zu laufen.
 
Bei mir auch. Hatte dem QuTScloud wie gesagt mal das Gateway weg genommen. Auch nach deutlich über den 3600 Sekunden (1h) lief das cloud image noch.
Also mutig gebootet: VM kam ohne Murren hoch.

Wie auch immer dieser Lizenzcheck abläuft, die VM funktioniert offenbar trotzdem.

Gruss
 
Das spricht ja schon wieder gegen alle Erkenntnisse die wir zuletzt gewonnen hatten :cry:
Die Tatsache dass der Support bei mir nicht einmal hinterfragt hatte, ob die VM denn überhaupt Internetzugriff hat, spricht auch dafür, dass es nicht erforderlich sein kann oder sein sollte... Die Praxis sah bei mir aber anders aus.

Hat das entfernen des Gateways denn auch wirklich etwas genutzt? Die VM hätte js wenigstens meckern müssen, dass auch Updates nicht abgerufen werden können und der NCSI check fehlschlägt...
 
Ja, das hat sie auch. Als Gateway hatte ich die IP der VM selbst eingegeben, damit konnte sie defintiv nicht raus in die weite Welt.
DNS war auch die VM selbst. Von der Konsole aus war auch kein Ping nach draussen möglich.

Gruss
 
Heute die QNAP und VM angeschaltet. Bleibt dabei. Kein Key und das Volumen ist auch wieder RO.
 
Das System wurde letzte Woche auf Werkseinstellung zurückgesetzt.
Weiß nicht ob ich schon erwähnt habe, aber QNAP ist einfach ....
Und von dem Support erwarte ich auch nichts.
 
Hab dem Support eine Rückmeldung gegeben.

Sehr geehrter Herr xxx,


ich habe zwischenzeitlich das NAS auf QTS 5.0.0.1932 aktualisiert und einen Werksreset durchgeführt.
Anschließend die Virtualization Station installiert sowie QuTScloud c5.0.1 aus dem Market Place installiert. Hat augenscheinlich funktioniert. Das Volumen war in Ordnung, Key gültig. Aber nach einem Neustart war die Lizenz ungültig, das System dadurch unbrauchbar und das Volumen Read-Only. Ich finde die Qualität welche QNAP in letzter Zeit abliefert erschreckend. Es gibt wenig bis nichts was auf Anhieb funktioniert. Der User übernimmt unfreiwillig immer mehr Aufgaben eines Betatesters.


Mit freundlichen Grüßen


xxx

Die nächte Antwort wird definitv nicht mehr so wohlwollend formuliert sein. Ich hab langsam die Schnauze gestrichen voll.
 
Nein, mit der vorherigen Version 1919 war die Lizenz gültig aber das Volumen RO. Zumindest bei mir nach jedem Reboot.
 

Letzte Anleitungen

Statistik des Forums

Themen
5.885
Beiträge
57.519
Mitglieder
5.823
Neuestes Mitglied
HanzDampf
Zurück
Oben