migration with doveadm backup to new cluster running dovecot 2.2.36 and replicator
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
Thomas Winterstein
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
-- Thomas Winterstein
Hello,
I had a similar problem some time ago, and the problem was the mailbox format change.
Please try to migrate with the same format.
Andrea
Il 05/01/21 15:02, Thomas Winterstein ha scritto:
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
--
Daddy, why doesn't this magnet pick up this floppy ?
TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188
-- Informativa Privacy
Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy@telecomitalia.sm.
Avviso di Riservatezza
Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
dsync is intended to be used to change mailbox format, so it should work just fine.
Aki
On 07/01/2021 11:17 Andrea Gabellini andrea.gabellini@telecomitalia.sm wrote:
Hello,
I had a similar problem some time ago, and the problem was the mailbox format change.
Please try to migrate with the same format.
Andrea
Il 05/01/21 15:02, Thomas Winterstein ha scritto:
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
--
Daddy, why doesn't this magnet pick up this floppy ?
TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188
-- Informativa Privacy
Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy@telecomitalia.sm.
Avviso di Riservatezza
Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
dsync is intended to be used to change mailbox format, so it should work just fine.
that's exactly what we thought and why we use dsync to migrate like described here
https://wiki2.dovecot.org/Migration/Dsync
Our replication is configured according to
https://wiki.dovecot.org/Replication
Both processes run separately in time.
Still on some accounts mails of Inbox or another folder get duplicated. We're currently trying to debug this.
what are we missing?
thanks Thomas
On 07.01.2021 10:21, Aki Tuomi wrote:
dsync is intended to be used to change mailbox format, so it should work just fine.
Aki
On 07/01/2021 11:17 Andrea Gabellini andrea.gabellini@telecomitalia.sm wrote:
Hello,
I had a similar problem some time ago, and the problem was the mailbox format change.
Please try to migrate with the same format.
Andrea
Il 05/01/21 15:02, Thomas Winterstein ha scritto:
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
--
Daddy, why doesn't this magnet pick up this floppy ?
TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188
-- Informativa Privacy
Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy@telecomitalia.sm.
Avviso di Riservatezza
Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
-- Thomas Winterstein .................... http://www.rz.uni-augsburg.de/ Universität Augsburg, Rechenzentrum ............. Tel. (0821) 598-2068 86135 Augsburg .................................. Fax. (0821) 598-2028
we were able to narrow down the cause of the problem.
After the initial dsync migration process the mailbox GUIDs are the same for each mailbox-name across all users. Is this intended behaviour of dsync? If not, how can this be changed?
After the first replication process the Inboxes of ~20% of users get different mailbox GUIDs.
During the next incremental dsync process the mailbox GUIDs of these ~20% get overridden by the inital one.
Then the incremental replication duplicates those Inboxes where the mailbox GUIDs don't match.
Any ideas?
thanks Thomas
On 07.01.2021 16:41, Thomas Winterstein wrote:
dsync is intended to be used to change mailbox format, so it should work just fine.
that's exactly what we thought and why we use dsync to migrate like described here
https://wiki2.dovecot.org/Migration/Dsync
Our replication is configured according to
https://wiki.dovecot.org/Replication
Both processes run separately in time.
Still on some accounts mails of Inbox or another folder get duplicated. We're currently trying to debug this.
what are we missing?
thanks Thomas
On 07.01.2021 10:21, Aki Tuomi wrote:
dsync is intended to be used to change mailbox format, so it should work just fine.
Aki
On 07/01/2021 11:17 Andrea Gabellini andrea.gabellini@telecomitalia.sm wrote:
Hello,
I had a similar problem some time ago, and the problem was the mailbox format change.
Please try to migrate with the same format.
Andrea
Il 05/01/21 15:02, Thomas Winterstein ha scritto:
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
--
Daddy, why doesn't this magnet pick up this floppy ?
TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188
-- Informativa Privacy
Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy@telecomitalia.sm.
Avviso di Riservatezza
Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
-- Thomas Winterstein .................... http://www.rz.uni-augsburg.de/ Universität Augsburg, Rechenzentrum ............. Tel. (0821) 598-2068 86135 Augsburg .................................. Fax. (0821) 598-2028
On 11/01/2021 05:18 Thomas Winterstein thomas.winterstein@rz.uni-augsburg.de wrote:
we were able to narrow down the cause of the problem.
After the initial dsync migration process the mailbox GUIDs are the same for each mailbox-name across all users. Is this intended behaviour of dsync? If not, how can this be changed?
After the first replication process the Inboxes of ~20% of users get different mailbox GUIDs.
During the next incremental dsync process the mailbox GUIDs of these ~20% get overridden by the inital one.
Then the incremental replication duplicates those Inboxes where the mailbox GUIDs don't match.
Any ideas?
thanks Thomas
On 07.01.2021 16:41, Thomas Winterstein wrote:
dsync is intended to be used to change mailbox format, so it should work just fine.
that's exactly what we thought and why we use dsync to migrate like described here
https://wiki2.dovecot.org/Migration/Dsync
Our replication is configured according to
https://wiki.dovecot.org/Replication
Both processes run separately in time.
Still on some accounts mails of Inbox or another folder get duplicated. We're currently trying to debug this.
what are we missing?
thanks Thomas
On 07.01.2021 10:21, Aki Tuomi wrote:
dsync is intended to be used to change mailbox format, so it should work just fine.
Aki
On 07/01/2021 11:17 Andrea Gabellini andrea.gabellini@telecomitalia.sm wrote:
Hello,
I had a similar problem some time ago, and the problem was the mailbox format change.
Please try to migrate with the same format.
Andrea
Il 05/01/21 15:02, Thomas Winterstein ha scritto:
No one?
If there are limitations in regards to how dsync in migration and replication can operate together these should be stated clearly in the documentation.
On 23.12.2020 20:33, Thomas Winterstein wrote:
Hello everyone,
we are working on migrating from dovecot 2.0.9 (maildir) to 2.2.36 (mdbox). The new cluster has two backend mail servers which replicate through doveadm replicator. To move the data initially we use doveadm backup (imapc).
arb Our migration command doveadm -o mail_fsync=never backup -R -u $user imapc:
To test the replication of new and purge of old mails with live data changes we ran imapc on a daily basis but encountered the problem that some mailboxes multiplied in size. We then made sure that imapc and replication don't run at the same time but after the first incremental imapc process, we still had the same problems.
The doveadm-backup man-page states that it's possible to run it multiple times during migration. But is it also possible to have the replicator running in between? From our understanding the doveadm backup should just work as an imap connection between the servers, synchronizing all changes made on the source to the destination. Or does the conversion from maildir to mdbox format in our case produce the problems?
If you're not supposed to run the replicator before having fully migrated, how can we shorten the downtime? rsync? And how can we be sure that similar problems don't occur after the migration if we can't test all mechanisms together with live data?
thanks
When doing migration, it is very useful to construct a temporary dovecot-migration.conf which lacks *any* automatic mailbox creation and has only the bare minimum you need (sieve needs to be configured, and mailbox attributes). This means no autocreate/autosubscribe loaded, and no auto=create or auto=subscribe in namespace config. It is recommended not to have any mailbox Name entries in your namespace config.
You should use doveadm -c /path/to/dovecot-migration.conf backup command on initial sync.
The mailboxes must not exist before you do initial sync, if they do, you run into troubles.
Aki
When doing migration, it is very useful to construct a temporary dovecot-migration.conf which lacks *any* automatic mailbox creation and has only the bare minimum you need (sieve needs to be configured, and mailbox attributes). This means no autocreate/autosubscribe loaded, and no auto=create or auto=subscribe in namespace config. It is recommended not to have any mailbox Name entries in your namespace config.
You should use doveadm -c /path/to/dovecot-migration.conf backup command on initial sync.
The mailboxes must not exist before you do initial sync, if they do, you run into troubles.
I tried what you said, no autocreate/autosubscribe... etc., but none of my tests with minimal migration config changed anything in the GUID behavior.
No folders for the users existed before this command.
doveadm -D -v -c minimal-conf backup -R -u USER imapc: > output 2>&1
doveadm(USER): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER doveadm(USER): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:/srv/mail/v/USER doveadm(USER): Debug: fs: root=/srv/mail/v/USER, index=, indexpvt=, control=, inbox=, alt= doveadm(USER): Debug: Namespace : Using permissions from /srv/mail/v/USER: mode=0700 gid=default dsync(USER): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER dsync(USER): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=imapc: dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Created new connection dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Looking up IP address (reconnect_ok=true, last_connect=1610467047) dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Connecting to 137.250.1.99:143 dsync(USER): Info: imapc(zitrone.rz.uni-augsburg.de:143): Connected to 137.250.1.99:143 (local 137.250.1.121:41094) dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticating as admin for user USER dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA dsync(USER): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticated successfully dsync(USER): Debug: imapc: root=, index=, indexpvt=, control=, inbox=, alt= dsync(USER): Debug: brain S: Local mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1598518510 uid_next=434 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1598518510 uid_next=434 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1598518508 uid_next=220 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1598518508 uid_next=220 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1598518507 uid_next=10 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1598518507 uid_next=10 subs=yes last_change=0 last_subs=0 dsync(USER): Debug: brain S: Local mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1598518506 uid_next=1049 subs=no last_change=0 last_subs=0 dsync(USER): Debug: brain M: Remote mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1598518506 uid_next=1049 subs=no last_change=0 last_subs=0 ...
for user in USER; do echo $user ; for mailbox in ls /srv/mail/v/$user/mailboxes/; do echo $mailbox; doveadm search -u $user
mailbox $mailbox ALL | head -n 1; done ; done
USER Drafts INBOX c92f64f79f0d1ed01e6d5b314f04886c 28 Junk Sent bfb2e03fdce327671e82bf173b1ccb8b 1 Trash 7f5af7ba291b2df1a11d573bdb55d7e9 1
doveadm -D -v -c minimal-conf backup -R -u USER2 imapc: > output 2>&1
doveadm(USER2): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER2 doveadm(USER2): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:/srv/mail/v/USER2 doveadm(USER2): Debug: fs: root=/srv/mail/v/USER2, index=, indexpvt=, control=, inbox=, alt= doveadm(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: Effective uid=500, gid=500, home=/srv/mail/v/USER2 dsync(USER2): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=imapc: dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Created new connection dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Looking up IP address (reconnect_ok=true, last_connect=1610467389) dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Connecting to 137.250.1.99:143 dsync(USER2): Info: imapc(zitrone.rz.uni-augsburg.de:143): Connected to 137.250.1.99:143 (local 137.250.1.121:41100) dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticating as admin for user USER2 dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Server capabilities: IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA dsync(USER2): Debug: imapc(zitrone.rz.uni-augsburg.de:143): Authenticated successfully dsync(USER2): Debug: imapc: root=, index=, indexpvt=, control=, inbox=, alt= dsync(USER2): Debug: brain S: Local mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1600955712 uid_next=105 subs=no last_change=0 last_subs=0 dsync(USER2): Debug: brain S: Local mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1600955716 uid_next=33 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Remote mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1600955712 uid_next=105 subs=no last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Remote mailbox tree: Trash guid=7f5af7ba291b2df1a11d573bdb55d7e9 uid_validity=1600955716 uid_next=33 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain S: Local mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1600955714 uid_next=9 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Remote mailbox tree: Sent guid=bfb2e03fdce327671e82bf173b1ccb8b uid_validity=1600955714 uid_next=9 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain S: Local mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1600955713 uid_next=5 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Remote mailbox tree: Drafts guid=e0187b65e763143666d22094cedfe6a4 uid_validity=1600955713 uid_next=5 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain S: Local mailbox tree: Junk guid=87680557f26fcb26843f739f7427e8c4 uid_validity=1600955715 uid_next=1 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Remote mailbox tree: Junk guid=87680557f26fcb26843f739f7427e8c4 uid_validity=1600955715 uid_next=1 subs=yes last_change=0 last_subs=0 dsync(USER2): Debug: brain M: Mailbox Drafts: local=00000000000000000000000000000000/0/0, remote=e0187b65e763143666d22094cedfe6a4/0/1: mailbox not selectable yet dsync(USER2): Debug: brain M: Mailbox INBOX: local=00000000000000000000000000000000/0/0, remote=c92f64f79f0d1ed01e6d5b314f04886c/0/1: mailbox not selectable yet dsync(USER2): Debug: brain M: Mailbox Junk: local=00000000000000000000000000000000/0/0, remote=87680557f26fcb26843f739f7427e8c4/0/1: mailbox not selectable yet dsync(USER2): Debug: brain M: Mailbox Sent: local=00000000000000000000000000000000/0/0, remote=bfb2e03fdce327671e82bf173b1ccb8b/0/1: mailbox not selectable yet dsync(USER2): Debug: brain M: Mailbox Trash: local=00000000000000000000000000000000/0/0, remote=7f5af7ba291b2df1a11d573bdb55d7e9/0/1: mailbox not selectable yet dsync(USER2): Debug: Namespace : /srv/mail/v/USER2/mailboxes/Drafts doesn't exist yet, using default permissions dsync(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: Namespace : /srv/mail/v/USER2/mailboxes/INBOX doesn't exist yet, using default permissions dsync(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: Namespace : /srv/mail/v/USER2/mailboxes/Junk doesn't exist yet, using default permissions dsync(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: INBOX: Mailbox opened because: copy caching decisions dsync(USER2): Debug: Namespace : /srv/mail/v/USER2/mailboxes/Sent doesn't exist yet, using default permissions dsync(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: INBOX: Mailbox opened because: copy caching decisions dsync(USER2): Debug: Namespace : /srv/mail/v/USER2/mailboxes/Trash doesn't exist yet, using default permissions dsync(USER2): Debug: Namespace : Using permissions from /srv/mail/v/USER2: mode=0700 gid=default dsync(USER2): Debug: INBOX: Mailbox opened because: copy caching decisions ...
for user in USER2; do echo $user ; for mailbox in ls /srv/mail/v/$user/mailboxes/; do echo $mailbox; doveadm search -u $user
mailbox $mailbox ALL | head -n 1; done ; done
USER2 Drafts INBOX c92f64f79f0d1ed01e6d5b314f04886c 28 Junk Sent bfb2e03fdce327671e82bf173b1ccb8b 1 Trash 7f5af7ba291b2df1a11d573bdb55d7e9 1
which options in dovecot config specifically must be set so that imapc adopts the GUID it gets from the server its migrating from.
thanks Thomas
participants (3)
-
Aki Tuomi
-
Andrea Gabellini
-
Thomas Winterstein