SoC new install script - Revision history

Dirk: Added a note that this has already been implemented

2009-02-08T10:15:38Z

Added a note that this has already been implemented

Blaine: /* Details */

2007-03-24T19:01:22Z

‎Details

Blaine: /* Details */

2007-03-24T18:58:59Z

‎Details

Dirk: Backlink

2007-03-08T11:52:54Z

Backlink

Dirk: Categories

2007-03-08T11:36:25Z

Dirk: SoC: New install script

2007-02-25T16:34:37Z

SoC: New install script

New page

== Incentive ==

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

# Create an empty database.
# 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.
# Edit lib-common.php so that it includes config.php.
# 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.

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

← Older revision		Revision as of 10:15, 8 February 2009
Line 1:		Line 1:
−	~~<center>(~~This is ~~an idea page~~ for the [[Google Summer of Code]]~~)</center>~~	+	This project was implemented in the 2007 Google Summer of Code. The new install script is available since [http://www.geeklog.net/article.php/geeklog-1.5.0 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 [[Google Summer of Code\|ideas page]] for a current list of GSoC project ideas.

← Older revision		Revision as of 19:01, 24 March 2007
Line 34:		Line 34:
	* Support for a separated Public and System or combined installation		* 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 ===		=== User Interface ===

← Older revision		Revision as of 18:58, 24 March 2007
Line 27:		Line 27:

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

← Older revision		Revision as of 11:52, 8 March 2007
Line 1:		Line 1:
		+	<center>(This is an idea page for the [[Google Summer of Code]])</center>
		+
		+
	== Incentive ==		== Incentive ==

← Older revision		Revision as of 11:36, 8 March 2007
Line 72:		Line 72:

	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.		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.
		+
		+
		+	[[Category:Summer of Code]] [[Category:Development]]