cvs pserver not listening on port 2401

[Karl Lehnberger]

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&
or over
xinetd
and then trying to connect from a client via
telnet cvshost 2401
or
cvs :pserver:***@cvshost:/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-socke
t
but the cvs server is running.
What can be the reason that "cvs pserver" isn't listening on port 2401?
There is no blocking firewall or router involved.

Thank's for help
-Karl

[JGentilin]

Did you try nmap? This should show the cvspserver on port 2401. Do you
have any local firewall rules that might block the port? I had a similar
problem when I setup my RedHat 9 machine as a server install.

Post by Karl Lehnberger
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&
or over
xinetd
and then trying to connect from a client via
telnet cvshost 2401
or
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-socke
t
but the cvs server is running.
What can be the reason that "cvs pserver" isn't listening on port 2401?
There is no blocking firewall or router involved.
Thank's for help
-Karl

[Larry Jones]

Post by Karl Lehnberger
But starting the cvs server either with
cvs -f --allow-root=/space/cvs pserver&

You can't do that -- CVS doesn't run as a stand-alone server, it *must*
run under a superserver like inetd or xinetd.

Post by Karl Lehnberger
or over
xinetd

Then your xinetd configuration likely wasn't correct.

-Larry Jones

Let's just sit here a moment... and savor the impending terror. -- Calvin

[Mark D. Baushke]

Post by Karl Lehnberger
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.

Post by Karl Lehnberger
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.

Post by Karl Lehnberger
and then trying to connect from a client via
telnet cvshost 2401
or
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.

Post by Karl Lehnberger
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.

Post by Karl Lehnberger
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.

Post by Karl Lehnberger
Thank's for help
-Karl

Good luck,
-- Mark

[Tom Copeland]

Post by Mark D. Baushke
The cvs executable itself is not intended to be a long-running daemon.

That's something I've wondered about... since cvs is run under xinetd,
the 500 KB binary gets loaded into memory each time a command comes in.
Has anyone given a shot at writing some front-end code to let cvs stay
in memory and serve up requests?

Yours,

tom

[Mark D. Baushke]

Post by Tom Copeland

Post by Mark D. Baushke
The cvs executable itself is not intended to be a long-running daemon.

That's something I've wondered about... since cvs is run under xinetd,
the 500 KB binary gets loaded into memory each time a command comes in.

I suspect the size and how many pages of the program may be shared among
processes will depend on your hardware and operating system.

Post by Tom Copeland
Has anyone given a shot at writing some front-end code to let cvs stay
in memory and serve up requests?

There are multiple 'front-end' programs for cvs. Two of the most popular
are named xinetd and inetd.

As for your suggestion that cvs run as a long-lived daemon, it is not
written securly enough for that (honestly, it would need a redesign and
reimplementation to be even close to safe running as 'root' most of the
time, that rewrite is called 'svn' and may be fetched from
subversion.tigris.org) and in any case as it needs to protect ownership
and group permissions, so all of the work after the initial connection
would need to be handed to a forked copy of itself that changed
permissions in any case which would have to switch users and 'lose' its
ability to do the right thing with future connections without a lot of
redesign.

Of course, I admit that I would personally rather see :pserver: code
dropped entirely from cvs as I do not consider it safe to operate a
server in pserver mode. In my opinion, cvs should operate without trying
to do user authentication and primary access control should be handled
by the operating system on which cvs is running... so I may be a bit
biased on the subject of this thread.

Enjoy!
-- Mark

[Larry Jones]

Post by Tom Copeland
That's something I've wondered about... since cvs is run under xinetd,
the 500 KB binary gets loaded into memory each time a command comes in.

Most modern systems keep the text in virtual memory until something else
needs the memory, but if you're concerned, you can always set the sticky
bit on the exectuable.

Post by Tom Copeland
Has anyone given a shot at writing some front-end code to let cvs stay
in memory and serve up requests?

That could be a challenge since the code is completely untested in the
environment. People have already reported problems sending multiple
commands over a single connection, let alone trying to server completely
unrelated users.

-Larry Jones

I think we need to change the rules. -- Calvin

[Tom Copeland]

Post by Larry Jones

Post by Tom Copeland
Has anyone given a shot at writing some front-end code to let cvs stay
in memory and serve up requests?

That could be a challenge

Yup, sounds like it :-). That's cool, just wondered about it...

Thanks,

Tom