2

I am behind a corporate fire wall and have been trying to set up my proxy settings by using export in a shell script located in /etc/profile.d/proxy.sh (see, e.g., How to set system-wide proxy address using shell script?).

While troubleshooting the settings, I also made changes in the "Network" GUI. I could not connect due to an error I introduced in the "Network" GUI, which I believe may have overridden the correct setting in the proxy.sh script file.

How does gsettings interact and/or conflict with environment variables set by scripts located in /etc/profile.d/ or /etc/environment? Which settings take precedence if there is a conflict? If I am using Ubuntu Desktop (i.e., a GUI environment) is it preferably to edit environment variables using gsettings (either from the GUI or a script that sets gsettings) so that they are accessible in the GUI (i.e., I disabled the proxy settings in the GUI because they conflicted with my script, but now I cannot see the settings set by the script in the GUI)? Any thoughts on best practice would be most appreciated.

user2514157
  • 783
  • 8
  • 19
  • Do not think the answer in the attached link will work. To expand a variable in a string, you must switch to double-quotes. You can use single-quotes inside a string like this: export http_proxy="http://$1/"; gsettings set org.gnome.system.proxy.http host "'$http_proxy'" –  Oct 15 '20 at 05:10
  • The primary thrust of my question is how "gsettings interact and/or conflict with environment variables set by scripts". I.e., if they conflict, who wins and why? – user2514157 Oct 15 '20 at 13:11

1 Answers1

1

As I couldn't find creditable sources, I would say: "AFAIK, there is no global setting for PROXY in the current distributions of GNU/Linux & BSD. It is all up to the end user application to use or ignore proxy setting at any level: environment vars, desktop environment, config ... Similar case to DNS"

So, for many net tools (like: apt, firefox, wget, ...) they have their own proxy settings and priority list.

If you are looking for tool from Gnome Desktop Environment. Then probably, this is the interesting part:

gnome-core → glib-networking → libproxy1v5

Config Modules

Config modules read proxy configuration from a source. Every config module has a type. There are three confnig types: SYSTEM Defines configuration on a system-wide basis USER Defines configuration on a user-wide basis

SESSION Defines configuration for this current login session only A module can also choose to have no config type.

The config module sources (as of 0.4.15) are: direct always return direct://, this is the global fallback

envvar reads http_proxy, https_proxy, ftp_proxy and no_proxy environment variables gnome reads gconf (SESSION) gnome3 reads gsettings (SESSION) kde reads kconfig (SESSION) wpad always returns wpad://, this is used to fall back on autodetect if desired

By default, modules are called in the following order:

  1. USER
  2. SESSION
  3. SYSTEM
  4. envvar
  5. wpad
  6. direct

The order within the categories is undefined and could be random. If a module says it can't find the configuration, the next module is tried.

The module order can be manually specified through an environmental variable (PX_CONFIG_ORDER). The order indicated in this variable does not replace the internal order, but prepends to it. Thus, if you wanted to prefer (for forcing a module, see whitelist/blacklist above) the usage of envvar, you would specify the following which would put envvar first in the list: export PX_CONFIG_ORDER=config_envvar

You can also lock-down the module order for all users on a system using /etc/proxy.conf. This feature is not yet documented (any volunteers!?).

Source: https://github.com/libproxy/libproxy/wiki/HowTo#config-modules

user.dz
  • 48,105