Amavis Fehlermeldung in der mail.info

Diese Fehlermeldung fiel mir heute in meinen Logfiles auf:

$ /var/log/mail.info
Aug 18 17:25:49 xxxxxx amavis[12234]: (12234-11) NOTICE: reconnecting in response to: err=2006, HY000, DBD::mysql::st execute failed: MySQL server has gone away at (eval 103) line 166, line 5.

Diese Meldung erscheint immer dann im Logfile, wenn eine eMail eingeht.

Eine kleine Anpassung und der Fehler ist behoben:

$ vi /etc/amavis/conf.d/50-user
$virus_admin = undef;
$spam_admin = undef;

Ändern in:

$ vi /etc/amavis/conf.d/50-user
$virus_admin = undef;
$spam_admin = undef;
$pax = 'pax';

Nach mehreren Tests kann ich sagen, der Fehler ist behoben.

Hinweis gefunden auf:
www.howtoforge.com

ISPConfig3 – cron_daily.php

Fehlermeldung im: ISPConfig Cron – Protokoll

PHP Notice: Undefined offset: 1 in /usr/local/ispconfig/server/cron_daily.php on line 95
PHP Notice: Undefined variable: append in /usr/local/ispconfig/server/cron_daily.php on line 107

Kleine Änderung in der cron_daily.php

Zeile 95 ändern in:
@list($key, $value) = preg_split('/[t= ]+/', $line, 2);

Zeile 107 ändern in:
if(!empty($append) AND $append == 1) $out .= $varName.' '.$varValue."n";

Caching: Apache2 + eAccelerator 0.9.6.1

Ok – wo wir schon mal dabei sind am Server Dinge zu erleidigen kann ich eAccelerator mal neu kompelieren. Grund? Cron hat mir geschrieben:

[eAccelerator] This build of „eAccelerator“ was compiled for PHP version 5.3.3-7+squeeze1. Rebuild it for your PHP version (5.3.3-7+squeeze3) or download precompiled binaries.

Na dann lieber Cron, danke fürden Hinweis – erledige ich sofort.
Da es noch immer keine neue Version vom eAccelerator gibt verwende ich die alten Dateien.
Go: Caching: Apache2 + eAccelerator 0.9.6.1 weiterlesen

ejabberd unter Debian lenny und es will nicht (behoben)

Ein neuer Tag ein neues Spielzeug. Getreu diesem Motto habe ich mich für einen Jabber-Server entschieden. Meine Entscheidung viel auf den freien Instant Messaging Server ejabberd. Sein modularer Aufbau konnte weit besser überzeugen als andere Server.

Ersteinmal die gute Nachricht: Die Anleitung von asconix.com hat auf Anhieb funktioniert. In der aktuellen Version wird aus /etc/ejabberd/ejabberd.conf ein /etc/ejabberd/ejabberd.cfg und der ejabberd-Server muss vor dem Anlegen des Admin-Users noch einmal gestartet werden.
Das Webadmin findet man dann auch unter: http://jabber.xxxxxxxx-xxx.tld:5280/admin

Ok – das Verbinden uns User-Anlegen hat super funktioniert. Tja – und dann passiert etwas und ich weiß noch nicht so genau was. Ich war gerade dabei das mod_http_fileserver zu aktivieren, als meine Installation sich verabschiedete. Ich hab das Modul gestartet, nur lief es nicht wie erwartet, bzw. so gar nicht. Ich startetet den ejabberd-Server einfach neu.

/etc/init.d/ejabberd restart

Tja – und seit dem ist mein ejabberd-Server von außen nicht mehr zu erreichen.

Symtome

  • Pidgin meldet mir ein neutrales „Verbindung nicht möglich“.
  • Ein Test liefert mir ein „Klasse es läuft“:
    [root@666:~$]>

    ejabberdctl status
    Node ejabberd@h1634262 is started. Status: started
    ejabberd is running

  • tcpdump erkennt eine eingehende Verbindung:
    [root@666:~$]>

    tcpdump |grep xxxxxxxx.xxx.xxxxxx.tlt
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    19:22:30.739050 IP xxxxxxxx.xxx.xxxxxx.tlt.14098 > xxxx-xxxxxx.tld.xmpp-client: S 3950140153:3950140153(0) win 5840 <mss 1 380,sackOK,timestamp 6896354 0,nop,wscale 6>

  • Und sämtliche Logfiles schweigen sich aus.
  • Und natürlich würde von mehreren Rechnern aus getestet.
  • Und das Webadmin war auch verschwunden:

    Fehler: Netzwerk-Zeitüberschreitung
    Der Server unter jabber.xxxxxxxx-xxx.tld:5280/admin braucht zu lange, um eine Antwort
    zu senden.

    • Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
    • Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
    • Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.

