Uploaded image for project: 'SignServer'
  1. SignServer
  2. DSS-818

TimeMonitor should be able to query a SignServer worker for its configuration

    Details

      Description

      Currently the TimeMonitor application has its own configuration in a Properties file. This requires shell access to configure the application. It also does not allow the application to be re-configured at runtime without restarting it.

      Implement support in the TimeMonitor for having a thread periodically calling a worker in SignServer to get the latest configuration. Some ID/versioning scheme (could be a random number) could be used so the configuration is only sent if it has actually changed. If the configuration has changed the config thread will flag that there is a new configuration available and the TimeMonitor main thread will start use it in the next appropriate time (ie on next round).

      The new worker, lets call it TimeMonitorManager, will host the time monitor configuration as part of its worker configuration for instance prefixed with "TIMEMONITOR.". Its fatalErrors should check that all required properties are available etc. The getStatus page should include the latest status from the TimeMonitor. To not have to create a connection back to the time-monitor from SignServer this information could be posted back to SignServer together with the status property update. A new StatusProperty could hold this information to present in the GUI.
      Also useful for the GUI would be the last say 10-20 log entries from the TimeMonitor, maybe an additional status property could hold this. If it turns out to be bad for performance, sending this could be done less frequent say only when the configuration is re-checked every 5 minutes or so (future ticket).

      Also update the status page output so it includes the configuration version (id/random number) so the TimeMonitorManager can output if the configuration used is the latest. The status line should also contain the measured execution times so the admin can adjust the time values accordingly.

      Add an additional property in the TimeMonitor properties file to enable this mode of getting the config from SignServer: signserver.mangedconfig=true/false. When this property is not set or set to false SignServer is not queried for the configuration. When the property is set the timemonitor starts disabled and queries SignServer for a new config every 15 seconds. It will not start query any time server until it gets an updated config from SignServer.

      If the TimeMonitor anyway gets a bad configuration it should log this, act as disabled and use a hardcoded safe value for how often to query for new configuration (15 s).

      Some properties should not be possible to change this way and should still only be available in the properties file:

      • The URL to SignServer, if this gets mis-configured it will not be possible to change back (without shell access). Also this should probably not be changed. It is also needed when the application is started.
      • The periodicity of which the configuration is changed, if this is set to a high value it can not be changed before this time has elapsed. However, as the configuration is always read at startup maybe it is enough that one can get out of this situation by restarting the TimeMonitor (or the server).
      • The NTP binaries to run should not be configurable
      • The stateweb properties are not expected to be changed frequently so those does not have to be available for config at this stage
      • The TimeMonitorManager should also have the functionality of the StatusPropertiesWorker when it comes to updating the TIMESOURCE0_INSYNC and LEAPSECOND properties, removing the need to configure an additional worker.

      Other issues

      • We need an additional worker to offer the stateweb page and have the possibility to do authorization and logging etc. This could be implemented in a separate worker "TimeMonitorStatusReportWorker".

      Cluster: Multiple nodes sharing database:

      • In the same way as for PCI HSM:s; each node has its own TimeMonitor application running and calling its SignServer
      • Limitation: Currently each node will have the same configuration
      • Limitation: The TimeMonitorManager only shows the time-source/TimeMonitor status and logs for its TimeMonitor and administrator thus needs to login to attend to the other nodes for their statuses
      • Future improvement: Host-specific configuration properties could be specified
      • Alternatively: Somehow have one TimeMonitorManager per node. Problem: How to name them?, use nodeid but how can admin easily discover available nodeids? Maybe have a nodes-list in GlobalConfiguration where each node adds itself during startup and then have a master TimeMonitorManager displaying available nodes and a config mapping those nodes to individual TimeMonitorManagers?
      • TODO: The current notion on config version is based on WorkerConfig.hashCode and this might not yield the same value on different servers but should not be a problem as the TimeMonitor is only talking to its SignServer. Alterantives could be to instead use something like a hash of all configuration keys+values to be sure the same configVersion is used everywhere. An other alternative could be to store the configVersion hidden in the WorkerConfig UpgradeableHashMap. When we have a proper rowVersioning scheme in the database that could be used. For now the hashCode should be enough.

      The current time offset should also be included in the status page and in the state line.

      TimeMonitor should still work with the StatusPropertiesWorker.

      QA:

      • Should test in cluster as well.

        Attachments

          Activity

            People

            Assignee:
            markus Markus Kilås
            Reporter:
            markus Markus Kilås
            Verified by:
            Marcus Lundblad
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Time Spent - 1 week, 2 days, 2 hours, 30 minutes Remaining Estimate - 2 hours
                2h
                Logged:
                Time Spent - 1 week, 2 days, 2 hours, 30 minutes Remaining Estimate - 2 hours
                1w 2d 2h 30m