Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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.