Beiträge von ñull

Ich konnte doch den Mailserver eines Hosting-Vertrags in der Datenbank ändern. Ich kann da leider keine Garantie übernehmen. Bitte beachte: Die Nutzung erfolgt auf eigene Gefahr. Bitte spring nicht über den Schritt mit der Sicherungskopie hinweg und gib uns Bescheid, ob es geklappt hat und ob du eine bessere, sicherere Methode kennst.

Vorbereitung

Entferne zunächst alle E-Mail-Konten, sodass sich kein einziges mehr in dem Konto befindet. Deaktivier die E-Mail-Berechtigung im Hosting-Vertrag, damit nichts von den bisherigen Einstellungen erhalten bleibt oder erneut hinzugefügt wird. Anschließend als Root oder mit „sudo“:

apt install sqlite3

systemctl stop liveconfig

cd /var/lib/liveconfig/

cp liveconfig.db liveconfig.backup.db

sich informieren

Jetzt können wir uns informieren. Ich habe das erst mal mit einer Kopie auf meinem Laptop gemacht und dann Beekeeper Studio benutzt, um die passenden Tabellen zu finden.

sqlite3 -box -header liveconfig.db 'SELECT MS_ID,MS_HOSTNAME FROM MAILSERVERS;'

sqlite3 -box -header liveconfig.db 'SELECT HC_ID , HC_NAME, HC_MAILSERVERID FROM HOSTINGCONTRACTS;'

Erstens können wir nun erkennen, dass 1 die MS_ID (=HC_MAILSERVERID) des falschen Servers und 2 die des richtigen Servers ist. Zweitens können wir nun den Vertrag identifizieren, bei dem die falsche ID eingestellt ist. Wir können nun mit dem nächsten Schritt fortfahren, um die HC_MAILSERVERID in der richtigen Zeile (HC_ID) der Tabelle „HOSTINGCONTRACTS“ auf den richtigen Wert zu ändern.

Change and finalize:

sqlite3 liveconfig.db "UPDATE HOSTINGCONTRACTS SET HC_MAILSERVERID = 2 WHERE HC_ID = 1"

sqlite3 -box -header liveconfig.db 'SELECT HC_ID , HC_NAME, HC_MAILSERVERID FROM HOSTINGCONTRACTS;'

systemctl start liveconfig

In der API-Dokumentation ist „mailserver“ jedoch in der PATCH-Methode für accounts aufgeführt. Ich gehe davon aus, dass dies zwar vorbereitet, aber noch nicht implementiert wurde. Möglicherweise ist PATCH accounts überhaupt nicht implementiert. Nur der Autor kann uns hier Klarheit verschaffen.

Ich habe das oben Genannte auf meinem Server ausprobiert. Es gibt folgende Ausgabe:

{"success":true}

Der Mailserver wurde jedoch nicht geändert. Muss ich vielleicht den vollständigen Datensatz des Kontos einfügen? Ich werde es dich wissen lassen.

Zitat von lebenszeit

'authorization: Bearer ...' sollte dies veröffentlicht werden

Das ist öffentlich zugängliches Demo-Wissen, das direkt aus der API-Dokumentation kopiert wurde.

Zitat von lebenszeit

Ungetestet: E-Mail (+ DKIM) deaktivieren im Account und im Vertrag. E-Mail im Vertrag aktivieren. Vielleicht kann dann der Mailserver gewählt werden.

Ich habe es versucht, aber nach der De-/Reaktivierung gibt es keine Möglichkeit, einen anderen Mailserver auszuwählen.

Nachdem ich das Hosting-Konto erstellt hatte, stellte ich zu spät fest, dass ich den falschen Mailserver dafür ausgewählt hatte; ich hatte die DNS-Domain bereits konfiguriert. Ich möchte diese Arbeit nicht noch einmal machen müssen. Ich habe immer noch keine E-Mail-Adresse und habe mich gefragt, ob es nicht eine Möglichkeit gibt, den Mailserver zu ändern. Lässt sich das nicht durch eine Änderung in der Datenbank oder über die API bewerkstelligen? Ist dies möglich mit dem API-Befehl "PATCH accounts"?

curl -X PATCH "https://demo-v3.liveconfig.com:8443/liveconfig/api/v1/accounts/<account-name>" \

-H 'accept: application/json'\

-H 'authorization: Bearer hLmGUXCkVbmDQ8YgoVLNWxR48K44cymcOBldhWP0'\

-H 'content-type: application/json' \

--data-raw '{ "mailserver": "<other_server>" }'

