[NOISSUE] Newbie question about replication

2020-10-27 Thread Piotr Auksztulewicz
On Mon, Oct 19, 2020 at 12:08:05AM +0200, Piotr Auksztulewicz wrote:
> On Sun, Oct 18, 2020 at 11:14:26PM +0200, John Fawcett wrote:
> > can you check if the missing emails are in the new directory on host B?
> 
> I cannot now. I did not think about that possibility when listing the
> contents of directories and have not checked the new directory.
> 
> > My guess is that the missing emails appeared on host A in new and were
> > replicated to host B in new. Then the imap client connected to host A
> > moved them from new to cur on host A and that such movement is not
> > subject to replica. So long as the emails have been replicated to either
> > new or cur on host B, then it should not be an issue about losing emails
> > if host A goes down, since connecting an imap client to host B will move
> > the emails to cur (that is no replication involved).

I have observed my servers for a few days and this is exactly what happens
- some mails are still in new/ on host B. The whole issue is nonexsitent.

Thanks for the hint.

-- 
Piotr "Malgond" Auksztulewicz firstn...@lastname.net


Re: Newbie question about replication

2020-10-18 Thread Piotr Auksztulewicz
On Sun, Oct 18, 2020 at 11:14:26PM +0200, John Fawcett wrote:
> can you check if the missing emails are in the new directory on host B?

I cannot now. I did not think about that possibility when listing the
contents of directories and have not checked the new directory.

> My guess is that the missing emails appeared on host A in new and were
> replicated to host B in new. Then the imap client connected to host A
> moved them from new to cur on host A and that such movement is not
> subject to replica. So long as the emails have been replicated to either
> new or cur on host B, then it should not be an issue about losing emails
> if host A goes down, since connecting an imap client to host B will move
> the emails to cur (that is no replication involved).

Now that I had connected a client to host B once, they must have got
moved to cur.

The next time I see this, I will check new directory as well. Maybe the
whole issue is just misunderstanding.


-- 
Piotr "Malgond" Auksztulewicz firstn...@lastname.net


Re: Newbie question about replication

