[clue-admin] CVS pserver access

[Jed S. Baer]

On Wed, 16 Mar 2005 11:16:23 -0500
Grant Johnson wrote:

> We use CVS here, and have many (150+) authorized to commit.   We use a 
> sandbox for our production snapshot.  
> Here is how:

Thanks for the input, but our environment is different from yours.

We have two projects. "website" is the live site. We use CVS as a content
management tool. There isn't anything happening in that project which one
would label as development/testing. Aside from content changes, it is
almost completely static. Commits to the website project are changes which
go immediately to the live site, with a few rare exceptions such as very
minor things such as spelling corrections which I might not publish until
there's some other major content update which needs to go live. The set of
people who have commit access here also need to be able to publish from
this repository right after changes are commited, without going through a
QA or change control cycle.

The other project is called "site_devel". It's where we're (slowly)
building a complete replacement for the current site. There will not be
"promotion to production", in the sense of an ongoing change management
cycle, until we get to the point of retiring the current production site
in favor of this one. Since this is purely a development project, there
isn't really a QA or change control cycle as such, except of course that
bugs will get fixed as things get tested. The release control cycle is
pretty much ad-hoc. Meaning that when some significant piece is stable
enough for volunteer testing, I (or somebody else) would issue a tag, and
publish the site to an accessible URL, which also generates a release
tarball. In between publishing, all updates need to be available to anyone
who wants to review the code.

In either case, I don't want to restrict commits, except some people who
have commit privilege on the website project might not have commit access
on the site_devel project, or vice-versa. We don't use tags in the website
project, and I don't yet see a need to restrict tagging in the site_devel
project, since only admins can publish anyway.

> To set up the anonymous access, simply put an entry for anonymous in the
> passwd file (mine is "anonymous::cvsuser") with no password.   The make 
> sure to put the anonymous ID in the readers file, and make sure it is 
> not in the writers file.   That is it.  Then to control who can put on 
> what tag, just go to my website(http://www.amadensor.com), and grab the 
> tools from there, and use them, of course, sharing back the things you 
> do to make them better. :)  I also have a tool there to allow users to 
> update their own pserver passwords via SSH, without requiring individual
> machine accounts.   Just set the tool as the login shell for a user with
> a published password.

I've setup CVS for anonymous access via pserver, using the instructions in
a book I found at the library. I think it was
http://www.elx.com.au/item/AW4206 "Multi-Tool Linux" -- it's instructions
were the same as yours, with some additional details on how to create the
Linux shell account for the anonymous user, and disallow pserver access
via having a shell account login -- all CVS access except anonymous
pserver checkout are via SSH on our server. The current problem, which I
haven't gotten back to working on, is that CVS chokes on checkouts by
anonymous. For one thing, it complains about not being able to find the
.cvsignore file, which I think is non-fatal, and then it complains that it
can't create its lockfile. I assume that means that the shell account
mapped to anonymous in the CVSROOT/passwd file has to be in a group having
write access to the repository, and so we rely on the readers file to
prevent commits. I just haven't gotten back to messing with it.

jed
-- 
http://s88369986.onlinehome.us/freedomsight/
Key fingerprint = B027 FEFB 4281 CC72 67D1  4237 F2D0 D356 077A A30E
... it is poor civic hygiene to install technologies that could someday
facilitate a police state. -- Bruce Schneier