Martin Zambo writes:

Hallo Sandy, Hallo Liste,

Am Freitag, 3. Juni 2005 17:23 schrieb Sandy Drobic:

...

Martin Zambo wrote:

...

Hallo Liste,

mein Server lief unter suse9.0 ca 2 Jahre problemlos. Jetzt musste ich auf 9.2 umsteigen. Nach der Umstellung klappt die Mailzustellung mit den alten Konfigurationsdateien nicht mehr.

Auf dem Sytem läuft Suse 9.2 aktualisiert, Cyrus-IMAP der zur Clientseite auch funktioniert.Nur kommen da keine Mails an, fetchmail holt ab und weiter kommen die mails dann nicht.

In messages kommt dann diese Meldung:

Jun 4 07:47:01 sky /usr/sbin/cron[23773]: (root) CMD (fetchmail) Jun 4 07:47:33 sky lmtpunix[23690]: accepted connection Jun 4 07:47:33 sky lmtpunix[23690]: lmtp connection preauth'd as postman Jun 4 07:47:33 sky master[23779]: about to exec /usr/lib/cyrus/bin/lmtpd Jun 4 07:47:33 sky lmtpunix[23779]: executed Jun 4 07:47:33 sky lmtpunix[23779]: DBERROR db4: 217 lockers

Ist das ein Hinweis auf mein Problem?

Die von cyrus-imapd benutzte BerkleyDB ist vermutlich defekt. Lass einmal db_recover über die Datenbank laufen. Ich weiss nicht, wo SuSE die versteckt, irgendwo in /var/imapd/db vermute ich mal. Aber Achtung, nicht als root, da sonst die Rechte umgeschrieben werden. Die Parameter zeigt dir db_recover --help an, db_recover -h /pfad/auf/db/ sollte reichen. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53

Martin Zambo wrote:

...

...

Auf dem Sytem läuft Suse 9.2 aktualisiert, Cyrus-IMAP der zur Clientseite auch funktioniert.Nur kommen da keine Mails an, fetchmail holt ab und weiter kommen die mails dann nicht.

Das heisst, die Anwender können sich anmelden, sehen ihre alten Mails, es kommen aber keine neuen herein?

Nach dem Start von fetchmail: sky:/home/martin # fetchmail 61 Nachrichten für xxxx-52-1 bei pop.1und1.com (678336 Oktetts). Nachricht xxxx-52-1@pop.1und1.com:1 von 61 wird gelesen (2752 Oktetts) ..

bleibt es so stehen es geht nicht weiter.

Werden die restlichen Mails abgeholt und erscheinen sie in der Ausgabe von mailq?

In messages kommt dann diese Meldung:

Jun 4 07:47:01 sky /usr/sbin/cron[23773]: (root) CMD (fetchmail) Jun 4 07:47:33 sky lmtpunix[23690]: accepted connection Jun 4 07:47:33 sky lmtpunix[23690]: lmtp connection preauth'd as postman Jun 4 07:47:33 sky master[23779]: about to exec /usr/lib/cyrus/bin/lmtpd Jun 4 07:47:33 sky lmtpunix[23779]: executed Jun 4 07:47:33 sky lmtpunix[23779]: DBERROR db4: 217 lockers

Ist das ein Hinweis auf mein Problem?

Das könnte schon ein Hinweis auf einen Datenbank-Fehler sein. Beim Update auf 9.3 haben auch viele über Probleme berichtet und deshalb sollte man VOR dem Update immer seine Mailbox.db als Klartext exportieren, falls nach dem Update eine inkompatible Berkeley-Version auf dem System installiert ist. Ich habe gerade gesehen, dass Suse anscheinend täglich mit /etc/cron.daily/cyrus eine Textkopie von mailbox.db erstellt. Sie liegt im Verzeichnis /var/lib/imap/Backup. Das ist mal eine sehr angenehme Entdeckung. Ansonsten eben manuell mit: su - cyrus -c "ctl_mboxlist -d" > /var/lib/imap/mailboxes.txt Schaue dir mal die Doku zum Backup von Cyrus Imap im Wiki an: http://asg.web.cmu.edu/twiki/bin/view/Cyrus/Backup

