dconf Settings: defaults and locks

Last year I worked on a project where I was playing around with system-wide default settings and locks and I thought I’d share a post based on some of my notes. Most all of what I will mention here is covered in depth by the dconf SysAdmin guide, so if you plan on using this, please read that guide as well. UPDATE: Gnome has moved all the dconf stuff into the Gnome SysAdmin guide, it’s a bit more scattered now, but there.

For most everyone, you have just one dconf database per user. It is a binary blob and it’s stored in ~/.config/dconf/user. Anytime you change a setting, this file gets updated. For system administrators who may want to set a company-wide default value, a new dconf database must be created.

Create a Profile

The first step in setting up other databases is to create a dconf profile file. By default you don’t need one since the system uses the default database, user.db, but to setup other databases you will. So create a file called /etc/dconf/profile/user and add the list of databases that you want. Note that this list is a hierarchy and that the user database should always be on top.

For this example, I will create a company database and a division database. The hierarchy implies that we will have company-wide settings, perhaps a wallpaper, settings on top that are specific to the division, perhaps the IP of a proxy server that’s geographically specific, and each user will have customized settings on top of that.

To create a profile, we’ll do the following:

mkdir -p /etc/dconf/profile

and edit /etc/dconf/profile/user, then add:

user-db:user
system-db:division
system-db:company

Keyfiles

(Note: I am doing this on a relatively clean precise install using a user that has not changed their wallpaper setting, that is important later)

Once you have created the profile hierarchy, you need to create keyfiles that set the values for each database. For this example, we will just set specific wallpaper files for each hierarchy. This is done with key files:

mkdir -p /etc/dconf/db/division.d/

and edit /etc/dconf/db/division.d/division.key, add the following:

[org/gnome/desktop/background]
picture-uri='file:///usr/share/backgrounds/Flocking_by_noombox.jpg'

Next we’ll create the company key file:

sudo mkdir -p /etc/dconf/db/company.d/

and edit /etc/dconf/db/company.d/company.key, add the following:

[org/gnome/desktop/background]
picture-uri='file:///usr/share/backgrounds/Murales_by_Jan_Bencini.jpg'

Finally, you need to run sudo dconf update so that dconf sees these changes.

After running dconf update, you will see two changes. The first and most obvious change is that the background is now a bunch of Flocking birds, not the Precise default. The second change is that you will see two new binary dconf database files in /etc/dconf/db, one called company and one called division. If you don’t see these changes then you did something wrong, go back and check the steps.

flocking

Since I have no default set the division’s default takes precedence

The current user and any new users will inherit the Division default wallpaper, Flocking. However, the user still may change the wallpaper to anything they want, and if they change it, that change will be set in the user database, which takes precedence. So this method gives us a soft-default, a default until otherwise modified. If you are trying this test on a user who has already modified the wallpaper, you will notice that it didn’t change due to this precedence.

If we want to force all users, new and existing, to get a specific wallpaper, we need to use a lock.

Locks

For this example, let’s assume that the IS department for our division really really likes the Flocking picture and doesn’t want anyone to change it. In order to force this, we need to set a lock. A lock is simple to make, it just specifies the name of the key that is locked. A locked key takes precedence over all other set keys.

Before doing this, I will use the wallpaper picker and select a new wallpaper, this will take precedence, until the lock is created. I picked Bloom for my test.

I like flowers more than birds.

I like flowers more than birds.

Now it’s time to make the lock, because the IS department really doesn’t like flowers, so we create the lock as follows.

sudo mkdir -p /etc/dconf/db/division.d/locks/

and then edit /etc/dconf/db/division.d/locks/division.lock (note file name doesn’t really matter) and add the following line:

/org/gnome/desktop/background/picture-uri

After saving the file, run sudo dconf update. Once doing so, I’m again looking at birds, even though I modified it in my user database to point to Bloom.

Lock file forces me to use the Division settings

Lock file forces me to use the Division settings

One interesting thing to note, any changes the user is making are still being set in their dconf user db, but the lock is overriding what is being seen from outside dconf. So if I change the wallpaper to London Eye in the wallpaper picker and then remove the lock by simply doing sudo rm division.lock && sudo dconf update, I immediately get the London Eye. So it’s important to keep this in mind, the user db is being written into, but the lock is in effect masking the user db value when the setting is read back.

