Beiträge von tbc233

Ich hab intern eine VM mit einem Uralt System die ich manchmal für diverse Testzwecke hochfahre. Wenn ich mit dieser SSL Verbindungen nach außen aufbauen möchte, krieg ich auch gerne mal die "unable to get local issuer certificate" Meldung, weil der lokale Zertifikatsspeicher mit den Root-CAs etc. hoffnungslos veraltet ist und die Authentizität des entfernten Zertifikats daher nichts verifiziert werden kann. Das wurde mit dem großen Zertfikatswechsel bei Letsencrypt vor zwei oder drei Jahren dann nochmal erheblich häufiger.

Will sagen: Für mich klingt es so als wäre Dein Set an Root CAs veraltet.

Somit kannst Du entweder schauen, dass Du die auf der Paperless Maschine auf Stand kriegst (Paket heißt meistens zb. "ca-certificates" bei vielen Distributionen) oder Du bringst Paperless dazu, auf die Verifizierung des Zertifikats zu verzichten.

Wenn es Paperless zulässt, wäre auch die Verwendung von unverschlüsseltem IMAP denkbar - muss man dann selbst abwägen ob man das möchte.

Ah, hab ich vergessen zu erwähnen. Ich hab das sowohl bei Reihe 4 als auch bei Reihe 6 so gesehen. Denke nicht dass hier ein Zusammenhang mit der Reihe besteht.

yep, kann ich bestätigen. Meldung tritt bei mir auch auf.

Interessant, weil die korrekte php.ini hätte aus meiner Sicht auch vorher mit den direkten Verweisen auf das cli binary gezogen werden sollen.

Aber freut mich, wenn ich was beitragen konnte

Zitat von pumi

Ich muss nach jedem Update in den Cronjobs die Pfade ändern, da nach einem php Update die verwendeten Pfade nicht mehr stimmen.

Grundsätzlich gib es für jeden php Zweig immer einen Symlink unter /usr/local/pd-admin2/bin/ , den Du hier verwenden kannst. Zum Beispiel /usr/local/pd-admin2/bin/php-8.2-cli für die aktuelle 8.2 cli.

Random Beispiel von meinem Testserver

/usr/local/pd-admin2/bin/php-7.0-cli -> /usr/local/pd-admin2/php-7.0.33/bin/php-cli
/usr/local/pd-admin2/bin/php-7.1-cli -> /usr/local/pd-admin2/php-7.1.33/bin/php-cli
/usr/local/pd-admin2/bin/php-7.2-cli -> /usr/local/pd-admin2/php-7.2.34/bin/php-cli
/usr/local/pd-admin2/bin/php-7.3-cli -> /usr/local/pd-admin2/php-7.3.33/bin/php-cli
/usr/local/pd-admin2/bin/php-7.4-cli -> /usr/local/pd-admin2/php-7.4.33/bin/php-cli
/usr/local/pd-admin2/bin/php-8.0-cli -> /usr/local/pd-admin2/php-8.0.30/bin/php-cli
/usr/local/pd-admin2/bin/php-8.1-cli -> /usr/local/pd-admin2/php-8.1.31/bin/php-cli
/usr/local/pd-admin2/bin/php-8.2-cli -> /usr/local/pd-admin2/php-8.2.27/bin/php-cli
/usr/local/pd-admin2/bin/php-8.3-cli -> /usr/local/pd-admin2/php-8.3.15/bin/php-cli
/usr/local/pd-admin2/bin/php-8.4-cli -> /usr/local/pd-admin2/php-8.4.2/bin/php-cli

Damit ersparst Du Dir das Nachziehen nach jedem Update.

Sorry, ich hab überlessen dass es um Subdomains geht und hatte nur die "www" Verzeichnisse gecheckt.

Es stimmt, für Subdomains kann ich den Bug bestätigen.

Ich hab mal ein paar Accounts random durchgeklickt, ich kann den Fehler bei mir nicht nachvollziehen. Verzeichnisse sind stets alle geschützt.

Zitat von Eisenherz

Es könnte auch daran liegen, dass vielleicht bei der PHP-Version von pd-admin bestimmte Module nicht aktiv sind. Ich meine, mich erinnern zu können, dass ich da noch Module aktivieren musste, bevor das lief.

Das stimmt, aber wenn er sagt dass er das "nicht-funktionieren" durch entfernen des debian eigenen PHP reproduzieren kann, muss es damit zu tun haben.

Ich denke mal, der Webserver verwendet sicher kein fremdes php. Blieben noch CLI Aufrufe. Hier könnte man ja mal testweise /usr/bin/php auf das jeweilige php der Standardumgebung symlinken - so als Test.

War es eine bewussste Entscheidung, hier ein lokal installiertes PHP ins Spiel zu bringen?

Ich hab jetzt bei Nextcloud nur Grundwissen, aber ich wüsste jetzt nicht (massive händische Eingriffe ausgenommen) wie ich ganz allgemein im Kontext der Standard Server Umgebung eine Webapplikation dazu bringen könnte, ein externes PHP zu benutzen. Aber möglicherweise macht Nextcloud diverse php-cli Aufrufe, die das lokale php ansprechen.

