Posts by comfreak

    Hi,


    stimmt auffallend, der "Connect" kommt zustande.


    Ich habe einmal auf "Certificate Response importieren" geklickt und bekomme folgende Meldung: "keytool error: java.lang.RuntimeException: java.io.IOException: DNSName components must begin with a letter or digit".


    Hm, ja, das Zertifikat hat im SAN mehrere DNS Einträge mit *.domain.tld stehen. Kommt ja etwas mit den * nicht klar?


    Ich habe daraufhin ein neues Zertifikat Request generiert, wo im DNS-Namen nur 1 Adresse steht "starface.domain.tld". Dieses habe ich mit unserer eigenen, privaten CA signiert, wieder in der Starface mit dem CA Zertifikat erfolgreich importiert und die Starface neu gestartet.


    Leider kommt immer noch keine SSL-Verbindung zu Stande, gleiches Phänomen wie vorher.


    Ich habe die "Lösung" mit der Weiterleitung auf https und die Beobachtung mit dem Zertifikat an den Starface-Support mal weitergeleitet. Ich denke, dass ich zwar so das eigentliche Upgrade von 6 auf 7 durchführen und vorerst damit leben kann, dass das Webinterface nur auf http erreichbar ist, aber dennoch eine Lösung von Starface für das https Probleme erwarte...


    Grüße,
    Pascal

    Hi,


    ups, sorry - ich muss mich korrigieren. Ich hatte nach dem letzten Mal wohl einen Snapshot zurück gespielt, wo dann HTTPS wieder deaktiviert war. Habe jetzt HTTPS wieder aktiviert:


    Unbenannt.png


    Code
    [root@localhost ~]# netstat -tupena | grep -E '443|80|8080|8181'
    tcp6       0      0 :::50080                :::*                    LISTEN      91         132877     8497/java
    tcp6       0      0 :::8080                 :::*                    LISTEN      91         132873     8497/java
    tcp6       0      0 :::8181                 :::*                    LISTEN      91         132876     8497/java
    tcp6       0      0 192.168.218.153:8080    192.168.218.241:50937   TIME_WAIT   0          0          -
    tcp6       0      0 192.168.218.153:8080    192.168.218.241:51070   ESTABLISHED 91         244557     8497/java
    tcp6       0      0 127.0.0.1:51356         127.0.0.1:80            TIME_WAIT   0          0          -
    udp        0      0 127.0.0.1:4580          0.0.0.0:*                           10         151283     9678/iaxmodem


    Aber es bleibt dabei: die Seite kann ich nicht mit HTTPS aufrufen - HTTP geht. Wenn ich das richtig interpretiere, ist 443 immer noch nicht offen. 8181 jedoch schon.


    Screenshot_2.jpgScreenshot_3.jpg



    Die Filepermissions 664 sind bei mir auch im Livesystem so...


    Pascal

    Hi,


    also ich finde nicht, dass das so aussieht, als wenn ich eine Antwort auf 443 erhalte. Die Zertifikatswarnung hätte ich auch erwartet, wenn ich direkt die IP angebe statt den DNS.


    Jep, https steht davor:


    Screenshot_1.jpg


    Via http:
    Screenshot_2.jpg



    Port 443 scheint nicht offen zu sein - Port 80 jedoch schon (liefert die Webseite ja auch aus).




    Code
    [root@localhost ~]# ls -la /opt/tomcat/ssl/
    total 16
    drwxrwxr-x  2 root tomcat   99 Feb 15 15:18 .
    drwxr-xr-x. 6 root tomcat  102 Feb 10 10:46 ..
    -rw-rw-r--  1 root tomcat 1870 Apr 13  2016 tomcatcert.pem
    -rw-rw-r--  1 root tomcat 3311 Apr 13  2016 tomcatkey.pem
    -rw-rw-r--  1 root tomcat 3231 Aug  8  2019 tomcat.keystore
    -rw-rw-r--  1 root tomcat 1274 Aug  8  2019 tomcat.keystore.bak

    Hi,


    habe die Daten vom Produktivserver auf den Testserver kopiert, geht leider immer noch nicht mit HTTPS.


    Dienste und kompletter Server wurde neu gestartet.


    Ggf. ein Problem, da es nicht via dem eigentlichen DNS Namen, sondern über die IP Adresse direkt aufgerufen wird...


    Screenshot_2.jpg


    Code
    [root@localhost starface]# ls -l /opt/tomcat/ssl/
    total 16
    -rw-rw-r-- 1 root tomcat 1870 Apr 13  2016 tomcatcert.pem
    -rw-rw-r-- 1 root tomcat 3311 Apr 13  2016 tomcatkey.pem
    -rw-rw-r-- 1 root tomcat 3231 Aug  8  2019 tomcat.keystore
    -rw-rw-r-- 1 root tomcat 1274 Aug  8  2019 tomcat.keystore.bak


    Pascal

    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

    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,


    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




    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....???

    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

    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

    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 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

    Morgen zusammen,


    ich habe einen weiteren Test mit dem VmWare Player gemacht - gleiches Ergebnis. Es liegt also nicht an der Virtualisierungstechnologie bzw. dem Hypervisor Proxmox!


    Bug in der Starface?


    Logs vom VmWare Test sind hier zu finden:LogsVmWare.zip


    Grüße,
    Pascal

    Hallo Tom,


    da die VM nicht mit UEFI läuft, gibt es auch kein Secure Boot zu deaktivieren - soweit ich das richtig im Kopf habe. :)


    ... oder reden wir hier vom Host...?


    Grüße,
    Pascal

    Hi Fabian,


    die VM, inkl. der zur Zeit im Produktiveinsatz, läuft unter Proxmox (QEMU/KVM, 7.1 - aktuelle Version).


    Die VM ist mit einem BIOS konfiguriert - kein UEFI.


    - Evtl. mal mit UEFI versuchen?
    - Wo du "Leitungskonfiguration" ansprichst: Evtl. ein Problem, wenn die Starface sich nicht mit unserem SIP Provider verbinden kann (fände ich schon sehr merkwürdig)? Nur, was passiert, wenn die Test-VM sich mit dem SIP-Provider (Vodafone) verbindet...wird die Produktiv-VM leitungstechnisch raus geschmissen und wir können nicht mehr nach extern telefonieren/externe Anrufe annhmen?
    - Bestimmte Dienste via SSH manuell starten, um an detailliertere Logs zu kommen oder so? Wenn ja, welche/wie?


    Screenshot_1.jpg


    Screenshot_2.jpg


    Grüße,
    Pascal

    Hallo zusammen,


    ich habe die VM via ISO neu installiert, die Lizenzen eingespielt und das Backup wiederhergestellt.


    Leider gleiches Ergebnis. Die Webseite ist nicht mehr erreichbar.


    Ist es ggf. ein Problem, wenn die VM vorher eine andere IP-Adresse hat, als die im Backup hinterlegt ist (wenn sie dort hinterlegt ist)? Ich habe nach der Wiederherstellung geprüft, ob die IP-Adresse sich geändert hat: die VM hat die Gleiche wie vor der Wiederherstellung.


    Hier die Logs und ein paar Screenshots: file.zip


    11:50: Einspielung Lizenz
    11:55: Wiederherstellung Backup
    11:58: Restore laut Webseite fertig -> Reboot


    Grüße,
    Pascal


    Edits: Hatte in einem Screenshot nicht alles zensiert