Configuring MATE Defaults

Amazon Linux WorkSpaces uses the MATE Desktop Environment by default. If you're creating a custom bundle for your organization, you may want to change some settings and have those settings apply by default to any workspaces created from that bundle. On Windows the user profile is copied to the default profile when you create an image, but on Linux only the root volume becomes part of the new image, so you'll need to know how to set those defaults on the system.

GSettings / dconf

Most of the settings in MATE (and in GNOME) are stored using GSettings. dconf is the database backend behind GSettings. You can think of it as something roughly equivalent to the Windows Registry. There are two ways of configuring system defaults, one for privileged users and systems administrators and one for vendors, distributors, and packagers.

The dconf System Administrator Guide describes a bit about how to use dconf to set local defaults and mandatory settings if you're a systems administrator. This is the process you'd follow if you use a configuration management system like Ansible. Note that dconf itself doesn't process any schema, so it's easy to make mistakes that could cause software to misbehave. The GNOME documentation recommends using dconf over GSettings overrides because /usr may be read-only on some systems. dconf can also allow you to lock specific settings.

For vendors and distributors the GIO Reference Manual recommends using vendor override files to effectively patch existing schema.

Inspecting Local Changes

Before making any changes to your desktop, capture a dump of all settings as they are by default already.

gsettings list-recursively | sort > gsettings.before

After making your changes, for example changing the wallpaper, capture another dump of the settings and compare them.

gsettings list-recursively | sort > gsettings.after
diff -U0 gsettings.{before,after}
--- gsettings.before    2018-12-07 12:14:34.052711800 -0800
+++ gsettings.after     2018-12-07 12:16:27.017519406 -0800
@@ -1117 +1117 @@
-org.mate.background picture-filename '/usr/share/backgrounds/amazon/workspaces-wireframe.svg'
+org.mate.background picture-filename '/usr/share/backgrounds/amazon/Amazon-WorkSpaces-4.jpeg'

In this example there are no additional differences than the one I want, but there may be if you've been clicking around much. Or you might have several changes you want to use.

Adding dconf Overrides

If you are a user or an administrator, it's recommended that you use dconf overrides to configure your system defaults.

Local dconf overrides are stored under /etc/dconf/db/local.d/ in a format similar to (but not quite) .ini. Group names in the file refer to the schema path, not the schema id. You can get the schema path from the .gschema.xml file.

grep -F path= /usr/share/glib-2.0/schemas/org.mate.background.gschema.xml
<schema id="org.mate.background" path="/org/mate/desktop/background/">

In the above example org.mate.background has a schema path of /org/mate/desktop/background/ so you'd use org/mate/desktop/background as the group name.


After you've placed a file like the above under /etc/dconf/db/local.d/ you need to also update the dconf database. This will cause it to process any overrides and save them into the binary database format it uses.

dconf update

Adding Schema Overrides

If you are a vendor or distributor, or if you are putting the override in an installable package, it's recommended that you use GSettings schema overrides.

GSettings schema and overrides are stored under /usr/share/glib-2.0/schemas/ in effectively the same format as dconf overrides, but using the dotted schema id as the group name instead of the schema path as in a dconf override. Schema override files end in .gschema.override


Schema overrides are processed in sort order, so it's common to use a two digit number to set the priority of your override compared to others. For example you might create an override file called 50_desktop-background.gschema.override. For the override to take effect you must compile them with glib-compile-schemas /usr/share/glib-2.0/schemas.

In RPM packages schema are compiled in %posttrans and %postun scriptlets. This is not needed on recent Fedora systems because file triggers take care of it, but it is still needed on RHEL 7, CentOS 7, and Amazon Linux 2. The %postun scriptlet is needed because %posttrans is not run for packages that have been uninstalled.

if [[ "$1" -eq 0 ]]; then
  /usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas &> /dev/null ||:

/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas &> /dev/null ||:

Resetting to Defaults

You'll want to see what everything looks like once you're done, to make sure it worked, so it's useful to reset all your local settings back to the newly configured system defaults in your own session. Most software will reconfigure immediately, but some could require you to logout first.

dconf reset -f /

Comments !