Beiträge von mjk

Auch ich möchte mich bei Herrn Keppler und seinem Team nochmals bedanken! Eine solche Bandbreite an PHP-Versionen in so kurzer Zeit zu aktualisieren, ist keine Selbstverständlichkeit. Ich selbst hatte vor einigen Tagen erst hier im Forum ein Posting verfasst, in dem es um die Deaktivierung alter PHP-Versionen ging und angefragt, wie man dies ohne direkten Zugriff auf die Datenbank lösen könnte. Exemplarisch möchte ich die Problematik einmal an nur einem einzelnen unserer Server aufzeigen:

Die Kunden haben dort aktuell nur die Wahl zwischen dem Standard PHP 8.4.27 (Debian 13 Pakete) und dem optionalen PHP 5.6.40 für den Übergang bis zum Jahresende, danach wäre dies endgültig deaktiviert worden. Im Laufe der Jahre sind aber die php-opt Pakete angewachsen - Debian Trixie bietet aktuell PHP 8.4, es gibt bereits php-opt mit Version 8.5 und die Version 8.6 steht schon in den Startlöchern. Und so sammeln sich im Laufe der Zeit immer mehr Domain-Konfigurationen breit gestreut auf alle PHP-Versionen an. Ja, man könnte in der LiveConfig-Datenbank auslesen, welche Version von welchem Kunden genutzt wird, diesen informieren und nach Ablauf einer Frist die Domains manuell umschalten. Wünschenswerter wäre mir aber, man versendet einen Newsletter mit dem Hinweis: "PHP 7.4.33 wird am 31.12.2026 deaktiviert". Die Kunden haben bis dahin die Möglichkeit, eine andere Version zu wählen und nach Ablauf wird das Paket entfernt. Jede noch darauf konfigurierte Domain wird im Anschluss automatisch auf die Standard-Version gesetzt.

Die Situation wie im Screenshot zu sehen hat gestern leider dazu geführt, das man entweder den Webserver so lange offline halten musste bis alle PHP-Versionen aktualisiert werden konnten - oder man hätte einen Weg finden müssen, um einzelne PHP-Versionen zu blockieren. In jedem Fall bin ich gespannt darauf, welche neuen Optionen diesbezüglich integriert werden

PHP 5.6.50-24

ii  php-5.6-opt                        1:5.6.40-24+deb13u1

Vermutlich ein Vertipper auf der Blog-Seite?

Ich klinke mich hier mal mit ein. Wir stehen vor einigen Server-Updates und wollen in diesem Zusammenhang auch bei den PHP-Versionen etwas aufräumen. Weder in der LiveConfig 3 Demo noch in der neuen REST-API habe ich eine Option gefunden, um bei mehreren Domains/Subdomains die PHP-Version in einem Rutsch neu zu setzen.

Zu LC2 gab es einen separaten Topic, wie man die Änderungen direkt in der LC-Datenbank ausführen kann:

Thema

Massenänderung PHP-Version

Ich verwende Liveconfig in einem Projekt nur für mich als "Verwaltungserleicherungstool", Kunden haben da keinen Zugriff drauf.

Nun will ich bei diesem Projekt die PHP-Version ändern und stehe vor einem Problem: wie mache ich das massenhaft und nicht nur bei einzelnen Domains. Alle Domains (es sind mehrere 100) durchzuklicken und von Hand zu ändern kann doch eigentlich nicht die Lösung sein? In der API gibt es aber, wenn ich nichts übersehen habe, auch nichts passendes.

Wie macht man das also am…

mhagge

7. Dezember 2016

Wenn es aber mittlerweile einen "offiziellen Weg" gibt, würden wir diesen bevorzugen (und in diesem Zusammenhang während des Updates auch direkt auf LC3 wechseln). Es braucht in jedem Fall zukünftig eine Option um z.B. zu sagen, alle Domains die derzeit das PHP 7.x Opt-Paket nutzen, sollen nun auf das PHP 8.x Opt-Paket umgestellt werden. Falls im Frontend nicht möglich, dann als Batch-Job über die REST-API. Habe ich etwas übersehen oder gibt es diese Optionen derzeit noch nicht?

Grunddaten:

LiveConfig Business-Lizenz, dazu ein Webserver und ein Datenbankserver als LiveConfig-Client. Kunde möchte Wordpress über den App-Installer installieren.

