Beiträge von marinal

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?

Na ja, man kann auch varchar auf mehr als 255 Zeichen setzen, ohne gleich auf text gehen zu müssen.

Nach einem quotacheck -f (ohne Fehler) und dem aktivieren mit Quotaon kommt immer noch der Fehler? Funktioniert ein "repquota -agv"?

Zitat von informant

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/www

Ich 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.

Ja, die wird eingesetzt:
Version: 1.9.1
Platform: x86_64-unknown-linux-gnu
Revision: 3767

Und ja, sie haben mit den 255 Zeichen recht ... ich war einen Moment sprachlos ... Änderungen sind hier nicht geplant.

- 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

So, ich konnte weiter verifizieren. Es gibt Probleme, wenn der OpenDKIM-Key 2048 Bit hat. 1024-Bit-Keys werden ohne Probleme verarbeitet.

@Liveconfig-Team: Gibt es zu dem 2048-Bit-OpenDKIM-Problem schon einen Lösungsansatz?

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

Guten Abend,
leider ist das nicht von Erfolg gekrönt. Ich habe ja erst am Zone-File editiert, als ich beim Update Fehler erhalten habe und die Fehler wegen OpenDKIm waren. Ich dacbte, wenn ich die fehlerhafte Zeile entferne, ist alles wieder in Ordnung, aber damit fingen die Probleme erst an.
Wenn ich das so mache, wie oben beschrieben, wird die Zone neu erstellt, aber es gibt immer noch Probleme mit dem Update, da der Eintrag für openDKIM nicht gefunden werden kann.
Ich habe bereits OpenDKIM bei der Domain deaktiviert, danach DNS deaktiviert und dann DNS und OpenDKIM wieder aktiviert. Jedoch ist immer das Feld bei OpenDKIM gefüllt, obwohl es noch keinen Schlüssel für OpenDKIM geben darf. Wird hier ein Wert gecached, der eigentlich nicht gecached werden sollte? Ich finde leider weder den Wert in den DB-Dumps, noch unter OpenDKIM, noch unter dem Bind-Verzeichnis.
Oder ist das eventuell doch ein Bug?