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