...

Zeit das Kommando "mailq" noch Mails an, die nicht ausgeliefert wurden? Wenn nicht, dann würde ich mal in /var/spool/imap nachsehen, wo die Mails abgelegt wurden.

EA50761C6F 492 Sat Jun 4 01:39:01 root@sky.pmz (temporary failure. Command output: couldn't connect to lmtpd: Bad file descriptor_ 421 4.3.0 deliver: couldn't connect to lmtpd_) root@sky.pmz

Postfix versucht, die Mails lokal per lmtpd weiterzuleiten und scheitert dabei. Es gibt mehrere Möglichkeiten, wie das scheitern kann. Könntest du die Ausgabe von "postconf -n", /etc/postfix/master.cf (ohne Kommentare) zeigen? Normalerweise ist mailbox_transport in /etc/postfix/main.cf auf cyrus gesetzt, wenn man einen Cyrus Imap Server verwendet. mailbox_transport = cyrus Wenn dort lmtp verwendet wird, sollte er natürlich genau übereinstimmen mit der Datei, die Cyrus dafür verwendet und Postfix sollte nicht chroot laufen. Bei mir wäre die richtige Datei /var/lib/imap/socket/lmtp. Nach eine Änderung an main.cf natürlich immer ein "postfix reload", damit die Änderungen übernommen werden.

-- 636 Kbytes in 813 Requests, da ist also einiges drin, mit welchem Eintrag kann ich das veränder?

Nur mit einer korrekten Konfiguration. Die Mails hängen in der Queue, können aber nicht an Cyrus weitergeleitet werden. Sobald die Konfiguration stimmt und Postfix neu gestartet wird, werden auch die Mails wieder zugestellt.

...

alte Installation mitsamt allen Einstellungen upgedatet?

Ja genau, war mal ein Versuch, bis auf das Problem war es durch das reaktiviren der alten Konfigurationsdateien kein Problem.

Beschreibe bitte mal präzise, WIE du upgedatet hast. Ich habe das Gefühl, dass es hier ein Problem gibt.

...

Was steht in den Logdateien, wenn Cyrus startet und wenn Postfix startet?

rcpostfix restart, Ausgabe var/log/mail:

Jun 4 08:45:11 sky postfix/qmgr[24349]: C108761DF2: from=, size=492, nrcpt=1 (queue active) Jun 4 08:45:11 sky postfix/qmgr[24349]: C8B9861E07: from=, size=492, nrcpt=1 (queue active)

Sieht sehr seltsam aus für ein "rcpostfix restart". Hier mal zum Vergleich meine Logausgabe: Jun 4 12:53:11 katgar postfix/master[3553]: terminating on signal 15 Jun 4 12:53:12 katgar postfix/postfix-script: starting the Postfix mail system Jun 4 12:53:12 katgar postfix/master[2951]: daemon started -- version 2.1.5

rccyrus restart, Ausgabe von messages:

