Re: cvs stupid user problem, please help me debug
Lo, on Friday, February 22, Paul E Condon did write:
> I saved a cvs repository of personal programs in RedHat some time ago,
> before I discovered Debian. Now I'm trying install it and access the
> files in it. I used tar to save the whole repository as cvs.tgz. When
> I untar it, I discover that the permissions are wrong and the group
> assignment of the files is different from the Debian convention. So I
> set about to make them right for Debian, but I can't get it to work.
To which Debian convention are you referring? The numeric GIDs should
have shifted, but other than that, I'm not aware of any Debian
convention for ownership of files in a CVS repository. In fact, due to
the way CVS repositories work, such a convention would most likely be
counterproductive.
> First question: Debian uses "src" as the conventional group name for
> cvs internal files.
Granted, I've customized my repository pretty heavily, but I don't see
this:
[ankh-morpork:/var/cvs]$ /bin/ls -ld /var/cvs
drwxr-xr-x 4 root root 4096 Feb 10 2001 /var/cvs
[ankh-morpork:/var/cvs]$ /bin/ls -l /var/cvs
total 8
drwxrwxr-x 3 root cvsadmin 4096 Feb 13 2001 CVSROOT
drwxr-xr-x 10 cobbe cobbe 4096 Feb 6 21:08 cobbe
IIRC, I created the cvsadmin group, but the permissions on /var/cvs
seem to indicate that the group permissions just default to whatever's
appropriate for the user who created the repository.
Which version of CVS are you using? The above results are from
1.10.7-7, the version in potato.
> Second question: What permissions do I need to set? I've done
> chmod g+w *
> everywhere that there is a directory, but I still get these error
> messages when I try to checkout a sample program directory, e.g.:
While Debian and RedHat may have default groups that they use for CVS
repositories, this isn't reallly all that relevant. As long as all of
the CVS users have write access to the appropriate directories,
everything should work out.
Typically, one does this by manipulating the group ownerships and
permissions of the files in the repository. I'm assuming that you want
all-or-none access: each user can access either the entire repository or
none of the repository. (More finely-grained access controls are
possible, but they complicate the process somewhat.) I'm also assuming
a `local' or `ext' access method, as opposed to `pserver'.
I'll use two metavariables to make the explanation easier: $CVS_GROUP is
to the name of the group controlling CVS access, and $REPOSITORY is the
name of the directory which contains the repository files (e.g., where
you untarred your archived repository).
- addgroup $CVS_GROUP
- Use adduser to ensure that all of the appropriate users are in
$CVS_GROUP.
- chgrp $CVS_GROUP $REPOSITORY
- chmod g+ws $REPOSITORY
## The setgid bit is crucial.
- find $REPOSITORY -print | xargs chgrp $CVS_GROUP
## Make everything owned by the CVS group.
- find $REPOSITORY -type d -print | xargs chmod g+ws
## Make all directories group-writable and setgid.
Make sure that you're running in $CVS_GROUP (you may need to log out and
log back in), and you should be good to go.
(If you don't understand what all of the above does or why you're doing
it, please ask. That understanding will help you deal with other
repository problems later on.)
> pecondon@big:~/co$ cvs co hello
> cvs checkout: warning: cannot write to history file
> /var/lib/cvs/CVSROOT/history: Permission denied
> cvs checkout: Updating hello
> cvs checkout: failed to create lock directory for `/var/lib/cvs/hello'
> (/var/lib/cvs/hello/#cvs.lock): Permission denied
> cvs checkout: failed to obtain dir lock in repository
> `/var/lib/cvs/hello'
> cvs [checkout aborted]: read lock failed - giving up
> pecondon@big:~/co$
Yeah. User pecondon doesn't have write access to the repository
directory. The above process should fix this.
HTH,
Richard
Reply to: