Ticket #36 (new enhancement)

Opened 3 years ago

Last modified 7 months ago

Separate out installation of the OpenGuides software from installing a guide

Reported by: ivorw Assigned to: Nobody
Priority: normal Milestone:
Component: openguides Version: 0.51
Severity: normal Keywords:
Cc:

Description

Currently, the install of OpenGuides is tricky, and doesn't allow a great deal of flexibility:

  • Running more than one guide on the same host
  • Upgrading the software

It is proposed that the install process be split into two distinct steps:

./Build install # install the software, run as root

./Build guide # Ask all the config questions about setting up a guide

# Set up the wiki.conf, CGI and database tables, run as www-data

Thus a CPAN(PLUS) or Debian apt-get install will only install the software, and not any guides. This exact mechanism can be used for software upgrades with the minimum of human effort.

As a side effect, the test suite will need revising, as the answers to the config questions about databases will not be known at this point.

Currently, the test suite is run against all the supported database drivers found (MySQL, pg, SQLite). These are destructive tests that are run against the databases concerned, and could have a devastating effect if run against the real production database.

I propose that instead, there are two options for running the test suite, either minimally via an SQLite throwaway database (the default), or running the tests against the full range of databases on the target machine - a full test. To do this will involve another new build target:

./Build testconfig # probe system for database drivers, and get authentification info

Once testconfig has been run, the test suite will run against all test databases, and the schemae and test data will be torn down on completion, and also at the beginning if the databases appear non-empty.

A full test with testconfig against all database platforms is recommended before shipping releases.

Note, this change will also insist on making DBD::SQLite a prerequisite module.

Attachments

openguides-setup-db (1.3 kB) - added by dom on 11/23/05 15:26:45.
OpenGuides setup script

Change History

11/23/05 15:25:38 changed by dom

Incidentally, my Debian packages have always abstracted guides and the software install. The package sets up a default guide for people but it's easy to add more guides (this is done with a symlink farm when installing as a CGI (ie a symlink to /etc/openguides/$guide/wiki.conf and symlinks to /usr/lib/cgi-bin/openguides/*.cgi from the site's cgi-bin. When mod_perl is supported we can just use the OPENGUIDES_CONFIG environment variable (already supported)).

In my opinion the functionality you describe in ./Build guide should instead be a script - not something that relies on having the source package around. Any user should, given appropriate file permissions, be able to set up a guide.

I've written openguides-setup-db (attached) for this purpose on Debian. It doesn't actually configure it for you but just does the db setup, but this would be a good place to start (renamed openguides-setup or oven ogadm newguide for a more generalised command-line tool).

11/23/05 15:26:45 changed by dom

  • attachment openguides-setup-db added.

OpenGuides setup script

11/23/05 16:57:36 changed by dom

  • component set to openguides.

11/24/05 00:50:16 changed by ivorw

I'm inclined to agree. People will want to be able to add a guide after the build directories have been blown away completely. So, the install will deliver a setup script as part of the "executables" that get installed.

Any user should, given appropriate file permissions, be able to set up a guide.

I think that it's most appropriate for the webserver account to be used to set up new guides, as this will guarantee that the permissions will work. We would need to be careful of the security issues though.

Having said that, there's no reason why this command line script couldn't be turned into a CGI script, making the setting up and changing configuration of guides even easier.

11/24/05 12:51:16 changed by dom

What about suExec user CGI though? That's a policy decision and not something the software should be trying to enforce.

I'm not sure it's worth having the guide creation be a CGI script either. You are left with the problem of making that work in a CGI environment then. Though if the logic is separated out into a module which can be driven from the command line instead, I'm not fussed.

12/31/05 13:20:46 changed by ivorw

  • status changed from new to assigned.
  • owner set to ivorw.

In progress. Just the first bit - decoupling Build.PL from the config questions.

06/10/07 09:05:13 changed by dom

  • status changed from assigned to new.
  • owner changed from ivorw to Nobody.

01/28/08 15:21:35 changed by perigrin

Having talked about this (again) with Bob and Earl on IRC. I'd like to have a completely seperate create-openguide script or some such that Build.pl could just call when it was done installing stuff. (I don't know the intricacies of Build.pl but I do think I could figure it out using Module::Install if you'd be willing to accept a patch large enough to include changing the Build process).

This would as an added benefit leave a script lying about for those of us who host multiple guides so that we could just run create-openguide to build new guide installs.

01/28/08 15:30:18 changed by bob

All Build.Pl should say is that the user needs to run a separate script to create a guide. This will help with automatic testing.

the script that should probably ask the same questions as build.pl does currently. or take cli options.

It should also probably create the database.

I think all tests just use sqlite now in a local db this negates some of the concerns above. these days openguides mostly relies on wiki::toolkit to have tested your db connectivity .