Hallo zusammen,
ich habe auch gestern schon festgestellt, dass der Fehler das "Score"-Ergebnis nicht wirklich fett macht. Und das mit der Remote-Adresse kann man auch aus Ihrer Sicht, Herr Keppler, sehen und macht auch Sinn. Da hatte ich wohl einen Gedankenwurm drin.
Ich wünsche allen einen guten Rutsch!! (bitte nicht zu wörtlich nehmen).
Guten Morgen,
da habe ich wohl die Mail gestern zu spät getippt. Sollte Clamav heißen und ich habe bereits meinen Post berichtigt.
Ja, die Zeile sieht in etwa so aus wie bei Dir. Es geht mir um folgenden Teil:
"[...] rhost=localhost,raddr=127.0.0.1 [...]"
Hallo zusammen,
mir ist gerade wegen einer Kundenanfrage aufgefallen, dass der Spamassassin immer localhost als Remote-Adresse bekommt.
Folgende Infrastruktur:
- Liveconfig-Server u.a. mit Webhosting
- Mialserver mit Clamav und Spamassassin (lcsam)
Beide Systeme laufen mit Debian.
Alle Mails, welche beim Mailserver ankommen und bei denen der Kunde Spamerkennung aktiviert hat, werden im System mit der RemoteAdress "127.0.0.1" verarbeitet. Deswegen befindet sich sehr oft das Attribut "URIBL_BLOCKED" im Ergebnis.
Kann hier eventuell jemand von Keppler sagen, ob das ein Bug oder ein Feature ist?
Danke und schönen Abend
Alexander
Ich hatte mich verschrieben, ein umask(0022) brachte nicht den gewünschten Erfolg. Die in "media/tmp/ hochgeladenen Dateien sind weiterhin 0640.
Guten Tag,
ich habe heute festgestellt, dass egal, was ich mache, der "Sekundärer DNS #4" wird nicht angenommen. Man speichert, es heißt "DNS-Vorlage erfolgreich aktualisiert" und wenn ich wieder auf die Vorlage gehe, ist wieder kein 4. sekundärer DNS zugewiesen. Egal, wie oft ich dies durchführe und egal, ob es sich um eine neue oder bereits vorhandene Vorlage handelt.
Verwendet:
Debian 8.3 mit bind 1:9.9.5
Kann dies jemand bestätigen?
Hallo,
danke für die schnelle Antwort. Aber es geht um keine einmalige Vergabe von Berechtigungen. Die Berechtigungen für die Verzeichnisse und Dateien sind alle korrekt vergegeben. Nur Magento selbst erstellt z.B. beim Upload von Bildern noch Verzeichnisse und Dateien und für die passen die Berechtigungen nicht. Wobei das für mich auch nicht wirklich schlüssig ist, da sowohl fcgi als auch Magento selbst eine umask von 022 vorgegeben hat. Und trotzdem sind die Berechtigungen 0750.
Von welcher Korrektur im Config-File sprichst Du?
Viele Grüße
Hallo zusammen,
ich kämpfe gerade mit einem seltsamen Phänomen. Ich verwende bei einem Kunden PHP mit FastCGi und Liveconfig 2.1.0.
Der Kunde hat Magento im Einsatz und Magento auf den Server migiert. Bei FastCGI ist eine umask von 022 eingetragen, bei Magento in der index.php auch eine umask von 022. Angelegt werden jedoch alle Verzeichnisse mit 0750 und die Dateien mit 0640. Hat irgendjemand einen Tip, woher das kommen kann?
Das Verhalten ist bei einem neu installierten Magento absolut identisch.
Vielen Dank schon im Voraus.
Die Änderungen klingen sehr gut und auf diese habe ich schon sehnsüchtig gewartet. Vielen Dank schon mal im Voraus!!
Wahrscheinlich stehe ich gerade vollkommen auf dem Schlauch.
Bisher hatte ich immer auf jeden Server Mail-, Web- und Datenbankserver am Laufen. Wegen mehrerer Gründe möchte ich aber zukünftig einen Mailserver für alle verwenden und dazu jeweils einen kombinierten Web- und Datenbankserver.
Nun meine Frage:
Wie kann ich den aktuell lokal laufenden Mailserver "exportieren" Also wie sage ich beim Server a, dass zukünftig Server b für die Mails zuständig ist? Wie ich das per DNS erledige, ist mir klar, aber es muss ja auch noch irgendwie die Konfiguration der Postfächer auf Server b kommen.
Viele Dank für jeden Gedankenanstoß.
Wie siehst Du, ob der Server läuft?
Was sagt netstat?
Bekommst Du mit einem Paketsniffer auf dem Server die Verbindungsversuche Deines FTP-Clients?
Läuft eine Firewall?
Mit mir spricht Dein FTP-Server übrigens:
telnet 213.133.103.238 21
Trying 213.133.103.238...
Connected to 213.133.103.238.
Escape character is '^]'.
220 213.133.103.238 FTP server ready
Quota aus fstab rausnehmen, neu starten, quota auf allen Laufwerken stoppen, Datei auf /var/www löschen und alles nochmals durchspielen. Besteht dann der Fehler immer noch?
Nach einem quotacheck -f (ohne Fehler) und dem aktivieren mit Quotaon kommt immer noch der Fehler? Funktioniert ein "repquota -agv"?
Naja, wie gibst du -f in der fstab mit. manuell aufrufen mit -f geht, aber es muss ja auch automatisch klappen und bei Systemstart.
Ich bin fast dazu geneigt, jetzt zu schreiben ... Du musst "-f" mit einen spitzen Messer in Deinen Bildschirm einritzen, damit es funktioniert ...
quotacheck -fvgm /var/wwwIch persönlich würde quotacheck mit -f laufen lassen. Ich hatte bisher dabei noch nie ein Problem. Oder die Quota-Optionen aus der fstab entfernen und neu starten. Danach die quota beenden, die Datei löschen und das ganze nochmals von vorne aufziehen. Sollte auch keine Probleme verursachen.
- bei einem 2048-Bit-Schlüssel kann er über die gewöhnlichen Mechanismen nicht abgerufen werden (der Schlüssel ist jedoch meines Erachtens in der ".db.jnl"-Datei
- in der '*.db'-Datei ist weder der 1024- noch der 2048-Bit-Schlüssel enthalten
- das 2048-Bit-Problem wurde schon in einem anderen Thread angemerkt (ich glaube zum Release von 1.9.1)
Beispieldomains wg. OpenDKIM gibt es per DN
Insbesondere die Integration von "Let's encrypt" klingt sehr toll, auch wenn damit dem einen oder anderen Hoster wieder etwas Taschengeld genommen wird, weil weniger Zertifikate verkauft werden 
Werden mit der Version die DNS-Einträge für Autodiscover automatisch eingefügt?
Die Anleitung aus dem Handbuch schon mal durchgeführt:
http://www.liveconfig.com/de/h…server.requirements.quota
?
Ansonsten ist mir bei Deinem Eintrag ein Leerzeichen aufgefallen:
grpjquota=aquot_a.group