[OpenAFS] Re: CVS and AFS

[Derek R. Price]

Charles Karney wrote:

> We use CVS in a mixed Windows and Linux environment.  Recently we switched
> from accessing the CVS repository vis ssh to a Linux machine on which
> CVSROOT was a local disk to having the CVS repository in AFS and having all
> clients access this as a local file system.
>
> The motivation for this change was
>
> * to simplify user authentication;
> * to allow finer grain control over access to the repository.

People will often be flamed on this list for using a shared network drive containing a repository.  At _best_, if your
AFS software is good, you probably want to use ssh access to your Linux server which keeps the repository in AFS space.  Search
the mail archives for more.

If you want simplified authentiction you might consider the Kerberized CVS client, but I've never tried building it under
Windows.  Assuming you've been using Kerberos with AFS, you probably have most of the hooks in place.


> While things are basically working OK, we are running into some problems as
> I'd be interested in hearing other peoples' experiences.
>
> (1) Windows does loose matching on the case of filenames.  On one occasion
>     this has led to the filenames in the repository been "spontaneously"
>     changed.  The way this happened was (I think)
>
>     * On a Linux system, I did 'cvs remove NOTES.DOC', followed by
>       'cvs add Notes.doc', i.e., a 'safe' rename.
>     * On an NT system (using WinCVS 1.06), a user modifies NOTES.DOC (which
>       he still has checked out) and CVS apparently matches this with
>       Notes.doc in the repository and alters the repository name to
>       NOTES.doc when he checks this in.
>     * I do a 'cvs update' and am surprised to see NOTES.DOC resurrected.
>
>     It would seem that the Windows versions of CVS should try REALLY hard
>     not to do this.

It's possible that the Windows version of CVS doesn't know it is doing this.  More likely, the AFS client/server is saying, "sure
I have NOTES.DOC!"  when Notes.doc is requested, then assumes that the user really wants to write "Notes.doc" for a write.  This
is a basic problem with UNIX file shares being used form Windows.


> (2) If the CVS repository is an AFS and if access to the repository is
>     granted by virtue of an AFS token in the name of NAME@CELL, this name
>     should be used in the log messages instead of the possibly random
>     Windows (or Unix) user name.  Lots of the Windows checkins are by
>     'Administrator' which is not very informative.

Sounds like you'd like to use ssh or pserver access.  How is CVS supposed to know this is what you wanted and not that you'd
granted every user access to the AFS repository as user 'cvsdev' and you really wanted the Windows user ID in the logs?

If you're really in the mood to hack, and you don't want to maintain this yourself, you might try and start a discussion with
some of the folks who know GSSAPI or who are currently doing security work on bug-cvs@gnu.org.


> (3) If an NT user checked out administrative files in $CVSROOT/CVSROOT,
>     modifies one of them and checks it back in the latest release in
>     CVSROOT carries DOS conventions.  When accessing the repository from
>     Linux, I then get
>
>       cvs log: syntax error in /afs/sarnoff.com/common/cvs/CVSROOT/config: line '
> ' is missing '='
>
>     Either the Unix clients should care about foreign newline conventions
>     in $CVSROOT/CVSROOT/config, or the Windows clients should ensure that
>     these files have Unix newline conventions.

This is another common problem with network share access to a repository.  Any number of solutions have been proposed from the
CVS server "preserving" whatever line endings it finds to always using UNIX conventions.  Patches happily accepted.  Search the
list archives for more.


> (4) It's too bad that AFS's notion of machine-independent pathname doesn't
>     carry through to Windows.  Having to set up drive letter e.g., Z:
>     pointing to /afs/CELL/ breaks this notion and is so retro.  I'd like to
>     be able to use
>
>         :local:\\afs\CELL\common\cvs
>
>     instead of
>
>         :local:z:\common\cvs

Is this a Windows problem or a CVS problem?  If Windows, why are you telling me?  If CVS, have you tried converting back slashes
to forward slashes in your root specification?


> (5) Finally, we love to have network-level encryption of the data in AFS
>     files.  Is this on anyones radar screen?

Network level encrytion?  Shouldn't this be invisible to applications?

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@collab.net         CollabNet ( http://collab.net )
--
Take my advice, I don't use it anyway.