A proxy setting was disabled yet HTTP_PROXY persists

I updated various server and hosts to use ipv6. This has had a crippling effect on the Squid Proxy (a separate issue). For now I have disabled the proxy setting for my account, and re-booted. (Booting wasn’t necessary but I did not know that at the time.)

The environment variable HTTP_PROXY persists with the proxy URL as its value.

$ echo $HTTP_PROXY
http://proxy1.sma.com:3128/

This is a problem for Chrome which heeds the HTTP_PROXY var.

How do I set HTTP_PROXY to an empty value for all of the host?

If this affects only one or two machines and looking for a temporary fix, then I might simply disable the “use proxy” setting in individual apps

Otherwise,
I’d expect that simply setting the variable’s value to null should be what you’re looking for.

Based on
https://askubuntu.com/questions/228530/updating-http-proxy-environment-variable
https://wiki.archlinux.org/index.php/Proxy_server

I’d expect that the following should work(That’s two single quotes, not a double quote)

export {HTTP,HTTPS,FTP}_PROXY=''

If you need to persist this setting across reboots, write the command into an /etc/profile.local and source if you want the command to take effect immediately without rebooting.

TSU

If this affects only one or two machines and looking for a temporary fix, then I might simply disable the “use proxy” setting in individual apps

That is part of the problem. Google Chrome in linux has no proxy settings; they refer the user to the system. Chrome uses the setting in HTTP_PROXY.

HTTP_PROXY is hardwired somewhere. I changed the proxy settings to use a different port (8118). HTTP_PROXY did not change; it pointed to the same place. I disabled the proxy settings; no change.

HTTP_PROXY is correct in /etc/sysconfig/proxy. It must be changed after it is set there.

Exporting HTTP_PROXY on a command line only effects that window; it is not a system-wide change.

You changed proxy settings where​?

In System settings. Yast :: Network Services :: Proxy.

The settings are currently proxy1.sma.com:8118, and disabled.

$ echo $HTTP_PROXY
http://proxy1.sma.com:3128/

Although I’m not testing,
I’d be surprised if exporting affects only the windowed console.
But… No matter. If you do what I describe by invoking the command in the /etc/profile.local file, that should apply the setting to the entire system.
If the system later picks up a new setting from elsewhere, I assume it will over-ride though.

IMO you should remove that configuration from your YaST Proxy setting, not just disable.

TSU

I created /etc/profile.local, added the export command, saved, closed. Opened a new window. No change.

$ cat /etc/profile.local
#
export HTTP_PROXY=
#

Is a reboot needed?

The profile set of files are activated on shell login. Those in /etc (like /etc/profile.local) work for all users that login. The ~/,profile (thus in a users’s home directory) work for that user on login. Has nothing to do with reboot (well, after a reboot all users have to login anew of course).

A variable that is exported to the process environment is only valid as such in that process and it’s child processes.
E.g. when I have in my .profile

export AAP=noot

and then start a program

someprogram

then inside the someprogram process the value of AAP can be used and will deliver noot (as long as the process someprogram does not change it).

Again: the environment of a process (with all those exported variables and other things) is promoted to a child process, but never to a parent process.

And re-read the above, all those profile files are only “sourced” on shell login. Everything that is not started from a login shell is not influenced by statements in profile files (except when those applications do that themselves).

The above, because I got the idea that some of these basic concepts are not part of your day to day Unix/Linux knowledge. If I am wrong I applogize (but maybe others can learn from it).

@jimoe666:

On this Leap 15.1 system, searching for case insensitive “HTTP_PROXY” in ‘/etc/’ gives the following result:


 # grep -Ri 'HTTP_PROXY' /etc/*
