Configuration variables

This section covers the available configuration variables, organized by servers. Take a look at Technical description to identify the different servers described here.

Note

At the time of this writing, not all the variables have been documented. We’re working on this (June 2016). Take into account that these variablse are the type of variables you’ll find in the .py configuration files. They are not variables for commands.

Laboratory Server

The laboratory server is closer to the experiment server and checks if it is alive, maintains the sessions and acts as a bridge between the pool of core servers and the experiments.

General

Property Type Default value Description
laboratory_session_type basestring Memory What type of session manager the Core Server will use: Memory or MySQL.
laboratory_session_pool_id basestring LaboratoryServer See “core_session_pool_id” in the core server.
laboratory_assigned_experiments list   List of strings representing which experiments are available through this particular laboratory server. Each string contains something like ‘exp1|ud-fpga|FPGA experiments;fpga:inst@mach’, where exp1|ud-fpga|FPGA experiments is the identifier of the experiment, and “fpga:inst@mach” is the WebLab Address of the experiment server.
laboratory_exclude_checking list [] List of ids of experiments upon which checks will not be run

Experiments

This section includes the configuration of existing laboratories.

HTTP

The HTTP experiment is a type of unmanaged laboratory which enables you to develop your own laboratory. WebLab-Deusto will call certain methods in that laboratory, and your laboratory will act taking that into account.

Property Type Default value Description
http_experiment_url basestring   The base URL for the experiment server. Example: ‘http://address/mylab/’ will perform requests to ‘http://address/mylab/weblab/
http_experiment_username basestring None The username used for performing that request. If not present, it will not use any credentials (and it will assume that the server is filtering the address by IP address or so).
http_experiment_password basestring None The password used for performing that request. If not present, it will not use any credentials.
http_experiment_batch bool False Does the system manage its own scheduling mechanism? If so, users requesting access will automatically be forwarded, and it is the experiment server the one who has to manage what to do with them.
http_experiment_api basestring None The API is calculated automatically. However, you may force a particular API (such as 0, which is the oldest one).
http_experiment_extension basestring None Is it using the standard routing system provided? Or is it using something like ‘.php’ in all the files?
http_experiment_request_format basestring json What format should be used for performing the request? JSON directly? Or standard http form?

Common configuration

These variables affect all the servers. For instance, certain servers use a session manager (e.g. the Core server for users, but also the Laboratory server).

General

These variables are simple variables which are general to the whole project.

Property Type Default value Description
debug_mode bool False If True, errors and exceptions are shown instead of generic feedback (like WebLabInternalServerError)
server_admin basestring None WebLab-Deusto administrator’s email address for notifications. See Admin Notifier settings below.
server_hostaddress basestring   Host address of this WebLab-Deusto deployment
propagate_stack_traces_to_client bool False If True, stacktraces are propagated to the client (useful for debugging).
facade_timeout float 0.5 Seconds that the facade will wait accepting a connection before checking again for shutdown requests.

Admin Notifier

The Admin notifier is mainly used by the core server for notifying administrators of certain activity such as broken laboratories.

Property Type Default value Description
mail_notification_enabled bool   Enables or Disables mail notifications
mail_server_host basestring   Host to use for sending mail
mail_server_helo basestring   Address to be used on the mail’s HELO
mail_server_use_tls basestring no Use TLS or not. Values: ‘yes’ or ‘no’
mail_notification_sender basestring   Address of the mail’s sender
mail_notification_subject basestring [WebLab] CRITICAL ERROR! (Optional) Subject of the notification mail

Sessions

The session configuration is mainly used by the Core Server, but also by the Laboratory Server and by certain Experiment Servers.

Property Type Default value Description
session_sqlalchemy_engine basestring mysql Database engine used for sessions the database. Example: mysql
session_sqlalchemy_host basestring localhost Location of the sessions database server
session_sqlalchemy_port int None Location of the sessions database server
session_sqlalchemy_db_name basestring WebLabSessions Database name of the sessions database
session_sqlalchemy_username basestring   Username for connecting to the sessions database
session_sqlalchemy_password basestring   Password for connecting to the sessions database
session_lock_sqlalchemy_engine basestring mysql Database engine used for locking the database. Example: mysql
session_lock_sqlalchemy_host basestring localhost Location of the locking database server
session_lock_sqlalchemy_port int None Location of the locking database server
session_lock_sqlalchemy_db_name basestring WebLabSessions Database name of the locking database
session_lock_sqlalchemy_username basestring   Username for connecting to the locking database
session_lock_sqlalchemy_password basestring   Password for connecting to the locking database
session_manager_default_timeout int 7200 Maximum time that a session will be stored in a Session Manager. In seconds.
session_memory_gateway_serialize bool False Sessions can be stored in a database or in memory. If they are stored in memory, they can be serialized in memory or not, to check the behaviour

