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.
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 | shAuf dem Server befindet sich jetzt allerdings LiveConfig 3. Laut Herrn Keppler wird Liveconfig 3 aber mit folgendem Aufruf installiert:
wget -O- https://install.liveconfig.com/lc3 | shDie 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?
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.