Posts by TCRserver

    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.

    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:


    Code
    mkdir /etc/apache2/suexec
    nano /etc/apache2/suexec/www-data
    Code
    /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.

    Welchen Vorteil hat eigentlich die 11 mariadb Version ggü. der 10er Reihe beim Hosting?

    Für so typische Dinge wie WordPress, phpBB, usw. sehe ich nicht direkt einen Vorteil, da reicht doch die Distri Version vollständig aus.

    Oder habe ich da irgendeinen Kniff übersehen bzw. nicht bedacht?

    Wir nutzen eine Mischung aus Lexoffice für die Buchhaltung und hostbill als Shopping System und jede Menge selbstgebauter Middleware. Aber wirklich der Knaller ist das System nicht. Eigentlich war gSales eine tolle Sache und mit Version 2 auch echt brauchbar, aber irgendwie hat es sich dann doch nicht bei uns durchgesetzt.


    Software kostet halt Geld, vor allem wenn es in Deutschland entwickelt wurde und auch noch sauber mit Steuer und Co. funktionieren soll.
    Das sollte man immer bedenken. Und 20 € pro Monat in der Selbsthosting Variante... Daran soll es nicht scheitern oder?

    Das müsst ihr mal genauer erklären?

    LC kann doch nichts dafür, wenn ihr Daten hin und her kopiert und das Zeit braucht.

    Ja man muss manuell eingreifen in die DB und Daten via rsync verschieben.

    Aber das sind 9 Kommandos auf der Shell für Hosting & DB und nochmal 4 für die Postfächer.

    Ja man kann es automatisieren und das Panel könnte es mitbringen, aber im Endeffekt macht genau das mein Job aus.

    Und ganz ehrlich... Manchmal macht es auch Spaß ein kleines Skript oder Tool zu schrieben welches man in seiner Helferlein Kiste packt.


    Oder verstehe ich euch gerade nicht?

    /etc/logrotate.d/clamav-milter

    Code
    /var/log/clamav/clamav-milter.log {
         rotate 12
         weekly
         compress
         delaycompress
         create 640  clamav adm
         postrotate
         invoke-rc.d clamav-milter restart > /dev/null || true
         endscript
         }


    /etc/logrotate.d/liveconfig


    Bitte mäßigt doch den Ton bei solchen "nicht" Reaktionen. Das ist nicht nett...
    Vor allem wenn man anscheinend keinen Plan von LC und den aktuellen Problemen hat.


    Zu dem ganzen Problem:


    LC 2.14.4
    Beim erstellen eines manuellen Backups über die Backup BETA Funktion von LC kommt folgende Fehlermeldung:


    An error occured while processing your request: mysql_stmt_execute: (1452) Cannot add or update a child row: a foreign key constraint fails (`LIVECONFIG`.`BACKUPS`, CONSTRAINT `BACKUPS_ibfk_3` FOREIGN KEY (`B_PLANID`) REFERENCES `BACKUPPLANS` (`BP_ID`) ON DELETE SET NULL)


    Dass es hier einen Fehler im Query bzw. der DB Struktur gibt, ist klar.
    Auch ich kann einen SQL Query lesen und interpretieren.


    Ich vermute, dass es einen Zusammenhang mit den DB Struktur Updates gibt. Hab mich aber auch nicht darum gekümmert, da die Funktion zum einen BETA ist und zum anderen von mir nicht genutzt wird. Aber ja der BUG existiert aktuell in LC.


    Nachtrag:


    Logfile Eintrag

    Quote

    [2022/10/21 15:00:34.935544] [14902|14903] ERROR: Releasing db connection, but still have open statements
    [2022/10/21 15:00:34.935599] [14902|14903] aborting SQL: 'INSERT INTO BACKUPS ( B_CONTRACTID, B_CREATED, B_USERID, B_PLANID, B_NOTIFY, B_NOTIFYADDR) VALUES ( ?, ?, ?, ?, ?, ?)'
    [2022/10/21 15:00:34.935876] [14902|14903] Database Exception: mysql_stmt_execute: (1452) Cannot add or update a child row: a foreign key constraint fails (`LIVECONFIG`.`BACKUPS`, CONSTRAINT `BACKUPS_ibfk_3` FOREIGN KEY (`B_PLANID`) REFERENCES `BACKUPPLANS` (`BP_ID`) ON DELETE SET NULL) (SQL: INSERT INTO BACKUPS ( B_CONTRACTID, B_CREATED, B_USERID, B_PLANID, B_NOTIFY, B_NOTIFYADDR) VALUES ( ?, ?, ?, ?, ?, ?))

    Ok, es ist genau umgekehrt.
    LC bringt die mbstring Extension mit, aber in der Standard Server Version ist es auf einem blanko System nicht installiert.
    Und der Updater nimmt eben nur den Aufruf php und nicht /opt/php-x.x/bin/php was zu einer LC-PHP Version führt.


    Lösung (Ubuntu/Debian): apt install php-mbstring


    Damit sollte es funktionieren.

    php_mbstring ist meines Wissens nach nicht in den LC PHP Versionen mit dabei.
    Wäre aber eine gute Sache wenn das mit rein kommen würde. Ich stolpere immer wieder über Anwendungen die mbstring benötigen.
    Und wenn roundcube es jetzt als Voraussetzung mit bringt, dann wäre es ein Argument mehr um es mit auf zu nehmen.


    Ich aktualisiere im Lauf des Tages mal eine Instanz von mir, dann kann ich es testen.

    Das passiert häufig, wenn man gleichzeitig ein MariaDB Update macht. Dann ist der DB Server noch nicht wieder online, während LC das Update macht und versucht auf die Datenbank zu zu greifen. (Nur relevant wenn man MySQL/MariaDB für die LC Datenbank benutzt)
    Den Fall hatten wir zumindest vor einigen Tagen mal wieder.