Global config "plugin_trust_level" not used

[mbbroberg]

I built snap off of 170c8d3 and I'm playing around with global configuration settings. I found that one flag, plugin_trust_level, does not get used. Trust level continues to require either a keyring or to be flagged at runtime.

Config file in YAML

---
log_level: 1
plugin_trust_level: 1
plugins:
  collector: {}
  publisher: {}
  processor: {}
tribe:
  enable: false

/snap/snapd --config $PATH/etc/snap/test.yaml
INFO[0000] Starting snapd (version: unknown)
INFO[0000] setting GOMAXPROCS to: 1 core(s)
INFO[0000] Setting work manager queue size               _block=New _module=scheduler value=25
INFO[0000] Setting work manager pool size                _block=New _module=scheduler value=4
INFO[0000] Configuring REST API with HTTPS set to: false  _module=_mgmt-rest
INFO[0000] REST API is enabled
INFO[0000] control started                               _block=start _module=control
INFO[0000] module started                                _module=snapd block=main snap-module=control
INFO[0000] scheduler started                             _block=start-scheduler _module=scheduler
INFO[0000] module started                                _module=snapd block=main snap-module=scheduler
INFO[0000] Starting REST API on :8181                    _module=_mgmt-rest
INFO[0000] REST started                                  _block=start _module=_mgmt-rest
INFO[0000] module started                                _module=snapd block=main snap-module=REST
INFO[0000] setting plugin trust level to: enabled
FATA[0000] need keyring file when trust is on (--keyring-file or -k)  _module=snapd block=main

There may be other issues here.

[mbbroberg]

Doing more testing and finding unexpected behavior. Using an example task file send my way by @tjmcs, I see that gomaxprocs isn't being respected when called as gomaxprocs: 2. See output line that mentions = 1:

./snapd --config $PLAY/SDI/etc/snap/keystone.yaml -t 0
INFO[0000] Starting snapd (version: unknown)
INFO[0000] setting GOMAXPROCS to: 1 core(s)
INFO[0000] Setting work manager queue size               _block=New _module=scheduler value=25
INFO[0000] Setting work manager pool size                _block=New _module=scheduler value=4
INFO[0000] Configuring REST API with HTTPS set to: false  _module=_mgmt-rest
INFO[0000] REST API is enabled
INFO[0000] control started                               _block=start _module=control
INFO[0000] module started                                _module=snapd block=main snap-module=control
INFO[0000] scheduler started                             _block=start-scheduler _module=scheduler
INFO[0000] module started                                _module=snapd block=main snap-module=scheduler
INFO[0000] Starting REST API on :8181                    _module=_mgmt-rest
INFO[0000] REST started                                  _block=start _module=_mgmt-rest
INFO[0000] module started                                _module=snapd block=main snap-module=REST
INFO[0000] setting plugin trust level to: disabled
INFO[0000] auto discover path is disabled
INFO[0000] snapd started                                 _module=snapd block=main
INFO[0000] setting log level to: debug

Config file used here:

---
# log_level for the snap daemon. Supported values are
# 1 - Debug, 2 - Info, 3 - Warning, 4 - Error, 5 - Fatal.
# Default value is 3.
log_level: 1
​
# log_path sets the path for logs for the snap daemon. By
# default snapd prints all logs to stdout. Any provided
# path will send snapd logs to a file called snapd.log in
# the provided directory.
# log_path: /some/log/dir
​
# Gomaxprocs sets the number of cores to use on the system
# for snapd to use. Default for gomaxprocs is 1
gomaxprocs: 2
​
# Control sections for configuration settings for the plugin
# control module of snapd.
control:
  # auto_discover_path sets a directory to auto load plugins on the start
  # of the snap daemon
  # auto_discover_path: /some/directory/with/plugins
​
  # cache_expiration sets the time interval for the plugin cache to use before
  # expiring collection results from collect plugins. Default value is 500ms
  cache_expiration: 750ms
​
  # max_running_plugins sets the size of the available plugin pool for each
  # plugin loaded in the system. Default value is 3
  # max_running_plugins: 1
​
  # keyring_paths sets the directory(s) to search for keyring files for signed
  # plugins. This can be a comma separated list of directories
  # keyring_paths: /some/path/with/keyring/files
​
  # plugin_trust_level sets the plugin trust level for snapd. The default state
  # for plugin trust level is enabled (1). When enabled, only signed plugins that can
  # be verified will be loaded into snapd. Signatures are verifed from
  # keyring files specided in keyring_path. Plugin trust can be disabled (0) which
  # will allow loading of all plugins whether signed or not. The warning state allows
  # for loading of signed and unsigned plugins. Warning messages will be displayed if
  # an unsigned plugin is loaded. Any signed plugins that can not be verified will
  # not be loaded. Valid values are 0 - Off, 1 - Enabled, 2 - Warning
  plugin_trust_level: 0
​
  # plugins section contains plugin config settings that will be applied for
  # plugins across tasks.
  plugins:
    all:
      password: p@ssw0rd
    collector:
      all:
        user: jane
      pcm:
        all:
          path: /usr/local/pcm/bin
        versions:
          1:
            user: john
            someint: 1234
            somefloat: 3.14
            somebool: true
      psutil:
        all:
          path: /usr/local/bin/psutil
    publisher:
      influxdb:
        all:
          server: xyz.local
          password: $password
    processor:
      movingaverage:
        all:
          user: jane
        versions:
          1:
            user: tiffany
            password: new password
