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.
Description of problem:
While Satellite serves /pub to clients on port 80 and 443, an external Capsule (offering just a subset of Satellite functionality) has the same served via 80 and 8443.
While serving /pub via HTTPS is probably not the most important feature of Satellite/Capsule, it is a nice way to distribute files to the clients.
Moving the listening port back to 443 will gain these pros:
- logical coherence where _any_ client machine within Satellite deployment talks to
- simplified firewall setting
Version-Release number of selected component (if applicable):
Sat 6.1.8 (in fact any Sat6)
How reproducible:
100%
Hey,
so it is not as easy as I initially thought, but I still think that the feature is valuable.
We use /pub for e.g. serving bootstrap.py in an easy accessible manner to the clients. Now we also install katello-client-bootstrap on capsules, so the vanilla version will be served equally at http://sat/pub/ and on http://caps/pub/.
Now bootstrap is a thing that customers might want to adjust to their specific needs (and not all of them just send PRs upstream ;)). This would then mean that they have to place bootstrap-hacked.py on every capsule (if the satellite is not reachable from the client).
A solution for the customer might be using the (not very documented) proxy on https://caps:8443/ to reach the satellite. But then they have to distinguish whether to access caps:8443 or sat:80 if they have clients on the satellite directly.
Having the client fetch http://whatever/pub-global/ which is always proxied to /pub on the satellite (= on the satellite it is just an alias) would allow the customer not to care much what "whatever" is in terms of running Satellite component.
Does that make sense?