Re: Bonsai

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  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:

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 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 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, create a
     vhost (, 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, 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,
     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.

Gnome-infrastructure mailing list
Gnome-infrastructure gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]