​
# scheduler configuration settings contains all settings for scheduler
# module
scheduler:
  # work_manager_queue_size sets the size of the worker queue inside snapd scheduler.
  # Default value is 25.
  # work_manager_queue_size: 10
​
  # work_manager_pool_size sets the size of the worker pool inside snapd scheduler.
  # Default value is 4.
  # work_manager_pool_size: 2
​
# rest sections contains all the configuration items for the REST API server.
restapi:
  # enable controls enabling or disabling the REST API for snapd. Default value is enabled.
  enable: true
​
  # https enables HTTPS for the REST API. If no default certificate and key are provided, then
  # the REST API will generate a private and public key to use for communication. Default
  # value is false
  # https: true
​
  # rest_auth enables authentication for the REST API. Default value is false
  # rest_auth: true
​
  # rest_auth_password sets the password to use for the REST API. Currently user and password
  # combinations are not supported.
  # rest_auth_password: changeme
​
  # rest_certificate is the path to the certificate to use for REST API when HTTPS is also enabled.
  # rest_certificate: /path/to/cert/file
​
  # rest_key is the path to the private key for the certificate in use by the REST API
  # when HTTPs is enabled.
  # rest_key: /path/to/private/key
​
  # port sets the port to start the REST API server on. Default is 8181
  port: 8282
​
# tribe section contains all configuration items for the tribe module
tribe:
  # enable controls enabling tribe for the snapd instance. Default value is false.
  enable: false
​
  # bind_addr sets the IP address for tribe to bind.
  # bind_addr: 127.0.0.1
​
  # bind_port sets the port for tribe to listen on. Default value is 6000
  # bind_port: 16000
​
  # name sets the name to use for this snapd instance in the tribe
  # membership. Default value defaults to local hostname of the system.
  # name: localhost
​
  # seed sets the snapd instance to use as the seed for tribe communications
  # seed: 1.1.1.1:16000

[mbbroberg]

The REST API port is not set either. Setting to port: 8282 and getting binding on 8181.

[IRCody]

I built snap off of 170c8d3 and I'm playing around with global configuration settings. I found that one flag, plugin_trust_level, does not get used. Trust level continues to require either a keyring or to be flagged at runtime.

Config file in YAML

---

log_level: 1
plugin_trust_level: 1
plugins:
collector: {}
publisher: {}
processor: {}
tribe:
enable: false

plugin_trust_level lives under control section. If you move it to that section I believe it will be parsed the way you are expecting.

When plugin_trust is enabled, you must also provide keyring paths through either yaml, command line, or via env variable. (yaml key is `keyrings_paths, also under the control section).

Doing more testing and finding unexpected behavior. Using an example task file send my way by @tjmcs, I see that gomaxprocs isn't being respected when called as gomaxprocs: 2. See output line that mentions = 1:

I'm not able to reproduce this either.

INFO[0000] Starting snapd (version: v0.13.0-beta-73-g170c8d3)
INFO[0000] setting GOMAXPROCS to: 2 core(s)

The REST API port is not set either. Setting to port: 8282 and getting binding on 8181.

I tried this and was unable to reproduce. Mine correctly binds to other ports.

INFO[0000] module started                                _module=snapd block=main snap-module=scheduler
INFO[0000] Starting REST API on :8282                    _module=_mgmt-rest
INFO[0000] REST started                                  _block=start _module=_mgmt-rest

Using the config file:

---
log_level: 1
gomaxprocs: 2
control:
        plugin_trust_level: 0

restapi:
        port: 8282

tribe:
        enable: false

Not sure what is different between our setups. I am working off of commit 170c8d3.

[mbbroberg]

Thanks @IRCody. These issues roll up into me misconfiguring plugin_trust_level: 1 by having it outside of control. I can't reproduce this any further. Seems like a user error on my part. Thanks for helping!

Closing.

[lynxbat]

Could we reopen the issue to better capture the user error instead of silently accepting it?

Printing warning messages for config with bad keys is pretty easy.

[IRCody]

Going to go ahead and reopen the issue for that discussion.

My thoughts:

I'm not sure it's super easy to do that. The keys in the above example aren't really bad (as in they have incorrect values or somehow error on unmarshal), they are extra. Extra keys are ignored when unmarshaling by json.Decoder. This issue is relevant. I don't believe there is a way to treat unknown fields as an error inside json.Unmarshal (and even our yaml unmarshal goes from yaml->json->struct).

We could unmarshal into a map[string]interface{} and walk through it to verify there are no keys we didn't expect in places we didn't expect. This is tedious but would work. It would give us very specific detail on where the error is.

We could also write a schema, something like this and use something like this jsonschema validator to validate a schema. I'm not sure it would pinpoint the error but you would at least see that the schema was invalid and could error on that.

[lynxbat]

Wouldn't a schema validator catch why? Seems like the cleanest path.

[IRCody]

I just didn't look to closely at the errors it would give you, I just figured it had to at least give valid/invalid.

Looking more closely at the errors that can be returned fro the one I linked above I think it would give us plenty of context to give good errors to the user. I agree schema is the cleanest way.

[lynxbat]

[IRCody]

Closing this in favor of #898.