This is Aolserver Made Easy!

AolserverMe provides an infrastructure around Aolserverto ease setup and configuration. The projects goal ist to make setting up Aolserver as easy or easier as the Apache Webserver.

Subpages

Areas of Concern

Startup

Aolserver acomplishes more or less the following steps at startup:

1. as root, preallocate the given tcp ports
2. start a Tcl-Interpreter and source in the main configuration file
   • a hierarchy of configuration parameters is built up
3. kill this Interpreter, only the configuration data remains
4. drop privileges, eventually chroot to the SERVER_HOME
5. load the dynamic (binary) modules
   • configured by the configuration data
6. source in all static (tcl) modules
   • also with access to the configuration data
   • locations: SERVER_HOME/tcl/* SERVER_HOME/modules/tcl/*
7. database pools?
8. initialize the interpreter threads
9. re-connect to the preallocated ports.
10. start serving from PAGE_ROOT Notes

Filesystem locations

Thus www see, that three locations have to be taken into account for reading and serving files:

• configuration files (/etc/aolserver4)
• dynamic modules (/usr/bin/aolserver4/modules)
• the SERVER_HOME and page root. If we want to maintain simplicity and allow chroot-ing we must keep the modules directory and the pageroot close under the SERVER_HOME. It must be noticed, that within one Aolserver process a number of virtual servers, each with its own pageroot and modules directory can be run, hencefore these must be separated into different directories.

Aolserver also will need to write to the filesystems, several types of write access come to mind:

• stderr/stdout of the server process
  • this should be captured to a logfile.
• error log
  • this is common for all virtual servers
• access logfiles per virtual server
• temporary files such as DAV-Locks
• file upload areas Finally we want to be able to run several aolserver processes on one computer, so the above must all be allocated at different locations in the file system.

Server and Directory Naming Scheme

Serverinstances:

each server process is uniquely named with a single name without whitespace. * The primary server is typically named main

Virtual Servers:

each virtual server inside a server process is named by its fully qualified domainname, * preferably without "www" at the start. This is called shortly a "Domain" as synonym for "Virtual Server".

Configuration Files:

reside inside /etc/aolserver4/instance, if a file main.tcl exists

• it is sourced, else if a file httpd.conf exists it is picked up by aolconf. example directory: /etc/aolserver/main

Domain Specific Configuration Files:

are named domain.ext and reside either in the

• instance directory or in a specific subdirectory of this if a separation is deemed necessary, e.g. with SSL-Certificatos or password files. ext may either be .conf, or indicate the purpose, e.g. .cgi.

run scripts (supervise):

 `/etc/aolserver4/`''instance''`/run`
`/etc/aolserver4/`''instance''`/log/run`

Logfiles:

non-chrooted:

/etc/aolserver4/instance/log/run/main -> /var/log/aolserver4/instance/log

chrooted:

/etc/aolserver4/instance/log/run/main -> /var/lib/aolserver4/instance/log

dynamic libraries:

/usr/lib/aolserver4/bin/

Globally used files before startup (chroot):

reside in /usr/share/aolserver4 these may englobe modules or template files which will be copied to a chroot environment.

Error logfiles for non-chrooted servers:

reside in :/var/log/aolserver4/instance.log

Access logfiles for non-chrooted servers:

/var/log/aolserver4/instance/domain/access.log

SERVER_HOMES:

/var/lib/aolserver4/instance/domain

Server Home

The server home holds all information regarding a specific virtual server, the following are relative to SERVER_HOME, inside a chrooted server they are relative to the root directory /

static modules:

tcl and modules/tcl/* Note the two possibilities to set up a specific module:

1. one file tcl/module.tcl

1. a collection of file in modules/tcl/module/, the file init.tcl is loaded from this directory commonly "standard" modules are put into the modules/tcl/* directories, while domain specific adaptions are stored in the tcl directory. error logfile:

log/error.log

supervise run log:

log/current

pid file:

log/pid

• the log directories allows to set permissions different from SERVER_HOME

cgi-files:

usr/bin/cgi-bin so config is similar to non-chrooted

• or domain/cgi-bin/

pageroot:

domain/www

temporary files:

domain`/tmp/_ _

modules specific files:

inside the directory domain/var/module/

access logfiles:

domainlog/access.log

Example:

• instance: main
• domain: example.com

/var/lib/aolserver4/main/:
                      example.com/www/ .. index.html ..
                      example.com/tcl/ .. pagewiz.tcl ..
                      example.com/log/access.log
                      example.com/tmp/ ..
                      example.com/var/http_auth/ .. pwd.cache ..
                      log/error.log
                      log/pid
                      modules/tcl/http_auth/ .. init.tcl ..

Startup Script Requirements

The startup scripts should acomplish the following requirements:

• supervise run script available
• sysv rc.d start/stop script available
• check database connectivity:
  • if a database is not available the server will not start
  • exclude the servers for which there is no connection but start the others
• create logfiles/directories on demand
• chroot/non-chroot option.
• checkonly option, eventually with log of all configuration parameters

• assemble the commandline (bind-parameter) according to the config-file Ideas:

• the database check functionality can be put into the aolserver startup/config interpreter

• use a tcl script to read the config and launch aolserver:
• aolserver4-start.tcl [supervise|sysv] [chroot] runs all instances defined in
• /etc/aolserver4/instance.tcl
• run script and /etc/init.d/aolserver4 make use of aolserver4-start.tcl
• /etc/default/aolserver4 holds the chroot option

Configuration file format

Should be:

• Easy to parse for Tcl
• Easy to read/write for humans
• have reasonable default values
• give opportunity to self-tune "everything"

• follow file-system standards Ideas:

• maintain a "database" for all know configuration options with data like

  • required/not required
  • sensible default value
  • global only/global and server/server only
• make parser a proper package so it can be re-used for launch script [wiki:self:/ConfigFileFormat Notes]