Beiträge von Angus.MacGyver

Ursache vermutlich gefunden / ermittelt:

Ich hatte unter Einstellungen > Web-Oberfläche > Kunden-/Vertragsnummer im Feld Nächste Vertragsnummer ursprünglich eine niedrigere Nummer (3) ausgewählt als es schon Verträge gab (0, 1, 2, 3, 4, 5, 6, 7, 8). (Damit wollte ich dafür sorgen die Lücken "aufzufüllen".)

Scheinbar verursachte dies jedoch einen (System-)Fehler gemäß liveconfig.log:

[110191] [2026-04-10 21:25:06.037876] [EMERG] Uncaught exception: unable to find next calculated account name
[110191] [2026-04-10 21:25:06.037916] [EMERG] METHOD: GET; URL: /liveconfig/api/v1/accounts
[110191] [2026-04-10 21:25:06.037921] [EMERG] Got exception: std::runtime_error

Sobald ich die Vertragsnummer auf eine Nummer höher als alle bestehenden Verträge eingestellt hatte trat der Timeout-Fehler nicht mehr auf!

kk: Vielleicht kann das System an dieser Stelle etwas fehlertoleranter ausgestaltet werden?!

Auch nach einem Wechsel auf MySQL/MariaDB bleibt es bei den Timeouts.

Zusätzlich musste ich bei näherer Betrachtung feststellen, dass vorgenommene Änderungen (PHP-Einstellungen) leider doch NICHT gespeichert wurden.

Kurze Notiz:

(Zur Kenntnis kk)

In der Datenbankstrukturdatei /usr/share/doc/liveconfig3/db-mysql.sql.gz fehlt scheinbar die Tabelle PREFERENCES_V3.

Diese ist in der SQLite-Datenbank wohl aber vorhanden.

Ich habe einfach den CREATE-Befehl aus der SQLite-Datenbank verwendet und diese Tabelle in MySQL/MariaDB selbst angelegt:

CREATE TABLE PREFERENCES_V3 ( PREF3_USERID INTEGER UNSIGNED NOT NULL, PREF3_KEY VARCHAR( 50) NOT NULL, PREF3_VALUE VARCHAR( 200) NOT NULL, PRIMARY KEY ( PREF3_USERID, PREF3_KEY), FOREIGN KEY ( PREF3_USERID) REFERENCES  USERS ( U_ID ) ON DELETE CASCADE)

Ich hatte heute einmal versucht den Timeout in /etc/apache2/apache2.conf anzupassen von 300 auf 600.

Leider hat das nicht wirklich geholfen; die Timeout-Meldung kommt trotzdem; und das ca. 5 Sekunden nach Klick auf den jeweiligen "Account".

Es scheint also, dass der API-Timeout nicht nur ausschließlich über die Apache-Konfiguration zustandekommt.

Wodurch wird der API-Timeout noch gesteuert bzw. wo könnte bzw. müsste ich hier weitere Timeout-Werte erhöhen?

Ich habe bisher nur die Standard SQLite-Datenbank im Einsatz.

Konkret wollte ich die PHP-Einstellungen eines "Kunden" ändern. Ich klicke also auf "Kunden", dann den Kunden, dann Accounts, dann auf den jeweiligen Account.

Im Fehlerfall laden die Account-Einstellungen dann nicht vollständig (es fehlt z.B. eben der PHP-Reiter) und es kommt eben zu dem erwähnten Timeout. Entsprechend kann ich die Einstellung dann nicht vornehmen.

Noch fazinierender: Wechsle ich dann von Firefox auf Chrome und mache das selbe, dann laden die Account-Einstellungen vollständig (Reiter PHP ist z.B. dann vorhanden); und die Timeout-Meldung kommt erst anschließend.

Allerdings: Das funktioniert so in Chrome auch nur "einmalig" direkt nach Login.
Will ich in der selben Session - weiterhin in Chrome - weitere Änderungen vornehmen, dann laden z.B. die Account-Einstellungen wieder nicht vollständig.

Ich habe keinen Proxy für die Server-Domain aufgesetzt; sondern ein kommerzielles SSL-Zertifikat hochgeladen bzw. hinzugefügt.

Hallo zusammen,

und zur Kenntnis kk,

ich erhalte im Haupt-Admin von Liveconfig 3.2.0 häufig die Meldung "HTTP request timed out!" und die entsprechend aufgerufene Seite bzw. Inhalte werden i.d.R. dann auch nicht geladen.

Was kann man hier tun?

Beste Grüße,

Angus MacGyver

Hallo zusammen,

in dem sehr alt Forenbeitrag Standardsubdomain wurde eine Fragegestelt, die mich auch interssieren würde:

Angenommen ich würde meinen "Webhosting-Kunden" (Keine Sorge: Reines Selbsthosting!) gerne jeweils automatisiert Standard-(Sub)-Domains verpassen wollen in der Form