2020-10-18 Thread John Fawcett
On 18/10/2020 22:53, Piotr Auksztulewicz wrote:
> On Sat, Oct 17, 2020 at 11:17:34PM +0200, John Fawcett wrote:
>>> I have observed my mail storage directories on both instances and have
>>> noticed that they diverge a little over time - the instance B not having
>>> all the updates. However the moment I connect another client to instance
>>> B and log in as a particular user, the state on instance B springs to the
>>> correct state and I see the same content on both clients, and the storage
>>> directories become identical as well.
>> Are there any replication errors logged? Does doveadm replicator status or
>> doveadm replicator status  give any sign of errors?
>>
>> Can you give some example or evidence of the disalignment that is happening?
> Thank you for response. I was asking if such difference in directories is
> normal or not and do I have the approach right or is there some obvious error
> in my configuration.
>
> I still have an example that prompted me to write this email. Instance B had
> three mails missing in comparison to instance A, when I listed the storage
> directories from the command line. They got replicated fine just after I
> connected a client to instance B. No difference since then, but I need to
> observe the servers for some more time, it seems like it happens over a few
> weeks or so. No errors in dovecot logs, doveadm replicator status output does
> not show any errors as well, but instances have been restarted, so it is not
> a goof indication. I am going to enable debug to see what's going on. Maybe it
> was some transient situation or human error on my part during setting it all 
> up
> or tweaking the configuration. I will come back if I observe such thing again.
>
> Here are the listings. Hostnames etc. replaced for privacy.
>
> --- Instance A
> root@serverA:/var/vmail/u...@example.net/mail/INBOX/.MailDir/cur# ll
> total 14684
> drwx-- 2 vmail vmail4096 Oct 16 13:15  .
> drwx-- 5 vmail vmail4096 Oct 16 13:15  ..
> -rw--- 1 vmail vmail  303371 Oct 30  2019 
> '1572438988.M167729P10012.hostname.mydomain.net,S=303371,W=307546:2,S'
> -rw--- 1 vmail vmail 1789790 Oct 30  2019 
> '1572438998.M633142P10012.hostname.mydomain.net,S=1789790,W=1814325:2,S'
> -rw--- 1 vmail vmail  171191 Nov 17  2019 
> '1574012316.M188507P14607.hostname.mydomain.net,S=171191,W=173557:2,S'
> -rw--- 1 vmail vmail 3430888 Nov 29  2019 
> '1574956300.M308957P25339.hostname.mydomain.net,S=3430888,W=3475534:2,S'
> -rw--- 1 vmail vmail7185 Mar 14  2020 
> '1584150674.M740366P21925.hostname.mydomain.net,S=7185,W=7294:2,S'
> -rw--- 1 vmail vmail5543 Mar 25  2020 
> '1585148832.M609262P877.hostname.mydomain.net,S=5543,W=5674:2,S'
> -rw--- 1 vmail vmail3052 Apr 19 22:23 
> '1587327803.M423484P19471.hostname.mydomain.net,S=3052,W=3122:2,S'
> -rw--- 1 vmail vmail   13690 Apr 23 14:47 
> '1587646046.M939301P22621.hostname.mydomain.net,S=13690,W=13886:2,S'
> -rw--- 1 vmail vmail 8917623 May 25 19:06 
> '1590426395.M585516P47979.hostname.mydomain.net,S=8917623,W=9033467:2,S'
> -rw--- 1 vmail vmail5473 Jun 20 20:14 
> '1592676840.M810974P68188.hostname.mydomain.net,S=5473,W=5576:2,S'
> -rw--- 1 vmail vmail8776 Jun 21 19:25 
> '1592760350.M765525P68795.hostname.mydomain.net,S=8776,W=8936:2,S'
> -rw--- 1 vmail vmail4624 Jul 23 17:25 
> '1595517903.M310464P9504.hostname.mydomain.net,S=4624,W=4715:2,S'
> -rw--- 1 vmail vmail4378 Aug 18 00:16 
> '1597702561.M109036P34930.hostname.mydomain.net,S=4378,W=4453:2,S'
> -rw--- 1 vmail vmail   14522 Sep 17 11:52 
> '1600336372.M982371P3862.hostname.mydomain.net,S=14522,W=14813:2,S'
> -rw--- 1 vmail vmail   30411 Sep 23 14:43 
> '1600865025.M865916P104.hostname.mydomain.net,S=30411,W=30850:2,S'
> -rw--- 1 vmail vmail   39928 Sep 30 08:27 
> '1601447231.M21429P464.hostname.mydomain.net,S=39928,W=40487:2,S'
> -rw--- 1 vmail vmail8529 Oct  9 15:32 
> '1602250379.M823144P212.hostname.mydomain.net,S=8529,W=8701:2,S'
> -rw--- 1 vmail vmail   17972 Oct 15 00:59 
> '1602716371.M291521P5700.hostname.mydomain.net,S=17972,W=18407:2,S'
> -rw--- 1 vmail vmail   38528 Oct 15 08:24 
> '1602743049.M23930P5928.hostname.mydomain.net,S=38528,W=39224:2,S'
> -rw--- 1 vmail vmail   52350 Oct 15 12:05 
> '1602756328.M324186P6101.hostname.mydomain.net,S=52350,W=53436:2,S'
> -rw--- 1 vmail vmail  112458 Oct 16 13:05 
> '1602846323.M415371P7147.hostname.mydomain.net,S=112458,W=114768:2,S'
>
>
> --- Instance B
> root@serverB:/var/vmail/u...@example.net/mail/INBOX/.MailDir/cur# ll
> total 14608
> drwx-- 2 vmail vmail   12288 Oct 16 13:15  .
> drwx-- 5 vmail vmail4096 Oct 16 13:15  ..
> -rw--- 1 vmail vmail  303371 Oct 30  2019 
> '1572438988.M167729P10012.hostname.mydomain.net,S=303371,W=307546:2,S'
> -rw--- 1 vmail vmail 1789790 Oct 30  2019 
> '1572438998.M633142P10012.hostname.mydomain.net,S=1789790,W=1814325:2,S'
> -rw--- 1 vmail vmail  171191 Nov 1

