Comment faire une fausse "session active" pour gconf?

Question

J'ai automatisé mon installation Ubuntu - J'ai du code Python qui s'exécute automatiquement (après une installation propre, mais avant la première connexion de l'utilisateur - c'est dans un script temporaire /etc/init.d/ qui configure tout depuis Apache & sa configuration à mes préférences personnelles Gnome. C'est ce dernier qui me pose des problèmes.

Cela a bien fonctionné dans Ubuntu 8.04 (Hardy), mais quand je l'utiliser avec 8.10 (Intrepid), la première fois que j'essaie d'accéder gconf, je reçois cette exception:

Impossible de contacter le serveur de configuration; Certaines causes possibles sont que vous devez activer la mise en réseau TCP/IP pour ORBit, ou que vous avez des verrous NFS obsolètes en raison d'un blocage du système. Voir http://www.gnome.org/projects/gconf/ pour information. (Détails - 1: Non en cours d'exécution au sein de la session active)

Oui, à droite, il n'y a pas de session de Gnome quand cela fonctionne, parce que l'utilisateur n'a pas encore connecté - cependant, cela a fonctionné avant; cela semble être nouveau avec Gnome d'Intrepid (2.24?).

À moins de modifier directement les fichiers XML de gconf, existe-t-il un moyen de créer une sorte de session Gnome proxy? Ou, d'autres suggestions?

(Plus de détails: ce code est en python qui fonctionne en tant que root, mais ce de setuid & setgid être moi avant de mes préférences en utilisant le module « gconf » du paquet python-gconf.)

Answer 1

Eh bien, je pense Je comprends la question. On dirait que votre script a juste besoin de démarrer le démon dbus, ou assurez-vous qu'il a démarré. Je crois que "session" se réfère ici à une session dbus. (here is some evidence), pas une session Gnome. Dbus et gconf fonctionnent tous deux correctement sans Gnome.

De toute façon, truquer une "session active" semble être une très mauvaise idée. Il ne le chercherait que s'il en avait besoin.

Peut-être que nous pourrions voir le script dans un pastebin? J'aurais dû le voir avant de faire un commentaire.

Answer 2

Je peux reproduire cela en installant GConf 2.24 sur ma machine. GConf 2.22 fonctionne bien, mais 2.24 le casse.

GConf ne démarre pas car D-Bus n'est pas en cours d'exécution. La génération manuelle de D-Bus et du démon GConf rend ce travail à nouveau.

J'ai essayé de reproduire le bus de la session D-Bus en procédant comme suit:

import dbus 
dummy_bus = dbus.SessionBus() 

... mais on m'a donné ceci:

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

Bizarre. On dirait qu'il n'aime pas venir si X ne fonctionne pas. Pour contourner cela, démarrez-dbus lancer manuellement (IIRC utiliser l'appel os.system()):

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

Vous devez analyser la sortie d'une certaine manière et de les injecter dans les variables d'environnement (vous voudrez probablement utiliser os.putenv) . Pour mes tests, je viens d'utiliser le shell, et définir l'environnement vars manuellement avec export DBUS_SESSION_BUS_ADDRESS=blahblah..., etc.

Ensuite, vous devez lancer gconftool-2 --spawn avec les variables d'environnement que vous avez reçues de dbus-launch. Cela lancera le démon GConf.Si les variables d'environnement D-Bus ne sont pas définies, le démon ne sera pas lancé.

Ensuite, exécutez votre code GConf. Si vous définissez les variables d'environnement du bus de session D-Bus pour votre propre script, vous pourrez désormais communiquer avec le démon GConf.

Je sais que c'est compliqué. --direct offre une option --direct qui vous permet de définir des variables GConf sans avoir besoin de communiquer avec le serveur, mais je n'ai pas trouvé d'option équivalente pour les liaisons Python (à moins de sortir manuellement XML).

Edit: Pour référence ultérieure, si quelqu'un veut courir dbus-launch à partir d'un script bash normal (par opposition à un script Python, comme ce fil discute), il est assez facile de récupérer l'adresse de bus de session pour utiliser dans le script:

#!/bin/bash 

eval `dbus-launch --sh-syntax` 

export DBUS_SESSION_BUS_ADDRESS 
export DBUS_SESSION_BUS_PID 

do_other_stuff_here 

Answer 3

Merci, Ali & Jeremy - vos deux réponses ont été d'une grande aide. Je travaille toujours dessus (même si je me suis arrêté pour la soirée). D'abord, j'ai pris l'indice d'Ali et essayais une partie de la suggestion de Jeremy: J'utilisais dbus-launch pour lancer "gconftool-2 --spawn". Cela n'a pas fonctionné pour moi. Je comprends maintenant pourquoi (thx, Jeremy) - J'essayais d'utiliser gconf depuis le même programme python qui lançait dbus & gconftool, mais son environnement n'avait pas les variables d'environnement - duh.

J'ai mis de côté cette stratégie lorsque j'ai remarqué l'option --direct de gconftool-2; En interne, gconftool-2 utilise une API qui n'est pas exposée par les liaisons gconf python. J'ai donc modifié python-gconf pour exposer la méthode supplémentaire, et une fois que cela sera construit (j'ai eu quelques problèmes sans rapport avec cela), nous verrons si cela corrige les choses - si ce n'est pas le cas (et peut-être parce que construire ces liens semble construire tout le gnome!), je trouverai un meilleur moyen de gérer les variables d'environnement dans cette première stratégie.

(je vais ajouter une autre réponse ici demain de toute façon)

Et c'est le jour suivant: je suis tombé un peu de mal avec mon python-gconf modifié, ce qui m'a inspiré d'essayer l'idée de Jeremy simple, qui a travaillé bien - avant de faire la première opération gconf, j'ai simplement lancé "dbus-launch", analysé les paires nom-valeur résultantes, et les ai ajoutées directement à l'environnement de python. Après avoir fait cela, j'ai couru "gconftool-2 --spawn". Problème résolu.