Open GoogleCodeExporter opened 9 years ago
In case you're not running gnome or kde, then the 'default' fallback to envvar
(which is what linux used for the last decades) is used and offers the
functionality required.
Isn't that working as expected?
Original comment by dominiqu...@gmail.com
on 17 Jun 2010 at 8:05
No, I don't want to change the environment variable in all my terminals
whenever I switch network.
Original comment by felipe.contreras
on 17 Jun 2010 at 8:18
Not to mention there are background services like packagekit (yum will use
libproxy soon)... how am I supposed change the proxy for them?
Original comment by felipe.contreras
on 17 Jun 2010 at 8:19
PackageKit has a rather broken implementation of proxy handling anyway. If this
is not fundamentally restructured, you won't have luck with it.
libproxy reads user session settings. PK (and thus also yum) run as root.
Typically not, what your session has configured.
PK forwards the proxy from the user session to the root account with some
polkit magic, but it's far from 'working'...
Original comment by dominiqu...@gmail.com
on 8 Jul 2010 at 12:11
OK, then I could sudo and change the system libproxy config and use that
instead of GNOME's.
Moreover, what happens if i'm not using KDE or GNOME, but fluxbox, or just the
console?
/etc/proxy.conf and ~/.config/proxy.conf solve the problems perfectly.
Original comment by felipe.contreras
on 8 Jul 2010 at 12:34
If you're not using gnome or kde, then libproxy does the same as linux did for
the last decade: it uses envvar.
Original comment by dominiqu...@gmail.com
on 8 Jul 2010 at 6:59
Which is not improvement at all!
Applications are already using envvar, so what would libproxy bring?
Say I use fluxbox, and I switch to my company's VPN, now I need to use a proxy.
With libproxy, I can edit /etc/proxy.conf, and Firefox, yum, xchat, pidgin
would work.
Without libproxy, I have to edit /etc/yum.conf, manually configure Firefox,
edit ~/.xchat2/xchat.conf, and ~/.purple/prefs.xml.
If you remove the support for /etc/proxy.config, then I would also need to:
edit /etc/yum.conf, manually configure Firefox, edit ~/.xchat2/xchat.conf, and
~/.purple/prefs.xml.
See? No improvement at all.
What baffles me is that you already got it right at the beginning and now you
are going back to square one.
Original comment by felipe.contreras
on 8 Jul 2010 at 7:59
Of course not an improvement, but also no regression on those systems.
The 'problem' with a config file is the priorization in case of a gnome session
for example: what's higher? the config file or the gnome session config?
we are aware that a config file is a nice addon, but it's not as simple to get
it all right as it sounds (the awareness is also the reason why this bug for
example was not just rejected but is still open).
Original comment by dominiqu...@gmail.com
on 8 Jul 2010 at 9:37
Right, it's not a regression, but you are asking people to use libproxy without
bringing any improvements? I don't think that will fly.
If you don't have a libproxy config file, then obviously GConf is higher.
If you have a libproxy config file, then that takes precedence, and in the
config file the user should be able to specify the priorities of each method.
Original comment by felipe.contreras
on 9 Jul 2010 at 4:38
Let me put in my $0.02. In almost every case on modern Linux, NetworkManager
is used for network connectivity (even on servers). IMHO, proxy settings
should go in NetworkManager and libproxy should read them from there. This
would permit per-connection proxy settings in a much more sane way than the
current implementation (in GNOME). It would also be cross-desktop and would
solve the problem of the fluxbox user and eliminate the need for a config file
(config files should almost never be seen as an improvement).
Original comment by npmccallum@gmail.com
on 9 Jul 2010 at 5:09
Not everyone uses NetworkManager, and not everyone uses a graphical UI.
For the ones that do, sure, a config file should not be needed.
But for the rest, a config file might be pretty much the only option.
Besides, while PackageKit gets fixed, a config file would also do the deed.
Original comment by felipe.contreras
on 9 Jul 2010 at 9:17
I've created a new ticket status (PatchWanted) and updated this case. I agree
it would be nice to have this feature, but there are more important things for
us to work on. A cleanly written patch will be accepted and merged.
Original comment by npmccallum@gmail.com
on 9 Jul 2010 at 9:29
Just as a 'side' not here: There is a config_sysconfig module, which was
proposed and merged by the openSUSE project (it's per default only active for
user root).
It uses the file /etc/sysconfig/proxy, which exists on any SUSE based system.
For not causing trouble with user sessions, this config module though is
skipped for non-root users. For root users it has precendence over anything
else, as root never has (or should have) a gnome or kde session)
Of course that does not yet solve the 'fluxbox' usecase, But it does address
the 'system service' usecase from comment 3.
Original comment by dominiqu...@gmail.com
on 12 Aug 2011 at 6:26
Hello there,
I thought that libproxy would help me with the problem (or scenario) I have,
and instead of that I stumbled upon this ticket where you guys kept telling
more than once something like "the same as linux did for the last decade: it
uses envvar"...
Oh well, let me tell you about my use case:
I have to setup a linux server hosted appliance (web server based
http://www.redmine.org for instance) inside a virtual machine in a corporate
environment. Until I'm experimenting, I managed to get Firefox from inside that
virtual guest to connect to the internet via the corporate PAC URL. Of course,
I could also just set some proxy server from the PAC file in env_vars for
having console apps working with the proxy, but imagine that PAC file is
several pages long, different destinations have to be routed differently. So
I'd actually need libproxy being able to use PAC, without forcing me to even
install a desktop environment, mozillolloida or anything like that on this
virtual server (which I finally won't, because it's a server), for being able
to maintain the packages (one example beeing wget patched to use libproxy) of
that system via SSH console only. Is there any way to achieve that, did I miss
some possibility?
Thanks in advance,
Lucian
Original comment by lmuresa...@gmail.com
on 17 Apr 2012 at 11:14
export http_proxy=wpad://
or
export http_proxy=pac+http://path/to.pac
Original comment by nathan...@themccallums.org
on 17 Apr 2012 at 2:07
Thanks Nathan for your reply, that helps further, but it's still not working, I
found out that on my system (Gentoo) libproxy-0.4.7 wasn't even built with any
pacrunner support, so I rebuilt it with webkit support, if I'm trying the proxy
utility shipped with libproxy now I'm getting this:
_PX_DEBUG=1 http_proxy=pac+http://proxyconf._MY_COMPANY_.net/ proxy
http://libproxy.googlecode.com/files/libproxy-0.4.7.tar.gz
Using config: 23envvar_config_extension
Using ignore:
Config is: pac+http://proxyconf._MY_COMPANY_.net/
PAC received!
Using pacrunner: 26webkit_pacrunner_extension
Pacrunner returned:
direct://
Maybe you can suggest how to debug this more thoroughly?
Original comment by lmuresa...@gmail.com
on 17 Apr 2012 at 3:42
So, after further testing I found that the "pac+http" scheme works. I also
improved the wget patch found in the opensuse bugtracker to actually make use
of this, I will polish it a bit more and send upstream wget. Actually I might
try to do the same for aria2c and git. Possibly subversion might support this
via neon, I've got to investigate this.
However, I've got one more question, is "pac+http" the only scheme supported in
libproxy for direct PAC retrieval? I found that "pac+https" and "pac+ftp" is
not able to download the PAC file served over https or ftp:
Schnappi libproxy-0.4.7 # _PX_DEBUG=1 ftp_proxy=pac+ftp://localhost/proxy.pac
proxy ftp://ftp.mozilla.org/pub/ls-lR.gz
Using config: 23envvar_config_extension
Using ignore:
Config is: pac+ftp://localhost/proxy.pac
Unable to download PAC!
direct://
Schnappi libproxy-0.4.7 # _PX_DEBUG=1 ftp_proxy=pac+https://localhost/proxy.pac
proxy ftp://ftp.mozilla.org/pub/ls-lR.gz
Using config: 23envvar_config_extension
Using ignore:
Config is: pac+https://localhost/proxy.pac
Unable to download PAC!
direct://
Schnappi libproxy-0.4.7 # _PX_DEBUG=1 ftp_proxy=pac+http://localhost/proxy.pac
proxy ftp://ftp.mozilla.org/pub/ls-lR.gz
Using config: 23envvar_config_extension
Using ignore:
Config is: pac+http://localhost/proxy.pac
PAC received!
Using pacrunner: 26webkit_pacrunner_extension
Pacrunner returned: PROXY ftp-proxy.t-online.de
http://ftp-proxy.t-online.de
Original comment by lmuresa...@gmail.com
on 18 Apr 2012 at 1:02
The RFC draft for WPAD only specifies HTTP. I'm not aware of any software
package which uses HTTPS or FTP.
Original comment by nathan...@themccallums.org
on 18 Apr 2012 at 2:42
Thanks, that clarifies it.
Original comment by lmuresa...@gmail.com
on 18 Apr 2012 at 3:49
Original issue reported on code.google.com by
felipe.contreras
on 17 Jun 2010 at 7:52