Nein, das ist aktuell nicht möglich: Die PHP-Konfiguration kann nur auf Vertrags-Ebene gesetzt werden.
Auf open_basedir würde ich im Übrigen gar nicht vertrauen: Aufrufe wie 'system("cat /var/www/foo/htdocs/wp-config.php");' werden von open_basedir nicht eingeschränkt.
Wir empfehlen unseren Kunden daher aktuell, bei relevanten Trennungen zwischen Webseiten auf verschiedene Accounts zu setzen. Linux-Dateisystem-Rechte verhindern obigen Fall nämlich sauber.
for f in /var/www/*/tmp; do
home=$(dirname $f);
u=$(stat -c %U "${home}/priv}"
g=$(stat -c %G "${home}/priv}"
dir="${home}/.ssh"
test -d $dir || mkdir $dir
chmod 0700 $dir
chown $u:$g $dir
touch $dir/authorized_keys
chown $u:$g $dir/authorized_keys
chmod 0600 $dir/authorized_keys
doneMal kurz runtergetippt. Sollte klappen - die beiden stat hab ich nachgeschaut.
Die Datei wird nur angelegt, wenn du php-opt-8.2 aus dem LiveConfig Repository installierst.
Bitte prüfe die php82.lua:
# cat /etc/liveconfig/lua.d/php82.lua
-- register additional PHP interpreter with LiveConfig
LC.web.addPHP( {
['id'] = 'php82',
['cli'] = '/opt/php-8.2/bin/php',
['cgi'] = '/opt/php-8.2/bin/php-cgi',
['fpm'] = {
['bin'] = '/opt/php-8.2/sbin/php-fpm',
['start'] = 'service php82-fpm start',
['stop'] = 'service php82-fpm stop',
['reload'] = 'service php82-fpm reload',
['pool'] = '/etc/php-fpm/php82-fpm.d',
['sockets'] = '/run/php82-fpm'
},
['eol-date'] = '2025-12-08'
} )Vermutlich ist hier etwas durcheinander gekommen - zumal bei dir als codename "php8" angegeben ist.
FTP (Systembenutzer) = SSH.
Wir haben die dnswl.org eingebunden.
Das sieht nach Server-Problem aus. Was steht in den Logs von LiveConfig?
Der Kunde nutzt die Passwort-Vergessen-Funktion. Dabei wird dann auch 2FA deaktiviert.
Tipp: überall etckeeper installieren. Da ist dann das gesamte /etc-Verzeichnis in einem Git-Repository, das regulär genutzt werden kann (git diff, log, checkout alter Revisionen).
Bitte prüfe, dass der LiveConfig-Client läuft - und was dort im Log steht. Prüfe auch, ob/dass der Client in der "Serververwaltung" als "verbunden" markiert ist.
Wir haben öfters den Fall, dass der Client abschmiert.
Das ist nicht gut. Das setzt vermutlich zwingend die dauerhafte Nutzung von RoundCube voraus. Das passiert so aber nicht. Die Leute nutzen Ihr Smartphone und die native MailApp.
Dem habe ich nicht widersprochen.
ZitatAber vielleicht könnte man das Plugin nutzen um einen eigenen Poller zu bauen und zu füttern, der die Mails dann als Dienst im Hintergrund periodisch abruft.
Genau das macht das Plugin doch: es pflegt Einträge, die dann periodisch vom "fetchmail.pl"-Cronjob durchgegangen und die Mails dann abgeholt werden.
Selbst noch nicht getestet.
Warum Webmail? Jeder Nutzer sollte den Sammeldienst selbst verwalten können. Die Einstellungen haben also nichts in der Postfach-Verwaltung von LiveConfig verloren - bestenfalls noch nach dem Login in LiveConfig mit den Zugangsdaten des Postfaches. Diese Funktion widerrum wird aber so gut wie niemals genutzt - der Sammeldienst passt IMHO daher am besten in den Webmailer.
Gehört IMHO eher Richtung Webmailer, beispielsweise bei RoundCube:
PEAR ist eine Sammlung an nicht-verschlüsselten/hashten/compilierten PHP_Scripts, die einfach nur im "include_path" liegen. Wie die da hinkommen, oder welcher include_path das ist, ist sekundär.
Die LiveConfig-PHP-Versionen bringen jeweils das PEAR-Binary mit, z.B. in /opt/php-8.2/bin/pear, so dass darüber die Skripte installiert werden können.
2023 würde ich jedoch dazu raten, auf Composer zu setzen und die Requirements dort statisch mit festen Versionsnummern zu definieren.
Die Anzeige ist ... suboptimal.
Technisch klappt's: mail._domainkey.foobar.dollmaier.net hat sauber den TXT-Eintrag bekommen.
Im Webinterface steht dennoch "mail._domainkey IN 300 TXT...".
Das ist im ersten Moment verwirrend, da der Name der (Sub-!)Domain noch mit dran muss. Dann würd's stimmen.
Intern passiert das via "$ORIGIN SUBDOMAIN..." auch.
Da könnte aber der vollständige DNS-Eintrag angezeigt werden, um das klarer zu machen ("mail._domainkey.foobar.example.com. IN TXT...").
Du kannst bei allen Domains die Domain (ohne www) öffnen, ggf auf die "Standard"-Ansicht wechseln (keine Experten-Ansicht) und nun den Haken für "www identisch" setzen.
Eine Bulk-Option besteht aktuell nicht.
RoundCube erlaubt, IMAP und "allgemeine" Logs zu schreiben.
Was steht nach dem Anmeldeversuch in diesen Logs?
"apache2ctl -S" prüfen: das sieht danach aus, als ob der vHost nicht sauber erstellt ist.
Allerdings würde ich davon abraten, den Hostname als Web-Adresse zu verwenden. Der ist allgemein schwieriger (vgl Default-vHost-Fallback).
Zuletzt, unabhängig davon: "addressesResolved" hat nur IPv4-Adressen. Gibt's Probleme mit IPv6?
Soweit alles so befolgt und eingestellt, Seite wird aber nach wie vor als unsicher angezeigt :confused:
Screenshot/URL?
Wird wirklich HTTPS benutzt, oder werden Inhalte über HTTPS eingebunden?
vgl auch https://movingtohttps.com/
Die Subdomain "www.post" müsste zusätzlich als Subdomain erstellt werden (sinnvollerweise mit Weiterleitung auf "post.radio...de").
Technisch aber nicht nötig, es funktioniert alles auch ohne das "www." vorne dran - also einfach den www-Haken beim SSL-Zertifikat weglassen.
"core dumped" ist ein Hinweis, dass im Binary was nicht passt - und kein direkter Fehler von LiveConfig.
Was passiert beim manuellen Aufruf von "/opt/remi/php81/root/usr/bin/php-cgi"? mit "-q", bzw mit "-v"?
Im Kernel-Log sollten sich noch weitere Hinweise finden (nach dem Aufruf).
