This section covers the available configuration variables, organized by servers. Take a look at Technical description to identify the different servers described here.
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.
Table of Contents
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.
|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|
This section includes the configuration of existing laboratories.
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.
|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?|
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).
These variables are simple variables which are general to the whole project.
|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.|
The Admin notifier is mainly used by the core server for notifying administrators of certain activity such as broken laboratories.
|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|
The session configuration is mainly used by the Core Server, but also by the Laboratory Server and by certain Experiment Servers.
|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|
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 variables for the Core server: what type of session, should we store students programs, etc.
|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.|
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.
|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”).|
Here you can customize the general web services consumed by the clients. Stuff like which ports will be used, etc.
|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|
The database configuration stores the users, groups, uses, etc.
|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|