[cvsnt] SSPI stopped working -- how to troubleshoot
garyl at veicon.com
Wed Nov 21 18:04:28 GMT 2007
Bo Berglund wrote:
> For the sspi format you have used you can do the following on a command
> prompt on the client:
> set CVSROOT=:sspi:garyl at cvs-server:/CVS-Repository
> cva logout
> cvs login
> (Now enter the password)
> This will update the cached password if successful and sspi will work
Thanks so much. That worked (after I again undid the account lockout --
not sure why this keeps happening, but hopefully it won't any longer,
now that the password issue is resolved).
> The only reasons to use your version of the connect string (with the
> user explicitly entered) are:
> 1) If you are logged on to the client computer as another user than the
> one you want to use for communicating with the CVS server
> 2) If the client PC is not part of the domain the cvs server is
> connected to
> 3) If the cvs server is not part of the domain the client PC is
> connected to
> 4) If you are connected via VPN or similar with difficulty getting AD
> authentication running
Makes sense; I'll drop the username in the future.
> Concerning the -d option to CVS
> This is not something you should ever do inside an existing sandbox!
I certainly agree that's not the intended usage, but sometimes things
happen due to misunderstandings or less than optimal procedures or
accidents. Like, while the sandbox has files that have been edited, the
access method changes or the server location changes due to a hardware
problem, or who knows what.
> I am surprised that it even overrides the CVS/Root files that exist in
> the sandbox, it shouldn't!
Because of cases like I mentioned, I would argue cvs should act like we
have come to expect well-designed programs to work, such that a command
line switch should always override an environment variable, which should
always override a configuration file or registry setting (as in
"CVS\Root"), which should always override a hard-coded value. Otherwise
the command line switch and environment variable are essentially
disabled and useless. So I would argue the -d switch should have two
purposes, to provide a value when one doesn't exist, and to override it
if one does exist.
> You use this typically on the command line if you are executing CVS
> commands in a folder that is not a sandbox, for example in order to
> create a sandbox by checking out a module from the server.
> Apart from that I see no valid use of that syntax. Either you are
> working inside the sandbox and then the Root files show where the files
> came from and where any operation should be directed,
... agreed, unless something out of the ordinary happened and it's no
longer valid ...
> or you are outside a sandbox, when the -d option or CVSROOt env
> variable can be used.
> If the server has changed name then you need to modify all Root files
> accordingly, in WinCvs there is a macro to handle this for you.
Changing the environment variable or using the command line switch would
be so much simpler, especially if there was an option to update the
> Best regards,
> Bo Berglund
More information about the cvsnt