[cvsnt] More on authentication problems with build 2048 and up...

Bo Berglund bo.berglund at telia.com
Fri Aug 12 00:08:57 BST 2005


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)



More information about the cvsnt mailing list