Core Server

This configuration is used only by the Core servers. The Core server manages the scheduling, life cycle of the users, the sessions, and the incoming web services calls. Note that there is other common configuration which affects the Core server, so also take a look at the Common Configuration in this document.

General

General variables for the Core server: what type of session, should we store students programs, etc.

Property Type Default value Description
core_server_url basestring   The base URL for this server. For instance, http://your-uni.edu/weblab/
core_universal_identifier basestring 00000000 Unique global ID for this WebLab-Deusto deployment. Used in federated environments, where multiple nodes register each other and do not want to enter in a loop. You should generate one (search for online GUID or UUID generators or use the uuid module in Python).
core_universal_identifier_human basestring WARNING; MISCONFIGURED SERVER. ADD A UNIVERSAL IDENTIFIER Message such as ‘University A’, which identifies which system is using performing the reservation. The unique identifier above must be unique, but this one only helps debugging.
core_session_type basestring Memory What type of session manager the Core Server will use: Memory or MySQL.
core_session_pool_id basestring UserProcessingServer A unique identifier of the type of sessions, in order to manage them. For instance, if there are four servers (A, B, C and D), the load of users can be splitted in two groups: those being sent to A and B, and those being sent to C and D. A and B can share those sessions to provide fault tolerance (if A falls down, B can keep working from the same point A was) using a MySQL session manager, and the same may apply to C and D. The problem is that if A and B want to delete all the sessions -at the beginning, for example-, but they don’t want to delete sessions of C and D, then they need a unique identifier shared for A and B, and another for C and D. In this case, “UserProcessing_A_B” and “UserProcessing_C_D” would be enough.
core_store_students_programs bool False Whether files submitted by users should be stored or not.
core_store_students_programs_path basestring None If files are stored, in which local directory should be stored.
geoip2_city_filepath basestring GeoLite2-City.mmdb If the maxminds city database is downloaded, use it
geoip2_country_filepath basestring GeoLite2-Country.mmdb If the maxminds country database is downloaded, use it
local_city basestring None Local city (e.g., if deployed in Bilbao, should be Bilbao). This is used so WebLab-Deusto uses it for resolving local IP addresses
local_country basestring None Local country, in ISO 3166 format (e.g., if deployed in Spain, should be ES). This is used so WebLab-Deusto uses it for resolving local IP addresses
ignore_locations bool False Ignore the locations system (and therefore do not print any error if the files are not found)
logo_path basestring client/images/logo.jpg File path of the logo.
logo_small_path basestring client/images/logo-mobile.jpg File path of the small version of the logo.

Scheduling

This is the configuration variables used by the scheduling backend (called Coordinator). Basically, you can choose among redis or a SQL based one, and customize the one selected.

Property Type Default value Description
core_coordination_impl basestring sqlalchemy Which scheduling backend will be used. Current implementations: ‘redis’, ‘sqlalchemy’.
core_coordinator_db_host basestring localhost Host of the database server.
core_coordinator_db_port int None Port of the database server.
core_coordinator_db_name basestring WebLabCoordination Name of the coordination database.
core_coordinator_db_username basestring   Username to access the coordination database.
core_coordinator_db_password basestring   Password to access the coordination database.
core_coordinator_db_engine basestring mysql Driver used for the coordination database. We currently have only tested MySQL, although it should be possible to use other engines.
core_coordinator_laboratory_servers list   Available laboratory servers. It’s a list of strings, having each string this format: “lab1:inst@mach;exp1|ud-fpga|FPGA experiments”, for the “lab1” in the instance “inst” at the machine “mach”, which will handle the experiment instance “exp1” of the experiment type “ud-fpga” of the category “FPGA experiments”. A laboratory can handle many experiments, and each experiment type may have many experiment instances with unique identifiers (such as “exp1” of “ud-fpga|FPGA experiments”).

Facade

Here you can customize the general web services consumed by the clients. Stuff like which ports will be used, etc.

Property Type Default value Description
core_facade_server_route basestring default-route-to-server Identifier of the server or groups of servers that will receive requests, for load balancing purposes.
core_facade_bind basestring   Binding address for the main facade at Core server
core_facade_port int   Binding address for the main facade at Core Server

Database

The database configuration stores the users, groups, uses, etc.

Property Type Default value Description
db_host basestring localhost Location of the database server
db_port int None Port where the database is listening, if any
db_database basestring WebLab Name of the main database
db_engine basestring mysql Engine used. Example: mysql, sqlite
db_echo bool False Display in stdout all the SQL sentences
db_pool_size int 5 Maximum number of spare connections to the database.
db_max_overflow int 35 Maximum number of connections to the database.
weblab_db_username basestring weblab WebLab database username
weblab_db_password basestring   WebLab database user password
weblab_db_force_engine_creation bool False Force the creation of an engine each time