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.

Derzeit werden die Repository-Schlüssel auf die gleiche Weise aktualisiert wie in der Installationsanleitung beschrieben wird:

wget -O /root/liveconfig-keyring.deb https://www.liveconfig.com/liveconfig-keyring.deb
dpkg -i /root/liveconfig-keyring.deb

In der Demo sehe ich die Sprachen Arabisch, Deutsch, Englisch und Niederländisch. Arabisch und Niederländisch sind vorhanden, aber vieles ist dort noch Englisch.

Wann wird Ihre Pootle-Seite auch Liveconfig 3 enthalten? Wäre es nicht schöner, wenn die Übersetzungen vor der Veröffentlichung weitgehend fertig sind?

Ich habe einen alten Server, den ich vorübergehend deaktiviert, aber als Snapshot behalten habe. Aus vorübergehend wurde dauerhaft. Jahre später habe ich versucht, ihn wiederherzustellen, aber irgendwie funktioniert die Vernetzung nicht mehr. In diesem Offline-Zustand ist es unmöglich, ihn aus der Serververwaltung von Liveconfig zu entfernen.

Wie kann man den Servereintrag trotzdem entfernen, ohne dass er online ist? Gibt es eine (My)SQL-Abfrage, um dies sicher zu tun, ohne die Datenbankintegrität von Liveconfig zu beeinträchtigen?

Mistake: Debian 11 still has php 7.4.33 as default. 8.x can only be installed with an additional PHP repository.

I removed all php to avoid confusion between standard and Sury php. Then I reinstalled from Sury php 8. 0.x and php 8.1.x. I run and see:

systemctl restart liveconfig; liveconfig --diag

Running OS diagnostics... (LiveConfig 2.16.0-release)
....

Running Lua diagnostics...
[WARNING] addPHP: incomplete FPM configuration for '/usr/sbin/php-fpm8.0' - skipping...
[WARNING] addPHP: incomplete FPM configuration for '/usr/sbin/php-fpm8.1' - skipping...

The warnings were for the missing ['fpm']['reload'] which I had commented out. I included it and corrected eol year:

-- register additional PHP interpreter with LiveConfig
LC.web.addPHP( {
  ['id']  = 'php8',
  ['cli'] = '/usr/bin/php8.0',
  ['cgi'] = '/usr/bin/php-cgi8.0',
  ['fpm'] = {
    ['bin']     = '/usr/sbin/php-fpm8.0',
    ['start']   = 'systemctl start php8.0-fpm',
    ['stop']    = 'systemctl stop php8.0-fpm',
    ['reload']  = 'systemctl restart php8.0-fpm',
    ['pool']    = '/etc/php/8.0/fpm/pool.d',
    ['sockets'] = '/run/php80-fpm'
  },
  ['eol-date']  = '2023-09-26'
} )

After Switching to FPM the affected site shows me this message when I access the site with my browser:

Zitat von php page with <?php phpinfo() ?>

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

In apache's configuration I see:

    <IfModule mod_proxy_fcgi.c>
        <FilesMatch ".+\.ph(p[3457]?|t|tml|ps)$">
            SetHandler "proxy:unix:/run/php80-fpm/<subscription-name>.sock|fcgi://localhost"
            SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
        </FilesMatch>
    </IfModule>

The run folder however does not exist, only /run/php. I finally made the socket folder common for all and in /run/php :

-- register additional PHP interpreter with LiveConfig
LC.web.addPHP( {
  ['id']  = 'php8',
  ['cli'] = '/usr/bin/php8.0',
  ['cgi'] = '/usr/bin/php-cgi8.0',
  ['fpm'] = {
    ['bin']     = '/usr/sbin/php-fpm8.0',
    ['start']   = 'systemctl start php8.0-fpm',
    ['stop']    = 'systemctl stop php8.0-fpm',
    ['reload']  = 'systemctl restart php8.0-fpm',
    ['pool']    = '/etc/php/8.0/fpm/pool.d',
    ['sockets'] = '/run/php'
  },
  ['eol-date']  = '2023-09-26'
} )

I am not sure if that will again cause conflicts when switching versions. I experienced these when after switching php version the FPM service complained that a socket (of the previous PHP version) already existed. The old socket under the other PHP version remained active and was apparently not closed when the version change took place. I tried changing from 8.0.x to 8.1.x and sure enough I see it again after restarting:

Zitat von systemctl restart php8.0-fpm; systemctl status php8.0-fpm

