| |||||||||||||
Mark Shuttleworth at LinuxTagMark Shuttleworth at LinuxTagPosted Jun 15, 2010 20:43 UTC (Tue) by dale.sykora (guest, #57981)Parent article: Mark Shuttleworth at LinuxTag
It would be nice if automated testing covered web proxy usage. Most problems I see with Ubuntu seem related to running behind a corporate firewall with proxy settings.
(Log in to post comments)
Mark Shuttleworth at LinuxTag Posted Jun 15, 2010 22:05 UTC (Tue) by marcH (subscriber, #57642) [Link]
What kind of software do you have in mind?
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 13:34 UTC (Wed) by dale.sykora (guest, #57981) [Link]
I do not have a particular automation testing software in mind, but I assume Ubuntu has some automated scripts to test basic stuff. I'm suggesting they run some of the automated tests on a machine that uses a proxy to see if anything is broken. I have noticed UbuntuOne cloud storage doesn't work behind a proxy. Also, some package install/updates fail (flash for instance).
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 19:57 UTC (Wed) by marcH (subscriber, #57642) [Link]
Sorry my question was not clear: What kind of software typically does not work behind a proxy? Examples?
Mark Shuttleworth at LinuxTag Posted Jun 17, 2010 4:47 UTC (Thu) by dougsk (guest, #25954) [Link]
circa centos 4.(2|3?) I ran into issues with yum. I pushed a script to export the HTTP_PROXY variable at boot up as I couldn't get the boxes to honor WPAD, mind you that was the gotohell plan as I had a two hour maintenance window. Could have been me.
Further down the road I ran into a host of issues with some other "corner" applications and platforms as well [Looked good in lab, meh]. In order to mitigate the pain, I put transparent proxies in place and have never looked back.
Mark Shuttleworth at LinuxTag Posted Jun 17, 2010 7:03 UTC (Thu) by walles (guest, #954) [Link]
Two pieces of software that come to mind are:
Apport: https://bugs.launchpad.net/bugs/94130 Bzr: https://bugs.launchpad.net/bugs/586341
Since both of them are Canonical driven projects, they would be two good candidates for receiving (more) behind-a-proxy testing.
Cheers /Johan
Mark Shuttleworth at LinuxTag Posted Jun 18, 2010 7:41 UTC (Fri) by k8to (subscriber, #15413) [Link]
apt-get fails sometimes, but it's more a matter of the debian practice of round-robin access distribution combined with unsynchronized and nonatomic updates of the mirrors in the pool, combined with apt-get's failure to handle this.
However, it does extremely perniciously whine, if HTTP_PROXY is set, as if this was a sin (but doesn't suggest any resolving action).
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 9:01 UTC (Wed) by dgm (subscriber, #49227) [Link]
I use Ubuntu daily in a corporate environment, behind a proxy, and there's only one gripe I would love to get rid off: having to change proxy settings manually each time I get in and out of the firewalled zone. I think this is an issue with NetworkManager, basically. Anything else just works for me.
One of these days I will look if there's a bug about this in Lauchpad and vote for it.
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 11:57 UTC (Wed) by mgedmin (subscriber, #34497) [Link]
I ended up writing a small shell script to enable/disable my proxy config with gconftool:
$ cat /home/mg/bin/proxy-on
$ cat /home/mg/bin/proxy-off
Mark Shuttleworth at LinuxTag Posted Jun 17, 2010 10:57 UTC (Thu) by zzxtty (subscriber, #45175) [Link]
Eek, isn't this what aliases are for?!
Mark Shuttleworth at LinuxTag Posted Jun 17, 2010 13:42 UTC (Thu) by marcH (subscriber, #57642) [Link]
You mean functions?
Mark Shuttleworth at LinuxTag Posted Jun 18, 2010 13:33 UTC (Fri) by zzxtty (subscriber, #45175) [Link]
I'm a tcsh man, not bash, but a quick look at the bash manpages suggests aliases are the correct term in this case. I would use an alias for a single command, functions appear to deal with multiple commands or more complex logic.
These should do the trick (untested):
A 'script'* would have to spawn a new shell to process the command, rather inefficient.
*I can't quite bring myself to call a one liner a script!
Mark Shuttleworth at LinuxTag Posted Jun 19, 2010 16:31 UTC (Sat) by bronson (subscriber, #4806) [Link]
> A 'script'* would have to spawn a new shell to process the command, rather inefficient.
True. In those situations where you want to switch your proxy 300 times per second, this is very important! ;)
Trading some performance for modularity and maintainability is usually a pretty good idea.
Mark Shuttleworth at LinuxTag Posted Jun 21, 2010 6:50 UTC (Mon) by zzxtty (subscriber, #45175) [Link]
"True. In those situations where you want to switch your proxy 300 times per second, this is very important! ;)"
Well you never know... No, from a performance point of view you are quite right. However I have been in the situation where I've been on machines which are constantly running out of process ids and every little helps (eg: echo *). Admittedly I don't see switching your proxy on and off would be a particularly high priority in such a situation!
"Trading some performance for modularity and maintainability is usually a pretty good idea."
You've lost me slightly there, I would have thought having one .cshrc (or .bashrc?) would be more maintainable than a bin directory full of separate files. I guess we all have our preferred ways of working!
Mark Shuttleworth at LinuxTag Posted Jun 25, 2010 10:54 UTC (Fri) by robbe (guest, #16131) [Link]
The PID overrun can also be thwarted by using "exec gconftool..." in the OP's scripts.
My maintainability concern with putting aliases in .bashrc is that only a single shell sees that.
Coming back to performance, the alias solution does incur the (small) per-shell cost of reading, parsing, and keeping in memory the alias, when in most shells you will never need it.
IIRC zsh has one-per-file functions that can reside in a directory somewhere. This is probably the optimal solution here: as maintainable as a shell script, loaded on demand, does not fork a new shell.
Mark Shuttleworth at LinuxTag Posted Jun 28, 2010 20:01 UTC (Mon) by bjartur (guest, #67801) [Link] Similiar to asource then?
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 13:05 UTC (Wed) by jiu (subscriber, #57673) [Link]
I have the same situation with corporate windows. I'm not too fussed about it becausr there's so much more to complain about
Mark Shuttleworth at LinuxTag Posted Jun 16, 2010 14:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you can create a proxy.pac file that will detect your IP address and decide to use a proxy or go direct depending on what your IP is (or anything else that it can detect in javascript)
proxy auto-config Posted Jun 25, 2010 10:47 UTC (Fri) by robbe (guest, #16131) [Link]
Yeah, this works for browsers. Other programs need HTTP, too.
I'd rather not have apt-get's http method evaluate JavaScript code.
Proxy auto-reconfiguration by network Posted Jun 17, 2010 1:31 UTC (Thu) by ewen (subscriber, #4772) [Link]
As dlang pointed out, you can create a procy.pac local file which is a short Javascript program to set the proxy used at request time. It can, amongst other things, check the current IP address you have against a list of subnets and set the proxy appropriately for that subnet. I wrote up how I do this a while ago:
http://ewen.mcneill.gen.nz/blog/entry/2010-02-12-web-prox...
and aside from extending it to support a few more networks it's worked flawlessly for months. (The example given in that page is to auto-use some specific proxies to reach some other networks behind NAT firewalls, but it should be obvious how to just make it depend on source IP so that it auto-changes when you're in a given firewalled network.)
Ewen
|
|||||||||||||