Frage nur zur Sicherheit, diesen Eintrag für die Spamhaus Zen habt ihr händisch gemacht, oder?

Oder wird das so in der SEU ausgeliefert?

Zitat von monderka

Der Debian-Server UND der PD-Admin laufen unter dem namen server1.meinname.de welcher mit einem A-Record auf die IPv4 hinterlegt ist.
Legen ich dann für den gleichen Namen auch einen AAAA Eintrag an, ist die PD-Admin-Oberfläche nicht mehr erreichbar.

Das ist richtig, das Problem ergibt sich dann tatsächlich (wenn man dann von einem ipv6 fähigen Internetzugang auf die pd-admin Oberfläche zugreifen möchte).

Dein Workaround mit einem anderen, reinen IP4 Hostnamen ist soweit auch okay, sollte aber keine Mailprobleme auslösen.

Entscheidend ist, dass der Reverse DNS Eintrag (PTR) für ipv6 und ipv4 auf den tatsächlichen Namen verweist.

Meiner Erinnerung nach musste ich beim letzten Mal den Namen auch noch in /var/qmail/control/me ändern. Ansonsten hat sich der Server in SMTP Dialogen noch mit dem alten Namen gemeldet, was Streß brachte wenn dies nicht mit dem PTR Record zusammenpasst.

Genau, so wars. Danke.

Das dc-install Script wird ja gar nicht mehr gebraucht.

Der Thread auf den Du Dich beziehst, ist stark veraltet. Er stammt aus der Zeit, als die pd-admin Umgebung von sich aus noch kein SSL auf diesen Diensten angeboten hat, daher haben das damals einige über stunnel (ein SSL Proxy vereinfacht gesagt) gelöst. Diese Lösung würde ich so nicht mehr einsetzen.

Soweit ich das zuletzt beobachtet habe, wird nun bei einer neu Installation automatisch ein Zerti von letsencrypt geholt sofern man es aktiviert in den Servereinstellungen und dann spätestens über den nächsten Lauf des Cronjobs soweit alles installiert.

Solltest Du das ganze im Nachhinein nachrüsten wollen, musst Du die Zertifikatsfiles in /opt/pdadmin/sslcerts ablegen (servername-key, servername-cert, servername-cacert) und dann gabs da ein Script namens "dc-install.sh". Ich finde den Download Link allerdings grad um die Burg nicht und will hier nicht eine veraltete Version rein stellen. Vielleicht kannst Du hier beim pd-admin Support um das Script nachfragen oder jemand kann den Link hier posten.

danke für Deine Recherche und Einschätzung.

Ich selbst habe ja, da ich ohnehin primär von mir betreute Projekte hoste, seit Jahren für das phpMyAdmin Verzeichnis nochmal einen htaccess/htpasswd Schutz drüber gestülpt.

phpMyAdmin hat ein Security Release raus gegeben. Ich konnte mich mit den Schwachstellen noch nicht genauer beschäftigen. Würde um Aufnahme in die Serverumgebung bitten

phpMyAdmin 5.2.2 is released

www.phpmyadmin.net

Ich hab es mal durchgezogen mit dem Script. Ging relativ schnell, weil der betroffene Server nicht viele Datenbanken hat.

Während das Script läuft und insbesondere während das SE Update gemacht wird, hagelt es eine ganze Menge Fehlermeldungen, die aber wohl im Kontext der Migration normal sind, schließlich wird ja das mysql Verzeichnis vorher weg gemoved etc.

Soweit schaut alles gut aus, läuft alles.

Alles klar, Danke. Dass es keinen direkten Upgrade Weg gibt, war mir klar. Aber dachte dass vielleicht die die se-update.sh Prozedur bei einem entsprechenden -s Aufruf vielleicht von sich aus selbst das Script anwirft.

Hallo,

Sorry, muss mal wieder mit dem MySQL Upgrade Thema um die Ecke kommen.
Ich habe bisher keinerlei Reihen bzw. MySQL Upgrades selbst gemacht, aber hier immer ein bisschen mitgelesen zu dem Thema. Nun möchte ich einen Server von MySQL 5.5 auf 5.7 upgraden. Braucht es dazu dieses externe Script hier noch? Oder erledigt das nun schon das se-update Script mit dem entsprechende "-s 6" Aufruf?

Danke

Ich krame mal diesen Uralt Thread raus (vielleicht hilft es mal jemandem), da ich gerade das selbe Problem hatte. Dieser Zustand führt auch zu einer relativ hohen CPU Auslastung und teilweise sehr hohen Verzögerungen bei der Mail Zustellung.

Das Problem dürfte hier sein, dass die Bayes Datenbank beschädigt ist. Das Entfernen des Lock Files alleine bringt hier keine Abhilfe. Geholfen hat mir hier nur, alle Dateien in /var/spamd/.spamassassin zu entfernen (Serverumgebung vorher stoppen). So wird dann wieder eine neue Datenbank angelegt.