Web Services Installer Design Doc
1 Restrucure web directories
1.1 New structure
/code/web
/public_php
/ams
/login (www)
/ring (www)
/tools (www)
/outpost (reserved, www private)
/stats (reserved, www private, needs replacement)
/admin (admin nel_tool)
/setup (*new*)
/api (from /code/web/api)
/app (from /code/web/app)
/webtt (from /code/www/public_php/webtt)
/private_php
/ams
/node_js (future use)
/sql (reference database dumps)
/docs
/ams (/code/ryzom/tools/server/ryzom_ams_docs)
/admin (/code/ryzom/tools/server/admin/docs)
1.2 Sources
/code/ryzom/tools/server/sql
/code/ryzom/tools/server/www
/code/ryzom/tools/server/admin
/code/ryzom/tools/server/ryzom_ams
/code/ryzom/tools/server/ryzom_ams_docs
/code/web/api
/code/web/app
1.4 Remove old stuff
/code/nelns/admin
/code/nelns/login_system/www
/code/nelns/login_system/database
2 Simplify Apache configuration
Everything under public_php goes into the public dir of the php host, and there shall be only ONE single host to configure for the web services.
3 User interaction installing web services
User installs apache2, php and mysql-server.
User adds himself to www-data group.
User simply drops all of the public and private php on his apache php server.
User sets www-data:www-data as owner of php files.
User browses to http://hostname/setup
Setup
4 Goals of the setup tool
Write all config.php files
Install all databases with user specific defaults
Setup also writes down locally a config file with the user’s last configurations (sexy format like json) so setup can be re-run without trouble.
Second phase: also be usable for database upgrades (so we provide diff .sql files when we do changes rather than change the full .sql dump)
Make it look sexy please (Just Bootstrap it)
No dependency at all on location of private_php.
There shall be NO config.php files etcetera existing in the repository (no repository files shall be overwritten at all by the setup), so that for an upgrade the user can simply overwrite ALL files on the webhost with the files on the repository without overwriting his own configuration (and rerun setup to perform an upgrade of databases if needed).
5 User interaction
5.1 Page to select modules
User is asked which tools to install, checkboxes for:
Core (login, etc)
Admin (admin)
AMS (ams)
5.2 Page with configuration
5.2.1 Basics
PHP Private directory (../private_php)
SQL Hostname (localhost)
SQL Username (root)
SQL Password ()
5.2.2 Core configuration
NeL Database name (nel)
5.2.3 Admin configuration
Admin Tool Database name (nel_tool)
(only on first setup) Admin username (can ignore this, just use default guest that's in the database sql dump for now)
(only on first setup) Admin password (can ignore this, just use default guest that's in the database sql dump for now)
5.2.4 AMS configuration
AMS Database name (core_ams?)
AMS User Database name (core_ams_user?)
AMS Admin username
AMS Admin password (see ams installer script how this works)
5.2.5 (only on first setup) Setup configuration
Setup password (to lock the setup with a password, in case we make it possible to have it re-run)
5.3 Page with installation result
User receives useful installation result messages, with nice green OK text for every installation step that went ok.
What needs to be done, basically...
There are scripts in /code/web/temp_cfg
config.php is the config that needs to be generated by the setup script, the setup generates this in public_php
admin/config.php and login/config.php need to be rewritten to grab the values from the main config.php, and moved back into public_php, so that these are not generated (only the main config.php will be generated)
There are sql database dumps in /code/web/sql
only nel and nel_tool need to be applied to the database
maybe create_webig as well
NOT ring_domain
The setup tool shall be under /code/web/public_php/setup/index.php and not depend on any other file than the config it may already have generated in case of config modifications