sudo gsettings peut modifier le proxy GNOME du mauvais utilisateur
Appliquez les paramètres de proxy GNOME dans la session de bureau de l'utilisateur visé au lieu de mettre à jour la base de paramètres de root.
Pour votre propre bureau GNOME, exécutez la modification du paramètre en tant qu'utilisateur depuis cette session de bureau :
gsettings get org.gnome.system.proxy mode
gsettings set org.gnome.system.proxy mode 'manual'Ceci illustre le contexte, pas une configuration complète du proxy ; les valeurs de point de terminaison et de contournement doivent aussi être correctes. Pour une route SOCKS manuelle définissez l'hôte et le port en plus du mode. Relisez la valeur dans la même session visée.
Exécuter la commande avec sudo ne sélectionne pas les paramètres de cet utilisateur. GSettings passe par un contexte backend. Avec dconf, la base de l'utilisateur et le bus de session comptent ; le manuel en ligne de commande exige une connexion au bus de session D-Bus pour écrire dans ce backend.
Pour une modification administrative, utilisez le mécanisme pris en charge de gestion du bureau ou de la session utilisateur. Changer d'UID dans un autre shell peut toujours manquer l'environnement de paramètres visé, et copier des variables depuis un processus correspondant arbitraire peut viser une autre connexion sur une machine multi-sessions.
Si la relecture est correcte mais que le routage ne change pas, identifiez l'interface de consommation de l'application. Un écouteur GSettings actif peut recevoir des notifications. Une application qui a copié http_proxy au démarrage ne reçoit pas de nouvel environnement quand dconf change, et sa politique de proxy privée peut choisir une autre route. Répéter l'écriture en root ne résout pas ce décalage du consommateur.