Allow multiple uses of dconf::db for the same database

[iainhallam]

At present, we create DConf settings manually in several Puppet profiles, mostly in the local database, but using different file names for different groups of settings. We'd prefer to use a module for this, and your DConf module looks great, but at present it can only be used once for each database.

Can there be a parameter to the dconf::db type so that the name of the resource can be different from the database?

# manifests/db.pp
define dconf::db (
  String $db = $name,
  # ...
  Stdlib::Absolutepath $db_dir = "${base_dir}/${db}.d",
  # etc.
) {
  # ...
      concat { "db_${db}_locks":
  # etc.
}

This way I could have two files for settings in different profiles:

# site/profiles/manifests/gnome/background.pp
dconf::db { 'local-background':
  db_file => '/etc/dconf/db/local.d/00-background',
  # ...
}

# site/profiles/manifests/gnome/login.pp
dconf::db { 'local-login':
  db_file => '/etc/dconf/db/local.d/00-login',
  # ...
}

[jps-help]

This should be possible with a little bit of work. Currently defining two separate files for the same DB results in a duplicate resource declaration.

  dconf::db{'system_proxy':
    db_dir => '/etc/dconf/db/local.d',
    db_file => "${db_dir}/${name}",
    settings => {
      'system/proxy/http' => {
        'host' => '172.16.0.1',
        'enabled' => 'true',
      },
    },
  }
  dconf::db{'disable_microphone':
    db_dir => '/etc/dconf/db/local.d',
    db_file => "${db_dir}/${name}",
    settings => {
      'org/gnome/desktop/privacy' => {
        'disable-microphone' => 'true',
      },
    },
  }

This is because the dconf::db defined-type uses a standard 'file' resource to create the db_dir. But we could switch to a stdlib ensure-resource declaration instead.

I'll look into this and see what else might need changing as well.

[jps-help]

I've pushed some draft changes to a dev branch (commit-id 5fd52fa)
Also tagged multi_db

Feel free to test and give feedback.

I still need to add documentation for it. But you can test using some code like the following:

include dconf

dconf::profile { 'local':
  entries => {
    'user'  => {
      'type'  => 'user',
      'order' => 10,
    },
    'local' => {
      'type'  => 'system',
      'order' => 21,
    },
    'site'  => {
      'type'  => 'system',
      'order' => 21,
    },
  },
}
dconf::db { 'system-proxy':
  db_dir      => '/etc/dconf/db/local',
  db_filename => 'system-proxy',
  settings    => {
    'system/proxy/http' => {
      'host'    => "'172.16.0.1'",
      'enabled' => 'true',
    },
  },
}
dconf::db { 'disable-microphone':
  db_dir      => '/etc/dconf/db/local',
  db_filename => 'disable-micrphone',
  settings    => {
    'org/gnome/desktop/privacy' => {
      'disable-microphone' => 'true',
    },
  },
}

The key difference here is specifying the db_dir and db_filename parameters for each resource. This way you can have multiple db config files under the same db_dir

[iainhallam]

That looks useful - does the same need to happen for the lock files so that they can be named for their contents as well, rather than having all locks in one file?

[jps-help]

That could be a bit more difficult since the locks file is also tied to the dconf::db resource. I think further changes would be needed for that.

[jps-help]

I have pushed another update to dev branch (commit-id: 3cd176600bacb652578dc758263d278d0d4d2113). This should allow multiple locks files as well.

The following is a working example

dconf::db { 'system-proxy':
  db_dir      => '/etc/dconf/db/local.d',
  db_filename => 'system-proxy',
  locks_filename => 'system-proxy',
  settings    => {
    'system/proxy/http' => {
      'host'    => "'172.16.0.1'",
      'enabled' => 'true',
    },
  },
  locks => [
    '/system/proxy/http/host',
    '/system/proxy/http/enabled',
  ],
}
dconf::db { 'disable-microphone':
  db_dir      => '/etc/dconf/db/local.d',
  db_filename => 'disable-micrphone',
  locks_filename => 'disable-microphone',
  settings    => {
    'org/gnome/desktop/privacy' => {
      'disable-microphone' => 'true',
    },
  },
  locks => [
    '/org/gnome/desktop/privacy/disable-microphone',
  ],
}

Although possible, I do think this approach is a bit of a hack. Managing everything in a single db file and locks file is the intended use-case of the module.

But I'll see about merging these changes at some point