- web1.nginx.lchost.de / web1.apache.lchost.de; also quasi [account].[webserver].lchost.de

Ginge so etwas und wenn ja wie?

Grüße,

MacGyver

Systemhaus-EHST Interessant; die Frage bleibt warum sind die Icons bei mir nicht da?
Und: Könnten Sie mir eventuell die vermutlich unter /var/lib/liveconfig/htdocs/ befindlichen PNG-Icons ggf. hier zur Verfügung stellen?

kk

Ein klitzekleiner kurzer Fehlerbericht:

Beim App-Installer werden die Icons nicht angezeigt.
Ursache: In der jeweiligen App-Konfiguration sind die Icons offenbar als PNG-Dateien verlinkt; ausgeliefert werden und im jeweiligen Ordner vorhanden sind scheinbar aber nur die SVG-Dateien.

Ok, dann habe ich evtl bei der nginx-Installation ggf. eine Abfrage falsch beantwortet oder so...

taenzerme Vielen Dank! Und siehe da; Aufruf z.B. der Server-IP bringt nun auch eine Platzhalter-Seite.

Dennoch wäre die Frage: Wer bzw. woher bzw. durch wen hätte die Datei fastcgi_params ursprünglich angelegt werden sollen und warum wurde diese nicht angelegt?

kk:
Ich hatte heute morgen einmal versucht in der GUI den NGINX-Prozess neu zu starten; habe dann aber ein rotes Ausrufezeichen erhalten.

journalctl -xeu nginx.service zeigte mir dann folgenden Fehler
[emerg] 71783#71783: open() "/etc/nginx/fastcgi_params" failed (2: No such file or directory) in /etc/nginx/sites-enabled/web4.conf:44

Eine solche Datei /etc/nginx/fastcgi_params hat es tatsächlich nicht.

Ebenfalls keine Ausgabe:

root@server:~# ss -tlpn | grep nginx
root@server:~#

Es sieht mir so aus, als ob NGINX nicht lauscht. Denn das angefragte ss -tpn | grep nginx bringt keine Ausgabe.

Nur Kurz von mir, weil ich gleich außer Haus bin:

root@server:~# liveconfig --diag
 _    _          ___           __ _     (R)
| |  (_)_ _____ / __|___ _ _  / _(_)__ _
| |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
|____|_|\_/\___|\___\___/_||_|_| |_\__, |_____________________________________
                                   |___/
Versions:
  LiveConfig 3.1.0 (build 16799, commit e728aa7d1)
  libk 0.9.0 (82f91aca)
  OpenSSL 3.3.5 (runtime: 3.3.5)
  PCRE 10.46 (runtime: 10.46)
  SQLite 3.50.4 (runtime: 3.50.4)
  cURL 8.16.0 (runtime: libcurl/8.16.0 OpenSSL/3.3.5 zlib/1.3.1)
  libdb 1.23.4
  libev 4.33
  zlib 1.3.1 (runtime: 1.3.1)

Running OS diagnostics...
FILE SYSTEMS:
  / [/dev/sda1] (total: 19351633920, free: 15374229504)
  /home [/dev/sda3] (total: 9738321920, free: 9221492736)
  /var [/dev/sda4] (total: 40945315840, free: 37770338304)
  /tmp [/dev/sda2] (total: 9737273344, free: 9220366336)
  /boot/efi [/dev/sda15] (total: 251872256, free: 251723264)
CPUs:
  CPU: 'cpu' user=91766 nice=4526 system=53521 idle=41149557 wait=8822 irq=0 sirq=5162 steal=0 guest=0
  CPU: 'cpu0' user=91766 nice=4526 system=53521 idle=41149557 wait=8822 irq=0 sirq=5162 steal=0 guest=0
  CPU: 'cpu1' user=91766 nice=4526 system=53521 idle=41149557 wait=8822 irq=0 sirq=5162 steal=0 guest=0
  CPU: 'cpu2' user=91766 nice=4526 system=53521 idle=41149557 wait=8822 irq=0 sirq=5162 steal=0 guest=0
  CPU: 'cpu3' user=91766 nice=4526 system=53521 idle=41149557 wait=8822 irq=0 sirq=5162 steal=0 guest=0
CPU IDENTIFICATION:
  Physical CPUs: 1
  CPU Vendor: GenuineIntel
  CPU Model: Intel Xeon Processor (Skylake, IBRS, no TSX)
  Physical Core Count: 4
  Cache: 16384 KB
LOAD AVERAGE:
  Load: 1min=0.0244141, 5min=0.0307617, 15min=0.00195312
MEMORY:
  Total Memory: 8134746112
   Free Memory: 6000586752
    Total Swap: 0
     Free Swap: 0
