Re: CVS_SERVER

[Greg A. Woods]

[ On Wednesday, August 1, 2001 at 15:09:13 (-0700), Mark D. Baushke wrote: ]
> Subject: Re: CVS_SERVER 
>
> Good for you. However, I have used :pserver: protocol repositories
> with read-write permissions in some cases. Calling them read-only is
> doing the :pserver: protocol an injustice.

To jump way off on a tangent for a second, no, it most certainly is not
doin the cvspserver protocol any injustice -- in fact it's jost the
opposite and is my one compromise to the whole cvspserver issue!

Cvspserver is quite literally a disservice to CVS as a whole and while
it exists it should only ever be used for anonymous read-only
repositories (since that's the only level of security it provides.

> You are mistaken.
> 
>  1) The default CVS_SERVER value is either 'cvs' or argv[0] depending
>     on how the ARGV0_NOT_PROGRAM_NAME macro is defined in main.c
>     The names are sometimes different if the client and server are
>     heterogeneous machines with regard to hardware and/or operating
>     systems (eg, UNIX client and VMS server).

What does that have to do with anything in this thread?  That hack is
simply a way to mangle program_name back into something recognisable by
the user.  I.e. it's the opposite of anything to do with CVS_SERVER.  So
far as I can tell neither argv[0] nor program_name are ever used on any
platform as the default name of the program to invoke as the server --
that's always $CVS_SERVER, or if it's not set then the hard-coded string
"cvs" is used in every case.

>  2) The CVS_SERVER is not a 'cheap hack' as it was developed because
>     all the world is not UNIX with UNIX semantics as to command
>     execution aliases via remote access shells. [No matter how much
>     you want cvs to be a unix only solution, it does work on a large
>     number of platforms.]

Well, it was actually described more or less as a cheap hack when it was
first developed (which was prior to 1993 as far as I can tell and
remember -- I'm not sure if it was there in the initial public release
of the C/S code in 1.5 or not).

In any case it does nothing that an appropriately designed wrapper
program on the server machine could not do itself.  Even the manual
describes CVS_SERVER as only an alternative.

[[ The manual source does contain a comment that suggests some later
maintainer did at one time at least agree in part with you (it was
probably Jim Kingdon -- I can't seem to get anonymous access to the CVS
repo right now to check though as somone's broken it and/or not fixed it
yet -- see what a pain it is to have that stuff stored in CVS/Root!) ]]

(and CVS_SERVER of course has no meaning whatsoever for :pserver:, which
is the only situation where a personal wrapper program could not work)

>     It is my recollection that the CVS_SERVER was introduced to make
>     it possible to work on machines which did not or could use a the
>     same command name on the client as is used on the server.

No, it was introduced as a hack to work around situations where the
"cvs" binary was installed in a directory not normally in the default
rshd/sshd path.  Clearly a wrapper program in the default path, or a
command alias/function, or a fix to the PATH in ~/.kshrc or whatever (as
described in the manual) avoides the problem from the get go.

CVS_SERVER really is only ever useful for short-term hacks where a quick
work-around is necessary for testing, etc.  Indeed it probably gets the
most use ever from src/sanity.sh itself.

Encoding the value of CVS_SERVER in CVS/Root is not only wrong and
unnecessary, but will lead to far more problems than it can ever solve.

>  3) Just because you appear to only ever use unix boxes does not mean
                       ^^^^^^
>     that other systems out there do not exist that sometimes need to
>     have the name be 'CVS' or 'cvs.exe' on the client and something
>     else on the server (possibly even a full pathname using odd
>     characters like brackets when that pathname is a VMS-style path
>     with lots of $s and square brackets in the path).
> 
> Greg, I know it may be difficult for you, but could try not to show
> your UNIX-centric bigotry in every e-mail you send in the future.
> Please?

There is nothing unix-centric here.  This is a name mapping issue, and
only a name mapping issue.  Pick your poison and I can hand you a safe
mangling algorithm that'll turn "cvs" into whatever's necessary.

