160 lines
6.7 KiB
Plaintext
160 lines
6.7 KiB
Plaintext
CVS port to VMS
|
|
|
|
DISCLAIMER: This port must be considered experimental. Although
|
|
previous versions have been in use at one large site since about
|
|
October, 1995, and the port is believed to be quite usable, various
|
|
VMS-specific quirks are known and the port cannot be considered as
|
|
mature as the ports to, say, Windows NT or unix. As always, future
|
|
progress of this port will depend on volunteer and customer interest.
|
|
|
|
This port is of the CVS client only. Or in other words, the port
|
|
implements the full set of CVS commands, but cannot access
|
|
repositories located on the local machine. The repository must live
|
|
on another machine (a Unix box) which runs a complete port of CVS.
|
|
|
|
Most (all?) work to date has been done on OpenVMS/AXP 6.2. Other VMS
|
|
variants might work too.
|
|
|
|
You will also need GNU patch installed on your system. Here's a list
|
|
of ftp servers which have VMS GNU resources, taken from
|
|
|
|
ftp://prep.ai.mit.edu/pub/gnu/vms.README
|
|
|
|
mvb.saic.com
|
|
wuarchive.wustl.edu
|
|
ftp.wku.edu
|
|
ftp.spc.edu
|
|
ftp.stacken.kth.se
|
|
|
|
Please send bug reports to bug-cvs@prep.ai.mit.edu.
|
|
|
|
As of CVS 1.5.something, this port passed most of the tests in
|
|
[.src]sanity.sh. I say "most" because some tests to not apply to the
|
|
CVS client. The tests were run by hand because the VMS POSIX shell
|
|
was incapable of running the script. The tests that sanity.sh
|
|
provides are not conclusive but at least provides some assurance that
|
|
the client is usable.
|
|
|
|
To compile, you will need DEC C (CC), DEC UCX, and of course DCL
|
|
installed on your machine. Just type "@build" in the top level
|
|
directory. This will build the sources in each subdirectory, and link
|
|
the executable [.src]cvs.exe
|
|
|
|
Copy the executable to an appropriate directory, and define the symbol "CVS"
|
|
in a .COM file which everyone running CVS will need to run. Here's an example
|
|
of what needs to be done.
|
|
|
|
$ CVS :== $YOUR_DEVICE:[YOUR.DIRECTORY.CVS]CVS.EXE
|
|
|
|
Accessing a remote repository can happen in several ways.
|
|
|
|
1. pserver
|
|
2. rsh - privileged (default)
|
|
3. rsh - unprivileged (on VMS side)
|
|
|
|
Here's how to do each of the above:
|
|
|
|
-------------------------------------------------------------------------------
|
|
1. pserver. This is the preferred way. It works just as it is
|
|
documented in the CVS manual (see the README file in the CVS
|
|
distribution for more information on the manual).
|
|
|
|
-------------------------------------------------------------------------------
|
|
2. Using CVS internal rsh support (privileged)
|
|
|
|
VMS's RSH is unusable for CVS's purposes (that is, the one in UCX.
|
|
Don't know about Multinet). However, there is code within CVS to
|
|
emulate RSH for purposes of contacting a CVS server "in the usual way"
|
|
via rshd. Unfortunately, this requires the VMS CVS client to be
|
|
installed with OPER privilege, by your system administrator.
|
|
|
|
RSH uses privileged ports and trusted software/hosts to determine
|
|
which user on the client side is trying to connect. Part of this
|
|
security is due to the fact that on VMS or UNIX, a non privileged
|
|
process is not permitted to bind a socket to a privileged port.
|
|
|
|
If rshd receives a connection on a non-privileged port, the connection is
|
|
immediately aborted. Only connections arriving from a privileged port will
|
|
be authenticated and served. The CVS client will therefore need privileges
|
|
under VMS to produce such a connection.
|
|
|
|
*** Please note that no careful examination has been done of the security
|
|
implications of installing CVS with the OPER privilege. If some hole
|
|
exists, then by doing so, you will enable users who are already on
|
|
your system to gain unauthorized privileges ***
|
|
|
|
-------------------------------------------------------------------------------
|
|
3. Using CVS internal rsh support (non-privileged)
|
|
|
|
There is a workaround, but this is one case where I think the cure is worse
|
|
than the disease. If you patch an rshd to not care that the RSH originating
|
|
port is "non-privileged", the CVS VMS client will allow you to define the
|
|
logical CVS_RCMD_PORT to the port number where this patched rshd will be
|
|
listening. I leave the talk of patching rshd to the gentle reader and his/her
|
|
friendly system administrator.
|
|
|
|
If I put an entry in my /etc/services file:
|
|
|
|
cvs_rcmd 4381/tcp cvs_rcmd
|
|
|
|
And add a line to /etc/inetd.conf, then restart inetd via "kill -1"
|
|
|
|
cvs_rcmd stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/cvs_rcmd
|
|
|
|
On the VMS side, you will have to do this:
|
|
|
|
$ define CVS_RCMD_PORT 4381
|
|
|
|
Then run CVS in the "usual way".
|
|
|
|
Note that the patched rshd will need to be invoked via inetd as root, so it can
|
|
authenticate and _become_ the intended user, the same as the regular rshd.
|
|
|
|
***Please note that you will be installing a security hole by doing this.***
|
|
|
|
Please also note that this security hole is no larger than allowing a
|
|
Macintosh, PC (OS/2, NT, etc.) to have it's hostname in any .rhosts file,
|
|
as any user can create a privileged socket without authentication, under these
|
|
environments. In fact, existing ports of CVS to these environment use this
|
|
to their advantage.
|
|
|
|
-------------------------------------------------------------------------------
|
|
Wildcard expansion is not yet implemented (i.e. CVS COMMIT *.c won't
|
|
work.) I think that expand_wild should be calling lib$findfile
|
|
(util.c in gzip is said to provide an example), but noone has gotten
|
|
around to implementing this.
|
|
|
|
Log messages must be entered on the command line using -m or -F. You
|
|
can use -e or define the logical EDITOR to cause CVS to try other
|
|
editors (TPU.EXE or any other editor which wants DCL command parsing
|
|
will not work) if you want to test what's available on your system. I
|
|
haven't tested this, but if you install vi or emacs, chances are it
|
|
will probably work. Just make sure the .EXE files are in a directory
|
|
listed in VAXC$PATH (is this a typo for DCL$PATH? Also, will a
|
|
logical name work?). If someone gets around to implementing it, we
|
|
should probably be using the callable editors (e.g. TPU$TPU), although
|
|
of course we also need interface(s) which are not locked into any
|
|
particular editors.
|
|
|
|
----------------------------------------
|
|
|
|
Notes regarding compiling on VAX/VMS 6.2 (not Alpha) (These are items
|
|
which hopefully will have cleaner solutions in the future, but here is
|
|
how to get around them for now):
|
|
|
|
* Need to compile lib/getdate.c with vaxc instead of decc to avoid a
|
|
compiler bugcheck. Therefore one must add SYS$LIBRARY:VAXCRTL/LIBRARY
|
|
to the link.
|
|
|
|
* In src/ignore.c, change lstat to stat. In vms/filesubr.c, change
|
|
"#ifdef S_ISLNK" to "#if 0".
|
|
|
|
* Ignore the warnings in vms/vmsmunch.c; the system include file
|
|
declares something as an int when it should be void *. Not *our*
|
|
fault!
|
|
|
|
Credits:
|
|
|
|
Initial VMS port by Benjamin J. Lee <benjamin@cyclic.com>, Cyclic
|
|
Software, October 1, 1995 (Update March 1, 1996).
|