Fehler:

Die Anwendung taucht beim Kunden im Menü auf, mit Status "Installation läuft...". Die Datenbank ist angelegt, hat aber scheinbar noch keine Inhalte. Das "apps"-Verzeichnis im Kunden-Hauptordner wurde noch nicht angelegt.

Auszüge aus den Logs:

/var/log/liveconfig/lcclient.log (Webserver)

[2025/10/03 15:12:30.794027] [1867763|1867763] Connecting to x.x.x.x ...
[2025/10/03 15:12:30.794294] [1867763|1867763] Connection established - waiting for SSL sequence from Server
[2025/10/03 15:12:30.846474] [1867763|1867763] Connected to LiveConfig 2.18.7
[2025/10/03 20:30:50.540877] [1867763|1867764] Downloading app installer from 'https://update.liveconfig.com/repo-v3.json'
[2025/10/03 20:30:50.574418] [1867763|1867764] Requesting installer file '/wai-wordpress-6.8.2-1.php.gz'...
[2025/10/03 20:31:00.188849] [1867763|1867766] wai-wordpress-6.8.2-1.php: 2025-10-03 20:31:00 URL:http://download.liveconfig.com/cache/wordpress-6.8.2-de_DE.tar.gz [34198757/34198757] -> "/var/cache/liveconfig/downloads/wordpress-6.8.2-de_DE.tar.gz" [1]

ls -lh /var/cache/liveconfig/downloads/wordpress-6.8.2-de_DE.tar.gz

-rw-r--r-- 1 liveconfig liveconfig 33M Jul 15 19:19 /var/cache/liveconfig/downloads/wordpress-6.8.2-de_DE.tar.gz

ls -lh /var/cache/liveconfig/installer/wai-wordpress-6.8.2-1.php

-rw-r--r-- 1 root root 12K Oct  3 20:30 /var/cache/liveconfig/installer/wai-wordpress-6.8.2-1.php

Nach einem Neustart des Servers mit der Business-Lizenz und dem lcclient auf dem Webserver steht der Status der Anwendung nun auf "Fehler" und der Button "Anwendung löschen" erscheint. In den Logs befinden sich keine neuen Einträge. Gibt es noch andere Stellen, um die Fehlerursache einzugrenzen und prüfen zu können?

Hallo,

wir hatten heute den Fall, das wir von einem auf ein anderes Debian 12 System einen Transfer des LiveConfig-Systems mit den vorhandenen Daten durchgeführt haben. Hilfreich hierbei waren die folgenden beiden Links:

Beitrag

RE: Migration LiveConfig -> Liveconfig

Hallo,

ich gehe davon aus, dass der neue Server "frisch" ist (d.h. dass dort noch keine Accounts mit LiveConfig angelegt wurden etc.), und dass es sich um die selbe Distribution und Version wie beim alten Server handelt?
Dann gehen Sie bitte wie folgt vor:

• kopieren Sie zuerst /etc/passwd, /etc/shadow und /etc/group vom alten Server auf den neuen Server
• installieren Sie anschließend LiveConfig und alle benötigten Pakete auf dem neuen Server (z.B. "aptitude install liveconfig-meta liveconfig")
• beenden

…

kk

21. November 2012

https://www.liveconfig.com/de/kb/server-wechseln/

Diese sind aber bereits älter und insbesondere gab es LiveConfig 3 zu diesem Zeitpunkt noch nicht. Wir haben beide Systeme auf den aktuellsten Versionsstand aktualisiert und anschliessend zunächst auf dem Zielsystem das "liveconfig-meta" Paket installiert. Dieses installiert auf einem Debian 12 System automatisch LiveConfig 3 mit. Zunächst haben wir daher alle übrigen Daten kopiert, auch solche aus /etc/liveconfig. Beim Start von LiveConfig 3 erhielten wir aber am Ende immer den Fehler, dass das Zertifikat aus /etc/liveconfig/sslcert.pem nicht gelesen werden konnte. Daher haben wir per "apt install liveconfig" die Version 2 manuell installiert, Liveconfig 3 wurde dabei entfernt. Die Pakete aus dem Meta-Paket haben wir anschließend manuell per apt nachinstalliert, damit diese bei einem autoremove nicht entfernt werden.

