ZitatIch 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 😉
Das hat zumindest bei mir nicht funktioniert. Erst die direkte Angabe auf die php.ini Datei hat bei mir beim php-x.x-cli Aufruf funktioniert.
Aber damals habe ich es noch mit einer älteren Version der SE / PD-Admin Version probiert; vielleicht hat sich das ja jetzt gebessert.
Bei mir funktioniert es mit folgenden Einstellungen perfekt:
| Modus | ClamAV Daemon (Socket) | |
| Socket | /tmp/clamd | |
| Länge des Datenstroms | 26214400 | Byte |
| Dateigrößenbeschränkung, -1 bedeutet kein Limit | -1 | Byte |
| Wenn infizierte Dateien während eines Hintergrund-Scans gefunden werden | Datei löschen |
Nur mal so zur Info:
Die intl.so Meldung bekommt man auch, wenn beispielsweise der Nextcloud cron-Job "cron.php" regelmäßig ausgeführt werden soll.
Wer das beispielsweise in seiner crontab einträgt, sollte daran denken den Pfad zur php.ini mitzugeben:
/usr/local/pd-admin2/bin/php-7.4-cli -c /home/<user>/php.ini -f /home/<user>/<domain>/<pfad zur Nextcloud Instanz>/cron.php
Anderenfalls habt ihr auch wieder die Meldung mit der Fallback implementation.
Nach Prüfung:
Ich kann den Fehler bestätigen; das tritt bei mir genauso auf.
Nach Downgrade auf pd-admin 4.66 läuft auch alles wieder mit dem Apache 2.4 reibungslos.
ob jetzt ein Austausch der /opt/pdadmin/bin/httpd_vhosts.pl auch schon ausgereicht hätte, habe ich nun nicht probiert.
Und mit welcher Ownership hast du da die Dateien gemacht. Eine autoconfig.php mit UID 0 würde ja nicht ausgeführt werden?!
Meine Top 3:
Muss: IPv6 Support verbessern
Optional: Fail2Ban standardmäßig integrieren
Optional: Notwendige Bibliotheken installieren, damit man Jitsi Meet leicht integrieren kann
Letzteres muss ich derzeit umständlich über einen Docker Container abbilden
Hmmm .... ich habe mal die alten pd-Admin Versionen angeschaut:
Das ist schon mindestens seit pd-admin 4.20 disabled. in pd-admin 4.18 war es jedenfalls noch aktiv.
Entweder ein Versehen oder man hat ein Problem entdeckt und es nie gefixt.
Ich steh grad am Schlauch.
An welcher Stelle haben wir eine Zwei Faktor Authentifizierung?
Ausschließlich bei der Debian Beta Version gibt es in der administrator_menu.conf einen Eintrag "350" zur Zwei Faktor Authentifizierung.
Im normalen Build (v4.63) ist das noch nicht enthalten.
Man mag jetzt raten, ob das demnächst für alle kommt oder etwas ist, was der Debian Distribution vorbehalten bleibt.
Ich habe das gerade mal bei mir nachvollzogen:
a) simscan weist auch bei mir das gleiche Verhalten auf
b) ein strings /usr/local/pd-admin2/qmail/bin/simcan|grep spam_ zeigt auch nur spam_passthru als Text an, spam_hits taucht nirgendwo auf
c) /usr/local/pd-admin2/qmail/bin/simscan -v sagt als Version: 1.4.0
Ich weiss jetzt leider nicht, mit welchen Optionen simscan kompiliert wurde, aber die der pd-admin Umgebung mitgelieferte simscan binary ist in der Hinsicht stur und weist bei spam_passthru=no immer ab 5.0 alles ab.
Alte Foren-Beiträge aus 2006 - 2008 von Daniel Bradler sagen, das würde gehen.
Da würde ich mir wünschen, das diese Option (wieder) aktiviert wird, damit ich zumindest die eindeutig höheren spam-Values pauschal abweisen könnte.
Hallo,
ja, das habe ich auch gedacht. Aber dann habe ich folgenden Artikel gefunden:
Artikel von heinlein-support.de zu rspamd
Und heinlein ist sehr aktiv in diesem Feld unterwegs.
Das Resümee scheint mir zu sein, das beide Plattformen anfangs ähnlich effektiv sind, die Lernkurve bei rspamd jedoch etwas langsam ansteigt, dafür aber am Ende effektiver ist. Aber ich bin da eher Laie, deswegen wäre ich für Feedback hierzu dankbar.
Hallo zusammen,
ich habe nach wie vor trotz Einsatz von spamassassin und vieler Optimierungen der Konfiguration weiterhin regelmäßig mit viel Spam zu kämpfen.
Im Internet habe ich gelesen, das es rspamd gibt und dieses wesentlich effektiver sein soll.
Hat hier jemand schon Erfahrungen mit sammeln können?
Es läßt sich wohl sowohl in dovecot als auch in sendmail einklinken.
Ich würde mir wünschen, das dies als alternative Option in künftigen Server-Umgebungen von pd-admin mit berücksichtigt wird.
Hallo zusammen,
ich habe gerade gesehen, das Roudcube 1.4.1 als Stable veröffentlicht wurde.
Wird diese Version demnächst in die PD-Admin Server Umgebung mit aufgenommen?
Das sollte zwar eigentlich keine Rolle mehr spielen, aber hast du mal geschaut, ob die richtige Perl Version verwendet wird?
Früher musste man die Datei /usr/bin/perl durch eine symbolischen Link auf /usr/local/pd-admin2/bin/perl ersetzen.
Tat man es nicht, konnte es passieren, das der Standard Perl Interpreter des Linux Betriebssystems aufgerufen wurde, der natürlich seine eigenen Klassen aufrief und nicht die Klassen der PD-Admin Installation kannte.
Welche PHP Version hast du denn für die NextCloud Installation verwendet?
Es gibt einen dokumentierten Bug: PHP Bug 78516
Der bewirkt, das der Password Hash nicht korrekt ausgelesen und geschrieben wird.
Abhilfe war wohl in der Nextcloud Installation in der Datei hasher.php die Größe der Memory Cost auf =>8 einzustellen;
dann funktioniert wohl alles.
Ist übrigens ein Bug, der nur CentOS 7.6 in Verbindung mit PHP 7.3 betrifft.
Ich verwende bisher DKIM nicht, zumal ich hier seitens Herrn Bradler keine Info über den Support desselbigen gesehen habe.
Auch ohne DKIM kann ich alle Mails an Google zustellen. Voraussetzung ist allerdings, das der Server nicht geblacklistet ist.
Ich empfehle daher, vorher über folgende Adresse zu prüfen, ob der Server irgendwo geblacklistet ist und dann ggfs. diese Problem zu bereinigen:
Hallo,
ich habe aktuell den Fall, das das Passwort eines Users gepwned wurde und unter Verwendung des Roundcube Clients massenhaft Spam-Mail versandt wurde (konkret mit dem roundcube 0.95, welcher in der pd-admin SE Umgebung noch enthalten ist.
Das führt dann in der Regel zu einem raschen Blacklisting und damit natürlich zum Lahmlegen des Servers, weil die "ordentlichen" Mails nicht mehr von den anderen Mailservern angenommen werden. Da man das nie ganz ausschließen kann, möchte ich den Roundcube Client besser absichern.
Hat jemand eine Idee, wie man die roundcube Mail-Konfiguration besser absichern kann?
Ich habe Parameter gesehen für ein Delay des SMTP Versands sowie die Begrenzung der maximalen Anzahl von eMail-Adressen in einer Mail.
Aber vielleicht gibt es ja sinnvollere Methoden? Hat jemand eine Idee?
Hallo,
nach Installation der pd-admin Version 4.60 habe ich unter dem Punkt "Einstellungen" als letzten Eintrag stehen:
Pfad zur .htusers für Kibana-Proxy ....
Was hat es damit auf sich? Habe ich da ein Feature verpasst?
Vielleicht einfach mal den opcache aktivieren:
- in php.ini "zend_extension = opcache.so" eintragen
- falls PHP als FPM läuft, den entsprechenden service in /service mit svc -d FPM-xxxxxx; svc -u FPM-xxxxxx neu starten.
Nur so als schnelle Idee.....
Hallo,
bei der Sichtung des Logfiles zum Cronjob für die Funktion "letsencrypt -all" ist mir aufgefallen, das für diverse Subdomains kein Zertifikat ausgestellt wird.
Hierbei wird immer folgendes protokolliert:
|
Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for subdomain.domain.de Using the webroot path /opt/pdadmin/etc/ssl-validation for all unmatched domains. Waiting for verification... Cleaning up challenges Failed authorization procedure. subdomain.domain.de (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://subdomain.domain.de/.we…YXr-VOBvsbQyqxuncFh92nV0s: q%!(EXTRA string=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html ) IMPORTANT NOTES: - The following errors were reported by the server: Domain: subdomain.domain.de Type: unauthorized Detail: Invalid response from http://subdomain.domain.de/.we…YXr-VOBvsbQyqxuncFh92nV0s: q%!(EXTRA string=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html ) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. certbot-auto failed############################### |
Bei Prüfung habe ich festgestellt, das diese Domains alle einen Redirect auf eine andere Adresse durchführen (Redirect 301), weil es so vom Kunden konfiguriert wurde.
Aus meiner Sicht dürfte hier entweder:
- gar kein letsencrypt Versuch gemacht werden, da die ggfs. externe Quelle bzw. der andere Pfad kein Anlegen des Challenge Files zuläßt
- oder in dem Container mit dem Redirect müsste auch eine alias-Konfiguration erfolgen, was aber nicht passiert.
Hat jemand anders von euch auch dieses Problem und wenn ja, wie geht ihr damit um?
Was das Ablehnen der Mails betrifft, so hat sich das mittlerweile wohl erledigt, denn die geänderte DNS-Adresse ist durch Replikation wohl endlich bekannt. Das Problem mit den Log-Einträgen hat sich aber nicht gelöst.
Soweit ich es bis jetzt feststellen konnte:
Dieser Log-Eintrag wird jedesmal erzeugt, wenn ich eine eMail an eine .gmail.com Adresse schicke.
So richtig verstehe ich das nicht, denn ich verwende auf meinem Server nur IPv4, weil mein Provider kein IPv6 anbietet.
Folglich erhalte ich bei DNS-Anfragen eigentlich auch immer nur die IPv4 Adressen zurück.
Daher verstehe ich nicht, warum qmail-remote eine Auslieferung an eine IPv6 Adresse versuchen sollte.
Es sei denn, die Information wird im Rahmen des Advertisements vom externen Mailserver angepriesen?!
Vielleicht hat ja einer noch eine Idee ....
