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

  • Zitat

    Nov 14 02:58:00 v230211191 postfix/smtpd[7817]: connect from v230211191[188.40.236.111]


    Schau doch mal deine postfix.conf durch evtl liegts ja einfach nur daran das postfix sich mit deiner ip connectet und nicht mit localhost bzw. 127.0.0.1


    Oder ist dieser Eintrag dort von einem andern Server??
    sonst ist jedenfalls für mich grad nix zu entdecken was nicht irgendwo normal wäre.



    MfG
    Andre

  • Dann schau mal da aufjedenfall nach denn seit wann verbindet sich ein client auf dem eigenen Server mit der IP ? das macht er im normalfall über localhost oder 127.0.0.1 da er die mails ja auch nur intern verteilt.


    Zitat

    /var/log/mysql/mysql-bin.000118


    was steht da schickes drin?


    MfG
    Andre

  • andre
    Die Datei ist leider kein reines Text-Format, sondern beinhaltet auch Binärdaten. Außerdem etwas zu groß, um sie hier anzuhängen.


    bebbo
    Tatsache ... localhost führt nicht zu 127.0.0.1, sondern zur "externen" IP-Adresse.


    In /etc/hosts steht:

    Code
    188.40.236.111 v230211191 v230211191.yourvserver.net localhost


    In /etc/postfix/main.cf steht folgendes:

    Code
    myhostname = v230211191.yourvserver.net
    mydomain = v230211191.yourvserver.net
    mydestination = $myhostname $mydomain localhost localhost.$mydomain
    mynetworks = 127.0.0.0/8


    In /etc/mysql/my.cnf:

    Code
    bind-address            = 127.0.0.1


    Es lief ja auch seit Monaten einwandfrei. Kann das vielleicht was mit dem Kernel-Update von letzter Woche zu tun haben?


    Gruß
    Konni

  • Zitat

    188.40.236.111 v230211191 v230211191.yourvserver.net localhost

    ändern in


    Code
    188.40.236.111 v230211191 v230211191.yourvserver.net
    127.0.0.1 localhost localhost.localdomain

    Damit sollten die Probleme eigentlich und hoffentlich behoben sein. Also weiter beobachten


    Komisch auch das es nur zu einer bestimmten Zeit ist. Läuft um die Zeit irgendnen Cron durch???


    MfG
    Andre

  • Der letzte Cron-Job, der durchgeflaufen ist, steht ja auch im letzten syslog-Ausschnitt ^^


    Code
    Nov 14 01:55:38 v230211191 -- MARK --
    Nov 14 02:09:01 v230211191 /USR/SBIN/CRON[30600]: (root) CMD (  [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
    Nov 14 02:17:02 v230211191 /USR/SBIN/CRON[32415]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
    Nov 14 02:35:38 v230211191 -- MARK --
    Nov 14 02:39:01 v230211191 /USR/SBIN/CRON[4013]: (root) CMD (  [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
    Nov 14 02:55:38 v230211191 -- MARK --

    Den syscp-Cron-Job habe ich ja schon deaktivier.


    Die Änderung der der hosts-Datei hat aber (noch) nichts bewirkt. Kann ich irgendwie den DNS-Cache löschen?
    rndc flush hat nicht funktioniert.


    Gruß
    Konni

  • Ich glaub das wird erst nachn Server neustart wirksam.
    Hast du denn im Syscp Forum mal nachgeschaut ob die crons so stimmen?
    (die hatte ich voll übersehen da oben :o )
    Evtl. lässt dir das ja die DB abschmieren weil da was Falsch läuft.


    MfG
    Andre

  • Hm ... selbst nach einem Neustart zeigt localhost immer noch auf die externe IP. Oder muss ich die Zeile mit 127.0.0.1 einfach über die andere schieben, damit diese zuerst "gewählt" wird?


    Im Syscp-Forum (du meinst doch das Unterforum hier im Forum, oder?) habe ich noch nicht nachgefragt. Nur mal kurz gestöbert, ob jemand ähnliche Probleme hat.

  • http://forum.syscp.org/
    Das Forum meinte ich ;)
    Mach mal ein Backup deiner main.cf
    und ändere dort
    [code]
    [myhostname = Eintrag/aus/etc/hosts
    mydomain = v230211191.yourvserver.net
    mydestination = eintrag_asu_hosts, localhost, localhost.localdomain, localhost
    mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
    /CODE]


    dann schau nochmal in die logs wie sich postfix mit mysql verbindet ob nun per local oder immernoch mit der IP
    Den restart von postfix nicht vergessen


    MfG
    Andre

  • Hallo Konni,


    leider ist der Thread zu lange, als dass ich den komplett durchlesen möchte.


    Aber du bist offensichtlich momentan der Meinung, dass dein Problem mit localhost zusammenhängt. Daher ein paar Anmerkungen:


    - Ein connect zu localhost (nehme an, dass =127.0.0.1 gilt) stammt aus Sicht des annehmenden Prozesses (bspw postfix oder mysql) von der externen IP. Das liegt vermutlich an der Virtualisierungslösung bzw. ist wenigstens bei meinem vServer Bronze so.


    - Mögliche Folgerung ist, dass die sonst übliche Konfiguration von postfix mynetworks = 127.0.0.1/24 und smtpd_sender_restrictions = permit_mynetworks, ... lokale E-Mails trotzdem abweist. Eine akzeptable Lösung wäre es vermutlich, die externe mit /32 bei mynetzworks mitaufzunehmen.


    - Weitere Folgerung dürfte sein, dass mysql bei einem connect per tcp einen Benutzer sucht, der als host den externen Host bzw. die externe IP eingetragen hat und eben nicht localhost.

  • Zitat

    - Ein connect zu localhost (nehme an, dass =127.0.0.1 gilt) stammt aus Sicht des annehmenden Prozesses (bspw postfix oder mysql) von der externen IP. Das liegt vermutlich an der Virtualisierungslösung bzw. ist wenigstens bei meinem vServer Bronze so.


    Dem ist nicht so. Die virtualisierungsmöglichkeit schreibt dir nicht vor wie welcher dienst connecten darf.
    Dies ist definitiv ein config Fehler sonst wärs a bei allen so ;)


    MfG
    Andre

  • Also: ich glaube nicht, dass es an (der falschen) localhost config liegt. Das sollte man zwar korrigieren

    Code
    127.0.0.1    localhost


    Was auffällt in den netstat reports sind folgende Punkte:

    Code
    unix  4      [ ]         STREAM     VERBINDUNGSAUFBAU 0        -                   private/rewrite
    unix  4      [ ]         STREAM     VERBUNDEN     144363527 8936/smtpd


    und

    Code
    unix  3      [ ]         STREAM     VERBUNDEN     142874381 7819/anvil          private/anvil
    unix  3      [ ]         STREAM     VERBUNDEN     142874380 29342/smtpd
    unix  3      [ ]         STREAM     VERBUNDEN     142874376 13922/tlsmgr        private/tlsmgr
    unix  3      [ ]         STREAM     VERBUNDEN     142874375 29342/smtpd
    unix  3      [ ]         STREAM     VERBUNDEN     142874359 7818/proxymap       private/proxymap


    Diese Zeilen gibt es nicht, wenn alles funktioniert. Um den Vermutungen eine weitere hinzuzufügen: Es könnte am tlsmgr liegen.


    Ich würde mal versuchen, den (mysql-)Server selbst tot zu kriegen, in dem man viele SMTP, IMAP, POP3 mit und ohne TLS Verbindungen öffnet.


    Wenn das (traurigerweise) erfolgreich zum Nicht-Funktionieren führt. Probiert man das mit einem Teil davon (also nur TLS, oder nur SMTP...) bis man weiß, was davon das Problem verursacht. Und dort guckt man nochmal tief in die Config... oder klemmt das erstmal ab.


    Viel Erfolg


    Bebbo

  • Hallo sugersgroer,


    du magst zwar recht haben, aber woran soll es dann liegen? Es könnte natürlich auch ein Fehler am Node sein. Für mich sah es beim kurzen Überfliegen von Konnis letzten Posts so aus, als würde sich sein vServer gleich verhalten.


    Meine Konfiguration (Debian Lenny):


    Code
    #route -n
    188.40.53.XXX    0.0.0.0         255.255.255.192 U     0      0        0 eth0
    188.40.236.XXX   0.0.0.0         255.255.255.192 U     0      0        0 eth0
    10.60.82.0       0.0.0.0         255.255.255.0   U     0      0        0 *
    0.0.0.0          188.40.53.65    0.0.0.0         UG    0      0        0 eth0
    Code
    #route add -net 127.0.0.0 netmask 255.0.0.0 dev lo
    SIOCADDRT: Operation not permitted

    Die Route braucht man natürlich normal nicht, wollte sie aber mal hinzufügen, um sicherzugehen, dass über loopback geroutet wird.


    Code
    #cat /etc/network/interfaces 
    # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
    # /usr/share/doc/ifupdown/examples for more information.
    Code
    #cat /etc/hosts
    EXTIP    EXTNAME.EXTDOMAIN    EXTNAME    
    127.0.0.1 localhost

    Auszug von ifconfig

    Code
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0

    Auszug aus /var/log/mail.log nach einem telnet 127.0.0.1 25

    Code
    Nov 14 14:35:15 EXTNAME postfix/smtpd[8574]: connect from EXTNAME.EXTDOMAIN[EXTIP]
    Nov 14 14:35:17 EXTNAME postfix/smtpd[8574]: disconnect from EXTNAME.EXTDOMAIN[EXTIP]
    Code
    #mysql -h 127.0.0.1
    ERROR 1045 (28000): Access denied for user 'root'@'EXTNAME.EXTDOMAIN' (using password: NO)
    Code
    #hostname -f
    EXTNAME.EXTDOMAIN
  • Danke, Jungs - das sieht echt genau nach meinem Fehler aus. Zumal postfix vor einigen Tagen auch tatsächlich von mir upgedatet wurde, wenn ich mich recht erinnere.


    Müsste nicht vor dem Update auch schon ein ähnlicher Code im Init-Script gewesen sein?


    Jetzt drückt mir alle die Daumen, dass es auch wirklich daran gelegen hat. ;)


    Falls dann alles gut ist, gebe ich auch virtuell ein Bier aus. :)


    Gruß
    Konni

  • Leider keine Entwarnung, Jungs ... immer noch der selbe Fehler. Ich vermute entweder ein Problem mit syscp oder mit MySQL, denn diese beiden Dienste laufen immer als letztes durch, bevor postfix nicht mehr auf MySQL zugreifen kann:


    Was macht der Cron mit dem php-Aufruf eigentlich genau? Ich kann die Syntax nicht komplett entschlüsseln. Killt der einfach alle PHP-Skripte, die länger laufen als die gültige Skriptlaufzeit?


    Was bezweckt der mysqld_safe restart um diese Uhrzeit (das macht er täglich)? Ist das ein Cron oder wird der Aufruf durch irgendeinen Fehler verursacht?
    Das sieht doch fast so aus, als wäre MySQL durch irgendwas abgewürgt worden, so dass es neugestartet werden muss. Anscheinend macht er dabei aber irgendwas beim Neustart falsch (fehlende mysqld-sock Verlinkung für postfix?).


    Gruß
    Konni