Insgesamt ist es hilfreich, vorab alle php / php-opt Versionen auf dem Zielsystem identisch zum Quellserver zu installieren, damit die PHP-Zuordnungen erhalten bleiben. Apache2 machte bei dem Wechsel am meisten Probleme, alle anderen Dienste liefen auf Anhieb. Insbesondere ist die Übernahme der Liveconfig-Daten von Version 2 auf 3 aber dann doch nicht so reibungslos, auch wenn die Datenbank kompatibel zueinander ist.

Zitat von kk

Dann muss da noch mal irgendetwas anderes passiert sein. LiveConfig 2.x und 3.x sind separate Pakete mit unterschiedlichen Namen; das o.g. Script kann nur LiveConfig 2.x installieren.
Auf welcher Distribution (&-Version) haben Sie das ausgeführt? Dann testen wir das gerne mal durch.

Frisch installiertes Debian 12.11 in einer KVM-VM. Außer der bekannten Meta-Package Abfrage und dem Lizenz-Code gab es während der Installation keine weiteren manuellen Eingriffe.

Zitat von bravesurfer

Das kann ich bestätigen war hier nach dem Update für lclogparse, lcpolicyd lcsam und lcbackup genau so.

Bei mir nach der frischen Neuinstallation. Das "Erste Schritte" Fenster macht auch Probleme. Die Option das es zukünftig nicht mehr angezeigt werden soll, ist ausgegraut - in meinem Fall braucht es nicht alle Dienste und Vorlagen, vermutlich bleibt es deshalb inaktiv. Da sollte es generell die Möglichkeit geben, das Fenster zukünftig auszublenden.

Wir haben eben einen neuen Server installiert, wie gewohnt mit dem Installer-Script was wir eigentlich immer für LiveConfig 2 verwenden:

wget -O- https://install.liveconfig.com | sh

Auf dem Server befindet sich jetzt allerdings LiveConfig 3. Laut Herrn Keppler wird Liveconfig 3 aber mit folgendem Aufruf installiert:

Beitrag

RE: Ausblick auf das nächste große Release

Ab sofort sind die Pakete liveconfig3 bzw. lcclient3 in den Repositories verfügbar.

Das Wichtigste vorab: wir verwenden bewusst separate Paketnamen (mit der "3" am Ende), damit niemand versehentlich auf LiveConfig 3.0 aktualisiert. Zu einem späteren Zeitpunkt (wenn LiveConfig 2 abgekündigt wird) werden wir das aber wieder umstellen.

Neu-Installationen mit LiveConfig 3.0 führt man am allereinfachsten mit dem nagelneuen Installationsscript durch:
(Quelltext, 1 Zeile)

Das bisherige Paket …

kk

1. August 2025

wget -O- https://install.liveconfig.com/lc3 | sh

Die URL "https://install.liveconfig.com/lc2" resultiert in einem 404 Error. Ist eine Neuinstallation von LiveConfig 2 per Script nicht mehr möglich?

Edit:

Der "Mail Log Parser" war nach frischer Aktivierung der Maildienste down. "lclogparse starten" bringt auf dem Frontend nur den Fehler "Error while handling request". /var/log/liveconfig/liveconfig.log sagt:

[19790] [2025-08-02 18:08:50.399386] [ERR] Failed to start service unit lclogparse: Unit lclogparse.service is masked.
[19789] [2025-08-02 18:08:50.399626] [ERR] Error while handling request: Unit lclogparse.service is masked.

systemctl status lclogparse
○ lclogparse.service
Loaded: masked (Reason: Unit lclogparse.service is masked.)
Active: inactive (dead)


systemctl unmask lclogparse
Removed "/etc/systemd/system/lclogparse.service".

Danach lässt sich der Dienst starten.

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?

Zitat von antondollmaier

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?

Zitat von flo4545

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.

Zitat von flo4545

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

Zitat von flo4545

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.

Zitat von taenzerme

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.

Zitat von taenzerme

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.

Zitat von taenzerme

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.

Zitat von flo4545

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.

Zitat von flo4545

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.

Zitat von flo4545

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?

Zitat von flo4545

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.

Zitat von taenzerme

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.

Zitat von kk

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.

Zitat von weltmeister

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.

Zitat von taenzerme

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.

Zitat von taenzerme

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?

Zitat von flo4545

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.

Zitat von flo4545

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.