@MarkusSachs: Es geht generell gar nicht, oder nur manchmal?
Hallo ja bei bestimmten Kollegen geht es generell nicht.
Habe bist jetzt vermutet das es bei denen war die eine Beta Version drauf hatten
Hallo @jlorenz,
genau, das Update wird immer wieder angeboten, aber nicht heruntergeladen. Ich habe das Verzeichnis pascom Client mal beobachtet, nachdem ich auf Neustart geklickt habe:
- doupdate Datei wird gelöscht
- pascom-client-setup-7.17.01.R.exe ist kurz mit 0 Byte zu sehen
- doupdate Datei wird angelegt
@HExSM: Hmm. Magst du mitte mal die Serverseitigen XMPP-Logs überprüfen - das sieht so aus als würde der Transfer abbrechen (Und der Client dann falsch reagieren und trotzdem behaupten es gäbe ein Update).
@MarkusSachs: Es sollte ohne weiteres möglich sein 17.01.DXX Version auf eine 17.01.R Version zu aktualisieren (vorrausgesetzt natürlich der Server ist auch aktuell).
- Sind alle Clientversionen hier betroffen?
- Welche Betriebssysteme setzen deine Kollegen ein?
- Gibt es sonst noch irgendwelche Konfigurationunterschiede zwischen “geht” und “geht nicht”?`
Grüße,
Jan
@jlorenz ja du hast recht, da scheint es Probleme zu geben. Anscheinend kann die pascom-client-setup-7.17.01.R.exe nicht gefunden werden.
2018.01.17 09:27:08 INFO [TaskEngine-pool-388]: net.pascom.ahab.server.xmppuser.XmppUserManager - Request available client updates
2018.01.17 09:27:09 INFO [TaskEngine-pool-388]: net.pascom.ahab.server.xmppuser.XmppUserManager - Push update event to desktop client [user@pascom/gVPw] for os [windows] target version [7.17.01.R]
2018.01.17 09:27:10 INFO [TaskEngine-pool-388]: net.pascom.ahab.server.FileTransferService - Streaming pascom-client-setup-7.17.01.R.exe (windows-7.17.01.R@update, 25061944 bytes) to user@pascom/gVPw
2018.01.17 09:27:17 ERROR [TaskEngine-pool-388]: net.pascom.ahab.server.FileTransferService - item-not-found(404)
@jlorenz also anbei die Antworten
- habe alle Windows 10 Build 1709
- Alles Pascom Client Versionen
- ich habe keine Unterschiede gefunden auf den PCs
Ich kann ja beim nächsten Update mal darauf schauen ob es vieliecht das gleich Problem ist wie bei @HExSM
Guten Morgen @jlorenz,
ich habe gestern das Update auf Version 17.02 durchgeführt und leider werden die Updates noch immer nicht übertragen.
Server Log:
2018.01.25 09:09:12 INFO [TaskEngine-pool-97]: net.pascom.ahab.server.xmppuser.XmppUserManager - Push update event to desktop client [user@pascom/CSRv] for os [windows] target version [7.17.02.R]
2018.01.25 09:09:13 INFO [TaskEngine-pool-97]: net.pascom.ahab.server.FileTransferService - Streaming pascom-client-setup-7.17.02.R.exe (windows-7.17.02.R@update, 25061432 bytes) to user@pascom/CSRv
2018.01.25 09:09:20 ERROR [TaskEngine-pool-97]: net.pascom.ahab.server.FileTransferService - item-not-found(404)
Client Log:
[2018-01-24 17:54:26.123] [Debug] [service.FileTransferService] unknown:0 - onFileReceived , file “pascom-client-setup-7.17.02.R.exe” , size: 25061432 , jid: “mdcmd@pascom/agent”
[2018-01-24 17:54:26.124] [Debug] [service.FileTransferService] unknown:0 - onJobStarted
[2018-01-24 17:54:33.209] [Warning] [service.FileTransferService] unknown:0 - Something went wrong with file transfering error is : 4
[2018-01-24 17:54:33.209] [Debug] [service.FileTransferService] unknown:0 - onJobFinished
Mit freundlichen Grüßen
Stefan
Hallo @HExSM:
Aus einem verdacht heraus. Welche Berechtigung haben denn die Setup Files auf dem Server?
Befehl hierzu: ls -la /var/www/mobydickcmd/provisioning/client
Alternativ kannst du nochmal versuchen, den XMPP Server neu zu starten…
Grüße,
Jan
Hallo @jlorenz,
Die Berechtigung sieht für mich korrekt aus.
-rw-r–r-- 1 www-data nogroup 25061432 Jan 22 10:32 pascom-client-setup-7.17.02.R.exe
Den XMPP-Server habe ich neu gestartet, aber das hat nichts gebracht.
Mit freundlichen Grüßen
Stefan
Hallo @jlorenz,
bei mir wird das update ebenfalls nicht korrekt geladen. Sowohl für Windows wie auch für MacOS.
Liebe Grüße
Maik
Nachtrag:
Im Logfile vom Webserver sieht mann, das der XMPP Daemon die Datei korrekt von localhost lädt. Das Problem liegt also im/am XMPP Daemon.
Grüße
Maik
Hallo @maik, @HExSM, @MarkusSachs,
Wie sind bei euch die beiden folgenden Systemeinstellungen konfiguriert?
sys.xmpp.properties.xmpp.ibb und sys.xmpp.externalip
Wir konnten das Verhalten bei uns nachstellen wenn ibb auf “false” (standard bei einer classic) steht und bei externalip eine IP konfiguriert ist. Ist da bei euch zufällig auch so? (Wenn ihr die Werte ändert, bitte hinterher Anwenden > Xmpp Server neustarten ausführen.
Grüße,
Jan
Hallo @jlorenz,
bei mir ist sys.xmpp.properties.xmpp.ibb auf false und auch unter sys.xmpp.externalip ist zwecks MobileHub auch ein Host eingetragen. Wenn ich sys.xmpp.properties.xmpp.ibb auf true setze funktioniert das Update vom Client. Die neue Installationsdatei wird zwar nur mit ~500KB/s vom Server geladen, aber damit kann man leben.
Vielen Dank 
Mit freundlichen Grüßen
Stefan
Hallo zusammen,
unter sys.xmpp.externalip habe ich unseren externen DNS Namen eingetragen. sys.xmpp.prperties.xmpp.ibb steht bei mir ebenfalls auf false.
@jlorenz Soll ich den xmpp.ibb testweise auf true setzen ? Was wird mit diesem Parameter konfiguriert ?
Grüße
Maik
Hallo @maik ,
ibb steht für In-Band Bytestreams - Damit werden alle File Transfers in den XMPP Stream eingebettet anstatt eine separate Verbindung zu nutzen. (Deswegen ist das auch soviel langsamer wie @HExSM bemerkt hat).
Das Problem ist hier, das sobald externalip gesetzt ist, selbige auch für die File-Transfers verwendet wird. Je nach Firewall-Konfiguration klappt das dann nicht. Also eigentlich dürfte auf diesen Systemen gar keine Dateiübertragung funktionieren.
ibb einfach auf true zu setzen ist hier denke ich der einfachste Workaround. XMPP Server neustarten dann nicht vergessen 
Grüße,
Jan
Workaround 2: Hairpin NAT in der Firewall für Port 7777 einrichten
Damit hat man dann keine Probleme mit der Geschwindigkeit, falls das wichtig ist.
Hallo zusammen,
@jlorenz mit IPP = true funktioniert es.
Was ist nun besser IPP = true setzen oder Port 7777 freischalten.
Grüße
Maik
Hallo @maik,
im cloudstack wird ibb aus technischen Gründen ohnehin erzwungen - von daher is das der Workaround den wir empfehlen (und evtl. in Zukünftigen Versionen automatisch aktivieren).
Grüße,
Jan
1 Like