Xroad Gps Map Update
Beatris Ninh
In the previous versions of X-Road, the service configuration overrides have been stored in /etc/xroad/services/local.conf. The file can contain environment variables and executable code which is a security problem.
In X-Road 7, the service configuration override mechanism is changed. The overrides are stored in non-executable /etc/xroad/services/local.properties. The file may only contain configuration overrides to predefined environment variables and everything else is ignored. Also, the format and the names of X-Road's environment variables will be different. Starting from version 7.0.0, all the variables are prefixed with XROAD_. For example, the difference in customizing memory allocation for proxy in X-Road 6 and X-Road 7:
Despite the changes, when upgrading from version 6 to 7, all overrides defined in /etc/xroad/services/local.conf will continue to work as before, including the old environmental variable names. However, starting from X-Road 7.0.0, the backups no longer contain the /etc/xroad/services/local.conf file, but instead the /etc/xroad/services/local.properties file will be included. It means that in case a Central Server or Security Server is restored from a backup, all local configuration overrides defined in /etc/xroad/services/local.conf are lost. Security Server user interface and command-line scripts related to backups warn about this.
It is strongly recommended to migrate all configuration overrides to the new /etc/xroad/services/local.properties file when upgrading from version 6 to 7. There's no automation in the migration and therefore, migrating the configuration overrides must be done manually by the administrator. The migration includes changing the variable names to the new XROAD_ prefixed format and updating the values according to the new properties format. In case the old /etc/xroad/services/local.conf configuration file contains something else than modifications to X-Road-related environmental variables, the changes must be handled in some other way since the new configuration override mechanism doesn't support them.
In X-Road 7, the /etc/xroad/services/local.properties file must have one environment variable per line and the properties related to the variable cannot be splitted over multiple lines using "\".
3. After the variables have been migrated, delete the old configuration file e.g. rm /etc/xroad/services/local.conf, and restart the xroad-* services or the Security Server host server.
Security Server message log archiving has been moved to a separate process xroad-addon-messagelog.service that logs into /var/log/xroad/messagelog-archiver.log. Monitoring systems need to be configured to take into account the new service and the log file in addition to the old ones.
No separate action is needed due to this change for new installations. After upgrading to 7.0.0 on RHEL platform, the new service needs to enabled (systemctl enable xroad-addon-messagelog) and started (systemctl start xroad-addon-messagelog) separately.
Optionally, the security server can use a remote database server. To avoid installing the default local PostgreSQL server during security server installation, install the xroad-database-remote -package, which will also install the PostgreSQL client and create the xroad system user and configuration directories (/etc/xroad).
Issue the following command to install the security server packages (use package xroad-securityserver-ee to include configuration specific to Estonia; use package xroad-securityserver-fi to include configuration specific to Finland; use package xroad-securityserver-is to include configuration specific to Iceland):
By default, xroad-proxy listens for consumer information system connections on ports 8080 (HTTP) and 8443 (HTTPS). To use standard HTTP(S) ports 80 and 443, verify that the ports are free, and make the following modifications:
The support for environmental monitoring functionality on a security server is provided by package xroad-monitor that is installed by default. The package installs and starts the xroad-monitor process that will gather and make available the monitoring information.
It is possible to automatically encrypt security server configuration backups. Security server uses The GNU Privacy Guard ( )for backup encryption and verification. Backups are always signed, but backup encryption is initially turned off.To turn encryption on, please override the default configuration in the file /etc/xroad/conf.d/local.ini, in the [proxy] section (add or edit this section).
To turn backup encryption on, please change the backup-encryption-enabled property value to true.By default, backups are encrypted using security server's backup encryption key. Additional encryption keys can be imported in the /etc/xroad/gpghome keyring and key identifiers listed using the backup-encryption-keyids parameter. It is recommended to set up at least one additional key, otherwise the backups will be unusable in case security server's private key is lost. It is up to security server's administrator to check that keys used are sufficiently strong, there are no automatic checks.
An alternative approach to the previous command is to temporarily configure the server to use a repository that contains only the specific version of X-Road software we want to upgrade to. For example, configure the repository as -release-rpm/rhel/7/7.1.0 and then use the yum update xroad-securityserver command.
Edit /etc/xroad.properties and add/update the following properties (if you customized the role names, use your own). The admin users are used to run database migrations during the install and upgrades.
Edit the /etc/xroad/db.properties file and add/update the following connection properties (if you customized the database, user, and/or role names, use the customized values).The database connection url format is jdbc:postgresql://:/
Previously, any external modification to /etc/xroad/signer/keyconf.xml was overwritten by the X-Road signer process ifit was running. Therefore, replicating the signer configuration without service disruptions would have required taking thecluster members offline one-by-one. The load balancing support adds the possibility for external modifications to thekeyconf.xml to be applied on secondary nodes without service disruptions. The actual state replication is done with a scheduledrsync over ssh. This might take a few minutes so a slight delay in propagating the changes must be tolerated by theclustered environment. A small delay should usually cause no problems as new keys and certificates are unlikely to be usedimmediately for X-Road messaging. Changes to the configuration are also usually relatively infrequent. These were one ofthe basic assumptions about the environment.Users should make sure this holds true for them.
Install security server packages using the normal installation procedure. Alternatively you can also install only the packagesrequired for secondary nodes. xroad-proxy-ui-api package can be omitted, but the admin graphical user interface(which is provided by this package) can be handy for diagnostics. It should be noted that changing a secondary'sconfiguration via the admin gui is not possible (except entering token PIN).
Change /etc/xroad/db.properties to point to the separate database instance and change password to match the onedefined in the primary database (the password is part of the data that is replicated to the secondaries).
After removing these groups, the super user created during the security server installation is a member of two UI privilege groups: xroad-securityserver-observer and xroad-security-officer. These groups allow read-only access to the admin user interface and provide a safe way to use the UI for checking the configuration status of the secondary security server. In addition, the groups allow the user to enter the token PIN code. Since admin UI users are UNIX users that are members of specific privilege groups, more users can be added to the groups as necessary. Security server installation scripts detect the node type of existing installations and modify user group creation accordingly. Instead, version upgrades do not overwrite or modify this configuration during security server updates.
Also, the secondary security server's management REST API can be used to read the secondary's configuration. However, modifying the secondary's configuration using the management REST API is blocked. API keys are replicated from the primary to the secondaries, and the keys that are associated with the xroad-securityserver-observer role have read-only access to the secondary. In addition, the keys that are associated with the xroad-securityserver-observer and xroad-security-officer roles, are able to enter token PIN codes. The keys that are not associated with the xroad-securityserver-observer role, don't have any access to the secondary. See next item for more details.
Note about API keys and caching.If API keys have been created for primary node, those keys are replicated to secondaries, like everything else from serverconf database is.The keys that are associated with the xroad-securityserver-observer role have read-only access to the secondary.Instead, the keys that are not associated with the xroad-securityserver-observer role, don't have any access to the secondary and API calls will fail.To avoid this, secondary REST API should only be accessed using keys associated with the xroad-securityserver-observer role, and only for operations that read configuration, not updates.
Furthermore, API keys are accessed through a cache that assumes that all updates to keys (e.g. revoking keys, or changing permissions) are done using the same node.If API keys are changed on primary, the changes are not reflected on the secondary caches until the next time xroad-proxy-ui-api process is restarted.To address this issue, you should restart secondary nodes' xroad-proxy-ui-api processes after API keys are modified (and database has been replicated to secondaries), to ensure correct operation.
e2b47a7662