Setting dconf values as admin

[Josef Wolf]

On Wed, Oct 25, 2017 at 10:54:55PM +0200, Ralf Mardorf wrote:
> On Wed, 25 Oct 2017 22:28:09 +0200, Josef Wolf wrote:
> >If the user already has a dbus session runnning, a new dbus connection
> >will be started. Write operations on this new dbus session will go
> >to /dev/null.
> 
> It worked for me at least for other dconf settings when running a Tails
> 3.1 live DVD. I experienced another issue that is related to
> gnome-terminal profiles, off-topic here, since it's not related to a
> dbus issue. OTOH running a user 1000 session I opened a terminal, run a
> script under root privileges, that runs
> 
> sudo -u user_1000 dbus-launch dconf load /org/foo/ < bar

This sudo session was running as a child of the desktop session and therefore
inherited the dbus session from the desktop.

My use case is different: I have a configuration tool which is (periodically)
started from cron. Therefore, there's no dbus session to inherit. And there's
no way to know in advance whether the user will be logged in at the time the
script is executed.

> Perhaps dbus-launch does the trick, if a script runs in a user's session
> under root privileges and the script does change dconf for this user
> session and maybe it doesn't work to change settings for another user
> running a session.

dbus-launch solves only half of the problem: it will create a session. This
works if the user is not logged in. But if the user is logged in, it will
create a second session, and all write operations will go into /dev/null.

> IMO dconf is annoying crap, it gains absolutely nothing, but makes
> configuring a PITA.

Yeah. dconf might be a good solution for interactive configurations on the
desktop. But configuring automatically via scripts was much easier with plain
old style config files.

What's more: with every release, the config methodology and the names of the
keys and values get new arbitrary names. This is really annoying for automatic
configuration :-(((

-- 
Josef Wolf
jw at raven.inka.de