Beiträge von Sumeragi

    zu 1)


    Die hängt vermutlich mit der Zustellung zusammen und an welchem Punkt die Signierung stattfindet. Ich nehme an, die Signierung findet beim Verlassen des Servers statt. Wozu sollten auch interne Mails signiert werden? Da ist man ja selbst Absender. IIRC greift bei interner Zustellung z.b. auch kein Spamassassin.


    zu 2) und 3)


    Die DKIM Signierung wurde nur in qmail implementiert. Zumindest wurden entsprechende Pakete in die SE eingepflegt. Mails, welche über qmail versandt werden, werden somit signiert. Alle anderen Mails werden nicht signiert.

    Eine Doppelsignierung erfolgt nur wenn das Skript / die Anwendung Mails signiert und dann über eine Mailbox versendet. Ob dies jedoch problematisch ist, weiß ich nicht.


    zu 4)


    Ich meine Gmail prüft auch auf DKIM und dort wurde mir meine Signatur als valide angezeigt... Müsste ich nur noch Mal nach schauen. Hatte es einmal getestet, wurde als valide angezeigt und damit hatte sich das Thema für mich erledigt :-P

    Dann würde ich einmal /home/user/bin/php mit einem Editor anschauen. Wenn der Haken gesetzt wurde, dann sollte dort die Binary mit der php.ini angegeben sein.

    Ich habe die Ursache gefunden...
    Problem war das ich die php.ini nicht in das Kunden-Verzeichnis, /home/k1xxxdbo/php.ini gesetzt habe sondern erst in das Subdomain-Root: /home/k1xxxdbo/go.domain.de/nextcloud_2020_1_JM/php.ini


    Das hat dazu geführt das nextcloud zwar die php.ini gelesen hat, aber die Plugins die in einem anderen Verzeichnis starten wohl nicht.


    Der Grund warum ich das eigentlich so gemacht habe war weil der der kunde unter http://www.domain.de eine wordpress installation hat und die php.ini nicht die gleiche sein sollte wie die für nextcloud unter go.domain.de.

    Aber mit der gleichen php.ini für beides geht jetzt alles korrekt.

    Nextcloud selbst lädt/liest die php.ini auch nicht, sondern der PHP Interpreter. Dieser lädt immer die php.ini im Home Verzeichnis. Ist dort keine vorhanden wird eine Standard php.ini geladen.


    Wird PHP mittels cgiwrap ausgeführt, kann man per htaccess Datei eine abweichende php.ini angeben. Zum Beispiel

    Code
    SetENV PHPRC /home/user/php-nextcloud.ini

    Bei Verwendung von fpm geht dies nicht, da die php.ini beim Start des fpm Prozesses einmalig geladen wird.


    Die php.ini im Dokument Root der nextcloud Instanz würde ich entfernen. Diese ist dadurch öffentlich abrufbar. Angreifer können so Informationen zur PHP Konfiguration bekommen.

    Wird der Cronjob mit der php-x.x-cli ausgeführt, muss auch eine php.ini angegeben werden. Andernfalls wird nur die Standard php.ini geladen. Wäre also das gleiche Verhalten wie oben.


    Ich würde auch über pd-admin im Endkundenbereich die php-cli setzen und den Haken bei "lokale php.ini verwenden" zu setzen. Dann muss man nur noch ~/bin/php ~/pfad/zu/skript.php beim Cronjob angeben 😉

    Dann wären mehr Informationen hilfreich...


    Ich setze Nextcloud 19 ein. Ausgeführt wird es mit FPM und PHP Version 7.4. Installiert ist die SE 6-0.369. Ich habe keinerlei derartige Meldungen.


    Ich würde auch vermuten, dass die 3rd Party App "Patchwork" hier die Meldungen erzeugt und nicht Nextcloud selbst. Müsste man also einmal schauen welche Vorgaben der Hersteller für die App hat.

    "Insecure dependency in require while running setuid"

    Liest sich für mich als würde eine http Quelle aufgerufen, eine https Quelle aber benötigt/gefordert wird. Ich nutze den Anwendungsinstaller jedoch praktisch nicht, daher wüsste ich auf Anhieb nicht was es sein könnte. Oder wo man schauen müsste... ?(

    Achso meine Ausgabe von /opt/pdadmin/lib war nach da Update auf die 64bit Version.


    /opt/pdadmin/lib/libmysqlclient.so.15.0.0 gibt es nur in der 32bit Version. Die Frage wäre ob nach dem Update immer noch die 32bit Version vorhanden ist.


    Ich habe folgendes gemacht (Befehle aus dem Kopf heraus rekapituliert :) )

    Bash
    cp -ax /opt/pdadmin /opt/_pdadmin
    cd ~
    wget http://download.pd-admin.de/pdadmin_v4_64.tar.gz
    tar xzf pdadmin_v4_64.tar.gz
    cd pdadmin
    ./update.sh

    Dabei natürlich darauf achten, dass im Home Verzeichnis nicht schon ein pdadmin Verzeichnis von einem vorherigen Update liegt.

    Die root Cronjobs können nicht über die Weboberfläche geändert werden. Dies geht nur über die Shell. Ich habe den Cronjob nicht mehr in meiner Liste und auch nach den letzten Updates würde dieser nicht wieder hinzugefügt. Ich kann das beschriebene Verhalten daher nicht nachvollziehen.

    Der Prolient ML 115 scheint mir (laut Google) auch schon was älter? Gab es Systemupdates? Neuer Kernel vielleicht, welcher nicht mehr die Treiber hat? Würde zumindest für ein Softwareproblem sprechen, wenn trotz Wechsel der Hardware das Problem bestehen bleibt (dies ist übrigens kein PDA Bug 😉).


    Ansonsten bräuchte es tatsächlich mehr Informationen wie Distribution, Kernel Version und genauere Hardware Infos.

    Wenn man sich beide Skripte einmal anschaut sind diese praktisch identisch. Ich vermute Mal der Unterschied ist lediglich, dass dc-ssl-install.sh extra heruntergeladen werden muss. update_host_certificate.sh hingegen wird direkt mit PDA mitgeliefert.

    Was für eine Linux Distri wird denn eingesetzt? Wie sieht der Inhalt von /opt/pdadmin/lib/ aus? Insbesondere die libmysql*

    Bash
    $ ll /opt/pdadmin/lib/libmysql*
    lrwxrwxrwx. 1 root root 20 29. Nov 2019 /opt/pdadmin/lib/libmysqlclient.so -> libmysqlclient.so.20
    lrwxrwxrwx. 1 root root 25 29. Nov 2019 /opt/pdadmin/lib/libmysqlclient.so.20 -> libmysqlclient.so.20.3.15
    -rwxr-xr-x. 1 root root 6,6M 26. Okt 11:25 /opt/pdadmin/lib/libmysqlclient.so.20.3.15
    $ file /opt/pdadmin/lib/libmysqlclient.so.20.3.15
    /opt/pdadmin/lib/libmysqlclient.so.20.3.15: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=48aaef8832bcbcd323968bb47dcba584138291b2, stripped

    Ich nutze CentOS 7 mit PDA 4.69 und der SE 6-0.368. Habe heute einfach Mal den 64 Bit tarball heruntergeladen und die update.sh ausgeführt. Kann keine Probleme nach der Ausführung feststellen.

    Als Hostname sollte ein FQDN verwendet werden. Sprich etwas wie server01.domain.de und nicht nur domain.de.

    Man kann auch ruhig domain.de später bei einem Endkunden anlegen. Nur darf/sollte man dann keine Subdomain mit server01.domain.de anlegen. Dann existieren nämlich zwei vhosts mit dem Namen was zu Problemen führen kann.

    Wenn ich nun z.B. die Domain Ihre.Domain.de mit dem Server verwalten will, kann der Server dann mail.Ihre-Domain.de heißen, oder muss ich ihn mail.Ihre-Andere-Domain.de nennen?

    Ja, das ist problemlos möglich. Habe ich auch so bei meinem Server und noch nie Probleme gehabt.

    Es wird nur das Let's Encrypt für den Hostnamen ausgestellt und unter /opt/of admin/sslcerts verlinkt. Entsprechend wird es nur für den Apache (customer, administrator, etc) automatisch konfiguriert.

    Mail, FTP und MySQL müssen weiterhin separat konfiguriert werden.

    Nodejs kann ja jeder Nutzer lokal installieren. Einfach die binaries herunter laden, entpacken und die Binaries nach ~/bin/ verlinken.

    Man kann seit PDA 4.66 Dienste für Nutzer einrichten/starten. Dort kann man dann "~/bin/npm skript.js" eintragen und es sollte laufen. Der Dienst sollte dann auf einen eigenen Port laufen. Dann kann man beim Endkunden unter Subdomains ein Proxy auf den Dienst einrichten.

    fpm:

    Code
    [Sat Aug 01 17:14:38.270719 2020] [proxy:error] [pid 15774] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /service/FPM-solotcbc-7.4.2/socket (*) failed
    [Sat Aug 01 17:14:38.270933 2020] [proxy_fcgi:error] [pid 15774] [client 217.61.194.123:60214] AH01079: failed to make connection to backend: httpd-UDS

    Der Apache bekommt keine Verbindung zum PHP socket. Die Frage ist, wieso.


    Zur Not einmal den fpm Prozess stoppen:

    Bash
    svc -d /service/FPM-solotcbc-7.4.2/

    und

    Bash
    /service/FPM-solotcbc-7.4.2/run

    auf der Konsole ausführen und schauen ob es Fehler gibt.