Re: Newbie question about replication

2020-10-18 Thread Piotr Auksztulewicz
On Sat, Oct 17, 2020 at 11:17:34PM +0200, John Fawcett wrote:
> > I have observed my mail storage directories on both instances and have
> > noticed that they diverge a little over time - the instance B not having
> > all the updates. However the moment I connect another client to instance
> > B and log in as a particular user, the state on instance B springs to the
> > correct state and I see the same content on both clients, and the storage
> > directories become identical as well.
>
> Are there any replication errors logged? Does doveadm replicator status or
> doveadm replicator status  give any sign of errors?
>
> Can you give some example or evidence of the disalignment that is happening?

Thank you for response. I was asking if such difference in directories is
normal or not and do I have the approach right or is there some obvious error
in my configuration.

I still have an example that prompted me to write this email. Instance B had
three mails missing in comparison to instance A, when I listed the storage
directories from the command line. They got replicated fine just after I
connected a client to instance B. No difference since then, but I need to
observe the servers for some more time, it seems like it happens over a few
weeks or so. No errors in dovecot logs, doveadm replicator status output does
not show any errors as well, but instances have been restarted, so it is not
a goof indication. I am going to enable debug to see what's going on. Maybe it
was some transient situation or human error on my part during setting it all up
or tweaking the configuration. I will come back if I observe such thing again.

Here are the listings. Hostnames etc. replaced for privacy.

--- Instance A
root@serverA:/var/vmail/u...@example.net/mail/INBOX/.MailDir/cur# ll
total 14684
drwx-- 2 vmail vmail4096 Oct 16 13:15  .
drwx-- 5 vmail vmail4096 Oct 16 13:15  ..
-rw--- 1 vmail vmail  303371 Oct 30  2019 
'1572438988.M167729P10012.hostname.mydomain.net,S=303371,W=307546:2,S'
-rw--- 1 vmail vmail 1789790 Oct 30  2019 
'1572438998.M633142P10012.hostname.mydomain.net,S=1789790,W=1814325:2,S'
-rw--- 1 vmail vmail  171191 Nov 17  2019 
'1574012316.M188507P14607.hostname.mydomain.net,S=171191,W=173557:2,S'
-rw--- 1 vmail vmail 3430888 Nov 29  2019 
'1574956300.M308957P25339.hostname.mydomain.net,S=3430888,W=3475534:2,S'
-rw--- 1 vmail vmail7185 Mar 14  2020 
'1584150674.M740366P21925.hostname.mydomain.net,S=7185,W=7294:2,S'
-rw--- 1 vmail vmail5543 Mar 25  2020 
'1585148832.M609262P877.hostname.mydomain.net,S=5543,W=5674:2,S'
-rw--- 1 vmail vmail3052 Apr 19 22:23 
'1587327803.M423484P19471.hostname.mydomain.net,S=3052,W=3122:2,S'
-rw--- 1 vmail vmail   13690 Apr 23 14:47 
'1587646046.M939301P22621.hostname.mydomain.net,S=13690,W=13886:2,S'
-rw--- 1 vmail vmail 8917623 May 25 19:06 
'1590426395.M585516P47979.hostname.mydomain.net,S=8917623,W=9033467:2,S'
-rw--- 1 vmail vmail5473 Jun 20 20:14 
'1592676840.M810974P68188.hostname.mydomain.net,S=5473,W=5576:2,S'
-rw--- 1 vmail vmail8776 Jun 21 19:25 
'1592760350.M765525P68795.hostname.mydomain.net,S=8776,W=8936:2,S'
-rw--- 1 vmail vmail4624 Jul 23 17:25 
'1595517903.M310464P9504.hostname.mydomain.net,S=4624,W=4715:2,S'
-rw--- 1 vmail vmail4378 Aug 18 00:16 
'1597702561.M109036P34930.hostname.mydomain.net,S=4378,W=4453:2,S'
-rw--- 1 vmail vmail   14522 Sep 17 11:52 
'1600336372.M982371P3862.hostname.mydomain.net,S=14522,W=14813:2,S'
-rw--- 1 vmail vmail   30411 Sep 23 14:43 
'1600865025.M865916P104.hostname.mydomain.net,S=30411,W=30850:2,S'
-rw--- 1 vmail vmail   39928 Sep 30 08:27 
'1601447231.M21429P464.hostname.mydomain.net,S=39928,W=40487:2,S'
-rw--- 1 vmail vmail8529 Oct  9 15:32 
'1602250379.M823144P212.hostname.mydomain.net,S=8529,W=8701:2,S'
-rw--- 1 vmail vmail   17972 Oct 15 00:59 
'1602716371.M291521P5700.hostname.mydomain.net,S=17972,W=18407:2,S'
-rw--- 1 vmail vmail   38528 Oct 15 08:24 
'1602743049.M23930P5928.hostname.mydomain.net,S=38528,W=39224:2,S'
-rw--- 1 vmail vmail   52350 Oct 15 12:05 
'1602756328.M324186P6101.hostname.mydomain.net,S=52350,W=53436:2,S'
-rw--- 1 vmail vmail  112458 Oct 16 13:05 
'1602846323.M415371P7147.hostname.mydomain.net,S=112458,W=114768:2,S'


