Proxy Installation Guide
Installing and configuring Red Hat Satellite Proxy Server
Abstract
Chapter 1. Introduction to Red Hat Satellite Proxy
1.1. Red Hat Satellite Proxy Server
- Scalability: one organization can support multiple local Red Hat Satellite Proxies.
- Security: a secure connection is maintained from the client systems to the local Satellite Proxy, and from there to the Red Hat Satellite servers.
- Saves time: packages are delivered significantly faster over a local area network than the Internet.
- Saves bandwidth: packages are only downloaded once from Red Hat Satellite (using the local Satellite Proxy Server's caching mechanism), instead of downloading each package separately to each client system.
- Customized updates: create an automated package delivery system for custom software packages, as well as official Red Hat packages required for the client systems. Customized, private Red Hat Satellite channels allow an organization to automate delivery of in-house packages.
- Customized configuration: restrict or grant updates to specific architectures and operating system versions.
1.2. Architecture and Operations
Important
- The client performs a login action at the beginning of a client session. This login is passed through one or more Satellite Proxy Servers until it reaches a Red Hat Satellite server.
- The Red Hat Satellite server attempts to authenticate the client. If authentication is successful, the server returns a session token through the chain of Satellite Proxy Servers. This token, which has a signature and expiration time, contains user information, such as channel subscriptions, username, and so on.
- Each Satellite Proxy Server caches this token on its local file system in the
/var/cache/rhn/
directory. Caching reduces some of the overhead of authenticating with Red Hat Satellite servers and greatly improves the performance of Red Hat Satellite. - This session token is sent to the client machine and is used in subsequent actions on Red Hat Satellite.
Chapter 2. Requirements
2.1. Software Requirements
- Base operating system: Satellite 5.8 and Satellite Proxy 5.8 are only supported on Red Hat Enterprise Linux 6. You can install the operating system using any of the methods supported by Red Hat.
- Satellite Proxy requires an equal or high version of Satellite. For example, Satellite Proxy 5.6 works with Satellite 5.6 and Satellite 5.8, but Satellite Proxy 5.8 works only with Satellite 5.8.
- A Satellite Proxy entitlement within the Satellite Server account.
- A Provisioning entitlement within the Satellite Server account (this is packaged with the Satellite Proxy entitlement).
- Access to the Red Hat Network Tools channel for the installed version of Red Hat Enterprise Linux. This channel includes the spacewalk-proxy-installer package that contains the
configure-proxy.sh
installation program required to install Satellite Proxy. - All rhncfg* packages installed on the Satellite Proxy (from the Red Hat Network Tools channel).
- Either the spacewalk-certs-tools package installed on the Satellite Proxy (from the Red Hat Network Tools channel) for Hosted users, or the secure sockets layer (SSL) CA certificate password used to generate the parent server certificate for Satellite Server users.
Important
You can install Satellite Proxy on Red Hat Enterprise Linux 5 or 6 in any virtualized environment that Red Hat supports, including Xen, Hyper-V, KVM, and VMware. For more information about supported environments, see https://access.redhat.com/site/certified-hypervisors.
Each version of Red Hat Enterprise Linux requires a certain package set to support Satellite Proxy. Adding more packages can cause errors during installation. Therefore, Red Hat recommends obtaining the desired package set in the following ways:
- For kickstart installations, specify the following package group:
@Base
- For installing Red Hat Enterprise Linux from CD or ISO image, select the following package group:
Minimal
2.2. Hardware Requirements
- A Pentium IV Processor or equivalent.
- At least 2 GB of memory. 4 GB of memory recommended.
- At least 5 GB of storage for a base installation of Red Hat Enterprise Linux.
- 6 GB of storage per architecture per release.The caching mechanism used by Satellite Proxy is the Squid HTTP proxy, which saves significant bandwidth for the clients. Cached packages are stored in the
/var/spool/squid
directory. The more disk space that the cache has available, the less likely it is to remove RPM files before they have expired. Providing less than the recommended storage reduces the performance enhancements offered by using the Proxy server.
/var
mount point on the system storing local packages has sufficient disk space to hold all of the custom packages, which are stored in /var/spool/rhn-proxy
. The required disk space for local packages depends on the number of custom packages served.
/etc/sysconfig/rhn/rhnsd
configuration file of each client system.
Note
2.3. Additional Requirements
- Full Access
- Client systems need full network access to the Satellite Proxy services and ports.
- Firewall Rules
- Red Hat strongly recommends setting up a firewall between the Satellite Proxy and the Internet. However, depending on your Satellite Proxy implementation, you need to open several TCP ports in this firewall:
Table 2.1. Ports to Open on the Satellite Proxy Port Direction Reason 80 Outbound The Satellite Proxy uses this port to reach your Satellite URL. 80 Inbound Client requests arrive using either HTTP or HTTPS. 443 Inbound Client requests arrive using either HTTP or HTTPS. 443 Outbound The Satellite Proxy uses this port to reach the Satellite URL. 5222 Inbound Allows osad
client connections to thejabberd
daemon on the Satellite Proxy when using Red Hat Network Push technology.5269 Inbound and Outbound If the Satellite Proxy is connected a Satellite Server, this port must be open to allow server-to-server connections using jabberd
for Red Hat Network Push Technology. - Synchronized System Times
- Time sensitivity is a significant factor when connecting to a Web server running SSL (Secure Sockets Layer); it is imperative the time settings on the clients and server are close together so that the SSL certificate does not expire before or during use. It is recommended that Network Time Protocol (NTP) be used to synchronize the clocks.
- Fully Qualified Domain Name (FQDN)
- The system upon which the Satellite Proxy is installed must resolve its own FQDN properly.
- Distribution Locations
- Because the Satellite Proxy forwards virtually all local HTTP requests to Red Hat Satellite, take care in putting files destined for distribution (such as in a kickstart installation tree) in the non-forwarding location on the Satellite Proxy:
/var/www/html/pub/
. Files placed in this directory can be downloaded directly from the Satellite Proxy. This can be especially useful for distributing GPG keys or establishing installation trees for kickstart files. - Bandwidth
- Network bandwith is important for communication among Satellites, Proxies, and Clients. To accomodate high volume traffic, Red Hat recommends a high bandwidth on a network capable of delivering packages to many systems and clients. As a guide, Red Hat provides a set of estimates for package transfer from one system to another over various speeds.
Table 2.2. Bandwidth estimates Single Package (10Mb)Minor Release (750Mb)Major Release (6Gb)256Kbps5 Mins 27 Secs6 Hrs 49 Mins 36 Secs2 Days 7 Hrs 55 Mins512Kbps2 Mins 43.84 Secs3 Hrs 24 Mins 48 Secs1 Day 3 Hrs 57 MinsT1 (1.5Mbps)54.33 Secs1 Hr 7 Mins 54.78 Secs9 Hrs 16 Mins 20.57 Secs10Mbps8.39 Secs10 Mins 29.15 Secs1 Hr 25 Mins 53.96 Secs100Mbps0.84 Secs1 Min 2.91 Secs8 Mins 35.4 Secs1000Mbps0.08 Secs6.29 Secs51.54 SecsRed Hat recommends at least a 100Mbps network speed for minor and major releases. This avoids timeouts for transfers longer than 10 minutes. All speeds are relative to your network setup.
ntsysv
or chkconfig
to disable services.
Chapter 3. Installing Red Hat Satellite Proxy
3.1. Summary of Installation Steps
- Obtain and install the Red Hat Satellite Proxy entitlements on your Red Hat Satellite server. This involves creating an updated manifest on the Red Hat Customer Portal. See Section 3.2, “Obtaining Satellite Proxy Entitlements”.
- Upload the updated manifest on your Red Hat Satellite server and synchronize the required channels for Satellite Proxy. See Section 3.3, “Uploading Satellite Proxy Entitlements to Satellite”.
- Create or provision a new Red Hat Enterprise Linux system for use as the Satellite Proxy host and register it to Satellite. See Section 3.4, “Installing the Operating System on the Satellite Proxy Host”
- Install the required packages on the Satellite Proxy host. See Section 3.5, “Installing the Red Hat Satellite Proxy Server Packages”
- Run the
configure-proxy.sh
installation script. See Section 3.6, “Running the Red Hat Satellite Proxy Installation Script” - Perform any necessary post-configuration tasks. See Section 3.7, “Performing Post-installation Tasks”
3.2. Obtaining Satellite Proxy Entitlements
- Log on to the Customer Portal and click Subscriptions.
- Click Satellite Organizations.
- Click Satellite.
- Select your desired Satellite.
- Click Attach a subscription.
- In addition to the existing subscriptions, select the subscription that contains the
Red Hat Satellite Proxy
product. Specify the desired quantity, which corresponds to the number of proxies to create, and click ATTACH SELECTED. Check that the corresponding version of Red Hat Enterprise Linux subscription is already attached. It may take several minutes for the subscriptions to be attached. - When the Attach a subscription window appears, click .
- Clickand save the manifest file locally.
3.3. Uploading Satellite Proxy Entitlements to Satellite
- Log into your Red Hat Satellite server as an administration user.
- Navigate to→ → .
- Click Browse and select the updated manifest.
Note
To upload the manifest from the command line, on the Satellite server, run:[root@satellite ~]# rhn-satellite-activate --manifest=manifest_file.zip
- Synchronize the RHN Tools channel and the Proxy channel.
[root@satellite ~]# cdn-sync --channel rhn-tools-rhel-x86_64-server-6
[root@satellite ~]# cdn-sync --channel redhat-rhn-proxy-5.8-server-x86_64-6
- Once synchronized, add these entitlements to an activation key. Navigate to create new key. Add the base channel for these entitlements, such as Red Hat Enterprise Linux base channel, and select Provisioning entitlement. Click Create Activation Key to complete.→ and click
3.4. Installing the Operating System on the Satellite Proxy Host
Note
- Allocate sufficient space to the partition used to store packages, according to the hardware requirements prescribed earlier. The default location for cached Red Hat packages is
/var/spool/squid
; custom packages are located in/var/spool/rhn-proxy
.Note
The installation program automatically calculates the available space on the partition where/var/spool/squid
is mounted and allocates up to 60 per cent of the free space for use by Satellite Proxy. - Ensure the firewall rules are updated to meet the requirements stated in Section 2.3, “Additional Requirements”. Modify your
iptables
settings and restart the service. - Install the packages required by Red Hat Satellite Proxy Server.
Important
Install only the base Satellite Proxy packages as installing additional packages might cause the Satellite Proxy installation to fail.See Section 2.1, “Software Requirements” for how to obtain the correct package group needed for each version of Red Hat Enterprise Linux. - Enable
Network Time Protocol (NTP)
and select the appropriate time zone on the Satellite Proxy and on all client systems.
rhnreg_ks
command. For example:
[root@satproxy ~]# rhnreg_ks --serverUrl=http://satellite.example.com/XMLRPC --activationkey=1-123456789abcedf123456789abcdef12
3.5. Installing the Red Hat Satellite Proxy Server Packages
- Log in as the root user on the intended Satellite Proxy system.
- Subscribe the client to the required channels:
[root@satproxy ~]# spacewalk-channel --add -c rhn-tools-rhel-x86_64-server-6 --user admin --password adminpassword
- Assign a provisioning entitlement to the system:
- On the Satellite server, click on.
- Click the Satellite Proxy's name.
- Click thetab.
- Choosein the section.
- Click.
- Install the Satellite Proxy installation package. This package contains the main script that leads you through the actual Satellite Proxy installation.
[root@satproxy ~]# yum install spacewalk-proxy-installer
3.6. Running the Red Hat Satellite Proxy Installation Script
Important
/root/ssl-build
directory:
[root@satproxy ~]# mkdir /root/ssl-build
[root@satproxy ~]# scp 'root@satellite.example.com:/root/ssl-build/{RHN-ORG-PRIVATE-SSL-KEY,RHN-ORG-TRUSTED-SSL-CERT,rhn-ca-openssl.cnf}' /root/ssl-build
--force-own-ca
option when you run the installation script.
# configure-proxy.sh
Note
--non-interactive
option with the installation script if you want to use default answers without any user interaction.
The installation script requests details about the Satellite Proxy installation specific to the machine where you are performing the installation.
- RHN Parent
- The Satellite Server domain name or address of the system that serves content to the Satellite Proxy.
- CA Chain
- Press Enter to use the default path for the Certificate Authority (CA) Chain.If the Satellite Proxy is communicating with Red Hat Satellite, then this value is usually
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
. Otherwise, custom SSL certificates must be located in the/usr/share/rhn/
directory. - Satellite Proxy version to activate
- Request for confirmation of the version of Satellite Proxy to install.
- HTTP Proxy
- If the Satellite Proxy server connects through an HTTP proxy, enter the proxy host name and port number, for example, corporate.proxy.example.com:3128
- Traceback email
- A comma-separated list of email addresses to which error-related traceback messages are sent, usually the email of the Satellite Proxy administrator.
- Use SSL
- Press Enter or type
y
to configure the Satellite Proxy to use SSL. - SSL Certificate
- Enter the details necessary to generate a valid SSL server certificate. Example 3.1, “Example Generation of an SSL Certificate” demonstrates generating such a certificate.
Example 3.1. Example Generation of an SSL Certificate
Regardless of whether you enabled SSL for the connection to the Satellite Proxy Parent Server, you will be prompted to generate an SSL certificate. This SSL certificate will allow client systems to connect to this Satellite Proxy securely. See the Satellite Proxy Installation Guide for more information. Organization: Example Company Organization Unit [proxy1.example.com]: Common Name: proxy1.example.com City: New York State: New York Country code: US Email [admin@example.com]:
Y
at each prompt.
3.7. Performing Post-installation Tasks
- Configure SSL
- The
configure-proxy.sh
program configures SSL, and prompts you to create a Certificate Authority password and confirm it before generating the SSL keys and the public certificate.Example 3.2. Example Generation of CA Key and Public Certificate
Generating CA key and public certificate: CA password: ********* CA password confirmation: *********
- Create Configuration Channel
- The installation program also requests confirmation that you want to create a configuration channel based on the configuration files created while running
configure-proxy.sh.
The installation program creates a Satellite Server configuration channel based on the name of the system (thesysID
) where the Satellite Proxy is installed (in the following example, thesysID
is 1000010000), and collects the varioushttpd,
SSL,
squid,
andjabberd
server files that will comprise the configuration channel for the Satellite Proxy server.An example of this configuration is shown in Example 3.3, “Example of Creating a Configuration Channel”.Example 3.3. Example of Creating a Configuration Channel
Create and populate configuration channel rhn_proxy_config_1000010000? [Y]: Using server name satellite.example.com Red Hat Network username: admin Password: Creating config channel rhn_proxy_config_1000010000 Config channel rhn_proxy_config_1000010000 created using server name satserver.example.com Pushing to channel rhn_proxy_config_1000010001: Local file /etc/httpd/conf.d/ssl.conf -> remote file /etc/httpd/conf.d/ssl.conf Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf Local file /etc/rhn/cluster.ini -> remote file /etc/rhn/cluster.ini Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf Local file /etc/httpd/conf.d/cobbler-proxy.conf -> remote file /etc/httpd/conf.d/cobbler-proxy.conf Local file /etc/httpd/conf/httpd.conf -> remote file /etc/httpd/conf/httpd.conf Local file /etc/jabberd/c2s.xml -> remote file /etc/jabberd/c2s.xml Local file /etc/jabberd/sm.xml -> remote file /etc/jabberd/sm.xml
- Restart services
- The final step of the installation process is to restart all of the Satellite Proxy-related services. The installation program exits when this step is completed.
Example 3.4. Restarting all Satellite Proxy Server-related Services
Enabling Satellite Proxy Shutting down rhn-proxy... Shutting down Jabber router: [ OK ] Stopping httpd: [ OK ] Stopping squid: [ OK ] Done. Starting rhn-proxy... init_cache_dir /var/spool/squid... Starting squid: . [ OK ] Starting httpd: [ OK ] Starting Jabber services [ OK ] Done.
3.8. Automating Satellite Proxy Server Installation
configure-proxy.sh
script allows administrators to create answer files that contain predetermined responses to prompts in the installation program.
SSL,
and other configuration parameters. See the configure-proxy.sh
manual page (man configure-proxy.sh
) for more information about creating and using answer files.
# example of answer file for configure-proxy.sh # for full list of possible option see # man configure-proxy.sh VERSION=5.8 RHN_PARENT=satellite.example.com TRACEBACK_EMAIL=jsmith@example.com USE_SSL=1 SSL_ORG="Red Hat" SSL_ORGUNIT="Satellite" SSL_CITY=Raleigh SSL_STATE=NC SSL_COUNTRY=US ENABLE_SCOUT=N CA_CHAIN=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT POPULATE_CONFIG_CHANNEL=Y
--answer-file
option with the configure-proxy.sh
script to use an answer file to help automate your Satellite Proxy installation, as shown in the following example. Replace the example answers_file.txt
file name with the path to your answer file.
# configure-proxy.sh --answer-file=/path/to/answers_file.txt
Chapter 4. Custom Channel Package Manager
4.1. Using the Custom Channel Package Manager and Serving Local Packages through the Red Hat Network Proxy
spacewalk-proxy-package-manager
package and its dependencies.
*.rpm
) are stored on the Red Hat Satellite Proxy Server.
/etc/rhn/rhn.conf
configuration file. See the rhn_package_manager
manual page for more information.
- Create a private channel.
- Upload the local packages into the channel.
4.1.1. Creating a Private Channel
- Log in to your local Red Hat Satellite server in the network.
- Click Channels on the top navigation bar. If the Manage Channels option is not present in the left navigation bar, ensure that this user has channel editing permissions set. Do this through the Users category accessible through the top navigation bar.
- In the left navigation bar, click Manage Software Channels and then the button at the top-right corner of the page.
- Select a parent channel and base channel architecture, then enter a name, label, summary, and description for the new private channel. The channel label must: be at least six characters long, begin with a letter, and contain only lowercase letters, digits, dashes (-), and periods(.). Also enter the URL of the channel's GPG key. Although this field is not required, it is recommended to enhance security.
- Click.
4.1.2. Uploading Packages
Note
rhn_package_manager -c "label_of_private_channel" pkg-list
/var/spool/rhn-proxy/rhn
.
pkg-list
is the list of packages to be uploaded. Alternatively, use the -d
option to specify the local directory that contains the packages to add to the channel. Ensure that the directory contains only the packages to be included and no other files. Custom Channel Package Manager can also read the list of packages from standard input (using --stdin
).
rhn_package_manager -c "label_of_private_channel" --source pkg-list
-c
or --channel
), the uploaded package headers will be linked to all the channels listed.
Note
rhn_package_manager -s -c "label_of_private_channel"
-s
option will list all the missing packages (packages uploaded to the Red Hat Satellite Server not present in the local directory). You must be an Organization Administrator to use this command. The script will prompt you for your Red Hat Satellite username and password.
4.2. Configuring Proxy Precaching
yum
as well as anaconda
(for kickstart installations and provisioning). See the rhn_package_manager
manual page for more information.
rhn_package_manager
command to manually load RPM files into the Proxy server's cache, or you can create a cron
job that uses the rsync
command to perform the task automatically.
Note
4.2.1. Manually Loading RPM Files into the Proxy Cache
rhn_package_manager
have been updated to avoid unwanted cache collisions. You can use the existing rhn_package_manager --copyonly
command to populate the cache; (an alias to that option has been added with the more user-friendly name --cache-locally
). Another significant change to rhn_package_manager
is that it can now read and import packages from a channel export, which could for example be created on the Satellite server using the rhn-satellite-exporter
utility. This is in addition to the other methods that rhn_package_manager
can use to import RPM files, such as the --dir
option for importing all RPM files in a directory, or a list of RPM files supplied on the command line.
/mnt/export
:
# rhn_package_manager --cache-locally --from-export /mnt/export --channel my-channel-1
--channel
option:
# rhn_package_manager --cache-locally --from-export /mnt/export
rhn_package_manager
command. Mount the images one at a time and run the same command on each.
4.2.2. Automatically Loading RPM Files into the Proxy Cache
rsync
command to download any updated RPM files to the Proxy cache. This assumes that you want to download all of the RPM files on the Satellite server to the Proxy. You need to run the cron job and rsync
command as root on the Proxy server, but can then log in to the Satellite server as any user that has read access to the RPM store; this should be all users.
You need to set up SSH key pairs that enable the root
user on the Proxy server to establish an SSH connection to $user
on the Satellite server, without typing a password.
Important
root
on the Proxy server:
ssh-keygen -t rsa -N '' -f /root/.ssh/id_dsa \ && cat /root/.ssh/id_dsa.pub | ssh user@satellite.example.com 'cat >> .ssh/authorized_keys'
# ssh user@satellite.example.com
You now need to add a cron
job with an appropriate rsync
command. For example, as root on the Proxy:
crontab -e 1 3 * * * /usr/bin/rsync -r user@satellite.example.com:/var/satellite/redhat/*/ /var/spool/rhn-proxy/rhn # write and quit with :wq
rsync
command at 3:01 a.m. every day and downloads any RPM files that are on the Satellite server into the Proxy cache. The /var/satellite
directory is the default Satellite root directory, but this is configurable. If you have changed it on your Satellite installation then adjust this command appropriately.
Chapter 5. Configuring Satellite Proxy to Use CNAME Records
5.1. Prerequisites
- Ensure that the required CNAME records have been configured for the server.
- Add the CNAME records to the Satellite Proxy server configuration.
- Create a new multi-host certificate and install it on the Satellite Proxy.
5.2. Adding CNAME Records to the Satellite Proxy Server Configuration
Note
Procedure 5.1. To Configure Your Satellite Proxy Server to Use CNAME Records:
- Determine the system ID of your proxy server. You can find this value in the
/etc/sysconfig/rhn/systemid
file on your proxy server. Locate the following stanza in this file (your system ID will be different from this example):<member> <name>system_id</name> <value><string>ID-1036997498</string></value> </member>
The system ID is contained within <string> tags. Do not include "ID-" as part of the actual system ID. - Add the following line to the
/etc/rhn/rhn.conf
file. Replace systemID with the value from the previous step:valid_cnames_sytemID= cname1,cname2,cname3
- Run the following command to restart the Tomcat service:
# service rhn-proxy restart
5.3. Generating and Using Multi-host SSL Certificates
rhn-ca-openssl.cnf
file to ensure that the Satellite Proxy server is aware of and uses these certificates.
Procedure 5.2. To Update the SSL Configuration File to use Multi-host Certificates:
- Edit the
/root/ssl-build/rhn-ca-openssl.cnf
file and locate the [CA_default] section. - Ensure the entry
copy_extensions = copy
exists and is not commented out. - Save and close the file.
Important
configure-proxy.sh
with SSL_CNAME
set, or the installation will fail.
Procedure 5.3. To Update the Answers File to Use Multi-host SSL Certificates:
- Edit the
answers.txt
file that you created for the initial Satellite Proxy installation. If you did not create such a file, you can find an example setup in/usr/share/doc/spacewalk-setup-<version>/answers.txt.
- Ensure the following line exists, and is not commented out:
SSL_CNAME = (cname01 cname02 cname03)
- Run the
configure-proxy.sh
script with the--answer-file
option to generate the multi-host SSL certificate. For example:# configure-proxy.sh --answer-file=</path/to/answers.txt>
Note
You can run theconfigure-proxy.sh
script multiple times to test or update configurations, as required.
Chapter 6. Load Balancing Satellite Proxy Servers
- Red Hat Satellite Proxy A, signified with IP address
192.168.100.16
and hostnameproxya.example.com
- Red Hat Satellite Proxy B, signified with IP address
192.168.100.17
and hostnameproxyb.example.com
- Load Balancer, signified with hostname
lb.example.com
- Red Hat Satellite Server with Red Hat Satellite Proxy A and B connected
- The client machine, signified with IP address
192.168.100.19
6.1. Installing Proxy Services to the Load Balancer
# yum install spacewalk-proxy-installer -y # configure-proxy.sh
Important
rhn-tools-rhel-x86_64-server-6
channel to access the spacewalk-proxy-installer
package.
httpd
package and its dependencies.
# yum remove httpd -y
6.2. Installing a Squid Reverse Proxy
# yum install squid
rhn-ssl-tool
on the Satellite server to generate the server certificates, because the CA is already available.
lb.example.com
; substitute the host name that applies to your deployment, and enter a suitable build directory. Run this command on the Satellite server.
$ rhn-ssl-tool --gen-server --set-hostname=lb.example.com -d /root/ssl-build
rhn-ssl-tool
used above creates SSL files for lb.example.com
and saves the files in /root/ssl-build
directory. Copy the server.crt
, server.key
, and the RHN-ORG-TRUSTED-SSL-CERT
CA certificate from the dhcp
directory to the lb.example.com
load balancer. These files are used to set up SSL for the actual load balancer. The RHN-ORG-TRUSTED-SSL-CERT
certificate allows SSL communication between the load balancer and the proxies.
/etc/squid/squid.conf
file on the lb.example.com
server to set up reverse proxy mode:
Example 6.1. Setting up Reverse Proxy Mode
# # SSL configuration # # Ensure you enter each configuration directive on a single line acl is_ssl port 443 https_port 443 cert=/etc/pki/tls/certs/lb.crt key=/etc/pki/tls/certs/lb.key accel vhost name=proxy_ssl cache_peer proxya.example.com parent 443 0 no-query originserver round-robin ssl name=proxya.example.com sslcafile=/etc/pki/tls/certs/squid-ca.crt cache_peer proxyb.example.com parent 443 0 no-query originserver round-robin ssl name=proxyb.example.com sslcafile=/etc/pki/tls/certs/squid-ca.crt cache_peer_access proxya.example.com allow is_ssl cache_peer_access proxya.example.com deny !is_ssl cache_peer_access proxyb.example.com allow is_ssl cache_peer_access proxyb.example.com deny !is_ssl http_access allow is_ssl # # Non-SSL configuration # # Ensure you enter each configuration directive on a single line acl nonssl port 80 http_port 80 accel name=proxy_nonssl defaultsite=dhcp16.example.com cache_peer 192.168.100.16 parent 80 0 no-query name=proxy_nonssl originserver cache_peer_access proxy_nonssl allow nonssl cache_peer_access proxy_nonssl deny !nonssl http_access allow nonssl sslpassword_program /bin/password.out forwarded_for on
server.crt
and server.key
files were renamed to lb.crt
and lb.key
respectively (short for load balancer) for easier identification. The Satellite CA certificate was renamed to squid-ca.crt
; the cache_peer sslcafile
option refers to this file.
squid
group:
# chgrp squid /etc/pki/tls/certs/{lb.crt,lb.key,squid-ca.crt}
-rw-r--r--. 1 root squid 5450 Aug 23 21:23 lb.crt -rw-r--r--. 1 root squid 1675 Aug 23 21:23 lb.key -rw-r--r--. 1 root squid 5363 Aug 22 14:19 squid-ca.crt
cache_peer
directives set up the two proxies that will be used in round-robin format. Note that you need to specify the CA certificate so that the load balancer can communicate with the proxies. Further, we are only allowing port 443 traffic to hit these proxies using the squid acl is_ssl
and cache_peer
directives.
defaultsite
directive. Acls are set up similar to the ssl port.
sslpassword_program
directive allows you to send the SSL key passphrase (if used; displayed for completeness) to squid on startup without human intervention. The contents of password.out is a bash script that echos the SSL passphrase. The forwarded_for
directive configures the load balancer to send the forwarded_for
headers to the proxies.
Important
/etc/squid/squid.conf
and comment out the default port, 3128, that squid normally listens on:
# Squid normally listens to port 3128 # http_port 3128
# service squid restart
6.3. Setting up the Client
/etc/sysconfig/rhn/up2date
file on the client to correctly address the load balancer:
serverURL[comment]=Remote server URL (use FQDN) serverURL=https://lb.example.com/XMLRPC
6.4. Testing the Configuration
Start the load balancer and the proxy machines. Note that the Satellite Proxy logs will not be created until the first requests are delivered (/var/log/rhn/
). Try to install and remove an RPM file, such as zsh.
/var/log/squid/access.log
file on the load balancer should contain information similar to the following:
1377540630.159 97 192.168.100.19 TCP_MISS/200 1515 POST https://lb.example.com/XMLRPC - ROUNDROBIN_PARENT/proxya.example.com text/base64 1377540630.733 529 192.168.100.19 TCP_MISS/200 1409 POST https://lb.example.com/XMLRPC - ROUNDROBIN_PARENT/proxyb.example.com text/xml 1377540639.968 87 192.168.100.19 TCP_MISS/200 3742 POST https://lb.example.com/XMLRPC - ROUNDROBIN_PARENT/proxya.example.com text/xml 1377540644.273 83 192.168.100.19 TCP_MEM_HIT/200 2238956 GET https://lb.example.com/XMLRPC/GET-REQ/rhel-x86_64-server-6/getPackage/zsh-4.3.10-5.el6.x86_64.rpm - NONE/- application/octet-stream 1377540646.765 100 192.168.100.19 TCP_MISS/200 1515 POST https://lb.example.com/XMLRPC - ROUNDROBIN_PARENT/proxyb.example.com text/base64 1377540647.291 485 192.168.100.19 TCP_MISS/200 1409 POST https://lb.example.com/XMLRPC - ROUNDROBIN_PARENT/proxya.example.com text/xml
yum
package install is still shared between the multiple proxies because multiple requests are involved during a package installation. The client IP address is 192.168.100.19 and you can see the named proxya.example.com
and proxyb.example.com
cache peers corresponding to the two different Satellite Proxies.
Refer to the following log files to monitor load balancer activity:
/var/log/squid/access.log
for watching requests arriving from the client/var/log/squid/cache.log
for debugging SSL startup issues and cache peers on ports 80 and 443
netstat
command to ensure that the squid load balancer is listening on the correct ports:
# netstat -tulpn | grep squid | grep tcp tcp 0 0 :::80 :::* LISTEN 29120/(squid) tcp 0 0 :::443 :::* LISTEN 29120/(squid)
Chapter 7. Upgrading a Red Hat Proxy Server Installation
7.1. Prerequisites
- Red Hat Enterprise Linux 6 (64-bit only).
- Removal of the previous Proxy server's system profile from the parent Satellite server.
7.2. Upgrading Your Proxy Installation
- Back up your existing Proxy server. If applicable, restore the SSL build directory from the backup to the directory
/root/ssl-build
. - Register the Proxy to the parent Satellite. Make sure that the Proxy is subscribed to both the Red Hat Enterprise Linux Server base channel and the Red Hat Network Tools child channel.
- Install the
spacewalk-proxy-installer
package from the Red Hat Network Tools child channel:# yum install spacewalk-proxy-installer
- Install the latest version of Proxy, as documented in Section 3.5, “Installing the Red Hat Satellite Proxy Server Packages”.
Note
If the Proxy server is registered to Red Hat Satellite, and the Proxy previously managed custom channels, restore the custom package repository from the pre-upgrade backup. The permissions and ownership will also need to be set up properly.# chmod 0750 /var/spool/rhn-proxy # chown apache:apache /var/spool/rhn-proxy # mkdir -m 0750 -p /var/spool/rhn-proxy/list # chown apache:apache /var/spool/rhn-proxy/list
The default custom package repository is usually/var/spool/rhn-proxy
. - After the installation, update the server to the latest errata updates:
# yum update
- Restart the Proxy Server services and test the Proxy Server's functionality:
# /usr/sbin/rhn-proxy restart
Appendix A. Sample Satellite Proxy Server Configuration File
/etc/rhn/rhn.conf
configuration file for the Satellite Proxy provides a means for administrators to establish key settings. Take care when making any changes, however, because any configuration errors in this file may cause Satellite Proxy failures.
traceback_mail
and proxy.rhn_parent
parameters. Review the sample and its comments (comments are identified by a hash mark (#) in column 1), for additional details.
Important
use_ssl
option to rhn.conf
for testing purposes. Set its value to 0 to turn off SSL between the Satellite Proxy and the Satellite server. Be aware that this greatly compromises security. Reset this option to its default value of 1 to re-enable SSL, or remove the line from the configuration file.
# Automatically generated RHN Management Proxy Server configuration file. # ------------------------------------------------------------------------- # SSL CA certificate location proxy.ca_chain = /usr/share/rhn/RHNS-CA-CERT # Corporate HTTP proxy, format: corp_gateway.example.com:8080 proxy.http_proxy = # Password for that corporate HTTP proxy proxy.http_proxy_password = # Username for that corporate HTTP proxy proxy.http_proxy_username = # Location of locally built, custom packages proxy.pkg_dir = /var/spool/rhn-proxy # Hostname of RHN Server or RHN Satellite proxy.rhn_parent = satellite.example.com # Destination of all tracebacks, etc. traceback_mail = user0@domain.com, user1@domain.com
Appendix B. Glossary of Terms
- Channel
- A channel is a list of software packages. There are two types of channels: base channels and child channels. A base channel consists of a list of packages based on a specific architecture and Red Hat release. A child channel is a channel associated with a base channel that contains extra packages.
- Organization Administrator
- An Organization Administrator is a user role with the highest level of control over an organization's Red Hat Satellite account. Members with this role can add and remove other users, other systems, and system groups to the organization. Each Red Hat Satellite organization requires at least one Organization Administrator.
- Channel Administrator
- A Channel Administrator is a user role with full access to channel management capabilities. Channel Administrators can create channels and assign packages to channels. Organization Administrators can use the Users tab on the Red Hat Satellite website to assign this role to other users.
- Red Hat Update Agent
- The Red Hat Update Agent is the client application that allows users to retrieve and install new or updated packages on the client system.
- Traceback
- A traceback is a detailed error description that is useful for troubleshooting the Satellite Proxy. Traceback files are automatically generated when a critical error occurs, and they are then emailed to the individuals designated in the Satellite Proxy's configuration file.
Appendix C. Revision History
Revision History | |||
---|---|---|---|
Revision 1.1-0 | Wed Feb 1 2017 | ||
|