Posts by OliverN

    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.

    wieviel waren denn bei Dir "einige Stunden"?

    Der Eintrag bestand eigentlich bereits seit 2 Wochen


    Falls Du hier aus Versehen vergessen hast, Deine Domain zu maskieren, dann ist das gut. Denn ich konnte damit andere Tests fahren.

    War ein versehen, aber ist ja kein Problem. Ich muss mich eh daran gewöhnen dies nicht zu Maskieren.


    Wenn alles ok ist bin ich ja beruhigt. Vielen Dank.

    Guten Morgen


    Ich habe folgenden DMARC DNS Eintrag

    Code
    1. "v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=0;ri=86400;rf=afrf;rua=mailto:postmaster@myOwnMailAddr.com;"

    Wenn ich nun einen Test über mail-tester.com mache, erhalte ich folgendes Resultat:

    Wenn ich einen Test über dmarcanalyzer.com mache, erhalte ich dieses Problem:

    Code
    1. Probleme
    2. Wir haben die folgenden Probleme mit Ihren DMARC-Aufzeichnungen bemerkt.
    3. Info : Wir haben eine eigene Adresse in Ihrem DMARC-Datensatz gefunden. Bitte stellen Sie sicher, dass Sie die eingehenden Berichte an Ihre eigene - Adresse weiterleiten, um die Statistiken im Tool zu sehen.

    Beim zweiten Test habe ich mal outlook.com verwendet. Dort kommt das selbe ergebnis. Ich weiss nicht, ob dort nun wirklich ein Problem vorliegt, oder ob dies ignoriert werden kann.


    PS. Sagt jemandem der Fehler

    Code
    1. dovecot: auth-worker: Fatal: master: service(auth-worker): child 4169 killed with signal 11

    etwas? Ich hatte den schon mal in einem Testserver, dieser erscheint mir aber immer wenn ich die Anleitung zu einem E-Mailserver nach Thomas Leister gehe.


    Gruss


    Oliver

    Zur Info: Ich habe ein 5 Sekunden Timer getestet aber ohne erfolg.


    Ich denke das hat mit meiner Sturheit zu tun das ich wollte das Postfix nur auf die Failover IPs hört :)

    Zumal die FailoverIPs einen anderen RDNS haben als die beiden normalen ServerIPs


    Installiert ist Debian 9.8.0

    Was ich nun noch gemerkt habe:


    Wenn ich den Server aufstarte, lauscht der Server nicht auf Port 25


    Wenn ich nun jedoch den Service postfix neustarte, lauscht Postfix wieder auf den Port 25, aber nur bis zu einem reboot.

    Nach einem Neustart die Ausgabe:

    Nach dem Neustart vom Service

    Wie ihr seht ist der Status der selbe.


    In der mail.err/info:

    Code
    1. postmulti[1176]: fatal: parameter inet_interfaces: no local interface found for 2a03:XXXX:XX:XXX::5
    2. postmulti[1176]: fatal: parameter inet_interfaces: no local interface found for 2a03:XXXX:XX:XXX::5

    Ich denke dies ist der Fehler das mein IPv6 Interface nicht oben ist. Dachte so müsste aber wenigstens die IPv4 Adresse auf Port 25 hören.


    Meine Interface

    Code
    1. up ip -6 addr add 2a03:XXXX:XX:XXX::5/64 scope global dev ens3 preferred_lft 0

    Muss ich einfach ein Timer setzen damit Postfix erst nach 4 Sekunden order so hochfährt, oder ist der Eintrag in der interface falsch?