[foreman-dev] [RFC] HTTP proxy for requests

[Sebastian Gräßl]

Hej,

at the moment there is a PR[1] open on foreman-docker to set a HTTP proxy 
for requests to registries.
The PR allows to set a HTTP proxy on the HTTP client, in this case deep 
down Excon, only for registry requests.

A HTTP proxy won't be set on requests if a `HTTP_PROXY` environment 
variable is available, since it is an unlikely setup to have registry 
request routed over a different proxy than other requests. However setting 
it via the environment variable will allow requests to succeed to resources 
available by the HTTP proxy, but will fail for those inside and possible 
blocked.

The `HTTP_PROXY` environment variable seems to be a standard, and therefore 
Excon is built to use it when available. 
Excon is used by docker-api as well as fog, it might be used by other 
components and there might be other parts that use another HTTP client like 
RestClient, which also respects the variable.

This means at the moment with that environment variable set some requests 
would already rely on it.
In any case this should be in mentioned in the manual to be aware of, also 
because some operating systems set this globally.

The question is should we make an afford to ensure deployment behind a HTTP 
proxy on a system with HTTP blocked works without issues and provide a way 
to configure it properly?

I've tested Foreman with HTTP blocked and `HTTP_PROXY` set, but in a very 
basic setup, with the only external requests being to Docker registries 
outside and squid configured to just pass requests through regardless there 
to.

It didn't show any apparent issue, but there are for sure issues with a 
more robust configured HTTP proxy. 
This raises another question: How common is a setup where external 
resources requiring HTTP are used with Foreman behind a HTTP proxy?

Comments?

All the best,
Sebastian

[1] https://github.com/theforeman/foreman-docker/pull/189

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] omnibus packaging

[Marek Hulán]

Hello

while it would made the packaging easier I don't think it's a very good 
approach. If there's some security issue found in one of deps, we'd need to 
build new version of the whole stack because of that. Btw on rpm based systems 
we use isolated ruby through software collection so it should not interfere 
with your system ruby. I wonder how you install newer system ruby on your 
system, if you use tools like rvm/rbenv it's usually explicitly activated only 
in user shell.

--
Marek

On čtvrtek 20. dubna 2017 0:22:24 CEST jake.plimack via foreman-dev wrote:
> would it be possible to move towards using omnibus packing for theforeman?
> i would love it if TF was self-contained with its own ruby and gems in
> /opt/foreman much like chef/sensu/etc do.
> 
> i have newer system-ruby on my machines than theforeman requires, so
> self-containing all the deps seems like a win-win-win-win as it'll make the
> installer platform agnostic and decouple the dependencies from everything
> else on the system.
> 
> https://github.com/chef/omnibus


-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Foreman AMA - today, 3pm UK time

[Greg Sutcliffe]

Hi all,

Since all our developers are

*busy having cocktails^W^W^W
*sleeping off an Easter Chocolate coma^W^W^W^W^W
*really really busy with 1.15 testing :P

I've decided to change today's community demo to an Ask Me Anything.
I'll chair it, and I'll try to get some other notable people on the
show too.

Feel free to ask questions here in advance (or mail me direct if you
desire anonymity), or you can tune in live to ask during the show (on
IRC / YouTube chat)

https://www.youtube.com/watch?v=0sl4HgMzgio

See you at 3pm!
Greg
-- 
IRC / Twitter: @gwmngilfen
Diaspora: gwmngil...@joindiaspora.com

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] omnibus packaging

[Michael Moll]

Hi,

On Wed, Apr 19, 2017 at 03:22:24PM -0700, jake.plimack via foreman-dev wrote:
> would it be possible to move towards using omnibus packing for theforeman?

I'm strongly against this for a broad variety of reasons. I think the
whole omnibus approach is very wrong and Puppet's move to AIO packaging
was/is also a major downer for me.

Regards
-- 
Michael Moll

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [RFC] HTTP proxy for requests

[Tom McKay]

As a dev I am curious how this is handled in our code. Does every usage of
RestClient need to know about the existence of a proxy? Are there multiple
proxies for different aspects (eg. https://cdn.redhat.com vs.
https://myinternalserver.example.com)?

On Thu, Apr 20, 2017 at 8:43 AM, Timo Goebel  wrote:

> Hi,
>
> Am 20.04.17 um 13:06 schrieb Sebastian Gräßl:
>
>> How common is a setup where external resources requiring HTTP are used
>> with Foreman behind a HTTP proxy?
>>
>> I believe, this is very common in enterprise environments. Usually any
> internet access is blocked for security reasons and only connections via a
> proxy server are allowed. The proxy ususally does a MITM attack to be able
> to investigate encrypted traffic. While this does make sense in some cases,
> don't get me started why it does not make any sense in others.
>
> Comments?
>>
>
> I think especially access to all the docker registries out there is
> something a corporate it-security team would want to go through a proxy
> server. Setting a proxy server on a server via environment variables
> (http_proxy) is quite easy with systemd unit files. However that may lead
> to problems when the client doesn't respect the 'no_proxy' environment
> variable and suddenly all requests to a smart proxy are routed via the http
> proxy. This is problematic when smart-proxy is on the same network and not
> reachable via the proxy server.
> I personally prefer only to have an explicit option in a settings file.
>
> - Timo
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] omnibus packaging

[jake.plimack via foreman-dev]

would it be possible to move towards using omnibus packing for theforeman?
i would love it if TF was self-contained with its own ruby and gems in 
/opt/foreman much like chef/sensu/etc do.

i have newer system-ruby on my machines than theforeman requires, so 
self-containing all the deps seems like a win-win-win-win as it'll make the 
installer platform agnostic and decouple the dependencies from everything 
else on the system.

https://github.com/chef/omnibus

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.