Как пользователь root, я могу использовать su для внесения изменений в dconf для другого пользователя. Как мне на самом деле заставить их применить?

Question 1

В приведенном ниже сценарии предполагается, что мы загрузили компьютер и вошли в систему как пользовательский борт в меню входа в систему. Это 14.04.2.

Если я открою терминал, как пользователь bort, я могу перечислить настройку dconf, например,

$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode
0

. Если бы я использовал dconf write, чтобы изменить значение на 1, в меню слева сторона экрана будет скрыта

$ dconf write /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode 1
$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode
1

Теперь меню скрыто. Теперь давайте предположим, что я использую dconf write, чтобы установить его обратно в 0. Меню появится снова.

Теперь, если я был в одном терминале как пользователь root и пытался использовать su bort -c, чтобы изменить значение для bort, я МОГУ изменить его. Я знаю это, потому что в другом терминале, где я являюсь пользователем bort, я могу использовать dconf read и увидеть, что значение изменилось на 1. Таким образом, значение было изменено, НО меню в левой части экрана все еще видно. Как я могу применить изменение на самом деле вместо того, чтобы просто обновляться в базе данных dconf? В конечном счете, я хочу знать это для использования с типом exec Puppet, но возможность сделать это как root от терминала будет полезна для достижения этой цели.

Как root в терминале:

# su bort -c "/bin/sh -c '/usr/bin/dconf write /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode 1'"

Как bort в терминале после выполнения предыдущей команды:

$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode
1

Тем не менее, меню все еще там. Я знаю, что на этот тип вопросов есть некоторые ответы на этом сайте, такие как использование dbus-launch, но это не сработало для меня. Может быть, это зависит от версии Ubuntu?

Question 2

Вам не установили переменную среды DBUS_SESSION_BUS_ADDRESS, таким образом, изменения не придерживаются. Как Ваш пользователь, запишите вывод

echo $DBUS_SESSION_BUS_ADDRESS

и затем в корневом использовании команды

export DBUS_SESSION_BUS_ADDRESS=xxxxx && dconf write ...

, который должен работать.

После борьбы с их хромой попыткой сокрытия их сокета некоторое время, одно рабочее решение автоматически получить адрес состоит в том, чтобы одолжить его через среду процесса:

# requires a GUI session program that will always run:
p=`pgrep -u \`whoami\` gnome-panel`

r=`grep -z DBUS_SESSION_BUS_ADDRESS /proc/$p/environ | sed 's/^[^=]*=//'`
export DBUS_SESSION_BUS_ADDRESS=$r

, Конечно, необходимо было бы выбрать что-то другое, чем панель гнома, если Вы не выполняете это.

Работы для SSH_AUTH_SOCK также. Просто оставив это здесь, таким образом, это может помочь людям, которые до сих пор погуглили неудачно (как я ;)).

Question 3

Question 4

В CentOS 8.3 для обновления настроек dconf работает следующее.

$user — это другой пользователь, как указано в заголовке вопроса выше.

dbus-run-session — это рекомендуемый способ запуска сеанса dbus в режиме командной строки. Нет необходимости экспортировать переменные DBUS_SESSION, такие как BUS_ADDRESS или PID.

# start a new dbus session and execute the dconf command in bash shell
sudo  -i -u ${user} bash <<-EOF
   exec dbus-run-session -- bash -c 'dconf write /org/gnome/software/download-updates false'
EOF

Чтобы узнать больше, прочтите man-страницу: man dbus-run-session и man dbus-launch

Полагаю, это должно работать на Ubuntu (не тестировалось)

Donjan Rodic · Answer 1 · 2 August 2015 в 00:22