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:
-
[positive]: allowed values are positive values starting from 0.
-
[string]: allowed values are strings. In fact, this setting can have any value.
-
[boolean]: allowed values are 0, no and false as negative values and 1, yes and true as positive values.
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.
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.
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.
Allows to configure where is running the central server
Af-Kernel.
Allows to configure port where is running central Af-Arch server:
Af-Kernel.
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.
Allows to configure where is located the database server port. This value can be left empty.
Allows to set the database name where is located the Af-Arch SQL data.
Allows to configure the database user login. This will be used to autenticate connections to the database.
Allows to configure the database user passowrd. This will be used to autenticate connections to the database.
Allows to configure how database access is performed. Currently, semantic supported are:
- permanent: makes all connections to be reused over and over again. This semantic creates all connections needed at the startup phase and share that connections between all threads accepting connections.
- close: makes all connections to be created and close every time a query is performed.
- refresh: makes all connections created at the startup time to be closed and reopened once the Af-Arch server detects an inactivity period of 1 hour.
Allows to set the file where the Af-Arch server logs will be stored. Logs at server side are generated using
AfGs Log module.
Allows to enable or disable log functionality at server side.
Allows to enable or disable user sessions mechanims.
Allows to configure how many time a user session is considered to be valid. Value provided must be measured in seconds.
Allows to configure how many time a user af-key is considered to be valid. Value provided must be measured in seconds.
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.
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:
-
stop: stops the running server until it is killed by the user.
-
backtrace: gets actual backtrace and prints it to the console and the exit.
-
none: do nothing, just exit.
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.
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.