Hide Forgot
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%
thinking again: no, proxying /pub is wrong as the capsule will drop own RPMs there.
Moving 6.2 bugs out to sat-backlog.
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?
It does, thanks. Moving this to an RFE per your description, but keeping it.
This has been available since 6.3. Closing this out as Current Release.