Beiträge von RipClaw

Zitat von antondollmaier

Ist da ein Reseller in der Kette deaktiviert worden?

Ich bin mit dem Fall vertraut. Es ist kein Reseller deaktivert in der Kette. Der Reseller wurde direkt von admin angelegt.

Ich habe mir auch die SQL Abfrage angesehen und dort gibt es Werte mit denen ich nichts anfragen kann. Es sind die Felder CUST_IDLEFT und CUST_IDRIGHT

Es werden beim Login folgende Abfragen durchgeführt:

SELECT U_ID, U_PASSWORD, U_OTPTYPE, U_OTPSECRET, U_2FA, U_SOAPTOKEN, U_CUSTOMERID, U_LOCKED, U_LANGUAGE, U_TEMPLATE, U_TIMEZONE, CUST_IDLEFT, CUST_IDRIGHT, CUST_LOCKED FROM USERS, CUSTOMERS WHERE U_CUSTOMERID = CUST_ID AND U_LOGIN = ? AND U_DELETED = 0

und

SELECT CUST_ID, CUST_LOCKED FROM CUSTOMERS WHERE CUST_IDLEFT < ? AND CUST_IDRIGHT > ? AND CUST_LOCKED > 0 ORDER BY CUST_IDLEVEL DESC

Die erste Abfrage prüft den Benutzernamen ab das sollte kein Negatives Ergebnis zurück liefern. Bei der zweiten Abfrage bin ich mir nicht sicher was zurück geliefert wird da ich nicht weiß was abgefragt wird.

Scheinbar hat Manitu inzwischen die Notbremse gezogen und wieder umgeschaltet.

Ich habe gesehen das in dem KB Artikel "Spam-Filterung verbessern" die DNS-Blocklist noch aufgeführt ist.

Hallo,

mir ist gerade aufgefallen das für Debian 11 kein PHP 8.4 im Repository vorhanden ist obwohl das laut Wiki da sein müsste. Kommt das noch oder gibt es da Probleme ?

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.

Vermutlich ist das einzige was man machen kann ist auf einer Testinstanz ein neues Liveconfig zu installieren und von dort die liveconfig.db zu kopieren.

Ich habe da noch keine Migration zurück zu SQLite gemacht. Das war nur eine generelle Frage.

Die liveconfig.db wird nach einer Umstellung auf MySQL nicht mehr beschrieben aber sie ist nicht komplett leer. Da sind von der Installation bis zum dem Zeitpunkt der Umstellung auf MySQL noch die Daten vorhanden. Man müsste eine Kopie machen und die Tabellen leeren aber die Struktur beibehalten.

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

Error 503: Service Unavailable

An error occured while processing your request: FOREIGN KEY constraint failed

Der Dienst lcbackup läuft.

systemctl status lcbackup

● lcbackup.service - LiveConfig Backup Daemon
     Loaded: loaded (/etc/systemd/system/lcbackup.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-07-17 11:31:32 CEST; 17min ago
    Process: 1812111 ExecStart=/usr/lib/liveconfig/lcbackup -d (code=exited, status=0/SUCCESS)
   Main PID: 1812115 (lcbackup)
      Tasks: 1 (limit: 38346)
     Memory: 1.7M
        CPU: 27ms
     CGroup: /system.slice/lcbackup.service
             └─1812115 /usr/lib/liveconfig/lcbackup -d

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

Ich hätte da zwei Fragen.

Wäre es theoretisch eigentlich möglich die Datenbank wieder zurück von MySQL auf SQLite zu migrieren ?

Und gibt es ein Archiv mit alten Liveconfig Versionen gibt falls man Probleme mit einem Upgrade hat und wieder auf einen alten Stand zurück will?

Zitat von kk

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.

Danke mit der aktuellen Preview klappt es

Zitat von kk

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.

Zitat von arnoldB

Siehe auch http://www.liveconfig.com/de/forum/threads/579-Apache-httpd-default-vHost-aktivieren-und-NOUPDATE-Funktionalität

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.

MY = {}


LC.dovecot = require("dovecot")


MY.dovecot = {}
MY.dovecot.configure = LC.dovecot.configure


function LC.dovecot.configure(cfg, opts)
    local configpath  = cfg['configpath']
    local configfile  = cfg['configfile']


    local rv = MY.dovecot.configure(cfg,opts)


    if rv == false then
        return rv
    else
        fh, msg = io.open(configfile, "a")
        fh:write("!include_try local.conf\n")
        fh:close()
    end


    return rv
end

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

!include_try local.conf

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

Liveconfig ist anfällig in Bezug auf den heartbleed Bug von openssl.

Das System selbst ist bereits gepatcht aber ein Test zeigt das der Liveconfig Admin Server noch anfällig ist.
Daher vermute ich das openssl statisch gegen Liveconfig gelinkt ist.

Zitat von webby

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.

Zitat von Snck3rs

Und ich dachte ich wäre zu doof bei mir kann der Dovecot-Server auch in der neuesten Version gar nicht gestartet werden

Das Problem lässt sich ganz einfach lösen:

apt-get install dovecot-imapd