Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony, now I have received a compoletely new PC so I can install stuff from the bottom up. :-) I installed CVSNT 2.5.2.2054 using my Innosetup installer. I installed the latest WinCvs available today at SF. Then I copied my whole work folder from the old PC to the new one including all CVS metadata. Next I opened a VPN channel to the office network where we have a CVSNT server running since years. It is now at version 2.0.38. Here I tried this: 1) in a sandbox with CVSROOT=:sspi:cvsserver:/PC I went ahead and issued a graph command from WinCvs to verify my connection. This succeeded immediately. 2) in a sandbox with CVSROOT=:sspi:bosse at cvsserver:/PC i first tried the log command but of course it failed because I have not yet logged in to the cvs server on this new PC. So I typed cvs login in the WinCvs command window. After entering my password I received this response: cvs login Logging in to :sspi:bosse at cvsserver:2401:/PC [80090311] No authority could be contacted for authentication. 3) Now I extracted the files from the 2.0.51d binaries zipfile I had saved into a new directory and pointed WinCvs to use this cvs.exe. Then my cvs login command succeeded and afterwards I could do all the stuff like graphing etc in this sandbox. 4) Then I switched WinCvs back to use the cvsnt build 2054 I had previously installed and tested operations on the bosse at cvsserver sandbox. But I was again treated to the infamous message: cvs log -- AGIAdmin.cfg (in directory C:\Engineering\Projects\PC\AGIAdmin\) [80090311] No authority could be contacted for authentication. Finally I decided to narrow down where this behaviour started so I extracted a number of binary packages and redirected WinCvs to these versions. The result I now have is that 2.5.2.2040 is the latest cvs.exe that I have access to which does work properly, the next one (build 2048) has this problem. So this shows that somehow the client operations done by the new builds cause a sspi authentication error if the CVSROOT is of the form :sspi:user at server:/repo, but succeeds with :sspi:server:/repo In the latter case I assume that the same authorisation server is used (the PDC of the office network)? That is a Windows 2000 server with Active Directory. My local PC is not connected to the domain, it is a Workgroup PC, but I have the same login here as I have on the domain. And whatever was done to break this was done between builds 2040 and 2048. Any ideas? /Bo (Bo Berglund, developer in Sweden)