INTERFACES:
  Name: 'lo'
       MAC: 00:00:00:00:00:00
       IPv4: '127.0.0.1'/8
       IPv6: '::1'/128
       IN: 188988 bytes (1513 packets)
       OUT: 188988 bytes (1513 packets)
       FLAGS: UP LOOPBACK
  Name: 'eth0'
       MAC: 92:00:06:a5:ce:42
       IPv4: '91.99.138.57'/32
       IPv6: '2a01:4f8:1c1a:184b::2'/64
       IPv6: '2a01:4f8:1c0c:b7fe::2'/64
       IPv6: 'fe80::9000:6ff:fea5:ce42'/64
       IN: 406620750 bytes (283471 packets)
       OUT: 35564671 bytes (237159 packets)
       FLAGS: UP BROADCAST
       DRIVER: virtio_net
  Name: 'eth0:1'
       MAC: 92:00:06:a5:ce:42
       IPv4: '49.13.39.53'/32
       FLAGS: UP BROADCAST
       DRIVER: virtio_net
HOSTNAME:
  Hostname: 'server.lchosting.de'
      FQDN: 'server.lchosting.de'
UPTIME:  Uptime: 1 days, 04:44:21
QUOTA for group 'root' at path /var/www: OK - kb_used=453036, inodes_used=4737
Running Lua diagnostics...
[51543] [2025-11-03 10:41:55.939743] [INFO] [LUA] Detected 'Debian GNU/Linux 13 (trixie)'
       Distribution name: 'Debian'
   Distribution codename: 'trixie'
     Distribution family: 'Debian'
    Distribution version: '13'
