-
Notifications
You must be signed in to change notification settings - Fork 11
Testbed Runtime 0.9
The Testbed Runtime version 0.9 is a complete rewrite of the basic architecture. While some code from TR 0.8 and older is reused (e.g., drivers, APIs) most of the architecture was redesigned and implemented from scratch to be more clean and comprehensible, extensible, and fast. This document aims to provide a comprehensive overview over the general architecture, as well as on how to install and configure Testbed Runtime.
The probably quickest way to install Testbed Runtime is to install it as a Debian package, using apt-get/aptitude. In order to do this you first need to add the Debian repository to apts sources:
wget -O - http://dev.itm.uni-luebeck.de/debian-repo/testbed-runtime-repo.gpg.key | apt-key add -
cd /etc/apt/sources.list.d
wget http://dev.itm.uni-luebeck.de/debian-repo/testbed-runtime.list
Then, you can install TRs portal and/or gateway service simply by running
apt-get install tr.iwsn-portal
or
apt-get install tr.iwsn-gateway
As TR is writen (almost) purely in Java it is easy and feasible to run TR on every platform that supports Java. Unfortunately, we don't provide ready-to-install-and-run packages for other system than Debian. In order to run TR manually (without any kind of service wrapper) you can simply run it by passing the executable JAR to the Java VM, together with a configuration file (see below for more info on configuring):
java -jar tr.iwsn-portal-0.9-server.jar --logLevel INFO --config portal.properties
and
java -jar tr.iwsn-gateway-0.9-server.jar --logLevel INFO --config gateway.config
The configuration of a testbed installation typically involves one or more (depending on the scenario) configuration files for the portal server and one configuration file that is equal to all gateway hosts.
In order to display all configuration options (including a bit of documentation) please run:
java -jar tr.iwsn-portal-0.9-SNAPSHOT-server.jar --helpConfig
for the portal server, or
java -jar tr.iwsn-gateway-0.9-SNAPSHOT-server.jar --helpConfig
for the gateway process. This will print out all available configuration parameters including a short description of their meaning.
Below, you'll find a more structured and detailed description on how to configure the invidual modules of Testbed Runtime.
Testbed Runtime consists of several modules, each providing a certain public or internal functionality and/or API. The most important modules are:
- the
Reservation Systemservice (RS), - the
Sensor Network Authentication and Authorization (SNAA)service, - the DeviceDB, and
- the WiseGui web front-end.
Most components take some basic parameters like the URI/Web server context path a service will be available on. Besides these
- RS and DeviceDB (an internal component storing configurations for IoT devices) can both be configured to use different types of persistence layers for it's reservation data,
- SNAA can be configured to use different authentication mechanisms, and
- WiseGui service takes several configuration parameters on how to present the GUI.
Below, you'll find several subsections, each describing in detail the configuration options of the corresponding component.
In order to configure which authentication backend to use you have to configure the following property to be eiter "DUMMY", "JAAS", "SHIRO", or "REMOTE":
# Usage: The authentication backend of the SNAA service
# Example: DUMMY/JAAS/SHIRO/REMOTE
snaa.type =
The dummy backend simply authenticates and authorizes every user request. Basically, it is a "return true" implementation. Typically this SNAA configuration is used on personal desktop-size testbeds, during development or if no access controls have to be made.
If JAAS is chosen as backend the SNAA implementation will delegate authentication and authorization to the standardized Java Authentication and Authorization System (JAAS). The following two parameters suffice here:
# Usage: The JAAS backends configuration file (only if JAAS is used)
snaa.jaas.config_file =
# Usage: The login module for the JAAS backend (only if JAAS is used)
# Example: edu.internet2.middleware.shibboleth.jaas.htpasswd.HtpasswdLoginModule
snaa.jaas.loginmodule =
As an example we'll use the well-known .htpasswd files used in the Apache HTTP servers. To use them, please put the following properties into the portals configuration file:
snaa.type = JAAS
snaa.jaas.config_file = snaa.jaas
snaa.jaas.loginmodule = HtpasswdFile
The property snaa.jaas.loginmodule points to the name of the JAAS module defined within with the snaa.jaas configuration file. ```snaa.jaas```` itself has the following content:
HtpasswdFile {
edu.internet2.middleware.shibboleth.jaas.htpasswd.HtpasswdLoginModule REQUIRED
htpasswdFile = "snaa.htpasswd";
};
The file snaa.htpasswd is standard-conform .htpasswd file that you can administer using e.g., the htpasswd command line utility.
For more information about JAAS and how it works, please refer to the corresponding documentation by Oracle.
The Shiro backend uses the Apache Shiro framework to perform authentication and authorization against a relational database schema using the JPA O/R mapper. Please configure the following properties to use ShiroSNAA:
# Usage: The number of iterations to be run for the hash algorithm to be used with Shiro authentication and authorization backend (only if SHIRO is used)
# Example: 1000
# Default value: 1000
#snaa.shiro.hash_algorithm.iterations = 1000
# Usage: The name of the hash algorithm to be used with Shiro authentication and authorization backend (only if SHIRO is used)
# Example: SHA-512
# Default value: SHA-512
#snaa.shiro.hash_algorithm.name = SHA-512
# Usage: The JPA (Hibernate) .properties file for the Shiro authentication and authorization backend (only if SHIRO is used)
snaa.shiro.jpa.properties_file =
The property snaa.shiro.jpa.properties_file has to point to a configuration file that contains all necessary information for the JPA framework to connect to the database. It must e.g., follow this example configuration properties:
hibernate.connection.url = jdbc:mysql://localhost:3306/tr_snaa
hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.dialect = org.hibernate.dialect.MySQLDialect
hibernate.hbm2ddl.auto = update
hibernate.connection.username =
hibernate.connection.password =
The properties within this file will be passed to the Hibernate persistence provider upon startup. For more documentation about the allowed configuration parameters please read the Hibernate documentation.
It is possible to start the SNAA system as a separate process, not embedding it into the portal process. In this case the portal will use the SNAAs services by doing SOAP Web service calls to the remote endpoint. In order to realize this behavior please set the following property:
# Usage: The URI of the remote SNAA server (only if REMOTE is used)
# Example: http://localhost:8890/soap/v3/snaa
snaa.remote.uri =
The only thing that has to be configured for the RS is the type of persistence layer ("backend") you want to use:
# Usage: Persistence layer to use
# Example: GCAL/JPA/IN_MEMORY/REMOTE
# Default value: IN_MEMORY
#rs.type = IN_MEMORY
# Usage: Persistence layer configuration .properties file
rs.jpa.properties =
The property rs.jpa.properties points to another .properties file containing the Hibernate configuration properties for the RS database (cf. SNAA JPA backend configuration). Below is a sample configuration for the RS:
hibernate.connection.url = jdbc:mysql://localhost:3306/tr_rs
hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.dialect = org.hibernate.dialect.MySQLDialect
hibernate.hbm2ddl.auto = update
hibernate.connection.username =
hibernate.connection.password =
The properties within this file will be passed to the Hibernate persistence provider upon startup. For more documentation about the allowed configuration parameters please read the Hibernate documentation.
# Usage: The username of the Google account to be used (only if GCAL is used)
rs.gcal.username =
# Usage: The password of the Google account to be used (only if GCAL is used)
rs.gcal.password =
No additional configuration necessary. Please note that this "persistence layer" is in fact non-persistent as its contents will be lost upon restarting the portal process. Can be used if you either don't need to maintain a real reservation database in your testbed or e.g., during development / debugging.
The DeviceDB is the central configuration database of your testbed installation in which all device configurations (such as timeouts, node type, node address, ...) are looked up during runtime. E.g., if a gateway detects a new USB device attached to one of it's USB / serial ports it will try to recognize the device type and identifier and look up a matching configuration in the DeviceDB. If found, the gateway will then connect to the device to have it ready for experimentation.
Once setup the DeviceDB can be administered using the DeviceDB front-end running at http://YOUR_PORTAL_HOST/admin/devicedb. This site is password-protected using HTTP basic authentication (see section about admin UI).
Other than that, the following parameters need to be set to configure the DeviceDB persistence back-end:
# Usage: The type of DeviceDB backend
# Example: IN_MEMORY/JPA/REMOTE/SMARTSANTANDER
# Default value: IN_MEMORY
#devicedb.type = IN_MEMORY
# Usage: The context path on which to run the device database REST API
# Example: /rest/v1.0/devicedb
# Default value: /rest/v1.0/devicedb
#devicedb.rest_api.context_path = /rest/v1.0/devicedb
# Usage: The context path on which to run the device database web frontend
# Example: /devicedb
# Default value: /devicedb
#devicedb.webapp.context_path = /devicedb
No configuration necessary. Please note that this "persistence layer" is in fact non-persistent as its contents will be lost upon restarting the portal process. Can be used if you either don't need to maintain a real device database in your testbed or e.g., during development / debugging.
# Usage: .properties file to initialize JPA backend for the device database
devicedb.jpa.properties =
Again, the property refers to a Hibernate configuration file in .properties format. Below is an example configuration file:
hibernate.connection.url = jdbc:mysql://localhost:3306/tr_devicedb
hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.dialect = org.hibernate.dialect.MySQLDialect
hibernate.hbm2ddl.auto = update
hibernate.connection.username =
hibernate.connection.password =
# Usage: The URI the DeviceDB REST service runs on
devicedb.remote.uri =
# Usage: If used in the SmartSantander context: the URI of the EventBroker to connect to
# Example: tcp://lira.tlmat.unican.es:9020
devicedb.smartsantander.eventbroker.uri =
# Usage: If used in the SmartSantander context: the ID of the TR portal server in the Resource Directory (RD)
devicedb.smartsantander.rd.portal_id =
The following configuration properties are passed to the WiseGui front-end for initialization:
# Usage: The context path under which the WiseGui shall be run
# Example: /
# Default value: /
#wisegui.context_path = /
# Usage: JSON Description of the federated testbeds to be displayed in WiseGui
# Example: {"urn:wisebed:uzl:staging1:":"Testbed 1", "urn:wisebed:uzl:staging2:":"Testbed 2"}
wisegui.federates =
# Usage: The context path under which the REST API runs
# Example: /rest/v1.0
# Default value: /rest/v1.0
#wisegui.rest_api.context_path = /rest/<v1 class="0"></v1>
# Usage: The directory under which to find the WiseGui. If not given WiseGui will be served from a packaged internal version.
wisegui.source_dir =
# Usage: Name of the testbed to be displayed in WiseGui frontend
# Default value: local testbed
#wisegui.testbed_name = local testbed
# Usage: The context path under which the WebSocket API runs
# Example: /ws/v1.0
# Default value: /ws/v1.0
#wisegui.websocket.context_path = /ws/v1.0
Every Testbed Runtime ships with a bundled version of the WiseGui packed into the portals jar file. If you want to use e.g., a newer (development) version or a fork simply clone the WiseGui project and set the wisegui.source_dir property to the directory that contains the cloned/forked WiseGui.
To customize the title of the testbed displayed to WiseGui users, please set wisegui.testbed_name.
Testbed Runtime comes with two administrative interfaces (at the time writing this): one for the DeviceDB (http://yourtestbed.yourdomain.tld/admin/devicedb) and one for the Shiro SNAA (http://yourtestbed.yourdomain.tld/admin/shiro-snaa, only if configured). Both sites are secured with HTTP basic authentication to be only accessible by testbed administrators.
To set/change username and password for the administrator please edit the following properties inside the portals configuration file:
admin.username = admin
admin.password = secret
and set them to more sensible values. The password is stored in plain-text format in this configuration file so please make sure file access is restricted accordingly on your server system.
The gateway process is the process that actually connects phyisically with the sensor nodes through their serial port or some other means (such as a wireless connection). In order to do so, it tries to detect sensor nodes as soon as they are attached to the gateway host (or come into communication range). Then, the gateway fetches the configuration of the detected sensor node from the DeviceDB running on the portal server and connects to it. Then, it will "tell" the portal that this specific detected node was attached to this portal host by sending him an according message on a TCP connection using an internal protocol. The portal will remember this information and will, from now on, send all user requests to the connected sensor node over the TCP connection initiated by the gateway process.
So, in order to have the gateway process be fully functional the configuration of the gateway only consists of just a small set of configuration options. Below you find a typical configuration of the gateway process that is sufficient (replace $PORTAL_HOST with the actual hostname of the portal server):
urnprefix = urn:local:
gateway.portaladdress = $PORTAL_HOST:9990
devicedb.type = REMOTE
devicedb.remote.uri = http://$PORTAL_HOST:9999/rest/v1.0/devicedb
The parameter gateway.portaladdress is the host and port on which the portal process listens for connections initiated by the gateways. The DeviceDB is of type REMOTE, pointing to the REST API endpoint URL which runs on the portal server.
Additionally to the properties above, if you want to enable the plugin mechanism, add the following property to have TR check for plugins in the configured directory.
gateway.plugin_directory = /usr/share/tr.iwsn-gateway/plugins
If run in the context of the SmartSantander project, TR requires some more properties:
devicedb.smartsantander.eventbroker.uri = tcp://$EVENTBROKER_HOST:9020
devicedb.smartsantander.rd.portal_id = my_portal_id
gateway.smartsantander.gateway_id = this_gateway_id
If given, TR will subscribe to events on the eventbroker running on $EVENTBROKER_HOST:9020 and listen for all events indicating that a device was added or removed from this gateway (identified by portal and gateway ID).