restore replication for shared folders? Run sync for
each folder separately?
On Wed, Mar 2, 2016, 6:01 PM Konstantin Udalov via Info-cyrus <
info-cyrus@lists.andrew.cmu.edu> wrote:
> Hello.
>
> I configured IMAP rolling replication from master to slave as was
> described in https://
Hello.
I configured IMAP rolling replication from master to slave as was
described in https://cyrusimap.org/imap/admin/sop/replication.html And
everything was fine. Until some strange records appear into logs. Here
is one of them.
Mar 2 04:48:55 hostname cyrus/sync_client[725]: MAILBOX
Hi,
I'm going to sync between a Gentoo (master) and a Debian 8 machine
(replica), Gentoo on Cyrus 2.4.17, Debian on "testing" Cyrus 2.4.18
because of broken sync in "stable"
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799724).
I am using virtual domains.
I've tried synctest from the m
Am Montag, den 14.12.2015, 07:31 -0400 schrieb Patrick Boutilier via
Info-cyrus:
> On 12/14/2015 06:25 AM, Marcus Schopen via Info-cyrus wrote:
> > Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via
> > Info-cyrus:
> >> Hi,
> >>
> >> I have a problem with a single mailbox. The user'
Hi,
Am Montag, den 14.12.2015, 12:53 +0100 schrieb Michael Menge via
Info-cyrus:
> Hi,
>
>
> Quoting Patrick Boutilier via Info-cyrus :
>
> > On 12/14/2015 06:25 AM, Marcus Schopen via Info-cyrus wrote:
> >> Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via
> >> Info-cyrus:
> >
Hi,
Quoting Patrick Boutilier via Info-cyrus :
On 12/14/2015 06:25 AM, Marcus Schopen via Info-cyrus wrote:
Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via
Info-cyrus:
Hi,
I have a problem with a single mailbox. The user's Outlook crashed and
since then the sync_client is
On 12/14/2015 06:25 AM, Marcus Schopen via Info-cyrus wrote:
Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via
Info-cyrus:
Hi,
I have a problem with a single mailbox. The user's Outlook crashed and
since then the sync_client is running wild on this user account and
produces hig
Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via
Info-cyrus:
> Hi,
>
> I have a problem with a single mailbox. The user's Outlook crashed and
> since then the sync_client is running wild on this user account and
> produces high load on the master. I stopped sync_client on master
Hi,
forgot the cyrus version: 2.4.12 on Ubuntu 12.04 LTS
Ciao!
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
Hi,
I have a problem with a single mailbox. The user's Outlook crashed and
since then the sync_client is running wild on this user account and
produces high load on the master. I stopped sync_client on master side
for the moment.
When I try to sync the user by hand
/bin/su - cyrus -c "/usr/lib/
I am looking at migrating a Cyrus IMAP 2.4 server to 2.5 (actually Kolab
3.1 to 3.4) and was wondering if it was safe to use the built in
replication between the releases.
Thanks
Mike
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail
Am Donnerstag, den 16.10.2014, 14:57 +0200 schrieb Rudy Gevaert:
> On Tue, Oct 14, 2014 at 10:28:24PM +0200, Marcus Schopen wrote:
> >
> > Thanks, what a great idea.
> >
> > Is it this script?
> >
> > https://github.com/rgevaert/cyrus-ugent/blob/master/src/cyrus-synccheck
> >
>
> Hi, yes it is
="csync"
This is strange - anyone with a Debian 8, too ?
Have you got csync defined in /etc/services?
csync 2005/tcp # Cyrus IMAP replication
But perhaps the more salient question would be; if the IMAP server is
listening on 2005, have you got imap misdefined i
Hi,
[...]
> Looks to me that you are running imap server on port 2005, not the sync
> server. Try telneting to port 2005 on the replica.
>
> You should see something like:
>
> Connected to replica.
> Escape character is '^]'.
> * SASL PLAIN
> * STARTTLS
> * COMPRESS DEFLATE
> * OK replica Cyrus syn
On 05/15/2015 07:06 PM, pl...@bibliothek.uni-kassel.de wrote:
Hi,
I have a strange problem setting up replication from one Linux to another.
Both machines run cyrus 2.4.17, master is Gentoo (32 bit), replica is
Debian 8 (64 bit).
I am running a similar pair with Gentoo / Debian 7 w/o any
Hi,
I have a strange problem setting up replication from one Linux to another.
Both machines run cyrus 2.4.17, master is Gentoo (32 bit), replica is
Debian 8 (64 bit).
I am running a similar pair with Gentoo / Debian 7 w/o any problems.
Problems start with synctest:
synctest -a cyrus@replica
On 12/19/2014 01:31 PM, Patrick Goetz wrote:
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
My current plan is to use imapsync for the migration and then
replication to another dummy server for backup, assuming I can figure
out how
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
>> My current plan is to use imapsync for the migration and then
>> replication to another dummy server for backup, assuming I can figure
>> out how to set up replicati
've rsynced the mail files once, rsyncing them again a short
time later should be pretty fast. There does need to be a backup
solution for people who only have one server, hence can't use
replication or imapsync to do backups.
There is, snapshots, or hosted mail services (like Fastmail
ap [removable disk/other server]
Once you've rsynced the mail files once, rsyncing them again a short
time later should be pretty fast. There does need to be a backup
solution for people who only have one server, hence can't use
replication or imapsync to do backups.
>
> Lastl
ing pair):
--- imapd-master.conf2014-11-24 13:37:45.752639666 -0600
+++ imapd-replica.conf 2014-11-24 13:31:58.702611566 -0600
@@ -1,22 +1,14 @@
##
-# These configuration parameters are for the master server
-# in a replication set
-servername: master.example.com
+#
Hi Rudy,
Am Montag, den 13.10.2014, 10:41 +0200 schrieb Rudy Gevaert:
>
>
> On 09/27/14 10:59, Marcus Schopen wrote:
> > Hi,
> >
> > always when I have to reboot the replica or its cyrus the
> > synchronization on master side stops, /var/lib/cyrus/sync/log fills up
> > and I don't see a "/usr/li
On 09/27/14 10:59, Marcus Schopen wrote:
> Hi,
>
> always when I have to reboot the replica or its cyrus the
> synchronization on master side stops, /var/lib/cyrus/sync/log fills up
> and I don't see a "/usr/lib/cyrus/bin/sync_client -r" process anymore.
>
> /var/log/mail.err on master when rest
On 10/10/2014 09:31 AM, Marcus Schopen wrote:
Hi Patrick,
Am Freitag, den 10.10.2014, 09:13 -0300 schrieb Patrick Boutilier:
On 10/10/2014 09:09 AM, Marcus Schopen wrote:
Am Samstag, den 27.09.2014, 10:59 +0200 schrieb Marcus Schopen:
Hi,
always when I have to reboot the replica or its cyrus
Hi Patrick,
Am Freitag, den 10.10.2014, 09:13 -0300 schrieb Patrick Boutilier:
> On 10/10/2014 09:09 AM, Marcus Schopen wrote:
> > Am Samstag, den 27.09.2014, 10:59 +0200 schrieb Marcus Schopen:
> >> Hi,
> >>
> >> always when I have to reboot the replica or its cyrus the
> >> synchronization on ma
On 10/10/2014 09:09 AM, Marcus Schopen wrote:
Am Samstag, den 27.09.2014, 10:59 +0200 schrieb Marcus Schopen:
Hi,
always when I have to reboot the replica or its cyrus the
synchronization on master side stops, /var/lib/cyrus/sync/log fills up
and I don't see a "/usr/lib/cyrus/bin/sync_client -r
Am Samstag, den 27.09.2014, 10:59 +0200 schrieb Marcus Schopen:
> Hi,
>
> always when I have to reboot the replica or its cyrus the
> synchronization on master side stops, /var/lib/cyrus/sync/log fills up
> and I don't see a "/usr/lib/cyrus/bin/sync_client -r" process anymore.
>
> /var/log/mail.e
Hi,
always when I have to reboot the replica or its cyrus the
synchronization on master side stops, /var/lib/cyrus/sync/log fills up
and I don't see a "/usr/lib/cyrus/bin/sync_client -r" process anymore.
/var/log/mail.err on master when restarting replica:
Sep 27 10:06:28 master cyrus/sync_clien
On Tue, Aug 26, 2014, at 08:56 PM, Marcus Schopen wrote:
> Hi,
>
> on my replication I see about a thousand dirs, many of them a few month
> old. The total size of /var/spool/cyrus/mail/sync. is about 240 MB. Most
> of the dirs are empty, about 240 dirs containing files
>
Hi,
on my replication I see about a thousand dirs, many of them a few month
old. The total size of /var/spool/cyrus/mail/sync. is about 240 MB. Most
of the dirs are empty, about 240 dirs containing files
For today for example I do see some dirs which are all empty:
drwx-- 1354 cyrus mail
edas wrote:
> Hi all,
>
> Is there a way to quickly verify that replication is working (for e.g.
> nagios monitoring)? It seems that file differences in e.g. cyrus.index
> happen even when replication succeeds, and parsing the whole mail log
> for error messages seems a bit overki
Hi all,
Is there a way to quickly verify that replication is working (for e.g.
nagios monitoring)? It seems that file differences in e.g. cyrus.index
happen even when replication succeeds, and parsing the whole mail log
for error messages seems a bit overkill.
--
Mit freundlichen Grüßen, / Best
On Mon, 2014-04-21 at 22:34 +0600, Eugene M. Zheganin wrote:
> If I'm using replication, and master goes offline for a moment, and I
> have some mail delivered on replica (from SMTP, beacuse I kinda have
> SMTP configured to deliver on localhost, and IMAP master is also a CARP
>
Hi.
If I'm using replication, and master goes offline for a moment, and I
have some mail delivered on replica (from SMTP, beacuse I kinda have
SMTP configured to deliver on localhost, and IMAP master is also a CARP
master), how do I handle this situtation when master is back online (and
I am looking at using Cyrus IMAP replication as part of setting up a DR
server at another site but am seeing poor performance during the initial
sync.
The servers are on different sites connected by a microwave link. I can
rsync between the two servers at slightly better than 30Mb/s, but am
connected
to the reception of incoming mails. However, I have no clue how the
entries are
related to the replication process. Maybe someone can shed light on this.
Every process of cyrus will write a line to the log indicating where
something changed, but not the change itself. Sync_client and
eceive any screen messages, that the replication was
> >stopped. I wonder what will happen in a production environment, when the
> >server reboots without my notice. Replication will fail and I will not be
> >able to guarantee full recovery. To my opinion this is unacceptable.
>
Hi
Quoting Willy Offermans :
Dear cyrus friends,
Once more my backend server was rebooted. I did not find any messages in my
logs nor did I receive any screen messages, that the replication was
stopped. I wonder what will happen in a production environment, when the
server reboots without my
Dear cyrus friends,
Once more my backend server was rebooted. I did not find any messages in my
logs nor did I receive any screen messages, that the replication was
stopped. I wonder what will happen in a production environment, when the
server reboots without my notice. Replication will fail and
my own question. I was indeed missing the authentication
> >> mechanism. I added to imapd.conf on the
> >> back-end server and the replication worked.
> >>
> >> So I wonder how I can tell sync_client which authentication mechanism to
> >> use? It seems
On Fri, 21 Feb 2014, Marcus Schopen wrote:
> Hi,
>
> Am Freitag, den 21.02.2014, 17:23 +0100 schrieb Willy Offermans:
> [...]
>>
>>
>> I can answer my own question. I was indeed missing the authentication
>> mechanism. I added to imapd.conf on the
>>
Hi,
Am Freitag, den 21.02.2014, 17:23 +0100 schrieb Willy Offermans:
[...]
>
>
> I can answer my own question. I was indeed missing the authentication
> mechanism. I added to imapd.conf on the
> back-end server and the replication worked.
>
> So I wonder how I can t
Dear cyrus friends,
On Fri, Feb 21, 2014 at 03:48:20PM +0100, Willy Offermans wrote:
> Dear cyrus friends,
>
> I like to use the replication feature of cyrus.
>
> On the backend I changed the cyrus.conf file. I added:
>
> to the SERVICES.
>
> On the client side I
Dear cyrus friends,
I like to use the replication feature of cyrus.
On the backend I changed the cyrus.conf file. I added:
to the SERVICES.
On the client side I changed the imapd.conf file and cyrus.conf file in the
following way.
cyrus.conf:
I added
to the START section.
imapd.conf:
I added
On Thu, Feb 20, 2014, at 10:03 AM, Marcus Schopen wrote:
> Hi,
>
> just a understanding question: for some testing I connected via imap to
> the slave an deleted some messages there. After that I started a
>
> /usr/lib/cyrus/bin/sync_client -u mailboxname
>
> on the master to sync master and s
Hi,
just a understanding question: for some testing I connected via imap to
the slave an deleted some messages there. After that I started a
/usr/lib/cyrus/bin/sync_client -u mailboxname
on the master to sync master and slave. This is the log on the master:
-
Feb 19 23:51:19 maste
On Thu, Feb 20, 2014, at 03:01 AM, Marcus Schopen wrote:
> I'm running a single standalone master and a replica slave. What is best
> failover practice for this setup? How do I make a replication slave to
> master if the standalone master is down? Just remove syncserver from
> S
Hi,
some questions about master and replication:
I'm running a single standalone master and a replica slave. What is best
failover practice for this setup? How do I make a replication slave to
master if the standalone master is down? Just remove syncserver from
SERVICE section on slav
Hi, i've configured an imap aggregator structure and all goes well.
I've 1 frontend, 1 mupdate master and 2 backends imap servers.
Every backends have a different users mailbox.
Every users can consult and receive mail by connect to frontend server.
I've a question about future request.
Is it
Hi all,
Could someone please tell how to enforce encryption for replication?
We authenticate users through
allowplaintext: 1
sasl_mech_list: plain
sasl_pwcheck_method: saslauthd
Certificates are installed and SSL/TLS work fine but some of our users
require that "allowplaintext: yes"
Hi,
I have encountered a problem with the replication on cyrus 2.4.16. On
one day the master had problems to replicate the changes of one mailbox
to the replica server via sync_client with the following log entries:
Master log:
ep 27 13:12:50 trisol cyrus/sync_client[19699]: MAILBOX received NO
On Mon, Sep 17, 2012, at 04:05 PM, Patrick Boutilier wrote:
> Cyrus 2.4.16
>
> Is there a way to force the sync-client to do a complete sync to the
> replica instead of just the new messages? My situation is that I lost
> half of my data on the replication server due to a RAID
Cyrus 2.4.16
Is there a way to force the sync-client to do a complete sync to the
replica instead of just the new messages? My situation is that I lost
half of my data on the replication server due to a RAID failure but not
the metadata. So cyrus on the replica thinks that the data is still
Um, sorry, folks, I hit "send" before I had a look at the "To" header. This
should have gone to our local list only.
--Janne / Univ. of Helsinki
On Thu, Aug 30, 2012 at 04:34:13PM +0300, Janne Peltonen wrote:
> Tämä siis tiedoksi teillekin. Toki INBOX renamesta seuraavat jumitukset saa
> jatkoss
Tämä siis tiedoksi teillekin. Toki INBOX renamesta seuraavat jumitukset saa
jatkossakin korjatuksi, seuraavaan USER-operaatioon asti... :(
--Janne
On Thu, Aug 30, 2012 at 04:33:18PM +0300, Janne Peltonen wrote:
> On Wed, Jan 18, 2012 at 01:25:08PM +0200, Janne Peltonen wrote:
> > On Wed, Jan 18,
On Wed, Jan 18, 2012 at 01:25:08PM +0200, Janne Peltonen wrote:
> On Wed, Jan 18, 2012 at 12:19:57PM +0200, Janne Peltonen wrote:
> > What to do, how to circumvent this problem in the current version? I'd
> > really
> > like to be able to be able to start replicating a user's mailbox and
> > meta
Hello.
I have two nodes - first is master and second is replica.
cyrus-imapd version on master is 2.4.13 and on replica 2.4.14.
I have configured rolling replication from first master node to replica.
When I try to synchronize all user mailboxes in parallel to running
rolling replication - it
On Thu, 2012-03-22 at 11:19 +0100, Egoitz Aurrekoetxea wrote
> I have a mailbox machine with near 6000 users. This machine is having
> some delay on the replication. I'm debugging the replication and have
> seen twice some problems with two users in they're seen database which
&
Hi,
I have a mailbox machine with near 6000 users. This machine is having some
delay on the replication. I'm debugging the replication and have seen twice
some problems with two users in they're seen database which I solved
basically removing the seen databases of this two users and
I'm on holiday with just my phone! Can you file a bug please.
Thanks,
B
On Thu, Feb 23, 2012, at 10:07 AM, Patrick Boutilier wrote:
> Cyrus 2.4.12
>
>
> I have noticed that when a user is deleted on the primary and their
> InBox was empty because they never received a single e-mail the DELETE
Cyrus 2.4.12
I have noticed that when a user is deleted on the primary and their
InBox was empty because they never received a single e-mail the DELETED
mailbox does not appear on the slave. I have not verified if this
happennes when the InBox is empty but they did receive a mail at one
poin
On Wed, Feb 01, 2012 at 05:59:09PM +0100, Matteo Cazzador wrote:
> Hello' i've a question about cyrus replication system,
> i need to syncronize "real time" 3 imap servers (mailbox and
> relative mail flags etc etc) in different geographic locations.
> Every ser
Hello' i've a question about cyrus replication system,
i need to syncronize "real time" 3 imap servers (mailbox and
relative mail flags etc etc) in different geographic locations.
Every server have the same users.
Is it possible using replication system to do it?
Is it po
n. But even in this second case, where the folder did get created
again, the ghost of the first DELETED folder (stamped 4F17C45B) was in the
mailbox list of the murder backend, causing trouble for replication.
What appears to be doing these deletions, looking at the syslog entries, is
imapd. And a comp
On Thu, Jan 19, 2012, at 11:09 AM, Janne Peltonen wrote:
> Hi!
>
> Today, I ran into a totally new kind of trouble with replication. Apparently,
> in some situation, when a user has some folders in the DELETED hieararchy, and
> the folders get actually removed from the disk, and
date operation failed
i16.mappi.helsinki.fi> lm "DELETED.user..BIOMEDICUM.Matkat
2012.06-20.Untitled Folder.4F17D602"
DELETED.user..BIOMEDICUM.Matkat 2012.06-20.Untitled Folder.4F17D602
(\HasNoChildren)
i16.mappi.helsinki.fi>
--clip--
The replication problem did go away, though:
--cl
tally new kind of trouble with replication. Apparently,
> in some situation, when a user has some folders in the DELETED hieararchy, and
> the folders get actually removed from the disk, and there is a USER operation
> for that user, the replication code tries to replicate the no-longer-existent
Hi!
Today, I ran into a totally new kind of trouble with replication. Apparently,
in some situation, when a user has some folders in the DELETED hieararchy, and
the folders get actually removed from the disk, and there is a USER operation
for that user, the replication code tries to replicate the
On Wed, Jan 18, 2012, at 10:52 AM, David Carter wrote:
> On Wed, 18 Jan 2012, Janne Peltonen wrote:
>
> > I recently upgraded Cyrus from version 2.3.16 to 2.4.12 (using the
> > wonderful RPMs from INVOCA). Now, I ran into a bit of a problem with
> > replication. F
On Wed, Jan 18, 2012 at 12:19:57PM +0200, Janne Peltonen wrote:
> What to do, how to circumvent this problem in the current version? I'd really
> like to be able to be able to start replicating a user's mailbox and metadata
> again, even if they have renamed their INBOX sometime in the past.
Well,
On Wed, 18 Jan 2012, Janne Peltonen wrote:
> I recently upgraded Cyrus from version 2.3.16 to 2.4.12 (using the
> wonderful RPMs from INVOCA). Now, I ran into a bit of a problem with
> replication. From time to time, a user thinks it a great idea to rename
> their INBOX in order
Hi!
I recently upgraded Cyrus from version 2.3.16 to 2.4.12 (using the wonderful
RPMs from INVOCA). Now, I ran into a bit of a problem with replication. From
time to time, a user thinks it a great idea to rename their INBOX in order to
save time in archiving old messages. Now, this screws up the
Thank you all,
I wiil do analysis to verify the problem about storage.
By Obe.
On 24/11/2011 14:17, Andy Bennett wrote:
> Hi,
>
>>> What IO subsystem do you have on this machine? What filesystem are you
>>> using?
>> I have 4 HDD 500GB S SATA II
>> with LSI 8704 ELP SAS
>> RAID 6
>> filesystem e
Hi,
>> What IO subsystem do you have on this machine? What filesystem are you
>> using?
>
> I have 4 HDD 500GB S SATA II
> with LSI 8704 ELP SAS
> RAID 6
> filesystem ext3 mounted with noatime, nodiratime
> this my vmstat after I run the command find -type f | xargs cat >
> /dev/null :
>
On Thu, November 24, 2011 11:52 am, Oberdan Albertoni wrote:
> I have 4 HDD 500GB S SATA II
> with LSI 8704 ELP SAS RAID 6
> filesystem ext3 mounted with noatime, nodiratime
RAID 6 over four disks.
FYI, RAID 6 carries the highest 'write penalty' of all RAID levels.
http://www.techrepublic.com
On 24/11/2011 02:07, Andy Bennett wrote:
> Hi,
>
>>>> I enabled replication between two servers with version 2.4.10 cyrus.
>>>> I set the option for the rolling replication, and it works fine but
>>>> obviously I have a high CPU load.
>>>> Unf
Hi,
>>> I enabled replication between two servers with version 2.4.10 cyrus.
>>> I set the option for the rolling replication, and it works fine but
>>> obviously I have a high CPU load.
>>> Unfortunately after 10 minutes of running processes pop3d increasing
On 22/11/2011 15:52, Andy Bennett wrote:
> Hi,
>
>> I enabled replication between two servers with version 2.4.10 cyrus.
>> I set the option for the rolling replication, and it works fine but
>> obviously I have a high CPU load.
>> Unfortunately after 10 minu
Hi,
> I enabled replication between two servers with version 2.4.10 cyrus.
> I set the option for the rolling replication, and it works fine but
> obviously I have a high CPU load.
> Unfortunately after 10 minutes of running processes pop3d increasing
> from 50 to over 200, ma
Hi,
I enabled replication between two servers with version 2.4.10 cyrus.
I set the option for the rolling replication, and it works fine but
obviously I have a high CPU load.
Unfortunately after 10 minutes of running processes pop3d increasing
from 50 to over 200, making the server unusable for
Hi,
On 19 October 2011 17:38, Bron Gondwana wrote:
> On Wed, Oct 19, 2011 at 04:58:35PM +0100, Guy wrote:
>> I've just started playing around with Cyrus replication and I've got a
>> set up with chained replication working nicely. I haven't tested
>> delay
On Wed, Oct 19, 2011 at 04:58:35PM +0100, Guy wrote:
> I've just started playing around with Cyrus replication and I've got a
> set up with chained replication working nicely. I haven't tested
> delayed expunges yet, but delayed deletes don't appear to work on the
Hi,
I've just started playing around with Cyrus replication and I've got a
set up with chained replication working nicely. I haven't tested
delayed expunges yet, but delayed deletes don't appear to work on the
replicas. The master server does a delayed delete and I can see th
Quoting Shashi Yash :
I'm trying to understand how replication works in cyrus. What kind of
data is written to the replication log file etc. According to the
documentation the sync log file is located in
(configdirectory)/sync/log. But I'm unable to find this file.
If you ha
I'm trying to understand how replication works in cyrus. What kind of
data is written to the replication log file etc. According to the
documentation the sync log file is located in
(configdirectory)/sync/log. But I'm unable to find this file.
I only see a lock file in (configdirec
ght :)
>
> This is a basic two-host setup, host A is Master, host B is Replica.
>
> When replication is attempted in automatic mode it fails.
> Incidentally, it fails in manual mode too.
>
> --- Replica
> Jul 20 15:29:24 clone-machine-target syncserve
basic two-host setup, host A is Master, host B is Replica.
When replication is attempted in automatic mode it fails.
Incidentally, it fails in manual mode too.
--- Replica
Jul 20 15:29:24 clone-machine-target syncserver[3630]: accepted connection
Jul 20 15:29:24 clone-machine-t
Agh, the problem solved, finally!
What caused this really weird behavior was something that is I'm not
even sure of, but what I did to fix it was basically took and
duplicated the master host, reconfigured it to be a replica and after
that I could sync and swap the roles as many times as I liked.
Below is strace output for cyrus-master during manual sync_client invocation:
/usr/lib/cyrus-imapd/sync_client -v -r
[root@imapsite-master scripts]# netstat -ntuap |grep cyru
tcp0 0 0.0.0.0:143 0.0.0.0:*
LISTEN 29795/cyrus-master
tcp0 0 0.0.0.0
Disregard the previous message with imtest output. I completely forgot
that imaps wasn't running. It works fine, actually.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
One more bit of information as a follow-up:
[root@imapsite-master scripts]# imtest -s -a zxy -m login -p imap -v localhost
starting TLS engine
setting up TLS connection
SSL_connect:before/connect initialization
write to 587EA850 [587F90B0] (89 bytes => 89 (0x59))
16 03 01 00 54 01 00
On Mon, Jul 11, 2011 at 3:47 PM, Bron Gondwana wrote:
>> Jul 11 11:21:14 imapsite-master syncserver[14019]: SSL_accept() timed
>> out -> fail
>> Jul 11 11:21:14 imapsite-master syncserver[14019]: STARTTLS failed:
>> imapsite-replica [10.10.0.188]
>
> Sounds like broken authentication.
>
>> ===
As a quick reply I've attached the configs that I use for both hosts
and strace output for synctest run on B switched to master. Hopefully
this will either demonstrate that the configuration is pretty much
okay, or perhaps give you an idea of where I got the replication setup
wrong.
Mean
ent).
The only difference between our master and replica configs these days
is that sync_client only gets started on the master. Actually, we
don't start it from cyrus.conf any more, we bring up the master first,
and then run sync_client from the init script after the master is
fully running.
>
9 imapsite-master syncserver[18209]: cmdloop(): startup
> Jul 11 12:51:39 imapsite-master syncserver[18209]: accepted connection
> Jul 11 12:51:39 imapsite-master syncserver[18209]: cmdloop(): startup
> Jul 11 12:52:39 imapsite-master syncserver[18209]: accepted connection
> Jul 11 12:52:39 imaps
12:52:39 imapsite-master syncserver[18209]: accepted connection
Jul 11 12:52:39 imapsite-master syncserver[18209]: cmdloop(): startup
Replication doesn't succeed, obviously.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
eepalives, the sync_client can
> be stuck waiting "forever" for the replica.
Didn't have tcp_keepalive: 1. Will note if changes anything.
> The second is that sync log files can be left around and never actually
> processed. It's this second one that is more of a
nc log files can be left around and never actually
processed. It's this second one that is more of a problem. We have a
program called "monitorsync" at FastMail that watches replication. Other
big sites do similar tricks.
I would love to replace monitorsync with better logic
#x27;m going to describe that
boggles my mind and I can't seem to find a clear-cut answer whether what
I'm up to is even supposed to work.
Using cyrus-imapd 2.4.10, built from jmeeuwen's SRPM aka kolabsys SRPM.
Here's the basic replication scenario I've implemented.
I ha
On Fri, Jun 03, 2011 at 03:01:14PM -0500, Blake Hudson wrote:
> Bron, I appreciate the info. I can certainly use this as a base. Though
> I must admit that without a working example, I'm not able to quickly
> modify the code and get it to run.
>
> Have you thought about making a generic version an
101 - 200 of 730 matches
Mail list logo