Lösungsansätze:
Nach dem ein Zurückspielen der original ejabberd.cfg nichts am Zustand änderte habe ich die Installation kurzerhand vom Server geworfen:

[root@666:~$]>

aptitude purge ejabberd

Dann wurden die letzen verbliebenen Dateien und Ordner noch gelöscht:

[root@666:~$]>

find / -name ejabberd

Nun ging ich die Anleitung noch einmal durch. Diese funktionierte ja. Tja – nur die Neuinstallation verhielt sich wie das Endergebnis der ersten Installation. Server läuft – kein Zugriff drauf. Ich habe die Sache noch 2mal bereinigt und neu getestet. habe sogar die Ports 5222, 5223, 5269, 5280 in Iptables freigegeben. Was nicht nötig war, da es ja schon lief.

Meine Vermutung liegt beim mod_http_fileserver. Nachdem ich den ejabberd-Server neu gestartet habe war die Domain nicht mehr erreichbar.

Ideen???

Update

Der Vollständigkeit halber erwähne ich hier, dass der Server ohne Probleme nun funktioniert. Woran es letztendlich lag kann ich nicht so richtig sagen, da ich es nicht herausgefunden habe. Ich vermute, dass die DNS-Daten für die Subdomain noch nicht aktualisiert waren. jedenfalls funktionierte der ejabberd-Server am nächsten Tag.

MySQL Anpassungen Part 3

Heutige Änderung in der /etc/mysql/my.cnf
[root@666:~$]>
vi /etc/mysql/my.cnf

von:
max_connections = 100
query_cache_limit = 1M
query_cache_size = 1M
tmp_table_size = 64M
max_heap_table_size = 64M
table_cache = 256

auf:
max_connections = 50
query_cache_limit = 8M
query_cache_size = 64M
tmp_table_size = 128M
max_heap_table_size = 128M
table_cache = 512

Danach:
/etc/init.d/mysql stop
/etc/init.d/mysql start

Hab schon in Top gesehen, dass ich einige Werte wieder heruntersetzen muss. Aber dies hat Zeit.

MySQL Anpassung Part 2

Die WordPress basierenden Webseiten werden schon jetzt schneller ausgeliefert. Die Änderungen vom 09. September am Apache2 und MySQL haben sich also bisher gelohnt.

Heutige Änderung in der /etc/mysql/my.cnf

[root@666:~$]>
vi /etc/mysql/my.cnf
von:
query_cache_size = 512k
tmp_table_size = 32M
max_heap_table_size = 32M
table_cache = 128

auf:
query_cache_size = 1M
tmp_table_size = 64M
max_heap_table_size = 64M
table_cache = 256

Danach:
/etc/init.d/mysql stop
/etc/init.d/mysql start

Das war es mal wieder für heute.

Apache und MySQL Anpassungen Part 1

Abgeschalten:

[root@666:~$]>
a2dismod include env setenvif userdir autoindex

Installiert:

[root@666:~$]>
apt-get install php5-curl

Deinstalliert:

[root@666:~$]>
apt-get remove --purge curl

Änderung in der MySQL-Konfiguration:

[root@666:~$]>
vi /etc/mysql/my.cnf
von
#skip-innodb
auf
skip-innodb

MySQL: Tuning – packen wir es an.

Es wird Zeit meine MySQL-Datenbank zu optimieren. Dafür ist ein wenig Vorbereitung nötig.
Ich habe derzeit ein Debian Lenny. Meine Konfigurationsdatei für MySQL befindet sich unter:
/etc/mysql/my.cnf

Um mir ein wenig Hilfe beim Optimieren zu holen ziehe ich mir via wget die beiden Scripte Tuning Primer Script und MySQLTuner

Zusätzlich musste ich noch bc installieren

Beide Scripte kann man nun wie folgt aufrufen:

Persönlich finde ich MySQLTuner in seiner Ausgabe übersichtlicher. Welches sich in der Praxis bewährt bleibt abzuwarten. Da die Optimierung an sich ein längerer Verlauf ist empfiehlt es sich ausgaben in Logs zu schreiben und mit less -R sich anzeigen zu lassen. Hierbei genießt man die ANSI-Ansicht der Ausgaben.

Ich hänge der Übersicht wegen gern das Datum an die Datei dran.

So – meine erste Auswertung werde ich morgen Abend machen, da dies sich erst lohnt, wenn der MySQL-Server mindestens 48 Stunden gelaufen ist.

Links: