Как я могу сделать поддельную «активную сессию» для gconf?

Question

Я автоматизировал установку Ubuntu - у меня есть код Python, который запускается автоматически (после чистой установки, но до первого входа пользователя - он находится во временном скрипте /etc/init.d/), который устанавливает все, начиная от Apache & его конфигурации для моих личных предпочтений Gnome. Это последнее вызывает у меня проблемы.

Это работало хорошо в Ubuntu 8.04 (Hardy), но когда я использую это с 8.10 (Intrepid), в первый раз я пытаюсь получить доступ к GConf, я получаю это исключение:

Не удалось связаться с сервером конфигурации; некоторые возможные причины: вам нужно включить TCP/IP-сеть для ORBit, или у вас есть устаревшие блокировки NFS из-за сбоя системы. См. http://www.gnome.org/projects/gconf/. (Подробности - 1: Не работает в течение активной сессии)

Да, правильно, нет сеанса Gnome, когда он запущен, поскольку пользователь еще не вошел в систему - однако это сработало раньше; это кажется новым с Гноме Intrepid (2.24?).

Невозможно изменить XML-файлы gconf напрямую, есть ли способ сделать какую-то сессию прокси-сервера Gnome? Или любые другие предложения?

(Подробнее: это питон код, который работает как корень, но Setuid в & setgid, чтобы быть мне перед установкой моих предпочтений с помощью модуля «Gconf» из пакета питона-Gconf.)

Answer 1

Ну, я думаю, Я понимаю вопрос. Похоже, ваш скрипт просто должен запустить дБ дБ, или убедиться, что он запущен. Я считаю, что «сеанс» здесь относится к сеансу dbus. (here is some evidence), а не сеанс Gnome. Dbus и gconf работают нормально без Gnome.

В любом случае, подделка «активной сессии» звучит как довольно плохая идея. Он будет искать его только в случае необходимости.

Возможно, мы могли видеть скрипт в пастебине? Я должен был действительно увидеть это, прежде чем делать какие-либо комментарии.

Answer 2

Я могу воспроизвести это, установив GConf 2.24 на свою машину. GConf 2.22 отлично работает, но 2.24 ломает его.

GConf не запускается, поскольку D-Bus не работает. Ручное создание D-Bus и демона GConf делает эту работу еще раз.

Я попытался нерест сеанса шины D-Bus, выполнив следующие действия:

import dbus 
dummy_bus = dbus.SessionBus() 

... но получилось так:

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. 

Weird. Похоже, что это не нравится, если X не работает. Чтобы обойти это, начать Dbus-запуск вручную (IIRC использовать os.system() вызов):

$ dbus-launch 
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-eAmT3q94u0,guid=c250f62d3c4739dcc9a12d48490fc268 
DBUS_SESSION_BUS_PID=15836 

Вам нужно разобрать выход как-то и ввести их в переменные окружения (вы, вероятно, хотите использовать os.putenv) , Для тестирования я просто использовал оболочку, и установить окружение вары вручную с export DBUS_SESSION_BUS_ADDRESS=blahblah... и т.д.

Далее, вам нужно запустить gconftool-2 --spawn с теми переменными окружения, которые вы получили от dbus-launch. Это запустит демон GConf.Если настройки окружения D-Bus не установлены, демон не запускается.

Затем запустите свой код GConf. Если вы установите переменные среды сеансовой шины D-Bus для своего собственного скрипта, теперь вы сможете общаться с демоном GConf.

Я знаю, что это сложно.

gconftool-2 обеспечивает --direct вариант, который позволяет вам установить GConf переменных без необходимости связываться с сервером, но я не смог найти эквивалентный вариант для привязки Python (короткий выводить XML вручную).

Edit: На будущее, если кто-то хочет работать dbus-launch внутри нормального bash сценария (в отличие от скрипта Python, так как эта нить обсуждения), это довольно легко получить адрес сеанса шины для использовать в скрипте:

#!/bin/bash 

eval `dbus-launch --sh-syntax` 

export DBUS_SESSION_BUS_ADDRESS 
export DBUS_SESSION_BUS_PID 

do_other_stuff_here 

Answer 3

Спасибо, Али & Джереми - оба ваши ответы были большая помощь. Я все еще работаю над этим (хотя я остановился на вечер).

Во-первых, я взял намек Али и пытался попробовать предложение Джереми: я использовал dbus-запуск для запуска «gconftool-2 --spawn». Это не сработало для меня; Теперь я понимаю, почему (thx, Jeremy) - я пытался использовать gconf из той же самой программы python, которая запускала dbus gconftool, но в ее окружении не было переменных среды - duh.

Я отложил эту стратегию в сторону, когда заметил параметр --direct gconftool-2; внутренне gconftool-2 использует API, который не отображается привязками python gconf. Таким образом, я модифицировал python-gconf, чтобы разоблачить дополнительный метод, и как только он будет создан (у меня возникли некоторые проблемы, связанные с работой), мы увидим, исправляет ли это что-то, если это не так (и, возможно, потому что построение этих привязок, похоже, создает все гномы!), я найду лучший способ управлять переменными окружения в этой первой стратегии.

(я добавлю еще один ответ завтра либо путь)

И это на следующий день: я столкнулся с небольшой неприятностью с моим модифицированным питоном-GConf, который вдохновил меня попробовать простую идею Джереми, который работал fine - перед выполнением первой операции gconf я просто запускал «dbus-launch», разбирал результирующие пары имя-значение и добавлял их непосредственно в среду python. Сделав это, я запустил «gconftool-2 -spawn». Задача решена.