In Debian Trixie zeigt liveconfig --diag :

[11544] [2026-06-11 11:07:01.620479] [INFO] [LUA]LC.exec(grep -q '^mail_plugins = quota' /etc/dovecot/dovecot.conf): exited with return code 1

In /etc/dovecot/dovecont.conf sehe ich nur:

!include conf.d/*.conf

!include_try local.conf

In /etc/dovecot/conf.d/90-quota.conf finde ich dann:

#mail_plugins {

# quota = yes

#}

Hier scheint es um eine geänderte Konfigurationssyntax zu gehen. Das LUA-Skript muss deshalb verbessert werden, da der neuen Syntax nach Aktivierung nicht erkannt wird.

I added PHP version 8.1. with (in debian 13):

-- /etc/liveconfig/lua.d/php81.lua
-- register additional PHP interpreter from Sury repository
LC.web.addPHP( {
  ['id']  = 'php81',
  ['cli'] = '/usr/bin/php8.1',
  ['cgi'] = '/usr/bin/php-cgi8.1',
  ['fpm'] = {
    ['bin']     = '/usr/sbin/php-fpm8.1',
    ['start']   = 'systemctl start php8.1-fpm',
    ['stop']    = 'systemctl stop php8.1-fpm',
    ['reload']  = 'systemctl restart php8.1-fpm',
    ['pool']    = '/etc/php/8.1/fpm/pool.d',
    ['sockets'] = '/run/php'
  },
  ['eol-date']  = '2025-12-31'
} )

Ergebnis:

liveconfig --diag

_    _          ___           __ _     (R)
| |  (_)_ _____ / __|___ _ _  / _(_)__ _
| |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
|____|_|\_/\___|\___\___/_||_|_| |_\__, |_____________________________________
                                  |___/
Versions:
 LiveConfig 3.2.2 (build 17630, commit 8e2de334e)
 libk 0.9.1 (b7950668)
 OpenSSL 3.5.6 (runtime: 3.5.6)
 PCRE 10.47 (runtime: 10.47)
 SQLite 3.53.1 (runtime: 3.53.1)
 cURL 8.20.0 (runtime: libcurl/8.20.0 OpenSSL/3.5.6 zlib/1.3.2)
 libdb 1.23.6
 libev 4.33
 zlib 1.3.2 (runtime: 1.3.2)

..

- PHP 8.1.34 (code='php81', eol='2025-12-31')
CGI/FastCGI: /usr/bin/php-cgi8.1
FPM: /usr/sbin/php-fpm8.1
pool config: /etc/php/8.1/fpm/pool.d
default php.ini: /etc/php/8.1/cgi/php.ini
- PHP 8.4.21 [DEFAULT] (code='php8')
CGI/FastCGI: /usr/bin/php-cgi
FPM: /usr/sbin/php-fpm8.1
pool config: /etc/php/8.1/fpm/pool.d
default php.ini: /etc/php/8.4/cgi/php.ini
- default PHP CLI: /usr/bin/php

Mein Punkt ist, dass die Pool-Konfiguration der neuen Version offenbar die Standard-Pool-Konfiguration beeinflusst hat. Ich bin der Meinung, dass jede PHP-Version ihren eigenen Pool-Ordner haben sollte. Das Ergebnis meiner zusätzlichen Version ist, dass 8.4 und 8.1 sich nun den Pool-Ordner /etc/php/8.1/fpm/pool.d teilen.

Ich habe auf meinem lcclient-Server nachgeprüft, auf dem ich 8.1 noch nicht installiert habe, und dort sehe ich, wie der Pool-Ordner eigentlich hätte aussehen sollen:

lcclient --diag
..

- PHP 8.4.21 [DEFAULT] (code='php8')
CGI/FastCGI: /usr/bin/php-cgi
FPM: /usr/sbin/php-fpm8.4
pool config: /etc/php/8.4/fpm/pool.d
default php.ini: /etc/php/8.4/cgi/php.ini
- default PHP CLI: /usr/bin/php

Falls dies tatsächlich unerwünscht ist oder hier ein Fehler vorliegt, könnte dies bitte behoben werden, bevor wir in der Sommerhitze einschlafen ?

In älteren Versionen vor LC3 war dies mit Pootle möglich und ich war selbst sogar an der spanischen und niederländischen Übersetzung von LC beteiligt. Jetzt, wo ich LC3 teste und installiere, bin ich auf einen Übersetzungsfehler gestoßen, und ich weiß nicht, wie ich mich wieder daran beteiligen kann. Kann mir jemand weiterhelfen

Any progress? Let me know if you need access to my test setup for further analysis.

My first experience with the Backup feature in LC3 is that of confusion as if it still were a Beta release. In fact I am still very reluctant to call a bug report or complaint because I am still unsure what is expected behavior. The only I do here is to transmit my confusion.

I will first present what I did to get it somewhat working. I decided to keep it simple by choosing for tar with local storage. I hope lcbackup is prepared to run some pre/post scripts to (un)mount the destination folder after/before backup?

My initial test setup:

• Server A
  • Liveconfig host
  • 1st DNS
  • Client's HTTP
  • Client's Database
• Server B
  • Mail
  • 2nd DNS
  • Company HTTP & Database, for Roundcube and other apps

This tested okay so far using the following accounts outline:

• Admin account
  • Account A (company use of server A)
    • main domain with some tool apps
  • Account B (company use of server B)
    • mail subdomain on server B with Roundcube
  • Customer My Company
    • Reseller account (to separate client accounts)
      • Client A (test account)

My steps to configure Backup.

• Activate Backup on all servers where it is needed.
  • LC menu: ☞ Servers ☞ localhost (Column ID) ☞ BACK-UP (Tab)
  • Click [ Add storage ]
    • Form data
      • Description: xxx backup
      • Type: tar
      • Directory: /var/backups/liveconfig
      • Location: local
    • Click [ 🗸 Save ]
  • Check that Services ☞ lcbackup shows a circled check mark (service is running)
  • Which should be consistent with the result of the following command:
    • sudo systemctl status backup
  • Remedy when unloaded, inactive etc.
    sudo systemctl unmask lcbackup
    sudo systemctl enable lcbackup
    sudo systemctl start lcbackup

Then I wanted to test primarily the function of manual backup as advertised in the UI. My main interest was to use this to migrate accounts from my old server. I activated this for the Client A test account which was a sub-account of the Company Reseller (see my test account outline):

• Customers ☞ click company's row ☞ click button [ Log in as user Client A ]
  • Customers ☞ click client A row ☞ click ACCOUNTS (tab) ☞ click account summary
  • Click BACKUP (tab)
    • activate allow customer to trigger backup manually
    • set (for instance) keep up to 3 manual backups and minimum time to wait between two backups: 10 minutes.
    • Click button [ 🗸 Save ]
  • I clicked back to Client A's OVERVIEW tab and clicked button [ Log in as user 'Client A' ]

I looked for the promised means to manually trigger a backup by client A but I did not find it anywhere. Since there is no documentation I keep doubting if this a bug or a configuration error. I first thought it might be an issue with reseller sub accounts, but the reseller has the same manual backup setting and after activating it and logging in as, I could not find any there either. What am I missing?

Then I started playing around with Backup schedules. I made some test schedules and then:

• I checked the backup location at /var/backup/liveconfig. There were (scheduled) backups as set up in menu BACKUP ☞ SCHEDULES
• They apparently were only related to the accounts A and B I created as the admin for admin.
  • Their schedules are visible in their account setting, but I cannot change the retention. The Delete button is not an option here because it will delete the whole account.
  • When I compare that with the Reseller created under the company customer then I notice in the account setting that you can still edit the schedules there.
    • Is that because there were no backups yet?
    • Or is that because they can only set once?
  • Apparently the retention setting activates the schedule, but you cannot change the retention any more when there was a backup created.
    • I deleted all backups of account A and still the retention could not be ediited.
• The location to restore I found in WEBSPACE ☞ BACKUP, with a page wide select select box to switch between the accounts. In both I could enter the restore page after clicking one of the retained backups in the list.
  • The Reseller had no WEBSPACE of its own, so there was no way to check its BACKUP tab there.
  • The Client A WEBSPACE ☞ BACKUP list was empty, as there was no way in their account setting to set the backup retention either.

So far my superficial impressions. I wanted to translate this into German but then I found out that I then would loose all outlines. Sorry about that. Now I have to revert to writing my own scripts, because beside being unable to trigger manual backup, I don't see an option to upload backup files or even see that the functionality exists.

Ich würde dafür plädieren, alles so einfach wie möglich zu halten. Es wäre bereits eine große Hilfe, wenn das aktuelle Backup-System die Möglichkeit bieten würde, eine Backup-Datei herunterzuladen und anschließend auf dem anderen Server wiederherzustellen.

Vielen dank!

Ich verwende eine leere String-Werte, um die Standardeinstellung von user_ini.filename zu deaktivieren, sie aber für Administratoren zuzulassen

Zitat von PHP Handbuch

Wenn dies auf eine leere Zeichenkette gesetzt wird, sucht PHP nach keiner Datei. Der Standardwert ist .user.ini.

In LC 2.17.0 war dies möglich, aber in 3.1.4 habe ich festgestellt, dass dies nicht mehr der Fall ist. Bitte stellen Sie diese Funktion wieder her, damit wir alle möglichen Konfigurationsfälle anpassen können.

Beim Anlegen eines neuen Benutzers fehlen zwei der fünf Sprachen: Französisch und Spanisch. Die Abhilfe besteht darin, sich zusätzlich als dieser Benutzer anzumelden und die Sprache in dessen Einstellungen zu ändern.

Ist diese Version (2.17.0) noch irgendwo verfügbar? Ich bräuchte sie für letzte Reparaturarbeiten, da ich noch immer damit beschäftigt bin, auf LC3 umzusteigen. Ich glaube, eine Deb-Datei reicht schon.

Leider habe ich (noch) keine Mountpunkte mit dem kleinsten Hetzner-Cloud-Server. Vielleicht später einmal.

Ich spreche hier jedoch von der Aktivierung des Dateiquota-Systems. Seit Debian Bookworm gibt es eine Änderung, dass dies nicht mehr über Mount-Optionen, sondern über das Tool tune2fs erfolgt. Außerdem sind Quota und wahrscheinlich auch Quota-Tools weiterhin erforderlich, um LC Zugriff auf die Quota-Berichte zu gewähren. Als ich feststellte, dass tune2fs nur dann Dateisystemoptionen schreiben kann, wenn die Partition nicht gemountet ist, schreckte mich das unnötigerweise ab. Ich hatte nämlich kurz vergessen, dass Hetzner mit seinem Rescue-System die ideale Lösung bietet.

Die Schritte sind daher wie folgt:

• Den Server herunterfahren.
• Den Server mit dem Rettungssystem starten.
• Sich beim Rettungssystem über SSH anmelden.
• Den richtigen Gerätenamen der Partition finden, auf der die Quote aktiviert werden soll, z. B. /dev/sda3.
• das Tool tune2fs verwenden:
  tune2fs -O quota /dev/sda3
• den Server unter Debian neu starten
• überprüfen, ob die Quota in den aktiven Dateisystemfunktionen aufgeführt ist:

tune2fs -l /dev/sda1 | grep -i quota | grep features

Zitat

Filesystem features: has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent 64bit flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize quota metadata_csum orphan_present

Ich wollte nur kurz mitteilen, dass die Anweisungen zum Aktivieren von Quota (Deutsche und Englische Version) nicht mehr aktuell sind. Hier finde ich eine ausführlichere Version auf Englisch, der ich folgen werde. Nach Debian Bookwork ist es meiner Meinung nach viel komplizierter geworden. Es ist ein umständlicher Vorgang erforderlich, um die Quota-Funktion hinzuzufügen, da das Speichermedium nicht gemountet sein darf. Ich werde morgen berichten, ob es damit funktioniert hat.

Zitat von kk

Ubuntu 18.04 LTS ist seit Mai 2023 "end of life", Updates dafür gibt es nur noch via ESM.

Das ist bekannt. Ich bin noch bei 18.04 ESM, weil die Aktualisierung auf 20.04 nie funktioniert hat. Ich könnte es noch einmal versuchen. Aber ich möchte eigentlich lieber auf Debian in einem neuen virtuellen Server umsteigen, also neu anfangen. Das bedeutet, dass ich das jetzt beschleunigt durchziehen muss.

Warum kann apt ab Version 2.17 keine neuen Upgrades mehr installieren? Wird mein altes Ubuntu 18.04.6 ab Version 2.18 nicht mehr unterstützt?

Dieses Kontrollkästchen bewirkt entweder das Gegenteil oder es funktioniert überhaupt nicht. Ich hatte es deaktiviert, und als ich versuchte, mich einzuloggen, um zu testen, ob ich die richtigen Informationen an den Benutzer gesendet hatte, wurde ich gezwungen, das Passwort trotzdem zu ändern; wenn man es ignoriert, kehrt man zum Login zurück.

Wo: LiveConfig 2.16.6 > Login als Wiederverkäufer > Kunde > Übersicht > Kunde bearbeiten.
Wie: Neues Passwort eingeben und auf Speichern klicken und dann gleich einloggen als Kunde.