Server configuration values reference

Introduction

This is the config settings reference available for all server. However, some values are only exclusive to be used by Af-Kernel central server.

Settings listed here can have several types of values to be assigned. These are:

Settings listed can be accessed using the API provided the AfGsConfig module.

All available config settings have indication about what type of values expect to accept.

Index

listening port [positive]

Port where the server is going to listen. Allowed values are 0 up to 65535 and auto.

If you use auto server will allocate the next port available.

listening hosname [string]

Allows to set the server hostname. This value will be used by Af-Arch clients to figure out where is located the server component.

You can also use auto and any value. In case of using auto Af-Arch will lookup for default server name. If you use any the Af-Arch server will be reached by any name the running host may have.

To set wrong this value have the implication that Af-Arch client will not be able to locate the server component.

server [string]

Allows to configure where is running the central server Af-Kernel.

kernel port [positive]

Allows to configure port where is running central Af-Arch server: Af-Kernel.

database server [string]

Allows to configure where is located the database server. The following information is used to configure abstract database connection which commonly is to a postgres server.

database port [positive]

Allows to configure where is located the database server port. This value can be left empty.

database name [string]

Allows to set the database name where is located the Af-Arch SQL data.

database user [string]

Allows to configure the database user login. This will be used to autenticate connections to the database.

database password [string]

Allows to configure the database user passowrd. This will be used to autenticate connections to the database.

database access semantic [string]

Allows to configure how database access is performed. Currently, semantic supported are:

log file [string]

Allows to set the file where the Af-Arch server logs will be stored. Logs at server side are generated using AfGs Log module.

log active [boolean]

Allows to enable or disable log functionality at server side.

sessions [boolean]

Allows to enable or disable user sessions mechanims.

session expiration [positive]

Allows to configure how many time a user session is considered to be valid. Value provided must be measured in seconds.

afkey expiration [positive]

Allows to configure how many time a user af-key is considered to be valid. Value provided must be measured in seconds.

host location check [boolean]

Value only valid at Af-Kernel server config.

Allows to activate host location check. This background process allows to check the location provided by Af-Arch servers. If a server is not found using location data provided by itself, Af-Kernel will remove it from the Af-Kernel registry.

This is useful to keep up to date host kernel location table.

on signal received [string]

Allows to set what action should be taken when a SIGSEGV signal is received.

Controls how signals are handler by Af-Arch servers. This allows to implement several politics allowing to debug, exit slowly or to print backtrace.

Allowed values are:

NOTE: "stop" value can be used for long running bugs allowing you to run gdb using attach command to debug the function which have received the signal, usually a SIGSEGV.

automatic register [boolean]

Every af-arch server needs to be registered against the central server: Af-Kernel This operation is done using the --update-services command line argument provided on every af-arch server. Obviously, this can be somekind tedious for some people who doesn't mind about controling when services are changing. This parameter doesn't applies to Af-Kernel central server because its especial behaviour, the Af-Kernel will just install itself.

One issue to keep in mind. Automatic registering process is only activated when central server responds that current server didn't been registed yet. But, once registered, if you add more services to your Af-Arch server, the registering process is still required for those new services, but it will not take place if you down use explicitily the --update-services command line option. This is because the current server has been already registered but the central server has no way to figure out if the already registered server has new services to be notified.