Red Hat Bugzilla – Bug 1132980
[RFE] Support bypassing proxy for some repository URLs
Last modified: 2018-09-19 11:05:02 EDT
As a user, I would like to be able to synchronize locally hosted yum repositories without going through the configured proxy. Possibly by accepting a proxy PAC, or some other list of excluded IP ranges.
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
It seems you can specify the proxy at the time of repo creation instead of yum_importer.json. If we did that, then the user could have a check box to turn off the proxy http://pulp-rpm-user-guide.readthedocs.org/en/latest/recipes.html#configure-proxy
*** Bug 1173335 has been marked as a duplicate of this bug. ***
*** Bug 1190197 has been marked as a duplicate of this bug. ***
This would effectively provide "Per Repo" proxy settings. We definitely need this feature in my organization. I'm facing the exact same issue. Currently, with proxy set up, the Red Hat repos sync correctly but internal ones bomb out. If I unset the proxy, Local repos are fine but Red Hat repos bomb out. The only other option available at the moment that I'm aware of is using cntlm to as the proxy on the local host. In CNTLM you can list URLs to not proxy. This solution is a band aid for us though because I need to use personal credentials to authenticate cntlm into the proxy for the red hat connectivity. (In reply to Stephen Benjamin from comment #3) > It seems you can specify the proxy at the time of repo creation instead of > yum_importer.json. If we did that, then the user could have a check box to > turn off the proxy > http://pulp-rpm-user-guide.readthedocs.org/en/latest/recipes.html#configure- > proxy
*** Bug 1262966 has been marked as a duplicate of this bug. ***
The Pulp upstream bug status is at NEW. Updating the external tracker on this bug.
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.
Created attachment 1095074 [details] Description of workaround for proxy issue using Squid Cleaned-up version of description how to install Squid in order to workaround the fact that certain corporate proxies don't redirect internal requests and that Satellite can only support one proxy address.
Thanks Eric, cntlm can be used similarly for working around this, especially helpful if you need to log in to the outbound proxy. That said, I hope neither of these are designated as a long term solution because adding another component (effectively a proxy for a proxy) to configure and maintain is more crap to go wrong.
Moving 6.2 bugs out to sat-backlog.
Created redmine issue http://projects.theforeman.org/issues/17425 from this bug
The /etc/squid/squid.conf file is Puppet-managed on a Satellite 6.2 system. This needs a new workaround. RH support told me to "set up a new machine" to install Squid on, which, is just stupid.
Changing component so Katello can take the next steps.
If this needs to be resolved soon, I suggest disassociating the Pulp redmine tracker. That level of new feature would not likely be doable until Pulp 3, and even then it would require substantial changes to how Katello interacts with Pulp's download settings.
(In reply to Michael Hrivnak from comment #57) > If this needs to be resolved soon, I suggest disassociating the Pulp redmine > tracker. That level of new feature would not likely be doable until Pulp 3, > and even then it would require substantial changes to how Katello interacts > with Pulp's download settings. Implementing it, will alter the constant necessity to install customized SQUIDs in secure corporate environments. Working on a similar case right now and this would have untied our hands. Humble opinion. Needs to be implemented asap like now. Placing myself in CC to provide feedback as needed.
*** Bug 1444999 has been marked as a duplicate of this bug. ***
I'm removing the Pulp issue, since we're not planning to pursue that option as part of any near-term resolution. We will however pursue that for Pulp 3.
Michale, since the solution would still be possibly pursued as part of a Pulp release, shouldn't we still keep the component?
Pulp will try to make it easier to do this in the future, but there is no reason to block this issue on any Pulp work. Usually if a Pulp issue is associated via an external tracker, that means it blocks the BZ, so I think in this case we should leave it off.
Connecting redmine issue http://projects.theforeman.org/issues/21706 from this bug
Moving to POST, since the PR associated with http://projects.theforeman.org/issues/21706 is merged.
After some discussion with roman, I can now reproduce. Here's the summary: * The presence of this change seems to cause an issue when updating a repository in pulp if and only if Basic auth credentials are set (upstream username, upstream password) * You do not even have to update the 'ignore proxy' setting, even updating the url will cause the error. * I believe this is fixed upstream in https://github.com/pulp/pulp/commit/80c7b96afbf80937e0406b3c22857169aafe5b46 Steps to reproduce: 1. satellite-installer --katello-proxy-url=http://foo.com --katello-proxy-username=bar --katello-proxy-password=foo --disable-system-checks --katello-proxy-port=1234 2. Create a repository, set: Name: anything Type: yum Upstream Url: Any url Upstream Username: admin Upstream password: password Leave everything else as the default 3. tail /var/log/messages grepping for 'basic_auth_password' 4. Attempt to change the upstream url to any other valid url notice the error: Task pulp.server.managers.repo.importer.update_importer_config[15422909-7fcd-4926-81ca-b7b22ed629d9] raised unexpected: OperationError(u"Could not save document (Cannot update 'config.basic_auth_password' and 'config' at the same time)",) If you revert the change this bz introduced, the problem seems to go away.
I did confirm that https://pulp.plan.io/issues/3210 (https://github.com/pulp/pulp/commit/80c7b96afbf80937e0406b3c22857169aafe5b46.patch) appears to resolve the issue.
Split the inability to update the option from hammer into a 2nd bug: https://bugzilla.redhat.com/show_bug.cgi?id=1544542
Since the current failure appears to be solved by a fix in pulp, updating the component to pulp and associating the upstream issue.
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.
Requesting needsinfo from upstream developer ttereshc@redhat.com because the 'FailedQA' flag is set.
Pulp part is fixed upstream. I'm removing FailedQA flag and moving BZ to POST.
*** Bug 1526578 has been marked as a duplicate of this bug. ***
VERIFIED on sat6.3.1-1 - even the authed repos now respect the flag and work properly.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1126
This is the shizzle