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.
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
Display More
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?
Folgende Schemaänderungen werden von 2.16.0-3 auf 2.16.0-4 ausgeführt:
CodeALTER 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
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.
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
Display More
Dieser Code macht nichts anderes als an die dovecot.conf folgenden Eintrag anzuhängen:
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.
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.
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
Danke. Ich hatte nicht so schnell mit einer Antwort gerechnet.
Das wäre meine Diagnoseausgabe gewesen aber das hat sich ja erübrigt
INTERFACES:
Name: 'lo'
MAC: 00:00:00:00:00:00
IPv4: '127.0.0.1'/8
IPv6: '::1'/128
IN: 23654 bytes (204 packets)
OUT: 23654 bytes (204 packets)
FLAGS: UP LOOPBACK
Name: 'venet0'
IPv4: '127.0.0.1'/32
IN: 87511116 bytes (63150 packets)
OUT: 3451962 bytes (36513 packets)
FLAGS: UP BROADCAST NOARP
Name: 'venet0:0'
IPv4: '172.17.2.159'/32
FLAGS: UP BROADCAST NOARP
HOSTNAME:
Hostname: 'liveconfig'
FQDN: 'liveconfig.xxxxx.xxx'
UPTIME:
Uptime: 8 days, 23:43:32
DMI:
ERROR: open(/dev/mem) failed: Operation not permitted
IPMI:
ERROR: IPMI not supported in this build
[INFO] Detected 'Debian GNU/Linux 6.0.1'
Diagnostics ready!
Display More
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:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:204 errors:0 dropped:0 overruns:0 frame:0
TX packets:204 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23654 (23.0 KiB) TX bytes:23654 (23.0 KiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:63150 errors:0 dropped:0 overruns:0 frame:0
TX packets:36513 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:87511116 (83.4 MiB) TX bytes:3451962 (3.2 MiB)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.17.2.159 P-t-P:172.17.2.159 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
Display More
Hier nochmal mit dem Befehl "ip addr list":
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.