Warning message

Log in to add comments.

The Satellite Blog is a place for the Engineering team to publish tips and tricks about how to use our products, videos which showcase new features, and to point users at new content on the Customer Portal.

Latest Posts

  • What you need to know to be ready for Satellite 6.4 and Puppet 5

    Authored by: John Spinks

    As we work towards a Satellite 6.4 release this fall there are some very important changes to Puppet that are coming that the Satellite team wants to prepare you for.

    Note: This affects ALL Satellite 6.3 users, even if you are not using Puppet or if you are using Puppet Enterprise.

    The last few releases of Satellite have supported Puppet 3.8, a version which has been end-of-life since December 31, 2016.
    Satellite 6.3 introduced support for Puppet 4, but since there were some major changes on the Puppet side between Puppet 3.8 and Puppet 4, Satellite 6.3 supported both versions.
    But Puppet 4 is also rapidly approaching its end-of-life date, expected around October 2018.

    The upcoming release of Satellite 6.4 will only support Puppet 5.
    This is because the other versions that we mentioned, Puppet 3.8 and Puppet 4, will both be end-of-life (or near end-of-life) by the time of the Satellite 6.4 release date.

    In order to upgrade to Satellite 6.4 from Satellite 6.3, you must first make sure that you have upgraded your Satellite 6.3 environment to Puppet 4.
    If you try to upgrade from Satellite 6.3 with Puppet 3.8 the installed is expected to fail in order to ensure that the Puppet upgrade is also successful.

    This is true even if you don't actively use Puppet.
    For customers that have upgraded to Satellite 6.3, Puppet is not automatically upgraded to Puppet 4. This is because of the significant changes that Puppet has made between releases.

    If you are a Puppet Enterprise user or you do not leverage the Puppet capabilities included with Satellite, this still impacts you too.
    However, it should just be a simple upgrade of Puppet that is built into
    Satellite, and should not affect your Puppet Enterprise operations.

    Once you have made sure any Puppet scripts will work as expected, the upgrade itself from Puppet 3.8 to Puppet 4 is quite easy.
    Enable the Puppet4 repos, then run the "satellite-installer" command with the "--upgrade-puppet" option. Full instructions are below.

    If you haven't already started moving to Satellite 6.3, the feedback has been fantastic. It is a great release, and if you are running an older version of Satellite 6 we would encourage you to upgrade to Satellite 6.3 soon. While you're at it, upgrade to Puppet 4.

    If you aren't leveraging Puppet in Satellite, then this shouldn't concern you much and it should be an easy upgrade (but you still need to do it).
    However, if you are a heavy Puppet user, and are using the Puppet shipped as part of Satellite, it should be noted that Puppet changed significantly between versions 3.8 and 4. As a result, you should plan to test any of your Puppet based modules to be sure that they work properly after the upgrade.
    Moving from Puppet 4 to 5 is much simpler and should require little changes to any of your modules.

    Here are some resources that we thought would be particularly helpful when planning the upgrade from Puppet 3.8 to Puppet 4.

    Hopefully, these resources will help to get your Satellite 6.3 environment updated to Puppet 4.

    Once you are at Satellite 6.3 and Puppet 4 you will be ready to upgrade to Satellite 6.4 and Puppet 5 when it is released this fall.

    Posted: 2018-06-26T22:49:49+00:00
  • Satellite 6.3.2 is now available

    Authored by: John Spinks

    Satellite 6.3.2 has just been released.
    The main driver for the 6.3.2 release is allowing customers to disable weak ciphers, but there are several other new features and fixes.
    There are two errata for the server [1][3] and one
    for the hosts [2]. The install ISOs will be updated later this week.

    Customers who have already upgraded to Satellite 6.3 should follow the instructions in the errata.
    Customers who are on older versions of Satellite should refer to the Upgrading and Updating Red Hat Satellite Guide.

    You may also want to consider using the Satellite Upgrade Helper if moving from Satellite 6.x to Satellite 6.3

    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.

    This update fixes the following bugs:

    • Users can now disable weak ciphers across Satellite 6's series of
      services and restrict to only TLS 1.2. For more information, see How to
      disable weak encryption (SSL 2.0 and SSL 3.0) on Red Hat Satellite:
      https://access.redhat.com/solutions/26833 (BZ#1553875, BZ#1318973)

      NOTE: If you are still using RHEL 5 Servers note that restricting communications to only TLS 1.2 will prevent RHEL5 from communicating with Satellite. Refer to Known Issues and Attacks Against SSL/TLS in OpenSSL/NSS/gnutls on Red Hat Enterprise Linux 5 for full details about supported TLS versions with RHEL 5.

    • The foreman-debug command now collects additional information to help
      with debugging, including passenger statistics. (BZ#1540493, BZ#1558545)

    • Satellite 6.3 could not sync containers from the Google or Quay
      registry because of differences in version 2 of the API. Satellite now
      supports these differences. (BZ#1555165)

    • Performance improvements, which arose from experiences with customer
      upgrades, are now available for the UI and CLI. (BZ#1511503, BZ#1567978,
      BZ#1553263, BZ#1560740, BZ#1563002, BZ#1575113)

    • Certain future-dated subscriptions could not be enabled based on the
      products they enable. This is now fixed. (BZ#1553264)

    • Authentication for OpenStack v3 was failing because Satellite did not
      use the domain field. This is now fixed. (BZ#1513932)

    • Problems that relate to migrating and upgrading, for example the
      content_source_id not migrating and template history disappearing, are
      now fixed. (BZ#1584874, BZ#1559108)

    • Intermittent segmentation faults in the Pulp stack are now fixed.
      (BZ#1516481)

    • Provisioning templates in RHEV 3.6 ignored the disk settings specified
      in the template. This is now fixed. (BZ#1399102)

    • The boot disk provisioning option was omitted from the hammer host
      create command. This is now fixed. (BZ#1544498)

    • Remote execution failed on host collections. This is now fixed.
      (BZ#1553017)

    • Intermittent segmentation faults in the qpid stack are now fixed.
      (BZ#1561819)

    • The initial remote execution command after a restart failed with the
      error message: "Could not use any Capsule". This is now fixed. (BZ#1558069)

    • Pulp workers became deadlocked when the PULP_MAX_TASKS_PER_CHILD setting was enabled. These workers now reconnect correctly. (BZ#1590906)

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

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

    [3]https://access.redhat.com/errata/RHBA-2018:1956

    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.

    Posted: 2018-06-20T07:04:16+00:00
  • Satellite 6.2.15 is now available

    Authored by: John Spinks

    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.

    Posted: 2018-05-23T11:23:32+00:00
  • Go West, [not so] young Spinks: One Satellite member’s guide to Red Hat Summit 2018

    Authored by: John Spinks

    Greetings!

    I’m John Spinks, Technical Marketing Manager for Satellite.
    While I’m relatively new to Red Hat, I get to work with Red Hat Satellite engineers and customers every day. Next week is my first Red Hat Summit so I’m excited to get to see so many of both in one place.

    Not only is this my first Summit as an attendee, I’m honored to say that this will also be my first time at Summit as a speaker. Brent Midwood and I will be presenting the session: Live Demonstration: Find it. Fix it. Before it breaks. That has of course captured a lot of my interest of late, but I’m also looking forward to attending some other breakout sessions about how Satellite enables customers and businesses to meet their goals.

    Breakout Sessions

    Summit has a packed and exciting agenda, so I’ve highlighted a few of the sessions and their description from the Summit agenda that I am most interested in attending and that I think will be of great interest to users of Red Hat Satellite:

    Live demonstration: Find it. Fix it. Before it breaks.

    A common saying is, "If it ain’t broke, don't fix it." But what if it is broken and you just don't know it? Waiting for something to break means late nights, lunches at your desk, or waiting for a maintenance window to fix issues. However, there are ways for you to automate how you predict, resolve, and manage issues before they cause you headaches. Read more.

    How Walmart uses systems management tools to manage its massive IT operation at scale

    To power the largest retailer in the world, Walmart’s IT operation must manage systems at unprecedented scale. Walmart’s IT leaders will share how they use various automation tools, including Red Hat Satellite, to give them the capacity they need. Darin Lively, Staff Systems Engineer, and Brian Ameling, Staff Systems Engineer, will offer a look into Walmart’s complex architecture and… Read more.

    A problem's not a problem, until it's a problem (Red Hat Insights)

    Find out how using predictive analytics from Red Hat Insights, you can assess the impact of a potential system issue and the likelihood of it becoming a problem. Read more.

    Red Hat Management roadmap and strategy

    Attend this session to learn the latest on the strategy and roadmap for Red Hat Management, including details on Red Hat Ansible Automation, Red Hat CloudForms, Red Hat Insights, and Red Hat Satellite. Read more.


    If you’re going to Red Hat Summit next week, I encourage you to add these sessions to your agenda now-- before they fill up!

    Automation and Management Booth

    As much as possible I’ll be spending time in the Automation & Management pod in the Red Hat booth during the Ecosystem Expo hours. Please stop by to say “Hello” to me or to any of our Satellite experts and see some demos of Red Hat Satellite 6.3 and some sneak peeks into what’s coming next.


    For those of you fortunate enough to go - safe travels and hope to see you there!
    If you can’t make it I hear that content (slides and recordings) will be posted after Summit at http://redhat.com/summit

    John Spinks
    @jbspinks

    Posted: 2018-05-02T13:10:32+00:00
  • Satellite 5 and RHN End of Life - Making sure that you are only connected to RHSM.

    Authored by: John Spinks

    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?

    Posted: 2018-04-30T13:00:07+00:00
  • Satellite 6.3.1 is now available

    Authored by: John Spinks

    Red Hat Satellite 6.3.1 includes packages that supports Red Hat Enterprise Linux 7.5 as well as a variety of performance enhancements and general bug fixes.

    Especially notable is the improvements in the performance of content views. In our tests we've seen publishing of a single content view on RHEL7 redunce in time by 43% and publishing of composite views reduced 95%. To put numbers to this 6.3.0 took 320 seconds to publish a composite view while 6.3.1 took 14 seconds to publish the same CV.
    Promotion also was significantly improved. A group of 16 CVs were promoted in 977 seconds in 6.3.0 to 5.78 seconds in 6.3.1 - a 99% reduction in time to promote!

    There are two errata for the server [1][3] and one for the hosts [2]. The install ISOs will be updated next week.

    Customers who have already upgrade to Satellite 6.3 should follow the instructions in the errata.
    Customers who are on older versions of Satellite should refer to the Upgrading and Updating Red Hat Satellite Guide.

    You may also want to consider using the Satellite Upgrade Helper if moving from Satellite 6.x to Satellite 6.3

    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.3.1

    • The performance of Content View publishing and promotion has been improved. (BZ#1522912)

    • The performance of Ansible Tower inventory collection has been improved. (BZ#1437197)

    • Various performance and scale improvements have been made. (BZ#1553881, BZ#1553879, BZ#1532348, BZ#1553871)

    • Several upgrade issues from 6.2.x to 6.3 have been resolved. (BZ#1549502, BZ#1547607, BZ#1553279)

    • The installer now allow users to configure the SSL protocols used by Tomcat. (BZ#1544995)

    • Disconnected installations no longer attempt to install the oauth gem from a remote server. (BZ#1541885)

    • Users can now configure custom products not to use an HTTP Proxy when syncing content, and to only use the proxy for Red Hat Content. (BZ#1132980)

    • 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". (BZ#1552118)

    • Puppet modules which were built on MacOS machines can now be imported into Satellite. (BZ#1445625)

    • Previously, an API endpoint used by the SCAP Satellite plug-in failed to provide generated guides based on the selected profile. Consequently, Red Hat Satellite was not able to get information from the plug-in, and the Satellite UI was broken. With this update, handling of the API endpoint has been updated, and it is now possible to generate guides using this API endpoint again. (BZ#1480595)

    • Backups were failing with relative paths since 6.2.13. This regression has been fixed. (BZ#1544401)

    • Pulp workers became deadlocked when the PULP_MAX_TASKS_PER_CHILD setting was enabled. These workers now reconnect correctly. (BZ#1590906)

    • When installing the katello-ca-consumer package, the script restarted Docker. Consequently, running containers where stopped. With this update, the Docker service is reloaded not restarted. (BZ#1518289)

    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:1126
    [2] https://access.redhat.com/errata/RHBA-2018:1127
    [3]https://access.redhat.com/errata/RHBA-2018:1956

    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.

    Posted: 2018-04-13T14:43:30+00:00
  • Preparing to Upgrade Satellite? Open a Proactive Support Case.

    Authored by: John Spinks

    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.

    Posted: 2018-04-11T16:33:49+00:00
  • Satellite 6.3 is now available

    Authored by: John Spinks

    Red Hat Satellite 6.3 is now available.

    Red Hat is pleased to announce the general availability of Red Hat Satellite 6.3. The latest release increases product stability and usability, and introduces new and enhanced features designed to meet user needs.

    Key features of Red Hat Satellite 6.3 are organized into key content areas below. Most of the new features include links to the feature overview available on the content portal.

    Content Management:

    System Provisioning:

    Configuration Management:

    Supportability:

    Security & User Access:

    Usability:

    Other enhancements

    In addition to the above major features for Satellite 6.3, there are a decent number of smaller features that do not have detailed feature overviews associated. The list of these other features are available here.

    Additional Details

    For more details on this release, see the Release Notes.

    For instructions on perfoming a fresh install of Red Hat Satellite 6.3, see the Installation Guide.

    For instructions on upgrading from an earlier version of Red Hat Satellite 6.x, see the Upgrading and Updating Red Hat Satellite Guide.

    Posted: 2018-02-21T16:57:28+00:00
  • Satellite 6.2.14 is now available

    Authored by: John Spinks

    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.

    Posted: 2018-02-05T15:43:11+00:00
  • Satellite 6.2.13 is now available

    Authored by: John Spinks

    Satellite 6.2.13 is now available.

    Red Hat Satellite 6.2.13 includes backup and restore capabilities for Capsule Servers, as well as other enhancements to make it easier to move the underlying Satellite operating system from a Red Hat ® Enterprise Linux ® 6 (RHEL 6) to a RHEL 7 environment. There are also enhancements to optimize package profile tasks, improvements to the pulp workers service, and documentation improvements.

    One of the most critical improvements is Backup and Restore of Capsule Servers using the katello-backup and katello-restore scripts. These steps will be documented in the refreshed Satellite 6.2 Server Administration Guide. This will help ease the transition of your Satellite or Capsule Server from RHEL 6 to RHEL 7.

    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.

    Satellite Migration from RHEL 6 to RHEL 7

    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.

    RHEL 7 has an improved kernel, newer versions of Ruby, and defaults to the XFS file system which provides better overall support for Satellite and Capsule Server operations. The combination of these updates to RHEL 7 result in significant increases in speed related to content focused.

    Future releases of Satellite 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 .
    The clone process at a high level requires backing up the Satellite Server or Satellite Capsule using the katello-backup script. Copy the backup files to the new host that is running RHEL 7, then restore using the katello-restore script.
    For long term supportability, it is important to note that RHEL 6 is in production phase 3 of its life cycle, meaning the operating improvements that help make Satellite run so well on RHEL 7 are not going to be coming to RHEL 6.

    To help make migration from RHEL 6 to RHEL 7 an easier process, the Satellite 6.2.13 release adds the capability to use the katello-backup and katello-restore scripts on your capsule servers. This enables you to restore your Satellite server and Satellite capsules from a RHEL 6 to RHEL 7 Servers. Detailed steps on how to upgrade your Satellite or Capsule server to RHEL 7 are available in the refreshed Satellite 6.2 Administration Guide.

    Posted: 2017-12-19T19:31:20+00:00
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.