Jun 4 08:56:10 sky ctl_cyrusdb[25734]: done recovering cyrus databases Jun 4 08:56:10 sky master[25735]: about to exec /usr/lib/cyrus/bin/idled Jun 4 08:56:10 sky master[25733]: ready for work Jun 4 08:56:10 sky master[25737]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Jun 4 08:56:10 sky master[25738]: about to exec /usr/lib/cyrus/bin/timsieved Jun 4 08:56:10 sky master[25739]: about to exec /usr/lib/cyrus/bin/lmtpd Jun 4 08:56:10 sky master[25740]: about to exec /usr/lib/cyrus/bin/timsieved Jun 4 08:56:10 sky lmtpunix[25739]: executed Jun 4 08:56:10 sky sieve[25740]: executed Jun 4 08:56:10 sky ctl_cyrusdb[25737]: checkpointing cyrus databases Jun 4 08:56:10 sky ctl_cyrusdb[25737]: archiving database file: /var/lib/imap/annotations.db Jun 4 08:56:10 sky sieve[25738]: executed Jun 4 08:56:10 sky ctl_cyrusdb[25737]: archiving log file: /var/lib/imap/db/log.0000000024 Jun 4 08:56:10 sky ctl_cyrusdb[25737]: archiving database file: /var/lib/imap/mailboxes.db Jun 4 08:56:10 sky ctl_cyrusdb[25737]: archiving log file: /var/lib/imap/db/log.0000000024 Jun 4 08:56:10 sky ctl_cyrusdb[25737]: done checkpointing cyrus databases Jun 4 08:56:10 sky master[25733]: process 25737 exited, status 0 Jun 4 08:56:33 sky lmtpunix[25739]: accepted connection Jun 4 08:56:33 sky lmtpunix[25739]: lmtp connection preauth'd as postman Jun 4 08:56:33 sky master[25742]: about to exec /usr/lib/cyrus/bin/lmtpd Jun 4 08:56:33 sky lmtpunix[25739]: duplicate_check: <20050604065633.955F361AD9@sky.pmz> user.root 0 Jun 4 08:56:33 sky lmtpunix[25742]: executed Jun 4 08:56:33 sky lmtpunix[25739]: mystore: starting txn 2147483651 Jun 4 08:56:33 sky lmtpunix[25739]: mystore: committing txn 2147483651 Jun 4 08:56:33 sky lmtpunix[25739]: duplicate_mark: <20050604065633.955F361AD9@sky.pmz> user.root 1117868193 18516 Jun 4 08:56:33 sky lmtpunix[25739]: mystore: starting txn 2147483652 Jun 4 08:56:33 sky lmtpunix[25739]: mystore: committing txn 2147483652 Jun 4 08:56:33 sky lmtpunix[25739]: duplicate_mark: <20050604065633.955F361AD9@sky.pmz> .root+@.sieve. 1117868193 0

Das sieht eigentlich recht gut aus. Cyrus selbst sollte in Ordnung sein. Sandy

Martin Zambo wrote:

Hallo Sandy, Hallo Liste,

...

...

...

Auf dem Sytem läuft Suse 9.2 aktualisiert, Cyrus-IMAP der zur Clientseite

...

...

...

auch funktioniert.Nur kommen da keine Mails an, fetchmail holt ab und weiter kommen die mails dann nicht.

...

Das heisst, die Anwender können sich anmelden, sehen ihre alten Mails, es

...

kommen aber keine neuen herein?

Genau, so ist es.

Dann dürfte Cyrus normal funktionieren. Was steht denn in /etc/cyrus.conf als lmtpunix? So sieht es bei mir aus: lmtp cmd="lmtpd" listen="lmtp" prefork=0 lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=0

...

Nach dem Start von fetchmail:

...

sky:/home/martin # fetchmail 61 Nachrichten für xxxx-52-1 bei pop.1und1.com (678336 Oktetts). Nachricht xxxx-52-1@pop.1und1.com:1 von 61 wird gelesen (2752 Oktetts) ..

bleibt es so stehen es geht nicht weiter.

...

Werden die restlichen Mails abgeholt und erscheinen sie in der Ausgabe von

...

mailq?

Die Maiq ist heute wieder leer, die Mails von gestern sind irgend wie verschwunden.

Dann wurden Sie ausgeliefert oder gebouncet. Könntest du mal in /etc/sysconfig/fetchmail den Parameter "FETCHMAIL_SILENT=no" setzen, dann loggt fetchmail jede Mail.

...

...

EA50761C6F 492 Sat Jun 4 01:39:01 root@sky.pmz (temporary failure. Command output: couldn't connect to lmtpd: Bad file descriptor_ 421 4.3.0 deliver: couldn't connect to lmtpd_) root@sky.pmz

sky:/home/martin # postconf -n

luser_relay = mz@it-zambo.de

Das funktioniert leider nur solange, bis Spammer entdecken, dass alle Mails mit so einem Catch-all ausgeliefert werden. Dann hagelt es SPAM...

mailbox_command = /usr/lib/cyrus/bin/deliver

