There’s a feature request(Feature #969: Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy) - Smart Proxy - Foreman) out to
make it unnecessary for direct communication between the capsule
provisioned hosts/content-hosts and the main katello/sat6 server. Currently
provisioning templates and subscription-manager requests have to be
fulfilled by the main foreman/katello/sat6 server. The feature request is
to be able to fulfill template and subscription-management requests from
the capsule/smart-proxy.
Here are a few possibilities:
Greg Sutcliffe already has a solution @ https://github.com/theforeman/smart-proxy/pull/100/files for templating.
For fulfilling subscription-manager requests from hosts by the capsule, the
capsule could use a similar approach and take the subscription requests
from the hosts and resubmit the request to the main katello server.
Install a squid-cache(http://www.squid-cache.org/) to the capsule to
proxy all templates/subscription-manager requests from the main
katello/satellite6 server.
Forward certain https requests made on the capsule to the main
forman/katello server.
Use an http server to do a reverse-proxy using apache mod_proxy or nginx
ReverseProxy. Basically same as #2 but with a web server. (I'm partial to
this approach because of familiarity)
Can I have some your opinions on the different approaches or maybe
suggestions for addition approaches?
Do you see any complications or benefits with any of the approaches?
Obviously I'm in favour of #1 since i wrote the initial implementation.
For reference, I considered a requirement of Squid or Apache to be too
heavy for the smart-proxy, which is intended to be run in-situ on
other servers which may already be loaded, or be low-spec boxes (e.g.
my house smart-proxy runs on a Raspberry Pi, which would struggle to
run Apache).
This is doubly true when you consider the fact that no other
Host<->Foreman traffic exists - everything else goes via the
smart-proxy or the puppetmaster. If there were other reasons to use
Squid or Apache, then this could be a justification for the extra cpu
cycles, but there's no such usecase here.
By contrast the proxy is already in place, and is now sufficiently
capable for my original PR to be finished - the core issue was the
ability to transparently handle both http and https traffic (because
we want to be secure by default, but older Anaconda versions and all
Debian installers cannot use https). This is now possible in 1.6. This
should be used in a rework of #1 to complete the goal of the client
retrieving templates from the proxy instead of the core server.
> There’s a feature request(Feature #969: Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy) - Smart Proxy - Foreman) out to
> make it unnecessary for direct communication between the capsule provisioned
> hosts/content-hosts and the main katello/sat6 server. Currently provisioning
> templates and subscription-manager requests have to be fulfilled by the main
> foreman/katello/sat6 server. The feature request is to be able to fulfill
> template and subscription-management requests from the capsule/smart-proxy.
>
> Here are a few possibilities:
>
> 1. Greg Sutcliffe already has a solution @
> https://github.com/theforeman/smart-proxy/pull/100/files for templating. For
> fulfilling subscription-manager requests from hosts by the capsule, the
> capsule could use a similar approach and take the subscription requests from
> the hosts and resubmit the request to the main katello server.
This approach appears to me to have the downside of requiring code
changes to the smart proxy for any communication we want to route
through it.
>
> 2. Install a squid-cache(http://www.squid-cache.org/) to the capsule to
> proxy all templates/subscription-manager requests from the main
> katello/satellite6 server.
> Forward certain https requests made on the capsule to the main
> forman/katello server.
I like this idea the most as a generic answer to routing traffic
through a smart proxy/capsule back to the main server. Greg brought up
the point of keeping the smart proxy lightweight enough for low
resource environments such as a Raspberry Pi. Do we know the typical
resource requirements of Squid? I don't think this would have to be a
required service of the smart proxy.
>
> 3. Use an http server to do a reverse-proxy using apache mod_proxy or nginx
> ReverseProxy. Basically same as #2 but with a web server. (I'm partial to
> this approach because of familiarity)
Currently, we appear to be using the smart proxy in two ways:
A way to manage external services
A remote hub for hosts to retrieve content
The latter being the case where, for subscription manager at least,
we'd want to proxy those calls. If that smart proxy/capsule is also a
Pulp content node then Apache will already exist and may be the better
route.
Eric
···
On Sun, Sep 21, 2014 at 11:37 PM, dustin t wrote:
Can I have some your opinions on the different approaches or maybe
suggestions for addition approaches?
Do you see any complications or benefits with any of the approaches?
> Obviously I'm in favour of #1 since i wrote the initial implementation.
>
> For reference, I considered a requirement of Squid or Apache to be too
> heavy for the smart-proxy, which is intended to be run in-situ on
> other servers which may already be loaded, or be low-spec boxes (e.g.
> my house smart-proxy runs on a Raspberry Pi, which would struggle to
> run Apache).
+1, even for katello's use case the package content should already be on
the smart proxy, no need for a squid cache.
I understand that for foreman the only other aspect that needs proxying
for provisioning is template rendering, but I'm curious why not just
proxy communications in a more generic way? If it were more generic to
allow access to things like /api/v2/ then even hammer could be proxied
as well. Is there anything special about templates that needs its own
logic?
Katello will need to add some sort of api proxy to allow for
subscription-manager usage through the proxy, so I'd like to see it
handled in a generic way as I think that would be cleaner all around.
-Justin
···
On 09/22/2014 04:51 PM, Greg Sutcliffe wrote:
This is doubly true when you consider the fact that no other
Host<->Foreman traffic exists - everything else goes via the
smart-proxy or the puppetmaster. If there were other reasons to use
Squid or Apache, then this could be a justification for the extra cpu
cycles, but there’s no such usecase here.
By contrast the proxy is already in place, and is now sufficiently
capable for my original PR to be finished - the core issue was the
ability to transparently handle both http and https traffic (because
we want to be secure by default, but older Anaconda versions and all
Debian installers cannot use https). This is now possible in 1.6. This
should be used in a rework of #1 to complete the goal of the client
retrieving templates from the proxy instead of the core server.
This use case is related to (2), but it is a means of keeping the
management network distinct from the managed network. I will agree that
it does not seem like we need the caching part of squid. So, if we can
use apache as a reverse proxy with appropriate SSL voodoo that may make
it lighter when installed with other services (such as a pulp node)
– bk
···
On 09/23/2014 08:39 AM, Eric D Helms wrote:
> On Sun, Sep 21, 2014 at 11:37 PM, dustin t wrote:
>> There’s a feature request(http://projects.theforeman.org/issues/969) out to
>> make it unnecessary for direct communication between the capsule provisioned
>> hosts/content-hosts and the main katello/sat6 server. Currently provisioning
>> templates and subscription-manager requests have to be fulfilled by the main
>> foreman/katello/sat6 server. The feature request is to be able to fulfill
>> template and subscription-management requests from the capsule/smart-proxy.
>>
>> Here are a few possibilities:
>>
>> 1. Greg Sutcliffe already has a solution @
>> https://github.com/theforeman/smart-proxy/pull/100/files for templating. For
>> fulfilling subscription-manager requests from hosts by the capsule, the
>> capsule could use a similar approach and take the subscription requests from
>> the hosts and resubmit the request to the main katello server.
>
> This approach appears to me to have the downside of requiring code
> changes to the smart proxy for any communication we want to route
> through it.
>
>>
>> 2. Install a squid-cache(http://www.squid-cache.org/) to the capsule to
>> proxy all templates/subscription-manager requests from the main
>> katello/satellite6 server.
>> Forward certain https requests made on the capsule to the main
>> forman/katello server.
>
> I like this idea the most as a generic answer to routing traffic
> through a smart proxy/capsule back to the main server. Greg brought up
> the point of keeping the smart proxy lightweight enough for low
> resource environments such as a Raspberry Pi. Do we know the typical
> resource requirements of Squid? I don't think this would have to be a
> required service of the smart proxy.
>
>>
>> 3. Use an http server to do a reverse-proxy using apache mod_proxy or nginx
>> ReverseProxy. Basically same as #2 but with a web server. (I'm partial to
>> this approach because of familiarity)
>
> Currently, we appear to be using the smart proxy in two ways:
>
> 1) A way to manage external services
> 2) A remote hub for hosts to retrieve content
>
> The latter being the case where, for subscription manager at least,
> we'd want to proxy those calls. If that smart proxy/capsule is also a
> Pulp content node then Apache will already exist and may be the better
> route.
>> There's a feature request(Feature #969: Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy) - Smart Proxy - Foreman) out to
>> make it unnecessary for direct communication between the capsule provisioned
>> hosts/content-hosts and the main katello/sat6 server. Currently provisioning
>> templates and subscription-manager requests have to be fulfilled by the main
>> foreman/katello/sat6 server. The feature request is to be able to fulfill
>> template and subscription-management requests from the capsule/smart-proxy.
>>
>> Here are a few possibilities:
>>
>> 1. Greg Sutcliffe already has a solution @
>> https://github.com/theforeman/smart-proxy/pull/100/files for templating. For
>> fulfilling subscription-manager requests from hosts by the capsule, the
>> capsule could use a similar approach and take the subscription requests from
>> the hosts and resubmit the request to the main katello server.
>
> This approach appears to me to have the downside of requiring code
> changes to the smart proxy for any communication we want to route
> through it.
We can use proxy plugins to achieve this - the existing proxy code is
likely to be packaged separately in the near future anyway (who wants
to install puppet on a DNS only proxy?)
>> 2. Install a squid-cache(http://www.squid-cache.org/) to the capsule to
>> proxy all templates/subscription-manager requests from the main
>> katello/satellite6 server.
>> Forward certain https requests made on the capsule to the main
>> forman/katello server.
>
> I like this idea the most as a generic answer to routing traffic
> through a smart proxy/capsule back to the main server. Greg brought up
> the point of keeping the smart proxy lightweight enough for low
> resource environments such as a Raspberry Pi. Do we know the typical
> resource requirements of Squid? I don't think this would have to be a
> required service of the smart proxy.
Agreed, its not required - also a +1 for encapsulating any new
functionality in a proxy plugin. Dependencies can then be expressed on
the plugin package. This could also be said for usecases involving
Apache.
In all, I think we want to code new features as proxy plugins, which
gives us considerably more flexibility in defining the requirements of
a plugin rather than the requirements of the proxy as a whole. Users
wishing to do, say, DHCP & DNS only on a lightweight box would then be
unaffected.
Greg
···
On 23 September 2014 13:39, Eric D Helms wrote:
> On Sun, Sep 21, 2014 at 11:37 PM, dustin t wrote:
> >> There's a feature request(Feature #969: Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy) - Smart Proxy - Foreman)
> out to
> >> make it unnecessary for direct communication between the capsule
> provisioned
> >> hosts/content-hosts and the main katello/sat6 server. Currently
> provisioning
> >> templates and subscription-manager requests have to be fulfilled by the
> main
> >> foreman/katello/sat6 server. The feature request is to be able to
> fulfill
> >> template and subscription-management requests from the
> capsule/smart-proxy.
> >>
> >> Here are a few possibilities:
> >>
> >> 1. Greg Sutcliffe already has a solution @
> >> https://github.com/theforeman/smart-proxy/pull/100/files for
> templating. For
> >> fulfilling subscription-manager requests from hosts by the capsule, the
> >> capsule could use a similar approach and take the subscription requests
> from
> >> the hosts and resubmit the request to the main katello server.
> >
> > This approach appears to me to have the downside of requiring code
> > changes to the smart proxy for any communication we want to route
> > through it.
>
We can use proxy plugins to achieve this - the existing proxy code is
> likely to be packaged separately in the near future anyway (who wants
> to install puppet on a DNS only proxy?)
>
> >> 2. Install a squid-cache(http://www.squid-cache.org/) to the capsule to
> >> proxy all templates/subscription-manager requests from the main
> >> katello/satellite6 server.
> >> Forward certain https requests made on the capsule to the main
> >> forman/katello server.
> >
> > I like this idea the most as a generic answer to routing traffic
> > through a smart proxy/capsule back to the main server. Greg brought up
> > the point of keeping the smart proxy lightweight enough for low
> > resource environments such as a Raspberry Pi. Do we know the typical
> > resource requirements of Squid? I don't think this would have to be a
> > required service of the smart proxy.
>
> I did a few tests with squid with caching disabled. With 5 connection open
simultaneously, RSS was around 16 kb. I also found a few blog posts about
installing squid with normal caching on raspberry pi as a parental control
feature. It seems lightweight enough to be used on Raspberry Pi.
> Agreed, its not required - also a +1 for encapsulating any new
> functionality in a proxy plugin. Dependencies can then be expressed on
> the plugin package. This could also be said for usecases involving
> Apache.
>
> In all, I think we want to code new features as proxy plugins, which
> gives us considerably more flexibility in defining the requirements of
> a plugin rather than the requirements of the proxy as a whole. Users
> wishing to do, say, DHCP & DNS only on a lightweight box would then be
> unaffected.
>
Agreed, users should have the ability to have this feature optionally
installed. If we go squid-proxy or httpd route though, would this feature
be enabled through capsule/forman/katello-installer?
···
> On Tue, Sep 23, 2014 at 7:08 AM, Greg Sutcliffe wrote:
> On 23 September 2014 13:39, Eric D Helms wrote:
> > On Sun, Sep 21, 2014 at 11:37 PM, dustin t > wrote:
>>> There's a feature request(Feature #969: Direct Client->Foreman communication shouldn't be needed (and moved to the Proxy) - Smart Proxy - Foreman) out to
>>> make it unnecessary for direct communication between the capsule provisioned
>>> hosts/content-hosts and the main katello/sat6 server. Currently provisioning
>>> templates and subscription-manager requests have to be fulfilled by the main
>>> foreman/katello/sat6 server. The feature request is to be able to fulfill
>>> template and subscription-management requests from the capsule/smart-proxy.
>>>
>>> Here are a few possibilities:
>>>
>>> 1. Greg Sutcliffe already has a solution @
>>> https://github.com/theforeman/smart-proxy/pull/100/files for templating. For
>>> fulfilling subscription-manager requests from hosts by the capsule, the
>>> capsule could use a similar approach and take the subscription requests from
>>> the hosts and resubmit the request to the main katello server.
>> This approach appears to me to have the downside of requiring code
>> changes to the smart proxy for any communication we want to route
>> through it.
> We can use proxy plugins to achieve this - the existing proxy code is
> likely to be packaged separately in the near future anyway (who wants
> to install puppet on a DNS only proxy?)
>
>>> 2. Install a squid-cache(http://www.squid-cache.org/) to the capsule to
>>> proxy all templates/subscription-manager requests from the main
>>> katello/satellite6 server.
>>> Forward certain https requests made on the capsule to the main
>>> forman/katello server.
>> I like this idea the most as a generic answer to routing traffic
>> through a smart proxy/capsule back to the main server. Greg brought up
>> the point of keeping the smart proxy lightweight enough for low
>> resource environments such as a Raspberry Pi. Do we know the typical
>> resource requirements of Squid? I don't think this would have to be a
>> required service of the smart proxy.
> Agreed, its not required - also a +1 for encapsulating any new
> functionality in a proxy plugin. Dependencies can then be expressed on
> the plugin package. This could also be said for usecases involving
> Apache.
So one issue I can see using a smart proxy plugin for various proxying
is performance. I don't believe that the smart proxy could or should be
able to handle the load that apache or squid could.
For something like provisioning templates its likely not to be an
issue. However if katello is going to be proxying all client
communication through the smart proxy, I don't know that it would scale
as well (at least not without more advanced deployment options).
-Justin
···
On 09/23/2014 10:08 AM, Greg Sutcliffe wrote:
> On 23 September 2014 13:39, Eric D Helms wrote:
>> On Sun, Sep 21, 2014 at 11:37 PM, dustin t wrote:
In all, I think we want to code new features as proxy plugins, which
gives us considerably more flexibility in defining the requirements of
a plugin rather than the requirements of the proxy as a whole. Users
wishing to do, say, DHCP & DNS only on a lightweight box would then be
unaffected.
proxy all templates/subscription-manager requests from the main
katello/satellite6 server.
Forward certain https requests made on the capsule to the main
forman/katello server.
I like this idea the most as a generic answer to routing traffic
through a smart proxy/capsule back to the main server. Greg brought up
the point of keeping the smart proxy lightweight enough for low
resource environments such as a Raspberry Pi. Do we know the typical
resource requirements of Squid? I don’t think this would have to be a
required service of the smart proxy.
I did a few tests with squid with caching disabled. With 5 connection
open simultaneously, RSS was around 16 kb. I also found a few blog posts
about installing squid with normal caching on raspberry pi as a parental
control feature. It seems lightweight enough to be used on Raspberry Pi.
Agreed, its not required - also a +1 for encapsulating any new
functionality in a proxy plugin. Dependencies can then be expressed on
the plugin package. This could also be said for usecases involving
Apache.
In all, I think we want to code new features as proxy plugins, which
gives us considerably more flexibility in defining the requirements of
a plugin rather than the requirements of the proxy as a whole. Users
wishing to do, say, DHCP & DNS only on a lightweight box would then be
unaffected.
Agreed, users should have the ability to have this feature optionally
installed. If we go squid-proxy or httpd route though, would this feature
be enabled through capsule/forman/katello-installer?
Can it be a proxy plugin which is installed and enabled, or not, optionally?
– k
···
On 09/23/2014 06:44 PM, dustin tsang wrote:
>
> Agreed, users should have the ability to have this feature optionally
> installed. If we go squid-proxy or httpd route though, would this
> feature be enabled through capsule/forman/katello-installer?
>
>
I don't see why not, we can rely on the installer to pull down the
packages and configure them if the feature is turned on. We do this
already for the Pulp Node.
Mike
···
On 09/23/2014 03:54 PM, Bryan Kearney wrote:
>
>
> On 09/23/2014 06:44 PM, dustin tsang wrote:
>>
>> Agreed, users should have the ability to have this feature optionally
>> installed. If we go squid-proxy or httpd route though, would this
>> feature be enabled through capsule/forman/katello-installer?
>>
>>
> Can it be a proxy plugin which is installed and enabled, or not,
> optionally?
>
> -- k
>
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
Mine won't. It's already running bind, isc-dhcp, tftp-hpa, puppet
agent (on cron, but still…), and the smart-proxy itself. It can
barely run the package manager when I want to do updates. No way I'm
getting Apache in there. Squid might fit, but I'm still in favour of
keeping it in the proxy, since I know that's already running
···
On 23 September 2014 23:47, Aaron Stone wrote:
> I used to run Apache 1.2 and Squid 2.0 on a 33 MHz 486. I'm pretty sure an
> RPi can handle the same :)
I'm actually having difficulty getting the reverse proxy to work with the
subscription-manager cli. Katello fails to authenticate some of the subman
requests due to the candlepin cert not being forwarded through the proxy. I
believe this is a limitation with how reverse proxies work.
Subscription manager also allows configuration with a http proxy. However
older versions of subscription manager may not support this.
Does anyone who know if it is possible to setup squid in reverse proxy mode
to forward requester certs?
Dustin
···
On Tuesday, September 23, 2014 7:48:43 PM UTC-7, Mike McCune wrote:
>
> On 09/23/2014 03:54 PM, Bryan Kearney wrote:
> >
> >
> > On 09/23/2014 06:44 PM, dustin tsang wrote:
> >>
> >> Agreed, users should have the ability to have this feature optionally
> >> installed. If we go squid-proxy or httpd route though, would this
> >> feature be enabled through capsule/forman/katello-installer?
> >>
> >>
> > Can it be a proxy plugin which is installed and enabled, or not,
> > optionally?
> >
> > -- k
> >
>
> I don't see why not, we can rely on the installer to pull down the
> packages and configure them if the feature is turned on. We do this
> already for the Pulp Node.
>
> Mike
> --
> Mike McCune
> mmccune AT redhat.com
> Red Hat Engineering | Portland, OR
> Systems Management | 650-254-4248
>
I used to run Apache 1.2 and Squid 2.0 on a 33 MHz 486. I’m pretty sure
an
RPi can handle the same
Mine won’t. It’s already running bind, isc-dhcp, tftp-hpa, puppet
agent (on cron, but still…), and the smart-proxy itself. It can
barely run the package manager when I want to do updates. No way I’m
getting Apache in there. Squid might fit, but I’m still in favour of
keeping it in the proxy, since I know that’s already running
>
>
>
> >
> >
> >>
> >> Agreed, users should have the ability to have this feature
> optionally
> >> installed. If we go squid-proxy or httpd route though, would this
> >> feature be enabled through capsule/forman/katello-installer?
> >>
> >>
> > Can it be a proxy plugin which is installed and enabled, or not,
> > optionally?
> >
> > – k
> >
>
> I don't see why not, we can rely on the installer to pull down the
> packages and configure them if the feature is turned on. We do this
> already for the Pulp Node.
>
> Mike
> –
> Mike McCune
> mmccune AT redhat.com <http://redhat.com>
> Red Hat Engineering | Portland, OR
> Systems Management | 650-254-4248
>
>
>
> I'm actually having difficulty getting the reverse proxy to work with
> the subscription-manager cli. Katello fails to authenticate some of
> the subman requests due to the candlepin cert not being forwarded
> through the proxy. I believe this is a limitation with how reverse
> proxies work.
What config did you try?
We actually do something similar on our dev setup with apache, or order
to allow sub-man registration to the dev server on port 3000. It
forwards to a non-ssl'd port:
···
On Thu, Sep 25, 2014 at 8:41 AM, Justin Sherrill wrote:
> On 09/25/2014 01:57 AM, dustin t wrote:
>
>
>
> On Tuesday, September 23, 2014 7:48:43 PM UTC-7, Mike McCune wrote:
>>
>> On 09/23/2014 03:54 PM, Bryan Kearney wrote:
>> >
>> >
>> > On 09/23/2014 06:44 PM, dustin tsang wrote:
>> >>
>> >> Agreed, users should have the ability to have this feature optionally
>> >> installed. If we go squid-proxy or httpd route though, would this
>> >> feature be enabled through capsule/forman/katello-installer?
>> >>
>> >>
>> > Can it be a proxy plugin which is installed and enabled, or not,
>> > optionally?
>> >
>> > -- k
>> >
>>
>> I don't see why not, we can rely on the installer to pull down the
>> packages and configure them if the feature is turned on. We do this
>> already for the Pulp Node.
>>
>> Mike
>> --
>> Mike McCune
>> mmccune AT redhat.com
>> Red Hat Engineering | Portland, OR
>> Systems Management | 650-254-4248
>
>
>
> I'm actually having difficulty getting the reverse proxy to work with the
> subscription-manager cli. Katello fails to authenticate some of the subman
> requests due to the candlepin cert not being forwarded through the proxy. I
> believe this is a limitation with how reverse proxies work.
>
>
> What config did you try?
>
> We actually do something similar on our dev setup with apache, or order to
> allow sub-man registration to the dev server on port 3000. It forwards to a
> non-ssl'd port:
>
> ProxyPass /pulp !
> ProxyPass / http://localhost:3000/
> ProxyPassReverse / http://localhost:3000
> ProxyPreserveHost on
> RequestHeader set X_FORWARDED_PROTO 'https'
>
> I assume something similar would work for this, I'm just not sure if you'd
> need something additional to forward to an SSL'd url.
>
> -Justin
>
>
>
> Subscription manager also allows configuration with a http proxy. However
> older versions of subscription manager may not support this.
>
> Does anyone who know if it is possible to setup squid in reverse proxy mode
> to forward requester certs?
>
> - Dustin
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> We also include setting of the request header to pass the certificate
> into Rails which may or may not need to be done within the proxy
> itself.
>
> <LocationMatch /rhsm|/subscription|/katello/api>
> RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
> SSLVerifyClient optional
> SSLRenegBufferSize 16777216
> SSLVerifyDepth 2
> # report to CLI and RHSM nicely when Katello is down
> ErrorDocument 500 '{"displayMessage": "Internal error, contact
> administrator", "errors": ["Internal error, contact administrator"],
> "status": "500" }'
> ErrorDocument 503 '{"displayMessage": "Service unavailable or
> restarting, try later", "errors": ["Service unavailable or restarting,
> try later"], "status": "503" }'
> </LocationMatch>
>
> Eric
>
I think the apache directive RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
is probably what I need on the squid side. I'll look around for an
equivalent directive.
Dustin
···
On Thursday, September 25, 2014 5:50:36 AM UTC-7, Eric Helms wrote:
On Thu, Sep 25, 2014 at 8:41 AM, Justin Sherrill <jshe...@redhat.com > <javascript:>> wrote:
On 09/25/2014 01:57 AM, dustin t wrote:
On Tuesday, September 23, 2014 7:48:43 PM UTC-7, Mike McCune wrote:
On 09/23/2014 03:54 PM, Bryan Kearney wrote:
On 09/23/2014 06:44 PM, dustin tsang wrote:
Agreed, users should have the ability to have this feature
optionally
installed. If we go squid-proxy or httpd route though, would this
feature be enabled through capsule/forman/katello-installer?
Can it be a proxy plugin which is installed and enabled, or not,
optionally?
– k
I don’t see why not, we can rely on the installer to pull down the
packages and configure them if the feature is turned on. We do this
already for the Pulp Node.
Mike
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
I’m actually having difficulty getting the reverse proxy to work with
the
subscription-manager cli. Katello fails to authenticate some of the
subman
requests due to the candlepin cert not being forwarded through the
proxy. I
believe this is a limitation with how reverse proxies work.
What config did you try?
We actually do something similar on our dev setup with apache, or order
to
allow sub-man registration to the dev server on port 3000. It forwards
to a
non-ssl’d port:
I assume something similar would work for this, I’m just not sure if
you’d
need something additional to forward to an SSL’d url.
-Justin
Subscription manager also allows configuration with a http proxy.
However
older versions of subscription manager may not support this.
Does anyone who know if it is possible to setup squid in reverse proxy
mode
to forward requester certs?
Dustin
–
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...@googlegroups.com <javascript:>.
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout.
