> I don't understand. What would prevent you from using CVS in client/server mode
To begin with, we can ignore pserver out of hand, right?
> (unless those that configured it absolutely turned it off) if you're able to use
> it in local mode? The only thing I can think of is if the repository is mounted
> and you don't have a login to the machine that it's mounted on.
Yes, assuming you meant "the repository is mounted on a network filesystem
from a fileserver, and you don't have an account on the fileserver."
Exactly. Somewhere on the web you will find advice on creating reliable
networked filesystems, which will say "First, don't let any ordinary users
ever log into the fileserver." Users may have accounts, but the accounts
exist purely for book-keeping and filesystem quota purposes. Users can
neither log in nor ssh in nor ... do anything to a fileserver, except access
files from in using the network filesystem.
I think this is a fairly typical configuration. Certainly, it's been the rule at
the 5 different sites I've worked in over the last 15 years.
> Assuming a default configuration. All one would have to do is set their CVSROOT
> properly, possibly set CVS_SERVER, and set CVS_RSH if one isn't using rsh.
You could get away with this by running "cvs server" not on a fileserver,
i.e. not on a local disk, but on a network filesystem client. I can even imagine
that this might simplify things wrt filesystem coherency --- everyone running
through a single cache manager --- even though I have never encountered
problems in that area.
But it doesn't always work, because of account administration.
Consider the AFS example, first the world, and then inside a single company:
The University of Wisconsin CS department uses AFS. It uses "public" AFS
- all UW CS filesystems area available anywhere in the world that has an AFS
client.
If I want to work with somone at Rutgers, I only have to add him to the ACLs
for my CVS repository, and he can pick it up over AFS. (This assumes that
you are using cross-realm authentication.)
Without AFS, I would have to give him an account on the machine that holds
the repository so that he can run CVS server. Or, create an anonymous account,
or, have him use my account, with some sort of additional layer of security
or authentication. None of which I am allowed to do, or, at least, none of which
I should be allowd to do on a properly secured system. (Wrt the only secure option,
giving him an account, I may just not want the hassle of doing so.)
Now consider a company that, say, has sites in Oregon, California, Israel,
Arizona, and Washington. It has internal firewalls - firewalls not just
between the intranet and the internet, but firewalls between the Israel
and Oregon, and even between projects in Oregon.
The company has already gone to the effort of setting up a corporate
wide AFS, and arranging for it to cross the firewalls. I.e. the security of
AFS is felt to be sufficient to make the security mavens happy.
(One day DFS will be available on the platforms I want it on.)
Other traffic across the firewalls is restricted: FTP, telnet, SSH.
Now say I'm in Oregon and I want to work with someone in Israel.
CVS pserver is out - the intra-company firewall doesn't allow it,
and I do not believe that pserver is secure enough to ask.
RSH out. SSH might be okay, but then I need to arrange for
the Israeli to have an account in Oregon, or vice versa; i.e. I fall
back to the account administration issue.
All of this is extra hassle since AFS is already everywhere.
(Now, I fudged a little bit - last I checked, cross realm authentication
wasn't working properly in AFS. It may be necessary to obtain a remote
account just so that you can obtain a token from the realm you want
to access files in. Nevertheless, an account just to allow authentication
is a hell of a lot less dangerous than an account that is actually
authorized to do things remotely.)
