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.
=================================================================== This posting is slightly out of time because of the crash of the cvsnt newsserver, but I am posting the reply anyway with an extra note at the end... =================================================================== On Sun, 28 Aug 2005 18:15:31 +1000, "Arthur Barrett" <arthur.barrett at march-hare.com> wrote: > >> G:\Engineering\DelphiGUI>cvs log --FormBatch.pas >> [80090311] No authority could be contacted for authentication. > >Can anyone else reproduce this? There have been a handful of other postings with similar problems... > >We cannot reproduce it here, so are missing some vital ingredient. I >personally use this user at host technique all the time with sspi.... > >Bo - do you have a home network or some other place you can try testing >this? See end of this response. > > I have seen other postings with the same problem so it is not only myself that is having this problem. I have the following setups where the problem shows up: 1. My "production" CVSNT server at home Here is where I manage my own projects like CVSMailer. It runs CVSNT 2.0.41a on a Windows 2000 Server PC. When I use the latest CVSNT as client on any of my various home PC:s I get this error message. But when I switch WinCvs to use an older set of binaries (in this case 2.0.51d) the cvs commands succeed juat fine. 2. A company CVSNT server accessed via VPN This case is real production software and the company LAN is accessed via VPN over the Internet. The server is a 2.0.38 CVSNT running on a Windows XP Professional PC (only a handful of developers). Exactly the same behaviour is observed here, with the user at server syntax there is invariably the error message with later builds on the client side, but switching the WinCvs binary usage (or on the command line by entering the full path to the alternate cvs.exe) to the older cvs makes everything work fine again. My feeling is that a test environment can be set up by: A) Install CVSNT server version 2.0.41a on a test PC B) Create a repository with some files in it C) Use a client PC where you also install 2.0.41a to access the server with the :sspi:user at server:/repo syntax D) Log in and check out a module E) Verify that you can update and log etc F) Now on the *client* PC install build 2064 (and possibly reboot) G) Go to the sandbox created in D) and check cvs operations I think you now will get the problems I (and others) have reported. I do have Internet access to my CVSMailer server but you have to email me in private so I can send you the address and login data. It is the 2.0.41a server mentioned above. ------------------NOTE-------------------------- During the time the cvsnt newsserver was down Arthur has pinpointed the cause of the authentication problem when a new cvs client accesse an old cvsnt server with the cvsroot set to :sspi:user at server:/repo. The reason is that the new client by default will use Kerberos rather than NTLM and since the Kerberos support is not implemented fully in cvsnt servers of olden times the connection fails. Workaround: Change the CVSROOT to :sspi;force=NTLM:user at server:/repo this must be done on existing sandboxes by using the WinCvs macro or manually editing all of the CVS/Root files. /Bo (Bo Berglund, developer in Sweden)