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.
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.
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.
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
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
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 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
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.
- User Wallpaper: unset, Division Wallpaper: Flock, Company Wallpaper: Murales
- User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales
- User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Company Wallpaper setting
- User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Division and Company Wallpaper setting
- 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.
Read more
Latest Official Posts
