Table of Contents
- Introduction
- Installation

  | · Introduction · Windows installation · UNIX installation · Starting the Server · Directory Structure

- Handling Challenger
- Virtual Servers
- Configuration Examples
- Modules
- Filesystems
- RXML Tags
- Graphics
- Proxy
- Databases
- Miscellaneous Modules
- Security Considerations
- Scripting
- Frontpage
- Upgrading
- Third Party Extensions
- Portability
- Reporting Bugs
- Appendix

Directory Structure
Challenger will always run with the `server/` directory as current directory. All relative paths will have this directory as their origin.

Directories
`server/` contains the read-only program files. When Challenger is upgraded the server directory with all its contents will be replaced. The files in `server/` should be left alone, otherwise important customizations might be lost when upgrading.

`server/start` is the script used to start Challenger.

`server/install` is the script used to install a new Challenger.

`server/bin/` contains binaries.

`server/modules/` contains the modules for that release of Challenger. Do not install your own modules here, put them in `local/modules/` instead. The directories where Challenger looks for modules can be configured in Global Variables/Module directories.

`server/nfonts/` contains fonts for the graphics capabilities of Challenger. Do not install your own fonts here, put them in `local/fonts/` instead. The directories where Challenger looks for fonts can be configured in Global Variables/Fonts....

`server/rxml_packages/` contains RXML packages that are included in the distribution.

`local/` is reserved for locally installed modules, fonts etc. It will never be touched by an upgrade procedure.

`local/modules/` preferred location for your own or third party modules.

`local/fonts/` preferred location for your own fonts.

`local/rxml_packages/` preferred location for your own or third party RXML packages.

`logs/` is the location for log files, unless changed with the `log-dir` option for the start script or the Global Variables/Log directory prefix variable. Several Challenger servers can share the same log directory.

`logs/debug/` contains the debug logs, one log for each Challenger server named after the configuration directory used by the specific server. The debug logs are rotated at each restart. The current debug log will always be called ``servername`.1`, the last ``servername`.2` ... until ``servername`.5`. The debug messages can be sent to syslog instead by changing the Global Variables/Logging method variable.

`logs/<virtual server name>/Log` is the default name for the access log for that Virtual Server. What is logged and where it is logged can be changed in the Server Variables/Logging.. variables.

`logs/<virtual server name>/Accessed.db` and `Accessed.names` are the access database files used by the <doc>`{accessed}`</doc> tag. Whether the <doc>`{accessed}`</doc> tag should be enabled and in that case where the database files should be stored can be configured in the Main RXML parser module.

`configurations/` is the default location for the configuration files, and can be changed by the `config-dir` option for the start script. This directory must be unique for each Challenger server. The configuration file format is undocumented and may be changed in future releases. A Challenger running on unix will reload its configuration files if it receives a SIGHUP signal.

`gtext_cache/` is the cache directory for the graphical text tag. It can be shared by several Challenger servers.

`platform/` contains the extra modules used by the full Roxen Platform. Like the `server/` directory, this will be replaced when doing an upgrade, so it should be considered read-only.

Pike
`bin/` contains the binaries for Pike and hilfe, the interactive Pike front end. The Pike executable is also hard linked as roxen so that it will appear with that name when you use the `ps` command.

`include/pike/` contains C include files for making Pike modules.

`lib/pike/include/` contains include files available in Pike programs.

`lib/pike/modules/` contains Pike modules available in Pike programs. The `.so` files are modules written in C, the `.pmod` files are modules written in Pike. If the Pike interpreter is compiled statically, which is always the case for the Windows version, the C modules will be compiled into the Pike binary instead.

`lib/pike/master.pike` is the master class for pike that controls a lot of Pike's behavior. For example how Pike classes are loaded.