Arbit - project tracking

Arbit installer

This document discusses the creation of an installer for arbit, which can be easily used by new users to install and test arbit.

Target groups

The following target groups should be kept in mind when designing an installer:

• Shared-host users

  They are probably the largest, but also most problematic, group of users. Shared-hosts often do have strange setups and might not be accessible by shell. A web-installer is a must for them.

• Dedicated-server users

  They can already install arbit by executing some CLI commands. A simpler interface for installing and updating an arbit installation would be preferred, though.

• Administrators

  Administrators of multiple arbit instances or other web applications should be able to manage those smoothly. They are not our primary target for now.

Common use case

The most common use case to install arbit consists of a very few easy steps:

1. Download arbit installer package.

2. Copy package to shared host.

3. Call URL pointing to the installer.

4. Enter security code, to get access to the installer.

5. Enter the required data, check for required dependencies, click "Install".

6. Have access to an usable arbit instance.

Requirements

Our requirements generally match the requirements described by Christian Weiske in a blog post dedicated to PHP web application installers.

Our installer does not need to be skinnable from the start, but it would be nice, to make this kind-of reusable. Also for now we only need to support CouchDB, but support for relational database will also be required at some point. Using something like a Database Schema component seems to be the way to go there.

The full list:

Security

• Require creation of filhttp://docs.php.net/manual/en/book.phar.phpe to proceed with installation

  • Ask for install password that has been written in a non-webaccessible file on the server

• Lock installation tool to a single IP address

  • Remove write rights from whole application directory after installation, if wished even from config file

  • Make installer unavailable after installation

Check and verify system requirements

• Minimum PHP version

• PHP extensions

• safe_mode

• Session availability

• File upload settings (file_uploads, upload_max_filesize) and post_max_size, perhaps generating .htaccess with correct settings automatically

• Checking a list of required PHP functions, i.e. exec (disable_functions)

• Script time limit (max_execution_time)

• Allowed RAM size (memory_limit)

• Writability of directories and files, creating them if necessary (i.e. cache dirs)

Collecting configuration data

• Database settings

  • Support for different database systems

  • Importing an SQL dump from file

  • Creating the database, possibly with a different user that has admin rights

  • Checking for connectivity

• Setting directories i.e. for cache files

• Setting all kinds of other configuration options (select from array of options, true/false, integer with ranges, email addresses etc.)

• Defining default config values

• Titles and longer descriptions for config options

• Having mandatory and optional settings. Optional ones are skippable.

Interface

• Skinnable

• Wizard-based on multiple pages

• Command line (CLI) support, i.e. via ncurses or readline

• Translations

Ideas

PHAR archives are most probably the way to go, since they provide read access to the included files, and can also provide a web and CLI executable. The would make it possible to upload one single file and run the installer directly from that one.

This could easily satisfy the first two groups of users and provide implement the given use case. With enough command line options this could also enable mass administration of arbit installations.