-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl Lehnberger <[EMAIL PROTECTED]> writes:
> Following the recommendations on > http://mia.ece.uic.edu/~papers/volans/setUpCVS.html > I set up a cvs environment on a RedHat9 Linux box (cvs-1.11.2-10). > But starting the cvs server either with > cvs -f --allow-root=/space/cvs pserver& This will not work as cvs does not itself bind to a particular port, but assumes that stdin, stdout and stderr will be connected to the appropriate place. > or over > xinetd This should work and should cause xinetd to be listening for connections to port 2401. When such a connection is initiated, xinetd will set stdin, stdout and stderr correctly for a newly created child cvs process and continue to listen on port 2401 for any other new incoming connections. The cvs executable itself is not intended to be a long-running daemon. > and then trying to connect from a client via > telnet cvshost 2401 > or > cvs :pserver:[EMAIL PROTECTED]:/space/cvs login > gives the error "connection refused" which means > that the cvs process isn't even listening on port 2401. > (verified with netstat) > In /var/log/messages I found > Jun 29 14:07:11 lll cvs: error setting KEEPALIVE: Socket operation on > non-socket > but the cvs server is running. In the first case, the cvs pserver is waiting for input from the controlling tty from which it was initiated. In the second case, my guess is that the xinetd is not properly configured or that you have a /etc/hosts.deny or other similar tcp wrapper configuration that is filtering all connections to 2401 into the bit bucket before xinetd sees them. > What can be the reason that "cvs pserver" isn't listening on port 2401? Becase 'cvs pserver' never listens on any port. That is something to do in xinetd or inetd and its interactions with either ipchains, iptables or the use of a tcpd wrapper using hosts.allow and hosts.deny files. > There is no blocking firewall or router involved. By default, many systems block this stuff for you. I believe that Redhat 9 GNU/Linux may be one such that does. Look for hosts.deny and hosts.allow files or an ipchains or iptables configuration as the most likely cause of this problem. > Thank's for help > -Karl Good luck, -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7V/d3x41pRYZE/gRAjVoAJ0YGnKxGFyqhQRPdwGwPw6a5g0buACgxXTN 0zSY5aTuX++XwRfqHfls1NI= =X21y -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs