Beiträge von weltmeister

Zitat von kk

für PHP 5.6 unter Debian 13 sollte man übrigens Schmerzensgeld verlangen

So sehe ich das auch, aber Sie glauben gar nicht, wie viele Kunden das noch immer nutzen. Eine "zwangsabschaltung" würde mit Kommentaren wie folgt enden: "dann suchen wir uns eben einen anderen Hoster, der das unterstützt." Oder Bewertungen bei Google: "Der Hoster hat meine Webseite geschrottet"... Das ist wie in den Flugzeugen mit den Disketten oder den Faxgeräten in den Behörden - mit den ewig gestrigen braucht man da nicht zu diskutieren.

Zitat von kk

Nein, die Dauer war hier wohl eher zufällig. Mit einem Reload der Seite oder der Tabelle wäre das wohl sofort weg gewesen.

Zum Hintergrund: wenn Sie auf den "löschen"-Button klicken, wird der Lösch-Befehl an den Server gesendet und anschließend wieder die Postfach-Tabelle angezeigt. Da sich das Postfach in Löschung befindet, ist es ausgegraut dargestellt. Wenn dann - irgendwann später - das Postfach tatsächlich gelöscht wurde, dann bekommt das der Browser hier offenbar noch nicht mit und ändert den Status deshalb nicht. Wir haben zwar einen Mechanismus dafür (Websockets + Messagebus), aber es kann sein dass das bisweilen noch nicht ganz rund läuft (z.B. wenn die Events eintreffen bevor die entsprechende Tabelle geladen wurde). Wir haben das bereits auf dem Radar.

Zu Wildcard-Zertifikaten: wie sähe der Anwendungsfall hierfür aus? Es "kostet" ja nichts, jeweils einzelne Zertifikate auszustellen.

Prinzipiell wären Wildcard-Zertifikate mit LC3 realisierbar, vorausgesetzt die betroffene Domain wird auch von LiveConfig im DNS verwaltet.

Besten Dank erst einmal das Sie sich um das Problem kümmern.

zu Punkt 2: was die Kunden konkret vorhaben, kann ich nicht exakt sagen, auch wird das bei Anfragen nicht weiter hinterfragt. Den Tipp mit den Einzelzertifikaten habe ich gegeben, der Kunde war nicht gerade begeistet und hat einen Providerwechsel angekündigt. Warscheinlich gibt es da eine Registrierungsfunktion wo zufällige Subdomains angelegt / erstellt werden. Diese sollten über SSL aufrufbar sein. So verstehe ich das. Bei WP-Multisites ist das ganze auch nicht ganz unwichtig. Auch da kamen schon zig Anfragen nach Wildcard-Zertifikaten.

Zitat von kk

Es existieren noch Objekte in der Datenbank, die mit diesem Kunden verknüpft sind und nicht automatisch mit gelöscht werden können.

Ich vermute, dass es hierbei um End-Verträge eines Resellers geht, und der Reseller selbst gelöscht wurde.

Sie könnten mal liveconfig --db-check ausführen und uns das Ergebnis an support@liveconfig.com schicken - dieser neue Kommandozeilenbefehl prüft die Datenbank auf mögliche Fehler.

Es handelt sich um keinen Reseller-Zugang. Es war ein ganz normal angelegter Endkunden-Account angelegt durch den Haupt-Benutzer. Da die Ausgabe unspektakulär ist direkt hier:

# liveconfig --db-check

Checking database integrity...

- checking nested set of customers

-> checked 43 customers

- checking for orphaned customers

- checking nested set of accounts

-> checked 0 accounts with reseller resources

- checking for accounts with invalid mail server

- checking age of RRD data

- RRD_TRAFFIC: 133712 records, oldest: 2013-12-04T00:00:00Z

- RRD_WEBSPACE: 128834 records, oldest: 2013-12-04T00:00:00Z

- RRD_NET: 11942 records, oldest: 2014-06-11T12:00:00Z

- RRD_MEM: 12321 records, oldest: 2013-12-04T00:00:00Z

- RRD_CPU: 12321 records, oldest: 2013-12-04T00:00:00Z

- RRD_MAIL: 14866 records, oldest: 2017-02-23T08:15:00Z

- checking table sizes, top 10 tables (KB):

11429888 RRD_TRAFFIC

10217472 RRD_WEBSPACE

3278848 DNSSEC

1716224 LOG

1200128 RRD_MAIL

1169408 RRD_MEM

1123328 RRD_CPU

953344 RRD_NET

731136 SUBDOMAINS

515072 SSLCERTS

All checks passed.

Das löschen von Accounts funktioniert auch nicht:

[2853086] [2025-08-08 13:59:19.818784] [INFO] LiveConfig starting...

[2853086] [2025-08-08 13:59:19.821898] [INFO] Database driver loaded: SQLite (3.50.3)

[2853090] [2025-08-08 13:59:19.840787] [INFO] Database driver loaded: SQLite (3.50.3)

[2853092] [2025-08-08 13:59:19.844870] [INFO] Connected to dBus!

[2853092] [2025-08-08 13:59:20.063246] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2853092] [2025-08-08 13:59:20.071917] [INFO] [LUA] Detected 'Debian GNU/Linux 12 (bookworm)'

[2853092] [2025-08-08 13:59:20.427383] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2853092] [2025-08-08 13:59:20.427657] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2853092] [2025-08-08 13:59:20.427782] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

[2853091] [2025-08-08 13:59:20.447988] [EMERG] Exception while processing sysinfo: Object not found or not authorised for it

[2853091] [2025-08-08 13:59:27.477830] [INFO] Account 'web37' successfully removed.

[2853092] [2025-08-08 13:59:27.481725] [INFO] LC.smtp.deleteMailbox(xxxx.xxxx@xxxx-xxxx.de) OK

[2853092] [2025-08-08 13:59:27.481759] [INFO] [LUA] Deleting mailbox xxxx.xxxx@xxxx-xxxx.de from dovecot config file: /etc/dovecot/passwd

[2853092] [2025-08-08 13:59:27.482022] [INFO] LC.popimap.deleteMailbox(xxxx.xxxx@xxxx-xxx.de) OK

[2853091] [2025-08-08 14:00:02.057711] [EMERG] Database exception: FOREIGN KEY constraint failed

[2853091] [2025-08-08 14:00:02.057729] [EMERG] SQL: DELETE FROM CUSTOMERS WHERE CUST_ID = ?1

Der Trick in der Datenbank mit dem setzen von einer 0 bei Hostingcontracts funktioniert auch nicht mehr.

Jetzt ist es nach langem warten wie von selbst verschwunden. Ist das normal, das es so lange dauert? Ca. 30 min. war es so zu sehen, das könnte für den Endkunden verwirrend sein.

Noch eine Frage, die gerade und auch schon mehrfach von Kunden reinkam: ist künftig eine Wildcard-SSL-Unterstützung mit Let's Encrypt-Zertifikaten geplant?

Das hier steht im Log:

[2841599] [2025-08-08 12:50:23.164952] [INFO] Mailbox '39' successfully removed.

[2618575] [2025-08-08 12:50:23.169779] [INFO] LC.smtp.deleteMailbox(xxx.xxx@xxx-xxx.de) OK

[2618575] [2025-08-08 12:50:23.169830] [INFO] [LUA] Deleting mailbox xxx.xxx@xxx-xxx.de from dovecot config file: /etc/dovecot/passwd

[2618575] [2025-08-08 12:50:23.171692] [INFO] LC.popimap.deleteMailbox(xxx.xxx@xxx-xxx.de) OK

Aber das Postfach ist noch durchgestrichen zu sehen.

Mailkonten werden nicht gelöscht sondern werden durchgestrichen mit einem grauen Uhrensymbol dargestellt. Hier besteht Handlungsbedarf.

Wenn man unter dem Punkt "Kunden" nach einer Domain sucht, wird nichts gefunden. Das wäre noch eine große Hilfe, um den entsprechenden Account schnell finden zu können.

Das zählen von ein- und ausgehenden Mails scheint noch nicht zu funktionieren. Es steht überall noch nichts in der entsprechenden Spalte.

Was ist eigentlich mit der Preview-Version? https://www.liveconfig.com/de/lab/
Sind diese Änderungen dann in der Version 3 schon enthalten oder gibt es noch ein "Zwischen-Update" vor der Version3?

So viel zum Thema, es mag sein, das dies übertrieben dargestellt wird, aber es gibt da schon Unterschiede: https://rackspeed.de/starke-partner/#litespeed

Die "großen" sind uns also schon um Nasenlängen im voraus.

Nach fast 5 Monaten noch keine Rückmeldung?

2030 ist es soweit

mod_qos funktioniert unter Debian 12 nicht mehr. Kennt jemand eine (sehr ähnliche) Alternative oder einen "Trick", wie man mod_qos doch zum laufen bekommt?

Leider nein. Auf diese möglichkeit wird schon sehr lange gewartet. Der Aufwand ist enorm, vor allem bei Kunden mit hunderten Mailadressen und Postfächern ist soetwas manuell kaum machbar.

Heute folgendes Problem, ein Kunde lässt sich absolut nicht löschen, egal was man macht. Auszug aus den Logs:

