Topic: Anyone got WinCVS working with SME Server???

[Jason Judge]

Hi,

I am attempting to use WinCVS to access a CVS repository on an SME server for some collaborative project work.

I've installed CVS on my SME 5.1.2 and it appears to be working correctly. I've set up a test repository in an i-bay and imported some test files.

I have enabled SSL access using standard passwords: I can connect to a telnet session over SSL using 'putty'. Using that telnet session I can access the CVS repository, so the user has correct permissions. That bit works fine.

I have set up port forwarding (local 2401 to my-server:2401) through putty. The logs tell me that is working.

I am attempting to connect to the CVS repository using WinCVS 1.2 connecting to localhost port 2401 (which is getting forwarded, presumably over the secure SSL session opened using 'putty').

So - why does this not work? I get errors like this from WinCVS:

cvs login
(Logging in to myuser@localhost)
cvs [login aborted]: recv() from server localhost: Connection reset by peer
*****CVS exited normally with code 1*****

Have I got this whole approach arse-about-face or is there still something else I need to set up?

I've read enougth manuals and howtos numb my brain, and still it all makes no sense. Anyone got this working?

-- Jason

[Jason Judge]

Or any other CVS client, for that matter....

I just need to know how you set it up, as the error messages I am getting back do not give me any clue as to where my problem actually lies.

Do I need to run some kind of daemon on the SME Server or do I need to open some ports or reboot the server? The Mitel HOWTO referred to SME/E-smith 4.2 - and ports may have been closed in 5.1.2.

-- JJ

[Greg Zartman]

Yes, works like a charm.  

I simply followedd the CVS howto on the Mitel site to install CVS on my SME box.   Once installed, you'll need to set a couple of environment variables on the client machine to gain access to you CVS server:

cvs_root=ssh
cvsroot=:ext:username@domainname:/cvsroot

I'd try the console CVS client first to make sure everything is working OK before moving to wincvs.

Regards,

Greg Zartman.

[Jason Judge]

When you say the 'console CVS client' do you mean 'cvs' from a shell command line on the SME box? If so, then I have confirmed this works fine. If not, then I would appreciate any pointers to a suitable basic CVS client.

I assume the '/cvsroot' would be the full server path to the CVS repository. In my case it is in an i-bay and so the path is /home/e-smith/files/ibays/cvsroot/ etc.

I know the ssh is working as I can get a secure command-line session up and running to the SME Server. Is this what the 'console CVS client' would be using to talk to the server?

