Uff - der "Lorem ipsum" - Text ist noch als License Agreement im Setup...
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:
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
Code
Display More[root@localhost ~]# wget http://192.168.218.153 --2022-02-16 15:56:13-- http://192.168.218.153/ Connecting to 192.168.218.153:80... connected. HTTP request sent, awaiting response... 200 Length: 1491 (1.5K) [text/html] Saving to: ‘index.html.1’ index.html.1 100%[==============================================================================================>] 1.46K --.-KB/s in 0s 2022-02-16 15:56:13 (145 MB/s) - ‘index.html.1’ saved [1491/1491] [root@localhost ~]# wget https://192.168.218.153 --2022-02-16 15:56:16-- https://192.168.218.153/ Connecting to 192.168.218.153:443... connected. GnuTLS: The TLS connection was non-properly terminated. Unable to establish SSL connection.
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:
Via http:
Screenshot_2.jpgCode
Display More[root@localhost ~]# wget [url]https://192.168.218.153[/url] --2022-02-16 13:52:26-- [url]https://192.168.218.153/[/url] Connecting to 192.168.218.153:443... failed: Connection refused. [root@localhost ~]# wget [url]http://192.168.218.153[/url] --2022-02-16 13:52:30-- [url]http://192.168.218.153/[/url] Connecting to 192.168.218.153:80... connected. HTTP request sent, awaiting response... 200 Length: 1491 (1.5K) [text/html] Saving to: ‘index.html’ index.html 100%[==============================================================================================>] 1.46K --.-KB/s in 0s 2022-02-16 13:52:30 (118 MB/s) - ‘index.html’ saved [1491/1491]
Port 443 scheint nicht offen zu sein - Port 80 jedoch schon (liefert die Webseite ja auch aus).
Code
Display More[root@localhost ~]# netstat -tulpena | grep 443 [root@localhost ~]# netstat -tulpena | grep 80 tcp 0 0 127.0.0.1:5038 127.0.0.1:58012 ESTABLISHED 996 28258 1408/asterisk tcp 0 0 192.168.218.153:32990 192.168.218.153:80 TIME_WAIT 0 0 - tcp 0 0 127.0.0.1:5038 127.0.0.1:58052 ESTABLISHED 996 32048 1408/asterisk tcp 0 0 127.0.0.1:5038 127.0.0.1:58054 ESTABLISHED 996 32959 1408/asterisk tcp 0 0 127.0.0.1:5038 127.0.0.1:58050 ESTABLISHED 996 32046 1408/asterisk tcp6 0 0 :::8080 :::* LISTEN 91 28329 1503/java tcp6 0 0 :::50080 :::* LISTEN 91 28332 1503/java tcp6 0 0 127.0.0.1:58012 127.0.0.1:5038 ESTABLISHED 0 28257 1527/java tcp6 0 0 127.0.0.1:58054 127.0.0.1:5038 ESTABLISHED 91 32958 1503/java tcp6 0 0 127.0.0.1:58052 127.0.0.1:5038 ESTABLISHED 91 32047 1503/java tcp6 0 0 ::1:35880 ::1:5432 ESTABLISHED 996 28082 1408/asterisk tcp6 0 0 127.0.0.1:58050 127.0.0.1:5038 ESTABLISHED 91 32045 1503/java tcp6 0 0 ::1:5432 ::1:35880 ESTABLISHED 26 27544 1979/postgres: aste tcp6 0 0 127.0.0.1:46446 127.0.0.1:80 TIME_WAIT 0 0 - tcp6 0 0 127.0.0.1:54380 127.0.0.1:5432 TIME_WAIT 0 0 - udp 0 0 0.0.0.0:4569 0.0.0.0:* 996 28078 1408/asterisk udp 0 0 127.0.0.1:4580 0.0.0.0:* 10 42686 2955/iaxmodem
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...
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?).
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,
PascalHabs: /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.
-
Hi,
darf ich noch erfragen, wo der Keystore dann auf einer 7.1er landen soll?
Danke und Grüße,
Pascal -
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 refusedNachdem 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ß
ThomasHi,
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ß
ThomasDas 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 -
Hi Silas,
meinst du die mit Interfaces die Leitungen zum Provider? Neben der Standard "STARFACE Connect" nur unsere Leitung zu Vodafone...
-
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 -
Hi Fabian,
danke - ich wende mich an den Support und gebe eine Rückmeldung.
Grüße und schönes Wochenende,
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?Grüße,
Pascal -
Hi,
https geht auch nicht nicht. http leitet auf https weiter, aber das schlägt fehl, weil Port 443 nicht offen ist?
Die folgenden Ports scheinen laut nmap offen zu sein:
22
80
5222
5261
5060 -
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 -> RebootGrüße,
PascalEdits: Hatte in einem Screenshot nicht alles zensiert