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).
was war's denn? (vgl https://xkcd.com/979/ )
Aktuell nein.
Wir legen bei größeren Anforderungen (eigene Pools, ...) die Subdomain in einen eigenen Vertrag.
Bisher nicht, Ticket dazu ist aber schon eröffnet.
Wegen DKIM/DMARC eigentlich ein "must-have", nicht nur "nice to have".
Dass hier spannende Zusatz-Probleme folgen (Stichwort Reseller-Mails/Absender!), ist leider auch klar.
Ist in der liveconfig.conf der "http_canonical_host" auf die öffentliche URL gesetzt?
Hallo,
aktuell kann eine Domain nicht direkt verschoben werden - die Domain müsste im alten Vertrag gelöscht und im neuen Vertrag neu erstellt werden.
Danke - das Paket fehlte mir auch noch.
Last but not least wird die 2.15 voraussichtlich die letzte Minor-Release-Serie vor Version 3 sein.
Hui!
Ich stell schon mal das Bier kalt 
RECURSIVE=1 /usr/lib/liveconfig/lcservice.sh fix-permissionsWurde das Zertifikat ggf beim Reseller/Admin angelegt?
Schwierig. Ein öffentlicher SMTP-Server muss gemäß RFC3207 auch unverschlüsselte Verbindungen erlauben. Prinzipiell ist es aber möglich, Postfix so zu konfigurieren dass bei bestimmten Empfängerdomains nur verschüsselte eingehende Verbindungen erlaubt sind (reject_plaintext_session)
Das klingt doch nach DANE / MTA-STS ...
warnquota kann in /etc/default/quota aktiviert werden.
Empfänger ist jedoch der User selbst (sprich, Vertragsname). Eine Weiterleitung gibt es nicht, da LiveConfig keine Mailadresse für einen Nutzer erzwingt.
Der Linux-Dienst hilft einem so also nichts.
Wir haben einen eigenen Dienst geschrieben, der die LiveConfig-Datenbank abfragt und dann die Mails "sauber" via SMTP verschickt - wenn eine Mailadresse existiert.
Hallo,
Allerdings fände ich es großartig, wenn in den nächsten Updates eine Funktion kommt, mit der Domains auch HTTP-Protokoll unabhängig erstellen kann. Zum Beispiel, dass ich Domains hinzufügen kann, die im Virtualhost auf einen von mir festgelegten Port hören und nicht nur Port 80 oder 443.
Warum?
Konkret: die HTTP-Validierung von SSL-Zertifikaten erfordert bei Let's Encrypt, dass HTTP/HTTPS (80/443) auf den CN/SAN des Zertifikates erreichbar sind. Bei anderen Ports kann somit keine Validierung erfolgen.
