[Cvs-cvs] Changes to ccvs/README.VMS [cvs1-11-x-branch]

[Derek Robert Price]

Index: ccvs/README.VMS
diff -u /dev/null ccvs/README.VMS:1.11.8.1
--- /dev/null   Thu Sep  1 12:25:43 2005
+++ ccvs/README.VMS     Thu Sep  1 12:25:39 2005
@@ -0,0 +1,155 @@
+                             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.
+
+Provided that both your client and your server are recent (for
+example, CVS 1.9.27 or later), you shouldn't need GNU patch or any
+other executables other than CVS.EXE.
+
+Please send bug reports to address@hidden
+
+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!
+
+* Remove the #define's of mode_t in vms/vms.h and pid_t in vms/pwd.h.
+Add "#include <sys/types.h>" in vms/pwd.h.
+
+Credits:
+
+Initial VMS port by Benjamin J. Lee <address@hidden>, Cyclic
+Software, October 1, 1995 (Update March 1, 1996).