Red Hat blog
Many organizations utilizing Red Hat Satellite have network policies that block direct access to the internet by the Satellite Server, and instead require that the Satellite Server go through an HTTP proxy to access the internet to synchronize content. Satellite 6.7 introduced some changes and new functionality around its support for connecting to the Red Hat CDN through a proxy that will be covered in this post.
On versions of Satellite prior to 6.7, it was possible to enable utilization of a global proxy. However, in environments with multiple proxy servers, it was not possible to configure a different proxy server for individual repositories. With Satellite 6.7, in addition to the ability to set a global proxy, it is now also possible to configure proxies at the individual repository level or at the product level.
Two example scenarios where multiple proxies might be needed include:
Environments in which one proxy server should be used to connect to the Red Hat CDN, and another proxy server is used to connect to a third party URL that provides content for a third party repository.
A Satellite environment with multiple organizations, where one organization would use one proxy, while a different organization would use a different proxy.
This post will cover the proxy related improvements in Satellite 6.7, as well as the new method used to configure a global proxy.
Configuring a Global Proxy in Satellite 6.7
Satellite versions prior to 6.7 used the
satellite-installer command to configure the proxy settings. This method is no longer used in Satellite 6.7.
To configure a global proxy in Satellite 6.7, login to the web interface, go to the Infrastructure menu and select HTTP Proxies.
Next, click on the New HTTP Proxy button, then provide a name for the proxy, the URL (including protocol and port, such as https://proxy-primary.example.com:3128), and optionally provide a username and password if the proxy requires authentication. In this example, we will name the proxy Primary Proxy.
Click the Test Connection button to validate the proxy configuration, which should show that the proxy connection was successful.
Finally, go to the Locations and Organizations tabs and select the locations and organizations that will be using this proxy.
The next step is to configure Satellite to use this newly created proxy as the global default proxy. To do so, go to the Administer menu, and select Settings. Select the Content tab and find the Default HTTP Proxy setting. Click the edit pencil button and select the proxy previously created Primary Proxy.
Configuring the Satellite server’s Subscription Manager configuration file (
/etc/rhsm/rhsm.conf) to use this proxy is also required, and this is outlined in the Satellite 6.7 documentation.
At this point, if you want everything on Satellite to go through this global proxy, you’re done. If you have multiple proxies in the environment that you would like to use different proxies for certain repositories or products, or if you would like different Satellite organizations to use different proxies, see the next sections.
Customizing Proxies at the Repository Level
Satellite 6.7 introduced the ability to configure proxies at the repository or product level. In the example in this section, I have the global HTTP proxy setup per the previous steps, however, I would like to sync just my EPEL 8 repository through a different proxy.
We will need to go back to the Infrastructure menu, select HTTP Proxies, and add another proxy as we did in the previous section. In this example, we’ll name this new proxy EPEL Proxy.
Next, we will go to the Content menu and select Products. We’ll then click on the name of the product that contains the EPEL repository, which will show a list of repositories in this product. In this example, we’ll click on the EPEL repository for which we want to customize the proxy settings.
Under the Sync Settings header, there will be a HTTP Proxy setting. This defaults to the Global Default proxy. We’ll click the pencil edit button and select Use Specific HTTP Proxy, which will make the HTTP Proxy configuration option available. From here, we can select the previously created EPEL Proxy we would like to use for this repository.
It is also possible to configure individual repositories to not use a proxy by selecting the No HTTP Proxy option.
Customizing Proxies at the Product Level
If you would like all of the repositories under a product to use a different proxy, the proxy can be defined at the product level. To configure this, go to the Content menu, and select Products. Check the box for the product you would like to customize the proxy for, and click the drop down arrow in the upper right corner. From the dropdown, select Manage HTTP Proxy.
You will be presented with the HTTP Proxy Management screen. From here, you can set the product to use the Global Default proxy, No Proxy, or Use Specific HTTP Proxy.
In this example, we will have this product use a Specific HTTP Proxy, and select the EPEL Proxy.
Using a Different Proxy for each Organization
In some environments, it might be necessary to set a different proxy for each Satellite Organization. Satellite doesn’t have an HTTP proxy setting at the organization level, and the Default HTTP Proxy setting is global to all organizations.
One possible solution for this would be to start with one of the organizations and create the HTTP proxy under the Infrastructure, HTTP Proxies menu. When creating the proxy, verify the Organization and Location tabs specify the correct items, then follow the previously covered steps to set a custom proxy at the product level for each of the products in that organization.
These steps would then be repeated on any additional organizations, with a new proxy created under each organization, and each of the organization's products would have the custom proxy set to that organization's proxy. In the end, every product in every organization would be configured with the appropriate HTTP proxy.
Summary and Closing
Satellite 6.7 makes working with multiple proxies possible in a way previously not available. In environments with multiple proxies, this opens up new possibilities for Satellite 6.7 customers.
About the author
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).