[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to kill server but not client

From: Mark D. Baushke
Subject: Re: how to kill server but not client
Date: Fri, 30 Jul 2004 17:00:11 -0700

Hash: SHA1

ben <address@hidden> writes:

> If this is in the documentation anywhere it's managing to elude me. Is
> there a functional way to remove or completely disable the cvs server
> daemon separately from the client? This would be on Linux machines
> with cvs installed via rpm's, which give no option to install only the
> client.

It is not possible to run a long-lived daemon to listen to cvs requests.

There is no cvs server daemon as such. It is possible to configure cvs
to be run from your inetd or xinetd in 'pserver' mode, but it is not
required that you do this. In fact, there are many who believe that
configuring a repository to use :pserver: is a bad idea from a security
point of view.

A cvs server needs to have a cvs repository in order to do work, so if
you don't have a repository on the server side, there is nothing for
that code to do.

If you never want to allow your cvs executable to act as a server, then
you would need to modify the cvs.spec file to include --disable-server
on the configure line... something like:

        %configure --without-gssapi --disable-server

and build your own RPMs for distribution.

If you run 'cvs --version' and it includes '(client/server)' in the
output, then you will know that the same executable could be used to
be the server side of a cvs connection if there is such a desire on
the part of the user as well as disk that could be so used.

Any user may create a private cvs repository to use provided they have
diskspace in which they may write files.

> I really don't understand the logic of bundling client and server in
> one rpm.

The client and the server are a single executable called 'cvs' rather
than separate executables.

Another application with a similar kind of function is rsync.

In both cases, the same executable may be used at both ends of an RSH or
SSH connection to transport information.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]