Apache OpenOffice (AOO) Bugzilla – Issue 6125
cvsup service is not running through tunnel
Last modified: 2003-12-06 14:52:32 UTC
Connected to so-cvsup Premature EOF from server
Martin, Our operations department was able to sync anoncvs prior to my closing the original issue. Are you using the IP or domain name to establish a connection with the server? I see in scripts from the first SC migration that IP was being used. If so, this would need to be updated to 64.125.133.202. Investigating further with operations as well. Kat
Operations reports that cvsupd is functioning on the server. Report in 5917 from Martin that this is still not functioning for him. Have requested script/configuration information.
have they tested cvsup directly or via ssh tunnel ? are thet sure this is not related to 3829 ? my configuration: bash-2.04$ /usr/local/bin/cvsup -v CVSup client, non-GUI version Copyright 1996-2001 John D. Polstra Software version: SNAP_16_1d Protocol version: 16.1 Operating system: LINUXLIBC6 http://www.polstra.com/projects/freeware/CVSup/ Report problems to cvsup-bugs@polstra.com called: bash-2.04$ /usr/local/bin/cvsup -1 -d 1000 -l /usr/local/cvsup/LOCK.cvsup -P m -g -L1 /usr/local/cvsup/supfile bash-2.04$ cat supfile *default umask=2 *default host=so-cvsup *default base=/usr/local/cvsup *default prefix=/usr/local/anoncvs/repository *default release=cvs *default delete use-rel-suffix cvs
I will double check this with them. Is the output from telnet similar to that in the previous issue?
Could you please log into the server where the tunnel is running 'telnet localhost 5999' on the tunnel server and run their normal cvsup client with the '-L 2' option for deugging and include the output here so operations can see that output?
updating whiteboard with internal issue number.
bash-2.04$ telnet localhost 5999 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host.
Operations has corrected the config files, you were correct the change needed to be made as in the previous issue like this. Could you please see if you can connect now? Thank you Kat
output after using -L2: Parsing supfile "/usr/local/cvsup/supfile" Connecting to so-cvsup Connected to so-cvsup Premature EOF from server
error message is still the same.
The configuration has been double checked and the issue is moving to an engineer for further investigation.
*** Issue 5917 has been marked as a duplicate of this issue. ***
Operations reports that service should be restored now. Could you please let us know if you are now able to use cvsup? Thank you Kat
Correction : can you use the service when _not_ connected through the tunnel? If not, could you please provide debug output of a tunnel session? Thank you Kat
It works without ssh-tunnel.
It is believed that the problem with using cvsup via the tunnel is related to the version of OpenSSH we are running on Solaris, but the exact difference is at this point unknown. Is running cvsup through the tunnel a requirement for you, or is it acceptable in its current state?
Hi Kat, since when 5999 is open to the world? In former times we are required to use the ssh tunnel. We were not aware that this port is open.
Hi, I would like to see some restriction for the world for using the cvsup service. We know that the wrong usage of cvsup clients can cause some server overload. so please provide a mechanism to resrtict access to certain clients.
I am discussing this situation with operations to determine at what point port 5999 was no longer blocked by the firewall, which was the original situation requiring the tunnel, as well as the implications. I have updated the issue discription to reflect the current situation.
We can provide restricted access to cvsup on the main server by adding a list of the allowed server IPs to a cvsup configuration file. If you could provide this list we can begin work on restriction. Operations had concerns about the load on the main site if cvsup access was widely advertised.
I still prefer cvsup access via ssh tunnel as this avoid problems with IP address changes. As this worked before migration to Solaris and works for cvs access I would like to see a plan for resolving the issue with cvsup access over ssh tunnel. In the meantime you may restrict access by IP, if it's possible to give ranges. We request access for the ranges 62.156.160.1-62.156.160.255 and 192.109.83.1-192.109.83.255.
Operations will begin by resticting access to the range of IPs provided, and investigate the tunnel issue further.
reassigning to support
accepting
taking co-ownership of this issue for support
issue was logged as pcn 10371 internally. insteng wrote the changes with the ip restrictions and are ready to roll out to ops. this is described in pcn 10680. when ops has a schedule and timeframe I will provide more information.
The inst rollout was completed last week. The ip range has been restricted to those listed. Could you please test the functionality of this issue and post any comments or questions? Thank you.
IP range restriction works. For the reasons mentioned above, I would like to see CVSUP over ssh2 tunnel work. What's the plan to get this work again?
We are discussing this replacement internally via PCN 11183 (through Eric @ Sun and David @ Collab). Since this issue was taken care of I'm closing the ticket. Any further discussion should go through those contacts. Thanks
Sorry, I have to disagree about the status of this issue. From my point of view "cvsup service is not running through tunnel" is not fixed. But may be we should discuss this also in the group mentioned below.
David @ Collab and Eric @ Sun have been discussing this offline. Changing status
Our plan is that we will update this issue when we here from David Boswell and Eric Renaud on the outcome of their discussions. Please let us know if that timeframe is not acceptable.
Now that the CVSup performance issue is resolved, we've agreed to leave the CVSup access method as is. We can go ahead and close this one out and then reopen as necessary if there are any additional comments or suggestions relating to this issue. Kenneth will officially close this out since IZ doesn't want to let me do it ;-)
closing issue, thanks
As agreed by Louis I will close these resolved fixed support-owned issues now. If you have trouble with that, please re-open the issue.