Я автоматизировал свою установку 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's Gnome (2.24?).
За исключением прямого изменения XML-файлов gconf, есть ли способ создать какой-то сеанс прокси-сервера Gnome? Или любые другие предложения?
(Подробнее: это код Python, который запускается от имени пользователя root, но идентификаторы setuid и setgid должны быть мной, прежде чем устанавливать мои предпочтения с помощью модуля "gconf" из пакета python-gconf.)






Думаю, я понял вопрос. Похоже, вашему сценарию просто нужно запустить демон dbus или убедиться, что он запущен. Я считаю, что «сеанс» здесь относится к сеансу dbus. (вот некоторые доказательства), а не сеанс Gnome. Dbus и gconf нормально работают без Gnome.
В любом случае, имитировать «активную сессию» - плохая идея. Он будет искать его только в том случае, если он ему понадобится.
Возможно, мы могли бы увидеть сценарий в пастебине? Я действительно должен был это увидеть, прежде чем делать какие-либо комментарии.
Я могу воспроизвести это, установив 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.
Странный. Похоже, он не любит появляться, если X не работает. Чтобы обойти это, запустите dbus-launch вручную (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 вручную).
Редактировать: Для справки в будущем, если кто-то хочет запустить 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
Спасибо, Али и Джереми - оба ваших ответа очень помогли. Я все еще над этим работаю (правда, на вечер перестал).
Во-первых, я понял подсказку Али и попробовал часть предложения Джереми: я использовал dbus-launch для запуска «gconftool-2 --spawn». У меня это не сработало; Теперь я понимаю, почему (спасибо, Джереми) - я пытался использовать gconf из той же программы Python, которая запускала dbus и gconftool, но в его среде не было переменных среды - да.
Я отказался от этой стратегии, когда заметил параметр --direct в gconftool-2; внутри gconftool-2 использует API, который не предоставляется привязками gconf python. Итак, я модифицировал python-gconf, чтобы предоставить дополнительный метод, и как только он будет построен (у меня были некоторые несвязанные проблемы с его работой), мы посмотрим, исправит ли это что-то - если это не так (и, возможно, если это произойдет, поскольку создание этих привязок, похоже, строит весь gnome!), я найду лучший способ управления переменными среды в этой первой стратегии.
(В любом случае я добавлю сюда еще один ответ)
И это на следующий день: у меня возникла небольшая проблема с моим модифицированным python-gconf, который вдохновил меня попробовать более простую идею Джереми, которая сработала нормально - перед выполнением первой операции gconf я просто запустил "dbus-launch", проанализировал полученные пары имя-значение и добавили их непосредственно в среду Python. Сделав это, я запустил gconftool-2 --spawn. Проблема решена.
Если новый Python API полезен, убедитесь, что вы отправили изменения вверх по течению.
Получил ту же проблему, установка этих переменных DBUS снова запустила gconf. Спасибо! Для справки, проблемы начались, когда список задач эволюции не соответствовал.