As far as I know all non-Unix implementations of rshd and/or sshd
implement some way of searching a set of "paths" to find an executable
program of a given name even if the underlying OS command-interpreter
has no concept of a command "search path".  Certainly any POSIX
compatible system will have such a facility to be used by rshd/sshd.

Note also that unless I'm grossly mistaken and my memory of doing such
things has gone bad "cvs.exe" or "CVS" is redundant in almost all
scenarios:  "cvs" alone will work just just fine with any proper
implementation of rshd or sshd since any such need for name mangling
will already have been anticipated by the implementors of rshd/sshd.

> It may not be possible for them to setup anything on the remote
> end. Just because the administrators of some system are being
> pig-headed does not mean that the community of cvs developers need to
> make it hard for people to use cvs.

If you've got non-cvspserver access to the CVS server then either you
can set stuff up on the CVS server (i.e. you will have shell access), or
the admins will have set things up properly for you in the first place
without need for any personal mangling (i.e. you don't have explicit
shell access and the admins are forcing you to run only a specified CVS
binary).

I don't know why you're trying to make this sound like a difficult
problem -- it's trivial every-day stuff for anyone who's done any amount
of similar remote job entry/execution in any modern networking
environment.

> Then I suggest that YOU use a wrapper script if that makes life so
> much better for YOU. However, you may find yourself needing to use
> CVS_SERVER yourself if you do that and you want the remote end to run
> your wrapper script instead of the 'cvs' that it finds first in its
> path... maybe you will be lucky and can put your own version of 'cvs'
> into your path on all of the remote servers that need it. You may have
> trouble if your systems admin restricts your remote command execution
> to only the one 'true' cvs executable.

I have used a wrapper script when necessary.

I've never set CVS_SERVER except as a quick hack to get something to
work temporarily (and yes I try to clean up my hacks, and did so in all
of those cases).

> In any case, you might want to look back at my original implementation
> of root.c. If a user explicitly forced a 'cvs -d cvs-spec' it would
> trash all the existing data in the CVS/Root file and replace it with
> the information on the -d option. Later users choose to replace this
> capability with one that will just ignore the CVS/Root contents by
> setting an environment variable. I'm not sure this is a better way for
> a user to use the tool or not, but at least it is flexible enough for
> most folks to use cvs.

Yes, I'm very well aware of the way your original implementation worked,
and with the changes that have been made to it subsequently.

Being able to arbitrarily (and indeed accidentally) change the server
information in CVS/Root is worse than not having the feature in the
first place.  At least in the current implementation only an explicit
'-d' will override CVS/Root -- that's about the safest way to allow an
override as it's the least likely to be accidentally used.  I would
prefer though if CVS/Root is going to stay as-is that another main
command parameter be added to allow a knowledgable user to overwrite
CVS/Root with new information given by '-d'.  That would save people
from having to write a lot of one-time command-line solutions (even
though on most platforms such a trick is quite easy to get right the
first time).

> I am of the school that believes that making a flexible tool is more
> useful than making one that is to restricted to be used in the wild.

What could be more flexible than an independent wrapper program?  Such a
program can literally do anything!

I think you need to learn to think more about software tools and their
use and think less about building all-in-one slicing dicing chopping
swiss-army knife applications....  :-)

> Your remarks lead me to believe you are of the other school of there
> being only one true way to design and implement anything. I guess we
> are always going to disagree on that one.

No, I just believe in building tools that can work together and that
each do one job to the best of their ability....  If you want a tool
that slices and chops, but not dices, then you can write a little
program that hooks a slicing tool and a chopping tool together in the
way you find most desirable.  That way you don't have to learn how to
turn the dicer off, and you won't accidentally dice anything that should
be sliced and chopped.

Please see:  "UNIX Style, or cat -v Considered Harmful", by Rob Pike;
USENIX Summer Conference Proceedings, 1983.  I agree with everything he
says in there entirely, and with most everything he's said on the same
subject since.  Despite the appearance of the word "UNIX" in the title,
the concepts therin are anything but "unix centric" -- it's a way of
thinking, not a doctrine enforced by a given type of system (though it
would be interesting to experiment with a system that could enforce such
stylistic attributes on one's tools! ;-).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>