Bug 1332395

Summary: Unable to sync Atomic Host Tree via proxy
Product: Red Hat Satellite Reporter: jnikolak
Component: InstallationAssignee: Partha Aji <paji>
Status: CLOSED DUPLICATE QA Contact: Sachin Ghai <sghai>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: bbuckingham, cpatters, cwelton, ggatward, stbenjam
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-08 20:40:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1321771    

Description jnikolak 2016-05-03 06:27:59 UTC
What problem/issue/behavior are you having trouble with?  What do you expect to see?

Attempts to sync the Red Hat Enterprise Linux Atomic Host Trees (OSTree) product fail due to unreachable host.
On investigation, the Satellite server is attempting to connect directly to the upstream source rather than use the configured http proxy.  Direct connections in our customer environment are denied - we MUST use the proxy.
RPM repo content mirroring is working correctly via the proxy.

root@sat62[~] # tcpdump -i eth0 -nn '( port 443 && ! host workstation1.example.org )'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:29:03.657432 IP 192.168.1.1.37341 > 173.223.172.251.443: Flags [S], seq 2436475307, win 29200, options [mss 1460,sackOK,TS val 66920754 ecr 0,nop,wscale 7], length 0
09:29:03.665083 IP 192.168.1.1.37342 > 173.223.172.251.443: Flags [S], seq 2641366363, win 29200, options [mss 1460,sackOK,TS val 66920762 ecr 0,nop,wscale 7], length 0
09:29:04.666625 IP 192.168.1.1.37342 > 173.223.172.251.443: Flags [S], seq 2641366363, win 29200, options [mss 1460,sackOK,TS val 66921764 ecr 0,nop,wscale 7], length 0

root@sat62[~] # host 173.223.172.251
251.172.223.173.in-addr.arpa domain name pointer a173-223-172-251.deploy.static.akamaitechnologies.com.

Where are you experiencing the behavior?  What environment?

OSTree sync should use configured http proxy settings.

When does the behavior occur? Frequently?  Repeatedly?   At certain times?

100% reproducible.

What information can you provide around timeframes and urgency?

Proxy configured as per Installation guide:
foreman-installer --katello-proxy-url=http://proxy.example.org --katello-proxy-port=8080

Setting $http_proxy and $https_proxy environment variables did not change behavior.


#Note proxy works with cdn but not with ostree

Comment 1 Geoff Gatward 2016-05-05 23:47:04 UTC
Found /etc/pulp/server/plugins.conf.d/ostree_importer.json  which contains no proxy info (the other importer.json files in this directory do contain the config)

root@sat62[/etc/pulp/server/plugins.conf.d] # cat ostree_importer.json
{
}


Manually copying the content from yum_importer.json to ostree_importer.json seems to have resolved this one, as a sync on the Atomic OSTree is now working.

Content of working ostree_importer.json:
{
        "proxy_host": "http://proxy.example.org",

        "proxy_port": 8080,

    "proxy_username": null,

    "proxy_password": null

}


In my installation the ostree support was added to Satellite (Content Management guide 11.1) AFTER the initial proxy configuration was performed (Install guide 3.4.1), so the ostree files were not present when the proxy was configured.

However, re-running the foreman-installer command to configure the proxy after the ostree setup still does not populate the ostree_importer.json.

IF the foreman-installer proxy routine was fixed to update the json, a documentation change would also be needed in the ostree section to mention re-running the proxy setup if required after installing ostree support.

Comment 4 Tom McKay 2017-01-24 15:30:55 UTC
Created redmine issue http://projects.theforeman.org/issues/18219 from this bug

Comment 5 Partha Aji 2017-06-08 20:40:11 UTC

*** This bug has been marked as a duplicate of bug 1366134 ***