sep 06 11:58:00 hostname php-fpm8.0[767720]: [06-Sep-2023 11:58:00] ERROR: Another FPM instance seems to already listen on /run/php/<subscription-name>.sock

sep 06 11:58:00 hostname php-fpm8.0[767720]: [06-Sep-2023 11:58:00] ERROR: FPM initialization failed

After some time it restored itself although I doubt that 8.0.x was still working because initialization failed. This is however a client with their own dedicated server with limited damage when you are aroud to solve it. Aparently a restart like this seems to solve the issue:

systemctl restart php8.{0,1}-fpm.service apache2 mariadb
systemctl status php8.{0,1}-fpm.service apache2 mariadb

Some more instruction is helpful for external repositories to avoid wrong recognition of Lc internals. Apparently Lc looks at the Debian version and the expected default version (in my case Debian 11 with php 8.0). The ID used here is php8. To distinguish sury from the LC provided repos in /opt, I used a different IDs namely php80sury. This causes a confusion that created and additional php8 version with mixed erroneous paths . I did not try it but I guess that the default will then fail to work correctly.

The only workaround I found is to follow the undocumented convention:

1. remove all default /opt based luas; when you use external repos they are simply not needed.
2. make your own luas and let the php 8 version have 'id' php8 . Only then the internal default recognition code is overridden. It recognises the 'id' not the PHP version.

Here I post the still untested pattern for php8:

php80sury.lua:
-- register additional PHP interpreter with LiveConfig
LC.web.addPHP( {
  ['id']  = 'php8',
  ['cli'] = '/usr/bin/php8.0',
  ['cgi'] = '/usr/bin/php-cgi8.0',
  ['fpm'] = {
    ['bin']     = '/usr/sbin/php-fpm8.0',
    ['start']   = 'systemctl start php8.0-fpm',
    ['stop']    = 'systemctl stop php8.0-fpm',
--    ['reload']  = 'systemctl reload php8.0-fpm',
    ['pool']    = '/etc/php/8.0/fpm/pool.d',
    ['sockets'] = '/run/php'
  },
  ['eol-date']  = '2022-09-26'
} )

This is how far I got but I see more errors. FPM seems to have become fully disconfigured. I have given up on it for lack of time. Any hints are appreciated how to get this working with fpm and sury repository. I don't mind answers in German.

Fehlermeldung:

Zitat

An error occured while processing your request: mysql_stmt_execute: (1451) Cannot delete or update a parent row: a foreign key constraint fails (`LIVECONFIG`.`USERS`, CONSTRAINT `USERS_ibfk_2` FOREIGN KEY (`U_CONTACTID`) REFERENCES `CONTACTS` (`CON_ID`))

LC 2.16.0 Die Datenbank wurde von Anfang an auf MySQL umgestellt. Der Vertrag des Kunden wurde bereits gelöscht. Wie sollte ich dieses Problem umgehen oder lösen?

Ich habe disable_functions als Benutzer admin in PHP Einstellungen geändert. Nach der Änderung sehe ich, dass bei meinen Kunden diese Einstellung nicht übernommen wurde. Dies erscheint mir nicht sehr sicher, auch weil nach der Änderung keine Warnung darüber erscheint. Im Moment ist es aber wichtiger zu wissen, wie ich dies manuell erreichen soll?

In spätere Debian/Ubuntu Versionen sieht man:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8))

... und geht es dann doch mit:

wget -O - https://www.liveconfig.com/liveconfig.key | gpg --dearmor - >/etc/apt/trusted.gpg.d/liveconfig.gpg

Ich habe gerade entdeckt, dass in der Anleitung eine für mich sehr wichtige Zeile im Abschnitt Konfigurationsdateien umziehen fehlt. Es hat zu lange gedauert, bis ich die Ursache herausgefunden habe, deshalb berichte ich hier darüber. Es scheint mir wünschenswert, dass auch /usr/lib/liveconfig/lua/custom.lua als Konfiguration gesehen oder zumindest irgendwo erwähnt wird:

rsync -avR --delete /etc/apache2 /etc/nginx /etc/proftpd \
/etc/awstats /etc/webalizer \
/etc/ssl/certs/*.crt /etc/ssl/private \
/etc/postfix /etc/dovecot /etc/opendkim \
/etc/liveconfig /var/lib/liveconfig \
/usr/lib/liveconfig/lua/custom.lua \
/etc/default/opendkim /etc/default/spamassassin \
root@destination.example.org:/