Sorry for the spam, I've got another question: I get the impression that the any config of any file that is passed using

fleet server --config my_config.yml

is ignored. I've been trying to set some initial values during installation (

org_info

and

org_logo

for my tests, but others as well, specifically

yara

). After noticing that these values don't seem to affect FleetDMs behaviour, I tried manipulating single values and then using

fleetctl get config --include-server-config

to confirm that the changes have indeed manifested in FleetDM's config, but the changes never appear, even though I did reload the binary (OK, yeah, I restarted the Docker container). So I was wondering: what's up with that? 🙂 Ideally, I would later use the

--config

flag to call FleetDM with two config files, one containing CLI flags and one containing YAML formatted config items, because it seems like not all options can be set using a YAML config file. However, I'm not sure if

--config

can even be used multiple times, and even if I only use to for one file, it seems to be ignored. Also, I haven't found any additional documentation on the

--config

flag apart from what

fleet --help

says: "_-c, --config string Path to a configuration file_".

No spam here :) Can you share the file you're passing to Fleet on startup? The most likely culprit for values not applying would be that a key is misplaced. You can redact any sensitive information or send it to me as a DM. If you do the latter, I may copy/paste here if I see an issue, but will make sure I'm not including anything potentially sensitive. You should definitely be able to convert all startup flags to YAML so that you can pass a single file. Which flags were you having trouble with there?

Hey @Jörg Sachse its important to remember there are ways to configure the fleet binary (things like how fleet should connect to mysql, redis, etc.) and then there is the runtime configuration (queries, teams, organizational settings, etc.) the

fleet

binary doesn't have a

server

command, that might have been a typo, but it does have a

serve

command. You can configure the fleet binary via yaml if that is your desire, and you have the config flag correct,

--config path/to/config.yml

. Once the fleet server starts and you have gone through setup, you can then use

fleetctl

to apply the runtime configuration https://fleetdm.com/docs/using-fleet/configuration-files#organization-settings

Hi @Kathy Satterlee & @Benjamin Edwards, Yes, there was indeed a typo in the question. The actual command that is used (copy & paste) is:

/usr/bin/fleet serve --config /opt/fleet/config/config.yml

. The content of the

config.yml

file is:

---
apiVersion: v1
kind: config
spec:
  agent_options:
    command_line_flags:
      enable_file_events: true
      disable_events: false
      schedule_splay_percent: 10
      schedule_max_drift: 60
      pack_refresh_interval: 3600
      schedule_default_interval: 3600
      hardware_disabled_types: partition,disk
      disable_logging: false
      logger_rotate: true
    config:
      decorators:
        load:
        - SELECT uuid AS host_uuid FROM system_info;
        - SELECT hostname AS hostname FROM system_info;
      options:
        disable_distributed: false
        distributed_interval: 10
        distributed_plugin: tls
        distributed_tls_max_attempts: 3
        # logger_plugin: tls
        logger_tls_endpoint: /api/osquery/log
        logger_tls_period: 10
        pack_delimiter: /
      yara:
        file_paths:
          system_binaries:
          - "/bin/%%"
          - "/usr/bin/%%"
          - "/usr/sbin/%%"
          - "/usr/local/bin/%%"
          tmp:
          - "/Users/%/tmp/%%"
          - "/tmp/%%"
        file_paths:
          system_binaries:
          - signature_group_1
          tmp:
          - signature_group_1
#        signature_urls:
        signatures:
          signature_group_1:
          - "<https://raw.githubusercontent.com/Yara-Rules/rules/master/cve_rules/CVE-2010-0805.yar>"
          - "/etc/osquery/testsig.yara"
    overrides: {}
  features:
    enable_host_users: true
    enable_software_inventory: true
  fleet_desktop:
    transparency_url: <https://fleetdm.com/transparency>
  host_expiry_settings:
    host_expiry_enabled: false
    host_expiry_window: 0
  integrations:
    jira: null
    zendesk: null
  mdm:
    apple_bm_default_team: ""
    apple_bm_enabled_and_configured: false
    apple_bm_terms_expired: false
    enabled_and_configured: false
    end_user_authentication:
      entity_id: ""
      idp_name: ""
      issuer_uri: ""
      metadata: ""
      metadata_url: ""
    macos_settings:
      custom_settings: null
      enable_disk_encryption: false
    macos_setup:
      bootstrap_package: ""
#      enable_end_user_authentication: false
      macos_setup_assistant: null
    macos_updates:
      deadline: ""
      minimum_version: ""
  org_info:
#    contact_url: ""
    org_logo_url: '<https://URL/to/logo.png>'
    org_name: SLUB Dresden
  server_settings:
    deferred_save_host: false
    enable_analytics: false
    live_query_disabled: false
    server_url: <https://myfleetserver.example.com>
  smtp_settings:
    authentication_method: "0"
    authentication_type: authtype_none
    configured: true
    domain: ""
    enable_smtp: true
    enable_ssl_tls: true
    enable_start_tls: true
    password: ""
    port: 25
    sender_address: <mailto:fleetdm-admin@example.com|fleetdm-admin@example.com>
    server: <http://mail.example.com|mail.example.com>
    user_name: ""
    verify_ssl_certs: true
  sso_settings:
    enable_jit_provisioning: false
    enable_jit_role_sync: false
    enable_sso: false
    enable_sso_idp_login: false
    entity_id: ""
    idp_image_url: ""
    idp_name: ""
    issuer_uri: ""
    metadata: ""
    metadata_url: ""
  vulnerability_settings:
    databases_path: "/tmp/vulndbs"
    recent_vulnerability_max_age: 48h
#    periodicity: 1h
  webhook_settings:
    failing_policies_webhook:
      destination_url: ""
      enable_failing_policies_webhook: false
      host_batch_size: 0
      policy_ids: null
    host_status_webhook:
      days_count: 0
      destination_url: ""
      enable_host_status_webhook: false
      host_percentage: 0
    interval: 0s
    vulnerabilities_webhook:
      destination_url: ""
      enable_vulnerabilities_webhook: false
      host_batch_size: 0

I also have a

cli.yml

that looks like this:

mysql:
  address: "fleet_mysql:3306"
  database: "fleetdb"
  username: "fleetdb"
  password: "fleetdb"
  max_open_conns: 100
redis:
  address: fleet_redis:6379
server:
  address: 0.0.0.0:8080
  cert: "/opt/fleet/ssl/server.cert"
  key: "/opt/fleet/ssl/server.key"
  tls: true
  tls_compatibility: "modern"
osquery:
  status_log_plugin: filesystem
  result_log_plugin: filesystem
logging:
  debug: false
  json: true
  disable_banner: true
filesystem:
  status_log_file: /opt/fleet/log/osquery_status.log
  result_log_file: /opt/fleet/log/osquery_result.log
  enable_log_rotation: true
  enable_log_compression: true
  max_age: 28
  max_backups: 3
upgrades:
  allow_missing_migrations: false

From what I gather, the

cli.yml

would be the file that I use for configuring the fleet binary on startup (e.g. instead of using env variables) and the

config.yml

would only contain runtime settings that need to be applied using

fleetctl

or direct REST API calls and cannot be applied using the

--config

flag, is that correct? EDIT: Forgot to say, I really appreciate your help. Thank you so very much for supporting the community (and myself for that matter).

Yes you are correct! Let us know how that goes.

I'm still testing, but it lokks yery good.

Sorry about that! I'll get the example updated to not include the

vulnerabilities

settings, which are handled in the server configuration.