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.

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.