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?
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.
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.
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.
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).
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)
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:
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.
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?
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.
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.