London Eye wallpaper is shown after I remove the lock

London Eye wallpaper is shown after I remove the lock

Lock Hierarchy

Lock hierarchy is interesting, in that the lowermost lock takes precedence. What this means is that if we lock both the company and division wallpapers, we will see the company one. In the example below I set locks on the wallpaper key for both databases, and I end up seeing Murales, the company default.

Company setting takes precedence

Company setting takes precedence with both locked

 

Locks Without Keys

It is also possible to set a lock on a hierarchy without a corresponding default key. In this instance the system default is used and the user is unable to change the setting. For this example, I set a company lock but removed the company key. The resulting wallpaper is the system default.

System default wallpaper for Precise is seen

System default wallpaper for Precise is seen

What Value is Seen – A Quiz

If you’d like to test your knowledge of what key will take precedence when read from dconf, follow the quiz below, answers are at the bottom. For each scenario, see if you can figure out what wallpaper the user will see, assume the same database hierarchy as used in the example.

  1. User Wallpaper: unset, Division Wallpaper: Flock, Company Wallpaper: Murales
  2. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales
  3. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Company Wallpaper setting
  4. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Division and Company Wallpaper setting
  5. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: unset, Lock file for Division and Company Wallpaper setting

Answers: Flock, London Eye, Murales, Murales, Default for Precise

Testing

Some notes about testing this if you are trying it:

    • Creating new users and logging in as them is a good way to see what settings are shown, the wallpaper is a great visual test as it’s easy to verify.
    • Do not do this on your development box. I screwed up my settings right before I was going to give a demo. I’d recommend a VM. If you do screw something up, check .xsession-errors, that’s where my problem was apparent.

Summary

If you’re a system administrator or you really like pictures of birds, dconf keyfiles and locks are the correct mechanism to make settings that are defaults, soft or hard. Hopefully this has been illustrative on how they work. I’d recommend playing with them in a VM and once you understand the hierarchies and locking, they should be pretty easy to use.

Tagged , ,

5 thoughts on “dconf Settings: defaults and locks

  1. Alexandre P. says:

    This is an interesting post. Thanks!

    I have been able to figure out pretty much all of this, but there is one thing I have not been able to accomplish: create multiple profiles and apply a profile to select users.

    For example, let’s say for our company:
    - the Division should have the Flock wallpaper (locked);
    - the Big Boss should have the wallpaper key unlocked, so he could select its favorite one;
    - all other employees should have Murales (locked).

    I guess this can be achieved by creating multiple Dconf profiles. For example, I would create a /etc/dconf/profiles/division profile, a /etc/dconf/profiles/boss profile and a /etc/dconf/profiles/employees profile. This way, for each profile, I could re-order which database has priority over the others and configure locks per profile.

    But what I don’t know is how I can set a user “alice” to have a Division profile, a user “bob” a Boss profile and a user “carl” an Employee profile.

    Do you have any clues on how this can be done?

    • Matt Fischer says:

      I’ve not tried this before, but your idea sounds valid. You could even have profiles without certain databases, such as what if you did this:

      user-db
      division
      division-locks
      company
      company-locks

      Alice’s profile would be: user-db, division, division-locks, company
      Bob’s would be: user-db, company (he gets defaults without locks)
      Carl would be: everything

      Of course this is not what you were asking, I think the solution is that Alice, Bob, and Carl each have a different value set for DCONF_PROFILE in their bashrc or bash_aliases file:

      export DCONF_PROFILE=/etc/dconf/profiles/boss

      I’ve not tried that before, but I think it will work, can you let me know if you try it?

  2. Gonzalo says:

    I am sorry, but isn´t there a simpler way to do this?

    KDE used to have a simple GUI (Kiosk) to create default settings and to lock down the desktop. You were then able to export those settings to other systems and this should be possible in a simpler and faster manner.

    I have been a linux user since 1998, but I still find it somewhat odd that we do not realize how important tools such as these are in large organizations.

  3. bob says:

    Very useful, thanks.

    Small niggle – at one point you advise to run ‘dconf-update’ rather than ‘dconf update’.

    Also the link to the dconf SysAdmin guide goes to a page which says “This page does not exist yet. You can create a new empty page, or use one of the page templates.” . Seems to be a problem on GNOME end though as the page is the first Google hit for ‘dconf SysAdmin guide’

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>