Posts by RipClaw

    Auf den ersten Blick scheint die Struktur ok zu sein. Ich habe es mit einem brandneuen Liveconfig verglichen.

    Wenn ich manuell die Daten in einer Kopie der Datenbank eintrage dann wirft SQLite keinerlei Fehler.

    Hallo. Ich habe folgendes Problem. Nach einem Umzug auf einen neuen Server funktioniert das Backup nicht mehr. Ich bekomme folgende Meldung:

    Code
    Error 503: Service Unavailable
    
    An error occured while processing your request: FOREIGN KEY constraint failed


    Der Dienst lcbackup läuft.


    Hat jemand eine Idee was es sein könnte ? Die Berechtigung Backups zu erstellen ist im Vertrag aktiv.

    Folgende Schemaänderungen werden von 2.16.0-3 auf 2.16.0-4 ausgeführt:

    Code
    ALTER TABLE HOSTINGPLANS ADD HP_MAILLIMIT_HOUR INTEGER DEFAULT -1 NOT NULL;
    ALTER TABLE HOSTINGCONTRACTS ADD HC_MAILLIMIT_HOUR INTEGER;
    ALTER TABLE MAILBOXES ADD MB_LIMIT_HOUR INTEGER;
    ALTER TABLE MAILBOXES ADD MB_LIMIT_STATUS TINYINT UNSIGNED DEFAULT 0 NOT NULL;
    ALTER TABLE MAILBOXES ADD MB_LIMIT_LASTBLOCKED DATETIME;
    ALTER TABLE MAILBOXES ADD MB_LIMIT_BLOCKCOUNT INTEGER UNSIGNED DEFAULT 0 NOT NULL;
    ALTER TABLE MAILSERVERS ADD MS_HIDE_SENDER_IP TINYINT UNSIGNED DEFAULT 0 NOT NULL;


    Danke für die schnelle Reaktion und die Informationen. Zum Glück wurde auf dem Server an diesem Tag nichts gemacht. Daher konnte ich mit dem Backup von der Nacht vorher das Problem beheben.

    Es gibt ein Problem das auftreten kann wenn man Liveconfig auf Version 2.16.0 aktualisiert auf Servern mit Liveconfig in einer MySQL Datenbank und die von Debian 8 an per Dist-Upgrade aktualisiert wurden.


    Hier in diesem Beispiel ist aktuell Debian 10 installiert.


    Wenn Liveconfig startet will es die Datenbankstruktur aktualisieren und bringt dann folgende Meldung:


    [2023/05/30 17:55:55.177138] [11214|11214] Upgrading database schema (r216001 -> 2.16.0-2)
    [2023/05/30 17:55:55.187047] [11214|11214] Upgrading database schema (r216002 -> 2.16.0-3)
    [2023/05/30 17:55:55.199261] [11214|11214] Upgrading database schema (r216003 -> 2.16.0-4)
    [2023/05/30 17:55:55.219040] [11214|11214] Database connection failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs


    Wenn man die Datenbank aus einem Backup einspielt kann das Upgrade erfolgreich durchgeführt werden da die InnoDB Struktur der von MariaDB 10.3 entspricht. Leider hilft es nichts die halb aktualisierte Datenbank zu sichern und neu einzuspielen da dann folgender Fehler kommt wenn man Liveconfig starten möchte:


    [2023/05/30 18:00:11.440416] [12549|12549] Database connection failed: Duplicate column name 'HP_MAILLIMIT_HOUR'


    Anscheinend wird das Upgrad auf die Struktur r216004 nur halb durchgeführt aber die entsprechenden Spalten sind schon vorhanden und leider habe ich keine Möglichkeit zu sehen welche Abfragen beim Upgrade von r216003 auf r216004 durchgeführt wurden so das ich die entsprechenden Spalten wieder entfernen kann oder aber den Rest von dem Upgrade auf r216004 manuell durchführen kann.

    Ja, wir haben die Preview eben aktualisiert (v2.14.0-dev20220322.2) - damit sollten alle bislang genannten Datenbankprobleme beseitigt sein.


    Viele Grüße


    -Klaus Keppler


    Ich habe gerade den gleichen Fehler bei einem frisch installierten Liveconfig. Es sind noch keine Kunden angelegt aber wenn ich via SOAP API die Funktion CustomerAdd ausführe dann stehen im Log folgende Fehler:


    [2022/06/28 14:37:28.226034] [14519|14521] ERROR: Releasing db connection, but still have open statements
    [2022/06/28 14:37:28.226065] [14519|14521] aborting SQL: 'INSERT INTO LOG ( LOG_LEVEL, LOG_CUSTOMERID, LOG_USERID, LOG_REALUSERID, LOG_TIMESTAMP, LOG_MODULEID, LOG_EVENTID, LOG_MESSAGE, LOG_DATA) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?)'
    [2022/06/28 14:37:28.226109] [14519|14521] aborting SQL: 'SELECT CUST_ID, CUST_CID FROM CUSTOMERS WHERE ( ( ( ( ( ( ( ( ( CUST_ADMIN_C = ? ) AND ( CUST_CID = ? ) ) AND ( CUST_CRYPTOSALT = ? ) ) AND ( CUST_IDLEFT = ? ) ) AND ( CUST_IDLEVEL = ? ) ) AND ( CUST_IDRIGHT = ? ) ) AND ( CUST_LOCKED = ? ) ) AND ( CUST_OWNER = ? ) ) AND ( CUST_OWNER_C = ? ) )'
    [2022/06/28 14:37:28.226147] [14519|14521] ERROR: Releasing db connection, but still have running transaction (-> forcing ROLLBACK)
    [2022/06/28 14:37:28.226452] [14519|14521] Database Exception: Database Error: mysql_stmt_execute: (1452) Cannot add or update a child row: a foreign key constraint fails (`liveconfig`.`LOG`, CONSTRAINT `LOG_ibfk_2` FOREIGN KEY (`LOG_USERID`) REFERENCES `USERS` (`U_ID`) ON DELETE SET NULL) (SQL: INSERT INTO LOG ( LOG_LEVEL, LOG_CUSTOMERID, LOG_USERID, LOG_REALUSERID, LOG_TIMESTAMP, LOG_MODULEID, LOG_EVENTID, LOG_MESSAGE, LOG_DATA) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?))

    Ich habe heute bei einem Kunden, der einen Hostingvertrag mit Groß-/Kleinschreibung erstellt hat, bemerkt das dadurch Probleme entstehen.


    Im Konkreten wollte er den Shellzugriff von nologin auf bash ändern aber Liveconfig hat den usermod Befehl immer den Benutzernamen mit Groß-/Kleinschreibung versucht aber im System wurde der Benutzer nur mit Kleinbuchstaben angelegt so das die Fehlermeldung ausgespuckt wurde das usermod den Benutzer nicht gefunden hat.


    Ob das auch beim Ändern von Passwörtern auftritt kann ich jetzt nicht sagen da ich es noch nicht getestet habe.


    Ich sehe zwei Möglichkeiten das zu beheben. Die erste, und mir liebste, wäre es überhaupt keine Großbuchstaben in den Hostingverträgen mehr zu erlauben. Die zweite wäre es vor dem ausführen von usermod den Benutzernamen in Kleinbuchstaben umzuwandeln.

    Ich habe folgendes Problem. Wenn ich z.B. ein Postfach anlege dann funktioniert das erst nach einem Neustart von liveconfig.


    Wenn ich Liveconfig mit "liveconfig -f" aufrufe dann erscheint unter anderem diese Meldung:


    [SERVER]: LCCP payload too large (1351971 byte) - aborting...
    [SERVER]: Error while parsing LCCP message - aborting...


    Ich vermute das dieses Verhalten erst seit der Version 1.7.5 auftritt.


    Netter Patch aber der muss jedesmal neu aufgespielt werden wenn ein Update von Liveconfig installiert wird, was ich vermeiden wollte.
    Wenn man aber die Funktion in die custom.lua packt bleibt sie unangetastet.


    Zudem ging es mir nicht darum das Liveconfig die dovecot.conf nicht mehr anfasst sondern das ich zusätzliche Konfigurationsoptionen einbringen kann. Konkret sollte ich für einen Serverkunden default_process_limit anpassen, aber gleichzeitig wollte ich dem Kunden die Möglichkeit lassen im Liveconfig Einstellungen an Dovecot vornehmen zu können.

    Dovecot verfügt ab Version 2 über die Konfigurationoption include_try. Damit können Teile der Konfiguration ausgelagert werden.
    Leider nutzt liveconfig diese Möglichkeit nicht so das man hier in der custom.lua etwas nachhelfen muss.


    Mit folgender Funktion in der custom.lua wird an das Ende der dovecot.conf ein Eintrag gesetzt der die local.conf einbindet.



    Dieser Code macht nichts anderes als an die dovecot.conf folgenden Eintrag anzuhängen:


    Code
    !include_try local.conf


    Alles von dem man nicht will das liveconfig es überschreibt kann man jetzt in die local.conf schreiben.

    Kann man nicht beides machen?
    Also zur Laufzeit die gewünschte Konfiguration einspeisen und gleichzeitig die Konfiguration wie gewünscht schreiben jedoch nicht den postfix extra dafür neu starten :)


    Ich nehme an du meinst mit "Postfix neu starten" einfach das Überschreiben der Konfiguration. Einen Restart muß man so oder so beim Postfix hinlegen damit der die neue Konfiguration einliest.


    Man könnte auch folgendes machen. Einen Bereich aussparen in dem eigene Konfigurationseinstellungen unangetastet werden.


    Allerdings nutzt das wenig wenn Liveconfig genau die gleichen Einstellungen anfassen will z.B. smtpd_recipient_restrictions um z.B. Blacklisten zu ändern.


    Ich selber würde sowieso keine Blacklisten direkt in die Konfiguration von Postfix packen sondern das ganze über einen Policy-Daemon abwickeln wie z.B: postfwd. Da ist man viel flexibler.

    Kleine Anmerkung zu dem Thema:


    Für postfix gibt es den Befehl postconf mit dem man einzelne Bereich der Konfiguration ändern kann ohne das gleich die ganze Konfiguration überbügelt werden muß.


    Vielleicht wäre es eine Überlegung dieses Tool zu nutzen statt die Konfiguration direkt zu schreiben.


    z.B. beim aktivieren des Virenscanners reicht dann:


    postconf -e 'smtpd_milters = unix:/var/run/clamav/clamav-milter.ctl'


    Nur Kommentare sind mit dieser Funktion nicht möglich.

    Danke. Ich hatte nicht so schnell mit einer Antwort gerechnet.


    Das wäre meine Diagnoseausgabe gewesen aber das hat sich ja erübrigt :)


    Ich habe liveconfig zum Testen auf einem VServer mit OpenVZ laufen.


    Hier wird leider nicht die IP Adresse erkannt. Vermutlich aufgrund der virtuellen Netzwerkinterfaces.


    So sieht die Ausgabe von ifconfig in dem VServer aus:



    Hier nochmal mit dem Befehl "ip addr list":


    Code
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
        link/void 
        inet 127.0.0.1/32 scope host venet0
        inet 172.17.2.159/32 scope global venet0:0


    Auf einem Virtuozzo Server wird vermutlich das gleiche Problem bestehen da die Netzwerkinterfaces identisch aufgebaut sind.

    Ist eigentlich schon angedacht eine Art Pluginsystem zu machen mit dem Drittanbieter zusätzliche Funktionen in die Weboberfläche integrieren könnten ?


    Ich könnte mir da Funktionen wie z.B. Bestellsysteme für Domains, Zertifikate usw. vorstellen, Abrechnungssysteme oder auch Supportsysteme.


    Ich weiß das es mit der SOAP API umgekehrt geht aber einige Funktionen bringt man besser in der Serveradministrationsoberfläche unter.