replication does not work
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 I also did some changes to the services file to add csync and portnumbers. If I run ClientComputer# synctest -u username -a username -t '' -m PLAIN MyComputer.example.com S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM S: * STARTTLS S: * COMPRESS DEFLATE S: * OK MyComputer Cyrus sync server v2.4.17 C: STARTTLS S: OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN S: * OK MyComputer Cyrus sync server v2.4.17 Please enter your password: C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj S: OK Success (tls protection) Authenticated. Security strength factor: 256 So everything seems to be fine However if I restart imapd on the client, I do not get any synchronization. I found the following message in the logs of the client: Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to backend server: authentication failure I found the following message in the logs of the backend: Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Or if I directly call for sync_client: MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r MyComputer# Can not connect to server '192.168.X.Y' I guess I'm missing the authentication mechanism for the sync_client, but I'm not sure. Can someone help me out? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl 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
Re: replication does not work
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 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 > > > > > > I also did some changes to the services file to add csync and portnumbers. > > If I run > > ClientComputer# synctest -u username -a username -t '' -m PLAIN > MyComputer.example.com > S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM > S: * STARTTLS > S: * COMPRESS DEFLATE > S: * OK MyComputer Cyrus sync server v2.4.17 > C: STARTTLS > S: OK Begin TLS negotiation now > verify error:num=19:self signed certificate in certificate chain > TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 > bits) > S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN > S: * OK MyComputer Cyrus sync server v2.4.17 > Please enter your password: > C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj > S: OK Success (tls protection) > Authenticated. > Security strength factor: 256 > > So everything seems to be fine > > However if I restart imapd on the client, I do not get any synchronization. > I found the following message in the logs of the client: > Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to > backend server: authentication failure > > > I found the following message in the logs of the backend: > > Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't > read/write key database /etc/opiekeys: Permission denied > Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: > ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not > found: unable to canonify user and get auxprops] > Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't > read/write key database /etc/opiekeys: Permission denied > Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: > ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not > found: unable to canonify user and get auxprops] > Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't > read/write key database /etc/opiekeys: Permission denied > Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: > ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not > found: unable to canonify user and get auxprops] > Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't > read/write key database /etc/opiekeys: Permission denied > Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: > ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not > found: unable to canonify user and get auxprops] > Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't > read/write key database /etc/opiekeys: Permission denied > Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: > ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not > found: unable to canonify user and get auxprops] > > Or if I directly call for sync_client: > > MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r > MyComputer# Can not connect to server '192.168.X.Y' > > > I guess I'm missing the authentication mechanism for the sync_client, but > I'm not sure. Can someone help me out? > > 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 tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl 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
Re: replication does not work
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 tell sync_client which authentication mechanism to > use? It seems like a feature request to me? or a hidden option to the > sync_client executable. That's an interesting question. I had a similar problem this week to force master and slave to sync via TLS. As long as the banner on slave side offered "DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN" to connection plain. I set "allowplaintext: no" and "sasl_mech_list: PLAIN" on slave and now both are talking PLAIN via TLS. So if there is an option on master side to force to login using eg. CRAM-MD5 then there might be an option too to force TLS. > I'm playing with replication now and testing what happens if one deletes > e-mails on the back-end server and not on the client. Will these mails be > restored on the back-end by replication and when? Don't understand, what is the client, the replica server? 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
Re: replication does not work
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 >> back-end server and the replication worked. >> >> So I wonder how I can tell sync_client which authentication mechanism to >> use? It seems like a feature request to me? or a hidden option to the >> sync_client executable. > > That's an interesting question. I had a similar problem this week to > force master and slave to sync via TLS. As long as the banner on slave > side offered "DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN" to connection plain. > I set "allowplaintext: no" and "sasl_mech_list: PLAIN" on slave and now > both are talking PLAIN via TLS. So if there is an option on master side > to force to login using eg. CRAM-MD5 then there might be an option too > to force TLS. > >> I'm playing with replication now and testing what happens if one deletes >> e-mails on the back-end server and not on the client. Will these mails be >> restored on the back-end by replication and when? > > Don't understand, what is the client, the replica server? Have you looked at the sasl_minimum_layer option? sasl_minimum_layer: 0 The minimum SSF that the server will allow a client to negotiate. A value of 1 requires integrity protection; any higher value requires some amount of encryption. Andy 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
Re: replication does not work
Hi Andrew, Am Freitag, den 21.02.2014, 11:21 -0800 schrieb Andrew Morgan: > 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 > >> back-end server and the replication worked. > >> > >> So I wonder how I can tell sync_client which authentication mechanism to > >> use? It seems like a feature request to me? or a hidden option to the > >> sync_client executable. > > > > That's an interesting question. I had a similar problem this week to > > force master and slave to sync via TLS. As long as the banner on slave > > side offered "DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN" to connection plain. > > I set "allowplaintext: no" and "sasl_mech_list: PLAIN" on slave and now > > both are talking PLAIN via TLS. So if there is an option on master side > > to force to login using eg. CRAM-MD5 then there might be an option too > > to force TLS. > > > >> I'm playing with replication now and testing what happens if one deletes > >> e-mails on the back-end server and not on the client. Will these mails be > >> restored on the back-end by replication and when? > > > > Don't understand, what is the client, the replica server? > > Have you looked at the sasl_minimum_layer option? > > sasl_minimum_layer: 0 > The minimum SSF that the server will allow a client to > negotiate. A value of 1 requires integrity protection; any > higher value requires some amount of encryption. > > > Andy Many thanks for your response. Yes, I've tried sasl_minimum_layer with values from 1 up to 100. But even then the master doesn't start a TLS connection to the replica. Hmm Cheers from Germany Marcus 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