Getting proxy support on GNOME; for real (libproxy-simple)

If you open gnome-network-properties and setup your proxy accordingly you would notice that most network applications don’t really work. There are several reasons for that.

Since as long as I can remember I have looked for a way to add proxy support on my applications. There has been a number of network libraries, none of which have ever fitted the bill for me. Finally, came GIO, now part of GLib, which has many advantages (although IMO not ideal; it works perfectly). Unfortunately, no proxy support.

There’s also libproxy, which one might think has proxy support, but it doesn’t; it merely provides a mechanism to find proxy configuration. This is good, but not the full picture.

But since GIO has plug-ins, it might be possible to provide proxy support transparently, with the help of libproxy… right? That’s where GLib networking comes. Great! So we have everything we need.

Not really.

You can read the full debate on Ubuntu’s bug report for Empathy. There are two major obstacles.

1) GLib developers don’t want HTTP Connect to work seamlessly

2) libproxy developers have changed their opinion on that GConf values mean

GLib

Let’s start with the first. AFAICR GLib developers said; well, libproxy plugins cannot have a backup method, so if you specify a global HTTP Connect proxy, applications would try to use it, then fail, and do nothing else; instead, they should try the direct method as a fallback.

While that’s true, the fact of the matter is that *today* all applications fail anyway! First implement the main case, then worry about the fall-back!

But I guess for GLib developers everything has to be perfect the first time, even if this is not GLib, but GLib networking. If you want HTTP Connect support, implement it yourself, GLib won’t help you. Fortunately, that’s what people do already anyway.

libproxy

The idea of libproxy sounded great; you have a single library that has all you need to get the proxy configuration: GConf, KDE settings, a personal configuration file, or even environment variables.

Except that at some point they decided that a personal configuration file was too difficult to maintain, and they decided to interpret GConf settings differently. So now libproxy is basically useless.

Yes, if you open gnome-network-properties, select “Manual proxy configuration”, “Use the same proxy for all protocols”, and input your “HTTP proxy”, libproxy will assume you are using a socks proxy. Stupid.

I discussed this with a libproxy developer. Before, you could have HTTP Connect for all protocols, and socks also for all protocols, but now, HTTP Connect for all protocols is not possible. Now, only socks for all protocols work, not HTTP Connect. Their answer; people don’t use HTTP Connect anyway.

Again, nonsense; most people use HTTP Connect.

Fix it

So, what if you are like me; behind an HTTP Connect proxy? Well, you use Pidgin, or something not-GNOME that implements proxy support by themselves.

Or you do like me.

After getting the latest glib, glib-networking, telepathy-glib, and telepathy-gabble (which implements HTTP Connect by themselves), you would still have the problem that libproxy will interpret GConf wrongly. That’s why I wrote libproxy-simple.

Just clone it, build it:
make prefix=/opt/libproxy-simple install

And run telepathy-gabble with the right LD_LIBRARY_PATH:
LD_LIBRARY_PATH=/opt/libproxy-simple/lib GABBLE_PERSIST=1 /opt/gabble/libexec/telepathy-gabble

That’s it, libproxy-simple would emulate the full-blown libproxy, but instead to something useful; parse the GConf settings properly.

I also implemented libproxy support in XChat, which will probably be available in the next version 2.8.10. Just use the same trick (LD_LIBRARY_PATH=/opt/libproxy-simple/lib) and it will automatically pick the right proxy from GConf.

