to give the admin full ACL rights for this mailbox but it didn't
help.
Is there any configuration option to change this behaviour?
Best regards,
Olaf Frączyk
--
NAVI Sp. z o.o.
Promienista 5/1
60-288 Poznań
mobile: +48609769035
phone: +48616622881
fax: +48616622882
http://www.navi.pl
Cyru
(not using user's password)?
Or maybe there is some other way to accomplish my goal?
I cannot expect from users to login via telnet and set it by themselves.
Best regards,
Olaf Frączyk
--
NAVI Sp. z o.o.
Promienista 5/1
60-288 Poznań
mobile: +48609769035
phone: +48616622881
fax: +486166
020-04-20 16:11, Olaf Frączyk wrote:
Hi,
I'm running 3.0.5.
I want to migrate to a new machine. I set up cyrus-imapd 3.0.13.
The replication started but it didn't transfer all mails.
The store isn't big 44GB, transferred was about 24 GB.
In the logs I see:
Apr 20 14:54:03 ifs sync_client
it cause problems?
Maybe I should move the sync_client from START section to SERVICES, it
seems that it is not automatically restarted
On 2020-04-21 08:47, Michael Menge wrote:
Hi Olaf
Quoting Olaf Frączyk :
Hi,
I upgraded to 3.0.13 but it didn't help.
This time it copied about 18GB
it happens, there is no activity both on the
replica and on the master for some time.
So maybe the imap server process is not recovering correctly in the
longlock situation?
On 2020-04-21 11:07, Olaf Frączyk wrote:
Hi,
When I run sync_client -r on the master I see the following on the
replica
SHUT_RD) = 0
close(6) = 0
close(5) = 0
munmap(0x7fc6ed5bb000, 16384) = 0
close(3) = 0
munmap(0x7fc6ed5d, 49152) = 0
close(4) = 0
exit
wrote:
Hi,
Quoting Olaf Frączyk :
The current situation is:
1. Replica:
stopped and started the replica
no activity on replica - iotop and top show nothing
the only messages on replica is incoming connection from master
2. Master:
when I run sync_client -r I still get:
Apr 21 12:38:36 ifs
, Olaf Frączyk wrote:
I also found out that when I see on master:
Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response
to MAILBOXES (idle for too long)
Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response
to RESTART (idle for too long)
Apr 21 11:12:38 ifs
On 2020-04-21 16:00, Michael Menge wrote:
Hi,
Quoting Olaf Frączyk :
I managed to get strace on both sides, however it doesn't make me
wiser - there is nothing obvious for me.
Additionally I see that replication works more or less for new
messages, but older are not processed.
I have
Best regrads,
Olaf Frączyk
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Hello,
1. Is currently master-master replication possible (maybe 3.2) Is it OK
to sync them two-way?
If yes - how to set up such config?
2. If master-master is impossible, is there any guide how to setup
failover from master to slave and possibly back? If split-brain happens
- is there an
Hello,
I was wondering why do we need to use this option on middle servers in
replication chain?
I don't use sync_server. The replication is done using IMAP protocol. Is
in this case this setting also necessary?
Shouldn't the middle server catch all changes that are done via IMAP
protocol
On 2020-04-21 20:40, Michael Menge wrote:
Quoting Olaf Frączyk :
Yes, at the beginning I was also thinking if initial sync is
necessary, but there was nothing in docs about it, something started
replicating and I simply assumed it does initial resync. I'll try it
this evening. :)
Since
is
for service processes (i.e. processes that listen on a socket and service
client requests). sync_client is a client, not a service.
Cheers,
ellie
On Wed, Apr 22, 2020, at 4:40 AM, Michael Menge wrote:
Quoting Olaf Frączyk :
Yes, at the beginning I was also thinking if initial sync is
necessary
On 2020-04-22 09:16, Andrzej Kwiatkowski wrote:
W dniu 20.04.2020 o 16:11, Olaf Frączyk pisze:
Hi,
I'm running 3.0.5.
I want to migrate to a new machine. I set up cyrus-imapd 3.0.13.
The replication started but it didn't transfer all mails.
The store isn't big 44GB, transferred was about 24
On 2020-04-29 16:47, Andrzej Kwiatkowski wrote:
Ok.
I was asking because of problem with low entropy on VM-s causing
performance issues with big installations.
I didn't have this issue, however as I said, my installation is really
small. If I needed more entropy I would think of using a
On 2020-04-29 03:39, ellie timoney wrote:
On Wed, Apr 29, 2020, at 1:12 AM, Olaf Frączyk wrote:
I was wondering why do we need to use this option on middle servers in
replication chain?
Hope this helps,
Yes it helped. Thank you. As the replication uses its own protocol even
over IMAP
On 2020-05-01 01:26, ellie timoney wrote:
The rolling sync_client takes care of cleaning up each sync_log file as it
finishes replicating it downstream.
Now consider the case where your replica is an end point, not a link in a
chain: it does not have a rolling sync_client forwarding
Hi,
cyrus-imapd 3.0.13, CentOS 8
replication over IMAP, no sync_server
I try to find out why rolling replication is failing in my case. They
sync_client -A works fine.
I have enabled logging for cyrus_admin in /var/lib/imap/log/cyrus_admin
On the replica side /var/lib/imap/log/cyrus_admin:
19 matches
Mail list logo
