Kurze Aktualisierung in der Sache:
Das Problem entstand wohl durch eine hohe Load auf den Webserver-Systemen, daher konnte die SSL-Warteschleife nicht von Liveconfig abgearbeitet werden. Nachdem die Load wieder im Normalbereich war, haben wir die Liveconfig-Dienste jeweils einmal neu gestartet, anschließend wurden die Zertifikate generiert.
Hallo,
uns ist heute aufgefallen, das die Verlängerung von bestehenden Let's Encrypt Zertifikaten seit einigen Tagen nicht mehr zu funktionieren scheint, die entsprechenden Aufträge verbleiben im Status "pending". Beispiel für eine Domain (Aussteller R11, Methode http-01, Ablauf am 25.03.2025):
{ "type": "http-01", "url": "https://acme-v02.api.letsencrypt.org/acme/chall/26**6/48*********p9g", "status": "pending", "token": "zQGRM**************rmnpJQ"}Laut liveconfig.log wurde die Erneuerung am 23.02. gestartet:
[2025/02/23 21:13:26.368665] [772|1587023] ACME2: starting order/renewal for SSL certificate 'w*******.de'Liegt aktuell ein Problem seitens Let's Encrypt vor? Gibt es eine Möglichkeit, an weitere Log-Daten zu kommen um das Problem genauer eingrenzen zu können?
Wir haben Weiterleitungen zu GMX/Webde/Gmail usw bei uns komplett unterbunden (blacklisted). Bestehende Weiterleitungen blieben aktiv.
Interessehalber: Innerhalb von LiveConfig blacklisted, so das Kunden beim Versuch der Konfiguration auf eine GMX/Web.de Adresse auch direkt angezeigt bekommen, das dies nicht erlaubt ist? Falls ja, wo wird dies konfiguriert?
Wer Webfakt mit vielen Kunden nutzt, wird mit einer Webanwendung als Ersatz nicht glücklich werden.
Webfakt können wir problemlos parallel von mehreren Arbeitsplätzen aus nutzen. Manchmal hakt es ein wenig, aber im Prinzip läuft es sehr gut.
Das sehe ich eigentlich nicht so. Vor 20 Jahren gab es bei Webanwendungen natürlich nicht die Möglichkeiten wie heute, aber die Zeiten haben sich geändert. Im Grunde ist das genauso eine Client-Server-Anwendung mit Datenbank- und Webserver. Viele Dinge, die Webfakt in der Client-Anwendung ausführt, lassen sich darüber hinaus ins Backend auf den Server verlagern (z.B. automatisierter Rechnungs- und Mahnlauf mit PDF-Generierung, Aktualisierung von Domains/Handles, Newsletterversand, SEPA-Lauf, Rücklastschriften erfassen usw.). Am Ende lässt sich das Frontend auf die Funktionen der Daten-Ein-/Ausgabe sowie Statistik/Analyse beschränken. Zumindest im Kern, denn im Laufe der Zeit wurde Webfakt so sehr aufgebläht das niemand alle Funktionen im vollen Umfang nutzen wird.
Wir warten deshalb noch ab, was tatsächlich die Zukunft bringt. Es gibt ja (für uns) keinen echten Zeitdruck jetzt sofort umsteigen zu müssen. Möglicherweise gibt es ja irgendwann eine wirklich sinnvolle Client/Serverlösung-Anwendung.
Ich denke, etwas komplett neues wird es in der Richtung nicht mehr geben, dafür ist der Hosting-Bereich zu speziell und die großen in der Branche haben weitgehend Eigenentwicklungen mit Kombinationen von Standard-Software (z.B. für die Buchhaltung).
Die Preise von Hostware sind nicht akzeptabel. Ab 499,- Eur im Monat(!) wenn man mehr als 2000 Kunden verwalten will....
Hinzu kommt, das man für die API-Anbindung an die Buchhaltung meist auch das größte Paket des jeweiligen Anbieters benötigt (bei LexOffice z.B. ~30€/Monat). Bei den kleineren Paketen steht keine API zur Verfügung. Natürlich wesentlich weniger im Vergleich zu dem Monatspreis von Hostware, aber bei mehreren Anbindungen kann so etwas die Gesamtsumme auch stark erhöhen.
Es gibt für viele Funktionen gute Lösungen am Markt und im Bereich Buchhaltung ist das für uns aktuell Lexoffice / Lexware office, deren API-Ansatz unseren Vorstellungen entspricht und zuverlässig weiterentwickelt wird.
Das halte ich ebenfalls für den besseren Ansatz, insbesondere wenn man bedenkt, das es immer mal wieder gesetzliche Änderungen gibt. Bei einem großen Anbieter wie Lexware ist man dann besser aufgehoben und muss sich um diesen Bereich nicht mehr selbst kümmern.
Mir wäre es langfristig zu riskant, weiterhin damit zu arbeiten. Ganz unabhängig davon, dass in meinen Augen eine desktopbasierte Windows-Software in 2024 nichts mehr zu suchen hat.
Das Problem war leider die fehlende Kommunikation seitens CiKa Software. Es wurde weder vorab, noch direkt nach Einstellung der Geschäftstätigkeit darüber informiert. Bei einigen Monaten Vorlaufzeit hätte man besser planen können, jetzt ist die kommende E-Rechnung der zeitliche Faktor.
Hostware hat zwar ganz viele Schnittstellen zu externen Services, bietet aber m.W. aktuell immer noch selber keine vernünftige API. Damit hätte ich schonmal ein Problem.
Das war tatsächlich schon vor 3 Jahren ein Kriterium auf Laravel zu setzen, da im Grunde eine vernünftige REST-API "out of the box" mit drin ist.
Die fehlende API ist definitiv ein Problem. Und eine solche sollte von Beginn an für sämtliche Funktionen existieren, denn Nachimplementierungen haben immer große Einschränkungen (wie man dann z.B. bei KBMPro sieht, wo die Module auf Kundenwunsch integriert wurden). Das Modul-System von Hostware ist allerdings sehr interessant: Wenn man sich in diesem Bereich mit mehreren Anbietern auf eine offene Lösung einigt, so könnte sehr viel Arbeitsaufwand eingespart werden. Ansonsten baut man mit einer Eigenlösung jedes mal neu eine Schnittstelle nach, welche jemand bereits umgesetzt und im Einsatz hat. Diese Zeit wäre besser investiert in der eigenen Kern-Software sowie einem bestimmten offenen Modul, welches man dann auch entsprechend pflegt.
Webfakt rechnet in der Rechnung falsch oder besser gesagt "ungenau" oder noch besser "zu genau".
Rechnungspositonen werden dort mit allen Nachkommastellen aus der Artikeldatenbank als Gesamt-Netto aufsummiert, dann die Märchensteuer daraus berechnet und damit der Brutto-Endbetrag.
Das fällt vor allem bei den Domain-Rechnungen in größerer Anzahl auf. Es sind zwar nur Cent-Beträge, aber am Ende ist die Summe nun mal falsch.
Wir haben einen auf Perl basierten Server ("ZUGFeRD-Server") programmiert, der auf einem bestimmten Port SMTP annimmt.
Ein guter Lösungsweg, daran hatte ich jetzt nicht gedacht! Das verschafft etwas Zeit für eine Eigenlösung. Am Ende sollte eine API zu einer etablierten Fakturierungssoftware stehen, welche ihrerseits regelmäßig an die gesetzlichen Erfordernisse angepasst wird. Im Bedarfsfall kann man diese auch zu einer anderen Software ändern oder eine Eigenlösung bauen, ohne die grundlegende Software (Datenbank mit Kundendaten, Speicherplätzen, Domains usw.) umbauen zu müssen.
Möglicherweise schwenken wir dann auch irgendwann um, aber aktuell sind wir dabei die ZUGFeRD-Rechnung auch in Webfakt mit einer eigenen vollständig im Webfakt-Workflow integrierten Lösung zu realisieren. Damit kann Webfakt dann auch problemlos weiter benutzt werden.
Das wäre als Übergangslösung interessant. Allerdings sehe ich dafür nur zwei Wege: Entweder man erstellt die ZUGFeRD-PDF-Dateien (Rechnungen) selbst indem man in Webfakt die Datenbank entsprechend ausliest. Oder man übernimmt die bereits generierten PDF-Dateien und ergänzt diese um die eingebetteten XML-Daten, bevor diese per E-Mail versandt werden. Darf man mehr über euren Lösungsweg erfahren?
Wir hatten Kontakt mit https://www.agenturbo.de/ und dem Produkt KBMpro.
KBMPro haben wir uns ebenfalls angesehen. Sehr schöne Software, allerdings mit Schwerpunkt auf Agenturen statt Provider. Leider kein API-First Prinzip, sonst hätte man fehlende Module leicht ergänzen können. So dürfte es derzeit sehr schwierig werden, alle fehlenden Funktionen von Webfakt nach zu implementieren.
Hostware (https://hostware.io/) sah ebenfalls interessant aus, allerdings benötigt dies ebenfalls eine externe Fakturierung/Buchhaltung für die Rechnungsgenerierung und -Versand.
Individuelle Lösung auf Laravel-Basis (u.a. mit Laravel Backpack) und selbstgebauter Anbindung an LexOffice und InternetX (AutoDNS).
Haben auch eine automatisierte Webfakt-Migration über Verarbeitung der Daten aus den Webfakt-Tabellen entwickelt.
Bei Fragen gerne melden.
Ich hatte dir im April eine PN hier im Forum geschickt, kam diese an? Auf lange Sicht finde ich eine solche Individuallösung am geeignetsten, mit Anbindung an eine externe Fakturierung und Schnittstellen zu den übrigen Systemen (Domainverwaltung / LiveConfig / ...). So könnte bei Bedarf auch eine Schnittstelle jederzeit gewechselt werden.
Das Rate-Limit wird mit jedem Update der Mail-I/O-Statistiken geprüft (also ca. alle 10 Minuten)
Kurze Rückfrage hierzu: Bei der Übersicht der Postfächer in LiveConfig (Menüpunkt "E-Mail") wird in der vorletzten Spalte der Wert "I/O (24Std)" angezeigt. Aus welcher Tabelle/Feld stammt dieser Wert in der Datenbank? Auf dem Mailserver-System selbst scheinen die Werte in der Datei "/var/lib/liveconfig/smtp.stats" vom Logparser gesammelt und dann in Intervallen mit dem Master-System abgeglichen zu werden. Wenn wir das Feld auslesen könnten, so könnte zumindest eine Warnung ausgesendet werden wenn ein bestimmtes Limit bei einem Postfach erreicht würde.
Hallo,
ist jemand von gSales bereits umgestiegen oder hat eine passende Alternative gefunden? Eine ähnliche Wechselproblematik gibt es zur Zeit bei Webfakt ebenfalls, nur mit dem Unterschied, das dort die Entwicklung komplett eingestellt wurde.
Wir haben so ein fast identisches System bereits vor 11 Jahren individuell programmieren lassen um unabhängig von solchen Anbietern zu sein. Es hat zwar ordentlich was gekostet, aber das war das beste was wir je machen konnten. Rechnungswesen, Mahnwesen, Gutschriften, Domain-, DNS- und Serververwaltung und ein Loginbereich für den Endkunden sowie vieles mehr sind drin.
Das wäre natürlich auch damals eine Alternative gewesen. Allerdings ist das nicht nur ein großer einmaliger Aufwand, so eine Software will natürlich ständig weiterentwickelt und gepflegt werden, um z.B. den aktuellen gesetzlichen Vorgaben zu entsprechen.
Für unsere Agentur- und Hosting-Abrechnung und -Automatisierung haben wir uns allerdings vor ca. 2 Jahren ein Verwaltungstool auf Laravel-Basis gebaut, dass die Funktionen, die LexOffice nicht hat, bietet (u.a. die Abrechnungswarteschlange, Domains und Hostingpakete registrieren/anlegen/kündigen etc. und einiges mehr) und am Ende nur die Rechnungen in LexOffice über die API erzeugt.
Zu einer solchen zweigeteilten Lösung tendiere ich zwischenzeitlich auch. Hat jemand bereits Erfahrungen mit Hostware gesammelt (https://hostware.io)? Im Grunde wäre dies ja ein passendes Tool, um alles relevante im ISP-Bereich sowie die Kundenstammdaten pflegen zu können, die Rechnungserstellung übernimmt dann LexOffice oder sevDesk.
Sobald LC3 mit der REST-API am Start ist wird das nochmal überarbeitet und ggf. wird daraus dann ein Produkt. Bei Interesse aber gerne auch jetzt schon melden.
Gibt es da schon Neuigkeiten zu?
Ich muss dieses Thema auch einmal nach all den Jahren aufgreifen, zumal es in letzter Zeit akut wird. Wenn ich es nach den Recherchen hier im Forum richtig verstanden habe, dann ist die Rate-Limit Funktion zwar eingebaut, ober noch immer nur über die Shell steuerbar? Natürlich könnte man jetzt mit entsprechenden Scripten alle bereits angelegten Domains parsen und in der Datenbank für das Rate-Limit aktivieren, dazu mit LUA-Scripten diese ebenfalls bei Neuanlage eintragen lassen. Bevor wir diesen Weg gehen aber noch eine Zusatzfrage:
Wir hätten gerne ein globales Rate-Limit für jedes existierende Postfach, zusammen mit einer Reporting-Möglichkeit sofern dieses überschritten wird. Nutzer, die größere Mengen an Nachrichten versenden (z.B. Newsletter) könnten dann nach Absprache manuell eingetragene Rate-Limits erhalten. Wenn ich es richtig gelesen habe, ist die Steuerung der Limits und die Freischaltung über den Postfach-Dialog geplant (was derzeit noch nicht in der Oberfläche implementiert ist). Dies wäre aber insoweit kontraproduktiv, als das ein betroffener User sich dann einloggt und die Freischaltung ohne weitere Prüfung vornehmen könnte, ähnlich wie bei einer automatischen Freischaltung nach Zeitintervall. Falls nicht nur das Postfach selbst kompromittiert ist, sondern beispielsweise die LiveConfig Zugangsdaten oder die lokalen PCs des Nutzers, so würde eine Kennwort-Änderung beim Postfach ebenfalls nur bedingt hilfreich sein.
Da der Topic bereits 9 Jahre alt ist, müssten eigentlich bereits Praxis-Erfahrungen vorliegen. Hat jemand die in LiveConfig integrierte Datenbank bereits länger in der Praxis in Verwendung, funktioniert dies mit den LUA-Scripten zuverlässig? Oder gibt es für diesen Zweck auch andere Konfigurationsmöglichkeiten, z.B. global über Postfix oder einer Zusatz-Software?
Wir haben tausende Kunden, hunderte Artikel, massenweise Vorlagen für Emails und andere Aktionen, Abrechnungsdaten, hunderte offene Posten mit unterschiedlichen Mahnungszuständen, tausende gebuchte Artikel alle mit unterschiedlichen Laufzeiten, Preisen etc.pp.
Das würde ich gerne mal sehen, wenn von heute auf morgen der Anbieter weg ist und man sofort unter Zeitdruck sich eine Sofware suchen muss die das allen genauso kann und die auch noch ale Daten importieren kann - das gehe ich jede Wette ein., das ist auch in 4 Wochen nicht realistisch.
Das wird auch jetzt bei einem Wechsel von Webfakt nicht realistisch sein. Im besten Fall findet man zeitnah eine geeignete Software und muss noch etwas selbst entwickeln, um die Daten per API selbst zu migrieren. Und in 10 Jahren steht man vielleicht wieder am gleichen Punkt.
Ich haben aber nicht dem Zeitdruck, weil die Software ja bei uns läuft ud auch weiterläuft. Spätestens wenn irgendwelche rechtlichen Änderungen eintreten, die nicht mehr umsetzbar sind, erst dann müsste man sich umsehen nach Ersatz.
Im besten Fall schaut man sich bereits vorher um. Oder noch besser, man nutzt diese Übergangszeit, um eine eigene Lösung zu entwickeln. Für uns stellt sich lediglich noch die Frage, ob für die Rechnungsstellung / Mahnwesen / Buchhaltung ein externes Produkt per API angesteuert werden soll oder ob man dieses integriert. Die Verwaltung der Kundendaten, Webspace-Pakete, Server und die Schnittstellen zu LiveConfig oder Domainanbietern würde dann in jedem Fall in der eigenen Software erfolgen.
Um zur eigenen Fragestellung zurück zu kommen: Aus meiner Sicht gibt es aktuell kein alternatives Produkt zu Webfakt als Gesamtpaket. Insbesondere nicht, wenn alles lokal laufen soll.
Naja... gSales erstellt ja nur Rechnungen und verwaltet die Kundendaten und Verträge. Aber irgendwie muss ja eine Buchhaltung, Lohn, Steuer, etc. gemacht werden.
Das macht bei uns der Steuerberater. Ich wäre in Zukunft aber natürlich auch nicht abgeneigt, das ganze aufzuteilen: LexOffice für Rechnungsversand / Buchhaltung / Lastschrift-Einzüge / Mahnwesen etc., darauf hätte der Steuerberater ebenfalls Zugriff. Und für die Verwaltung der Kundendaten / Server / Domains / Webspace-Pakete mit zugehörigen Schnittstellen ein separates System. Für letzteres gibt es aber scheinbar noch kein fertiges Produkt bzw. nur individuell programmierte Lösungen.
Zum Thema: wir haben lange Zeit g*Sales eingesetzt. Konzeptuell unschlagbar - die aktuelle Version kenne ich aber nicht mehr. Wir setzen ein eigenes System ein, das die Buchhaltungsdaten dann nach Lexoffice kippt. Lexoffice läuft gut - für Hosting mit schnell ändernden Produkt-Lebenszyklen sind die Serienrechnungen IMHO aber nur schwerlich brauchbar.
Ich hatte im Topic zu gSales bereits gesehen, das einige eine solche Kombination mit LexOffice wohl gebaut haben, z.B. hier:
Darf man fragen, warum in dieser Kombi und nicht direkt gSales? Warum hattet ihr das damals umgestellt?
Aktuell erscheint bei Aufruf der Cika-Software Webseite nur noch ein Wartungshinweis.
Warum nicht das liveconfig-meta-Paket deinstallieren und die (benötigten) Abhängigkeiten manuell installieren?
Das wäre eine mögliche Option. Allerdings ist das Meta-Paket ja genau für den Fall gedacht, das man alle benötigten Dienste "in einem Rutsch" auf einem Einzelsystem installieren kann. Auf den Cluster-Systemen nutzen wir dieses natürlich nicht. Eigentlich würde schon eine Option ausreichen, um die vom OS installierte PHP-Version in LiveConfig auszublenden und für die Zukunft die Standard-Version automatisch heraufsetzen zu können.
Das Problem mit der installierten Version 5.6.40 bzw. liveconfig-meta Paket wurde zwischenzeitlich gelöst:
apt depends liveconfig-meta
liveconfig-meta
Depends: libc6 (>= 2.19)
Depends: ca-certificates
Depends: quota
Depends: bzip2
Depends: unzip
Depends: zip
|Depends: <apache2-mpm-prefork>
Depends: apache2 (>= 2.4)
|Depends: apache2-suexec
apache2-suexec-custom
apache2-suexec-pristine
Depends: apache2-suexec-pristine
Depends: libapache2-mod-fcgid
|Depends: php5-cgi
Depends: php-cgi
php7.4-cgi
|Depends: php5-cli
Depends: php-cli
php7.0-cli
php7.3-cli
php7.4-cli
|Depends: php5-curl
Depends: php-curl
php7.3-curl
php7.4-curl
|Depends: php5-gd
Depends: php-gd
php7.4-gd
|Depends: php5-imagick
Depends: php-imagick
|Depends: php5-imap
Depends: php-imap
php7.4-imap
|Depends: php5-mysql
Depends: php-mysql
|Depends: php5-sqlite
Depends: php-sqlite3
php7.4-sqlite3
Depends: imagemagick
graphicsmagick-imagemagick-compat
imagemagick-6.q16
Depends: postfix
Depends: dovecot-imapd
Depends: dovecot-pop3d
Depends: dovecot-sieve
Depends: clamav-milter
Depends: opendkim
|Depends: <mysql-server>
Depends: mariadb-server
Depends: proftpd-basic
|Depends: awstats
Depends: webalizer
Recommends: <libapache2-mod-suphp>
|Recommends: php5-mcrypt
Recommends: <php-mcrypt>
Recommends: <php5-mhash>
php5-common
Recommends: <php5-suhosin>Hier mussten lediglich vorab die angegebenen "php-*" Pakete installiert werden, bevor die veralteten Versionen entfernt werden konnten:
apt install php-cgi php-curl php-gd php-imagick php-imap php-mysql php-sqlite3
apt remove php5-cli php5-cgi php5-common
apt auto-removeJetzt taucht in LiveConfig die PHP-Version 7.4.33 als Standard-Version auf. Da das PHP-Paket innerhalb des liveconfig-meta Pakets als Abhängigkeit definiert ist, kommt man um die Installation wohl nicht herum. Gibt es denn zumindest die Möglichkeit, dieses in der Oberfläche für den Kunden auszublenden? Eine Checkbox wie bei den opt-Varianten ist in den Einstellungen leider nicht vorhanden.
Wir haben heute einen Kundenserver auf einen aktuelleren OS-Stand gebracht (aktuell noch Debian 11). php-8.1-opt und php-8.2-opt sind über das LiveConfig Repository installiert, ältere opt-Pakete wurden entfernt. Allerdings hat dieses System seine ursprüngliche Standard PHP-Version bis heute beibehalten (5.6.40):
- PHP 5.6.40 [DEFAULT] (code='php5')
CGI/FastCGI: /usr/bin/php-cgi
default php.ini: '/etc/php5/cgi/php.ini'
- default PHP CLI: /usr/bin/phpDiese würden wir gerne am besten aus der LiveConfig-Auswahlliste sowie vom System entfernen. In einem Artikel aus der Wissensdatenbank (https://www.liveconfig.com/de/kb/debian-upgrade-8/) wurde eine Aktualisierung zwar beschrieben, stößt aber auf Probleme:
apt -s remove php5-cli php5-cgi php5-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
apache2 apache2-bin apache2-data apache2-suexec-pristine apache2-utils clamav clamav-base clamav-daemon clamav-freshclam clamav-milter clamdscan dns-root-data galera-4
geoip-database gsfonts imagemagick imagemagick-6-common imagemagick-6.q16 libaom0 libapache2-mod-fcgid libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap
libcgi-fast-perl libcgi-pm-perl libclamav9 libconfig-inifiles-perl libdav1d4 libdbd-mysql-perl libdbi-perl libde265-0 libdjvulibre-text libdjvulibre21 libfcgi-bin
libfcgi-perl libfcgi0ldbl libfftw3-double3 libgeoip1 libgomp1 libheif1 libhiredis0.14 libhtml-template-perl libilmbase25 libjxr-tools libjxr0 liblqr-1-0 libltdl7
libmagickcore-6.q16-6 libmagickcore-6.q16-6-extra libmagickwand-6.q16-6 libmariadb3 libmcrypt4 libmemcached11 libmemcachedutil2 libmilter1.0.1 libmspack0 libmysqlclient18
libnetpbm10 libnl-3-200 libnl-genl-3-200 libnuma1 libonig2 libopendbx1 libopendbx1-sqlite3 libopendkim11 libopenexr25 libpng12-0 libqdbm14 librbl1 libsnappy1v5
libterm-readkey-perl libtfm1 libunbound8 libvbr2 libvpx1 libwebpdemux2 libwebpmux3 libwmf0.2-7 libx265-192 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-common
mariadb-server mariadb-server-10.5 mariadb-server-core-10.5 mysql-common netpbm opendkim opendkim-tools php-common php-curl php-imagick php7.4-cgi php7.4-cli php7.4-common
php7.4-curl php7.4-json php7.4-opcache php7.4-phpdbg php7.4-readline proftpd-basic proftpd-core proftpd-doc proftpd-mod-crypto proftpd-mod-wrap quota socat ttf-dejavu-core
unzip webalizer zip
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
php7.4-cgi
Suggested packages:
php-pear
The following packages will be REMOVED:
liveconfig-meta php5-cgi php5-cli php5-common php5-gd php5-imap php5-json php5-mcrypt php5-mysql php5-readline php5-redis php5-sqlite
The following NEW packages will be installed:
php7.4-cgi
0 upgraded, 1 newly installed, 12 to remove and 0 not upgraded.Aus welchem Grund würde an dieser Stelle das Paket "liveconfig-meta" entfernt werden? Gibt es dort Abhängigkeiten, welche wir vorab auflösen müssen?
Am besten wäre natürlich, wenn man zukünftig die PHP-Varianten ausschließlich über das LiveConfig-Repo beziehen und dort dann eine Standard-Variante bestimmen kann. Letzteres funktioniert ja bereits, allerdings taucht dann die vom Betriebssystem installierte Variante immer noch auf (welche bei Debian prinzipbedingt meist älter ist). Ein "switchen" der Standard-Version über die Oberfläche oder Config-Datei wäre ebenfalls wünschenswert, scheint aber aktuell wohl nur manuell mit SQL-Queries über die Datenbank direkt zu laufen - zumindest soweit ich das im Forum recherchieren konnte.
Leider ist es offenbar so, das es keinen Support und vermutlich keine Weiterentwicklung mehr gibt. CiKa-Software ist nicht mehr erreichbar.
Ist das definitiv oder nur eine Vermutung? Bei telefonischer Kontaktaufnahme bedenken, das die Support-Zeiten recht überschaubar sind (Mo-Do 10-15 Uhr, Fr. 10-14 Uhr, Quelle: https://www.cika-software.de/kontakt/ ). Ansonsten ist die Webseite aber normal erreichbar.
Hallo Herr Keppler,
danke für die Anpassung der Maske, so schaut das schon wesentlich besser und eindeutiger für den Kunden aus! 
Wir überarbeiten die gesamte GUI derzeit (weitere Infos dazu spätestens Anfang Oktober), da können wir sicher noch die eine oder andere Anregung aufnehmen.
Wird es die Möglichkeit geben, die neue GUI vorab zu testen (z.B. auf einem Demo-Server bei Ihnen oder über eine eigene Installation z.B. per Beta-Repository)?