[2025/04/28 08:14:29.882350] [408995|409001] Deleting subscription 'web40' (all objects deleted successfully)
[2025/04/28 08:14:29.888247] [408995|409005] ERROR: Releasing db connection, but still have open statements
[2025/04/28 08:14:29.888260] [408995|409005] aborting SQL: 'DELETE FROM HOSTINGCONTRACTS WHERE HC_ID = ?1'
[2025/04/28 08:14:29.888266] [408995|409005] aborting SQL: 'SELECT HOSTINGCONTRACTS.*, HP_MAXCUSTOMERS, HP_PERMISSIONGROUPID, AC_ID, AC_SERVERID, AC_LOGIN, AC_STATUS FROM HOSTINGCONTRACTS LEFT JOIN HOSTINGPLANS ON ( HC_PLANID = HP_ID) LEFT JOIN ACCOUNTS ON ( HC_ID = AC_CONTRACTID AND AC_TYPE = 0) WHERE HC_ID = ?1'
[2025/04/28 08:14:29.888271] [408995|409005] ERROR: Releasing db connection, but still have running transaction (-> forcing ROLLBACK)
[2025/04/28 08:14:29.888444] [408995|409005] Database exception: database disk image is malformed (SQL: DELETE FROM HOSTINGCONTRACTS WHERE HC_ID = ?1)
[2025/04/28 08:14:35.708084] [408995|409126] Updating AppInstaller repository (https://update.liveconfig.com/repo-v3.json)...
[2025/04/28 08:14:35.893822] [408995|409003] ERROR: Releasing db connection, but still have open statements
[2025/04/28 08:14:35.893849] [408995|409003] aborting SQL: 'UPDATE RRD_TRAFFIC SET RRD_VALUE1= ?1, RRD_VALUE2= ?2, RRD_VALUE3= ?3, RRD_TIMESTAMP= ?4 WHERE RRD_ARCHIVEID = ?5 AND RRD_SLOTID = ?6'
[2025/04/28 08:14:35.893854] [408995|409003] aborting SQL: 'SELECT RRA_ID, RRA_STEP, RRA_SIZE, RRA_SLOTPOS, RRA_LASTTS, RRA_VALUE1, RRD_VALUE1, RRA_VALUE2, RRD_VALUE2, RRA_VALUE3, RRD_VALUE3, RRD_SLOTID, RRD_TIMESTAMP FROM RRA_TRAFFIC LEFT JOIN RRD_TRAFFIC ON ( RRA_ID = RRD_ARCHIVEID AND RRA_SLOTPOS = RRD_SLOTID) WHERE RRA_CONTRACTID = ?1 AND RRA_LEVEL = 0 ORDER BY RRA_ID ASC'
[2025/04/28 08:14:35.893858] [408995|409003] ERROR: Releasing db connection, but still have running transaction (-> forcing ROLLBACK)
[2025/04/28 08:14:35.893874] [408995|409003] Database exception: database disk image is malformed (SQL: UPDATE RRD_TRAFFIC SET RRD_VALUE1= ?1, RRD_VALUE2= ?2, RRD_VALUE3= ?3, RRD_TIMESTAMP= ?4 WHERE RRD_ARCHIVEID = ?5 AND RRD_SLOTID = ?6)

Was ist zu tun?

Heute hatten wir wieder so einen Fall. Die Absender suchen, ganz klar, bei uns die Schuld obwohl es eigentlich gar nicht unser Problem ist, sondern das des Absenders. Gibt es da eine Idee oder sollte der Kunde die Spamfilter ganz abschalten?

Das ganze hat zu 99% nichts mit LiveConfig zu tun.

Danke für die Antwort. Die "log_errors"-Einstellung kann der Kunde ändern, standardmäßig ist diese jedoch deaktiviert, auch bei diesem Kunden ist "nein" gesetzt. Dennoch wird das Log angelegt. Kann man dies andersweitig unterbinden? Wahrscheinlich setzt die Einstellung die Webseite des Kunden mit "ini_set()" dann wohl selbst, was der Kunde als Ursache oftmals gar nicht vermutet.

Das Problem besteht leider noch immer sporadisch. Kann das bitte behoben werden ohne weitere Bastelarbeiten in der Datenbank?

In den PHP-Einstellungen habe ich "log_errors" deaktiviert. Dennoch wird für die Kunden eine solche Datei unter /var/www/webXX/logs/priv/php_errors.log erstellt.
Stehe ich gerade auf dem Schlauch? Wie kann man dies deaktivieren? Bei manchen Kunden "wachsen" diese Dateien auf mehrere GB, so das ab und zu Anfragen kommen, warum der Webspace schon wieder voll sei.