Chapter 3. Performing Additional Configuration on Satellite Server
3.1. Using Red Hat Insights with Satellite Server
You can use Red Hat Insights to diagnose systems and downtime related to security exploits, performance degradation and stability failures. You can use the dashboard to quickly identify key risks to stability, security, and performance. You can sort by category, view details of the impact and resolution, and then determine what systems are affected.
Note that you do not require a Red Hat Insights entitlement in your subscription manifest. For more information about Satellite and Red Hat Insights, see Red Hat Insights on Satellite Red Hat Enterprise Linux (RHEL).
To maintain your Satellite Server, and improve your ability to monitor and diagnose problems you might have with Satellite, install Red Hat Insights on Satellite Server and register Satellite Server with Red Hat Insights.
Scheduling insights-client
Note that you can change the default schedule for running insights-client
by configuring insights-client.timer
on Satellite. For more information, see Changing the insights-client schedule in the Client Configuration Guide for Red Hat Insights.
Procedure
To install Red Hat Insights on Satellite Server, enter the following command:
# satellite-maintain packages install insights-client
To register Satellite Server with Red Hat Insights, enter the following command:
# insights-client --register
3.2. Enabling the Satellite Tools Repository
The Satellite Tools repository provides the katello-agent
and puppet
packages for clients registered to Satellite Server. Installing the Katello agent is recommended to allow remote updates of clients. The base system of a Capsule Server is a client of Satellite Server and therefore must also have the Katello agent installed.
Procedure
To enable the Satellite Tools repository, complete the following steps:
- In the Satellite web UI, navigate to Content > Red Hat Repositories.
- Use the Search field to enter the following repository name: Red Hat Satellite Tools 6.5 (for RHEL 7 Server) (RPMs).
In the Available Repositories pane, click on Red Hat Satellite Tools 6.5 (for RHEL 7 Server) (RPMs) to expand the repository set.
If the Red Hat Satellite Tools 6.5 items are not visible, it may be because they are not included in the Subscription Manifest obtained from the Customer Portal. To correct that, log in to the Customer Portal, add these repositories, download the Subscription Manifest and import it into Satellite.
-
For the
x86_64
entry, click the Enable icon to enable the repository.
Enable the Satellite Tools repository for every supported major version of Red Hat Enterprise Linux running on your hosts. After enabling a Red Hat repository, a Product for this repository is automatically created.
For CLI Users
Enable the Satellite Tools repository using the hammer repository-set enable
command:
# hammer repository-set enable --organization "initial_organization_name" \
--product 'Red Hat Enterprise Linux Server' \
--basearch='x86_64' \
--name 'Red Hat Satellite Tools 6.5 (for RHEL 7 Server) (RPMs)'
3.3. Synchronizing the Satellite Tools Repository
Use this section to synchronize the Satellite Tools repository from the Red Hat Content Delivery Network (CDN) to your Satellite. This repository repository provides the katello-agent
and puppet
packages for clients registered to Satellite Server.
Procedure
To synchronize the Satellite Tools repository, complete the following steps:
In the Satellite web UI, navigate to Content > Sync Status.
A list of product repositories available for synchronization is displayed.
- Click the arrow next to the Red Hat Enterprise Linux Server product to view available content.
- Select Red Hat Satellite Tools 6.5 (for RHEL 7 Server) RPMs x86_64.
- Click Synchronize Now.
For CLI Users
Synchronize your Satellite Tools repository using the hammer repository synchronize
command:
# hammer repository synchronize --organization "initial_organization_name" \
--product 'Red Hat Enterprise Linux Server' \
--name 'Red Hat Satellite Tools 6.5 for RHEL 7 Server RPMs x86_64' \
--async
3.4. Configuring Satellite Server with an HTTP Proxy
If your network uses an HTTP Proxy, you can configure Satellite Server to use an HTTP proxy for requests to the Red Hat Content Delivery Network (CDN) or another content source. Use the FQDN instead of the IP address where possible to avoid losing connectivity because of network changes.
The following procedure configures a proxy only for downloading content for Satellite.
Authentication Methods
Only basic authentication is supported: add your user name and password information to the --katello-proxy-url
option, or use the --katello-proxy-username
and --katello-proxy-password
options.
To Configure Satellite with an HTTP Proxy
Verify that the
http_proxy
,https_proxy
, andno_proxy
variables are not set.# unset http_proxy # unset https_proxy # unset no_proxy
Run
satellite-installer
with the HTTP proxy options.# satellite-installer --scenario satellite \ --katello-proxy-url=http://myproxy.example.com \ --katello-proxy-port=8080 \ --katello-proxy-username=proxy_username \ --katello-proxy-password='proxy_password'
Verify that Satellite Server can connect to the Red Hat CDN and can synchronize its repositories.
On the network gateway and the HTTP Proxy, enable TCP for the following host names:
Host name Port Protocol subscription.rhsm.redhat.com
443
HTTPS
cdn.redhat.com
443
HTTPS
*.akamaiedge.net
443
HTTPS
cert-api.access.redhat.com (if using Red Hat Insights)
443
HTTPS
api.access.redhat.com (if using Red Hat Insights)
443
HTTPS
Satellite Server communicates with the Red Hat CDN securely over SSL. Use of an SSL interception proxy interferes with this communication. These hosts must be whitelisted on the proxy.
For a list of IP addresses used by the Red Hat CDN (cdn.redhat.com), see the Knowledgebase article Public CIDR Lists for Red Hat on the Red Hat Customer Portal.
On Satellite Server, complete the following details in the
/etc/rhsm/rhsm.conf
file:# an http proxy server to use (enter server FQDN) proxy_hostname = myproxy.example.com # port for http proxy server proxy_port = 8080 # user name for authenticating to an http proxy, if needed proxy_user = # password for basic http proxy auth, if needed proxy_password =
SELinux Considerations for Custom Ports
SELinux ensures access of Red Hat Satellite 6 and Red Hat Subscription Manager only to specific ports. In the case of the HTTP cache, the TCP ports are 8080, 8118, 8123, and 10001 - 10010. If you use a port that does not have SELinux type http_cache_port_t
, complete the following steps:
To verify the ports that are permitted by SELinux for the HTTP cache, enter a command as follows:
# semanage port -l | grep http_cache http_cache_port_t tcp 8080, 8118, 8123, 10001-10010 [output truncated]
To configure SELinux to permit a port for the HTTP cache, for example 8088, enter a command as follows:
# semanage port -a -t http_cache_port_t -p tcp 8088
3.5. Using an HTTP Proxy for all Satellite HTTP Requests
If your Satellite Server must remain behind a firewall that blocks HTTP and HTTPS, you can configure a proxy for communication with external systems, including compute resources.
Note that if you are using compute resources for provisioning, and you want to use a different HTTP proxy with the compute resources, the proxy that you set for all Satellite communication takes precedence over the proxies that you set for compute resources.
To set an HTTP proxy for all outgoing HTTP connections from Satellite, complete the following steps:
- In the Satellite web UI, navigate to Administer > Settings.
- In the HTTP(S) proxy row, select the adjacent Value column and enter the proxy URL.
- Click the tick icon to save your changes.
Excluding Hosts from Receiving Proxied Requests
If you use an HTTP Proxy for all Satellite HTTP or HTTPS requests, you can prevent certain hosts from communicating through the proxy.
To exclude one or more hosts from communicating through the proxy, complete the following steps:
- In the Satellite web UI, navigate to Administer > Settings.
- In the HTTP(S) proxy except hosts row, select the adjacent Value column and enter the names of one or more hosts that you want to exclude from proxy requests.
- Click the tick icon to save your changes.
3.6. Resetting the HTTP Proxy
If you want to reset the current HTTP proxy setting, enter the following command:
# satellite-installer --scenario satellite --reset-katello-proxy-url \ --reset-katello-proxy-port --reset-katello-proxy-username \ --reset-katello-proxy-password
3.7. Enabling Power Management on Managed Hosts
When you enable the baseboard management controller (BMC) module on Satellite Server, you can use power management commands on managed hosts using the intelligent platform management interface (IPMI) or a similar protocol.
The BMC service enables you to perform a range of power management tasks. The underlying protocol for this feature is IPMI; also referred to as the BMC function. IPMI uses a special network interface on the managed hardware that is connected to a dedicated processor that runs independently of the host’s CPUs. In many instances the BMC functionality is built into chassis-based systems as part of chassis management (a dedicated module in the chassis).
For more information on the BMC service, see Adding a Baseboard Management Controller (BMC) Interface in the Managing Hosts guide.
Before You Begin
- All managed hosts must have a network interface, with type BMC. Satellite uses this NIC to pass the appropriate credentials to the host.
Enable Power Management on Managed Hosts
Run the installer with the options to enable BMC.
# satellite-installer --foreman-proxy-bmc "true" \ --foreman-proxy-bmc-default-provider "freeipmi"
3.8. Configuring DNS, DHCP, and TFTP on Satellite Server
You can configure DNS, DHCP, and TFTP on Satellite Server.
If you want to configure external services, see Chapter 4, Configuring External Services.
If you want to disable these services in Satellite in order to manage them manually, see Section 3.9, “Disabling DNS, DHCP, and TFTP for Unmanaged Networks”.
To view a complete list of configurable options, enter the satellite-installer --scenario satellite --help
command.
Before You Begin
- Contact your network administrator to ensure that you have the correct settings.
You should have the following information available:
- DHCP IP address ranges
- DHCP gateway IP address
- DHCP nameserver IP address
- DNS information
- TFTP server name
- Use the FQDN instead of the IP address where possible in case of network changes.
Configure DNS, DHCP, and TFTP on Satellite Server
Run
satellite-installer
with the options appropriate for your environment.# satellite-installer --scenario satellite \ --foreman-proxy-dns true \ --foreman-proxy-dns-managed true \ --foreman-proxy-dns-interface eth0 \ --foreman-proxy-dns-zone example.com \ --foreman-proxy-dns-forwarders 172.17.13.1 \ --foreman-proxy-dns-reverse 13.17.172.in-addr.arpa \ --foreman-proxy-dhcp true \ --foreman-proxy-dhcp-managed true \ --foreman-proxy-dhcp-interface eth0 \ --foreman-proxy-dhcp-range "172.17.13.100 172.17.13.150" \ --foreman-proxy-dhcp-gateway 172.17.13.1 \ --foreman-proxy-dhcp-nameservers 172.17.13.2 \ --foreman-proxy-tftp true \ --foreman-proxy-tftp-managed true \ --foreman-proxy-tftp-servername $(hostname)
For more information about configuring DHCP, DNS, and TFTP services, see the Configuring Network Services section in the Provisioning Guide.
The script displays its progress and writes logs to
/var/log/foreman-installer/satellite.log
. You can view the settings used, including theadmin_password
parameter, in the/etc/foreman-installer/scenarios.d/satellite-answers.yaml
file.
Any changes to the settings require running satellite-installer again. You can run the script multiple times and it updates all configuration files with the changed values.
3.9. Disabling DNS, DHCP, and TFTP for Unmanaged Networks
If you want to manage TFTP, DHCP, and DNS services manually, you must prevent Satellite from maintaining these services on the operating system and disable orchestration to avoid DHCP and DNS validation errors. However, Satellite does not remove the back-end services on the operating system.
Procedure
To prevent Satellite from maintaining DHCP, DNS, and TFTP services on the operating system, and disable orchestration, complete the following steps:
On Satellite Server, enter the following command:
# satellite-installer --foreman-proxy-dhcp false \ --foreman-proxy-dns false \ --foreman-proxy-tftp false
- In the Satellite web UI, navigate to Infrastructure > Subnets and select a subnet.
- Click the Capsules tab and clear the DHCP Capsule, TFTP Capsule, and Reverse DNS Capsule fields.
- Navigate to Infrastructure > Domains and select a domain.
- Clear the DNS Capsule field.
Optional: If you use a DHCP service supplied by a third party, configure your DHCP server to pass the following options:
Option 66: IP_address_of_Satellite_or_Capsule Option 67: /pxelinux.0
For more information about DHCP options, see RFC 2132.
Satellite 6 does not perform orchestration when a Capsule is not set for a given subnet and domain. When enabling or disabling Capsule associations, orchestration commands for existing hosts can fail if the expected records and configuration files are not present. When associating a Capsule to turn orchestration on, make sure the required DHCP and DNS records as well as the TFTP files are in place for the existing Satellite hosts in order to prevent host deletion failures in the future.
3.10. Configuring Satellite Server for Outgoing Emails
To send email messages from Satellite Server, you can use either an SMTP server, or the sendmail
command.
Prerequisites
If you have upgraded from a previous release, rename or remove the configuration file /usr/share/foreman/config/email.yaml
and restart the httpd
service. For example:
# mv /usr/share/foreman/config/email.yaml \ /usr/share/foreman/config/email.yaml-backup # systemctl restart httpd
To Configure Satellite Server for Outgoing Emails:
-
In the Satellite web UI, navigate to Administer
Settings. Click the Email tab and set the configuration options to match your preferred delivery method. The changes have an immediate effect.
The following example shows the configuration options for using an SMTP server:
Table 3.1. Using an SMTP server as a delivery method Name Example value Delivery method
SMTP
SMTP address
smtp.example.com
SMTP authentication
login
SMTP HELO/EHLO domain
example.com
SMTP password
password
SMTP port
25
SMTP username
satellite@example.com
The
SMTP username
andSMTP password
specify the login credentials for the SMTP server.The following example uses gmail.com as an SMTP server:
Table 3.2. Using gmail.com as an SMTP server Name Example value Delivery method
SMTP
SMTP address
smtp.gmail.com
SMTP authentication
plain
SMTP HELO/EHLO domain
smtp.gmail.com
SMTP enable StartTLS auto
Yes
SMTP password
password
SMTP port
587
SMTP username
user@gmail.com
The following example uses the
sendmail
command as a delivery method:Table 3.3. Using sendmail as a delivery method Name Example value Delivery method
Sendmail
Sendmail arguments
-i -t -G
The
Sendmail arguments
specify the options passed to thesendmail
command. The default value is-i -t
. For more information see the sendmail 1 man page.
If you decide to send email using an SMTP server which uses TLS authentication, also perform one of the following steps:
Mark the CA certificate of the SMTP server as trusted. To do so, execute the following commands on Satellite Server:
# cp mailca.crt /etc/pki/ca-trust/source/anchors/ # update-ca-trust enable # update-ca-trust
Where
mailca.crt
is the CA certificate of the SMTP server.-
Alternatively, in the web UI, set the
SMTP enable StartTLS auto
option toNo
.
-
Click Test email to send a test message to the user’s email address to confirm the configuration is working. If a message fails to send, the web UI displays an error. See the log at
/var/log/foreman/production.log
for further details.
For information on configuring email notifications for individual users or user groups, see Configuring Email Notifications in Administering Red Hat Satellite.
3.11. Configuring Satellite Server with a Custom Server Certificate
SSL certificates are used to protect information and enable secure communication. Red Hat Satellite 6 creates self-signed SSL certificates to enable encrypted communications between the Satellite Server, external Capsule Servers, and all hosts. Instead of using these self-signed certificates, you can install custom SSL certificates issued by a Certificate Authority which is an external, trusted company. For example, your company might have a security policy stating that SSL certificates must be obtained from a Certificate Authority. To obtain the certificate, create a Certificate Signing Request and send it to the Certificate Authority, as described in Section 3.11.1, “Obtain an SSL Certificate for Satellite Server”. In return, you receive a signed SSL certificate.
To use a custom certificate on Satellite Server, complete these steps:
- Section 3.11.1, “Obtain an SSL Certificate for Satellite Server”
- Section 3.11.2, “Validate the Satellite Server’s SSL Certificate”
- Section 3.11.3, “Run the Satellite Installer with Custom Certificate Parameters”
- Section 3.11.4, “Install the New Certificate on all Hosts Connected to the Satellite Server”
- If you have external Capsule Servers registered to the Satellite Server, proceed to Configuring Capsule Server with a Custom Server Certificate in the Installing Capsule Server guide to configure the Capsule Servers to use a custom certificate.
3.11.1. Obtain an SSL Certificate for Satellite Server
If you already have a custom SSL Certificate for the Satellite Server, skip this procedure.
Use PEM encoding for the SSL Certificates.
Procedure
To obtain custom SSL certificates for Satellite Server, complete the following steps:
Create a directory to store all the source certificate files, accessible only to the
root
user, for example/root/sat_cert
.# mkdir /root/sat_cert
Create a private key with which to sign the Certificate Signing Request (CSR).
Note that the private key must be unencrypted. If you use a password-protected private key, remove the private key password.
If you already have a private key for the Satellite Server, skip this step.
# openssl genrsa -out
/root/sat_cert/satellite_cert_key.pem
4096Create the
/root/sat_cert/openssl.cnf
configuration file for the Certificate Signing Request (CSR) and include the following content. In the[ req_distinguished_name ]
section, enter information about your organization.NoteThe certificate’s Common Name (CN) and the Subject Alternative Name (SAN) DNS.1 must match the fully-qualified domain name (FQDN) of the server on which it is used. If you are requesting a certificate for a Satellite Server, this is the FQDN of Satellite Server. If you are requesting a certificate for a Capsule Server, this is the FQDN of Capsule Server.
To confirm a server’s FQDN, enter the following command on that server:
hostname -f
.[ req ] req_extensions = v3_req distinguished_name = req_distinguished_name x509_extensions = usr_cert prompt = no [ req_distinguished_name ] C = Country Name (2 letter code) ST = State or Province Name (full name) L = Locality Name (eg, city) O = Organization Name (eg, company) OU = The division of your organization handling the certificate CN = satellite.example.com [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection subjectAltName = @alt_names [ usr_cert ] basicConstraints=CA:FALSE nsCertType = client, server, email keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer [ alt_names ] DNS.1 = satellite.example.com
Generate the Certificate Signing Request (CSR):
# openssl req -new \ -key /root/sat_cert/satellite_cert_key.pem \ -out /root/sat_cert/satellite_cert_csr.pem \ -config /root/sat_cert/openssl.cnf
Send the certificate signing request to the Certificate Authority. The same Certificate Authority must sign certificates for Satellite Server and Capsule Server.
When you submit the request, specify the lifespan of the certificate. The method for sending the certificate request varies, so consult the Certificate Authority for the preferred method. In response to the request you can expect to receive a Certificate Authority bundle, and a signed certificate, in separate files.
3.11.2. Validate the Satellite Server’s SSL Certificate
Enter the katello-certs-check
command with the required parameters as per the following example. This validates the input files required for custom certificates and outputs the commands necessary to install them on the Satellite Server, all Capsule Servers, and hosts under management with Satellite.
Validate the custom SSL certificate input files. Change the files' names to match your files. Note that for the
katello-certs-check
command to work correctly, Common Name (CN) in the certificate must match the FQDN of Satellite Server.# katello-certs-check \ -c /root/sat_cert/satellite_cert.pem \ 1 -k /root/sat_cert/satellite_cert_key.pem \ 2 -b /root/sat_cert/ca_cert_bundle.pem 3
3.11.3. Run the Satellite Installer with Custom Certificate Parameters
Now that you have created an SSL certificate and verified it is valid for use with Red Hat Satellite 6, the next step is to install the custom SSL certificate on the Satellite Server and all its hosts.
There is a minor variation to this step, depending on whether or not the Satellite Server is already installed. If it is already installed, the existing certificates must be updated with those in the certificates archive.
The commands in this section are output by the katello-certs-check
command, as detailed in Section 3.11.2, “Validate the Satellite Server’s SSL Certificate”, and can be copied and pasted into a terminal.
Enter the
satellite-installer
command, depending on your situation:If Satellite is already installed, enter the following command on the Satellite Server:
# satellite-installer --scenario satellite \ --certs-server-cert /root/sat_cert/satellite_cert.pem \ --certs-server-key /root/sat_cert/satellite_cert_key.pem \ --certs-server-ca-cert /root/sat_cert/ca_cert_bundle.pem \ --certs-update-server --certs-update-server-ca
Important parameters in this command include
--certs-update-server
and--certs-update-server-ca
, which specify that the server’s SSL certificate and certificate authority are to be updated. For a brief description of all the installer’s parameters, enter the command:satellite-installer --scenario satellite --help
.NoteFor all files in the
satellite-installer
command, use full path names, not relative path names. The installer records all files' paths and names, and if you enter the installer again, but from a different directory, it may fail as it is unable to find the original files.If Satellite is not already installed, enter the following command on the Satellite Server:
# satellite-installer --scenario satellite \ --certs-server-cert /root/sat_cert/satellite_cert.pem \ --certs-server-key /root/sat_cert/satellite_cert_key.pem \ --certs-server-ca-cert /root/sat_cert/ca_cert_bundle.pem
NoteFor all files in the
satellite-installer
command, use full path names, not relative path names. The installer records all files' paths and names, and if you enter the installer again, but from a different directory, it may fail as it is unable to find the original files.
-
Verify the certificate has been successfully installed on the Satellite Server before installing it on hosts. On a computer with network access to the Satellite Server, start a web browser, navigate to the URL
https://satellite.example.com
and view the certificate’s details.
3.11.4. Install the New Certificate on all Hosts Connected to the Satellite Server
Now that the custom SSL certificate has been installed on the Satellite Server, it must also be installed on every host registered to the Satellite Server.
Until BZ#1683835 is resolved, you cannot upgrade the katello-ca-consumer
package; you must remove the old package and install the new one. Upgrading the katello-ca-consumer
package fails because the upgrade reverts the baseurl
setting in rhsm.conf
to subscription.rhsm.redhat.com
.
Procedure
Enter the following commands on all applicable hosts.
Delete the current
katello-ca-consumer
package on the host.# yum remove 'katello-ca-consumer*'
Install the custom SSL certificate on the host.
# yum localinstall http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
3.12. Using External Databases with Satellite
As part of the installation process for Red Hat Satellite, the satellite-installer command installs MongoDB and PostgreSQL databases on the same server as Satellite. In certain Satellite deployments, using external databases can help with the server load. However, there are many factors that can affect Satellite Server’s performance. Moving to an external database might not help your specific problem.
Depending on your requirements, you can use external databases for either MongoDB or PostgreSQL database, or both.
Red Hat does not provide support or tools for external database maintenance. This includes backups, upgrades, and database tuning. Customers using an external database require their own database administrator to support and maintain the database.
If your Satellite deployment requires external databases, use the following information to set up and point to external databases from Satellite.
FIPS-related Restrictions
Until BZ#1743706 is resolved, you cannot use an external MongoDB with Satellite in FIPS mode.
3.12.1. MongoDB as an External Database Considerations
Pulp uses the MongoDB database. If you want to use MongoDB as an external database, the following information can help you discern if this option is right for your Satellite configuration.
Advantages of External MongoDB
- Increase in free memory and free CPU on Satellite
- Flexibility to tune the MongoDB server’s system without adversely affecting Satellite operations
Disadvantages of External MongoDB
- Increase in deployment complexity that can make troubleshooting more difficult
- An external MongoDB server is an additional system to patch and maintain
- If either the Satellite or the Mongo database server suffers a hardware or storage failure, Satellite is not operational
- If there is latency between the Satellite and the external database server, performance can suffer
If you suspect that your Mongo database is slow, you can work with Red Hat Support to troubleshoot. You might be encountering a configuration problem or existing performance problems with Satellite 6 that moving to an external database server might not help. Red Hat Support can examine existing known issues and also work with the Satellite Engineering team to determine the root cause.
3.12.2. PostgreSQL as an External Database Considerations
Foreman, Katello, and Candlepin use the PostgreSQL database. If you want to use PostgreSQL as an external database, the following information can help you discern if this option is right for your Satellite configuration.
Advantages of External PostgreSQL:
- Increase in free memory and free CPU on Satellite
-
Flexibility to set
shared_buffers
on the PostgreSQL database to a high number without the risk of interfering with other services on Satellite - Flexibility to tune the PostgreSQL server’s system without adversely affecting Satellite operations
Disadvantages of External PostgreSQL
- Increase in deployment complexity that can make troubleshooting more difficult
- The external PostgreSQL server is an additional system to patch and maintain
- If either Satellite or the PostgreSQL database server suffers a hardware or storage failure, Satellite is not operational
- If there is latency between the Satellite server and database server, performance can suffer
If you suspect that the PostgreSQL database on your Satellite is causing performance problems, use the information in Satellite 6: How to enable postgres query logging to detect slow running queries to determine if you have slow queries. Queries that take longer than one second are typically caused by performance issues with large installations, and moving to an external database might not help. If you have slow queries, contact Red Hat Support.
3.12.3. Overview
To create and use a remote database for Satellite, you must complete the following procedures:
- Use Section 1.2, “Storage Requirements and Guidelines” to plan the storage requirements for your external databases
- Prepare PostgreSQL with databases for Foreman and Candlepin and dedicated users owning them
-
Prepare MongoDB with user
pulp
owning thepulp_database
- Follow the initial steps to install Satellite and ensure that the databases are accessible from Satellite
-
Edit the parameters of
satellite-installer
to point to the new databases, and runsatellite-installer
Preparing Red Hat Enterprise Linux Server 7 for Database Installation
You require a freshly provisioned system with the latest Red Hat Enterprise Linux Server 7 that meets the storage requirements from Section 1.2, “Storage Requirements and Guidelines”.
Subscriptions for Red Hat Software Collections and Red Hat Enterprise Linux do not provide the correct service level agreement for using Satellite with external databases. You must also attach a Satellite subscription to the base system that you want to use for the external database.
- Use the instructions in Identifying and Attaching the Satellite Subscription to the Host to attach a Satellite subscription to your server.
To install MongoDB and PostgreSQL servers on Red Hat Enterprise Linux Server 7, you must disable all repositories and enable only the following repositories:
# subscription-manager repos --disable '*' # subscription-manager repos --enable=rhel-server-rhscl-7-rpms \ --enable=rhel-7-server-rpms
3.12.4. Installing MongoDB
You can install only the same version of MongoDB that is installed with the satellite-installer
tool during an internal database installation. You can install MongoDB using Red Hat Software Collections (RHSCL) repositories or from an external source, as long as the version is supported. Satellite supports MongoDB version 3.4.
To install MongoDB, enter the following command:
# yum install rh-mongodb34 rh-mongodb34-syspaths
Start and enable the rh-mongodb34 service:
# systemctl start rh-mongodb34-mongod # systemctl enable rh-mongodb34-mongod
Create a Pulp user on MongoDB for database pulp_database:
# mongo pulp_database \ --eval "db.createUser({user:'pulp',pwd:'pulp_password',roles:[{role:'dbOwner', db:'pulp_database'},{ role: 'readWrite', db: 'pulp_database'}]})"
In the
/etc/opt/rh/rh-mongodb34/mongod.conf
file, specify the bind IP:bindIp: your_mongodb_server_bind_IP,::1
Edit the
/etc/opt/rh/rh-mongodb34/mongod.conf
file to enable authentication in thesecurity
section:security: authorization: enabled
Restart the
rh-mongodb34-mongod
service:# systemctl restart rh-mongodb34-mongod
Open port 27017 for MongoDB:
# firewall-cmd --add-port=27017/tcp # firewall-cmd --runtime-to-permanent
From Satellite Server, test that you can access the database. If the connection succeeds, the command returns
1
.# scl enable rh-mongodb34 " mongo --host mongo.example.com \ -u pulp -p pulp_password --port 27017 --eval 'ping:1' pulp_database"
3.12.5. Installing PostgreSQL
You can install only the same version of PostgreSQL that is installed with the satellite-installer
tool during an internal database installation. Satellite supports only a specific version of PostgreSQL that is available through Red Hat Enterprise Linux Server 7 repositories. You can install PostgreSQL using rhel-7-server-rpms repositories or from an external source, as long as the version is supported. For more information about the repository that contains the supported version of PostgreSQL, and what version is supported, see the Package Manifest.
To install PostgreSQL, enter the following command:
# yum install postgresql-server
To initialize, start, and enable PostgreSQL service, enter the following commands:
# postgresql-setup initdb # systemctl start postgresql # systemctl enable postgresql
Edit the
/var/lib/pgsql/data/postgresql.conf
file:# vi /var/lib/pgsql/data/postgresql.conf
Remove the
#
and edit to listen to inbound connections:listen_addresses = '*'
Edit the
/var/lib/pgsql/data/pg_hba.conf
file:# vi /var/lib/pgsql/data/pg_hba.conf
Add the following line to the file:
host all all satellite_server_ip/24 md5
Restart PostgreSQL service to update with the changes:
# systemctl restart postgresql
Open the postgresql port on the external PostgreSQL server:
# firewall-cmd --add-service=postgresql # firewall-cmd --runtime-to-permanent
Switch to the
postgres
user and start the PostgreSQL client:$ su - postgres -c psql
Create two databases and dedicated roles, one for Satellite and one for Candlepin:
CREATE USER "foreman" WITH PASSWORD 'Foreman_Password'; CREATE USER "candlepin" WITH PASSWORD 'Candlepin_Password'; CREATE DATABASE foreman OWNER foreman; CREATE DATABASE candlepin OWNER candlepin;
From Satellite Server, test that you can access the database. If the connection succeeds, the commands return
1
.# PGPASSWORD='Foreman_Password' psql -h postgres.example.com -p 5432 -U foreman -d foreman -c "SELECT 1 as ping" # PGPASSWORD='Candlepin_Password' psql -h postgres.example.com -p 5432 -U candlepin -d candlepin -c "SELECT 1 as ping"
To install and configure the remote database for Satellite, enter the following command:
satellite-installer --scenario satellite \ --foreman-db-host postgres.example.com \ --foreman-db-password Foreman_Password \ --foreman-db-database foreman \ --katello-candlepin-db-host postgres.example.com \ --katello-candlepin-db-name candlepin \ --katello-candlepin-db-password Candlepin_Password \ --katello-candlepin-manage-db false \ --katello-pulp-db-username pulp \ --katello-pulp-db-password pulp_password \ --katello-pulp-db-seeds mongo.example.com:27017 \ --katello-pulp-db-name pulp_database
You can query the status of your databases. For example, enter the following command with the --only
and add postgresql
or rh-mongodb34-mongod
:
For PostgreSQL, enter the following command:
# satellite-maintain service status --only postgresql
For MongoDB, enter the following command:
# satellite-maintain service status --only rh-mongodb34-mongod
3.13. Restricting Access to mongod
Only the apache
and root
users should be allowed access to the MongoDB database daemon, mongod
, to reduce the risk of data loss.
Restrict access to mongod
on Satellite and Capsule Servers using the following commands.
Configure the Firewall.
# firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 27017 -j DROP \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 27017 -j DROP \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 28017 -j DROP \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 28017 -j DROP
Make the changes persistent:
# firewall-cmd --runtime-to-permanent