Bin mal gespannt, was nach dem 30.11. passiert.
Habe genau einen Kunden, dessen 3CX auf einem RPi läuft. Der bekommt aber erst im Dezember ein Proxmox-Cluster.
Das ging leider nicht eher, da Komponenten nicht erhältlich waren.
Habe das Zertifikat auf ein eigenes Zertifikat umgestellt und /var/lib/3cxpbx/Bin/nginx/conf/nginx.conf auf read-only für phonesystem gestellt.
Wenn das dennoch nicht mehr weiter laufen sollte, wäre das uncool von 3CX.
Vermute eh, dass die früher oder später auch die On-Premise-Versionen einstampfen werden und Cloud-Only kommt.
Wäre für uns aus verschiedenen Gründen dann jedenfalls das finale Aus für 3CX.
Habe gerade diese Aussagen durch gelesen:
https://www.3cx.de/blog/raspberrypi-migration-startup/
"...Mit dem Aufkommen von kostengünstigem Cloud Computing und der kostenlosen 3CX StartUP-Lösung macht der Betrieb einer eigenen 3CX-Instanz auf dem Raspberry Pi jedoch keinen Sinn mehr – weder für die Anwender noch für 3CX..."
Der Artikel ist leider für Kommentare gesperrt.
Also schreibe ich hier an Corina Werner:
Mir fällt dazu folgendes ein, warum es gerade für Anwender viel mehr Sinn ergibt, nicht die Cloud-Lösung zu verwenden, sondern statt dessen auf die On-Premise-Lösung zu setzen (zumindest gilt das für unsere Kunden):
Anpassungen an Templates: Z.B. Snom-Telefon-Templates für 2N Anbindung, d.h. Tür öffnen, Kamera-Bild aktivieren und Live-Stream auf dem Display darstellen. Zum anderen gewährleistet eine On-Premise-Anlage eine Anbindung der Türsprechstellen auch bei Ausfall des Internets.
Nächster Punkt: Telekom SIP Trunk NGN: läuft nicht in der Cloud
Dritter Punkt: Eigener FQDN auch in der Standard-Version: Die 3CX wird in unserem automatischen Zertifikats-Deployment mit unserem Zertifikat betankt.
Vierter Punkt: 3CX schreibt Passwörter im Klartext in die DB. Einen Teufel werde ich tun und Klartext-Passwörter auch noch in die Cloud zu verlegen. Dass dies überhaupt so gehandhabt wird, ist gruselig und ein No-Go. Abgesehen davon verstößt damit 3CX gegen die Pflicht zur Gewährleistung der Datensicherheit bei der Verarbeitung personenbezogener Daten gemäß Art. 32 Abs. 1 lit a) DSGVO.
Fünfter Punkt: Wir haben einen Hook geschrieben, der Adressdaten Änderung oder Neuanlage aus dem ERP in die 3CX Postgres DB schreibt, damit diese auf den Telefonen verfügbar und aktuell sind.
Sechster Punkt: Wir haben eine Java-Applikation geschrieben, die Click2Dial aus allen Anwendungen ermöglicht und Informationen sowohl aus dem Verzeichnisdienst, als auch aus der 3CX-DB liest um die Zuordnung der Telefone zu eruieren.
Siebter Punkt: automatisierte Reports generieren, durch Aufbereiten der Daten aus der 3CX-DB
Achter Punkt: Anbindung an Grafana und Prometeus via telegraf. Auch hier wird die DB angezapft.
Neunter Punkt: 3CX läuft auf schlanken LXC-Containern auf einem Proxmox-Cluster und ist deshalb skalierbar und via haproxy hochverfügbar
Zehnter Punkt: Dual- oder Multi-WAN, also sicherere Anbindung, wechselnde Gateways nach Trafic Shaping und Lastaufkommen. Das hat 3CX noch nie gerafft, dass es das gibt und auch so eingesetzt wird.
Wenn ich noch weiter nachdenke, fallen mir noch zehn Punkte ein, warum es für den Anwender keinen Sinn ergibt die Nachteile der Cloud in Kauf zu nehmen. Der einzige, der Vorteile davon hat, ist 3CX.
Und jetzt Off-Topic als Abschluss: Die Zuckerbergsche Whatsapp-Datenkraken-Anbindung hätte man sich schenken können. Das ist bei uns und unseren Kunden tabu. Nicht nur deshalb:
https://www.it-daily.net/it-sicherh...app-verstoss-gegen-datenschutzrecht-liegt-vor
