I recently moved a machine from our MAIN domain to a LAB domain (another domain with a hardened filewall for R&D and crazy stuff.)
We use Subversion for most of our Source Control, but a lot of legacy stuff is still in CVS and uses SSPI (Security Service Provider Interface enabling NTLM for CVS). So, when I do an update from Tortoise it automatically sends my Windows User details over there and authenticates me against the domain.
However, now I'd moved the machine and it was in another domain. The LAB domain is fairly harded and doesn't have a way for a MAIN domain user to login. Consequently updating CVS via SSPI is/was a problem.
I wrote a lame little batch file that's used like this:
addcvsuser.bat MYREPO labcvsuserIt looks like this:
IF "%1"=="" GOTO USAGEIF "%2"=="" GOTO USAGESET CVSROOT=:sspi:MYCVSSERVERNAME:/%1cvs passwd -a -r MAIN\somewindowsuser %2SET CVSROOT=GOTO EXIT:USAGEECHO Usage: addcvsuser REPOSITORY NEWUSERNAME:EXIT
Assuming the admin is logged in as a legit user, this file temporarily sets the CVSROOT Environment Variable with the name of the Repository you want to add a user to. The user will be added to the passwd file in that repository and won't be a real Windows User. It might be a user named labcvsuser that doesn't exist on the domain. That user is mapped to MYCVSSERVERNAME\somewindowsuser that IS a real Windows User, on the real MAIN domain.
Then, in Tortoise I change the CVSROOT used by Tortoise to :pserver: instead of :sspi: and open up ports 2401 and 2402. Now the LAB TortoiseCVS can use a username/password combo that's not on the domain and get mapped to a domain (or local) user and crisis averted.
Ads by The Lounge