Distribution description: 'Debian GNU/Linux 13 (trixie)'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.65'
   Package version: '2.4.65-2'
   Modules: core so watchdog http log_config logio version unixd access_compat actions alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex cgid deflate dir env fcgid filter http2 include mime mpm_event negotiation proxy proxy_fcgi proxy_http reqtimeout rewrite setenvif socache_shmcb ssl suexec
 - Found 'nginx' web server
   Version: '1.28.0'
   Package version: '1.28.0-1+0~20250426.43+debian13~1.gbpdffa8b'
 - PHP 8.0.30 (code='php80', eol='2023-11-26')
   CGI/FastCGI: /opt/php-8.0/bin/php-cgi
   FPM: /opt/php-8.0/sbin/php-fpm
        pool config: /etc/php-fpm/php80-fpm.d
   default php.ini: /opt/php-8.0/etc/php.ini
 - PHP 8.1.33 (code='php81', eol='2025-12-31')
   CGI/FastCGI: /opt/php-8.1/bin/php-cgi
   FPM: /opt/php-8.1/sbin/php-fpm
        pool config: /etc/php-fpm/php81-fpm.d
   default php.ini: /opt/php-8.1/etc/php.ini
 - PHP 8.2.29 (code='php82', eol='2026-12-31')
   CGI/FastCGI: /opt/php-8.2/bin/php-cgi
   FPM: /opt/php-8.2/sbin/php-fpm
        pool config: /etc/php-fpm/php82-fpm.d
   default php.ini: /opt/php-8.2/etc/php.ini
 - PHP 8.3.27 (code='php83', eol='2027-12-31')
   CGI/FastCGI: /opt/php-8.3/bin/php-cgi
   FPM: /opt/php-8.3/sbin/php-fpm
        pool config: /etc/php-fpm/php83-fpm.d
   default php.ini: /opt/php-8.3/etc/php.ini
 - PHP 8.4.14 (code='php84', eol='2028-12-31')
   CGI/FastCGI: /opt/php-8.4/bin/php-cgi
   FPM: /opt/php-8.4/sbin/php-fpm
        pool config: /etc/php-fpm/php84-fpm.d
   default php.ini: /opt/php-8.4/etc/php.ini
 - PHP 8.5.0 (code='php85', eol='2028-12-31')
   CGI/FastCGI: /opt/php-8.5/bin/php-cgi
   FPM: /opt/php-8.5/sbin/php-fpm
        pool config: /etc/php-fpm/php85-fpm.d
   default php.ini: /opt/php-8.5/etc/php.ini
 - PHP 8.4.11 [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
Checking for FTP server software:
 - Found 'proftpd' FTP server
   Version: '1.3.8c'
   Package version: '1.3.8.c+dfsg-4'
Checking for SMTP server software:
 - Found 'postfix' SMTP server
   Version: '3.10.4'
   Package version: '3.10.4-1~deb13u1'
   DANE/TLSA support: 'yes'
   ClamAV: '1.4.3+dfsg-1'
   Postgrey: '1.37-2.1'
 - found SpamAssassin (package version: '4.0.1-5')
   configured: yes
 - found OpenDKIM (package version: '2.11.0~beta2-9.1+b1')
   configured: yes
Checking for POP/IMAP server software:
[51543] [2025-11-03 10:41:56.609986] [INFO] [LUA]LC.exec(grep -q '^mail_plugins = quota' /etc/dovecot/dovecot.conf): exited with return code 1
 - Found 'dovecot' POP/IMAP server
   Version: '2.4.1'
   Package version: '1:2.4.1+dfsg1-6+deb13u1'
Checking for database server software:
 - Found 'MariaDB' database server
   Version: '11.8.3'
   Package version: '1:11.8.3-0+deb13u1'
Checking for DNS server software:
 - Found 'bind' DNS server
   Version: '9.20.15'
   Package version: '1:9.20.15-1~deb13u1'
   DNSSEC support: yes
Done.
______________________________________________________________________________
Copyright (c) 2009-2025 LiveConfig GmbH.             http://www.liveconfig.com

Fehlerbild: Bei Aufruf von epgw.baeumel.com oder auch der IP-Adresse 49.13.39.53 (die beide NGINX zugewiesen sein sollten) bekomme ich im Firefox "Verbindung fehlgeschlagen".

Vielen Dank für die Erklärung.

Es handelt sich natürlich nur um eine Einzel-Lizenz.

Konkret hätte ich - wenn es meine Finanzen denn einmal erlauben - gerne auf jährliche Rechnung ggf. umstellen wollen.

(Oder eventuell auch einmal für eine Lizenzkündigung...)

Liebe Alle,

da ich mit der Liveconfig 3 noch so meine liebe Not habe (Webseite kann nicht aufgerufen werden bei Webserver NGINX; auch der Aufruf der dem NGINX zugeordneten IP-Adresse des Servers liefert kein Ergebnis z.B. eine Defaultseite) wollte ich den leeren Debian 13-Server wieder mit Liveconfig 2 bestücken.

Das Installscript bricht jedoch bei der Installation des Meta-Packetes ab; er motzte - nach freier Erinnerung - an, dass er irgendwelche gewünschten PHP5-Pakete nicht finden könne.

Nun frage ich mich:

Wäre es nicht auch möglich alle grundsätzlich benötigten Komponenten die das Meta-Package enthält einfach händisch zu installieren?

Gibt es irgendwo eine Liste aller grundsätzlich benötigten Pakete bzw, des Inhaltes des Meta-Pakets?

Grüße,

MacGyver

Liebe alle,

Liebe LiveConfig GmbH,

Sehr geehrter Herr Keppler ( kk),

ich muss nun leider die Form der öffentlichen Ansprache wählen, insbesondere da meine zwei Support-Tickets (LC#2025051434000015 und LC#2025092934000043) bisher nicht beantwortet wurden.

Ich habe leider keine Zugangsdaten für das Lizenzportal unter https://www.liveconfig.com/license/ erhalten. Die Passwort-Rücksetzung des Lizenzportals scheint leider auch nicht zu funktionieren.

@Alle: Gibt es Hinweise was ich tun könnte? Bzw.: Wie sähen denn die Zugangsdaten zu Lizenzportal üblicherweise aus? E-Mail-Adresse der Bestellung und Passwort oder ganz anders?

Beste Grüße,

Angus MacGyver

Ich kann mir mit Hilfe durch stackoverflow selbst antworten:

1) Man füge Symlinks zur jeweiligen PHP-Binary unter /usr/bin/ ein:

ln -s /opt/php-8.3/bin/php /usr/bin/php83

ln -s /opt/php-8.4/bin/php /usr/bin/php84

2) Dann kann bei der jeweiligen Scriptausführung im CLI angeben mit welcher PHP-Binary das Script ausgeführt werden soll:

php83 /var/www/web4/htdocs/tempest.php --epg config=schedulesdirect1

Hallo zusammen,

ich hatte versucht mein mittlerweile "berühmtes" PHP-Script nun über die Command Line auszuführen mittels

php /var/www/web4/htdocs/tempest.php --epg config=schedulesdirect1

erhalte hier in der Folge dann einen Fehler:

PHP Fatal error: Uncaught Error: Call to undefined function simplexml_load_file()

Nachdem die herkömmliche Scriptausführung über Browser im Gegensatz jedoch problemlos funktioniert; scheint es mir, dass der PHP-CLI-Aufruf mit einer anderen PHP-Version läuft als die übliche Remote-Ausführung im Browser. Ich vermute hier konkret, dass die PHP-CLI mit dem "Distro-PHP" läuft wohingegen die "Browser-Ausführung" mit der jeweils im Webhosting festgelegten "Zusatz-PHP-Version" (installiert vom Liveconfig-Repo) läuft.

Frage also:

Wie kann ich mittels Command-Line-Aufruf die passende bzw. gewünschte PHP-Version spezifizieren mit deren Hilfe das Script ausgeführt wird?