Konnte man nicht ein SE-Update forcieren? Ansonsten muss bis zum nächsten Update gewartet werden und geprüft werden.
Beiträge von Sumeragi
-
-
Im Update Skript finde ich nichts zu "cron". Auch nicht im tarball der SE (geprüft bei Reihe 8). Müsste man einmal testen und verifizieren, ob bei einem Update aus kommentierte Zeilen entfernt werden.
-
Unter /usr/local/pd-admin2/dovecot-2.2/etc/dovecot.tmpl sind Templates der Konfigurationsdateien. Änderungen dort werden auch bei einem SE Update übernommen.
-
Ich würde mir dazu einmal
PHP: INI-Einstellungen für die Sicherheit von Sessions - Manual
anschauen. Über die Einstellungen kann man Sessions sicherer gestalten.
-
Wenn man sich unsicher ist, am besten einfach einen neuen Thread erstellen
Man kann keine Wildcard Einträge wie @*.shop anlegen. Am besten ist es sich zunächst die Mail-Header der Mails anzuschauen. Eventuell kommt der Spam von einem Server, den man dann blocken kann.
-
Wofür wird der Hotfix noch einmal benötigt? Adhoc weiß ich nicht mehr wofür der war und im Forum fand ich dazu nichts.
-
Soll nur der Webserver über die eine IP laufen? Den Webserver kann man auf eine IP festlegen, in dem man bei "Listen" im Template eine IP vor dem Port setzt. Man kann dabei mehrere Listen Zeilen setzen.
-
Der Symlink von MySQL ist auf jeden Fall korrekt.
Wenn ich data.inf und data2.inf nach "/var/mysql" grepe, ist in der data.inf die gleiche Zeile wie bei Ihnen, in der data2.inf wird nichts gefunden. Für mich erschließt sich daraus aber noch nicht wo der Dateitypkonflikt sein soll.
-
Dies kann ich bestätigen.
Schritte zur Reproduktion:
Administrator: Einstellungen => Serverkonfiguration => Hilfe
Code: Fehlermeldung Browser Konsolejquery-3.5.1.min.js:2 Uncaught TypeError: e.indexOf is not a function at S.fn.load (jquery-3.5.1.min.js:2:84831) at modal_show_help_ (pdscript.js:52:16) at HTMLAnchorElement.onclick (administrator.cgi?todo=customers.main:72:144) S.fn.load @ jquery-3.5.1.min.js:2 modal_show_help_ @ pdscript.js:52 onclick @ administrator.cgi?todo=customers.main:72
Endkunde: Datenbanken => Übersicht => Hilfe
Code: Fehlermeldung Browser Konsolejquery-3.5.1.min.js:2 Uncaught TypeError: e.indexOf is not a function at S.fn.load (jquery-3.5.1.min.js:2:84831) at modal_show_help_ (pdscript.js:52:16) at HTMLAnchorElement.onclick (customer.cgi?todo=db.main:72:127) S.fn.load @ jquery-3.5.1.min.js:2 modal_show_help_ @ pdscript.js:52 onclick @ customer.cgi?todo=db.main:72
Der Fehler ist beim Administrator und Endkunde identisch. Die Hilfe stammt übrigens aus PDA und hat somit nichts mit der Serverumgebung zu tun.
-
Das Datumsformat kann nicht angepasst werden.
Den Fehler kann ich bei mir nicht reproduzieren. Ich verwende aktuell PDA 4.101, SE 8-0.408 und Oracle Linux.
Für eine mögliche Unterstützung wären mehr Details zu dem Fehler wichtig, wie eben
- Betriebssystem
- pd-admin Version
- Version der Serverumgebung
Angaben "Neuste" ist dabei nicht hilfreich. Ich meine im Forum gab es dafür auch irgendwo eine Vorlage... Bei Fehlermeldungen ist eine genaue Schritt-für-Schritt Anleitung zudem sehr hilfreich. Dann können andere dies gezielt nachstellen und so helfen.
-
Ich nutze Oracle Linux und dort habe ich keine gai.conf. Da es so für mich funktionierte, hatte ich mich nicht näher damit beschäftigt. Die Lösung mit der IP ist da aber sicher die Beste.
-
Bei mir ruft der Proxy den Server immer über die IPv4 Adresse auf. Eine Endlosschleife oder ähnliches habe ich bisher nicht beobachten können. Aber sicherlich sollte ein Aufruf auf per IP und Übergabe des Hostnamens funktionieren.
-
Wenn man ins httpd Template schaut ist dort /usr/local/pd-admin2/htdocs also document root angegeben. Dort befinden sich auch roundcubemail und Co. Ich denke das alles zu ändern ist aufwändiger als einfach wieder eine index.html ins bisherige Verzeichnis zu kopieren
-
Ich hab es ganz einfach mit einem Proxy gelöst:
Apache Configuration
Alles anzeigen<VirtualHost xxxx:xxxx:xxxx:xxxx:xxxx:443> UseCanonicalName off ServerName hostname.des.servers ServerAdmin mail@admin RewriteEngine On ProxyRequests Off <Proxy *> Require all granted </Proxy> SSLProxyEngine On ProxyPass "/" "https://hostname.des.servers" connectiontimeout=5 tmmeout=30 ProxyPassReverse "/" "https://hostname.des.servers/" ProxyTimeout 120 Header always set Content-Security-Policy "default-src http: 'unsafe-inline' 'self' 'unsafe-eval'; script-src http: 'unsafe-inline' 'self' 'unsafe-eval'; style-src http: 'self' 'unsafe-inline'" SSLEngine on SSLCertificateFile /opt/pdadmin/sslcerts/hostname.des.servers-cert SSLCertificateKeyFile /opt/pdadmin/sslcerts/hostname.des.servers-key SSLCertificateChainFile /opt/pdadmin/sslcerts/hostname.des.servers-cacert SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ </VirtualHost>
Dadurch wird auch das Problem mit der Lizenz gelöst.
Der vhost für Port 80 leitet direkt auf HTTPS weiter. Da steht also nicht viel drin.
-
In der aktuellen SE fehlt die index.html unter /ist/local/pd-admin2/htdocs dadurch kommt es zu dem Forbidden Fehler, da keine index.* Datei vorhanden ist und ein list directory nicht erlaubt ist.
Dies führt jedoch zu einem Bug in pd-admin. Wenn man nach "Einstellungen" => "Indexseite des Webserver" geht kommt ein Fehler:
CodeSoftware error: stat </usr/local/pd-admin2/htdocs/index.html> failed: No such file or directory at /opt/pdadmin/www/administrator/administrator.cgi line 8271 For help, please send
Lösen lässt sich das ganz einfach, in dem man die index.html aus einem Backup einer älteren SE zurück kopiert
-
Frage zu den cron jobs:
Warum muss man die letsencrypt jobs manuell hinzufügen?
Erledigt das nicht schon ein andes Script implizit mit?Bei mir ist die letzte Installation schon etwas her, aber da wurden die Cronjobs für let's encrypt automatisch gesetzt. Musste nichts manuell festlegen.
Und braucht man wirklich ein eigenes Script wie regenerate_mail_certs.sh oder ist /opt/pdadmin/bin/update_host_certificate.sh nicht eigentlich auch "cronfähig"
Das update_host_certificate.sh Skript kann einfach per Cron ausgeführt werden. Mache ich mittlerweile auch so.
Der Fehler im Script /usr/local/pd-admin2/share/mkdhparams habe ich im anderen Thread zwar gefixed,
aber die erzeugte Datei wird nach meinem Kenntnisstand nur von Courier-IMAP genutzt.
Kann also wirklich (auch aus pd-admin) entfernt werden.Ja, der Cronjob kann weg, da dieser bei aktuellen pd-admin Versionen nicht mehr benötigt wird.
-
In der Konfigurationsdatei kann TLSv1.3 nicht angegeben werden, um nur TLSv1.3 zu akzeptieren
Codessl_protocols = TLSv1.3 -> Fatal: Unknown ssl_protocols setting: Unrecognized protocol 'TLSv1.3' ssl_min_protocol = TLSv1.3 -> deferral: doveconf:_Fatal:_Error_in_configuration_file_/usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf_line_64:_Unknown_setting:_ssl_min_protocol/
Stimmt du hast Recht, Mein Fehler!
Hatte das mit einem anderen Server verwechselt, der 2.3 verwendet.
Apropos zwecks Fehlermeldungen bzw. Warnungen unter 2.2, keine Einträge im mail.log Log, jedoch startet Dovecot nicht …
-----
Bleibt aber noch die Sache, dass ssl = required, überschrieben wird
Richtig, die Option TLSv1.3 kennt Dovecot 2.2 nicht. Dies wird erst mit Dovecot 2.3 eingeführt. Ebenso wird ssl_min_protocol erst mit Dovecot 2.3 eingeführt. Dies ersetzt ssl_protocols.
TLS 1.3 kann zwar explizit nicht angegeben werden, wird aber unterstützt. Man kann
Codessl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384
setzen. Dann hat man nur noch ECDHE Schlüssel in Verwendung und ist nicht mehr auf ssl_dh_parameter_length angewiesen. Dies sollte dann mehr einer "modernen" Konfiguration entsprechen. Elliptic Curve Schlüssel haben den Vorteil, dass diese weniger CPU-intensiv sind. In der Dovecot Doku wird auch empfohlen DHE Schlüssel zu deaktivieren.
-
apropos modern und Dovecot 2.2 …
# unfortunately, Dovecot 2.2 and OpenSSL 3.0 does not support the modern configuration
Ich habe noch nicht herausgefunden wo es da eine Inkompatibilität gibt. Denn stand jetzt ist, dass die Serverumgebung mit Dovecot 2.2 und OpenSSL 3.0 ausgeliefert wird. Und es funktioniert. Es kann auch TLS 1.3 verwendet werden.
Wenn ich die Dovecot Doku richtig lese unterstützt Doveecot 2.2 "ssl_dh" nicht. Wirft das keinen Fehler oder Warnung aus?
-
Im Grunde betrifft es ja nur die Parameter "ssl" und "ssl_dh_parameters_length". Die anderen Parameter sind ja identisch.
Einen größeren Wert bei ssl_dh_parameters_length muss man nicht setzen, wenn man keine DHE cipher suits konfiguriert. Ein Wert von 4096bit verzögert den (Neu)Start von dovecot und macht es nicht unbedingt sicherer. Eine höhere Sicherheit erreicht man durch die Nutzung von ECDHE cipher suits.
Auch Mozilla schlägt bei intermediate Einstellungen nur 2048bit vor. Bei moderben Einstellungen entfällt dies, da nicht mehr relevant: https://wiki.mozilla.org/Security/Server_Side_TLS
-
Auch wenn dieser Thread schon etwas länger zurück liegt, dachte ich Teile ich kurz mein Wissen
Änderungen müssen unter /usr/local/pd-admin2/dovecot-2.2/etc/dovecot.tmpl/ vorgenommen werden. Dann bleiben diese auch nach einem SE Update bestehen