mailbox_command = kann leer bleiben, darum kümmert sich bereits mailbox_transport. Du könntest aber auch noch explizit angeben: fallback_transport = lmtp:unix:/var/lib/imap/socket/lmtp

mailbox_size_limit = 51200000 mailbox_transport = cyrus mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient mydestination = $myhostname, localhost.$mydomain myhostname = sky.pmz mynetworks = 10.0.0.0/24, 127.0.0.0/8

Hier würde ich noch die inet_interfaces = (all oder ip Adresse) reinbringen. Per Default lauscht Postfix nur auf localhost, jetzt würde ich aber nicht beschwören, ob er eine solche Default-Einstellung auch bei einer Übernahme macht. Mit "netstat -tulpen" findest du schnell heraus, auf welchen IPs und Ports welches Programm lauscht.

smtpd_sender_restrictions = hash:/etc/postfix/access

Ist in der Datei irgendetwas drin?

strict_rfc821_envelopes = yes transport_maps = hash:/etc/postfix/transport Steht hier irgendetwas drin?

Sinnvoll ist es bestimmt auch smtpd_recipient_restrictions explizit anzugeben.

master.cf # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd localhost:10025 inet n - n - - smtpd -o content_filter = smtp-amavis:[127.0.0.1]:10024

Ah, hier wird es interessant. Könntest du bitte prüfen, ob amavis überhaupt läuft? rcamavis status Mails kommen also über fetchmail und smtp herein und sollen gefiltert werden. Bei mir steht es genau umgekehrt. /etc/postfix/master.cf: smtp inet n - n - 2 smtpd -o content_filter=smtp:127.0.0.1:10024 localhost:10025 inet n - n - - smtpd -o content_filter= Mails kommen herein und werden mit dem content_filter über Port 10024 an amavis übergeben. In /etc/amavisd.conf steht dann: # SMTP SERVER (INPUT) PROTOCOL SETTINGS (e.g. with Postfix, Exim v4, ...) # (used when MTA is configured to pass mail to amavisd via SMTP or LMTP) $inet_socket_port = 10024; # accept SMTP on this local TCP port # POSTFIX, or SENDMAIL in dual-MTA setup, or EXIM V4 # (set host and port number as required; host can be specified # as IP address or DNS name (A or CNAME, but MX is ignored) $forward_method = 'smtp:127.0.0.1:10025'; # where to forward checked mail $notify_method = $forward_method; # where to submit notifications amavis verarbeitet die Mails also und schickt sie dann weiter an localhost:10025. Dort wiederum lauscht Postfix, diesmal ohne content_filter und übergibt die Mail an den Transport. /etc/postfix/main.cf: mailbox_transport=cyrus /etc/postfix/master.cf: cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} Das sollte es dann eigentlich gewesen sein. Wenn es bei dir hakt, auch wenn die oben genannten Einstellungen noch einmal alle geprüft sind, dann wird es allmählich Zeit, ans Eingemachte zu gehen, sprich, die Konfiguration auf das absolute Minimum zu beschränken, das zum Funktionieren zu bringen und dann die übrigen Funktionen wieder einfügen. Der erste Kandidat dafür wäre amavis. Das sieht bei dir etwas seltsam aus. Auf den ersten Blick komme ich nicht dahinter, wie die localhost:10025 jemals in Funktion tritt. Der scheint in der Luft zu hängen. Wenn du testweise mal amavis deaktivieren willst, dann kommentiere einfach mal die Optionen auf localhost:10025 aus. Siehst du eigentlich amavis-Meldungen im Log? Im Ablauf also: Internetmail -> SMTP Port 25 kommuniziert mit Postfix -> Postfix übergibt intern per localhost:10024 an amavisd -> Amavisd: prüft Mail auf Viren und Spam -> übergibt an localhost:10025 Postfix nimmt wieder entgegen auf localhost:10025 und leitet sie weiter über transport:cyrus , ruft also /usr/lib/cyrus/bin/deliver auf, um an Cyrus zu übergeben.

...

