[opensuse-factory] global proxy configuration
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it? 2)now proxy requires relogin to work, but yast does not warns user about it, when user changes proxy settings. moreover yast shows proxy config, just as user set it, if user wants to check current proxy settings. and this confuses, if this settings still not applied, and waiting for relogin. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2008-12-12 at 23:43 +0300, z wrote:
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it?
It should work well in GNOME, in Mozilla and a few other that understand the proxy configuration. Anything based off the environment variables will not. Hub -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hubert Figuiere wrote:
On Fri, 2008-12-12 at 23:43 +0300, z wrote:
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it?
It should work well in GNOME, in Mozilla and a few other that understand the proxy configuration.
Anything based off the environment variables will not.
z, were you getting at this sort of situation?: If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there). The lack of a working 'abort' button [0] in the YaST software tools means your best bet is to identify the process and (as root) kill it, then try again. [0] an ongoing problem, recently re-opened as bug #407104 https://bugzilla.novell.com/show_bug.cgi?id=407104 -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2008/12/13 Richard (MQ) <osl2008@googlemail.com>:
Hubert Figuiere wrote:
On Fri, 2008-12-12 at 23:43 +0300, z wrote:
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it?
It should work well in GNOME, in Mozilla and a few other that understand the proxy configuration.
Anything based off the environment variables will not.
z, were you getting at this sort of situation?:
i have opensuse 11.1 RC1 with KDE 4.1.3 when i go to yast->networkservices->proxy and enable\disable proxy, it will not be truly enabled\disabled until relogin. (if i disable proxy, environment variables still unchanged[contain previous proy addresses] and software downloads via yast will fail, if proxy server can't be reached )
If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there).
yes, this method does not work for me.
The lack of a working 'abort' button [0] in the YaST software tools means your best bet is to identify the process and (as root) kill it, then try again.
[0] an ongoing problem, recently re-opened as bug #407104 https://bugzilla.novell.com/show_bug.cgi?id=407104 -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2008/12/13 Richard (MQ) <osl2008@googlemail.com>:
Hubert Figuiere wrote:
On Fri, 2008-12-12 at 23:43 +0300, z wrote:
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it?
It should work well in GNOME, in Mozilla and a few other that understand the proxy configuration.
Anything based off the environment variables will not.
z, were you getting at this sort of situation?:
i have opensuse 11.1 RC1 with KDE 4.1.3 when i go to yast->networkservices->proxy and enable\disable proxy, it will not be truly enabled\disabled until relogin. (if i disable proxy, environment variables still unchanged[contain previous proy addresses] and software downloads via yast will fail, if proxy server can't be reached )
If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there).
yes, this method does not work for me.
2008/12/14 z <zoomer.gm@gmail.com>: this bug is still here in 11.1 release. should i create a bugreport?
The lack of a working 'abort' button [0] in the YaST software tools means your best bet is to identify the process and (as root) kill it, then try again.
[0] an ongoing problem, recently re-opened as bug #407104 https://bugzilla.novell.com/show_bug.cgi?id=407104 -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
z wrote:
If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there).
yes, this method does not work for me. this bug is still here in 11.1 release. should i create a bugreport?
What version of yast2-pkg-bindings do you have? In https://bugzilla.novell.com/show_bug.cgi?id=402593#c7 we are told it is fixed in yast2-pkg-bindings-2.17.13 If you have this or later, I think a new bug is necessary; else not. -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/19 Richard (MQ) <osl2008@googlemail.com>:
z wrote:
If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there).
yes, this method does not work for me. this bug is still here in 11.1 release. should i create a bugreport?
What version of yast2-pkg-bindings do you have? In https://bugzilla.novell.com/show_bug.cgi?id=402593#c7 we are told it is fixed in yast2-pkg-bindings-2.17.13
If you have this or later, I think a new bug is necessary; else not.
i have yast2-pkg-bindings-2.17.29 checked yast proxy settings now, i can confirm, that it works for turnin proxy on. but turning proxy off does requires relogin, else i have complaining message from yast-software-mgmt, yast-sw-update, and they can't refresh repositories. https://bugzilla.novell.com/show_bug.cgi?id=458708 reopened
-- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
z wrote:
2009/1/19 Richard (MQ) <osl2008@googlemail.com>:
z wrote:
If a YaST software tool stops due to e.g. wrong proxy settings preventing successful download, it would be nice if you could use the YaST proxy configuration to fix the problem before selecting "re-try" in the first window. Unfortunately this doesn't seem to work in 11.1RC1, I know not why (I will test in 11.1 final and file a bug if confirmed there).
yes, this method does not work for me. this bug is still here in 11.1 release. should i create a bugreport? What version of yast2-pkg-bindings do you have? In https://bugzilla.novell.com/show_bug.cgi?id=402593#c7 we are told it is fixed in yast2-pkg-bindings-2.17.13
If you have this or later, I think a new bug is necessary; else not.
Apologies, I got confused between two related bugs that I'm following: my comments above are unrelated to the issue that you report. i have yast2-pkg-bindings-2.17.29
checked yast proxy settings now, i can confirm, that it works for turnin proxy on. but turning proxy off does requires relogin, else i have complaining message from yast-software-mgmt, yast-sw-update, and they can't refresh repositories. https://bugzilla.novell.com/show_bug.cgi?id=458708 reopened
Yes, I see this unwanted behaviour too. I have several machines that I use both at work (where I'm behind a non-transparent proxy) and at home (where the proxy is transparent - can be ignored for YaST). Moving from the Work environment to home, if I forget to disable the proxy YaST software management insists on using it without an effective abort (that's bug https://bugzilla.novell.com/show_bug.cgi?id=402593). Using YaST -> Network Services -> Proxy to correct (remove) the unwanted proxy has no effect on an already-running YaST -> Software management -> Online-Update or similar. Exiting and re-starting YaST allows the new setting to be seen properly. This is bug https://bugzilla.novell.com/show_bug.cgi?id=458708 Sorry for any confusion -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi z ( and others) I'll try to shed some more light into the issue.
1)can global proxy enabling\disabling be performed on-the-fly, without need of relogin? or are there some troubles with it?
It depends on the application. In general, if the application reads proxy settings from some config file (sysconfig, for example), you don't need to re-login. Application picks up proxy settings on the next start. On the other hand, if the application relies upon $http_proxy ($FTP_PROXY, whatever) environment variable being set, restarting application is not enough and relogin is needed. It is because these env. variables need to be updated (there is a script executed upon login doing that). What happens in YaST and libzypp (and curl, because libzypp is libcurl-based) is a mix of both approaches: 1) Switching proxy from Off to On: YaST module writes proxy URL into /root/.curlrc file. Until you log in again, $http_proxy env. variable remains empty. But we don't mind, because libzypp's media handling library pokes into /root/.curlrc and uses proxy URL from there. Everyone is happy :) 2) Switching proxy from On to Off: YaST module clears /root/.curlrc file, but until relogin, $http_proxy variable remains set and libcurl (thus, libzypp too) still uses that URL even though you don't want to use proxy anymore. Some people are not that happy anymore :(
2)now proxy requires relogin to work, but yast does not warns user about it, when user changes proxy settings.
YaST proxy module had pop-up telling user to relogin to apply the configuration, but we removed it in openSUSE 10.3 (for usability reasons, afair) :( Come to think of it, it was not so good idea ... now even the help text does not mention the need of relogin (and even if it did, nobody reads the help anyway). Allright, the bug (https://bugzilla.novell.com/show_bug.cgi?id=458708) is already assigned to me, I'll put the pop-up back. B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Katarina Machalkova wrote:
Hi z ( and others)
I'll try to shed some more light into the issue. Thanks! ... 2) Switching proxy from On to Off: YaST module clears /root/.curlrc file, but until relogin, $http_proxy variable remains set and libcurl (thus, libzypp too) still uses that URL even though you don't want to use proxy anymore. Some people are not that happy anymore :(
Presumably, it's only necessary to clear $http_proxy for the environment that applies for YaST - closing all YaST windows and starting afresh using something along the lines of control-F2 then kdesu "export $http_proxy=''; yast2" should work without actually logging out and in - not sure if this is quite the correct syntax though? Any bash scripting experts care to advise?
Allright, the bug (https://bugzilla.novell.com/show_bug.cgi?id=458708) is already assigned to me, I'll put the pop-up back.
I think this is a good idea - it will affect few people but is a big problem to them. Thanks! -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/20 Richard (MQ) <osl2008@googlemail.com>:
Katarina Machalkova wrote:
Presumably, it's only necessary to clear $http_proxy for the environment that applies for YaST - closing all YaST windows and starting afresh using something along the lines of control-F2 then
kdesu "export $http_proxy=''; yast2"
Using env(1) seems neater to me. And worked within ALT-F2 which doesn't seem to wrap a sh -c "..." around the text entered. env http_proxy= kdesu yast2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/20 Richard (MQ) <osl2008@googlemail.com>:
Katarina Machalkova wrote:
Presumably, it's only necessary to clear $http_proxy for the environment that applies for YaST - closing all YaST windows and starting afresh using something along the lines of control-F2 then
kdesu "export $http_proxy=''; yast2"
Using env(1) seems neater to me. And worked within ALT-F2 which doesn't seem to wrap a sh -c "..." around the text entered.
env http_proxy= kdesu yast2
Does this mean it is possible to disable proxy use by libzypp without relogin? Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
Does this mean it is possible to disable proxy use by libzypp without relogin?
environ(7) explains editting the environment of current process, which affects forked children. But that does not affect parent processes, it's a local not global change. So in general no. For curl usage by YaST, always nullify http_proxy and only use ~root/.curlrc, or manage it's own setting somewhere to overwrite the _proxy variables, might be a solution.
From curl(1)
-x/--proxy <proxyhost[:port]> Use specified HTTP proxy. If the port number is not specified, it is assumed at port 1080. This option overrides existing environment variables that sets proxy to use. If there's an environment variable setting a proxy, you can set proxy to "" to override it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
Does this mean it is possible to disable proxy use by libzypp without relogin?
environ(7) explains editting the environment of current process, which affects forked children. But that does not affect parent processes, it's a local not global change. So in general no.
For curl usage by YaST, always nullify http_proxy and only use ~root/.curlrc, or manage it's own setting somewhere to overwrite the _proxy variables, might be a solution.
From curl(1)
-x/--proxy <proxyhost[:port]> Use specified HTTP proxy. If the port number is not specified, it is assumed at port 1080. This option overrides existing environment variables that sets proxy to use. If there's an environment variable setting a proxy, you can set proxy to "" to override it.
Ok I just tested, I disabled proxy via yast and then shut squid down. ..curl was then cleaned out but the variable $http_proxy still contained the proxy address and zypper ref failed. I then export http_proxy= and zypper ref worked correctly. From this I would conclude yast proxy settings should clear the environment variable when proxy is disabled and the problem of logout/login being required would be solved, would you agree? Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/21/2009 at 1:15 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote: Ok I just tested, I disabled proxy via yast and then shut squid down. ..curl was then cleaned out but the variable $http_proxy still contained the proxy address and zypper ref failed. I then export http_proxy= and zypper ref worked correctly. From this I would conclude yast proxy settings should clear the environment variable when proxy is disabled and the problem of logout/login being required would be solved, would you agree?
You can't clear an environment variable from a parent process (shell). This is simply not possible. Check this schema bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2) Whenever you spawn a child process, the environment from the parent is copied and that's the only environment you can modify. So if yast-doSomething would clear the http_proxy, that would be completely useless for a later start of zypper, as it will copy env0 again and create 0.2... so no go at all... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dominique Leuenberger wrote:
On 1/21/2009 at 1:15 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote:
Ok I just tested, I disabled proxy via yast and then shut squid down. ..curl was then cleaned out but the variable $http_proxy still contained the proxy address and zypper ref failed. I then export http_proxy= and zypper ref worked correctly. From this I would conclude yast proxy settings should clear the environment variable when proxy is disabled and the problem of logout/login being required would be solved, would you agree?
You can't clear an environment variable from a parent process (shell). This is simply not possible.
Check this schema
bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2)
Whenever you spawn a child process, the environment from the parent is copied and that's the only environment you can modify. So if yast-doSomething would clear the http_proxy, that would be completely useless for a later start of zypper, as it will copy env0 again and create 0.2... so no go at all...
Dominique
I understand from this that I can clear the variable myself from a root konsole but yast is unable to do this, correct? As I said previously I successfully stopped a fresh instance of zypper from using the proxy by clearing the variable from the command line as root. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/21/2009 at 2:00 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote: Dominique Leuenberger wrote: bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2)
I understand from this that I can clear the variable myself from a root konsole but yast is unable to do this, correct? As I said previously I successfully stopped a fresh instance of zypper from using the proxy by clearing the variable from the command line as root. Regards Dave P
you can do so as root as you're 'working' in bash in which own env0. So all set and unset operations go straight there. As soon as you start another process, it receives a copy of env0 and thus it can't change the environment for any command you're going to start from bash later on. you as user in bash modify env0, yast will only have access to env0.1 (not a problem of yast, it's the way process spawning deals with environments) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/21/2009 at 2:03 PM, "Dominique Leuenberger" <Dominique.Leuenberger@TMF-Group.com> wrote:
On 1/21/2009 at 2:00 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote: Dominique Leuenberger wrote: bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2)
you as user in bash modify env0, yast will only have access to env0.1 (not a problem of yast, it's the way process spawning deals with environments)
Just a very simple example showing you that this is not possible: create a bash script like: ---- snip ---- #!/bin/bash echo Testvar has value $testvar unset testvar echo Testvar has value $testvar ---- snip ---- No in your bash:
export testvar="Test data" sh myscript.sh echo Testvar has value $testvar
Testvar has value Test data Testvar has value Testvar has value Test Data (the first two echos come from the script.. so it inherited testvar from your bash. it unsets the variable afterwards and you can confirm this with the echo which does no longer have a value. As soon as the script is over, you get back to your console where you can verify that the changed variable is not given back to the parent shell. I hope this helps to show the way environments are handled. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dominique Leuenberger wrote:
On 1/21/2009 at 2:03 PM, "Dominique Leuenberger"
<Dominique.Leuenberger@TMF-Group.com> wrote:
On 1/21/2009 at 2:00 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote:
Dominique Leuenberger wrote:
bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2)
you as user in bash modify env0, yast will only have access to env0.1 (not a problem of yast, it's the way process spawning deals with environments)
Just a very simple example showing you that this is not possible: create a bash script like:
---- snip ---- #!/bin/bash echo Testvar has value $testvar unset testvar echo Testvar has value $testvar
---- snip ----
No in your bash:
export testvar="Test data" sh myscript.sh echo Testvar has value $testvar
Testvar has value Test data Testvar has value Testvar has value Test Data
(the first two echos come from the script.. so it inherited testvar from your bash. it unsets the variable afterwards and you can confirm this with the echo which does no longer have a value. As soon as the script is over, you get back to your console where you can verify that the changed variable is not given back to the parent shell.
I hope this helps to show the way environments are handled.
Dominique
Ok I think I have the idea, I turned off proxy in yast logged into tty2 as root and the variable was not set, I turned on proxy in yast and variable was still not set in tty2, I logged out of tty and then in again and the variable was set. From this I conclude I should only use environment variables in programs for static things and rather use a config file for things that might need to be changed on the fly. Logging out and in to a console is easy but a pain with a gui. I suppose I will just have to control my speed by changing squid.conf and restarting squid as I have for a while now. Thanks for your patience with me. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 Dominique Leuenberger <Dominique.Leuenberger@tmf-group.com>:
On 1/21/2009 at 1:15 PM, Dave Plater <dave.plater@yahoo.co.uk> wrote: Ok I just tested, I disabled proxy via yast and then shut squid down. ..curl was then cleaned out but the variable $http_proxy still contained the proxy address and zypper ref failed. I then export http_proxy= and zypper ref worked correctly. From this I would conclude yast proxy settings should clear the environment variable when proxy is disabled and the problem of logout/login being required would be solved, would you agree?
You can't clear an environment variable from a parent process (shell). This is simply not possible.
Check this schema
bash (env0) yast2 (env0.1) yast2-doSomething (env0.1.1) zypper (env0.2)
Whenever you spawn a child process, the environment from the parent is copied and that's the only environment you can modify. So if yast-doSomething would clear the http_proxy, that would be completely useless for a later start of zypper, as it will copy env0 again and create 0.2... so no go at all...
OK, i don't aknowledged with curl\libcurl (which libzypp uses?) Is there a way to force all curl calls from libzypp to use only ~/.curlrc settings? (which yast can control) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 z <zoomer.gm@gmail.com>:
OK, i don't aknowledged with curl\libcurl (which libzypp uses?) Is there a way to force all curl calls from libzypp to use only ~/.curlrc settings? (which yast can control)
That's what I think will happen if http_proxy etc are always nullified, when yast uses libzyp & libcurl. forked children meant future ones forked after the change. 2009/1/21 Rob OpenSuSE <rob.opensuse.linux@googlemail.com>:
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
Does this mean it is possible to disable proxy use by libzypp without relogin?
environ(7) explains editing the environment of current process, which affects forked children. But that does not affect parent processes, it's a local not global change. So in general no.
For curl usage by YaST, always nullify http_proxy and only use ~root/.curlrc, or manage it's own setting somewhere to overwrite the _proxy variables, might be a solution.
From curl(1)
-x/--proxy <proxyhost[:port]> Use specified HTTP proxy. If the port number is not specified, it is assumed at port 1080. This option overrides existing environment variables that sets proxy to use. If there's an environment variable setting a proxy, you can set proxy to "" to override it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/21 z <zoomer.gm@gmail.com>:
OK, i don't aknowledged with curl\libcurl (which libzypp uses?) Is there a way to force all curl calls from libzypp to use only ~/.curlrc settings? (which yast can control)
That's what I think will happen if http_proxy etc are always nullified, when yast uses libzyp & libcurl. forked children meant future ones forked after the change.
2009/1/21 Rob OpenSuSE <rob.opensuse.linux@googlemail.com>:
If I do that in bash.bashrc.local then maybe it might work? Regards Dave P
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
Does this mean it is possible to disable proxy use by libzypp without relogin?
environ(7) explains editing the environment of current process, which affects forked children. But that does not affect parent processes, it's a local not global change. So in general no.
For curl usage by YaST, always nullify http_proxy and only use ~root/.curlrc, or manage it's own setting somewhere to overwrite the _proxy variables, might be a solution.
From curl(1)
-x/--proxy <proxyhost[:port]> Use specified HTTP proxy. If the port number is not specified, it is assumed at port 1080. This option overrides existing environment variables that sets proxy to use. If there's an environment variable setting a proxy, you can set proxy to "" to override it.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
If I do that in bash.bashrc.local then maybe it might work?
I don't think so, I was suggesting an alteration to nullify the proxy strings, specifically aimed to clean up the package management behaviour, when the proxy usage is turned off. That is to rely soley on what's written in ~root/.curlrc, avoiding user http_proxy settings. The behaviour of the environment, is performance and ease for programmer oriented. Effectively it is an in-process memory cache of configuration oriented settings, without reading disk files, or accessing a database. Knowledgeable experienced users do not expect, changes to those settings to be immediately effective. info:/bash/Bash Startup Files Suggests possibily of defining BASH_ENV, a startup file that would be read by non-interactive /bin/bash scripts. However there's no guarantee this would be run. The specification of char ** environ as a variable, makes it hard to provide new backends with more sophisticated configurable cache-ing behaviour via getenv/putenv/setenv/unsetenv/clearenv functions. So software suites which need sophisticated configuration, use other methods. For example browsers provide ways for Network Admin to configure automatic proxy detection. Hopefully these explanations will help you understand the explanation Katarina Machalkova gave earlier in the thread. If not then some generalised reading on concepts of processes, environment will make things clearer. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/21 Dave Plater <dave.plater@yahoo.co.uk>:
If I do that in bash.bashrc.local then maybe it might work?
I don't think so, I was suggesting an alteration to nullify the proxy strings, specifically aimed to clean up the package management behaviour, when the proxy usage is turned off. That is to rely soley on what's written in ~root/.curlrc, avoiding user http_proxy settings.
The behaviour of the environment, is performance and ease for programmer oriented. Effectively it is an in-process memory cache of configuration oriented settings, without reading disk files, or accessing a database. Knowledgeable experienced users do not expect, changes to those settings to be immediately effective.
info:/bash/Bash Startup Files Suggests possibily of defining BASH_ENV, a startup file that would be read by non-interactive /bin/bash scripts. However there's no guarantee this would be run.
The specification of char ** environ as a variable, makes it hard to provide new backends with more sophisticated configurable cache-ing behaviour via getenv/putenv/setenv/unsetenv/clearenv functions. So software suites which need sophisticated configuration, use other methods. For example browsers provide ways for Network Admin to configure automatic proxy detection.
Hopefully these explanations will help you understand the explanation Katarina Machalkova gave earlier in the thread. If not then some generalised reading on concepts of processes, environment will make things clearer.
I have resigned myself to changing delay_pools values in squid.conf and rcsquid restart to control bandwidth usage on the fly as before. Thanks for the enlightenment as far a environments are concerned, I'm still a newbie as far as nix systems are concerned. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (7)
-
Dave Plater -
Dominique Leuenberger -
Hubert Figuiere -
Katarina Machalkova -
Richard (MQ) -
Rob OpenSuSE -
z