Von dem Tool scheint es einen Container zu geben. Nimm doch den, dann entfällt das komplizierte Setup mit eigenen Paketen, für die es sicherlich einen Grund gibt warum man die nutzen möchte und nicht die etablierten Standard Pakete.
Ansonsten würde ich die Doku zu eigene PHP Pakete empfehlen.
Dann schreibe ich doch gleich noch ein paar Issues fürs lange Wochenende 
Kann ich eigentlich die aktuelle LC2 Datenbank auf dem LC3 Server nutzen, ohne dass die ganzen Clients angebunden sind?
Also nur die DB kopieren und dann mit realistischeren Daten meine API Anbindung testen?
Brute Force ist jetzt nicht unbedingt eine Lücke...
Wenn man die Zugangsdaten hat, dann hat man "legitimen" Zugriff auf das Mail System.
Hier hilft dann sowas wie fail2ban oder sshguard gegen zu häufige Anmeldeversuche.
Anhand des Log Auszugs kann ich nichts erkennen.
Im Prinzip müsste man die Queue prüfen wo die Mails her kommen, also von welchem Kunden oder ob die von z.B. PHP versendet werden.
cd /var/spool/postfix
find active bounce deferred incoming maildrop -type f | wc -lWenn hier irgendwas größer 10 raus kommt, dann würde ich anfangen die Queue zu prüfen.
Um danach zumindest mal den permanenten Versand zu beenden, könnte man temporär die Mailserver stoppen.
Dann fängt die Suche nach dem Versender innerhalb des Systems an.
Ich habe mal angefangen den öffentlichen Bugtracker im Github mit einigen Punkten zu füllen. Vielleicht finden sich ja noch mehr Leute die mitmachen.
Generell funktioniert die API Schnittstelle sehr gut und der Fortschritt von LC3 in den letzten Wochen ist deutlich spürbar.
Ganz ehrlich, es nervt inzwischen etwas. Lass doch das gemaule bitte. So schlecht ist LiveConfig nicht und ich bin SysAdmin weil ich nicht für alles eine GUI benötige. Ja es gibt teilweise echt Handlungsbedarf, aber manche Sachen kann ich auch händisch machen. Oder in Zukunft über die LC3 API.
mal probiert die Seriennummer der Domains zu erhöhen?
Damit sollte doch die Zone komplett neu geschrieben werden.
Und was sagen die Logs ist da evtl. noch ein Fehler zu finden?
Ich habe die Zonen vor einigen Jahren mal neu geschrieben, als bei OVH das RZ abgebrannt ist und einer meiner Secondary dort stand.
Aber das war ein Umzug von Debian nach Debian und es gab eigentlich nur ein Problem, dass irgendein Sync nicht funktioniert hat und sich die IP-Adressen geändert haben. Ich erinnere mich nicht mehr ganz genau daran.
Ich meine, dass LiveConfig die Zonen auch komplett neu erstellt und kein Backup vom Secondary dafür benötigt.
Wie wenn man einen weiteren Nameserver hinzufügt, der wird ja auch komplett neu beschrieben.
Folgende Infos habe ich noch von damals:
>> Vorab schonmal: den Ersatz-Server installierst Du bitte einfach "ganz normal"
>> (also frisch aufsetzen). Da dann den lcclient installieren und mit der Host-ID des
>> "alten" lcclient ins LiveConfig einbinden (also nicht als neuen Server, sondern
>> als Ersatz für den alten).
>1.) wenn BIND und lcclient auf dem "neuen" Secondary laufen, auf
> Serververwaltung -> (Server wählen) -> DNS gehen, und dort die
> Konfiguration (IP-Adressen) anpassen und abspeichern
> (damit werden die relevanten Konfigurationsdateien neu geschrieben)
>
>2.) danach folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:
>
> update NAMESERVERS set NS_UPDATEKEYS=1;
>
> Anschließend LiveConfig (auf dem Master-Server) neu starten.
> Kurz danach sollten die TSIG-Schlüssel neu geschrieben werden
> (/etc/bind/keys.liveconfig - sowohl auf dem Primary DNS als auch auf dem
> Secondary)
> Wichtig ist, dass beim Master in keys.liveconfig nun die neue IP des
> Secondaries drin steht.
>3.) Wenn soweit alles geklappt hat, den LiveConfig-Server auf v2.11.3 aktualisieren (aktuelle Preview, die Clients können auf 2.11.2 bleiben)
>
>4.) Danach das DNS-Template bearbeiten und den betroffenen Secondary aus dem
> Template *entfernen*.
>
>5.) einen Moment warten, bis die Jobs abgearbeitet sind.
>
>6.) Danach das DNS-Template erneut bearbeiten, und den Secondary wieder aufnehmen.
>
> Die Zonen sollten dann in /etc/bind/zones.liveconfig auftauchen.
>In /var/log/liveconfig/liveconfig.log (Master) bitte prüfen, ob es Fehlermeldungen bei einzelnen Domains gibt.
>In Einzelfällen hilft es, die jeweilige Domain mal kurz auf "externen DNS-Server" zu schalten und danach wieder zurück (damit wird die komplett neu im DNS konfiguriert). Sollte es mehrere Probleme geben, melde Dich bitte.
>
Gefühlt sollte es noch immer so funktionieren.
Nur eben den Punkt 3 überspringen, der sollte nicht mehr ganz aktuell sein 
Per default ist bei dir die PHP Version von Debian aktiv.
Und dort wirst du auch keinen ioncube installiert haben.
Tausche mal die PHP Version im LiveConfig auf die andere 8.2.
Dann wird es vermutlich funktionieren.
Also nicht falsch verstehen... aber WHMCS benutzen und damit faktisch irgendwas mit Domains, Hosting, Server machen zu wollen und dann ein einfaches PHP Programm nicht zum laufen bekommen. Bitte überdenkt nochmal den Plan.
Zum Problem:
Sicher, dass die richtige PHP Version ausgewählt ist im LiveConfig?
Wurde auch LiveConfig nach dem installieren einmal neu gestartet?
Ansonsten wird ioncube nicht geladen.
Was auch hilft wäre eine Ausgabe von liveconfig --diag
Ich kenne leider keine entsprechende Übersicht.
Wäre mal ein Vorschlag für die Heise Redaktion, dass sie daraus einen Artikel machen.
Bei den meisten Anbietern die (meiner Meinung nach) eine richtig hohe Qualität anbieten, ist das Problem, dass Sie nach Postfächern oder Domains abrechnen. Und dann auch noch irgendwelche kruden Vertragsbedingungen mit rein verknüpfen, dass es bei allen Postfächern auf dem Server identisch sein muss. Was dann bei Shared Hosting eher keinen Sinn macht, wenn ich für jedes Postfach ~ 0,50€ für den SPAM Filter zahlen muss.
Was ich aus dem Kopf raus an Listen kenne:
Barracuda Anti-Spam
Securepoint
SPAMHAUS
Abusix
mcgrail / KAM
Heinlein
Schaal-IT
Spamcop
SORBS
Wir nutzen https://abusix.com/, allerdings kostenpflichtig, mit sehr guten Ergebnissen.
Welche Listen verwendet ihr von Abusix?
Combined und SPAM Blocklist, oder noch mehr?
Wir verwenden von SPAMHAUS DQS und Hashblocklist. Zusammen mit NixSPAM war es eine ganz gute Kombination.
Mist, dabei war die echt gut und hat gerade den D/A/CH Raum echt gut abgedeckt.
Sehr schade, aber auch sehr verständliche Argument.
Plan B wäre Power Automate zu nutzen.
Aus Erfahrung ist das durchaus auch mal ein schneller weg etwas zu ändern.
Völlig ins blaue geraten (wirklich geraten!!!).
Umstellung per DB machen und dann einmal die IP Gruppen unter DNS aktualisieren.
Meistens, in der LiveConfig Welt, ist es so, dass er mit einer Aktualisierung der IP Gruppen, alle Konfigurationen neu schreibt.
Man könnte es ja mal mit einer Domain testen 
Also ehrlich gesagt kenne ich das Problem nicht und es gibt genau 0 Tickets in den letzten Jahren dazu.
Wir stecken aber auch extrem viel Arbeit in die SPAM Filter rein und fahren die gleiche harte Nummer bei Mail Empfang wie die geliebten gratis Mailbox Mitbewerber.
Dadurch gibt es kaum SPAM-Verdacht Mails und es braucht auch keinen SPAM Ordner.
Bitte nicht als Kritik verstehen, sondern als Anregung ob man das Problem Anderweitig lösen könnte.
Was hat das jetzt damit zu tun?
Ransomware kann jeden von uns treffen.
Egal ob die Daten auf einem Server liegen oder lokal auf einem PC.
Wenn ich mich mit Hosting beschäftige, dann sollte doch ein eigener Server für solch wichtige Daten kein Problem darstellen.
Es muss ja nicht immer die Cloud sein. Manchmal reicht auch noch ein guter einfacher Server mit einem Betriebssystem seiner Wahl.
Naja... gSales erstellt ja nur Rechnungen und verwaltet die Kundendaten und Verträge. Aber irgendwie muss ja eine Buchhaltung, Lohn, Steuer, etc. gemacht werden.
Hi,
das Thema ist durchaus kompliziert und nicht einfach...
Und egal für welches Programm man sich entscheidet, es kostet viel Zeit und viel Fummelei bis alles passt
Alternativen (Reihenfolge wertungsfrei und was ich im Kopf habe):
gSales
hostbill
WHMCS
upmind.com
blesta
FOSSBilling (OpenSource)
Ein schneller Dirty Fix:
mkdir /etc/apache2/suexec
nano /etc/apache2/suexec/www-data/var/www
public_html/cgi-bin
# The first two lines contain the suexec document root and the suexec userdir
# suffix. If one of them is disabled by prepending a # character, suexec will
# refuse the corresponding type of request.
# This config file is only used by the apache2-suexec-custom package. See the
# suexec man page included in the package for more details.Ich kenne das verhalten ebenfalls von Server Umzügen, habe es aber bisher nicht analysiert.
Apache neu starten nicht vergessen.
z.B. htt ps://mein.server.xyyz/webmail (ohne leerzeichen)
Eben den Link vom installierten Webmail eintragen, welcher auch immer (roundcube, etc).