Wenn dort lmtp verwendet wird, sollte er natürlich genau übereinstimmen mit der Datei, die Cyrus dafür verwendet und Postfix sollte nicht chroot laufen. Bei mir wäre die richtige Datei /var/lib/imap/socket/lmtp.

Wie kann ich das prüfen?

Sollte nicht notwendig sein, aber ob es die richtige Datei ist, sollte in /etc/cyrus.conf stehen.

...

...

Nur mit einer korrekten Konfiguration. Die Mails hängen in der Queue, können aber nicht an Cyrus weitergeleitet werden. Sobald die Konfiguration stimmt und Postfix neu gestartet wird, werden auch die Mails wieder zugestellt.

Die Konfiguration lief unter suse 9.0 ohne Probleme.

Ich hatte nach dem Upgrade von 9.1 nach 9.2 das Problem, dass saslauthd nicht als Startdienst übernommen wurde und ich plötzlich nicht mehr in cyrus reinkam. Das konnte ich zum Glück recht schnell feststellen und durch das Starten des saslauthd beheben.

...

Beschreibe bitte mal präzise, WIE du upgedatet hast. Ich habe das Gefühl, dass es hier ein Problem gibt.

Rechner neu gestartet, von CD gebootet, dann statt Neuinstallation update ausgewählt. Nach dem das durchgelaufen ist habe ich ein Online Update gemacht, die rpmsave Dateien reaktiviert und damit die Konfigurationsdateien aus 9.0

Gab es noch größere Probleme mit den aktualisierten Konfigurationsdateien oder warum hast du die alten verwendet? Die vorhandenen sollten eigentlich korrekt angepasst sein durch das Upgrade. Hast du die durch das Upgrade erstellten Konfigurationsdateien aufgehoben? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com

Am Montag, 6. Juni 2005 10:52 schrieb Martin Zambo:

Hallo Sandy, Hallo Dieter, Hallo Liste,

vielen Dank für die Hilfe, jetzt läuft alles bis auf ein Problem. Mails kommen wieder rein und werden auch wieder richtig sortiert. Wenn ich aber auf den Imap-Server zugreife bekomme ich die Fehlermeldung Status der Ressource lässt sich nicht ermitteln.

In /var/log/messages steht,

Jun 6 10:40:32 sky imap[20413]: skiplist: invalid magic header: /var/lib/imap/user/m/martin.seen Jun 6 10:40:32 sky imap[20413]: DBERROR: opening /var/lib/imap/user/m/martin.seen: cyrusdb error

Das was Dieter dazu vorgeschlagen hat habe ich probiert, Cyrus gestoppt su cyrus /usr/bin/db_recover -h /var/lib/imap/user/m/

Da bekomme ich keine Fehlerausgabe.

rccyrus start Dann steht in der messages: 10:47:08 sky ctl_cyrusdb[20561]: archiving log file: /var/lib/imap/db/log.0000000001 Jun 6 10:47:08 sky ctl_cyrusdb[20561]: archiving database file: /var/lib/imap/mailboxes.db Jun 6 10:47:08 sky ctl_cyrusdb[20561]: archiving log file: /var/lib/imap/db/log.0000000001 Jun 6 10:47:08 sky ctl_cyrusdb[20561]: done checkpointing cyrus databases Jun 6 10:47:08 sky master[20557]: process 20561 exited, status 0

Mein Problem bleibt, KMail meldet: Status der Ressource lässt sich nicht ermitteln Ein Versuch, den Status der Ressource Keine Informationen zu INBOX erhältlich.Serverantwort: System I/O error zu ermitteln, ist fehlgeschlagen. Daten wie Name, Typ, Größe usw. lassen sich damit nicht feststellen.

In messages kommen dann wieder diese Meldungen: er/m/martin.seen Jun 6 10:49:17 sky imap[20576]: DBERROR: opening /var/lib/imap/user/m/martin.seen: cyrusdb error Jun 6 10:49:17 sky imap[20576]: skiplist: invalid magic header: /var/lib/imap/user/m/martin.seen Jun 6 10:49:17 sky imap[20576]: DBERROR: opening /var/lib/imap/user/m/martin.seen: cyrusdb error

