Problem mit cyrus-imap nach Wechsel zu 10.2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Freunde, um meine Mails auch unter 10.2 zu behalten, habe ich /var/lib/imap/ und /var/spool/imap/ kopiert. Beim Start erhalte ich diese Fehlermeldung: Dec 20 14:47:41 marina master[3488]: about to exec /usr/lib/cyrus/bin/imapd Dec 20 14:47:41 marina imap[3488]: DBERROR db4: PANIC: fatal region error detected; run recovery Ein "ctl_cyrusdb -r" als cyrus bringt leider auch nichts. Was kann ich tun? Gibt es einen anderen Weg den imap von 10.1 nach 10.2 zu migrieren? Vielen Dank! Walze. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFiUM0WWDSer2je2cRAsplAJ4r+InUbOpaytgVOLHqf7Pgf9en2ACeIAx3 FC8aBEgbSze1eE4Yu9tXRQU= =pzwS -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Wednesday 20 December 2006 15:05, Frank G. Walzebuck wrote:
um meine Mails auch unter 10.2 zu behalten, habe ich /var/lib/imap/ und /var/spool/imap/ kopiert. Beim Start erhalte ich diese Fehlermeldung:
Dec 20 14:47:41 marina master[3488]: about to exec /usr/lib/cyrus/bin/imapd Dec 20 14:47:41 marina imap[3488]: DBERROR db4: PANIC: fatal region error detected; run recovery
Ein "ctl_cyrusdb -r" als cyrus bringt leider auch nichts. Was kann ich tun? Gibt es einen anderen Weg den imap von 10.1 nach 10.2 zu migrieren?
Hast Du darauf geachtet, die gleichen DB-Backends zu benutzen? Wenn nicht, musst Du die Datenbanken konvertieren bzw. bei einigen kann man die einfach löschen. $ man cvt_cyrusdb -- Andreas Winkelmann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Freunde,
um meine Mails auch unter 10.2 zu behalten, habe ich /var/lib/imap/ und /var/spool/imap/ kopiert. Beim Start erhalte ich diese Fehlermeldung:
Dec 20 14:47:41 marina master[3488]: about to exec /usr/lib/cyrus/bin/imapd Dec 20 14:47:41 marina imap[3488]: DBERROR db4: PANIC: fatal region error detected; run recovery
Ein "ctl_cyrusdb -r" als cyrus bringt leider auch nichts. Was kann ich tun? Gibt es einen anderen Weg den imap von 10.1 nach 10.2 zu migrieren?
Erst unter 10.1 die Datenbanken in Klartext sichern und dann unter 10.2 die Datenbanken wieder importieren. Wenn du keine 10.1 mehr hast, dann setze schnell eine vmware auf mit 10.1, kopiere dort die Datenbanken hin und konvertiere sie dort. Wenn die Pfade zu den Datenbanken nicht passen oder die Formate nicht die bei dir verwendeten sind, musst du die Scripte entsprechend anpassen. Export auf altem System: # export mailboxes.db su - cyrus -c 'ctl_mboxlist -d >/var/lib/imap/mailboxes_export.txt' # export seen databases (eine Zeile): su - cyrus -c 'for seenfile in `find /var/lib/imap/user -name \*.seen`; do /usr/lib/cyrus/bin/cvt_cyrusdb $seenfile skiplist ${seenfile%seen}txt flat; done' # export deliver.db (prüfe dein eigenes format, bei mir berkeley-nosync): su - cyrus -c '/usr/lib/cyrus/bin/cvt_cyrusdb /var/lib/imap/deliver.db berkeley-nosync /var/lib/imap/deliver.txt flat' Dann die ganzen Daten rüberkopieren Prüfe, ob der Besitzer der Daten cyrus:mail ist, und setze den Besitzer notfalls richtig. Import neues System: rccyrus stop # Lösche alte Datenbanken rm /var/lib/imap/db/* rm /var/lib/imap/tls_sessions.db rm /var/lib/imap/mailboxes.db rm /var/lib/imap/deliver.db find /var/lib/imap/ -type f -name *.seen | xargs rm # import mailboxes.db su - cyrus -c 'ctl_mboxlist -u </var/lib/imap/mailboxes_export.txt' # import seen databases (eine Zeile): su - cyrus -c 'for txtfile in `find /var/lib/imap/user -name \*.txt`; do /usr/lib/cyrus/bin/cvt_cyrusdb $txtfile flat ${txtfile%txt}seen skiplist; done' # import deliver.db: su - cyrus -c '/usr/lib/cyrus/bin/cvt_cyrusdb /var/lib/imap/deliver.txt flat /var/lib/imap/deliver.db berkeley-nosync' rccyrus start Dann sollte Cyrus wieder laufen und die Datenbanken wieder auf dem korrekten Stand sein (mailboxes, seen, deliver). Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Sandy, vielen Dank für Deine Antwort! Ich habe es nachvollzogen und erhalte die folgende Meldung: ./cyrus_restore.sh Shutting down IMAP/POP3 service (cyrus-imapd) done rm: cannot remove `/var/lib/imap/tls_sessions.db': No such file or directory rm: cannot remove `/var/lib/imap/deliver.db': No such file or directory rm: missing operand Try `rm --help' for more information. Converting from /var/lib/imap/deliver.txt (flat) to /var/lib/imap/deliver.db (berkeley- nosync) Warning: apparently empty database converted. Starting IMAP/POP3 service (cyrus-imapd) done
Wenn die Pfade zu den Datenbanken nicht passen oder die Formate nicht die bei dir verwendeten sind, musst du die Scripte entsprechend anpassen.
Da habe ich wohl ein anderes Datenbankformat. Wie bekomme ich es raus? Wie muß ich Deine Skripte anpassen? Ich benutze die Standardeinstellungen von SUSE... Vielen Dank für Deine Hilfe! Walze. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFisCkWWDSer2je2cRApZrAJ0StgBt5jwdPvVLSlkMVD0ygUR6zgCePPXh 92LV1eFfJCZi0+hRATEpfyc= =ExEN -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Sandy,
vielen Dank für Deine Antwort! Ich habe es nachvollzogen und erhalte die folgende Meldung:
./cyrus_restore.sh Shutting down IMAP/POP3 service (cyrus-imapd) done rm: cannot remove `/var/lib/imap/tls_sessions.db': No such file or directory rm: cannot remove `/var/lib/imap/deliver.db': No such file or directory rm: missing operand
Schau doch mal nach, wo bei dir das Defaultverzeichnis von Cyrus liegt: In /etc/imapd.conf: configdirectory: /var/lib/imap partition-default: /var/spool/imap Darauf musst du die Scripte anpassen. Sieh auch bitte nach, welcher Adminuser eingetragen ist. und verwende diesen gegebenenfalls für die Ausführung der Scripte, wenn es nicht cyrus ist. Das Restore kann natürlich erst auf dem neuen Rechner ausgeführt werden und erwartet dann die vom alten System konvertierten Datenbanken als .txt Export. Ist das denn geschehen? Gab es Warnungen beim Export?
Try `rm --help' for more information. Converting from /var/lib/imap/deliver.txt (flat) to /var/lib/imap/deliver.db (berkeley- nosync) Warning: apparently empty database converted. Starting IMAP/POP3 service (cyrus-imapd) done
Wenn die Pfade zu den Datenbanken nicht passen oder die Formate nicht die bei dir verwendeten sind, musst du die Scripte entsprechend anpassen.
Da habe ich wohl ein anderes Datenbankformat. Wie bekomme ich es raus? Wie muß ich Deine Skripte anpassen? Ich benutze die Standardeinstellungen von SUSE...
In der Hilfe zu "man 5 imapd.conf" stehen immer die Defaults für die Datenbanken. Notfalls kannst du aber ohne die deliver.db anfangen, die legt Cyrus dann automatisch an. Bei meinem System (Suse 9.2): deliver.db: duplicate_db: berkeley-nosync The cyrusdb backend to use for the duplicate delivery suppression and sieve. mailboxes.db: mboxlist_db: skiplist The cyrusdb backend to use for the mailbox list. Allowed values: flat, berkeley, skiplist seen.db seenstate_db: skiplist The cyrusdb backend to use for the seen state. Allowed values: flat, berkeley, skiplist Suche mal, was für dein System gilt. Zwingend notwendig: mailboxes.db Für Anwender wichtig, aber notfalls auch löschen und durch Cyrus neu anlegen lassen: seen.db Nicht so kritisch aber nett, notfalls löschen und durch Cyrus neu anlegen lassen: deliver.db Was meldet Cyrus (auf dem neuen System) denn im Log, wenn du nach dem Konvertieren der mailboxes.db Cyrus startest? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Sandy,
Schau doch mal nach, wo bei dir das Defaultverzeichnis von Cyrus liegt:
In /etc/imapd.conf: configdirectory: /var/lib/imap partition-default: /var/spool/imap
Darauf musst du die Scripte anpassen. Sieh auch bitte nach, welcher Adminuser eingetragen ist. und verwende diesen gegebenenfalls für die Ausführung der Scripte, wenn es nicht cyrus ist.
paßt alles!
Das Restore kann natürlich erst auf dem neuen Rechner ausgeführt werden und erwartet dann die vom alten System konvertierten Datenbanken als .txt Export. Ist das denn geschehen? Gab es Warnungen beim Export?
Nö: walze:~/cyrus # ./cyrus_backup.sh Shutting down IMAP/POP3 service (cyrus-imapd) done Converting from /var/lib/imap/user/e/eve.seen (skiplist) to /var/lib/imap/user/e/eve.txt (flat) Converting from /var/lib/imap/user/m/marina.seen (skiplist) to /var/lib/imap/user/m/marina.txt (flat) Converting from /var/lib/imap/user/w/walze.seen (skiplist) to /var/lib/imap/user/w/walze.txt (flat) Converting from /var/lib/imap/deliver.db (berkeley-nosync) to /var/lib/imap/deliver.txt (flat) Starting IMAP/POP3 service (cyrus-imapd) done
Zwingend notwendig: mailboxes.db
Was ist damit? Auch mit kopieren? Ich denke nur die *.txt-Files?
Für Anwender wichtig, aber notfalls auch löschen und durch Cyrus neu anlegen lassen: seen.db
Nicht so kritisch aber nett, notfalls löschen und durch Cyrus neu anlegen lassen: deliver.db
Was meldet Cyrus (auf dem neuen System) denn im Log, wenn du nach dem Konvertieren der mailboxes.db Cyrus startest?
Dec 21 20:18:28 marina master[16065]: SLPderegister [service:imap://marina.:143] Dec 21 20:18:28 marina master[16065]: SLPderegister [service:pop3://marina.:110] Dec 21 20:18:28 marina master[16065]: SLPderegister [service:sieve://marina.:2000] Dec 21 20:18:28 marina master[16065]: exiting on SIGTERM/SIGINT Dec 21 20:18:28 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:28 marina ctl_mboxlist[16175]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:28 marina ctl_mboxlist[16175]: skiplist: recovered /var/lib/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds Dec 21 20:18:28 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:29 marina cvt_cyrusdb[16197]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16197]: skiplist: recovered /var/lib/imap/user/m/marina.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina cvt_cyrusdb[16198]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16198]: skiplist: recovered /var/lib/imap/user/e/eve.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina cvt_cyrusdb[16199]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16199]: skiplist: recovered /var/lib/imap/user/w/walze.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:29 marina cvt_cyrusdb[16201]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina master[16229]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Dec 21 20:18:29 marina master[16229]: retrying with 8192 (current max) Dec 21 20:18:29 marina master[16229]: process started Dec 21 20:18:29 marina master[16230]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Dec 21 20:18:29 marina ctl_cyrusdb[16230]: recovering cyrus databases Dec 21 20:18:30 marina ctl_cyrusdb[16230]: skiplist: recovered /var/lib/imap/mailboxes.db (31 records, 2308 bytes) in 1 second Dec 21 20:18:30 marina ctl_cyrusdb[16230]: skiplist: recovered /var/lib/imap/annotations.db (0 records, 144 bytes) in 0 seconds Dec 21 20:18:30 marina ctl_cyrusdb[16230]: done recovering cyrus databases Dec 21 20:18:30 marina master[16231]: about to exec /usr/lib/cyrus/bin/idled Dec 21 20:18:30 marina master[16229]: SLPRegister [service:imap://marina.:143] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: SLPRegister [service:pop3://marina.:110] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: SLPRegister [service:sieve://marina.:2000] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: ready for work Dec 21 20:18:30 marina master[16233]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Dec 21 20:18:30 marina ctl_cyrusdb[16233]: checkpointing cyrus databases Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving database file: /var/lib/imap/annotations.db Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving database file: /var/lib/imap/mailboxes.db Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: done checkpointing cyrus databases Dec 21 20:18:30 marina master[16229]: process 16233 exited, status 0 Dec 21 20:19:09 marina master[16253]: about to exec /usr/lib/cyrus/bin/imapd Dec 21 20:19:09 marina imap[16253]: executed Dec 21 20:19:09 marina imap[16253]: accepted connection Dec 21 20:19:09 marina imap[16253]: login: localhost [127.0.0.1] walze plaintext User logged in Dec 21 20:19:09 marina imap[16253]: IOERROR: opening /var/spool/imap/user/walze/cyrus.header: No such file or directory Dec 21 20:20:14 marina master[16229]: process 16253 exited, status 0 Irgendwie verstehe ich den Cyrus nicht... Vielen Dank! Walze. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFiuA5WWDSer2je2cRAnH8AJ9UvphTD0vDoEnJQQdKYfOC8uQCSgCeImIP Up+B3nhUlEFyTcgTJ5oESIM= =DOqT -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Sandy,
Schau doch mal nach, wo bei dir das Defaultverzeichnis von Cyrus liegt:
In /etc/imapd.conf: configdirectory: /var/lib/imap partition-default: /var/spool/imap
Darauf musst du die Scripte anpassen. Sieh auch bitte nach, welcher Adminuser eingetragen ist. und verwende diesen gegebenenfalls für die Ausführung der Scripte, wenn es nicht cyrus ist.
paßt alles!
OK.
Das Restore kann natürlich erst auf dem neuen Rechner ausgeführt werden und erwartet dann die vom alten System konvertierten Datenbanken als .txt Export. Ist das denn geschehen? Gab es Warnungen beim Export?
Nö:
walze:~/cyrus # ./cyrus_backup.sh Shutting down IMAP/POP3 service (cyrus-imapd) done Converting from /var/lib/imap/user/e/eve.seen (skiplist) to /var/lib/imap/user/e/eve.txt (flat) Converting from /var/lib/imap/user/m/marina.seen (skiplist) to /var/lib/imap/user/m/marina.txt (flat) Converting from /var/lib/imap/user/w/walze.seen (skiplist) to /var/lib/imap/user/w/walze.txt (flat) Converting from /var/lib/imap/deliver.db (berkeley-nosync) to /var/lib/imap/deliver.txt (flat) Starting IMAP/POP3 service (cyrus-imapd) done
Zwingend notwendig: mailboxes.db
Was ist damit? Auch mit kopieren? Ich denke nur die *.txt-Files?
Auf jeden Fall muss die exportierte txt-Datei kopiert werden. Wenn du faul bist, kannst du auch die letzte aus dem Verzeichnis /var/lib/imap/backup/ nehmen. Suse legt dort täglich ein Backup der mailboxes.db in flat Format ab. Export auf altem System: # export mailboxes.db su - cyrus -c 'ctl_mboxlist -d >/var/lib/imap/mailboxes.txt' Diese mailboxes.txt brauchen wir auf dem neuen System, um die mailboxes.db daraus zu erstellen.
Was meldet Cyrus (auf dem neuen System) denn im Log, wenn du nach dem Konvertieren der mailboxes.db Cyrus startest?
Dec 21 20:18:28 marina master[16065]: SLPderegister [service:imap://marina.:143] Dec 21 20:18:28 marina master[16065]: SLPderegister [service:pop3://marina.:110] Dec 21 20:18:28 marina master[16065]: SLPderegister [service:sieve://marina.:2000] Dec 21 20:18:28 marina master[16065]: exiting on SIGTERM/SIGINT Dec 21 20:18:28 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:28 marina ctl_mboxlist[16175]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:28 marina ctl_mboxlist[16175]: skiplist: recovered /var/lib/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds
Das sieht aber nach einer leeren mailboxes.db aus. Nicht gut!
Dec 21 20:18:28 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:29 marina cvt_cyrusdb[16197]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16197]: skiplist: recovered /var/lib/imap/user/m/marina.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina cvt_cyrusdb[16198]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16198]: skiplist: recovered /var/lib/imap/user/e/eve.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina cvt_cyrusdb[16199]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina cvt_cyrusdb[16199]: skiplist: recovered /var/lib/imap/user/w/walze.seen (0 records, 144 bytes) in 0 seconds Dec 21 20:18:29 marina su: (to cyrus) root on /dev/pts/1 Dec 21 20:18:29 marina cvt_cyrusdb[16201]: DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or directory Dec 21 20:18:29 marina master[16229]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Dec 21 20:18:29 marina master[16229]: retrying with 8192 (current max) Dec 21 20:18:29 marina master[16229]: process started Dec 21 20:18:29 marina master[16230]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Dec 21 20:18:29 marina ctl_cyrusdb[16230]: recovering cyrus databases Dec 21 20:18:30 marina ctl_cyrusdb[16230]: skiplist: recovered /var/lib/imap/mailboxes.db (31 records, 2308 bytes) in 1 second
Das sieht schon besser aus.
Dec 21 20:18:30 marina ctl_cyrusdb[16230]: skiplist: recovered /var/lib/imap/annotations.db (0 records, 144 bytes) in 0 seconds Dec 21 20:18:30 marina ctl_cyrusdb[16230]: done recovering cyrus databases Dec 21 20:18:30 marina master[16231]: about to exec /usr/lib/cyrus/bin/idled Dec 21 20:18:30 marina master[16229]: SLPRegister [service:imap://marina.:143] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: SLPRegister [service:pop3://marina.:110] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: SLPRegister [service:sieve://marina.:2000] Dec 21 20:18:30 marina master[16229]: Error registering service with slp -20 Dec 21 20:18:30 marina master[16229]: ready for work Dec 21 20:18:30 marina master[16233]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb Dec 21 20:18:30 marina ctl_cyrusdb[16233]: checkpointing cyrus databases Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving database file: /var/lib/imap/annotations.db Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving database file: /var/lib/imap/mailboxes.db Dec 21 20:18:30 marina ctl_cyrusdb[16233]: archiving log file: /var/lib/imap/db/log.0000000001 Dec 21 20:18:30 marina ctl_cyrusdb[16233]: done checkpointing cyrus databases Dec 21 20:18:30 marina master[16229]: process 16233 exited, status 0 Dec 21 20:19:09 marina master[16253]: about to exec /usr/lib/cyrus/bin/imapd Dec 21 20:19:09 marina imap[16253]: executed Dec 21 20:19:09 marina imap[16253]: accepted connection Dec 21 20:19:09 marina imap[16253]: login: localhost [127.0.0.1] walze plaintext User logged in Dec 21 20:19:09 marina imap[16253]: IOERROR: opening /var/spool/imap/user/walze/cyrus.header: No such file or directory
Gibt es cyrus.header dort wirklich nicht oder ist der Besitzer nicht cyrus:mail? Prüfe bitte for alle Dateien in var/spool/imap/, ob der Besitzer cyrus:mail ist.
Dec 21 20:20:14 marina master[16229]: process 16253 exited, status 0
status 0 ist doch in Ordnung. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sandy,
Gibt es cyrus.header dort wirklich nicht oder ist der Besitzer nicht cyrus:mail? Prüfe bitte for alle Dateien in var/spool/imap/, ob der Besitzer cyrus:mail ist.
/var/spool/imap auf dem Zielsystem ist leer. Vielen Dank! Walze. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFiu3YWWDSer2je2cRApAJAJ4uX1BP3oi1/nFLSNd8sShjhMzw4wCeIme5 4MegIBsw9EgOokwfKWnGNow= =372y -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Sandy,
Gibt es cyrus.header dort wirklich nicht oder ist der Besitzer nicht cyrus:mail? Prüfe bitte for alle Dateien in var/spool/imap/, ob der Besitzer cyrus:mail ist.
/var/spool/imap auf dem Zielsystem ist leer.
Versuche zuerst einmal, auf dem Zielsystem einen neuen Account anzulegen und auf diesen zuzugreifen per IMAP. Wenn das funktioniert, hast du ein lauffähiges Cyrus System und kannst die Daten hineinkopieren: Falls du dich als cyrus nicht anmelden kannst in cyradm, vergleiche die Einstellungen, insbesondere die SASL-Einstellungen in /etc/imapd.conf. Dann - fährst du also auf dem alten System Cyrus runter - exportierst mailboxes.db, seen.db, deliver.db - fährst auf dem Zielsystem Cyrus runter - löschst alle Dateien unter /var/lib/imap - kopierst die Daten auf das Zielsystem - Löschst alle *.db in /var/lib/imap (auf Zielsystem) - Löschst den Inhalt von /var/lib/imap/db/* - importierst mailboxes.db auf Zielsystem - löscht die alten .seen in /var/spool/mail - importierst die .seen aus den .txt - importierst die deliver.db - fährst Cyrus auf dem neuen System hoch - Kontrolle im Log, ob Fehler auftauchen, insbesondere db error. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Sandy,
- fährst du also auf dem alten System Cyrus runter - exportierst mailboxes.db, seen.db, deliver.db - fährst auf dem Zielsystem Cyrus runter - löschst alle Dateien unter /var/lib/imap - kopierst die Daten auf das Zielsystem - Löschst alle *.db in /var/lib/imap (auf Zielsystem) - Löschst den Inhalt von /var/lib/imap/db/* - importierst mailboxes.db auf Zielsystem - löscht die alten .seen in /var/spool/mail - importierst die .seen aus den .txt - importierst die deliver.db - fährst Cyrus auf dem neuen System hoch - Kontrolle im Log, ob Fehler auftauchen, insbesondere db error.
Mit ein wenig Ruhe und Bedacht hat es nun prima geklappt. Vielen Dank Sandy! Für all diejenigen, die vor dem gleichen Problem stehen, hier die beiden Skripte. (Benutzung auf eigene Gefahr.) ___________________________________________________________________ #!/bin/bash # cyrus-Backup rcfetchmail stop rcpostfix stop rccyrus stop # export mailboxes.db su - cyrus -c 'ctl_mboxlist -d >/var/lib/imap/mailboxes_export.txt' # export seen databases (eine Zeile): su - cyrus -c 'for seenfile in `find /var/lib/imap/user -name \*.seen`; do /usr/lib/cyrus/bin/cvt_cyrusdb $seenfile skiplist ${seenfile%seen}txt flat; done' # export deliver.db (prüfe dein eigenes format, bei mir berkeley-nosync): su - cyrus -c '/usr/lib/cyrus/bin/cvt_cyrusdb /var/lib/imap/deliver.db berkeley-nosync /var/lib/imap/deliver.txt flat' rsync -avz -e ssh /var/lib/imap/ zielhost:/var/lib/imap/ rsync -avz -e ssh /var/spool/imap/ zielhost:/var/spool/imap/ rccyrus start rcpostfix start rcfetchmail start ______________________________________________________________________ #!/bin/bash # cyrus-Restore #Import neues System: rccyrus stop # Lösche alte Datenbanken rm /var/lib/imap/db/* rm /var/lib/imap/tls_sessions.db rm /var/lib/imap/mailboxes.db rm /var/lib/imap/deliver.db find /var/lib/imap/ -type f -name *.seen | xargs rm # import mailboxes.db su - cyrus -c 'ctl_mboxlist -u </var/lib/imap/mailboxes_export.txt' # import seen databases (eine Zeile): su - cyrus -c 'for txtfile in `find /var/lib/imap/user -name \*.txt`; do /usr/lib/cyrus/bin/cvt_cyrusdb $txtfile flat ${txtfile%txt}seen skiplist; done' # import deliver.db: su - cyrus -c '/usr/lib/cyrus/bin/cvt_cyrusdb /var/lib/imap/deliver.txt flat /var/lib/imap/deliver.db berkeley-nosync' rccyrus start - -- Walze. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFjA1zWWDSer2je2cRAk8bAJ940JPn3kDezRTbYr+WKlTC1eJz/wCeMLw8 cBFXaFSMx8LCDJ2WgBKWdQw= =kwS8 -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck schrieb: hatte das gleiche Problem beim Test-Umzug auf 10.2, die Korrespondez kam gerade richtig. Zusätzlich muss noch die /etc/sasldb2 mit den auth-login Daten kopiert werden, falls der Umzug auf ein neues System geht und natürlich die /etc/imapd.conf, falls die Konfiguration die gleiche bleibt. mfg Kasimir Müller -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Kasimir Müller wrote:
Frank G. Walzebuck schrieb:
hatte das gleiche Problem beim Test-Umzug auf 10.2, die Korrespondez kam gerade richtig.
Zusätzlich muss noch die /etc/sasldb2 mit den auth-login Daten kopiert werden,
"muss" nur, wenn auch sasldb für die Authentifikation eingesetzt wird. Ansonsten halt die Einträge der passwd, shadow, group oder der Datenbank, wo die Daten abgelegt sind. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Kasimir,
Zusätzlich muss noch die /etc/sasldb2 mit den auth-login Daten kopiert werden, falls der Umzug auf ein neues System geht und natürlich die /etc/imapd.conf, falls die Konfiguration die gleiche bleibt.
öhm, habe ich alles nicht gemacht. Geht trotzdem prima. Ich schreibe nun von dem neuen 10.2-System... Walze. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Frank G. Walzebuck wrote:
Hallo Kasimir,
Zusätzlich muss noch die /etc/sasldb2 mit den auth-login Daten kopiert werden, falls der Umzug auf ein neues System geht und natürlich die /etc/imapd.conf, falls die Konfiguration die gleiche bleibt.
öhm, habe ich alles nicht gemacht. Geht trotzdem prima. Ich schreibe nun von dem neuen 10.2-System...
Das ist alles nur notwendig, wenn man SICHERGEHEN will. (^-^) Normalerweise führt das Upgrade des Systems die notwendige Umwandlung von Datenbanken bei Cyrus durch. Wenn jedoch eine komplette Neuinstallation durchgeführt wird und danach dann nur die Daten eingespielt werden, dann kommst du in Probleme bei Cyrus. Auch bei Openldap, wo die Daten in einer Berkeley-DB gehalten werden, kann dies zu heftigen Problemen führen, wenn die Berkeley-DB zwischen den Systemversionen nicht kompatibel ist. Für deine eigenen Daten mag das nicht so kritisch sein, vor allem, wenn du nachträglich die Mails per Fetchmail reinholst und ein paar Stunden mehr oder weniger Ausfall nicht viel ausmachen. Wenn du jedoch einen Server umstellst, auf dem produktiv von vielen Kunden bzw. Mitarbeitern gearbeitet wird, dann möchtest du die Downtime to kurz wie möglich halten und sicherst dich entsprechend ab, damit die angekündigte Zeit für das Upgrade eingehalten werden kann. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic schrieb:
Das ist alles nur notwendig, wenn man SICHERGEHEN will. (^-^)
Normalerweise führt das Upgrade des Systems die notwendige Umwandlung von Datenbanken bei Cyrus durch. Wenn jedoch eine komplette Neuinstallation durchgeführt wird und danach dann nur die Daten eingespielt werden, dann kommst du in Probleme bei Cyrus. Auch bei Openldap, wo die Daten in einer Berkeley-DB gehalten werden, kann dies zu heftigen Problemen führen, wenn die Berkeley-DB zwischen den Systemversionen nicht kompatibel ist.
Für deine eigenen Daten mag das nicht so kritisch sein, vor allem, wenn du nachträglich die Mails per Fetchmail reinholst und ein paar Stunden mehr oder weniger Ausfall nicht viel ausmachen. Wenn du jedoch einen Server umstellst, auf dem produktiv von vielen Kunden bzw. Mitarbeitern gearbeitet wird, dann möchtest du die Downtime to kurz wie möglich halten und sicherst dich entsprechend ab, damit die angekündigte Zeit für das Upgrade eingehalten werden kann.
Sandy
Hi Sandy, ich hab heute die Umstellung 10.1 -> 10.2 auf meinem Home-Server gemacht (nach entsprechenden Vorbereitungen). Die cyrus-dbs wurden nicht (!) automatisch umgewandelt, nach den Vorbereitungen und in Kenntnis der Fakts wars dann aber kein Problem. Ein kleiner Hinweis im Update-Process bzw. am besten schon vorher wäre aber schon nett, liebe Suse-Leute ! Danke nochmal für die wichtigen Hinweise und funktionierende Problem-Lösung. Happy Xmas Kasimir -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Andreas Winkelmann -
Frank G. Walzebuck -
Kasimir Müller -
Sandy Drobic