httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: CVS Read-Only Solution
Date Wed, 13 Mar 1996 17:38:27 GMT
> 
> > Now edit your CVSROOT commitinfo file and add a line like:
> > 
> > ALL             $CVSROOT/CVSROOT/check_user
> > 
> > This defines a script to be run before a commit is authorized.  The 
> > check_user script should do something like:
> 
> We do all this anyway. I brought over the FreeBSD code that did access control
> long before cvs had it built in and I see no immediate reason to change at
> the moment since we don't need password authentication.
> 
> > Now, create a user id on your server machine called cvsuser.  Give this
> > user regular cvs priviledges but don't let the user log into the
> > server machine.  Stick an entry for him in your CVSROOT passwd file and
> > you are done.
> 
> Yep, this is what people are proposing.
> 
> > On the client side people should do:
> > 
> > cvs -d :pserver:cvsuser@hyperreal.com:/export/home/cvs login
> > 
> > Then they will be asked for the cvsuser password.
> > 
> > Once given they can do:
> > 
> > cvs -d :pserver:cvsuser@hyperreal.com:/export/home/cvs checkout apache
> > 
> > and from then on it will be transparent.  They simply cd into their
> > work directory and type: cvs update
> 
> Is this using a "real" server deamon? We don't run one at the moment and
> I haven't looked at that at all.

Actually, we do. This is how I run remote CVS ...

> > 
> > If the client tries to do a cvs commit, they will get the following
> > message:
> > 
> > cvs server: Pre-commit check failed
> > cvs [server aborted]: correct above errors first!
> 
> This is what happens now.
> 
> > 
> > I think this should cover concerns that Brian had regarding giving
> > anonymous shell access to hyperreal, and it precludes these anonymous
> > users from comitting any changes to the source tree.  It also isn't
> > completely anonymous in that people who wish to use this will have to
> > obtain the read-only cvsuser password.  But this could be something simple
> > and well-known.  
> 
> This is basically what is being proposed and doesn't require the
> use of cvs-1.7 authentication. It doesn't solve any of the problems I have,
> which are, there's no way to know who was using the system when something
> went wrong and there's no control over who can get access (the password
> will have to be given out pretty freely and can be passed around with no
> problems). It possibly circumvents the need to create a login in account
> by using a true server rather than rsh but that's something I've never 
> looked at.
> 
> > 
> > If you choose to implement this, I'll write up a concise step-by-step
> > client-guide for installing CVS and obtaining up-to-date snapshots.
> >
> 
> You can do this anyway for those new to using remote cvs or for that matter
> cvs in general. The issues are the same regardless of whether you have commit
> privs.

But it seems that with the current set up you _have_ to have commit privs in
order to be able to get Apache at all. This (I think) is only because checkouts
are logged. Is there any reason for this? If we _really_ must have it, can we
log checkouts in a seperate world-writeable file?

On the other hand, I really must (belatedly) agree that CVS is not a very good
way to let every T,D and H keep up to date with Apache. It would be nice for
selected people to have read access, tho.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message