--- Instance B
root@serverB:/var/vmail/u...@example.net/mail/INBOX/.MailDir/cur# ll
total 14608
drwx-- 2 vmail vmail   12288 Oct 16 13:15  .
drwx-- 5 vmail vmail4096 Oct 16 13:15  ..
-rw--- 1 vmail vmail  303371 Oct 30  2019 
'1572438988.M167729P10012.hostname.mydomain.net,S=303371,W=307546:2,S'
-rw--- 1 vmail vmail 1789790 Oct 30  2019 
'1572438998.M633142P10012.hostname.mydomain.net,S=1789790,W=1814325:2,S'
-rw--- 1 vmail vmail  171191 Nov 17  2019 
'1574012316.M188507P14607.hostname.mydomain.net,S=171191,W=173557:2,S'
-rw--- 1 vmail vmail 3430888 Nov 29  2019 
'1574956300.M308957P25339.hostname.mydomain.net,S=3430888,W=3475534:2,S'
-

Re: Newbie question about replication

2020-10-17 Thread John Fawcett
On 16/10/2020 14:23, Piotr Auksztulewicz wrote:
> Hi,
>
> I am a long-time dovecot user/admin for my family mail server, but
> I had ventured into configuring replication only recently and I am not
> sure about how it should work and what are the good practices. My intent
> for replication was to have another instance to switch to in a short
> time if something fails. I have daily backups, but it will take much
> more time to rebuild and restore than just to switch to a good instance
> while taking time to restore the bad one.
>
> The setup seems to work just fine from IMAP client point of view (minus
> sieve scripts - but I have worked it around as I am not yet ready to
> upgrade dovecot beyond what's in stable Debian at the moment). I have my
> clients configured to access instance A exclusively; instance B is just
> sitting around with no clients routinely connected. Also only instance A
> is receiving deliveries from both my primary and secondary MTAs. I have
> some doubt however if this is the right thing to do and if it is correct
> from the dovecot server point of view.
>
> I have observed my mail storage directories on both instances and have
> noticed that they diverge a little over time - the instance B not having
> all the updates. However the moment I connect another client to instance
> B and log in as a particular user, the state on instance B springs to the
> correct state and I see the same content on both clients, and the storage
> directories become identical as well.

Are there any replication errors logged? Does

doveadm replicator status

or

doveadm replicator status 

give any sign of errors?

Can you give some example or evidence of the disalignment that is happening?

John


Newbie question about replication

2020-10-16 Thread Piotr Auksztulewicz
Hi,

I am a long-time dovecot user/admin for my family mail server, but
I had ventured into configuring replication only recently and I am not
sure about how it should work and what are the good practices. My intent
for replication was to have another instance to switch to in a short
time if something fails. I have daily backups, but it will take much
more time to rebuild and restore than just to switch to a good instance
while taking time to restore the bad one.

The setup seems to work just fine from IMAP client point of view (minus
sieve scripts - but I have worked it around as I am not yet ready to
upgrade dovecot beyond what's in stable Debian at the moment). I have my
clients configured to access instance A exclusively; instance B is just
sitting around with no clients routinely connected. Also only instance A
is receiving deliveries from both my primary and secondary MTAs. I have
some doubt however if this is the right thing to do and if it is correct
from the dovecot server point of view.

I have observed my mail storage directories on both instances and have
noticed that they diverge a little over time - the instance B not having
all the updates. However the moment I connect another client to instance
B and log in as a particular user, the state on instance B springs to the
correct state and I see the same content on both clients, and the storage
directories become identical as well.

I am afraid that, if instance A fails, I would not have the current state
on instance B. Is there anything I should have done differently?

Here is dovecot -n output of instance A. Instance B config is symmetrical
with imap1/2 hostnames switched.

FYI: actual domain is substituted for privacy. mail.mydomain.net is an
internal subdomain with private IP addresses. Instances of dovecot are
containerized with access to internal virtual bridge on which MTAs and
supporting processes are present as well. The access from outside is
provided by port forwarding/NAT, only for imaps and pop3s ports.
Other ports are only internally accessible for local clients (postfix,
mutt, doveadm command line tool etc.) or debug purposes.

# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-9-cloud-amd64 x86_64  
# Hostname: imap1.mail.mydomain.net
auth_failure_delay = 3 secs
auth_verbose = yes
auth_worker_max_count = 5
deliver_log_format = msgid=%m; from=%f: %$
disable_plaintext_auth = no
doveadm_password = # hidden, use -P to show it
doveadm_port = 4551
first_valid_uid = 100
login_greeting = # 
mail_attribute_dict = file:mail/dovecot-attributes
mail_gid = 122
mail_home = /var/vmail/%u
mail_location = maildir:~/mail:LAYOUT=fs:DIRNAME=.MailDir:UTF-8
mail_plugins = " notify replication"
mail_privileged_group = vmail
mail_uid = 113
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext editheader vnd.dovecot.debug
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = /etc/dovecot/dovecot-sql.conf.ext.local
  driver = sql
}
plugin {
  mail_replica = tcp:imap2.mail.mydomain.net
  sieve = ~/.sieve
  sieve_dir = ~/sieve
  sieve_extensions = +vnd.dovecot.debug +editheader
  sieve_user_log = ~/log/sieve.log
}
pop3_fast_size_lookups = yes
pop3_lock_session = yes
pop3_no_flag_updates = yes
pop3_save_uidl = yes
protocols = " imap lmtp sieve pop3"
replication_max_conns = 5
service aggregator {
  fifo_listener replication-notify-fifo {
group = root
mode = 0660
user = vmail
  }
  unix_listener replication-notify {
group = root
mode = 0660
user = vmail
  }
}
service auth-worker {
  chroot = /etc/dovecot/db
  process_limit = 10
  unix_listener auth-worker {
mode = 0600
user = doveauth
  }
  user = doveauth
}
service auth {
  client_limit = 64
  inet_listener sasl {
address = imap1.mail.mydomain.net
port = 9192
  }
  unix_listener auth-userdb {
group = vmail
mode = 0660
user = doveauth
  }
  user = doveauth
}
service dict-async {
  protocol = none
}
service dict {
  protocol = none
}
service director {
  protocol = none
}
service doveadm {
  inet_listener doveadm {
address = imap1.mail.mydomain.net
port = 4551
  }
}
service imap-hibernate {
  protocol = none
}
service imap-login {
  inet_listener imap {
address = imap1.mail.mydomain.net
port = 143
  }
  process_limit = 30
  service_count = 1
}
service imap-urlauth-login {
  protocol = none
}
service imap-urlauth-worker {
  protocol = none
}
service imap-urlauth {
  protocol = none
}
service i

Re: Question about replication

2019-08-02 Thread Sami Ketola via dovecot


> On 2 Aug 2019, at 15.21, Coy Hile  wrote:
> 
>> On Aug 2, 2019, at 7:57 AM, Sami Ketola via dovecot  
>> wrote:
>> 
>> Sounds like you do not want to do replication but migration.
>> 
>> In this case migration can be easily done by using doveadm dsync to pull the 
>> mails from old server to new server. 
>> 
>> Something like: 
>> 
>> doveadm backup -u userid -R -f ssh syncuser@remote "sudo /usr/bin/doveadm 
>> dsync-server -u userid”
>> 
> 
> That may be the easier solution, you’re right. I was hoping to run both in 
> parallel for a bit, but cutting over probably makes the most sense.
> 
> Thanks,


What you can do to make the switchover short as possible is to pre-sync all 
emails offline with first run of doveadm backup, and then the later the same 
command again during switchover just to sync the delta.

Sami



Re: Question about replication

2019-08-02 Thread Coy Hile via dovecot



> On Aug 2, 2019, at 7:57 AM, Sami Ketola via dovecot  
> wrote:
> 
> 
> 
>> On 2 Aug 2019, at 14.52, Coy Hile via dovecot  wrote:
>> 
>> Good morning,
>> 
>> 
>> I’m looking at dovecot replication for the first time for a particular use 
>> case: The VM running dovecot is currently in a public cloud, and  I want to 
>> move it on-premises, so I want to replicate all mail data from the older 
>> instance to the new (then cutover internal DNS) (and in the process update 
>> to newer features on the internal instance such as mdbox vs Maildir).
>> 
>> However, the new instance I’m building is internal, would have access to the 
>> internet only via NAT, so the replication would have to be one way. Is there 
>> anything in particular that I need to keep in mind when I’m trying to setup 
>> this sort of setup? The documentation that I’ve read seems to imply (or 
>> assume) synchronous, bidirectional replication.
>> 
>> Thanks, and apologies if this is an obvious question; this is my first foray 
>> into doing something not utterly trivial with Dovecot.
> 
> Sounds like you do not want to do replication but migration.
> 
> In this case migration can be easily done by using doveadm dsync to pull the 
> mails from old server to new server. 
> 
> Something like: 
> 
> doveadm backup -u userid -R -f ssh syncuser@remote "sudo /usr/bin/doveadm 
> dsync-server -u userid”
> 

That may be the easier solution, you’re right. I was hoping to run both in 
parallel for a bit, but cutting over probably makes the most sense.

Thanks,

-Coy




Re: Question about replication

2019-08-02 Thread Sami Ketola via dovecot



> On 2 Aug 2019, at 14.52, Coy Hile via dovecot  wrote:
> 
> Good morning,
> 
> 
> I’m looking at dovecot replication for the first time for a particular use 
> case: The VM running dovecot is currently in a public cloud, and  I want to 
> move it on-premises, so I want to replicate all mail data from the older 
> instance to the new (then cutover internal DNS) (and in the process update to 
> newer features on the internal instance such as mdbox vs Maildir).
> 
> However, the new instance I’m building is internal, would have access to the 
> internet only via NAT, so the replication would have to be one way. Is there 
> anything in particular that I need to keep in mind when I’m trying to setup 
> this sort of setup? The documentation that I’ve read seems to imply (or 
> assume) synchronous, bidirectional replication.
> 
> Thanks, and apologies if this is an obvious question; this is my first foray 
> into doing something not utterly trivial with Dovecot.

Sounds like you do not want to do replication but migration.

In this case migration can be easily done by using doveadm dsync to pull the 
mails from old server to new server. 

Something like: 

doveadm backup -u userid -R -f ssh syncuser@remote "sudo /usr/bin/doveadm 
dsync-server -u userid"

Sami



Question about replication

2019-08-02 Thread Coy Hile via dovecot
Good morning,


I’m looking at dovecot replication for the first time for a particular use 
case: The VM running dovecot is currently in a public cloud, and  I want to 
move it on-premises, so I want to replicate all mail data from the older 
instance to the new (then cutover internal DNS) (and in the process update to 
newer features on the internal instance such as mdbox vs Maildir).

However, the new instance I’m building is internal, would have access to the 
internet only via NAT, so the replication would have to be one way. Is there 
anything in particular that I need to keep in mind when I’m trying to setup 
this sort of setup? The documentation that I’ve read seems to imply (or assume) 
synchronous, bidirectional replication.

Thanks, and apologies if this is an obvious question; this is my first foray 
into doing something not utterly trivial with Dovecot.