Beiträge von Sumeragi

Konnte man nicht ein SE-Update forcieren? Ansonsten muss bis zum nächsten Update gewartet werden und geprüft werden.

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

jquery-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

jquery-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:

<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:

Software 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

Zitat von kai

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.

Zitat von kai

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.

Zitat von kai

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.

Zitat von Twilo

In der Konfigurationsdatei kann TLSv1.3 nicht angegeben werden, um nur TLSv1.3 zu akzeptieren

Code

ssl_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

Alles anzeigen

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

ssl_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.

Zitat von Twilo

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.

Zitat von Twilo

sorry beim Kopieren ist

Code

ssl_dh=</etc/ssl/certs/dh_params4096.pem

leider auf der Strecke geblieben

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

Mozilla SSL Configuration Generator

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