Opened 12 years ago

Closed 4 years ago

#36 closed enhancement (duplicate)

Separate out installation of the OpenGuides software from installing a guide

Reported by: Ivor Williams Owned by: bob
Priority: high Milestone:
Component: openguides Version: 0.51
Severity: major Keywords: install migrated


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 (1)

openguides-setup-db (1.3 KB) - added by Dominic Hargreaves 12 years ago.
OpenGuides setup script

Download all attachments as: .zip

Change History (12)

comment:1 Changed 12 years ago by Dominic Hargreaves

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).

Changed 12 years ago by Dominic Hargreaves

Attachment: openguides-setup-db added

OpenGuides setup script

comment:2 Changed 12 years ago by Dominic Hargreaves

Component: openguides

comment:3 Changed 12 years ago by Ivor Williams

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.

comment:4 Changed 12 years ago by Dominic Hargreaves

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.

comment:5 Changed 11 years ago by Ivor Williams

Owner: set to Ivor Williams
Status: newassigned

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

comment:6 Changed 10 years ago by Dominic Hargreaves

Owner: changed from Ivor Williams to Nobody
Status: assignednew

comment:7 Changed 9 years ago 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 could just call when it was done installing stuff. (I don't know the intricacies of 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.

comment:8 Changed 9 years ago 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 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 .

comment:9 Changed 5 years ago by bob

Keywords: install added
Owner: changed from Nobody to bob
Priority: normalhigh
Severity: normalmajor

comment:10 Changed 4 years ago by bob

Keywords: migrated added

migrated but has useful info still in this ticket.

comment:11 Changed 4 years ago by bob

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.