Red Hat Bugzilla – Bug 462396
Need DMZ Proxy solution write-up
Last modified: 2016-07-03 20:54:14 EDT
Description of problem:
In the beginning parts of the Satellite reference guide, there is documentation that describes various Satellite and Satellite + Proxy architectures for running your systems management set up.
It would be very good to have an additional 'architecture' outlined here that describes a network with some clients on an internal network and some clients in a DMZ. Without a Proxy, this case is difficult as a hole must be poked and maintained in the firewall for each client in the DMZ for it to be able to communicate with the Satellite. (Internal network can communicate out to DMZ but DMZ clients cannot communicate in.) This solution involves poking one hole in the firewall for Proxy, and allowing all DMZ clients to connect to the Satellite via the Proxy.
This is a somewhat common set up for Satellite users and should be illustrated in the guide as a solution to a very common network restriction.
Xixi (cc'ed) will be writing a knowledgebase article corresponding with this solution.
Giving ownership to John Ha - Xixi still on CC.
So, is there a KBase article for this DMZ solution? We've missed the window for 5.3.0, I'm afraid, but I can queue it up for 5.3.x or 5.n.
(In reply to comment #2)
> So, is there a KBase article for this DMZ solution?
This is on my TODO but keep getting pre-empted... Let me see if I can get a draft this or next week...
We need more details about how this DMZ would look like diagrammatically and the general user tasks to set such a network up.
Recommending this be moved to sat600 for inclusion then.
This is slated for inclusion in the Satellite 5.5 documentation. If there is
any other source content that is not listed (or linked to) in this bug, please
link to it.
Added to content specification for 5.4.1.
DMZ Proxy Solution
Unless the Satellite server is in disconnected mode, it needs to initiate outbound connections on ports 80 and 443 to the Red Hat Network (RHN) Hosted service (<filename>rhn.redhat.com</filename>, <filename>xmlrpc.rhn.redhat.com</filename>, and <filename>satellite.rhn.redhat.com</filename>). To ensure correct functioning of the satellite system, do not restrict access to these hosts and ports. If required, an http or https proxy can be used, by issuing the <command>satellite-sync --http-proxy</command> command.
The Satellite server needs to allow inbound connections on ports 80 and 443 from client systems and any RHN Proxy servers connected to the Satellite, as well as any system that needs to access the Satellite Web UI. WebUI and client requests come in via either http or https.
The RHN monitoring functionality requires outbound connections to individual monitoring-enabled client systems on port 4545. RHN Satellite monitoring makes connections to <command>rhnmd</command> running on client systems if monitoring is enabled and probes are configured for registered systems.
The RHN push functionality requires both outbound and inbound connections on port 5269 to and from each registered RHN Proxy server with RHN push functionality enabled. This is used for two-way communications between the <command>jabberd</command> service on Satellite and Proxy, respectively. In addition, it needs to allow inbound connections on port 5222 from client systems directly registered to the Satellite. This is used for one-way (client to server) communications between the <command>osad</command> service on client systems and the <command>jabberd</command> service on the Satellite.
In the Additional Requirements section of the Installation Guide, as per John's suggestion. Revision 1-29.
Taking this bug for verification.
This book has now been dropped to translation (RT#75265).
No further updates can be accepted. Please raise a new bug for any changes.
5.4.1 Satellite books are now available on docs.redhat.com. Please raise a new bug for any issues.