What about other programs? Well, unfortunately my workaround is only useful for 2), that means if the application already has proxy support, but it’s not getting the right configuration, then the LD_LIBRARY_PATH trick would help. Otherwise, you would are out of luck :(

About these ads

9 thoughts on “Getting proxy support on GNOME; for real (libproxy-simple)

  1. I’m not sure SOCKSv5/4a/4 users will appreciate much you libproxy-simple. Also, I hope you notice that GConf is no longer the configuration daemon in Gnome 3. Another reason why libproxy-simple is useless is because it’s not thread safe, which is the reason of some of libproxy complexity.

    > 1) GLib developers don’t want HTTP Connect to work seamlessly

    As said I want it, but I didn’t had enough justification at the time of writing. The good news is that more Telepathy connection manager are moving to GIO, thus Gabble (the XMPP Jabber connection manager) will not be the only one needing HTTP proxy. Hopefully that will convince more people wee need it in Glib.
    Also this affirmation is incorrect, cause if they didn’t wanted they would have made it really difficult to support in your program, but in Gabble/Wocky we have it, and it was not difficult at all.

  2. @Nicolas

    It’s easy to add SOCKS support, just look at socks_host/socks_port and use that for all the ports.

    How can you say libproxy-simple is useless when has worked perfectly for me? I have never encountered a problem with it. Sure, theoretically speaking there might be issues, but those can be easily solved.

    In the meantime; it does the job. Which is more than what I can say of libproxy.

    Anyway, if I make those changes, would you endorse libproxy-simple? I don’t think so. So what’s wrong with making it usable for my particular use-case? (And AFAIK the most pervasive one).

    And regarding GNOME 3, I hope they have fixed the proxy configuration. But I don’t use GNOME 3, nor I plan to. I use XFCE.

    As most people are still using GNOME 2, it’s nice to have something to get things working today for Google Chrome, Pidgin, Empathy, and X-Chat.

    And sure, GLib developers made proxy support possible, but not HTTP Connect, that’s just a side effect.

  3. Hi

    Can you please describe where to set LD_LIBRARY_PATH.
    Empathy looks through the service file to locate the binary and starts it automatically.
    So how can we influence this gabble startup through LD_LIBRARY_PATH?
    I am sorry it might be simple question but we are novice.
    please explain in detail.

    Looking forward for your reply.
    Regards.

  4. @Santosh Not if you start the service manually.

    If you run this:
    LD_LIBRARY_PATH=/opt/libproxy-simple/lib GABBLE_PERSIST=1 /usr/libexec/telepathy-gabble

    Then telepathy-gabble will always be running, and would start receiving D-Bus calls from Empathy. Make sure to run first gabble, and then Empathy. Also make sure that the command actually runs; it would fail if there’s another instance of telepathy-gabble running on the background.

    And use the appropriate telepathy-gabble (that has proxy support).

  5. @Felipe
    Here is what I did, pls guide me where Im wrong:

    [santosh@santosh-desktop ~]$ LD_LIBRARY_PATH=/opt/libproxy-simple/lib GABBLE_PERSIST=1 /usr/libexec/telepathy-gabble
    (telepathy-gabble:995): tp-glib-DEBUG: started version 0.11.8 (telepathy-glib version 0.14.5)

    -> Now the telepathy gabble is running
    -> then started empathy, and tried to configure google talk account which resulted in “Network Error”.

    FYI, Proxy is already set in the system and pidgin works fine.

  6. I don’t know if this is of any help for anyone, but I personally use a small Chromium addon(ProxySwitchy) to switch proxies very quickly. It supports multiple presets and automagically sets up the Gnome proxy configuration, over DBus I guess, and all the Gnome apps that I care about are aware of that setting.

    I only wish zsh was able to automatically set http_proxy when I set it in the browser addon, and why not even alias ssh to go through corkscrew in that case. Anyway I worked around this by creating some aliases that help me to quickly toggle the proxy manually and to use corkscrew for SSH when http_proxy is set.

  7. Loads of you are miss-informed, Chromium and Pidgin does not use libproxy but reads directly from Gnome 2 settings. They also don’t work well on Gnome3 because of that, just like libproxy-simple.

    Also, libproxy-simple is total no go the way it is, as it’s missing support for network exclusion, which means you’ll end up proxying your local network stuff and localhost, which is bound to failure. Those network exclusion list are quite hard to parse correctly, glib-networking Gnome3 back-end does a pretty poor job with it compare to libproxy. And this Gnome3 back-end was written and reviewed by very good GLib GIO developers.

  8. Loads of you are miss-informed, Chromium and Pidgin does not use libproxy but reads directly from Gnome 2 settings. They also don’t work well on Gnome3 because of that, just like libproxy-simple.

    Misinformed in what sense? Pidgin and Chrome work just fine without using libproxy.

    And yeah, there’s brokerage with GNOME 3 (thanks to GNOME developers), but fortunately there are ways around that; libpurple has other configuration methods, and Chrome can use ProxySwitchy, or one can manually edit the GConf entries.

    Also, libproxy-simple is total no go the way it is, as it’s missing support for network exclusion, which means you’ll end up proxying your local network stuff and localhost, which is bound to failure.

    You are still missing the point; GNOME network capabilities are totally broken right now. It’s not if you are accessing the local network, or localhost; it is all the time.

    Those network exclusion list are quite hard to parse correctly, glib-networking Gnome3 back-end does a pretty poor job with it compare to libproxy. And this Gnome3 back-end was written and reviewed by very good GLib GIO developers.

    Except that it doesn’t work at all. Yeah, I tried GNOME 3, and it also fails miserably.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s