The Cambridge LAVA Lab has a transparent squid proxy which saves having to configure each dispatcher and device to use it. Outgoing HTTP traffic from the lab has no choice as it is intercepted at the internet gateway.
We did this because even after configuring the dispatcher, and devices, it's almost impossible to make all test shell tasks use the proxy. LAVA sets a shell environment inside a job but many of the clients in the various different types of job simply ignore it. Chasing every test writer was not feasible as the lab usage is so large, but might be ok in a smaller lab with tighter control of the jobs.
We don't proxy HTTPS requests because that's becomes very complicated with faking certificates etc
Marc Titinger <mtitinger at baylibre.com> writes:
I had to make this change to get squid3 going with our LAVA 1.0 machine. I thought this could be useful. I did not test extensively though.
FWIW, I had problems getting lava-dispatcher to use my local squid proxy also. Seems setting LAVA_PROXY in lava-dispatcher.conf was working for the the devices (lava set the environment variable after booting the target), but lava-dispatcher itself was not using the proxy.
I'll give this a try as well.
Kevin
On 14/04/2016 12:20, Matt Hart wrote:
The Cambridge LAVA Lab has a transparent squid proxy which saves having to configure each dispatcher and device to use it. Outgoing HTTP traffic from the lab has no choice as it is intercepted at the internet gateway.
We did this because even after configuring the dispatcher, and devices, it's almost impossible to make all test shell tasks use the proxy. LAVA sets a shell environment inside a job but many of the clients in the various different types of job simply ignore it. Chasing every test writer was not feasible as the lab usage is so large, but might be ok in a smaller lab with tighter control of the jobs.
Hi Matt,
makes sense, thanks for sharing. I guess we'll do the same eventually.
BR, Marc
We don't proxy HTTPS requests because that's becomes very complicated with faking certificates etc
Marc Titinger <mtitinger at baylibre.com> writes:
I had to make this change to get squid3 going with our LAVA 1.0 machine. I thought this could be useful. I did not test extensively though.
FWIW, I had problems getting lava-dispatcher to use my local squid proxy also. Seems setting LAVA_PROXY in lava-dispatcher.conf was working for the the devices (lava set the environment variable after booting the target), but lava-dispatcher itself was not using the proxy.
I'll give this a try as well.
Kevin
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Matt Hart matthew.hart@linaro.org writes:
The Cambridge LAVA Lab has a transparent squid proxy which saves having to configure each dispatcher and device to use it. Outgoing HTTP traffic from the lab has no choice as it is intercepted at the internet gateway.
We did this because even after configuring the dispatcher, and devices, it's almost impossible to make all test shell tasks use the proxy. LAVA sets a shell environment inside a job but many of the clients in the various different types of job simply ignore it.
In kernel CI, the downloads required to get a job started (kernel, dtb, ramdisk etc.) often take longer than running the job itself, so I primarily want the dispatcher downloads to go through a proxy.
I' don't care if the targets and tests themselves go throught the proxy, so fixing LAVA to use the proxy from the environment is still useful, IMO.
Kevin
Oh agreed, was just saying how/why the lab does it transparently
On 14 April 2016 at 18:01, Kevin Hilman khilman@baylibre.com wrote:
Matt Hart matthew.hart@linaro.org writes:
The Cambridge LAVA Lab has a transparent squid proxy which saves having to configure each dispatcher and device to use it. Outgoing HTTP traffic from the lab has no choice as it is intercepted at the internet gateway.
We did this because even after configuring the dispatcher, and devices, it's almost impossible to make all test shell tasks use the proxy. LAVA sets a shell environment inside a job but many of the clients in the various different types of job simply ignore it.
In kernel CI, the downloads required to get a job started (kernel, dtb, ramdisk etc.) often take longer than running the job itself, so I primarily want the dispatcher downloads to go through a proxy.
I' don't care if the targets and tests themselves go throught the proxy, so fixing LAVA to use the proxy from the environment is still useful, IMO.
Kevin
-
Kevin Hilman -
Marc Titinger -
Matt Hart