Beiträge von Konni

  • Nach Neuinstallation weigert postfix sich bei ausgehenden Mails (SMTP)

    Achja - hier noch meine main.cf

    Gruß
    Konni

  • Nach Neuinstallation weigert postfix sich bei ausgehenden Mails (SMTP)

    Hallo Leute,

    ich hatte vor kurzem schon mit heftigen postfix-Problemen zu kämpfen gehabt (ich hatte hier davon berichtet). Nun habe ich endlich mal etwas Zeit gehabt und eine Neuinstallation durchgeführt. Gestern Mittag hatte ich also begonnen das neue System einzurichten (Lenny + Syscp).

    Angefangen hatte ich wie immer mit lighttpd und denyhosts. Danach habe ich dann mit dem Mail-Server angefangen (dovecot + postfix).

    Dovecot hatte ich auch schnell am laufen. Mit postfix hatte ich aber gleich wieder Probleme. Eingehende eMails werden problemlos verwaltet und an Dovecot verteilt. Ich kann allerdings keine eMails versenden. Thunderbird3 meldet immer einen fehlerhaften Login. Die Daten sind aber auf jeden Fall korrekt und die MySQL-Anbindung von postfix sollte auch stimmen. Immerhin werden ja auch die eingehenden Mails korrekt verteilt.
    Ich tippe also auf irgendein Problem mit der SMTP-Authentifizierung.

    Da ich mit postfix auf keinen grünen Zweig kam, habe ich zwischendurch auch mal exim4 ausprobiert. Aber auch hier hatte ich fast das selbe Problem. Eingehende Mails kein Problem, ausgehende wurden zurückgeschickt mit der Meldung "unroutable address". Im Debug-Modus war das Problem aber wohl auch irgendwas mit einer fehlerhaften Authentifizierung.

    Also: Was habe ich falsch gemacht? Hat jemand einen Tipp für mich?

    Einrichtung war streng nach Syscp-Angaben, natürlich angepasst auf die eigenen Daten.

    Im mail.log habe ich dann immer solche Einträge:

    Code
    Jan  2 23:12:06 v230211191 postfix/smtpd[7215]: connect from p54xxxxx3.dip.t-dialin.net[84.xxx.xxx.83]
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: warning: SASL authentication failure: Password verification failed

    Im auth.log dieses:

    Code
    Jan  2 23:12:06 v230211191 postfix/smtpd[7215]: sql auxprop plugin using mysql engine
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: sql plugin Parse the username mxxxxxxx@kxxxxxx.biz
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: sql plugin try and connect to a host
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: sql plugin trying to open db 'syscp' on host 'localhost'
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: sql plugin could not connect to host localhost
Jan  2 23:12:07 v230211191 postfix/smtpd[7215]: sql plugin couldn't connect to any host

    Wenn ich in der /etc/postfix/sasl/smtpd.conf localhost durch 127.0.0.1 ersetze, gibt es allerdings den selben Fehler.

    Hat wer einen Tipp oder kann sich das vielleicht mal selbst ansehen? Ich habe gestern locker 10 Stunden damit verbracht und bis es langsam leid. ;)

    Edit: Ich habe auch schon die "alte" main.cf von postfix ausprobiert, die vorher auf meinem System einwandfrei funktioniert hat. Die bringt hier den selben Fehler.

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von bebbo;11049

    Und der Neustart kommt von ganz alleine? Kein CRON, kein anderes Programm, was diesen verursacht?

    EDIT:
    Wie sieht es mit einem Full Query Log aus?
    Ist vielleicht die Platte voll?
    ...


    Also bei mir sind 14 bon 15 GB frei. Nach Weihnachten mache ich eine Neuinstallation (Lenny+SysCP sind ja jetzt verfügbar) und dann konfiguriere ich mal von vorne ...

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von ramstein;10189

    schreibst ein kleines "howto" für blöde ?

    oder sind die vorhandenen daten dann eh wech .... ?


    Ich habe die Tabellen einfach in phpmyadmin exportiert und dann das SQL-Script entsprechend angepasst (InnoDB durch MyISAM ersetzt). Dann die Tabellen gedropt und dann die SQL-Datei wieder eingespielt.

    Et voilà - funktioniert.

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Hm ...

    Ich habe glaube ich einzig in der main.cf die Einstellungen zu TLS geändert - das müsste dieser Teil sein:

    Code
    # tls config
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/ssl/private/***.key
smtpd_tls_cert_file = /etc/ssl/certs/***.crt
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
tls_random_prng_update_period = 3600s

    Das lief ja aber auch über Monate hinweg einwandfrei. Die master.cd habe ich - soweit ich mich erinnere - nicht angefasst.

    tlsmgr lässt laut master.cf nur einen Prozess zu. Kann es sein, dass dann ein Prozess blockiert und somit die darauffolgenden Mails nicht mehr ausgeliefert werden?

    Denn in meiner ersten netstat.txt sieht man, dass python zu diesem Zeitpunkt aktuell mit postfix verbunden ist (wird wohl eine Report-Mail von denyhosts sein).

    Auf TLS würde ich aber ungern verzichten. Das ist auch immerhin einer der Gründe, warum ich einen eigenen vServer als Mail-Server einsetze.

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Das hatte ich ja schon gemacht ... da passiert aber so gut wie nichts.

    Freitag:

    Wie man sieht, war nicht viel los vor dem Crash ...

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Erste gute Nachricht:
    Der Server lief heute Nacht mit der abgeschalteten InnoDB-Engine einwandfrei durch und funktioniert immer noch bestens. ;)

    bebbo
    Auch das Neustarten von postfix korrigierte ebenso wie das Neustarten von MySQL den Fehler. Ich weiß aber nicht, ob das nur an der postfix-jail Verlinkung gelegen hat. Wird diese beim postfix-Neustart auch neu angelegt?

    Welcher Wert gilt denn in der my.cnf bei max connections, wenn diese Zeile auskommentiert ist?

    Bleibt die Frage: Was ist jetzt ohne die InnoDB-Engine anders, dass heute Nacht zum ersten Mal Ruhe ist? Vor allem: Warum sollte postfix mitten in der Nacht so viele Verbindungen zu MySQL aufbauen? Ich bekomme nachts so gut wie keine Mails (außer die DenyHosts-Reports).

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von killerbees19;9839

    Dieser Fehler wird meistens durch überschriebene (oder nicht angepasste) Startscripte in /etc/mysql verursacht, oder die debian-start.inc.sh selbst ist veraltet/falsch. Am besten alle gesetzten Variablen kontrollieren und vergleichen ;)


    Hallo Christian,

    die Variable $MYSQL ist nicht gesetzt. Ich hätte das ja noch händisch erledigt, weiß aber gar nicht, auf welchen Wert die gesetzt werden soll. Dem Shell-Skript nach vermute ich, dass dort der Pfad zur mysql-binary gesetzt werden soll.

    Kann das jemand bestätigen / widerlegen?

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Tja, wenn ich das wüsste, hätte ich das Problem bestimmt schon beheben können. Selbst mit aktivierten MySQL-Log steht nichts drin, außer, dass MySQL neu gestartet wurde.

    Seit dem Update auf Lenny ist das ganze eher schlimmer geworden. Der MySQL-Server stürzt jetzt nachts komplett ab, während ja unter Etch nur postfix nicht mehr auf die Datenbank zugreifen konnte.

    MySQL hat jetzt auch irgendwas beim Start zu meckern:

    Code
    # /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Linking mysqld.sock to the postfix-jail.
Checking for corrupt, not cleanly closed and upgrade needing tables..
v230211191:/etc/mysql# /usr/share/mysql/debian-start.inc.sh: line 21: MYSQL: unbound variable
/usr/share/mysql/debian-start.inc.sh: line 25: MYSQL: unbound variable

    Gerade eben habe ich noch die einzige InnoDB-Datenbank zu MyISAM konvertiert und InnoDB abgeschaltet. Mal schauen, was heute Nacht passiert.

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von killerbees19;9720


    Habt ihr/du eigentlich bei Netcup schon einmal nachgefragt wegen diesem Problem? Ich habe den Thread jetzt nicht immer verfolgt, aber ich könnte mir vorstellen, dass irgendetwas am Node den Fehler produziert und/oder vllt. der Raid-Controller/HDD des Nodes dafür verantwortlich ist. Ist natürlich nur eine Vermutung, aber fragen kostet ja nichts :o


    Ich hatte schonmal nachgefragt, ob ein Festplatten- oder Speicherproblem vorliegt.

    Die kurze Antwort:

    Zitat

    laut Monitoring sind keine Festplattenfehler oder Memory-Fehler auf dem von Ihnen genutzten Node bekannt. Eventuelle Fehlermeldungen werden alle 10 Minuten ausgewertet.

    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Welche Kernel habt ihr denn momentan am Start? Bei mir ist es dieser:

    # uname -a
    Linux v230211191.yourvserver.net 2.6.29.6-vs2.3.0.36.14-beng #1 SMP Tue Aug 18 08:43:50 BST 2009 x86_64 GNU/Linux

    Heute Nacht war es mal wieder so weit. Dieses Mal schon um 01:45 Uhr.

    Ich benutze zurzeit nur eine einzige InnoDB-Datenbank (roundcube). Diese werde ich heute mal auf MyISAM umstellen und dann InnoDB abschalten.

    Das Update auf Lenny habe ich noch nicht gemacht, weil ich heute Morgen früh aufstehen musste und dann die Nacht nicht so lange aufbleiben konnte.

    Gruß
    Konni