X-Road: System Parameters User Guide
Version: 2.74 Doc. ID: UG-SYSPAR
| Date | Version | Description | Author |
|---|---|---|---|
| 29.05.2015 | 1.0 | First draft | Siim Annuk |
| 01.06.2015 | 1.1 | Some corrections done, typos fixed | Siim Annuk |
| 30.06.2015 | 1.2 | Minor corrections done | Vello Hansen, Imbi Nõgisto |
| 26.08.2015 | 1.3 | Corrections regarding SQL done | Marju Ignatjeva |
| 09.09.2015 | 2.0 | Editorial changes made | Imbi Nõgisto |
| 11.09.2015 | 2.1 | Global configuration generation interval added | Martin Lind |
| 20.09.2015 | 2.2 | Editorial changes made | Imbi Nõgisto |
| 23.09.2015 | 2.3 | Warning added about changing system parameters | Siim Annuk |
| 24.09.2015 | 2.4 | Note added about setting the timeStampingIntervalSeconds system parameter | Siim Annuk |
| 07.10.2015 | 2.5 | Default value of the parameter acceptable-timestamp-failure-period set to 14400 | Kristo Heero |
| 8.12.2015 | 2.6 | New parameters for configuring signature algorithms and key length, proxy client-side TLS protocols, and software token pin policy | Jarkko Hyöty |
| 8.12.2015 | 2.7 | Added parameters for toggling SOAP body logging on/off | Janne Mattila |
| 17.12.2015 | 2.8 | Added monitoring parameters | Ilkka Seppälä |
| 28.1.2016 | 2.9 | Added configuration client admin port | Ilkka Seppälä |
| 04.10.2016 | 2.10 | Converted to markdown format | Sami Kallio |
| 05.10.2016 | 2.11 | Added options for proxy client and server connections. Clarified client-timeout option. | Olli Lindgren |
| 02.11.2016 | 2.12 | Fix ocspFreshnessSeconds description in system parameters document. | Ilkka Seppälä |
| 01.12.2017 | 2.13 | Added documentation for minimum global conf version | Sami Kallio |
| 20.01.2017 | 2.14 | Added license text and version history | Sami Kallio |
| 08.02.2017 | 2.15 | Updated documentation with new environmental monitoring parameters describing sensor intervals | Sami Kallio |
| 23.02.2017 | 2.16 | Added documentation for OCSP-response retrieval deactivation parameter | Tatu Repo |
| 03.03.2017 | 2.17 | Added new parameter jetty-ocsp-responder-configuration-file | Kristo Heero |
| 07.03.2017 | 2.18 | Added new parameters ocsp-responder-client-connect-timeout and ocsp-responder-client-read-timeout | Kristo Heero |
| 11.04.2017 | 2.19 | Changed default values of the proxy parameter client-timeout to 30000, client-use-fastest-connecting-ssl-socket-autoclose and client-use-idle-connection-monitor to true. Added new messagelog parameters timestamper-client-connect-timeout and timestamper-client-read-timeout. Changed default value of the proxy parameter pool-validate-connections-after-inactivity-of-millis to 2000. | Kristo Heero |
| 06.06.2017 | 2.20 | Removed parameter default-signature-algorithm, replaced parameters csr-signature-algorithm with csr-signature-digest-algorithm, signature-algorithm-id with signature-digest-algorithm-id, and confSignAlgoId with confSignDigestAlgoId. Added new proxy-ui parameter auth-cert-reg-signature-digest-algorithm-id. | Kristo Heero |
| 14.06.2017 | 2.21 | Added new parameter allowed-federations for enabling federation in a security server. | Olli Lindgren |
| 11.07.2017 | 2.22 | Changed connector SO-linger values to -1 as per code changes | Tatu Repo |
| 18.08.2017 | 2.23 | Update wsdl-validator-command description | Jarkko Hyöty |
| 31.08.2017 | 2.24 | Moved ocsp-cache-path and enforce-token-pin-policy from under proxy to under signer and added them to central server and configuration proxy lists | Tatu Repo |
| 17.10.2017 | 2.25 | Added new security server env-monitor parameter (limit-remote-data-set). | Joni Laurila |
| 20.10.2017 | 2.26 | Clarified the effects of disabling SOAP body logging on the SOAP Headers. Split the system parameters to different tables for readability | Olli Lindgren |
| 22.11.2017 | 2.27 | Default changed to vanilla. New colums added for FI and EE values. | Antti Luoma |
| 02.01.2018 | 2.28 | Added proxy parameter allow-get-wsdl-request. | Ilkka Seppälä |
| 29.01.2018 | 2.29 | Removed proxy parameter client-fastest-connecting-ssl-use-uri-cache. Added proxy parameter client-fastest-connecting-ssl-uri-cache-period. | Ilkka Seppälä |
| 05.03.2018 | 2.30 | Added reference to terms and abbreviations, modified reference handling, added numbering. | Tatu Repo |
| 06.04.2018 | 2.31 | Removed TLSv1.1 support (client-side interfaces for incoming request) and TLS SHA-1 ciphers from default ciphers list. | Kristo Heero |
| 18.08.2018 | 2.32 | Added new parameter ocsp-retry-delay | Petteri Kivimäki |
| 08.10.2018 | 2.33 | Added new parameter xroad-tls-ciphers | Henri Haapakanni |
| 18.10.2018 | 2.34 | Default value of the parameter signer.client-timeout set to 60000 | Petteri Kivimäki |
| 25.10.2018 | 2.35 | Update note regarding supported cipher suites on RHEL 7 | Petteri Kivimäki |
| 26.10.2018 | 2.36 | Added new parameter module-manager-update-interval | Petteri Kivimäki |
| 08.11.2018 | 2.37 | Improved definition of minimum-global-configuration-version on the central server and configuration proxy | Ilkka Seppälä |
| 19.12.2018 | 2.38 | Fixed the default value of trusted-anchors-allowed | Ilkka Seppälä |
| 21.12.2018 | 2.39 | Add connector initial idle time parameters | Jarkko Hyöty |
| 23.01.2019 | 2.40 | Added new Central Server parameter auto-approve-auth-cert-reg-requests | Petteri Kivimäki |
| 31.01.2019 | 2.41 | REST message log parameters | Jarkko Hyöty |
| 03.02.2019 | 2.42 | Added new Central Server parameter auto-approve-client-reg-requests | Petteri Kivimäki |
| 27.03.2019 | 2.43 | Added management REST API parameters | Janne Mattila |
| 02.04.2019 | 2.44 | Added new message log parameter clean-transaction-batch | Jarkko Hyöty |
| 08.04.2019 | 2.45 | Update REST related message log parameters' descriptions | Petteri Kivimäki |
| 30.04.2019 | 2.46 | Added new parameter timestamp-retry-delay | Petteri Kivimäki |
| 02.07.2019 | 2.47 | Added new Central Server parameter auto-approve-owner-change-requests | Petteri Kivimäki |
| 26.11.2019 | 2.48 | Add proxy serverconf caching parameters | Jarkko Hyöty |
| 05.12.2019 | 2.49 | Fix broken link in Table of Contents | Tapio Jaakkola |
| 11.12.2019 | 2.50 | Added new Central Server parameter ha-node-name | Jarkko Hyöty |
| 01.04.2020 | 2.51 | Added new management REST API parameters key-management-api-whitelist and regular-api-whitelist | Janne Mattila |
| 03.04.2020 | 2.52 | Removed proxy parameter allow-get-wsdl-request. | Petteri Kivimäki |
| 12.04.2020 | 2.53 | Updated connector-host property EE-package value. | Petteri Kivimäki |
| 30.04.2020 | 2.54 | Added new parameter enforce-client-is-cert-validity-period-check | Märten Soo |
| 01.07.2020 | 2.55 | Updated enforce-token-pin-policy property EE-package value. | Petteri Kivimäki |
| 30.07.2020 | 2.56 | Moved proxy-ui parameters into proxy-ui-api parameters | Janne Mattila |
| 30.07.2020 | 2.57 | CS default database password is autogenerated. | Ilkka Seppälä |
| 13.10.2020 | 2.58 | Add new parameter akka-use-secure-remote-transport | Jarkko Hyöty |
| 11.02.2021 | 2.59 | Add new parameter auto-update-timestamp-service-url | Ilkka Seppälä |
| 01.06.2021 | 2.60 | Add new parameter messagelog.archive-grouping | Jarkko Hyöty |
| 04.08.2021 | 2.61 | Add new parameters for messagelog archive encryption | Jarkko Hyöty |
| 25.08.2021 | 2.62 | Update X-Road references from version 6 to 7 | Caro Hautamäki |
| 31.08.2021 | 2.63 | Update messagelog and proxy parameters | Ilkka Seppälä |
| 05.10.2021 | 2.64 | Added a new chapter about custom command line arguments 6 | Caro Hautamäki |
| 13.04.2022 | 2.65 | Corrected message logging max body size parameter name | Raido Kaju |
| 28.04.2022 | 2.66 | Updated max-loggable-message-body-size property EE-package value. | Ričardas Bučiūnas |
| 30.09.2022 | 2.67 | Updated key-length property EE- and FI-package values. | Petteri Kivimäki |
| 05.06.2023 | 2.72 | Update global configuration generation rate parameter | Andres Rosenthal |
| 15.06.2023 | 2.73 | Added strict-identifier-checks parameter | Madis Loitmaa |
| 13.06.2023 | 2.74 | Add configurable max request size constrains for central server admin service. | Andres Rosenthal |
Table of Contents
-
X-Road: System Parameters User Guide
- Table of Contents
- License
- 1 Introduction
- 2 Changing the System Parameter Values
-
3 Security Server System Parameters
- 3.1 Common parameters :
[common]
- 3.2 Proxy parameters:
[proxy]
- 3.3 Proxy User Interface parameters:
[proxy-ui]
- 3.4 Signer parameters:
[signer]
- 3.5 Anti-DOS parameters:
[anti-dos]
- 3.6 Configuration Client parameters:
[configuration-client]
-
3.7 Message log add-on parameters:
[message-log]
- 3.8 Environmental monitoring add-on configuration parameters:
[env-monitor]
- 3.9 Management REST API parameters:
[proxy-ui-api]
- 3.1 Common parameters :
- 4 Central Server System Parameters
- 5 Configuration Proxy System Parameters
- 6 Adding command line arguments
License
This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.
1 Introduction
This document describes the system parameters of the X-Road components – of the security server, the central server and the configuration proxy. Additionally, changing the default values of the system parameters are explained. Please note the term 'vanilla' in the documentation. In X-Road context vanilla means the X-Road without any of the country specific customizations, settings etc. The vanilla version of X-Road security server is installed with xroad-securityserver package. The country specific versions are installed with xroad-securityserver-XX where XX is the country code f.ex. FI or EE.
1.1 Terms and abbreviations
See X-Road terms and abbreviations documentation [TA-TERMS].
1.2 References
- [INI] INI file, http://en.wikipedia.org/wiki/INI_file.
- [CRON] Quartz Scheduler CRON expression, http://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/tutorial-lesson-06.html.
- [PR-MESS] X-Road Message Protocol v. 4.0.
- [PR-TARGETSS] Security Server Targeting Extension for the X-Road Message Protocol.
- [PR-SECTOKEN] Security Token Extension for the X-Road Message Protocol.
- [TA-TERMS] X-Road Terms and Abbreviations.
- [CRONMAN] http://linux.die.net/man/8/cron.
- [CRONHOW] Cron format specifications https://help.ubuntu.com/community/CronHowto.
- [PR-REST] X-Road Message Protocol for REST v. 1.0.
- [UG-SS] X-Road 7. Security Server User Guide. Document ID: UG-SS
2 Changing the System Parameter Values
The system parameters specify various characteristics of the system, such as port numbers, timeouts and paths to files on disk. The system parameters of the X-Road components are mainly stored in configuration files. Additionally, X-Road central server stores some system parameters in the database.
Changing the values of the system parameters is strongly discouraged, since it may cause unexpected system behaviour.
2.1 Changing the System Parameter Values in Configuration Files
The configuration files are INI files [INI], where each section contains parameters for a particular server component.
In order to override the default values of system parameters, create or edit the file
/etc/xroad/conf.d/local.ini
Each system parameter affects a specific server component. To change the value of a system parameter, a section for the affected component must be created in the INI file. The name-value pairs of the system parameters for that component are written under the section, one pair per line.
The following format is used for the sections:
[ServerComponent]
SystemParameterName1=Value1
SystemParameterName2=Value2
For example, to configure the parameter client-http-port for the proxy component, the following lines must be added to the configuration file:
[proxy]
client-http-port=1234
Multiple parameters can be configured under the same section:
[proxy]
client-http-port=1234
server-listen-port=20000
NB! Changing the parameter values in the configuration files requires restarting of the server.
WARNING! The value of the parameter is not validated, thus care must be taken when changing the value. For example, setting the port number to a non-numeric value in the configuration will cause the system to crash.
2.2 Changing the System Parameter Values in the Central Server Database
The central server database can be accessed with the psql utility using the following command (password is defined in /etc/xroad/db.properties
):
psql -U centerui -h localhost centerui_production
The default value of a system parameter can be overridden by adding the parameter name and value to the system_parameters table:
INSERT INTO system_parameters (key, value, created_at, updated_at) VALUES ('parameter_name', 'parameter_value', (now() at time zone 'utc'), (now() at time zone 'utc'));
To edit the value of a system parameter already inserted into the system_parameters table:
UPDATE system_parameters SET value = '*parameter_value*', updated_at = (now() at time zone 'utc') WHERE key = 'parameter_name';
To restore the default value of a system parameter, delete the parameter from the system_parameters table:
DELETE FROM system_parameters WHERE key = 'parameter_name';
NB! Modifying or deleting system parameters other than the ones listed in section System Parameters in the Database will cause the system to crash.
2.3 Changing the Global Configuration Generation Interval in the Central Server
In order to override the default value of the global configuration generation interval, edit the cron expression [CRON] in the file
/etc/cron.d/xroad-center
The default contents of the file are the following:
#!/bin/sh
* * * * * xroad curl http://<IP_ADDRESS>:8084/managementservice/gen_conf 2>&1 > /dev/null;
NB! Global configuration generation interval must be modified with extreme care. Misuse of the global configuration generation interval may hinder the operation of the whole X-Road instance.
The configuration generation interval must be shorter than the value of global configuration expiration interval (confExpireIntervalSeconds, see section 4.2 ), or else the configuration downloaded by the configuration clients (security servers or configuration proxies) will always expire before valid configuration becomes available. It is highly recommended that the global configuration generation interval is multiple times smaller than the global configuration expiration interval.
3 Security Server System Parameters
This chapter describes the system parameters used by the components of the X-Road security server. For instructions on how to change the parameter values, see section Changing the System Parameter Values in Configuration Files.
3.1 Common parameters : [common]
| Parameter | Vanilla value | Description |
|---|---|---|
| configuration-path | /etc/xroad/globalconf/ | Absolute path to the directory where global configuration is stored. |
| temp-files-path | /var/tmp/xroad/ | Absolute path to the directory where temporary files are stored. |
| akka-use-secure-remote-transport | true | Should Akka remoting use TLS (true) or not (false). The keypair used is ephemeral and recreated after boot. |
3.2 Proxy parameters: [proxy]
| Parameter | Vanilla value | FI-package value | EE-package value | Description |
|---|---|---|---|---|
| client-http-port | 80 8080 (RHEL) |
TCP port on which the service client's security server listens for HTTP requests from client applications. | ||
| client-https-port | 443 8443 (RHEL) |
TCP port on which the service client's security server listens for HTTPS requests from client applications. | ||
| client-timeout | 30000 | Defines the time period (in milliseconds), for which the service client's security server tries to connect to the service provider's security server. When the timeout is reached, the service client's security server informs the service client's information system that a service timeout has occurred. | ||
| configuration-anchor-file | /etc/xroad/configuration-anchor.xml | Absolute file name of the configuration anchor that is used to download global configuration. | ||
| connector-host | <IP_ADDRESS> | <IP_ADDRESS> | IP address on which the service client's security server listens for connections from client applications. The value <IP_ADDRESS> allows listening on all IPv4 interfaces. The value <IP_ADDRESS> allows listening on localhost only. | |
| database-properties | /etc/xroad/db.properties | Absolute file name of the properties file for the configuration of the security server database. | ||
| ocsp-responder-listen-address | <IP_ADDRESS> | IP address on which the service provider's security server listens for requests for OCSP responses from the service client's security server. The service client's security server downloads OCSP responses from the service provider's security server while establishing a secure connection between the security servers. The value <IP_ADDRESS> allows listening on all IPv4 interfaces. Must match the value of proxy.server-listen-address. | ||
| ocsp-responder-port | 5577 | TCP port on which the service provider's security server listens for requests for OCSP responses from the service client's security server. The service client's security server downloads OCSP responses from the service provider's security server while establishing a secure connection between the security servers. | ||
| ocsp-responder-client-connect-timeout | 20000 | Connect timeout (in milliseconds) of the OCSP responder client. The service client's security server downloads OCSP responses from the service provider's security server while establishing a secure connection between the security servers. | ||
| ocsp-responder-client-read-timeout | 30000 | Read timeout (in milliseconds) of the OCSP responder client. The service client's security server downloads OCSP responses from the service provider's security server while establishing a secure connection between the security servers. | ||
| server-listen-address | <IP_ADDRESS> | IP address on which the service provider's security server listens for connections from the service client's security servers. The value <IP_ADDRESS> allows listening on all IPv4 interfaces. | ||
| server-listen-port | 5500 | TCP port on which the service provider's security server listens for connections from the service client's security server. | ||
| server-port | 5500 | Destination TCP port for outgoing queries in the service client's security server. | ||
| jetty-clientproxy-configuration-file | /etc/xroad/jetty/clientproxy.xml | Absolute filename of the Jetty configuration file for the service client's security server. For more information about configuring Jetty server, see https://www.eclipse.org/jetty/documentation/jetty-9/index.html. | ||
| jetty-serverproxy-configuration-file | /etc/xroad/jetty/serverproxy.xml | Absolute filename of the Jetty configuration file for the service provider's security server. For more information about configuring Jetty server, see https://www.eclipse.org/jetty/documentation/jetty-9/index.html. | ||
| jetty-ocsp-responder-configuration-file | /etc/xroad/jetty/ocsp-responder.xml | Absolute filename of the Jetty configuration file for the OCSP responder of the service provider's security server. For more information about configuring Jetty server, see https://www.eclipse.org/jetty/documentation/jetty-9/index.html. | ||
| ssl-enabled | true | If true, TLS is used for connections between the service client's and service provider's security servers. | ||
| client-tls-ciphers | See 1 | TLS ciphers (comma-separated list) enabled on the client-side interfaces (for both incoming and outgoing requests). (since version 6.7) | ||
| xroad-tls-ciphers | See 2 | TLS ciphers (comma-separated list in preferred order) accepted on requests between security servers, and between operational monitoring daemon and client. (since version 6.20) | ||
| client-tls-protocols | TLSv1.2 | TLS protocols (comma-separated list) enabled on the client-side interfaces (for both incoming and outgoing requests). For backward compatibility TLSv1.1 is still supported on the client-side interfaces for outgoing requests (since version 6.7) | ||
| server-connector-initial-idle-time | 30000 | The initial idle time (in milliseconds) that unauthenticated connections are allowed to be idle before the provider security server starts closing them. Value of 0 means that an infinite idle time is allowed. | ||
| server-connector-max-idle-time | 0 | 120000 | The maximum time (in milliseconds) that connections from a service consuming security server to a service providing security server are allowed to be idle before the provider security server starts closing them. Value of 0 means that an infinite idle time is allowed. A non-zero value should allow some time for a pooled connection to be idle, if pooled connections are to be supported. | |
| server-connector-so-linger | -1 | The SO_LINGER time (in seconds) at the service providing security server end for connections between security servers. A value larger than 0 means that upon closing a connection, the system will allow SO_LINGER seconds for the transmission and acknowledgement of all data written to the peer, at which point the socket is closed gracefully. Upon reaching the linger timeout, the socket is closed forcefully, with a TCP RST. Enabling the option with a timeout of zero does a forceful close immediately. Value of -1 disables the forceful close. |
||
| server-support-clients-pooled-connections | false | true | Whether this service providing security server supports pooled connections from the service consumer side. If set to false, connections are to be closed immediately after each message. This may be a wanted approached for security servers behind load balancers. | |
| client-connector-initial-idle-time | 30000 | The initial idle time (in milliseconds) that client connections are allowed to be idle before the security server starts closing them. Value of 0 means that an infinite idle time is allowed. | ||
| client-connector-max-idle-time | 0 | The maximum time (in milliseconds) that connections from a service consumer to the service consumer's security server are allowed to be idle before the security server starts closing them. Value of 0 means that an infinite idle time is allowed. | ||
| client-connector-so-linger | -1 | The SO_LINGER time (in seconds) at the service consuming security server end for connections between a consumer and a security server. A value larger than 0 means that upon closing a connection, the system will allow SO_LINGER seconds for the transmission and acknowledgement of all data written to the peer, at which point the socket is closed gracefully. Upon reaching the linger timeout, the socket is closed forcefully, with a TCP RST. Enabling the option with a timeout of zero does a forceful close immediately. Value of -1 disables the forceful close. |
||
| client-httpclient-timeout | 0 | The maximum time (SO_TIMEOUT, in milliseconds) that connections from a service consuming security server to a service providing security server are allowed to wait for a response before the consumer end httpclient gives up. Value of 0 means that an infinite wait time is allowed. This does not affect idle connections. | ||
| client-httpclient-so-linger | -1 | The SO_LINGER time (in seconds) at the service consuming security server end for connections between security servers. A value larger than 0 means that upon closing a connection, the system will allow SO_LINGER seconds for the transmission and acknowledgement of all data written to the peer, at which point the socket is closed gracefully. Upon reaching the linger timeout, the socket is closed forcefully, with a TCP RST. Enabling the option with a timeout of zero does a forceful close immediately. Value of -1 disables the forceful close. |
||
| client-use-idle-connection-monitor | true | Should the idle connection monitor be used to clean up idle and expired connections from the connection pool. | ||
| client-idle-connection-monitor-interval | 30000 | How often (in milliseconds) should the connection monitor go through the pooled connections to see if it can clean up any idle or expired connections. This option requires the connection monitor to be enabled to have any effect. | ||
| client-idle-connection-monitor-timeout | 60000 | The minimum time (in milliseconds) that a pooled connection must be unused (idle) before it can be removed from the pool. Note that removal from the pool also depends on how often the connection monitor runs. This option requires the connection monitor to be enabled to have any effect. | ||
| pool-total-max-connections | 10000 | The total maximum number of connections that are allowed in the pool. | ||
| pool-total-default-max-connections-per-route | 2500 | The default route specific connection maximum that is set unless a route specific connection limit is set. Due to the current implementation, this is actually the total maximum limit of connections, indepedent of what the above setting is. | ||
| pool-validate-connections-after-inactivity-of-millis | 2000 | When reusing a pooled connection to a service providing security server, check that the connection (the socket) is not half-closed if it has been idle for at least this many milliseconds. This method cannot detect half-open connections. Value of -1 disables the check. | ||
| pool-enable-connection-reuse | false | true | Allow pooled connections between security servers to be used more than once on the client side. The service provider end of the connections has to have the setting server-support-clients-pooled-connections=true for the pooling to work between a provider and consumer security servers. |
|
| client-use-fastest-connecting-ssl-socket-autoclose | true | On TLS connections between security servers, should the underlying TCP-layer connection (socket) be closed on the service consumer end when the TLS layer connection is terminated. | ||
| client-fastest-connecting-ssl-uri-cache-period | 3600 | When a service consumer's security server finds the fastest responding service providing security server, how long the result should be kept in the TLS session cache? 0 to disable. | ||
| health-check-port | 0 (disabled) | The TCP port where the health check service listens to requests. Setting the port to 0 disables the health check service completely. | ||
| health-check-interface | <IP_ADDRESS> | The network interface where the health check service listens to requests. Default is all available interfaces. | ||
| actorsystem-port | 5567 | The (localhost) port where the proxy actorsystem binds to. Used for communicating with xroad-signer and xroad-monitor. | ||
| server-conf-cache-period | 60 | Number of seconds to keep selected serverconf configuration items in memory | ||
| server-conf-client-cache-size | 100 | Maximum number of local clients to keep cached | ||
| server-conf-service-cache-size | 1000 | Maximum number of services to keep cached | ||
| server-conf-acl-cache-size | 100000 | Maximum number of access rights to keep cached in memory. | ||
| enforce-client-is-cert-validity-period-check | false | Whether to reject a request when client information system certificate is expired or not yet valid. | ||
| backup-encryption-enabled | false | Whether to encrypt security server backup files using server's OpenPGP key. | ||
| backup-encryption-keyids | Comma-separated list of additional recipient OpenPGP key identifiers. |
Note about database-properties
file: Management REST API module uses the same database-properties file, but
limits the configuration parameters usage:
-
hibernate.dialect
cannot be changed, it is fixed to a custom PostgreSQL dialect. - out of
hibernate.connection.*
parameters, onlyurl
,username
andpassword
can be configured.
This in practice limits configurability to different kinds of PostgreSQL database configurations, and it is not possible to use for example MySQL as a data store for REST API module.
3.3 Proxy User Interface parameters: [proxy-ui]
Proxy-ui has been removed in version 6.24 and it's parameters are not used anymore.
proxy-ui-api parameters replace the old [proxy-ui]
parameters.
3.4 Signer parameters: [signer]
| Parameter | Vanilla value | FI-package value | EE-package value | Description |
|---|---|---|---|---|
| ocsp-cache-path | /var/cache/xroad | Absolute path to the directory where the cached OCSP responses are stored. | ||
| enforce-token-pin-policy | false | true | true | Controls enforcing the token pin policy. When set to true, software token pin is required to be at least 10 ASCII characters from at least tree character classes (lowercase letters, uppercase letters, digits, special characters). (since version 6.7.7) |
| client-timeout | 60000 | Signing timeout in milliseconds. | ||
| device-configuration-file | /etc/xroad/signer/devices.ini | Absolute filename of the configuration file of the signature creation devices. | ||
| key-configuration-file | /etc/xroad/signer/keyconf.xml | Absolute filename of the configuration file containing signature and authentication keys and certificates. | ||
| port | 5556 | TCP port on which the signer process listens. | ||
| key-length | 2048 | 3072 | 3072 | Key length for generating authentication and signing keys (since version 6.7) |
| csr-signature-digest-algorithm | SHA-256 | Certificate Signing Request signature digest algorithm. Possible values are - SHA-256, - SHA-384, - SHA-512. |
||
| ocsp-retry-delay | 60 | OCSP retry delay for signer when fetching OCSP responses fail. After failing to fetch OCSP responses signer waits for the time period defined by "ocsp-retry-delay" before trying again. This is repeated until fetching OCSP responses succeeds. After successfully fetching OCSP responses signer returns to normal OCSP refresh schedule defined by "ocspFetchInterval". If the value of "ocsp-retry-delay" is higher than "ocspFetchInterval", the value of "ocspFetchInterval" is used as OCSP retry delay. | ||
| module-manager-update-interval | 60 | HSM module manager update interval in seconds. | ||
| password-store-ipc-key-pathname | / |
3.5 Anti-DOS parameters: [anti-dos]
| Parameter | Vanilla value | Description |
|---|---|---|
| enabled | true | Flag for enabling or disabling the AntiDOS system. |
| max-cpu-load | 1.1 | Maximum allowed CPU load for accepting new connections. If set to > 1.0, then CPU load is not checked. |
| max-heap-usage | 1.1 | Specifies the maximum allowed Java heap usage when accepting new connections. If set to > 1.0, then heap usage is not checked. |
| max-parallel-connections | 5000 | Maximum number of parallel connections for AntiDOS. |
| min-free-file-handles | 100 | Minimum amount of free file handles in the system for accepting new connections. At least one free file handle must be available to accept a new connection. |
3.6 Configuration Client parameters: [configuration-client]
| Parameter | Vanilla value | Description |
|---|---|---|
| port | 5665 | TCP port on which the configuration client process listens. |
| update-interval | 60 | Global configuration download interval in seconds. |
| admin-port | 5675 | TCP port on which the configuration client process listens for admin commands. |
| allowed-federations | none | A comma-separated list of case-insensitive X-Road instances that fetching configuration anchors is allowed for. This enables federation with the listed instances if the X-Road instance is already federated at the central server level . Special value none, if present, disables all federation (the default value), while all allows all federations if none is not present. Example: allowed-federations=ee,sv allows federation with example instances EE and Sv while allowed-federations=all,none disables federation. X-Road services xroad-confclient and xroad-proxy need to be restarted (in that order) for the setting change to take effect. |
| proxy-configuration-backup-cron | * 15 3 * * ? | Cron expression for proxy configuration automatic backup job |
3.7 Message log add-on parameters: [message-log]
| Parameter | Vanilla value | FI-package value | EE-package value | Description |
|---|---|---|---|---|
| message-body-logging | true | false | Whether message body should be logged or not. If true, the messages are logged in their original form. If false, the message body is cleared of its contents (SOAP body will have an empty child element inside it; REST message body, service path and query parameters will be omitted). In addition, the SOAP header and REST HTTP headers will only have specific set of elements logged, see Note on logged X-Road message headers . As a side effect, details such as formatting and namespace labels of the xml message can be changed and new elements may be introduced for default values in SOAP header. Removal of message body is usually done for confidentiality reasons (body contains data that we do not want to have in the logs). Note that changing the message this way prevents verifying its signature with the asicverifier tool. |
|
| soap-body-logging | true | false | (deprecated, see message-body-logging) | |
| enabled-body-logging-local-producer-subsystems | Subsystem-specific overrides for message body logging when message-body-logging = false. This parameter defines logging for local producer subsystems, that is, our subsystems that produce some service which external clients use. Comma-separated list of client identifiers for which message body logging is enabled. For example FI/ORG/1710128-9/SUBSYSTEM_A1, FI/ORG/1710128-9/SUBSYSTEM_A2 where - FI = x-road instance - ORG = member class - 1710128-9 = member code - SUBSYSTEM_A1 = subsystem code This parameter can only be used on subsystem-level, it is not possible to configure message body logging per member. If a subsystem has forward slashes “/” in for example subsystem code, those subsystems can’t be configured with this parameter. |
|||
| enabled-body-logging-remote-producer-subsystems | Subsystem-specific overrides for remote producer subsystems, that is, remote subsystems that produce services which we use. Parameter is used when message-body-logging = false. |
|||
| disabled-body-logging-local-producer-subsystems | Same as enabled-body-logging-local-producer-subsystems, but this parameter is used when message-body-logging = true. | |||
| disabled-body-logging-remote-producer-subsystems | Same as enabled-body-logging-remote-producer-subsystems, but this parameter is used when message-body-logging = true. | |||
| acceptable-timestamp-failure-period | 14400 | 18000 | Defines the time period (in seconds) for how long is time-stamping allowed to fail (for whatever reasons) before the message log stops accepting any more messages (and consequently the security server stops accepting requests). Set to 0 to disable this check. The value of this parameter should not be lower than the value of the central server system parameter timeStampingIntervalSeconds. | |
| archive-interval | 0 0 0/6 1/1 * ? * | CRON expression [CRON] defining the interval of archiving the time-stamped messages. | ||
| archive-max-filesize | 33554432 | Maximum size for archived files in bytes. Reaching the maximum value triggers file rotation. | ||
| archive-path | /var/lib/xroad | Absolute path to the directory where time-stamped log records are archived. | ||
| clean-interval | 0 0 0/12 1/1 * ? * | CRON expression [CRON] for deleting any time-stamped and archived records that are older than message-log.keep-records-for from the database. | ||
| hash-algo-id | SHA-512 | The algorithm identifier used for hashing in the message log. Possible values are - SHA-224, - SHA-256, - SHA-384, - SHA-512. |
||
| keep-records-for | 30 | Number of days to keep time-stamped and archived records in the database of the security server. If a time-stamped and archived message record is older than this value, the record is deleted from the database. | ||
| timestamp-immediately | false | If true, the time-stamp is created synchronously for each request message. This is a security policy requirement to guarantee the time-stamp at the time of logging the message. | ||
| timestamp-records-limit | 10000 | Maximum number of message records to time-stamp in one batch. If the number of message records in a single batch exceeds 70 % of timestamp-records-limit value, a warning is logged in proxy.log . |
||
| timestamper-client-connect-timeout | 20000 | The timestamper client connect timeout in milliseconds. A timeout of zero is interpreted as an infinite timeout. | ||
| timestamper-client-read-timeout | 60000 | The timestamper client read timeout in milliseconds. A timeout of zero is interpreted as an infinite timeout. | ||
| timestamp-retry-delay | 60 | Time-stamp retry delay in seconds when batch time-stamping fails. After failing to batch time-stamp, the timestamper waits for the time period defined by "timestamp-retry-delay" before trying again. This is repeated until fetching a time-stamp succeeds. After successfully fetching a time-stamp, the timestamper returns to normal time-stamping schedule. If the value of "timestamp-retry-delay" is higher than the value of the central server system parameter "timeStampingIntervalSeconds", the value of "timeStampingIntervalSeconds" is used. If the value of "timestamp-retry-delay" is zero, the value of "timeStampingIntervalSeconds" is used. | ||
| archive-transaction-batch | 10000 | Size of transaction batch for archiving messagelog. This size is not exact because it will always make sure that last archived batch includes timestamp also (this might mean that it will go over transaction size). | ||
| max-loggable-message-body-size | 10485760 (10 MiB) | 20971520 (20MiB) | Maximum loggable REST message body size | |
| truncated-body-allowed | false | If the REST message body exceeds the maximum loggable body size, truncate the body in the log (true) or reject the message (false). | ||
| clean-transaction-batch | 10000 | Maximun number of log records to remove in one transaction. | ||
| archive-grouping | none | Archive file grouping, one of 'none', 'member' (group by member), 'subsystem' (group by subsystem). | ||
| archive-transfer-command | A command that is executed after the (periodic) archiving process e.g. to transfer archive files automatically from the security server. Defaults to no operation. | |||
| archive-encryption-enabled | false | If true, archive files are encrypted using OpenPGP (GnuPG) | ||
| archive-gpg-home-directory | /etc/xroad/gpghome | GPG home for archive file signing (and default encryption) keys | ||
| archive-encryption-keys-config | Configuration file for member identifier to OpenPGP key id mapping. Per-member keys can be used when grouping is by 'member' or 'subsystem' (subsystems use the member's key). See [UG-SS] for details. | |||
| archive-default-encryption-key | Default OpenPGP key id for archive encryption (if not defined, the primary encryption key is used) | |||
| messagelog-encryption-enabled | false | If true, message bodies are stored to the database in an encrypted format | ||
| messagelog-keystore | Path to the keystore containing the key used in messagelog encryption | |||
| messagelog-keystore-password | Messagelog keystore password | |||
| messagelog-key-id | Identifier of the messagelog encryption key |
3.7.1 Note on logged X-Road message headers
If the messagelog add-on has the message body logging disabled, only a preconfigured set of the SOAP headers and/or REST HTTP headers will be included in the message log.
SOAP
The logged SOAP headers are the X-Road message headers listed in Chapter 2.2 of
the X-Road Message Protocol document [PR-MESS], as well as the representedParty
extension of the X-Road protocol described in the
extension's XML schema. The security server targeting extension for the X-Road message protocol
[PR-TARGETSS] or the Security Token Extension [PR-SECTOKEN] will not be included in the message log.
REST
The logged HTTP headers are the X-Road HTTP headers listed in Chapter 4.3 of the X-Road Message Protocol for REST document [PR-REST], including the security server targeting extension for the X-Road message protocol [PR-TARGETSS]. All other HTTP headers are excluded from the message log.
3.8 Environmental monitoring add-on configuration parameters: [env-monitor]
| Parameter | Vanilla value | Description |
|---|---|---|
| port | 2552 | TCP port number used in communications with xroad-proxy and xroad-monitor components. |
| system-metrics-sensor-interval | 5 | Interval of systems metrics sensor in seconds. How often system metrics data is collected. |
| disk-space-sensor-interval | 60 | Interval of disk space sensor in seconds. How often disk space data is collected. |
| exec-listing-sensor-interval | 60 | Interval of exec listing sensor in seconds. How often sensor data using external command are collected. |
| certificate-info-sensor-interval | 86400 | Interval of certificate information sensor in seconds. How often certificate data is collected. The first collection is always done after a delay of 10 seconds. |
| limit-remote-data-set | false | On/Off switch for filtering out optional monitoring data. With flag set to true, only security server owner can request and get full data set. |
3.9 Management REST API parameters: [proxy-ui-api]
| Parameter | Vanilla value | Description |
|---|---|---|
| ssl-properties | /etc/xroad/ssl.properties | Absolute path to file which overrides the default properties of the SSL connections to REST API. |
| key-management-api-whitelist | <IP_ADDRESS>/8, ::1 | Comma-separated list of plain IP addresses or address ranges in CIDR notation, which are allowed to call key management endpoints using basic authentication |
| regular-api-whitelist | <IP_ADDRESS>/0, ::/0 | Comma-separated list of plain IP addresses or address ranges in CIDR notation, which are allowed to call regular endpoints using api key authentication |
| wsdl-validator-command | The command to validate the given X-Road service WSDL. The command script must: a) read the WSDL from the URI given as an argument, b) return exit code 0 on success, c) return exit code 0 and write warnings to the standard error (stderr), if warnings occurs, d) return exit code other then 0 and write error messages to the standard error (stderr), if errors occurs. Defaults to no operation. |
|
| auth-cert-reg-signature-digest-algorithm-id | SHA-512 | Signature digest algorithm used for generating authentication certificate registration request. Possible values are - SHA-256, - SHA-384, - SHA-512. |
| auto-update-timestamp-service-url | false | If enabled, makes the security server update the timestamping service URLs when they are changed on the central server. In case there are multiple timestamping services with the same name, the update will not be done and a warning is logged instead. |
| request-size-limit-regular | 50KB | Maximum size of Management REST API requests |
| request-size-limit-binary-upload | 10MB | Maximum size of Management REST API requests for file uploads |
| rate-limit-requests-per-second | 20 | Management REST API request rate limit per second. Rate limits apply per each requesting IP. |
| rate-limit-requests-per-minute | 600 | Management REST API request rate limit per minute. Rate limits apply per each requesting IP. |
| rate-limit-cache-size | 10000 | Controls how many IP addresses can be remembered in the rate-limit cache Tradeoff between memory usage and protection from a large attack. |
| allowed-hostnames | Determines which hostnames are allowed to be used in "Host" header of the HTTP requests. Any hostname is allowed when left unspecified. | |
| cache-default-ttl | 60 | Configures default cache expiration in seconds. Cache is hit during authentication requests. Setting the value to -1 disables the cache. |
| cache-api-key-ttl | 60 | Configures Api Key cache expiration in seconds. Can be used by various api services. Setting the value to -1 disables the cache. |
| strict-identifier-checks | true* | Configures identifier input validation (member code, subsystem code etc). Values: true - identifiers must mach pattern ^[a-zA-Z0-9'()+,-.=?]* .false - identfiers must not contain colon (: ), semicolon (; ), slashes (/\ ), percent (% ) or control characters. |
NOTE:
strict-identifier-checks
default value is true for new installations starting from version 7.3.0. It is set tofalse
inlocal.ini
during upgrade process if version installed before upgrade is less than 7.3.0.
Configurable SSL connection parameters are those
Spring Boot's common application properties
that start with server.ssl
.
ssl.properties can be used to override any server.ssl.*
property, also those that do not have default values. However, the result of merging default properties
and overridden / new properties needs to be a functional combination.
Default values for the SSL properties are
| SSL Property | Default value | Description |
|---|---|---|
| server.ssl.key-store | /etc/xroad/ssl/proxy-ui-api.p12 | Path to the key store that holds the SSL certificate |
| server.ssl.key-store-password | proxy-ui-api | Password used to access the key store |
| server.ssl.enabled | true | Whether to enable SSL support |
| server.ssl.ciphers | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | Supported SSL ciphers |
| server.ssl.protocol | TLS | SSL protocol to use |
| server.ssl.enabled-protocols | TLSv1.2 | Enabled SSL protocols |
Management REST API module uses database-properties
configuration from the proxy parameters,
with some additional limitations on configurability (see details in proxy chapter).
4 Central Server System Parameters
The system parameters described in this chapter are used by the X-Road central server, except for the parameters ocspFreshnessSeconds and timeStampingIntervalSeconds.
The values of ocspFreshnessSeconds and timeStampingIntervalSeconds are distributed to the security servers via the global configuration. These parameters determine the interval of calling OCSP responder services and time-stamping services (respectively) by the security servers.
4.1 System Parameters in the Configuration File
For instructions on how to change the parameter values, see section Changing the System Parameter Values in Configuration Files.
4.1.1 Common parameters: [common]
| Server component | Name | Vanilla value | Description |
|---|---|---|---|
| common | temp-files-path | /var/tmp/xroad/ | Absolute path to the directory where temporary files are stored. |
4.1.2 Center parameters: [center]
| Name | Vanilla value | Description |
|---|---|---|
| conf-backup-path | /var/lib/xroad/backup/ | Absolute path to the directory where configuration backups are stored. |
| database-properties | /etc/xroad/db.properties | Absolute path to file where the properties of the database of the central server are stored. |
| external-directory | externalconf | Name of the signed external configuration directory that is distributed to the configuration clients (security servers and/or configuration proxies) of this and federated X-Road instances. |
| generated-conf-dir | /var/lib/xroad/public | Absolute path to the directory where both the private and shared parameter files are created for distribution. |
| internal-directory | internalconf | Name of the signed internal configuration directory that is distributed to the configuration clients (security servers and/or configuration proxies) of this X-Road instance. |
| trusted-anchors-allowed | true | True if federation is allowed for this X-Road instance. |
| minimum-global-configuration-version | 2 | The minimum supported global configuration version on the central server. This parameter is used if the central server needs to generate multiple versions of global configuration. Note that the support for global configuration V1 has been dropped in X-Road 6.20.0 and since that version the minimum value for this parameter is 2. |
| auto-approve-auth-cert-reg-requests | false | True if automatic approval of auth cert registration requests is enabled for this X-Road instance. Automatic approval is applied to existing members only. |
| auto-approve-client-reg-requests | false | True if automatic approval of client registration requests is enabled for this X-Road instance. Automatic approval is applied to existing members only. In addition, automatic approval is applied only if the client registration request has been signed by the member owning the subsystem to be registered as a security server client. |
| auto-approve-owner-change-requests | false | True if automatic approval of owner change requests is enabled for this X-Road instance. Automatic approval is applied to existing members only. |
| ha-node-name | Central server HA node name. See IG-CSHA before modifying this parameter. |
4.1.3 Center parameters: [admin-service]
| Name | Default value | Description |
|---|---|---|
| allowed-hostnames | Determines which hostnames are allowed to be used in "Host" header of the HTTP requests. Multiple hostnames can be provided as comma separated list. Any hostname is allowed when left unspecified. | |
| global-configuration-generation-rate-in-seconds | 60 | Global Configuration generation rate in seconds |
| rate-limit-enabled | true (see Description for more information) |
Controls whether the built-in rate limiting is enabled. Note. If the service is behind a reverse proxy (default), the proxy needs to forward the real IP address for the rate-limiting to work correctly. Therefore, by default, using forward headers is enabled. If the service is exposed directly, it must not use forwarded (e.g. X-Forwarded-For) headers (can be spoofed by clients), and the corresponding configuration (server.forward-headers-strategy) needs to be disabled (see additional information). |
| rate-limit-requests-per-second | 20 | Controls how many requests from an IP address are allowed per second. To disable this feature, set this value to -1. |
| rate-limit-requests-per-minute | 600 | Controls how many requests from an IP address are allowed per minute. To disable this feature, set this value to -1. |
| rate-limit-expire-after-access-minutes | 5 | Controls how long the rate-limit cache entries are valid |
| rate-limit-cache-size | 10000 | Controls how many IP addresses can be remembered in the rate-limit cache Tradeoff between memory usage and protection from a large attack. |
| cache-default-ttl | 60 | Configures default cache expiration in seconds. Cache is hit during authentication requests. Setting the value to -1 disables the cache. |
| cache-api-key-ttl | 60 | Configures Api Key cache expiration in seconds. Can be used by various api services. Setting the value to -1 disables the cache. |
| certificate-allowed-extensions | der,crt,pem,cer | Determines which file extensions are allowed when uploading certificate file. To disable this check, leave this value empty. |
| certificate-allowed-content-types | application/x-x509-cert,text/plain | Determines which file content types are allowed when uploading certificate file. Content type is deducted from file extension and file contents. To disable this check, leave this value empty. |
| xml-allowed-extensions | xml | Determines which file extensions are allowed when uploading XML file. To disable this check, leave this value empty. |
| xml-allowed-content-types | text/xml,application/xml | Determines which file content types are allowed when uploading XML file. Content type is deducted from file extension and file contents. To disable this check, leave this value empty. |
| backup-allowed-content-types | application/pgp-encrypted | Determines which file content types are allowed when uploading backup file. Content type is deducted from file extension and file contents. To disable this check, leave this value empty. |
| strict-identifier-checks | true* | Configures identifier input validation (member code, subsystem code etc). Values: true - identifiers must mach pattern ^[a-zA-Z0-9'()+,-.=?]* .false - identfiers must not contain colon (: ), semicolon (; ), slashes (/\ ), percent (% ) or control characters. |
| request-size-limit-regular | 50KB | Maximum size of Management REST API requests |
| request-size-limit-binary-upload | 10MB | Maximum size of Management REST API requests for file uploads |
NOTE:
strict-identifier-checks
default value is true for new installations starting from version 7.3.0. It is set tofalse
inlocal.ini
during upgrade process if version installed before upgrade is less than 7.3.0.
4.1.4 Signer parameters: [signer]
| Name | Default value | Description |
|---|---|---|
| ocsp-response-retrieval-active | false (see Description for more information) |
This property is used as an override to deactivate periodic OCSP-response retrieval for components that don't need that functionality, but still use signer. Values: false - OCSP-response retrieval jobs are never scheduled true - periodic OCSP-response retrieval is active based on ocspFetchInterval. Note that if the entire property is missing, it is interpreted as true. This property is delivered as an override and only for the components where the OCSP-response retrieval jobs need to be deactivated. The property is missing for components that require OCSP-response retrieval to be activated. |
| ocsp-cache-path | /var/cache/xroad | Absolute path to the directory where the cached OCSP responses are stored. |
| enforce-token-pin-policy | false | Controls enforcing the token pin policy. When set to true, software token pin is required to be at least 10 ASCII characters from at least tree character classes (lowercase letters, uppercase letters, digits, special characters). (since version 6.7.7) |
4.1.5 Center parameters: [registration-service]
| Name | Default value | Description |
|---|---|---|
| rate-limit-enabled | true (see Description for more information) |
Controls whether the built-in rate limiting is enabled. Note. If the service is behind a reverse proxy (default), the proxy needs to forward the real IP address for the rate-limiting to work correctly. Therefore, by default, using forward headers is enabled. If the service is exposed directly, it must not use forwarded (e.g. X-Forwarded-For) headers (can be spoofed by clients), and the corresponding configuration (server.forward-headers-strategy) needs to be disabled (see additional information). |
| rate-limit-requests-per-second | -1 | Controls how many requests from an IP address are allowed per second. To disable this feature, set this value to -1. |
| rate-limit-requests-per-minute | 10 | Controls how many requests from an IP address are allowed per minute. To disable this feature, set this value to -1. |
| rate-limit-cache-size | 10000 | Controls how many IP addresses can be remembered in the rate-limit cache Tradeoff between memory usage and protection from a large attack. |
| rate-limit-expire-after-access-minutes | 2 | Controls how long the rate-limit cache entries are valid |
| api-trust-store | /etc/xroad/ssl/center-admin-service.p12 | Path to a trust store containing certificates for the central server admin API. |
| api-trust-store-password | center-admin-service | Password for the trust store. |
| api-base-url | https://<IP_ADDRESS>:4000/api/v1 | Central server management API base URL. |
| api-token | API token for the central server management API (required). The token needs to have the MANAGEMENT_SERVICE role (and for security, no other roles). |
4.1.6 Center parameters: [management-service]
| Name | Default value | Description |
|---|---|---|
| rate-limit-enabled | true (see Description for more information) |
Controls whether the built-in rate limiting is enabled. Note. If the service is behind a reverse proxy (default), the proxy needs to forward the real IP address for the rate-limiting to work correctly. Therefore, by default, using forward headers is enabled. If the service is exposed directly, it must not use forwarded (e.g. X-Forwarded-For) headers (can be spoofed by clients), and the corresponding configuration (server.forward-headers-strategy) needs to be disabled (see additional information). |
| rate-limit-requests-per-second | -1 | Controls how many requests from an IP address are allowed per second. To disable this feature, set this value to -1. |
| rate-limit-requests-per-minute | 10 | Controls how many requests from an IP address are allowed per minute. To disable this feature, set this value to -1. |
| rate-limit-cache-size | 10000 | Controls how many IP addresses can be remembered in the rate-limit cache Tradeoff between memory usage and protection from a large attack. |
| rate-limit-expire-after-access-minutes | 2 | Controls how long the rate-limit cache entries are valid |
| api-trust-store | /etc/xroad/ssl/center-admin-service.p12 | Path to a trust store containing certificates for the central server admin API. |
| api-trust-store-password | center-admin-service | Password for the trust store. |
| api-base-url | https://<IP_ADDRESS>:4000/api/v1 | Central server management API base URL. |
| api-token | API token for the central server management API (required). The token needs to have the MANAGEMENT_SERVICE role (and for security, no other roles). |
4.2 System Parameters in the Database
This section describes the system parameters used by the X-Road central server. For instructions on how to change the parameter values, see section Changing the System Parameter Values in the Central Server Database.
| Name | Value type | Vanilla value | Description |
|---|---|---|---|
| confExpireIntervalSeconds | integer | 600 | Time in seconds of the validity of the configuration after creation. |
| confHashAlgoUri | string | http://www.w3.org/2001/04/xmlenc#sha512 | URI of the algorithm used for calculating the hash values of the global configuration files. Possible values are http://www.w3.org/2001/04/xmlenc#sha256, http://www.w3.org/2001/04/xmlenc#sha512. |
| confSignDigestAlgoId | string | SHA-512 | Identifier of the digest algorithm used for signing the global configuration. Possible values are - SHA-256, - SHA-384, - SHA-512. |
| confSignCertHashAlgoUri | string | http://www.w3.org/2001/04/xmlenc#sha512 | URI of the algorithm used for calculating the hash value of the certificate used to sign the global configuration. Possible values are http://www.w3.org/2001/04/xmlenc#sha256, http://www.w3.org/2001/04/xmlenc#sha512. |
| ocspFreshnessSeconds | integer | 3600 | Defines the validity period (in seconds) for the OCSP responses retrieved from the OCSP responders. OCSP responses older than the validity period are considered expired and cannot be used for certificate verification. |
| timeStampingIntervalSeconds | integer | 60 | Defines the interval of time-stamping service calls. Interval in seconds after which message log records must be timestamped. The interval must be between 60 and 86400 seconds. Note: this value must be less than ocspFreshnessSeconds. |
4.3 Global Configuration Generation Interval Parameter
The global configuration generation interval parameter regulates the timing for global configuration generation. Global configuration generation is invoked by the Cron daemon [CRONMAN]. The parameter is located at following file:
/etc/cron.d/xroad-center
The file is deployed during X-Road installation and by default has following content (see exact cron specifications) [CRONHOW]:
#!/bin/sh
* * * * * xroad curl http://<IP_ADDRESS>:8084/managementservice/gen_conf 2>1 >/dev/null;
The parameter regulating the timing of global configuration generation is the cron expression at the start of the last line (* * * * *), which means that global configuration generation is invoked every minute by default.
5 Configuration Proxy System Parameters
This chapter describes the system parameters used by the X-Road configuration proxy.
5.1 Configuration proxy module parameters: [configuration-proxy]
| Name | Vanilla value | Description |
|---|---|---|
| address | <IP_ADDRESS> | The public IP or NAT address which is accessed for downloading the distributed global configuration. |
| configuration-path | /etc/xroad/configurationproxy/ | Absolute path to the directory containing the configuration files of the configuration proxy instance. |
| generated-conf-path | /var/lib/xroad/public | Absolute path to the public web server directory where the global configuration files that this configuration proxy generates are be placed for distribution. |
| signature-digest-algorithm-id | SHA-512 | ID of the digest algorithm the configuration proxy uses when computing global configuration signatures. The possible values are - SHA-256, - SHA-384, - SHA-512. |
| hash-algorithm-uri | http://www.w3.org/2001/04/xmlenc#sha512 | URI that identifies the algorithm the configuration proxy uses when calculating hash values for the global configuration files. The possible values are http://www.w3.org/2001/04/xmlenc#sha256, http://www.w3.org/2001/04/xmlenc#sha512 |
| download-script | /usr/share/xroad/scripts/download_instance_configuration.sh | Absolute path to the location of the script that initializes the global configuration download procedure. |
| minimum-global-configuration-version | 2 | The minimum supported global configuration version on the configuration proxy. This parameter is used if the configuration proxy needs to distribute multiple versions of global configuration. Note that the support for global configuration V1 has been dropped in X-Road 6.20.0 and since that version the minimum value for this parameter is 2. |
5.2 Signer parameters: [signer]
| Name | Vanilla value | Description |
|---|---|---|
| ocsp-response-retrieval-active | false (see Description for more information) |
This property is used as an override to deactivate periodic OCSP-response retrieval for components that don't need that functionality, but still use signer. Values: false - OCSP-response retrieval jobs are never scheduled true - periodic OCSP-response retrieval is active based on ocspFetchInterval. Note that if the entire property is missing, it is interpreted as true. This property is delivered as an override and only for the components where the OCSP-response retrieval jobs need to be deactivated. The property is missing for components that require OCSP-response retrieval to be activated. |
| ocsp-cache-path | /var/cache/xroad | Absolute path to the directory where the cached OCSP responses are stored. |
| enforce-token-pin-policy | false | Controls enforcing the token pin policy. When set to true, software token pin is required to be at least 10 ASCII characters from at least tree character classes (lowercase letters, uppercase letters, digits, special characters). (since version 6.7.7) |
[1] Default value for proxy.client-tls-ciphers.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
[2] Default value for proxy.xroad-tls-ciphers.
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
(see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider for possible values)
Note. OpenJDK 8 on RHEL 7 supports ECDHE key agreement protocol starting from RHEL 7.3. In RHEL 7 versions prior to RHEL 7.3 only DHE cipher suites are supported.
6 Adding command line arguments
Sometimes you may need to provide command line arguments for Security Server, Central Server or Configuration Proxy, in order to override some parameters. For example if you wish to increase Java's maximum heap size, you can do it with the properties file /etc/xroad/services/local.properties
. The file is also included in the backup archive file when taking a configuration backup of either Central Server or Security Server.
6.1 The configuration file
The file /etc/xroad/services/local.properties
replaces the file /etc/xroad/services/local.conf
starting from X-Road version 7.
The local.properties
file's contents consists of key-value pairs such as XROAD_SIGNER_PARAMS=-XX:MaxMetaspaceSize=100m
. Notice that you cannot use quotes in the values. If you have multiple values for one key, use space to separate the values e.g. XROAD_SIGNER_PARAMS=-Xmx100m -XX:MaxMetaspaceSize=100m
. Also notice that with local.properties
you can only add new parameters and override old ones – you cannot remove existing default parameters.
Example of /etc/xroad/services/local.properties
with modifications that override the default Java memory parameters for Security Server:
XROAD_PROXY_PARAMS=-Xms200m -Xmx1024m
Example of /etc/xroad/services/local.properties
with modifications that override the default Java memory parameters for Central Server:
XROAD_CS_ADMIN_SERVICE_PARAMS=-Xms200m -Xmx1024m
Example of /etc/xroad/services/local.properties
with modifications that override the default Spring Boot parameter for Central Servers management API:
XROAD_CS_ADMIN_SERVICE_PARAMS=-Dserver.forward-headers-strategy=NONE
All possible properties to adjust in this file:
| Property | Details |
|---|---|
| XROAD_PARAMS | Parameters for all processes |
| XROAD_SIGNER_PARAMS | Parameters for the Signer |
| XROAD_ADDON_PARAMS | Parameters for all addons |
| XROAD_CONFCLIENT_PARAMS | Parameters for the Configuration Client |
| XROAD_CONFPROXY_PARAMS | Parameters for the Configuration Proxy |
| XROAD_MONITOR_PARAMS | Parameters for the Environmental Monitor |
| XROAD_OPMON_PARAMS | Parameters for the Operational Monitor |
| XROAD_PROXY_PARAMS | Parameters for the Security Server |
| XROAD_PROXY_UI_API_PARAMS | Parameters for the Security Server's admin API |
| XROAD_SIGNER_CONSOLE_PARAMS | Parameters for the Signer Console |
| XROAD_CS_ADMIN_SERVICE_PARAMS | Parameters for the Central Server's admin API |
| XROAD_CS_REGISTRATION_SERVICE_PARAMS | Parameters for the Central Server's registration API |
| XROAD_CS_MANAGEMENT_SERVICE_PARAMS | Parameters for the Central Server's management API |
6.2 Legacy configuration file support in X-Road v7
If you have upgraded from X-Road version 6 to version 7, you might still be using local.conf
script file with legacy parameters (non XROAD_ prefixed parameters), which is considered deprecated in X-Road version 7. The legacy file local.conf
will not be included in the configuration backups anymore – the new file local.properties
will be included instead, therefore it is strongly recommended migrating to the new local.properties
file.
The legacy file local.conf
will still be supported along with the legacy parameters. It is possible for both files to exist side-by-side. In this case the values from local.properties
are appended first and then the local.conf
file gets executed as a script afterwards. Notice that if your local.conf
script contains new XROAD_ prefixed parameters and old legacy parameters, the new XROAD_ prefixed parameters will always be preferred.


I am a master's degree computer science student from Italy with a huge passion for software development and cutting-edge technologies!
I'm developing an oracle that interacts with the Ethereum blockchain and automates the emission of Smart Lithium Coins, a new cryptocurrency conceived by Professor Gerardo Iovane at University of Salerno, based on the Ethereum ERC20 standard. This system makes Smart Lithium Coins available on the market and distributes them across the participants of the project, as explained in the whitepaper. The whole system is being developed using AdonisJS, a NodeJS framework very similar to its PHP counterpart Laravel and I'm making extensive use of RxJS to unleash the full potential of reactive programming, applying it to the data streams coming from the blockchain. In addition to the backend, I also developed a small web app to interact with the oracle using VueJS.
MeteoWhere is a hybrid application developed using Ionic 3. It allows users to easily find places to do various activities based on the forecast. Thanks to MeteoWhere, for example, it's easy to find ski stations to snowboard and the app will suggest only the ski slopes where the snow is high enough! The app has been developed for Spinvector CEO Giovanni Caturano.
The project was developed with Maria Elena Cammarano.
SoMusic! is a plugin built for the Social Networking Service Oxwall. It allows users to create and share musical scores. SoMusic! has a built-in music editor and a graphic visualization tool which helps users finding errors made during composition, using the 4-part music theory.
I developed the score editor from scratch using vanilla Javascript and then I used it to build an Oxwall plugin written in PHP.
DiscoverItaly is a hybrid app developed using Ionic 3 which allows users to find places of interest, restaurants, typical local products and festivals nearby!
The app was developed as a web scraping project for an exam and I worked on both the front-end and the back-end. The back-end is built with NodeJS, uses MongoDB for persistence and was deployed on AWS. Data was scraped from many websites, among which TripAdvisor. To do that, I developed a bot using PhantomJS headless browser, Selenium Webdriver and NodeJS.
This simple project was created for a parallel programming exam. The program takes as input two matrix A (m x n) and B (n x l) and multiplies them spreading the computation across multiple processors. Any number of processors can be used for the computation.
The project was developed using MPI and deployed on a cluster hosted on AWS.
This simple project was created for a p2p networks exam. It implements a Second-Price Auction System using a peer to peer network.
The project was developed in Java using the library TomP2P together with Maria Elena Cammarano.


Byte-le Royale is a 24 hour programming competition where competitors in teams of up to 3 write an AI to play a video game. The teams will be competing against each other to see who can create the best AI!
Saturday, February 10th at 12:00 PM to Sunday, February 11th at 2:00 PM
Quentin Burdick Building Room 104
Who doesn't like prizes? We will be offering prizes to the top three teams who compete.
We are still collecting donations for the prize pool, however currently
we have $350 for prizes which we will be splitting 55%, 30%, 15%.
$64 per person
$35 per person
$17 per person
Opening Ceremony. Competition Starts.
5:00 PMFood ticket purchase cutoff.
6:00 PMPizza Dinner for those who purchased a food ticket.
8:00 PMGoody-Bag Distribution for those who purchased a food ticket.
9:00 PMMini Special Event.
Bagels and cream cheese for breakfast.
12:00 PMSubmissions Close. Judging begins.
2:00 PMClosing Ceremony and Awarding Winners.
In order to better judge how many people will be attending, we would like to encourage everyone who plans on attending to RSVP. Attendence of the event is 100% free. We will, however, be offering a food ticket package. Additionally, to save time, you can RSVP up to three people (the max number of people in a team) at one time.
At the event from 12:00 PM to 5:00 PM on Saturday, we will be selling $10 food ticket packages. This food ticket package will include 3 food tickets redeemable for the two meals listed on the schedule, as well as a goody bag that may consist of: Chips/Crackers, Candy bars, Cans of Pop, Cookies. All perfect things to keep your blood-sugar levels high, and keep you pumped up.
Our intent is not to make a profit, so all profits from the food ticket sales will be used for filling up those goody-bags and purchasing meals.
| Team Name | Average Trophies |
|---|---|
| AESTHETIC YUUSHA | 65.2666 | Byte-Le Royale | 59.3666 |
| Dean of Lean Greens | 53.6666 |
| Has Sentient AI | 52.0333 |
| Team Shire | 47.2666 |
| Spaghet Code | 43.2 |
| Team HuyaBooyahJewyaaaaa | 42.1333 |
| Team Wubalubadubdub | 42.1333 |
| Green Viper | 41.7333 |
| Wholesale Whales | 39.900 |
| Team TheTeam | 34.4333 |


Grindcore as a music genre
This website is dedicated to the exploaration of music genre called Grindcore. Grindcore is very extreme genre of music. Taste for grindcore music is usually an acquired taste, meaning it does not come naturally for most of the people. According to Wikipedia article on this genre:
Grindcore is an extreme fusion genre of heavy metal and hardcore punk that originated in the mid-1980s, drawing inspiration from abrasive-sounding musical styles, such as: thrashcore, crust punk, hardcore punk, extreme metal, and industrial. Grindcore is characterized by a noise-filled sound that uses heavily distorted, down-tuned guitars, grinding overdriven bass, high speed tempo, blast beats, and vocals which consist of growls and high-pitched shrieks.
Grindcore is a very niche genre with relatively small amounts of listeners as it is very extreme. However, it does not mean that the genre is monotonous or dull.
Deathgrind and Goregrind
Death grind is a mixture of death metal genre and grindcore. It usually has more down-tuned guitars than regular a grindcore. It more relies on growls and low-pitched scream.
Goregrind most of the times can be characterized as deathgrind by its sound. The difference is that this microgenre relies on lyrics that depict gore and forensic pathology. The most credited band for microgenre emergence is British band Carcass, specifically, their early albums.
Coprogrind and Pornogrind
These microgenres in their sound do not differentiate from grindcore. Their major difference is their lyrical themes. Coprogrind relies on excrements and defecation, while pornogrind usually depicts pornography and perversion.
Noisegrind
The most prominent difference is Noisegrind's sound quality. It is usually heavily distorted and additional noise added to it, sometimes excessively. Most bands record their music at a very low quality. The music value of addition of noise to the music is very questionable as noise has no melody, temp or structure. The use of noise can be explained by the DIY mentality of the musicians and their preference for, as they call it, "raw" and unprocessed sound.


General Instructions
Eligible applicants are invited to personally submit online applications on all days during June 27th 2011 to July 18th, 2011 (up to 5.00 p.m.) in the prescribed online format available at www.thapar.edu for the following categories of posts with payment, mode as prescribed:-
The details of the posts, qualifications, category of persons are as under:
Assistant Environmental Engineer
Junior Environmental Engineer
Scientific Assistant
Instructions for filling the online form
1. Candidate can apply online from anywhere where there is an access to the Internet.
2. Before submitting the online application, prepare a Demand Draft of requisite amount
Application Fee:
General: Rs. 500/-(Five Hundred Only)
SC/ST: Rs. 125/-(One Hundred Twenty Five Only)
Mode of Payment:-
Application fee to be deposited through a bank Demand Draft (DD) drawn in favour of “Coordinator, Entrance Test for PPCB” payable at Patiala.
Note: The candidates applied earlier for the post of Scientific Assistant against advertisement given in August 2008 by the Board need not to apply again as the same shall be considered. However, they are required to submit a copy of their earlier deposited form along with a DD of the balance amount as per details below:
General Category: Rs. 400/-
S.C./S.T./: Rs. 100/-
3. Complete the form available on the website www.thapar.edu by clicking at the link “Recruitment of various posts for Punjab Pollution Control Board”.
4. Every successful registration will be allotted a Registration No. printed on the acknowledgement slip.
5. Get a print out of the successful registered application form.
6. Take a print out of Registration form and send it to Coordinator, Entrance Test for PPCB, Thapar University, Patiala – 147004, along with DD of requisite amount ,one photograph ,Copy of experience certificates(if any), educational certificates and proof of category except general at the earliest , last date of receiving complete documents is 25 July 2011.
7. Incomplete form or forms filled with wrong information will stand automatically cancelled/ rejected and shall not be considered for further processing.
8. Candidates may apply for more than one post by submitting separate application for each post along with separate processing fee.
9. For any help, please contact us at<EMAIL_ADDRESS>10. Only Online registered application forms will be entertained.
11. The “Date of Birth” that you mention is this Online form should be same as mentioned in your School Leaving / Birth Certificate. If there is any mismatch found during physical verification of the documents , your candidature would stand cancelled.
12. Please check the form once completely before final submission, as once you "SUBMIT" the form, it won't allow you to modify any field. After clicking on "SUBMIT", you can only PRINT the form, you cannot modify the data.
13. After entering all mandatory information correctly, once you click on "SUBMIT" button the system shall send you an email and will take you on a page containing your Login ID and password. Please ensure you keep these details with you safely for future use.
14. Once your application form with all the necessary document will received then your admit card will generate automatically in your login and also a confirmation email will be sent to you.
15. Customer Care : For any Technical queries contact on<EMAIL_ADDRESS>NOTE:
1. Candidates will be called for original documents inspection as per category wise merit list with 50% extra waiting list on an appointed day in person before a high level committee at a specified place before issue of appointment letters. Failure of any candidate to come personally with all complete original documents shall lead to forfeiture of his claim and the next candidate on merit shall be considered their and then. There shall be NO EXTENSION OF DATE WHATSOEVER UNDER ANY CIRCUMSTANCES.
2. The recruitment SHALL BE MADE SUBJECT TO 100% VERIFICATION of DEGREES & CERTIFICATES from issuing authorities within six months and SHALL BE LIABLE TO BE DECLARED NULL AND VOID ABINITIO WITHOUT ANY NOTICE WHATSOEVER IN CASE ANY DOCUMENT IS FOUND FAKE OR FORGED. The department shall also without fail launch against such candidates suitable criminal proceedings besides civil proceedings to make recoveries of salary and other emoluments paid to such candidates.
Other inportant documents
General Information regarding entrance test
Syllabus for entrance exam
Official Advertisement
General Conditions
Special Conditions
Mode of selection
Make sure you read the above instruction, and check which categories are available for your application. Once done you can proceed to fill the online application


|
Packages |
| de.uni.bamberg.wiai.minf.forflow.datagenerator |
The entry point of the data generator application; it contains the main method. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller |
Represents the controller of the MVC pattern; it's not allowed to get access to the data model directly, instead
use this package to do so. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.algorithm |
Used algorithms are put in here. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.boot |
Links to external files are defined here; a file is said to be external, if and only if
it doesn't reside in a *.jar file. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.datageneration |
Everything needed to generated proper data is seeded in this package. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.datageneration.dependency |
Some attributes (facets) rely on values of other attributes; in other words, the depend on those attributes. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.datageneration.distribution |
To make data generation flexible and not static, random data is used;
This data is calculated by probability distributions. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.datageneration.filltype |
Specifies different types to 'fill' attributes with data or values, respectively. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.datageneration.unit |
A unit is a standardized weight or measurement that describes the generated entity more precisly. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.io |
Everything that has to do with serialization or deserialization is in this package. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.log |
This package is responsible for handling exceptions and errors. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.controller.worker |
Long running background tasks for I/O, database or any other computational intensive
task are separated from the EDT. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.model |
Represents the data model of MVC pattern; therefore, the data structures used in this application are stored here. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.model.datastructure |
Contains the Meta-Meta-Model artefact class describing the EMF Ecore Meta-Model. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.view |
Represents the view of the MVC pattern and interacts with the user through a UI. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.view.dialog |
All dialog frames are in this package. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.view.graph |
Graphical components to visualized all sorts of things; here it
visualizes probability functions. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.view.message |
Messages caused either due to errors, information, input, query etc are
created with predefined methods. |
| de.uni.bamberg.wiai.minf.forflow.datagenerator.view.util |
Utilities which are used by the view layer, but do not fit into any of the
previous packages. |


{% include 'head.html' %}
Sokim is an online implementation of the board game 'Dixit' (pronouced Diceit) Starting: Every player draws 6 paintings. Decide who will start Game Loop: The current 'storyteller' chooses a painting and describes it to the other players. They then place their card face down on the table. The other players now choose a card which they think will stump the others. Once everyone places in a card, they are flipped. All players vote anonymously on which card they believe was the storyteller's.(You cant vote for your own image) Scoring: If all players have found the correct image or none did: everyone but the storyteller gets two points else: storyteller gets 3 points each player who guessed correctly gets 3 points All players but the storyteller get a bonus point for anyone who guessed their painting. Game End: The game ends when the deck runs out, or a person hits 30 points the game ends. Player with the most points wins.


|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use Word | |
|---|---|
| net.sf.extjwnl.data | Classes for extracting and containing data from the dictionary. |
| net.sf.extjwnl.data.list | Lists and associated classes that hold the results of relationship operations. |
| net.sf.extjwnl.dictionary | Classes for accessing dictionary information. |
| net.sf.extjwnl.princeton.data | Implementations of DictionaryElementFactory for Princeton's release of WordNet. |
| Uses of Word in net.sf.extjwnl.data |
|---|
| Subclasses of Word in net.sf.extjwnl.data | |
|---|---|
class |
Adjective
An Adjective is a Word that can have an adjective position. |
class |
Verb
A Verb is a subclass of Word that can have 1 or more
VerbFrame s (use cases of the verb). |
| Methods in net.sf.extjwnl.data that return types with arguments of type Word | |
|---|---|
List<Word> |
Synset.getWords()
|
| Uses of Word in net.sf.extjwnl.data.list |
|---|
| Methods in net.sf.extjwnl.data.list that return Word | |
|---|---|
Word |
PointerTargetNode.getWord()
If the target is a word, return it, otherwise return null. |
| Uses of Word in net.sf.extjwnl.dictionary |
|---|
| Methods in net.sf.extjwnl.dictionary that return Word | |
|---|---|
Word |
Dictionary.getWordBySenseKey(String senseKey)
Returns a word by specified senseKey or null if not found. |
| Uses of Word in net.sf.extjwnl.princeton.data |
|---|
| Methods in net.sf.extjwnl.princeton.data that return Word | |
|---|---|
protected Word |
AbstractPrincetonDictionaryElementFactory.createWord(Synset synset,
int index,
String lemma)
Creates a word. |
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |


ABAP Quick Fixes - Remove Line Break at End of Statement
This small quick fix moves the dot "." to end of statement if it is placed in the next line.


This sets how the value generated by the optional {_ribbon} controller is affected by touching, sliding, and releasing.
| short release | When the ribbon is touched, that position is defined as zero, and all values are relative to that position. The \+1 {_unit} range equals 1/16 of the physical length of the ribbon, so small gestures are all that is needed. When the ribbon is released, the value resets to zero. | |
| short hold | Same as short release, but the value remains where it is when the ribbon is released. | |
| short smooth | Same as short hold, but the initial touch point is defined as the current value, so only sliding changes the value. | |
| medium \. | Same as the short versions, but the \+1 unit range equals one quarter of the physical length of the ribbon. | |
| long \. | Same as the short and medium versions, but the \+1 unit range equals the full physical length of the ribbon, so large gestures are usable, and fine resolution is achievable. | |
| fixed release | The \+1 unit range maps directly to the position along the full ribbon, so touching the ribbon immediately jumps to that value. When the ribbon is released, the value resets to zero. | |
| fixed hold | Same as fixed release, but the value remains where it is when the ribbon is released. |
This is contained in the {Common_controllers_cluster controllers cluster} within the {Common_section}.
This is contained in the CONTROL section of the right panel, under the following parameter number:
| {sw-5.png height=48} |
This appears in the display as Ribbon Algorithm.
This is accessed via {_NRPN} 0,14.
| MIDI | display | ||
| 0 | short release | (default) | |
| 1 | short hold | ||
| 2 | short smooth | ||
| 3 | medium release | ||
| 4 | medium hold | ||
| 5 | medium smooth | ||
| 6 | long release | ||
| 7 | long hold | ||
| 8 | long smooth | ||
| 9 | fixed release | ||
| 10 | fixed hold |


Programming language: on building Lisp, falling out of grace and reviving in the JVM ecosystem.
https://www.se-radio.net/2008/01/episode-84-dick-gabriel-on-lisp/
https://www.se-radio.net/2010/03/episode-158-rich-hickey-on-clojure/
Data Engineer
Programming language: on building Lisp, falling out of grace and reviving in the JVM ecosystem.
https://www.se-radio.net/2008/01/episode-84-dick-gabriel-on-lisp/
https://www.se-radio.net/2010/03/episode-158-rich-hickey-on-clojure/


Purging Weapon
Even though Gladiators are not particularely religious, they learned how to infuse their weapon with the power of a combat blessing that makes it surprisingly effective against dark creatures.
+${value} Damage to Demon & Undead
8 12 16 20 24 28 32 36 40 44 48 52
+${value}% Damage to Demon & Undead
10 18 26 34 42 50 58 66 74 82 90 98
MaxLevel
8
UltimateLevel
12


{# # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. -#} {% extends "base.html" %} {% block title %}{% trans orgname=organization.display_name %}Profile of {{ orgname }}{% endtrans %}{% endblock %} {% block content %}
{{ project.releases[0].summary }}
{% endfor %} {% else %}{% trans org=organization.display_name|default(organization.name, true) %}{{ org }} has not uploaded any projects to PyPI, yet{% endtrans %}


Created by Jaclyn Ciringione May 25, 2017 as practice using Angular2 and the Spotify API v1. Thanks for viewing!


A Generic Process to Use Distributed ZOOpt¶
A Brief Introduction to ZOOclient Components¶
In ZOOclient, an optimization problem is abstracted in several
components: Objective
, Dimension
, Parameter
, and
Solution
, each is a Julia type.
An Objective
object is initialized with a Dimension
object as
the input, where the Dimension
object defines the dimension size and
boundaries of the search space. A Parameter
object specifies
algorithm parameters. The zoo_min
function makes the optimization
happen, and returns a Solution
object which contains the final
solution and the function value. Moreover, after the optimization, the
Objective
object contains the history of the optimization for
observation.
A Generic Process to Use Distributed ZOOpt¶
The Generic process to use Distributed ZOOpt contains five steps:
- Start the control server (ZOOsrv)
- Start the evaluation servers ( ZOOsrv)
- Define the objective function
- Run Julia client code ( ZOOclient)
- Define a
Dimension
objectdim
, then usesdim
to construct anObjective
object - Define a
Parameter
objectpar
- Use
zoo_min
to optimize - Run client code
- Shut down evaluation servers and the control server (ZOOsrv)
The step 1 and the step 2 can be omitted if the servers have been started. Commonly the step 4 is executed several times for different tasks. The step 5 could be executed only when users do not want to run client code any more.
Users carry out step 1, 2 and 5 on general servers and step 3 and 4 for specific tasks.
Details of the Generic Process¶
Start the control server
Users should provide a port to start the control server.
from zoosrv import control_server
# users should provide the port occupied by the control server
control_server.start(20000)
Start the evaluation servers
Users should provide a configuration file to start the evaluation servers.
from zoosrv import evaluation_server
evaluation_server.start("evaluation_server.cfg")
configuration file is listed as follows:
[evaluation server]
shared fold = /path/to/project/ZOOsrv/example/objective_function/
control server ip_port = <IP_ADDRESS>:20000
evaluation processes = 10
starting port = 60003
ending port = 60020
shared fold
indicates the root directory your julia client and
evaluation servers work under. The objective function should be defined
under this directory. constrol server's ip_port
means the address of
the control server. The last three lines state we want to start 10
evaluation processes by choosing 10 available ports from 60003 to 60020.
Define the objective function
An objective function should satisfy the interface
def func(solution):
, where solution
is a Solution
object
that encapsulates x and f(x). In general, users can custom their
objective function by
def func(solution):
x = solution.get_x() # fixed pattern
value = f(x) # function f takes a vector x as input
return value
In the Sphere function example, the objective function looks like
def sphere(solution):
x = solution.get_x()
value = sum([(i-0.2)*(i-0.2) for i in x]) # sphere center is (0.2, 0.2)
return value
Run Julia client
- Define a
Dimension
objectdim
, then usesdim
to construct anObjective
object.
Dimension
type looks like
type Dimension
size::Int64
regions
types
end
size
is an integer indicating the dimension size. regions
is a
list that contains the search space of each dimension (search space is a
two-element list showing the range of each dimension, e.g., [-1, 1] for
the range from -1 to 1). tys
is a list of boolean value, True
means continuous in this dimension and False
means discrete.
In the Sphere function example, dim
looks like
dim_size = 100
dim_regs = [[-1, 1] for i = 1:dim_size]
dim_tys = [true for i = 1:dim_size]
mydim = Dimension(dim_size, dim_regs, dim_tys)
Then use dim
to construct an Objective
object.
obj = Objective(mydim)
- Define a
Parameter
objectpar
The type Parameter
defines all parameters used in the optimization
algorithms. Commonly, five parameters are needed to be manually
determined by users. Respectively are budget
,
evaluation_server_num
, control_server_ip_port
,
objective_file
and func
.
# budget: the number of calls to the objective function
# evalueation_server_num: the number of evaluation servers
# control_server_ip_port: the ip:port of the control server
# objective_file: the objective funtion is defined in this file
# func: the name of the objective function
par = Parameter(budget=10000, evaluation_server_num=10, control_server_ip_port="<IP_ADDRESS>:20000",
objective_file="fx.py", func="sphere")
- Use
zoo_min
to optimize
sol = zoo_min(obj, par)
# print the Solution object
sol_print(sol)
- Run client code
$ ./julia -p 10 /path/to/your/clent/code/client.jl
Starting with julia -p n
provides n
worker processes on the
local machine. Generally it makes sense for n
to equal the number of
CPU cores on the machine.
- Shut down evaluation servers and the control server
The control server process can interact with users. The evaluation processes should be shut down by the control server. Otherwise, later tasks will receive the ip:ports of invalid evaluation processes. A simple example to shut down servers is listed here.


Public repository for open sources projects brought to you by CET Electronics.
Featuring .Net, Windows Phone, Windows RT, .Net Micro Framework and several related technologies.
http://www.cet-electronics.com/
| RTU (Binary) | TCP | UDP | ||||
|---|---|---|---|---|---|---|
| Master | Slave | Master | Slave | Master | Slave | |
Desktop .Net 4.5 |
||||||
WP 7.5 |
n/a |
n/a |
(details) |
n/a |
(details) |
n/a |
WP 8 |
n/a |
n/a |
(details) |
n/a |
(details) |
n/a |
Windows RT |
n/a |
n/a |
coming soon |
n/a |
coming soon |
n/a |
.Net Micro 4.1(Netduino/Fez) |
(details) |
(details) |
(details) |
(details) |
(details) |
(details) |
.Net Micro 4.2(Netduino Plus 2) |
(details) |
(details) |
(details) |
(details) |
(details) |
(details) |
New features:
Coming shortly:
| RTU (Binary) | TCP | UDP | ||||
|---|---|---|---|---|---|---|
| Master | Slave | Master | Slave | Master | Slave | |
Desktop .Net |
planned for version 2 |
planned for version 2 |
planned for version 2 |
planned for version 2 |
planned for version 2 |
planned for version 2 |
Windows Phone 7.5 |
n/a |
n/a |
(details) |
n/a |
(details) |
n/a |
.Net Micro 4.1(Netduino/Fez) |
(details) |
(details) |
(details) |
(details) |
(details) |
(details) |


Google Chrome Extension for improved productivity for surfing the Web. Making popup window with content when mouse over the link.


I shared a post yesterday about going to Taipei Main Station. The main purpose of that trip is to buy Gundam model for my son. My friend gave him a box of GD as a gift last year and we did not let him open it until this weekend. He was crazy about it and we thought it’s a great toy for developing his 3-D sense so we decided to get more - from TMS obviously.
昨天分享了到台北車站的所見所吃，其實，最主要的目的就是幫兒子買鋼彈模型。我一個朋友去年送過他一盒鋼彈，我們一直沒讓他打開，直到前天晚上，他超級愛的，很快就組合好，我們覺得這玩具不錯，可以培養空間感，所以決定幫他再買些。
This is my son’s very first GD robot in his life - Crossbone GUNDAM.
下面這一隻就是他人生的第一隻鋼彈機器人，Crossbone GUNDAM。
We found from internet about where to get these GD babies. One store is located in the Area Y of TMS underground mall.
我們從網路上鎖定一家買鋼彈的好地方，就是在台北地下街的Y區。
Not many, but also not entirely without, people.
人不多，但也不是很少。
So this is a place where teenager toy stores abound.
顯然這附近都是大小朋友的玩具販賣專區。而小朋友們還不太怕病毒。
This is it - the “Toy Park”. We are here.
就是這一間Toy Park. 進去看看！
Full of models and kids’ dreams.
好多貨，玩具或是夢想？
Still many customers. Young kids are afraid of nothing, or, lack of toys. Not virus definitely.
不少客人，年輕人什麼都不怕，只怕沒玩具玩吧，病毒肯定是不怕的。
Fulfilled dreams inside the window.
夢想的完成品，展示中。’
Dragon ball characters.
七龍珠的人物。
We bought him and our nephews some boxes of GDs. Congrats to him for becoming one of the Gundamers!! ^_^
恭喜我兒正式進入鋼彈迷行列。我個人小時候是不曾玩過，只組過其他模型。所以，也跟著看看玩玩吧~~~
This page is synchronized from the post: ‘The Road to GUNDAM 到鋼彈之路’


Michael "Migo" Gaultney
GitHub Username: mjgaultney
First off, I hope that you enjoy my first website layout and navigation. In case you missed the few times my name has been plastered around the webpage, my name is Michael and I am a first time web development student. The course began in December of 2020 and will last 32 weeks covering a variety of subjects related to web development. I was born on the Texas coast but have spent most of my adult life traveling either for pleasure or for volunteer work. I have always been interested in computers and coding however never had an opportunity to spend proper time learning the subject. This opportunity came in the midst of COVID-19 and I have been enjoying it since the start. It is a lot to learn and comes with many frustrations but, again, fun nonetheless.
I currently live in Dallas, TX and have part time jobs until I can get my career on the move with the knowledge and skills to be learned in this course.
If you have any questions please feel free to contact me by LinkedIN on the left navigation link or by clicking the email button.