Re: Bonsai

[James Henstridge <james jamesh id au>]

Are there any comments on this proposal?  Is there anything else that 
needs to be done to get the ball rolling?

James Henstridge wrote:

> Nat Friedman wrote:
>
> > Hi guys,
> >
> > Jeff, James and I were talking on IRC tonight about the lack of a Bonsai
> > setup for cvs.gnome.org.  Thanks to James, we have a partial ViewCVS
> > implementation, but it doesn't have a checkin database, and so we cannot
> > view the patches for a given commit.
> >
> > And our cvs commit emails include a broken bonsai URL in the footer.
> >
> > James said that he was willing to setup a ViewCVS checkin database so
> > that we could replicate the bonsai functionality we used to have, but he
> > doesn't have the machine access he needs to do this.
> >
> > I am just emailing as an advocate of having some kind of change-viewing
> > solution working, so that our CVS commits can be tracked more easily.
> > James says that there is a mysql setup on canvas already, so I think he
> > just needs bits to create a database and set that up.
> >  
>
> Owen suggested I post a follow-up to the gnome-infrastructure list 
> about what would be needed to get viewcvs set up such that it can 
> perform the CVS history queries (such as the ones we used bonsai for 
> in the cvs-commits-list emails).  Here is an example of what the 
> viewcvs query results look like:
>    http://www.gnome.org/~jamesh/viewcvs-query.html
>
> This provides pretty much the same information as Bonsai's results, 
> and the exact layout can be changed by altering the templates.
>
> As with Bonsai, there are two parts to be configured before we can use 
> the check-in database feature:
>
>    * configure the viewcvs CGI script to enable the feature and give
>      the details needed to log into the MySQL database.
>    * Set up the "loginfo handler" (a script CVS runs when someone makes
>      a commit) to add new checkins to the database.
>
> One of the other things that was brought up when this was discussed 
> before was moving all CGI programs off of cvs.gnome.org.  ViewCVS 
> should not cause a problem w.r.t. this.  It only needs read only 
> access to the CVS repository (which is already provided via NFS), and 
> the query feature just needs read only access to the MySQL database 
> holding the check-in data.  The only part that would need to run on 
> cvs.gnome.org is the loginfo handler.
>
> To try and get the ball rolling, here is a list of steps that could be 
> used to get everything set up:
>
>   1. if viewcvs is going to be moved over to www.gnome.org, create a
>      vhost (viewcvs.gnome.org, maybe?) and install viewcvs
>      appropriately.  This should be pretty easy to do since all the
>      gnome specific viewcvs customisations are held in CVS.
>   2. Create the mysql database.  Two database user accounts would be
>      needed -- a read-only one and one with write access.
>   3. Use viewcvs's "cvsdbadmin" script to populate the database with
>      our existing check-in history, and configure viewcvs so it can
>      connect to the database using the read only db account.  At this
>      point, we should be able to perform CVS history queries, but it
>      won't see new checkins.
>   4. On cvs.gnome.org, put a copy of the viewcvs loginfo-handler script
>      somewhere, and add a call to it from CVSROOT/loginfo.  This will
>      add new checkins to the database.
>   5. Run "cvsdbadmin update" to add any missing commits to the
>      database.  This will catch anything between the initial history
>      import and setting up the loginfo handler.
>
> To use the query database feature, the MySQL binding for Python will 
> need to be installed.  This package is included with Fedora/RHEL as 
> "MySQL-python", so installing it shouldn't add any administrative burden.
>
>
> One issue that Owen brought up was the loginfo handler in step (4).  
> When using CVS-over-SSH the loginfo handler is going to be run as the 
> user, and also writes the the database.  Therefore, all CVS users 
> would in theory be able to read the database password.  I can see 
> three possible ways to handle this:
>
>    * Do nothing.  Users can't run arbitrary commands on cvs.gnome.org,
>      and can't write to CVSROOT/ (which would be needed to get CVS to
>      run arbitrary commands on their behalf).  Also, the checkin
>      database contains no precious data -- it just caches some
>      information about the CVS repository which they already have write
>      access to.
>    * Use some kind of setuid wrapper around loginfo-handler so it does
>      its work as a different unprivileged user.
>    * Use Bonsai's loginfo handler (this is possible because viewcvs
>      shares Bonsai's database schema).  Bonsai's handler sends an email
>      containing the checkin information which is then read by another
>      script and added to the database, giving the same sort of
>      separation as using a setuid wrapper.
>
> Any comments on this?  I'd be willing to do some of the work or 
> provide instructions for others.  I can't get the process started 
> alone though since I don't have the required permissions, and we'd 
> need to know how this fits in with the system administration policies.
>
> James.
> _______________________________________________
> Gnome-infrastructure mailing list
> Gnome-infrastructure gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-infrastructure