Posts by OliverN

    Wenn deine Emails abgewiesen werden, dann hast du Glück. Normalerweise verschwinden diese. Was steht im Log-File als Ablehnungsgrund?

    Hier kommen wir genau in das Schwere. Ein Grossteil der Nachrichten erhalte ich gar nie zurück und erhalte keine Bounce Meldung. Bei MS ist es das übliche "Please contact your Internet service provicer since part of their network is on our Block list (S3150). Bei den Firmen erhalte ich teils gar keine Rückmeldung oder Meldungen wie "refused to talk to me: 554) oder "Your access to submit messages to this e-mail system has been rejected (in reply to RCPT TO command)


    Den RBL-Status deiner IP kannst du mithilfe von z.B. http://multirbl.valli.org/ überprüfen.

    Danke den kenne ich. Dort werden mir auch sieben Einträge angezeigt, jedoch habe ich diese noch nicht hinbekommen auszutragen. Habe auch schon Beiträge gefunden bei denen diese Einträge als irrelevant angezeigt wurden.

    srn.surgate.net

    abuse.ch ZeuS Tracker Domain

    abuse.ch ZeuS Tracker IP

    AntiCaptcha.NET IPv4

    dnsbl.isx.fr

    dnsrbl.org

    openresolvers.org

    SurGATE Reputation Network (SRN)


    Dies liegt aber unter Umständen auch daran das diese Seiten teils gar nicht erreichbar sind und daher Fehler ausgeben.

    die IP(v6) bei smtp_bind_address(6) ist auch diejenige, welche Postfix verwendet ...,

    und diese sollte tunlichst im SPF stehen ...

    Sorry das habe ich nicht erwähnt. Natürlich ist auch die IPv6 Failover eingetragen und auch per SPF Freigegeben.


    Da ich noch am schauen bin die IPv6 Adresse als Standard zu setzen, habe ich die IPv6 Adresse des Servers genommen und die IPv4 der Failover. Dies auch in Postfix konfiguriert. Die Mails werden von MS und einigen Firmen abgewiesen. Sobald die IPv4 die des Servers ist klappt es. Ich muss doch dann fast davon ausgehen das ich einfach ne "faule" Failover habe?

    Bsp. in den Mail-Headern

    Im Mailheader wird keine IP angezeigt


    Ggf habe ich gestern auch geschlafen was du mit src meinst. Mein Server hat als Ausgehende IP die Original Server IP und nicht die Failover IP.

    Ich habe jedoch auch die Failover IP mal als Ausgehende verwendet (auch getestet)

    Code
    1. ip -4 route change default via <GATEWAY> src <FAILOVER>

    So wird mir die Failover als Ausgehende verwendet, die Mails bleiben trotzdem überall stecken und kommen nicht durch.

    Wäre dies überhaupt Relevant, da Postfix ja mittels smtp_bind_address an die IP gebunden wird?

    Sendet dein Postfix denn auch von der Failover IP? Oder sendet er von der normalen IP?

    Er sendet von der FailOver IP


    Änderst du die Default Route entsprechend mit einer src Kennzeichnung?

    hier muss ich gestehen bin ich überfragt. kann ich das testen?



    Sind beide Adressen auch als Sendeberechtigt im SPF Record markiert?

    Normalerweise nur die Failover, aber für die tests war natürlich die serverIP drin

    kannst du die dazugehörenden Einträge der mail.log, welche mit diesem einem der mail.warn korrelieren posten?

    Gerne


    Code
    1. May 18 05:04:42 sven postfix/postscreen[4962]: CONNECT from [77.83.201.70]:36754 to [91.204.44.26]:25
    2. May 18 05:04:48 sven postfix/postscreen[4962]: PASS NEW [77.83.201.70]:36754
    3. May 18 05:04:48 sven postfix/smtpd[4965]: warning: hostname hostmaster.meric.net.tr does not resolve to address 77.83.201.70
    4. May 18 05:04:48 sven postfix/smtpd[4965]: connect from unknown[77.83.201.70]
    5. May 18 05:04:49 sven postfix/smtpd[4965]: NOQUEUE: reject: RCPT from unknown[77.83.201.70]: 450 4.7.25 Client host rejected: cannot find your hostname, [77.83.201.70]; from=<info@simpcinema.pw> to=<hostmaster@xxxxx.ch> proto=ESMTP helo=<simpcinema.pw>
    6. May 18 05:04:49 sven postfix/smtpd[4965]: disconnect from unknown[77.83.201.70] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=4/6

    Ich kenne den Absender auch nicht. Finde es einfach speziell das dieser Eintrag regelmässig erscheint. Denke aber auch nicht das der ein Problem ist

    Guten Morgen


    Ich habe vor einer Weile einen E-Mailserver gem. der Anleitung Thomas Leister neu aufgesetzt. Seit ich damit auf dem neuen RS1000 bin, habe ich jedoch das ein oder andere Problem und wollte mich mal erkunden ob die Reaktionszeit Problematisch sein könnte.


    Das eine Problem ist das ich bei diversen Firmen blockiert werde, und bei Microsoft keine einzige E-Mail durchbekomme. Gem. Microsoft gibt es mit der IP jedoch kein Problem. Da jedoch alle E-Mails überal reinkommen sobald ich die Server IP anstelle der Failover IP eintrage (DNS Einträge werden natürlich jeweils frühzeitig angepasst) kommen die E-Mails rein. Wie es scheint habe ich eine "Faule" Failover IP erhalten. Ich habe das mal dem NetCup support gemeldet. Ein Wechsel ist ausgeschlossen aber sie wollen mal bei MS schauen ob sie was erreichen. Naja.


    Ein spezielleres Problem ist der Text von MXToolbox. Hier erhalte ich immer mal wieder folgende Meldung:

    pasted-from-clipboard.png


    Manchmal muss ich 5 - 10 Versuche starten damit der Fehler weg ist, manchmal ist er beim zweiten mal weg.


    In der mail.log sehe ich nichts spezielles während der Abfrage von MXToolbox

    Code
    1. May 19 08:19:24 sven postfix/postscreen[15163]: CONNECT from [18.205.72.90]:50462 to [91.204.44.26]:25
    2. May 19 08:19:25 sven postfix/postscreen[15163]: PASS OLD [18.205.72.90]:50462
    3. May 19 08:19:25 sven postfix/smtpd[15166]: connect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90]
    4. May 19 08:19:27 sven postfix/smtpd[15166]: NOQUEUE: reject: RCPT from keeper-us-east-1c.mxtoolbox.com[18.205.72.90]: 554 5.7.1 <test@mxtoolboxsmtpdiag.com>: Relay access denied; from=<supertool@mxtoolbox.com> to=<test@mxtoolboxsmtpdiag.com> proto=ESMTP helo=<keeper-us-east-1c.mxtoolbox.com>
    5. May 19 08:19:28 sven postfix/smtpd[15166]: disconnect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

    DIe mail.err ist leer und die mail.warn hat nur ab und an diesen Eintrag:

    Code
    1. May 19 08:00:06 sven postfix/smtpd[15044]: warning: hostname hostmaster.meric.net.tr does not resolve to address 77.83.201.70

    Was es damit aufsich hat weiss ich aber grad auch nicht :)


    Ist der Timeout problematisch, und kann ich diesen irgendwie verhindern?


    Ich bedanke mich schon jetzt für jeden Hinweis.


    Gruss


    Oliver

    Ich habe mir überlegt es wäre ggf schlau die Datenbank gar nicht ins Galera Cluster zu legen, da ich ja sonst nicht mehr gut an den Backup Server komme sollte es den Galera Cluster mal zerlegen :D und das ist in meiner Testumgebung sehr gut möglich :D:D:D

    ich kenne das System ebenfalls nicht, aber als ersten Ansatz fürs Troubleshooting würde ich hier einen rekursiven Grep auf das passende /etc/ bzw. wo die Software liegt, loslassen

    Danke. Auch da habe ich wohl alles erwischt.


    Was verwendet denn ihr so für Backups von mehreren Servern? Bisher hatte ich borg, aber die Art und die Webui von bareos sind halt schon sehr verlockend :D

    Ich kenne dieses System nicht, aber versuch einmal die Tabellen selbst anzulegen. Die dafür notwendigen SQL-Befehle müssten hier stehen:

    Danke für deinen Vorschlag. Hier bleibt der selbe Fehler.


    Ich habe das Gefühl, dass ich noch an weiteren stellen die Zugangsdaten, rsp. den Host ersetzen muss. Finde aber bisher noch nichts. Ich suche mal weiter. Wenn noch Vorschläge da sind nehm ich die natürlich gerne :)

    Guten Abend


    Im moment habe ich wieder etwas Zeit und versuche mich am Bareos Server. Dazu gibt es ja sehr viele Anleitungen. Eine die ich gefunden habe ist die folgende: https://www.taste-of-it.de/bar…ion-unter-debian-stretch/


    Was ich bisher jedoch nicht herausgefunden habe, ist wie ich das ganze Installieren kann ohne den MariaDB Server auf dem Server zu haben. Ich habe einen Galera Cluster und würde natürlich gerne die Bareos Datenbank auf diesem Betreiben.


    Bei bareos-database-common müsste ich ja dann nein wählen. Aber ich habe bisher nicht herausgefunden wie ich das ganze dann Manuell hinbekomme.

    Gem. der Dokumentation von Bareos muss ich die Datei /etc/bareos/bareos-dir.d/catalog/MyCatalog.conf eintragen. Aber wie es weiter geht weiss ich da einfach nicht so recht. Nach dem ich die MyCatalog.conf erstellt habe, erscheint immerhin beim Test /usr/sbin/bareos-dir -t -f -d 500 das eine Verbindung aufgebaut werden kann aber danach fehler kommen.

    Erst dachte ich, ich muss ggf mit den Scripten erst die DB vorbereiten. Aber auch da gibt es sofort einen Fehler.

    Code
    1. /usr/lib/bareos/scripts/create_bareos_database
    2. Creating mysql database
    3. ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
    4. Creating of bareos database failed.

    Bitte entschuldigt die eventeull blöde Frage. Aber ich sehe da im moment wirklich nicht weiter.

    Wenn ich die Rechte auf www-data ändere geht es. Ich habe das nun mal so gemacht und werde ein paar Tage beobachten ob es läuft. Nochmals danke.

    Ich denke aber ich war da im Kopf auf dem Holzweg bitte entschuldige.

    Ok. Ich dachte es reicht wenn die gruppe passt. Bitte entschuldige.

    Da es auf dem NFS Share mehrere Domains gibt mit anderen Benutzern, kann ich nicht einfach ein chown testen da ich dann auch die Übergeordneten Ordner auch alle anpassen muss. Gibt es eine Möglichkeit dies anders zu lösen/testen?


    Edit: Ich habe nun kurz auf dem Storageserver von einer Datei die rechte auf www-data geändert. Dies würde gehen. Die Frage ist ob ich die Rotierung irgendwie hinbekomme. Ggf das ich für jeden Benutzer eine Rotierung separat mache. Aber die Anpassung in der /etc/logrotate.d/nginxwar ja nicht die Lösung

    Was passiert denn, wenn du dies manuell aufrufst?

    Code
    1. invoke-rc.d nginx rotate
    2. [ ok ] Re-opening nginx log files: nginx.

    Aber dort erscheint dann entsprechend der Fehler in der /var/log/nginx/error.log. Also scheint dort wirklich das Problem zu liegen. Die Frage ist nun nur noch wo

    Paul hat ja bereits erwähnt, dass die Gruppe Schreibrechte braucht oder die Datei www-data gehören muss.

    www-data hat ja schreibrechte ansonsten würde ja die access.log und error.log keine Einträge im NFS Share

    Der nginx läuft als Benutzer www-data

    /etc/nginx/nginx.conf

    Code
    1. user www-data;
    2. worker_processes auto;
    3. error_log /var/log/nginx/error.log warn;
    4. pid /var/run/nginx.pid;
    5. .....

    Der Fehler tritt jeden Tag um 06.25 Uhr auf, und jedesmal natürlich nach dem ich /usr/sbin/logrotate -dfv /etc/logrotate.d/nginx ausführe. Der Fehler erscheint in /var/log/nginx/error.log. Die /var/log/nginx/error.log wird nach dem Befehl auch jedesmal sauber rotiert, und in der neuen error.log ist dann der Fehler auf dem NFS Share zu finden.


    Symlinks existieren keine.

    In der Webkonfigurationsdatei habe ich natürlich die beiden Zeilen

    Code
    1. access_log /mnt/wwwData/logs/domain/access.log;
    2. error_log /mnt/wwwData/logs/domain/error.log;

    drin stehen.

    Hallo Paul


    Auch dir danke für deine Antwort.


    Installiert ist es per apt-get.


    Die logrotate.d/nginx

    diese habe ich nicht geändert. Also versuchsweise natürlich, aber es ist alles wieder beim alten.


    Achtung: Nicht nginx rotiert seine Logs, sondern logrotate, ein Systemdienst. Was steht denn in der /etc/logrotate.d/nginx drin? Hast du das System denn selbst aufgesetzt?


    Dieser Fehler im nginx kommt nicht durch das logrotate, sondern dass nginx nicht ins log schreiben kann, was auch klar ist, wenn die Datei "oliver" gehört, die Gruppe zwar www-data ist, aber nur Leserechte hat.

    nginx scheint jedoch in die Datei schreiben zu können. Die Datei /mnt/wwwData/logs/domain/access.log hat ja alle Einträge welche auch aktualisiert werden. Das heisst doch das nginx die Schreibrechte hat?

    Es ist mir klar, dass Du den Mount selbst gemacht hast, aber da Lower Camel Case für Linux-Dateinamen (wwwData) eher ungewöhnlich ist, wollte ich da mal kurz darauf hinweisen - vielleicht ist es ja nur ein Schreibfehler.

    Ok Danke. Ich war mir das in der Entwicklung teils gewöhnt und hab mir da gar keinen Kopf gemacht. Ich werde dies daher bei gelegenheit anpassen.

    Was ich noch herausgefunden habe: für die Logrotation existiert ja die Konfiguration /etc/logrotate.d/nginx

    Ein /usr/sbin/logrotate -dfv /etc/logrotate.d/nginx zeigt mir nun jedoch an, dass er nur die Logs in /var/log/nginx rotiert. In der selben Zeit werden jedoch auch die auf dem NFS Mount rotiert. Ist dies irgend ein Prozess von nginx der dies auslöst? Ansonsten müsste ich diesen ja beim Parameter -d sehen.

    Guten Abend


    Heute habe ich mal wieder ein Problem gefunden, finde aber das Problem gerade nicht.

    Ich habe von nginx die Logfiles auf einem mounted share. Dies klappt auch gut. z.B. access.log hat immer sauber alle Einträge.


    Einmal am Tag führt er die Logrotate aus. Als user ist dort "www-data adm" drin wie es auch Standardmässig vergeben ist. Jedoch erscheint im nginx log trotzdem folgender Fehler das er es nicht rotieren kann

    Code
    1. 2019/04/05 19:49:51 [emerg] 1574#1574: open() "/mnt/wwwData/logs/domain/access.log" failed (13: Permission denied)

    Hat jemand eine Idee wie ich das beheben könnte? Der Besitzer der Datei:

    Code
    1. -rw-r--r-- 1 oliver www-data

    und nginx scheint ja auch schreiben zu können.