The problem seems to be connecting WinCVS via the CVS server port, 2401. The server appears to be refusing connections (but I really don't know if it is) and I have no idea if it's the port that's wrong, the connection type, the username or password or even whether some process needs to be started on the server.

I'm sure everthing is there, but don't know enough about it to know where to look for the solution.

-- Jason

[Greg Zartman]

Jason Judge wrote:
>
> When you say the 'console CVS client' do you mean 'cvs' from
> a shell command line on the SME box? If so, then I have

Yes and no.  CVS from the console is a shell command, but you need to try it on the client machine in addition to the server.   I've you need a copy of the shell version of CVS for windows, give me a shout off-list and I'll email it to you.

> confirmed this works fine. If not, then I would appreciate
> any pointers to a suitable basic CVS client.

The best CVS client out there is the shell version.  I wouldn't use anything but that....  Granted, you can't browse the repository files like you can with wincvs, but there really isn't a need to.  Once you checkout a project, you should only be updating, appending, and adding to the main repository.  I find that the shell version is the best for doing this.

> I assume the '/cvsroot' would be the full server path to the
> CVS repository.

That's right.  To make life ALOT easier, I made a symbolic link in the base directory on my cvs server pointing to the ibay where I keep my CVS repositories:
cvsroot ->  /home/e-smith/files/ibays/cvsroot/files/

> I know the ssh is working as I can get a secure command-line
> session up and running to the SME Server. Is this what the
> 'console CVS client' would be using to talk to the server?

SME comes with ssh as a standard, but windows does not.  I downloaded ssh.exe (for windows) and stuck it in my /winnt directory on my client machine.   This is what is called by CVS as a result of one of the environment variables that I told you about yesterday:  cvs_rsh = ssh.

I think WinCVS has ssh built into it, but can't remember.  In any event, get the shell command verison of cvs working on your client machine first, then start messing with WinCVS.

> the port that's wrong, the connection type, the username or
> password or even whether some process needs to be started on
> the server.

If you followed the instructions on the CVS howto for SME, CVS will be sitting there waiting for requests.  Remember to create a repository on the server  using the command "cvs import -m "New Repository" repository_name repository_name start"  This will ONLY work if you've set the environment variables that I told you about in my previous message.  

Good luck.

Greg Zartman

[Jason Judge]

Nope - I've tried. There is something else wrong. I get the same message from the console CVS as I do from WinCVS:

C:\tmp>set cvs_root=ssh
C:\tmp>set CVSROOT=:ext:myuser@acadweb.co.uk:/home/e-smith/files/ibays/cvsibay/files
C:\tmp>cvs import -m "test2" test2 test2 start
> acadweb.co.uk:Connection refused
rsh: can't establish connection
cvs [import aborted]: end of file from server (consult above messages if any)


The only clue I get that I am actually attempting to connect to the server is the server hard disk light that flashes as I press , otherwise there are no other clues - not anything in any log file I can find.

The wierd thing is that this command does not prompt me for a password. Should it? Or should the server connection be established first?

CVS works fine on the server, it is just the when I try using it over the ssh link that I get this 'Connection refused'. I am absolutely stuck as I do not have a clue where to look next as I don't know what bit is broken.

Has anyone else had this problem? Did you find a solution?

-- Jason

P.S. Thanks for your help so far!

I just had a thought - I installed the CVS RPM through the SME Server 'Update Server' pane. This does run as root, doesn't it? If there were any setuid files to install then I assume it would have to. /usr/bin/cvs is owned by root, so I assume this isn't the problem.

[Jason Judge]

Okay, I've got the command-line version working now. The environment variable that needs setting is CVS_RSH=ssh.

There is a great article at http://www.ifm-services.com/people/jamesk/papers/cms/cvs-win32-client.html which explains how to set up the public-private keys required to allow SSH to function correctly.

-- Jason

[Frej]

Even following exactly what's explained in the link Jason pointed out, I can't make it work. I always get this :
--
Z:\>ssh -v -l frej olianet
SSH Version 1.2.14 [winnt-4.0-x86], protocol version 1.4.
Standard version.  Does not use RSAREF.
ssh_connect: getuid 0 geteuid 0 anon 0
Connecting to olianet [192.168.2.1] port 22.
Connection established.
Remote protocol version 1.99, remote software version OpenSSH_2.9p2
Waiting for server public key.
Received server public key (768 bits) and host key (1024 bits).
Host 'olianet' is known and matches the host key.
Initializing random; seed file z:/.ssh/random_seed
IDEA not supported, using 3des instead.
Encryption type: 3des
Sent encrypted session key.
Received encrypted confirmation.
Trying RSA authentication with key 'frej'
Server refused our key.
--

If you have any ideas on what is wrong please tell me.
thx bye.

[Jason Judge]

Now I have got it working, it is fantastically easy to use (and we have a small team on this project geographically distributed - i.e. not in one place).

However, what I did was give up on WinCVS. It is probably the most unintuitive of all the CVS tools I have used, so when it is not behaving it is difficult to tell exactly what it is and is not doing right and, indeed, what it is supposed to be doing in the first place.

For me - Tortoise CVS (v0.44 - I have not got 0.56 working under Win2000) is the bee's knee's. It integrates with Windows File Explorer and does 99% of what you would commonly want to do. There is always the command line to drop back to when you want to do something more complex. Even after using Tortoise I tried going back to get WinCVS working, but failed misserably. I always got the 'server refused' error, but I still don't have a clue _what_ is being refused!

Set up some private/public keys on your Windows machines and likewise in your Unix account, then ssh.exe does not need a password to connect. I use putty.exe to show this works. Install Tortoise and tell it to use ssh and that is just about it.

WinCVS though? I'm sure it's good, but I just can't get my head around the way the application is structured.

Reply if you want some more detailed instructions.

Regards,

Jason

[Frej]

Hi !

I'm using the "mini-HOWTO" from the link you provided.
I tried using TortoiseCVS, but even in TortoiseCVS, I always get the "Server Refused Our Key" error (see exact error in my last message).

I tried to create the keys under windows (ssh-keygen from tortoise, or the way it is explained for putty) and linux (directly creating keys under each user on the server)... but it doesn't work.

And I just can't figure out what's wrong !

I tried to checkout sthg anyway but I need to give my password to a cmd box coming out of nowhere (with "ssh" title) in order to make it work. ssh keys just don't make it

Thx for help.

Frej.

[Jason Judge]

Frej,

I did write a long reply - but then I pressed the Escape key and it all disappeared! My fingers must have been in vi mode

The gist of my reply was: there are two places I know of on Windows where the keys are stored. Different applications may look in either one of these places.

* putty.exe uses the Unix method and looks for the ssl keys under a '.shh' directory at a location defined by the environment variable '%HOME'.

* ssh.sh uses the Windows method and looks for the "%USERPROFILE%/Application Data/ssh/authorisation" (or something like this) directory and gets the kesy from here - at least it does on Windows 2000.

The file formats and sub-directory names at these two locations are slightly different (naturally - why should it be easy to integrate Win/Lin?) and so the keys need to be copied to both these locations for the full set of ssl tools to work, i.e. you can't use one directory for both putty.exe and ssh.exe.

I can post more details if needed. Let me know which version of Windows you are using.

Don't forget each user of the SME server needs the keys in their home directory under ~user/.ssh and this directory (and everything it contains) must be set (chmod) 600 before it will work.

JJ

[Frej]

thx : the las advice was it... keys were not in the right place, and not with the good rights...

thx a lot.

[Jason Judge]

Glad to be of help.

-- Jason