Difference between revisions of "SoC new install script"

Latest revision as of 10:15, 8 February 2009

This project was implemented in the 2007 Google Summer of Code. The new install script is available since Geeklog 1.5.0. This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. Please see our ideas page for a current list of GSoC project ideas.

Incentive

By today's standards, Geeklog's installation process is somewhat archaic. The following steps are required:

1. Create an empty database.
2. Edit config.php, where you have to enter your database information, path to where Geeklog resides and, optionally, to your web root, as well as the URL of your site.
3. Edit lib-common.php so that it includes config.php.
4. Run the install script, where you have to enter the path to Geeklog again, and which will then populate the database.

Common problems that new users encounter include

• "What is the path I have to enter?"
• Failure to understand the relationship between the path (on the webserver) and the URL of the site.
• Parse errors in config.php and lib-common.php, caused by syntax errors because of missing quotes or semicolons or because of the use of inadequate editors.
• Troubleshooting in case something goes wrong: When to run the install script again (because the error occured before the database was populated) and when not to (because it was successful and only failed to display the "success" page because of a wrong path or URL).

Goals

The goal of this project is, obviously, to create a much more user friendly install script that avoids as many of the above issues as possible. Special care has to be taken, though, to make this as secure as possible.

Details

The install script will have to support both fresh installs with an initial database setup as well as upgrades where changes in the database layout (new fields or tables) will have to be worked into an exisiting database. It should also allow to import database backups to recover from problems and to ease migration of a site to a new server.

Must be tested and support the following:

• IIS and Apache webservers
• Unix and Windows server/directory/perms
• MySQL and MS SQL Databases
• Support for a separated Public and System or combined installation

Deliver a final solution that is well documented, well structured and commented code that is easy to maintain going forward.

User Interface

The install script should allow the user to enter the following information:

• Database information (name of database, db server, db username and password, table prefix)
• Path to Geeklog (i.e. location of config.php) and the webroot (public_html, in Geeklog's terminology)
• URL of the site
• Site email address (also used for the initial Admin user account)

As the paths and path/URL relationship are a constant source of confusion, the script should attempt to support the user to pick the correct values. It could derive this information from its environment (e.g. the current URL) and suggest changes to the user (e.g. if "public_html" is part of the URL or if the config.php is accessible from the web).

Geeklog comes with a separate script to check for correct file and directory permissions (so that e.g. the logfiles are writable) which should be incorporated into the install process and run automatically during the install.

Troubleshooting

In case an error occurs during the install or upgrade, the install script should assist the user as much as possible to identify the cause of the problem and whether to continue or to start over (so the script will have to keep track of its progress).

As parse/syntax errors will not occur anymore with to the new concept, the remaining issues the install script will have to cater for are

• Database problems (permissions, wrong database information, database not created, db server not running, ...)
• Path / URL problems

Upgrade

For the upgrade process, the install script should attempt to identify which Geeklog version the current database belongs to so that the user picks the correct upgrade. It could also offer to create a database backup before attempting the upgrade.

Plugins

Geeklog ships bundled with several plugins (currently: Calendar, Links, Polls, Spam-X, Static Pages). The tables and initial data for these plugins is included in the MySQL / MSSQL dump that is used to initialize the database on a fresh install. This makes it hard to bundle additional plugins or remove any of the current plugins from the install. The new install script should instead have a way to detect the presence of plugins and handle their install and upgrade independently.

Security considerations

config.php is Geeklog's central configuration file with well over 100 configuration options, including the database information (username and password). Making this file writable would be a considerable security risk and has to be avoided.

Likewise, lib-common.php is an important file that will be included by all the Geeklog script files. Geeklog's security relies on lib-common.php to include config.php and to do that in a manner that is not subject to manipulation (hard-coded to the actual path, preferrably).

In both cases (config.php and lib-common.php), a compromise must be found that makes the installation easier for the user while not putting the site at risk. For example, if the files have to be writable during the install, the site could refuse to load if they are still writable after the install.

Notes

The install process includes several bootstrapping / "chicken and egg" problems, as certain features can only be used when the correct path information is provided or when the database has been set up correctly. These should, however, not lead to code duplication if at all possible.