Re: cvs pserver not listening on port 2401

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl Lehnberger <address@hidden> 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:address@hidden:/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-----