• Hallo zusammen,

    danke für die Antworten.

    ChrisKrause: Ich habe das Problem aber auch unter VMware reproduzieren können, daher schließe ich eine Fehlkonfiguration der VM unter Proxmox aus. Hier die Config meiner VM: Screenshot_2.jpg - "Display" und "Machine" ist bei mir anders, aber wie gesagt, unter VMware habe ich das Problem auch reproduzieren können. Ein "kleineres" Backup habe ich auch schon versucht zu importieren, leider auch erfolglos.

    bytegetter: Ich kann die Starface neu installieren und dann läuft sie ja auch. Ich habe erst Probleme, wenn ich ein Backup aus der vorherigen Version importiere (so wie es von Starface vorgesehen ist). Die Starface mit den alten Einstellungen manuell neu einrichten ist viel Arbeit, welche ich mir ersparen möchte - vor allem, weil Starface das Importieren des Backups ja als korrekte Vorgehensweise beim Upgrade vorgibt.

    Grüße,
    Pascal

  • Hallo zusammen,

    @Silas: Nein wir haben in der alten VM 1 Netzwerkadapter, sowie bei der neuen VM 1 Netzwerkadapter.

    bytegetter: Ich kann bei der Installation via ISO keine Backupdatei angeben. Wenn ich die VM mit der ISO starte, wird nach der Auswahl im GRUB Boot Menü (Auswahl "Install STARFACE") automatisch die Installation gestartet. Dabei habe ich keine Möglichkeit eine Backupdatei anzugeben. Nach dem 1. Boot geht der Wizard auf, wo ich zwar eine Backupdatei angeben kann, aber nach dem Restore lande ich wieder in dem genannten Problem.

    Screenshot_0.jpgScreenshot_1.jpgScreenshot_2.jpgScreenshot_3.jpg

    Ich denke ich werde es weiter mit dem Starface Support versuchen. :)

    Dennoch danke.

    Grüße,
    Pascal

  • Hallo,

    hat jemand eine Lösung für das Problem gefunden? Ich habe hier das gleiche Problem. Die Installation der neuen VM und update auf Version 7.1.1.7 geht soweit ohne Probleme (unter Proxmox). Sowie ich versuche ein Backup meiner Starface 6.7 einzuspielen kommt der Fortschrittsbalken, der auch suggeriert, dass das alles funktioniert hat, aber das Webinterface ist nicht erreichbar. Ich komme per ssh auf die VM und dort sehe ich auch tomcat laufen. Der lauscht aber komischerweise nicht auf Port 443 oder 80. Offenbar ist das über nft/firewallregeln per NAT/redirect geregelt, dass Requests auf Port 443 zum tomcat umgeleitet werden, aber das scheint irgendwie nicht zu gehen... leider kann ich das nicht weiter debuggen, da ich mich mit nft kaum auskenne....

    Bin für jeden Tipp dankbar, da ich die starface nun endlich auf 7.1 heben muss...

    Danke und Gruß
    Thomas

  • Hi,

    ich bin zur Zeit im Kontakt mit dem Starface Support. Deren Vorschlag war bisher alle Drittanbietermodule (wir hatten nur 1) zu entfernen und alte Daten mit dem Starface Achivierungsmodul zu archivieren. Alternativ die 7er Starface Anlage manuell neu konfigurieren...:(

    Das brachte aber leider keine Abhilfe und ich habe jetzt ein Backup von unserer Anlage eingeschickt, damit Starface es reproduzieren kann - mal schauen was dabei rum kommt.

    Ich habe neben Proxmox auch den VMware Player getestet, um QEMU/Proxmox auszuschließen, leider beide Male das gleiche Ergebnis - sogar wenn ich auf eine 6.7er das Backup wiederherstelle (heißt also, unsere momentanen Backups sind nutzlos (wir haben zum Glück noch ganze tägliche VM Backups...)).

    Ich werde aber weiter berichten, wenn ich mehr weiß.

    Grüße,
    Pascal

  • Hi

    Quote


    Ich habe neben Proxmox auch den VMware Player getestet, um QEMU/Proxmox auszuschließen, leider beide Male das gleiche Ergebnis - sogar wenn ich auf eine 6.7er das Backup wiederherstelle (heißt also, unsere momentanen Backups sind nutzlos (wir haben zum Glück noch ganze tägliche VM Backups...)).

    Oh Mann... das klingt ja großartig.... Wir haben noch diverse 6.7er Anlagen, die wir supporten und "irgendwann" mal updaten müssen. Eine manuelle Neukonfiguration ist da voll der Horror, und die Kunden werden das sich nicht zahlen wollen....

    Gruß
    Thomas

  • slu: Ohne vorwurfsvoll zu sein: Was soll ich denn mit top sehen sollen? Die Auslastung eines Prozesses, was mir dann was bringt? Ein Log zu beobachten wäre doch eher sinnvoller oder (welche hier im Thread ja bereits verfügbar sind)?

    Ich kann dir nicht ganz folgen, sorry. :(

    Aber ehrlich: ich will aus Zeitmangel nicht spielen (privat sähe das anders aus) - ich befolge den Anweisungen von Starface und es geht nicht, der Ball liegt für mich bei Starface...

    Grüße,
    Pascal

  • Was soll ich denn mit top sehen sollen? Die Auslastung eines Prozesses, was mir dann was bringt?

    Es wäre ein Anfang das Problem einzugrenzen...


    Ein Log zu beobachten wäre doch eher sinnvoller oder (welche hier im Thread ja bereits verfügbar sind)?


    Bin ich ganz bei dir, ich würde mich da einfach mal mit /var/log beschäftigen bevor man direkt in /var/log/starface schaut.

  • Hi alle,

    ich habe noch etwas "rumgeforscht" (aber parallel auch einen Call bei Starface aufgemacht). Der eigentliche Java Prozess, der das WebUI ausliefert lauscht nicht auf Port 80 oder 443 sondern auf den Ports 8080 bzw. 8181. Die Zugriffe mit dem Webbrowser, die ja auf Port 80 oder 443 landen, werden per Firewallregel auf 8080 bzw. 8181 umgeleitet. Das ist sowohl bei 6.7 als auch bei 7.1 so.

    Nachdem ich nun aber ein Backup auf 7.1 einspiele, lauscht der Prozess zwar noch auf Port 8181, jedoch auf der Loopback Adresse 127.0.0.1 und nicht generell auf allen IPs des Hosts (so wie es wohl normalerweise sein sollte, so ist es jedenfalls _bevor_ ich das Backup auf der 7.1er Version eingespielt hatte). Der Prozess lässt auch keine Zugriffe zu und lehnt jeden Verbindungsaufbau ab:

    telnet localhost 8181
    Trying ::1...
    telnet: connect to address ::1: Connection refused
    Trying 127.0.0.1...
    telnet: connect to address 127.0.0.1: Connection refused

    Nachdem ich den Server einmal boote, lauscht kein Prozess mehr auf 8181, sondern nur noch auf 8080. Ein http Request auf Port 80 wird direkt mit einem redirekt auf 443 beantwortet, da aber kein Prozess vorhanden ist, der diesen bedient, geht das nicht.

    Hat jemand eine Vermutung? Am Ende ist das noch irgend ein Verschlüsslung/Zertifikats/CA Problem...

    Gruß
    Thomas

  • Hi alle,

    ich nochmal...

    Quote


    Hat jemand eine Vermutung? Am Ende ist das noch irgend ein Verschlüsslung/Zertifikats/CA Problem...

    ..genau das ist es dann auch... Beim Backup wird offenbar der keystore nicht mit übertragen und der tomcat
    hat keinen key mit dem er die Verschlüsselung machen kann.... Lösung: vor dem Backup den webserver im
    AdminUI so umkonfigurieren, dass es sowohl auf http als auch auf https lauscht und kein redirect erzwingt.
    Dann kann man nach dem wiederherstellen des Backups per http:// auf die Starface zugreifen...

    Gruß
    Thomas


  • Hi,

    bei mir ist auch kein Port 8181 mehr auf, nur 8080 auf der normalen IP (also nicht localhost). 443 ist auch nicht auf und Port 80 lauscht nur auf localhost


    Hi alle,

    ich nochmal...


    ..genau das ist es dann auch... Beim Backup wird offenbar der keystore nicht mit übertragen und der tomcat
    hat keinen key mit dem er die Verschlüsselung machen kann.... Lösung: vor dem Backup den webserver im
    AdminUI so umkonfigurieren, dass es sowohl auf http als auch auf https lauscht und kein redirect erzwingt.
    Dann kann man nach dem wiederherstellen des Backups per http:// auf die Starface zugreifen...

    Gruß
    Thomas

    Das könnte ich mal testen...jedoch bleibt dann als Ergebnis, dass Backups für die 6.7er nutzlos waren, da der Key nicht mit exportiert wurde....???

  • Hi,

    darf ich noch erfragen, wo der Keystore dann auf einer 7.1er landen soll? :)

    Danke und Grüße,
    Pascal

    Habs: /var/starface/tomcat/ssl/keystore.jks

    Jedoch existiert der Keystore dort bereits - identisch zu dem im Backup.

    Ich werde es mit dem Vorschlag von t.klaube versuchen - jedoch lauscht unsere Starface bereits auf http und https, aber ich werde die Umleitung auf https mal deaktivieren.

    Screenshot_1.jpg

  • Hi,

    jep - wenn ich die Weiterleitung auf HTTPS deaktiviere und nach dem Restore nur HTTP aufrufe, kann ich die Webseite erreichen. Aktiviere ich dann wieder die Umleitung, geht es nicht mehr. Etwas komisch ist dann die Meldung, dass die Starface unter der Adresse localhost.localdomain zu erreichen ist (dürfte die Beobachtung von t.klaube bestätigen?).

    Unbenannt.jpg

    Nun gut - ich habe 2 Telefone in die Test-Starface eingebunden/provisionieren lassen und kann telefonieren.

    Zusätzlich habe ich einen vollständigen Import des Backup durchgeführt (Sprachansagen, Statistiken etc.) und auch das funktioniert, solange die Weiterleitung auf HTTPS deaktiviert ist.

    Ich denke so kann ich den Upgradeversuch im Produktivsystem versuchen.

    Heißt also ich kann mit der 7.1er keine HTTPS Weiterleitung mehr aktivieren, solange ich die Starface nicht neu aufsetze?


    Grüße,
    Pascal

    Edited once, last by comfreak (February 15, 2022 at 12:04 PM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!