[xen-tools-dev] apt-proxy setting (was Bug#610457...)

[Alex Tomlins]

On 31/03/11 15:00, Axel Beckert wrote:
> Hi Alex,
>
> Alex Tomlins wrote:
>>>> I've implemented this here:
>>>> https://gitorious.org/~alext/xen-tools/alext-xen-tools/commits/apt_proxy
>>> Thanks!
>>>
>>>   From a first glance it looks good and I'll probably include your
>>> patches. I'd though change two things:
>>>
>>> * Change the option's name from apt_proxy to apt-proxy.
>> Makes sense.  I wasn't sure which way to go as the existing options seem
>> to use a mixture.
> Well, yeah, historically grown. But I'd prefer to not have underscores
> in long options. Maybe we'll once change all of them to dashes, but
> supoort underscores for backwards-compatibility.
>
>>> * Instead of prepending the environment variable to some command, I'd
>>>     prefer to use $ENV{http_proxy}, etc.
>> I was mostly being cautious there to make sure it didn't effect anything
>> else (as the proxy is typically an apt-cacher type proxy, and not a
>> general http proxy).
> Yeah, and for using $ENV{http_proxy} the opposite was the reason. I
> thought it would be good if then anything uses the proxy in general.
>
> But maybe it would be also good to distinguish between
>
> 1) proxy setting for the installation (which happens on the Dom0)
> 2) proxy setting for the DomU (after installation)
> 3) all other things (if there are any)
>
In my use case, the apt_proxy would be an apt-cacher-ng installation 
(e.g. http://apt-cache:3142), which only supports accessing apt 
repositories, and doesn't work as a general http proxy.  I combine this 
with setting cache=no in xen-tools.conf to avoid duplicating the caching 
of .debs.

Before I'd gone down this route i'd been setting the http_proxy before 
calling xen-create-image, and this mostly worked, but I found some of my 
role scripts were breaking when trying to install ruby gems for example.

so for the above 1 and 2 would use an apt proxy/cache (but could also 
use a standard proxy)
3 (e.g. stuff in role scripts) would have to be a generic http proxy.

It would be good if debootstrap had an option to specify a proxy, but I 
couldn't see one, so I went for using the http_proxy env variable.
>> Having had a closer look, I can't see it effecting
>> anything else, so I'll push that change up as well
> Your arguments made think a little bit more about this issue. Not sure
> though, what's the best way to handle it.
>
> 		Regards, Axel
Maybe a solution would be to set the http_proxy ENV variable before the 
call to debootstrap, and then restore the original value (if_any) 
afterwards.

This would mean that cases 1 and 2 would use the apt-proxy setting, and 
case 3 would the Dom0's http_proxy ENV variable.

thanks,
Alex

P.S. I've stopped copying the bug report as this is getting somewhat 
off-topic.

-- 
Alex Tomlins 	
Unboxed
Consulting

E: 	alex.tomlins at unboxedconsulting.com 
<mailto:alex.tomlins at unboxedconsulting.com>
M: 	+44 7824 696 890
T: 	+44 20 3137 2930
F: 	+44 20 7183 4251

	
17 Blossom Street
London, E1 6PL
United Kingdom
www.unboxedconsulting.com <http://www.unboxedconsulting.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://xen-tools.org/pipermail/xen-tools-dev/attachments/20110331/2a91bff1/attachment.htm>