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.

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

    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


    Code
    /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.

    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.

    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.

    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.

    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.

    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.