Bug 462396 - Need DMZ Proxy solution write-up
Need DMZ Proxy solution write-up
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Docs Reference Guide (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lana Brindley
Martin Minar
: Documentation
Depends On: 644720
Blocks: sat541-docs
  Show dependency treegraph
Reported: 2008-09-15 17:54 EDT by Máirín Duffy
Modified: 2016-07-03 20:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-16 18:27:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Máirín Duffy 2008-09-15 17:54:54 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.
Comment 1 Clifford Perry 2009-01-09 17:18:35 EST
Giving ownership to John Ha - Xixi still on CC.
Comment 2 John Ha 2009-03-04 19:42:46 EST
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.
Comment 3 Xixi 2009-03-04 21:01:08 EST
(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...
Comment 4 John Ha 2009-06-09 01:30:17 EDT
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.
Comment 11 Lana Brindley 2010-10-08 00:55:17 EDT
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.

Comment 12 Lana Brindley 2010-11-16 16:12:35 EST
Added to content specification for 5.4.1.

Comment 13 Lana Brindley 2011-01-30 21:38:52 EST
		    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.

Comment 14 Pavel Novotny 2011-04-21 08:19:54 EDT
Taking this bug for verification.
Comment 16 Lana Brindley 2011-05-05 20:08:53 EDT
This book has now been dropped to translation (RT#75265).
No further updates can be accepted. Please raise a new bug for any changes.
Comment 17 Lana Brindley 2011-06-16 18:27:26 EDT
5.4.1 Satellite books are now available on docs.redhat.com. Please raise a new bug for any issues.


Note You need to log in before you can comment on or make changes to this bug.