Hallo, versuch doch mal folgendes: Cyrus stoppen und dann: su cyrus /usr/cyrus/bin/reconstruct -r user.martin evtl. auch noch für andere User machen, oder die Option -a hinzufügen für alle Konten. Kann auch sein, dass der Befehl bei dir etwas woanders liegt, ich kenne das hier nur von einer relativ alten Version. Mfg, Thomas

Am Dienstag, 7. Juni 2005 07:40 schrieb Martin Zambo:

Hallo Sandy, Hallo Liste,

ich habe wie dieter vorgeschlagen hatte das folgende gemacht:

versuch doch mal folgendes: Cyrus stoppen und dann: su cyrus /usr/cyrus/bin/reconstruct -r user.martin Das war ich übrigens....

Das Ergebniss war das fast alle Ordner und auch fast alle E-Mails weg waren. Dann habe ich den Mailorden umbenannt, den Ordner aus der Datensicherung in das Mailverzeichniss geschoben, cyrus neu gestartet und es hat sich nichts verändert, die Mails sind wieder auf dem Server werden aber nicht mehr angezeigt, nur noch 2 Ordner der Rest ist nicht sichtbar.

Dann habe ich nochmal Dieter Voschlag probiert, mit folgendem Ergebniss:

cyrus@sky:/home/martin> /usr/lib/cyrus/bin/reconstruct -r user.martin user.martin: Mailbox has an invalid format user.martin.Dlug: Mailbox has an invalid format user.martin.Elug: Mailbox has an invalid format user.martin.Faxgate: Mailbox has an invalid format user.martin.Hausbau: Mailbox has an invalid format user.martin.Liste: Mailbox has an invalid format user.martin.Niko: Mailbox has an invalid format user.martin.Postfix: Mailbox has an invalid format user.martin.Schrott: Mailbox has an invalid format user.martin.Send: Mailbox has an invalid format user.martin.Sent: Mailbox has an invalid format user.martin.Skyrix: Mailbox has an invalid format user.martin.Suse: Mailbox has an invalid format user.martin.Trash: Mailbox has an invalid format user.martin.Wippermann: Mailbox has an invalid format user.martin.ebay: System I/O error Permission denied user.martin.freier support: Mailbox has an invalid format user.martin.lx-office: Mailbox has an invalid format user.martin.mantion: Mailbox has an invalid format user.martin.web: Mailbox has an invalid format

Habt ihr noch eine Idee wie ich das reparieren kann? Das Problem hab ich auch bei einigen Mailkonten, aber das kam irgendwie von alleine. Die lassen sich nicht mal mehr löschen. user.martin.ebay: System I/O error Permission denied Das deutet auf einen Rechte Fehler hin. Überprüf mal den Besitzer der Dateien, das müsste cyrus sein. So einen Fehler hatte ich aber auch mal, als mein EXT2-Dateisystem Probleme gemacht hat. Wie bekomme ich die Sicherung, also Kopie des alten /var/spool/imap reaktiviert?

Hast du auch mal die db zurückgesichert? Mfg, Thomas

Hallo Liste, nochmals vielen Dank für eure Lösungsvorschläge, hat aber leider alles nichts gebracht, Meine Idee währe die Mails die ich gesichert habe in eine vollige Neuinstallation des cyrus einzubinden, besteht da eine Möglichkeit? Ich habe vor dem Update von 9.0 auf 9.2 das komplette /var gesichert, ist es damit möglich die Daten so vorzubereiten das ich sie in ein neue Installation von cyrus einspiele? Ich habe ein Reservesystem was ich neu installiert habe zur Verfügung auch 9.2 wie könnte ich die Mails da rein bekommen. Bisher habe ich das so gemacht in dem ich beide Systeme parallel in K-Mail eingerichtet habe und dann die Mails ordnerweise kopiert. Es währe aber schön wenn es ohne das zweite System ginge. Danke für eure Hilfe Mit freundlichem Gruss Martin Zambo