Re: Replication: problems with synctest
It looks like my problem with replication not working in one direction was a SASL thing. One of my servers was advertising GSSAPI as an authentication mechanism, but it didn't really work (I don't have Kerberos installed on my systems). Apparently, sync_client on the other box was deciding to use GSSAPI, but was giving up because it wasn't actually functional. I fixed the problem by moving the libgss* libraries out of the SASL2 library directory. While I was at it, I also moved the libntlm* and libotp* libraries out of the SASL2 library directory, since I'm not using either of these authentication methods either. I'm mildly concerned that a future software upgrade might cause these libraries to reappear. Is there a more reliable way to disable SASL authentication mechanisms, other than removing files from the library directory? -- Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED] http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales The difference between theory and practice is that, in theory, theory and practice are identical -- whereas in practice, they aren't. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
Hi Rich, That truly depends on how your Unixlike (Linux) handles the package. If you're using a rpm, you may want to look into using a SRPM the next time and tweek the .spec file so it does not try and pull in ntlm and otp and gssapi. That's one thing I dislike about most package management systems. Instead of letting you decide what you want, they pull in every option it can. :( That, or when you upgrade you can upgrade using a source tarball to upgrade. Then you can disable gssapi, otp and ntlm to ensure they don't come back. Scott Rich Wales wrote: It looks like my problem with replication not working in one direction was a SASL thing. One of my servers was advertising GSSAPI as an authentication mechanism, but it didn't really work (I don't have Kerberos installed on my systems). Apparently, sync_client on the other box was deciding to use GSSAPI, but was giving up because it wasn't actually functional. I fixed the problem by moving the libgss* libraries out of the SASL2 library directory. While I was at it, I also moved the libntlm* and libotp* libraries out of the SASL2 library directory, since I'm not using either of these authentication methods either. I'm mildly concerned that a future software upgrade might cause these libraries to reappear. Is there a more reliable way to disable SASL authentication mechanisms, other than removing files from the library directory? Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
I'm mildly concerned that a future software upgrade might cause these libraries to reappear. Is there a more reliable way to disable SASL authentication mechanisms, other than removing files from the library directory? Set sasl_mech_list to the list of mechanism you wish to support. For example, sasl_mech_list: kerberos_v4 gssapi plain anonymous -jeaton Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
Rich Wales wrote, at 11/14/2007 06:13 PM: It looks like my problem with replication not working in one direction was a SASL thing. One of my servers was advertising GSSAPI as an authentication mechanism, but it didn't really work (I don't have Kerberos installed on my systems). Apparently, sync_client on the other box was deciding to use GSSAPI, but was giving up because it wasn't actually functional. I fixed the problem by moving the libgss* libraries out of the SASL2 library directory. While I was at it, I also moved the libntlm* and libotp* libraries out of the SASL2 library directory, since I'm not using either of these authentication methods either. I'm mildly concerned that a future software upgrade might cause these libraries to reappear. Is there a more reliable way to disable SASL authentication mechanisms, other than removing files from the library directory? I don't use replication, but for normal authentication, I'm able to specify which mechanisms are advertised by including this in imapd.conf: sasl_mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 Maybe this (or some variation) will also work for replication, and you can leave the libraries in place. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
On Nov 13, 2007 8:08 AM, Rich Wales [EMAIL PROTECTED] wrote: OK, so I decided to try what I described earlier (replication in both directions, with different users using different master servers) . . . . But now I'm running into an authentication problem. One of my servers (my original replica) simply refuses to authenticate to the other one (my original master). I've double-checked the user name and password, and I know it's in the sasldb2.db file on the master, but authentication just will not work. I tried synctest to each server, and I can't connect to either server using synctest. Examples (whodunit is my original master; flipflop is my original replica; and I've obscured the real authentication strings in the AUTHENTICATE commands): % synctest -u admin -m plain whodunit S: * SASL NTLM LOGIN PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5 S: * STARTTLS S: * OK whodunit.richw.org Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO user not found Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. % synctest -u admin -m plain flipflop S: * SASL CRAM-MD5 DIGEST-MD5 GSSAPI LOGIN PLAIN NTLM S: * STARTTLS S: * OK flipflop Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO authentication failure Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. What's especially weird is the first one (whodunit), which gave a user not found error, even though there IS an account named admin in the sasldb2.db on that machine. Any ideas what I might be doing wrong here? Do you have virtdomains enable ? Did you setup defaultdomain ? Did you define user [EMAIL PROTECTED] ? Is $defaultdomain in loginrealms ? Hope this help. -- Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED] http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales The difference between theory and practice is that, in theory, theory and practice are identical -- whereas in practice, they aren't. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Alain Spineux aspineux gmail com May the sources be with you Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
On Nov 13, 2007 8:08 AM, Rich Wales [EMAIL PROTECTED] wrote: OK, so I decided to try what I described earlier (replication in both directions, with different users using different master servers) . . . . But now I'm running into an authentication problem. One of my servers (my original replica) simply refuses to authenticate to the other one (my original master). I've double-checked the user name and password, and I know it's in the sasldb2.db file on the master, but authentication just will not work. I tried synctest to each server, and I can't connect to either server using synctest. Examples (whodunit is my original master; flipflop is my original replica; and I've obscured the real authentication strings in the AUTHENTICATE commands): % synctest -u admin -m plain whodunit S: * SASL NTLM LOGIN PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5 S: * STARTTLS S: * OK whodunit.richw.org Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO user not found Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. % synctest -u admin -m plain flipflop S: * SASL CRAM-MD5 DIGEST-MD5 GSSAPI LOGIN PLAIN NTLM S: * STARTTLS S: * OK flipflop Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO authentication failure Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. What's especially weird is the first one (whodunit), which gave a user not found error, even though there IS an account named admin in the sasldb2.db on that machine. Any ideas what I might be doing wrong here? Do you have virtdomains enable ? Did you setup defaultdomain ? Did you define user [EMAIL PROTECTED] ? Is $defaultdomain in loginrealms ? No, my testconfig is very simple: configdirectory: /var/lib/imap partition-default: /var/spool/imap admins: cyrus sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt delete_mode: delayed Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
On Nov 13, 2007 8:08 AM, Rich Wales [EMAIL PROTECTED] wrote: OK, so I decided to try what I described earlier (replication in both directions, with different users using different master servers) . . . . But now I'm running into an authentication problem. One of my servers (my original replica) simply refuses to authenticate to the other one (my original master). I've double-checked the user name and password, and I know it's in the sasldb2.db file on the master, but authentication just will not work. I tried synctest to each server, and I can't connect to either server using synctest. Examples (whodunit is my original master; flipflop is my original replica; and I've obscured the real authentication strings in the AUTHENTICATE commands): % synctest -u admin -m plain whodunit S: * SASL NTLM LOGIN PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5 S: * STARTTLS S: * OK whodunit.richw.org Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO user not found Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. % synctest -u admin -m plain flipflop S: * SASL CRAM-MD5 DIGEST-MD5 GSSAPI LOGIN PLAIN NTLM S: * STARTTLS S: * OK flipflop Cyrus sync server v2.3.9 Please enter your password: C: AUTHENTICATE PLAIN *** S: NO authentication failure Authentication failed. generic failure Security strength factor: 0 C: EXIT Connection closed. What's especially weird is the first one (whodunit), which gave a user not found error, even though there IS an account named admin in the sasldb2.db on that machine. Any ideas what I might be doing wrong here? Do you have virtdomains enable ? Did you setup defaultdomain ? Did you define user [EMAIL PROTECTED] ? Is $defaultdomain in loginrealms ? No, my testconfig is very simple: configdirectory: /var/lib/imap partition-default: /var/spool/imap admins: cyrus sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt delete_mode: delayed Ops, that was the wrong thread, sorry! Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication: problems with synctest
My earlier problem with synctest turned out to be caused by my not specifying an authentication name (-a argument on the command line). Since I didn't have an -a argument, synctest apparently decided to use my account name (from the USER environment variable?) as the authentication name -- which was definitely not what I wanted. I figured this out by decoding my AUTHENTICATE PLAIN base64 string and noticing my own account name included there, even though I was trying to log in as admin. When I started using commands with both -u and -a, such as this . . . synctest -u admin -a admin -m plain whodunit . . . my synctests started working just fine. However, sync_client on one of my servers (flipflop) is still unable to connect to sync_server on the other server (whodunit). I've been adding a bunch of syslog() calls to backend.c and saslclient.c, in an attempt to get sync_client to explain what is going on. So far, all I can determine is that the call to sasl_client_start(), near the top of saslclient(), in saslclient.c, is failing with a SASL_FAIL returned value. I'm not sure why, yet. Replication syncing in the other direction (whodunit to flipflop) works just fine. Remember, what I'm trying to do here is to set up replication going both ways between a pair of servers. This is 2.3.9, BTW. Any ideas welcome. -- Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED] http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales The difference between theory and practice is that, in theory, theory and practice are identical -- whereas in practice, they aren't. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