Binary file /etc/alternatives/jre/lib/libnet.so matches
Binary file /etc/alternatives/jre/lib/modules matches
Binary file /etc/alternatives/jre_11/lib/libnet.so matches
Binary file /etc/alternatives/jre_11/lib/modules matches
Binary file /etc/alternatives/ftp matches
Binary file /etc/alternatives/jre_openjdk/lib/libnet.so matches
Binary file /etc/alternatives/jre_openjdk/lib/modules matches
/etc/php7/cli/pear.conf:a:33:{s:9:"cache_dir";s:19:"/var/cache/php-pear";s:15:"default_channel";s:12:"pear.php.net";s:16:"preferred_mirror";s:12:"pear.php.net";s:13:"remote_config";s:0:"";s:13:"auto_discover";i:0;s:13:"master_server";s:12:"pear.php.net";s:10:"**http_proxy**";s:0:"";s:7:"php_dir";s:20:"/usr/share/php7/PEAR";s:7:"ext_dir";s:26:"/usr/lib64/php7/extensions";s:7:"doc_dir";s:24:"/usr/share/php7/PEAR/doc";s:7:"bin_dir";s:8:"/usr/bin";s:8:"data_dir";s:25:"/usr/share/php7/PEAR/data";s:7:"cfg_dir";s:24:"/usr/share/php7/PEAR/cfg";s:7:"www_dir";s:27:"/usr/share/php7/PEAR/htdocs";s:7:"man_dir";s:30:"/usr/share/php7/PEAR/local/man";s:8:"test_dir";s:25:"/usr/share/php7/PEAR/test";s:8:"temp_dir";s:14:"/tmp/pear/temp";s:12:"download_dir";s:18:"/tmp/pear/download";s:7:"php_bin";s:12:"/usr/bin/php";s:10:"php_prefix";s:0:"";s:10:"php_suffix";s:0:"";s:7:"php_ini";s:0:"";s:12:"metadata_dir";s:20:"/usr/share/php7/PEAR";s:8:"username";s:0:"";s:8:"password";s:0:"";s:7:"verbose";i:1;s:15:"preferred_state";s:6:"stable";s:5:"umask";i:18;s:9:"cache_ttl";i:3600;s:8:"sig_type";s:3:"gpg";s:7:"sig_bin";s:18:"/usr/local/bin/gpg";s:9:"sig_keyid";s:0:"";s:10:"sig_keydir";s:22:"/etc/php7/cli/pearkeys";}
/etc/profile.d/profile.sh:      HTTP_PROXY=*)
/etc/profile.d/profile.sh:          http_proxy="${val}"
/etc/profile.d/profile.sh:          export http_proxy
/etc/profile.d/profile.sh:    unset http_proxy https_proxy ftp_proxy gopher_proxy no_proxy NO_PROXY socks_proxy SOCKS_PROXY SOCKS5_SERVER
/etc/profile.d/profile.csh:    case HTTP_PROXY=*:
/etc/profile.d/profile.csh:     setenv http_proxy "${val:q}"
/etc/profile.d/profile.csh:     unsetenv http_proxy https_proxy ftp_proxy gopher_proxy no_proxy socks_proxy SOCKS_PROXY SOCKS5_SERVER
/etc/sysconfig/proxy:# Example: HTTP_PROXY="http://proxy.provider.de:3128/"
/etc/sysconfig/proxy:HTTP_PROXY=""
/etc/wgetrc:#http_proxy = http://proxy.yoyodyne.com:18023/
/etc/xdg/kioslaverc:httpProxy=HTTP_PROXY
 # 

Regardless of which user, a “normal” one or, “root”, echoing “$HTTP_PROXY” returns a null string …
[HR][/HR]Please note that, there’s more than a few places where “HTTP_PROXY” can be set, system wide, and, therefore, one has to tread carefully …

Running the source command will activate the new settings in the current User logon session, but a reboot will also work (that’s the main reason to implement in the /etc/profile…ocal)

TSU

Yes,
But only because the YaST Proxy setting on this machine is left hanging… configured but disabled.

TSU

Proxy, set by YaST, is exported as http_proxy (small letters).

AFAIK, the value of “HTTP_PROXY” should always explicitly defined as a quoted string, even if the value is a null string and, it’s good coding practice to have the definition preceding the export – despite the “bash” man page indicating otherwise:


HTTP_PROXY=""
export HTTP_PROXY

Maybe personal taste, but in any case it stresses the difference between the creating a variable and setting it’s value and the exporting of the variable to the environment. Something that is not understood by all.

Also

henk@boven:~> AAP=noot
henk@boven:~> echo $AAP
noot
henk@boven:~> AAP=
henk@boven:~> echo $AAP

henk@boven:~>

shows that using the “” for an empty string is not needed, but I agree that makes better reading and understanding. Again: coding practise.

I have been tracing the order of profile execution. I presume the profile scripts in /etc/ are executed first, then ~/.profile, <something>, ~/.bashrc .

The <something> is there because HTTP_PROXY is empty after ~/.profile is run, and is set when ~/.bashrc starts.

Does anyone know what happens between ~/.profile and ~/.bashrc?

Basicaly you find the documentation (as usual) in

man bash

I agrre that it is a lot to read, but start at the chapter INVOCATION.

If you actually traced profile execution, you would know it.

Does anyone know what happens between ~/.profile and ~/.bashrc?

Nothing because in default SUSE installation ~/.bashrc is sourced before ~/.profile unless you modified it.

bash does not source both .profile and .bashrc so this reading won’t answer it (although it is of course must read otherwise). Default SUSE /etc/profile sources .bashrc explicitly.

I “traced” it by inserting echo statements into scripts. HTTP_PROXY is empty leaving ~/.profile, and is set entering ~/.bashrc. Hence the assumption that <something> happened between the two scripts.

I logged into a separate account on this host. HTTP_PROXY is empty for that account. So the problem is unique to my main account.

Nothing because in default SUSE installation ~/.bashrc is sourced before ~/.profile unless you modified it.

This is at odds with the above observation. I have no recollection of ever messing with the profile scripts.

Aren’t the profile scripts executed whenever an app (say firefox or wireshark) is started? The Bash scripts would only apply for command windows, yes?

Here is a more detailed trace. It starts when I log in to the account. The last line is when a command window opens. The “before” and “after” in the .profile lines are outputs from the beginning of the script and at the end; HTTP_PROXY does not change at any time in .profile.

20191115-18:28:08 .profile - http_proxy before: 
20191115-18:28:08 .bashrc  - http_proxy before: 
20191115-18:28:08 .profile - http_proxy after:  
20191115-18:28:08 .bashrc  - http_proxy before: 
20191115-18:28:08 .profile - http_proxy before: 
20191115-18:28:08 .profile - http_proxy after:  
20191115-18:28:15 .bashrc  - http_proxy before: http://proxy1.sma.com:3128/

I am guessing there is some Gnome desktop startup code somewhere setting HTTP_PROXY.

Start with plain text mode logon on tty, this will eliminate most of the complexity associated with GUI. If this variable is not set, this is likely something in GUI part indeed.