Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement configuration #26

Closed
ionut-arm opened this issue Oct 9, 2019 · 5 comments
Closed

Implement configuration #26

ionut-arm opened this issue Oct 9, 2019 · 5 comments
Assignees
Labels
enhancement New feature or request
Projects

Comments

@ionut-arm
Copy link
Member

Implement a configurator module whose task is to spin up all the system components, given a TOML configuration.

Proposing the following changes:

  • Implement and expose a configuration structure for each component that needs configuring
  • Add said structure to the Builder of the component so that build() results in a fully configured module
  • Implement the configurator to pick up a TOML tree structure, parse it into its components and initialise everything in the right order
  • Move system spin-up from main to the configurator, which returns the assembled service ready to be run

Example configuration file:


  # PARSEC Service Configuration File

  title = "Parsec Config"

  [listener]
  socket_path = "/tmp/security-daemon-socket"
  socket_timeout = 100

  [[key_id_manager]]
  type = "ondisk"
  name = "on-disk-manager"
  path = "~/.parsec/key_ids/"

  [[provider]]
  type = "mbed-userspace"
  persist_keys = true
  key_id_manager = "on-disk-manager"
  converter = "protobuf"

  [[key_id_manager]]
  type = "mongo"
  name = "mongo-manager"
  address = "127.0.0.1:27017"

  [[provider]]
  type = "pkcs11"
  key_id_manager = "mongo-manager"
  converter = "protobuf"

  [[authenticator]]
  type = "simple"
  default_app_name = "root"

  [[authenticator]]
  type = "jwt"

Outstanding questions:

  • What should be the final structure of the config file?
  • Should we move to generating provider ID dynamically?
  • Do we offer the option of setting the provider ID in the configuration?
  • What happens if we have duplicate authenticators? (e.g. two "simple" authenticators with different default app names?)
  • Do we allow defaulting of parameters? (e.g the converter for providers would always be "protobuf", at least for a while)
@hug-dev hug-dev added the enhancement New feature or request label Oct 9, 2019
@hug-dev
Copy link
Member

hug-dev commented Oct 9, 2019

The idea sounds good to me!

  • What should be the final structure of the config file?

An alternative structure with indentation would be:

[providers]
  [providers."mbed-with-persistence"]
  type = "mbed-userspace"
  persist_keys = true
  key_id_manager = "on-disk-manager"
  converter = "protobuf"

  [providers."mbed-without-persistence"]
  type = "mbed-userspace"
  persist_keys = false
  key_id_manager = "on-disk-manager"
  converter = "protobuf"

The names mbed-wth-persistence are not needed for this file but could be logged somewhere and provide a way to add indentation on this file. I don't know which one is more readable.
In the listener section there should probably be a type as well in case different listeners are implemented?

  • Should we move to generating provider ID dynamically?

I think it could be done in a later change with its specific design for simplicity.

  • Do we offer the option of setting the provider ID in the configuration?

As the Key ID Manager uses the Provider ID in the path where it stores the Key ID mappings, a provider needs to have the same ID when the service restarts. For this reason, I guess it is a good idea to explicitely set an ID in the configuration.

  • What happens if we have duplicate authenticators? (e.g. two "simple" authenticators with different default app names?)

Forbid having duplicate authenticators?

  • Do we allow defaulting of parameters? (e.g the converter for providers would always be "protobuf", at least for a while)

I am in favor of that.

@hug-dev hug-dev added this to To do in Parsec Oct 10, 2019
@hug-dev
Copy link
Member

hug-dev commented Oct 15, 2019

Aside note:

From man page daemon (7), it is said that systemd daemons can receive the SIGHUP signal to reload their configuration.
I am unsure of the security implications of that but for example, when this signal is received the threads could be joined, the current instances could be dropped and the configurator could be called again. That would be a nice feature 🍸

@hug-dev
Copy link
Member

hug-dev commented Oct 21, 2019

As per #50 it would be nice to add a logging option in the configuration that contains a binary option to have or not timestamps in the logs. I think by default it should be disabled.

@hug-dev
Copy link
Member

hug-dev commented Oct 22, 2019

Is there more work to do after #51 ?

@ionut-arm
Copy link
Member Author

I think the work done so far should cover this issue. If we need to do more things we can raise new issues specific to what other configurables will be added.

Parsec automation moved this from To do to Done Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

3 participants