[clue-admin] CVS pserver access

[Grant Johnson]

Jed S. Baer wrote:

>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.
>  
>
I understand.   That is the point of using the tags.   One can commit 
everything, and look at it and say "Yes, I like it," then simply by 
tagging it, move it up to the server.   Also by doing this the way we 
have, we have, in some cases, allowed people to commit that we do not 
fully trust to put stuff on the server (they make too much broken code.)

>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
>  
>
I see, I did not realize that this was a complete replacement rather 
than a small upgrade thing.   In that case, a new module definitely 
makes sense.

>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.
>  
>
We also do not restrict commits.   We use the restriction on tagging to 
restrict publishing.   This way a CM person (or a site admin in your 
case) can publish without ever actually shelling on to the webserver.   
We have a mixed environment here, and this allows a CM person to do a 
migration to production from their Winders desktop through a GUI without 
ever touching SSH to log on to the production box.

>  
>
>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.
>
>  
>
The readers/writers files will prevent commits.  The user that anonymous 
executes as must have write access to the repository, but that user does 
not need to be able to log in (their shell can /bin/flase) In fact, we 
use one system user for all pserver access, and that user has no 
permission to log in at all.   I do not know if you can restrict users 
who have access via SSH and real system accounts from using pserver as 
well.  The bad thing about pserver is plain text equivelent passwords 
going across the network.   Not a big deal when the user has no write 
access, and no password anyway because you want it to be publicly viewable.

>jed
>  
>
I hope some of this insight from using CVS for a large project with many 
developers across several environments with some having adhoc releases 
(any developer can tag for dev, and it updates every minute on the 
minute) and some controled (only qa people can say things are ready to 
migrate to qa and be qa'ed, and only the cm and production support can 
say they are ready to go to production) helps you out conceptually.