Red Hat Satellite 6.2.15 includes bug fixes for improving the performance of Satellite 6.2.x.
There is one erratum for the server [1] and one for the hosts [2].
ISOs should be published next week.

Customers who have already upgraded to 6.2 should follow the instructions in the errata. Customers who are on 6.1.x should follow the upgrade instructions in the Satellite 6.2 Installation Guide. Customers who have received hotfixes should verify the list below to ensure their hotfix is contained in the release before upgrading. Please reach out to Red Hat Support in these cases.

Fixes included in 6.2.15

This update fixes the following bugs:

• TLS 1.2 is now enabled by default on Satellite 6.2. (BZ#1331041, BZ#1548093)
• Performance problems with registration, such as concurrent registrations and task blocking have been improved based on work with larger customers. (BZ#1490019, BZ#1514508, BZ#1553845)
• A new dispatch router has been released to fix a segmentation fault caused by long running use. (BZ#1535891)
• Performance problems with the katello-errata query have been improved and backported to Satellite 6.2. (BZ#1518804)
• Performance problems with memory consumption when searching for an unqualified hostgroup have been improved and backported to Satellite 6.2. (BZ#1547986)
• Performance problems with the subscription page when the user has a large volume of hosts have been improved and backported to Satellite 6.2. (BZ#1551674)
• Restarting a pulp worker with running tasks caused the tasks to be in a broken state. This problem has been fixed. In such cases, tasks are stopped with warning "Task cancelled". This fix has been backported to Satellite 6.2. (BZ#1526437)
• Synchronization tasks that were interrupted by Satellite restarting were not completing. This is now fixed and has been backported to Satellite 6.2. (BZ#1548167)
• The foreman-debug tool has been updated to collect the foreman-maintain logs. This improves the ability to analyze problems during upgrades. (BZ#1542407)
• The katello-backup tool can now use relative paths. (BZ#1544396)
• Users received errors when they created hosts using hammer with two network interfaces if eth0 was not the primary interface. This is now fixed. (BZ#1417053)
• Users were not able to manage their own taxonomies. This functionality has been enabled. (BZ#1476843)
• Custom products created for RHEL5 were not using the correct checksum type. SHA1 is now used for these repositories. (BZ#1480694)

Users of Red Hat Satellite are advised to upgrade to these updated packages, which fix these bugs.

[1] https://access.redhat.com/errata/RHBA-2018:1672

[2] https://access.redhat.com/errata/RHBA-2018:1673

Satellite Migration from RHEL 6 to RHEL 7

As a reminder, Red Hat continues to strongly recommend your Satellite and Capsule Servers only be run on RHEL 7. There are several reasons why you should move your Satellite environment from RHEL 6 to RHEL 7 including enhanced performance and long-term supportability.

Future releases of Satellite (6.3 and above) will only support RHEL 7 and above.

In preparation for newer versions of Satellite, you need to start thinking about how to move from older versions of RHEL to RHEL 7.
While RHEL 6 does support an in-place migration from RHEL 6 to RHEL 7, this migration mechanism is not supported when running Satellite on the RHEL host. Instead, you will need to clone your Satellite environment from a host running RHEL 6 to another host running RHEL 7.
Review the Satellite 6.2.13 release blog for more detailed information about moving your Satellite environment from RHEL 6 to RHEL 7. 6.2.13 includes some important features for capsule backup and recovery which helps to ease the movement from RHEL 6 to RHEL 7.

Have you completed your migration from Satellite 5 to Satellite 5.8, but you keep getting messages from us about upgrading before January 31, 2019?

It could be that your systems are still registered with Red Hat Network (RHN), even if you have moved to a newer version.

Let's walk through a couple steps to show you how you can check and see if you are registered with RHN or Red Hat Subscription Manager (RHSM).

I moved to Satellite 6 - Does this affect me?

If you have moved off of Satellite 5 to Satellite 6, and you have shut down all Satellite 5 systems, then this article does not impact you. Satellite 6 cannot be registered to RHN. However, if you still have Satellite 5 systems in your environment please verify that they have been upgraded to Satellite 5.8 and have moved to RHSM.

Why are these steps important?

As of January 31, 2019 the RHN connector that Satellite 5.7 and older uses to get content will be completely shut down. After this date NO CONTENT will be available through RHN. Both system level updates and channel syncing will be stopped as a result.

Satellite 5.8 and Satellite 6 uses RHSM instead of RHN, so this shutdown does not impact those versions.

What happens to my Satellite 5.7 or older server after January 31, 2019?

Red Hat STRONGLY recommends an upgrade to Satellite 5.8 prior to 31-Jan-2019. However, if the Satellite is not upgraded,

You WILL

• Be able to use the Satellite 5.7 (or lower) with previously downloaded content.
• Be able to receive updates for the underlying OS (if registered via RHSM)
• Receive support from CEE to upgrade to 5.8.

You WILL NOT

• Receive updates for (and be able to synchronize) any channels previously synced via Satellite 5.
• Receive updates for the underlying OS (if registered via RHN)
• Receive help for anything else Satellite related other than upgrading to Satellite 5.8.

I have not moved to Satellite 5.8 OR I have installed Satellite 5.8 but have not migrated to RHSM. What do I do?

If you are looking to start the process of migrating from RHN to RHSM, follow the instructions in the article: "Preparing Satellite 5 systems for Red Hat Network's End of Life."

How could I be registered to both RHN and RHSM?

If you had a Satellite system that was registered with RHN, and you upgraded your environment to Satellite 5.8 and manually registered with RHSM, then you might be double registered.
However, if you used the rhn-migrate-classic-to-rhsm command then you should have been properly registered with RHSM and removed from RHN.

How can I check if I am double registered to both RHN and RHSM?

Verify that you are connected to RHSM

The first thing you should do if verify that your subscription-manager status is current:

# subscription-manager status 
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Current

Next, Look at the list of consumed subscriptions to verify that you have a Red Hat Satellite subscription attached to the system:

# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   Red Hat Satellite 
Provides:            Red Hat Satellite
                            Red Hat Satellite Capsule

Verify that you are NOT connected to RHN

To confirm that the system is not also registered to RHN as well as RHSM, use the yum repolist command to verify that the rhnplugin is NOT present:

# yum repolist 
Loaded plugins: product-id, search-disabled-repos, security, subscription-manager 
repo id                                                               repo name                                                           status
rhel-6-server-rpms                            Red Hat Enterprise Linux 6 Server (RPMs)                20,029
rhel-6-server-satellite-5.7-rpms      Red Hat Satellite 5.7 (for RHEL 6 Server) (RPMs)           736

1. Notice the line starting with Loaded plugins:, there should not be rhnplugin loaded in the above yum command output.
2. RHSM repositories end with rpms, so all the repo id's listed in above yum command output should end with rpms.

Many of these details are covered in the solution: How to verify whether Red Hat Satelite v 5.x server is successfully migrated from RHN Hosted to RHSM?

Worried about your upcoming Satellite upgrade? Don’t be.

In addition to our detailed upgrade documentation, our support team has been through hundreds of upgrades and they’re happy to help if something deviates from your expectations. In order to optimize your upgrade experience if you chose to engage our support team, please submit what we call a “Proactive Support Case” ahead of your planned upgrade window.

Why should you do this? This will allow for an experienced Satellite support professional to be on-call and/or aware of your plans so they can quickly assist or help triage any issues you could see, as well as minimizing logistics in the event that a problem does occur since a case is already open.

On average, most planned upgrades within a major release, for example from Satellite 5.7 to Satellite 5.8 or Satellite 6.2 to Satellite 6.3, are able to be completed within a 4-8 hour maintenance window and many are completed well under that time estimate.

Here’s how you can submit a proactive support ticket:

Note: In order for our support team to properly prepare for a proactive support ticket we require some time to review the case and staff appropriately to make sure we have someone available to assist.

• For support during normal business hours: Proactive support cases that need coverage during normal business hours should be opened at least 48 hours prior to the upgrade event.

• For support during the weekend: Proactive support cases that need weekend coverage should be opened at least 4 days prior to the weekend of the upgrade.
  For example, If you plan to upgrade this weekend your support ticket will need to be in by close of business Tuesday in order to be proactively supported.

1. Open a case providing information about the upcoming upgrade from Satellite 5.x to Satellite 5.8.

   • Access Red Hat Customer Portal
   • Access Support > Support Cases > Open a New Support Case > Open Case
   • Fill in the forms, describing the planned upgrade
   • Include notation “proactive case”

   • Include Environment information for all impacted components:

     • SOS Report
     • Time/Date of planned upgrade window
     • For Satellite 6 include:
       • How many Satellite and Capsule Servers are in use
       • Are any of the above using the disconnected model? If so, how many?
       • Output from Foreman-debug
     • For Satellite 5 include:
       • How many Satellite and Proxy Servers are in use
       • Are any of the above using the disconnected model? If so, how many?
       • Output of spacewalk-debug
       • Output of: rhn-satellite status
       • Output of rhn-schema-version
       • Output of database-schema-version
       • If the environment was previously upgraded include the schema-upgrade-log
       • Contents of: /etc/rhn/rhn.conf

   • Include any additional information that would assist troubleshooting

   • Submit the case
2. Notify TAM/CSM team of the proactive case
   • Notify TAM/CSM of case #
   • Use support number, if needed, to raise awareness (1-888-467-3342)
3. Case will be flagged within Red Hat to be monitored for potential actions
4. Post upgrade: work with TAM/support team to ensure case is closed

Customers who submit a proactive support ticket are still asked to follow the upgrade documentation very carefully as that is still the single best source for guidance on your Satellite upgrades. However, our support professionals have seen their fair share of “edge cases” and exceptions and they can help close any gap quickly if they see any potential challenges.

Staying on Satellite 5? Get to Satellite 5.8 ASAP!

Are you a Satellite customer running Satellite 5.7 or earlier version?
Hopefully by now you've heard about RHN shutting down on January 31, 2019. This means that after January 31, 2019 your Satellite Server will no longer be able to download new content.
To protect yourself and to be sure that you can continue to access content you need to upgrade your Satellite environment to Satellite 5.8.

On Satellite 5 and ready to move to Satellite 6 but want more help?

Red Hat has recently released a consulting offering for Satellite 5 to Satellite 6 transition. Contact your account team for more details.

Red Hat Satellite 6.2.14 includes fixes for performance improvements and stability, as well as upgrade enhancements to make it easier to upgrade Satellite 6.2 to the upcoming Satellite 6.3 release.
There is one erratum for the server [1] and one for the hosts [2]. The install ISOs will be updated later this week.

Customers who have already upgraded to 6.2 should follow the instructions in the errata. Customers who are on 6.1.x should follow the upgrade instructions in the Satellite 6.2 Installation Guide. Customers who have received hotfixes should verify the list below to ensure their hotfix is contained in the release before upgrading. Please reach out to Red Hat Support in these cases.

Fixes included in 6.2.14

Security Fixes:

• It was discovered that python-twisted-web used the value of the Proxy header from HTTP requests to initialize the HTTP_PROXY environment variable for CGI scripts, which in turn was incorrectly used by certain HTTP client implementations to configure the proxy for outgoing HTTP requests. A remote attacker could possibly use this flaw to redirect HTTP requests performed by a CGI script to an attacker-controlled proxy via a malicious HTTP request. (CVE-2016-1000111)

Bugs:

• Upgrades from Satellite 6.2 to Satellite 6.3 were failing due to the use of certificates with custom authorities. These upgrade paths now work. (BZ#1523880, BZ#1527963)
• Additional tooling is provided to support data validation when upgrading from Satellite 6.2 to Satellite 6.3. (BZ#1519904)
• Several memory usage bugs in goferd and qpid have been resolved. (BZ#1319165, BZ#1318015, BZ#1492355, BZ#1491160, BZ#1440235)
• The performance of Puppet reporting and errata applicability has been improved. (BZ#1465146, BZ#1482204)
• Upgrading from 6.2.10 to 6.2.11 without correctly stopping services can cause the upgrade to fail on removing qpid data. This case is now handled properly. (BZ#1482539)
• The cipher suites for the Puppet server can now be configured by the installation process. (BZ#1491363)
• The default cipher suite for the Apache server is now more secure by default. (BZ#1467434)
• The Pulp server contained in Satellite has been enhanced to better handle concurrent processing of errata applicability for a single host and syncing Puppet repositories. (BZ#1515195, BZ#1421594)
• VDC subscriptions create guest pools which are for a single host only. Administrators were attaching these pools to activation keys which was incorrect. The ability to do this has been disabled. (BZ#1369189)
• Satellite was not susceptible to RHSA-2016:1978 but security scanners would incorrectly flag this as an issue. The package from this errata is now delivered in the Satellite channel to avoid these false positives. (BZ#1497337)
• OpenScap report parsing resulted in a memory leak. This leak has been fixed. (BZ#1454743)
• The validation on the length of names for docker containers and repositories was too restrictive. Names can now be longer. (BZ#1424689)
• Goferd continues to leak memory when qdrouterd is not accessible. Was supposedly fixed as per bz 1260963 (BZ#1318015)

Users of Red Hat Satellite are advised to upgrade to these updated packages, which fix these bugs.

[1] https://access.redhat.com/errata/RHSA-2018:0273

[2] https://access.redhat.com/errata/RHBA-2018:0272

Satellite Migration from RHEL 6 to RHEL 7

As a reminder, Red Hat continues to strongly recommend your Satellite and Capsule Servers only be run on RHEL 7. There are several reasons why you should move your Satellite environment from RHEL 6 to RHEL 7 including enhanced performance and long term supportability.

Future releases of Satellite (6.3 and above) will only support RHEL 7 and above. In preparation for newer versions of Satellite you need to start thinking about how to move from older versions of RHEL to RHEL 7.
While RHEL 6 does support an in-place migration from RHEL 6 to RHEL 7, this migration mechanism is not supported when running Satellite on the RHEL host. Instead you will need to clone your Satellite environment from a host running RHEL 6 to another host running RHEL 7 .
Review the Satellite 6.2.13 release blog for more detailed information about moving your Satellite environment from RHEL 6 to RHEL 7. 6.2.13 includes some important features for capsule backup and recovery which helps to ease the movement from RHEL 6 to RHEL 7.