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
-
Performing DHCP kexec on discovered hosts
Satellite 6.2 introduced PXE-less discovery which is targeted to networks without PXE or DHCP services available. In this workflow, kernel on discovered nodes is replaced (via kexec technology) instead of rebooting. This turns out to be useful feature on PXE/DHCP networks as well.
To configure kexec on PXE/DHCP enabled network, do the following simple steps.
Step 1: Verify foreman discovery image version
Newer version of foreman-discovery-image must be used in order to send required "discovery_kexec" fact. We are planning rebase of foreman-discovery-image package in Satellite 6.2 upcoming errata. In the meantime, it is possible to download upstream version which is based on CentOS 7 rather than Red Hat Enterprise Linux. Series 3.4 are known to work with Satellite 6.2.
tftp_capsule# cd /var/lib/tftpboot/boot/ tftp_capsule# wget http://downloads.theforeman.org/discovery/releases/3.4/fdi-image-3.4.1.tar tftp_capsule# tar -xvf fdi-image-3.4.1.tarStep 2: Configure foreman discovery image kernel options
Satellite will either reboot or kexec discovered node based on presence of special fact called "discovery_kexec". When present and KExec template is associated with given Hostgroup and Operating System, kexec is performed. Reboot is the fallback mechanism if the two requirements are not met.
In Hosts - Provisioning templates search for "global" string and edit "PXELinux global default" template. In Satellite 6.2 it is possible to directly edit this template, in upcoming version this template must be cloned and Global setting must be changed to use the cloned template instead the default one.
ONTIMEOUT discovery_upstream ... LABEL discovery_upstream MENU LABEL Foreman Discovery Image 3.4.1 KERNEL boot/fdi-image/vmlinuz0 APPEND initrd=boot/fdi-image/initrd0.img rootflags=loop root=live:/fdi.iso rootfstype=auto ro rd.live.image acpi=force rd.luks=0 rd.md=0 rd.dm=0 rd.lvm=0 rd.bootif=0 rd.neednet=0 nomodeset proxy.url=https://CAPSULE_URL:9090 proxy.type=proxy fdi.pxfactname1=discovery_kexec fdi.pxfactvalue1=1 IPAPPEND 2Change proxy.url and proxy.type accordingly to point to either Satellite Server or Capsule. Note the options fdi.pxfactname1=discovery_kexec fdi.pxfactvalue1=1 which are required in order to have the "discovery_kexec" fact sent along.
Now click on Build PXE Default to rebuild pxelinux.cfg/default template. Hosts can be discovered now.
Step 3: Modify Red Hat KExec template
Find Red Hat Kexec template, clone it, associate it with requied Operating System and edit its contents:
<%# kind: kexec name: Red Hat kexec oses: - CentOS 4 - CentOS 5 - CentOS 6 - CentOS 7 - Fedora 19 - Fedora 20 - Fedora 21 - Fedora 22 - RedHat 4 - RedHat 5 - RedHat 6 - RedHat 7 -%> <% mac = @host.facts['discovery_bootif'] bootif = '00-' + mac.gsub(':', '-') if mac append = @host.facts['append'] -%> { "kernel": "<%= @kernel %>", "initram": "<%= @initrd %>", <% if (@host.operatingsystem.name == 'Fedora' and @host.operatingsystem.major.to_i > 16) or (@host.operatingsystem.name != 'Fedora' and @host.operatingsystem.major.to_i >= 7) -%> "append": "ks=<%= foreman_url('provision') %> inst.ks.sendmac <%= "ksdevice=bootif BOOTIF=#{bootif} #{append}" %>" <% else -%> "append": "ks=<%= foreman_url('provision') %> kssendmac <%= "BOOTIF=#{bootif} #{append}" %>" <% end -%> }The template was designed for DHCP-less environments and it assumes static IP configuration. These "discovery_*" facts are not present, therefore the default template generates "ip=::::::none" Anaconda configuration which leads to System halted. The modified version does not provide static configuration, therefore Anaconda performs DHCP request.
Make sure to set this template as default one for required Operating Systems.
Step 4: Verify requirements and provision
Before provisioning the very first discovered node, show the detail page, expand all facts and search for "discovery_kexec" fact, it should be set to "1". Also make sure the Red Hat KExec template is associated with Operating System.
Discovered hosts now can be provisioned or auto-provisioned and kexec will be performed instead of reboot.
Troubleshooting
On some hardware or VMs, kexec will freeze when discovered node is on the first virtual console (tty1) with the text user interface.
To workaround this issue switch virtual terminal to tty2 (Alt+F2) before kexecing.
Posted: 2017-08-11T08:00:00+00:00 -
Satellite 6.2.11 is released
Satellite 6.2.11 has been released today. 6.2.11 introduces many fixes in the messaging infrastructure of Satellite 6. There is one erratum for the server [1] and one for the hosts [2]. The install ISOs will be updated next week at the earliest.
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 at [3].
PLEASE NOTE: Customers who have received hotfixes should verify the list below to ensure their hotfix is contained in the release before upgrading. Their hotfixes may be overwritten if they upgrade. Please reach out to the Satellite team if you are unsure.
The list of bugs resolved in 6.2.11 include:
-
Updated QPID packages have been included to address performance and memory issues. (BZ#1367735, BZ#1443470, BZ#1431783, BZ#1449743, BZ#1468450, BZ#1368718)
-
Users can now manage a system without the use of gofer. (BZ#1445403)
-
Several search bugs have been resolved. (BZ#1392422, BZ#1462350)
-
The RBAC system has been updated to unlock behaviors for non-admin users and to suppress database errors. (BZ#1246865, BZ#1427282)
-
Manifest refreshes were not respecting proxy settings on the host. These settings are now respected. (BZ#1464881)
-
A batch job has been introduced to clean up repository metadata on Capsules. (BZ#1425691)
-
An error message from foreman-rake was causing confusion. The message has now been cleaned up. (BZ#1429418)
-
Deleting an interface was deleting the entire host record. The code will now correctly only delete the interface. (BZ#1285669)
-
Bulk Capsule syncs were causing a race condition which resulted in failed syncs. This case is now handled correctly. (BZ#1391298, BZ#1443213)
-
This release contains various memory and performance improvements. (BZ#1434040, BZ#1458857, BZ#1437150)
-
Users can now browse to /pub on Capsule Servers over HTTPS. (BZ#1432580)
-
Certain trends would show a database error. The query behind this trend has been resolved. (BZ#1375000)
Please reach out with any questions or concerns.
[1] https://access.redhat.com/errata/RHBA-2017:2466
[2] https://access.redhat.com/errata/RHBA-2017:2467
[3] https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-serverPosted: 2017-08-10T20:57:13+00:00 -
-
Dealing with many network interfaces during host check-ins
Satellite 6 comes with powerful host importing capabilities as part of its inventory feature. When a host checks-in via Puppet or subscription-manager, all incoming data, which we call "facts", are parsed. This mechanism is called "fact import".
By default Satellite 6 extracts networking information such as NICs, MAC and IP addresses making necessary changes to reflect the new state in the inventory database. When an IP address of a registered host changes for example, the same change is applied in Satellite 6 database during fact import.
This can be problem for hosts with frequently changing interfaces, typically virtualization hypervisors or container hosts. The default behavior in Satellite 6 is safe; new interfaces are added but missing interfaces are never removed. This stems from Puppet behavior when disabled interfaces are not reported via facter which could lead to mis-deletions in the Satellite 6 inventory.
In these workloads, Satellite 6 will be adding new network interfaces to hosts indefinitely leading to slow performance of host check-ins for both Puppet and subscription-manager. We've seen hosts with thousands of records of invalid network interface inventory data. There are two configuration options to solve this situation.
First, fact import for NICs can be completely disabled via Ignore Puppet facts for provisioning global setting. When this option is turned on, the IP or MAC address of existing host is never updated automatically. Although the name of this setting implies this only affects Puppet, it also affects subscription-manager import code as well. We will rename this option in the future to match its real meaning.
This will essentially completely turn off Puppet fact parsing which cannot be used in case hosts are being registered via Puppet and network interfaces are needed, for example to remotely execute scripts. For this case, there is an alternative method to filter out some interfaces from being added or updated in the Satellite 6 inventory via Ignore interfaces with matching identifier global option. By default it is set to:
'lo', 'usb*', 'vnet*', 'macvtap*', '_vdsmdummy_'For example to filter out docker network interfaces, 'veth*' would be added to the list. Interface naming conventions are different for virtualization or container technologies like libvirt, vdsm, xen or lxc. What is usually common is some prefix or suffix that can be easily matched using a wildcard syntax. Note the syntax is not a regular expression, but a simple wildcard.
Satellite 6.2.9 introduced two new settings called Ignore facts for operating system and Ignore facts for subnet which work in a similar way, but are not related to network interfaces.
Posted: 2017-08-09T08:00:00+00:00 -
How to share custom repositories across organizations
Satellite 6 is strictly a multi-tenant application meaning that every organization gets its own subscription manifest and must select appropriate repositories and sync it. Although the design of Satellite 6 makes sure every single RPM package is downloaded only once across all organization, syncing metadata and publishing and promoting content within many organizations can be time consuming for some specific use cases. The following will work with Satellite 6.2 or newer.
One use case is a custom Yum repository with EPEL. This type of content can be easily shared across organizations in case there is a need to use latest and greatest EPEL content synced on a daily basis for example. In this case, the recommended way is to create a special organization which we will refer to under the name "SharedContent". It is recommended to give it unique and short label as it will be present in all repository URLs; a good candidate would be "shared".
Under SharedContent organization new Custom Product and Repository can be created, let's say EPEL product and EPEL7 repository. During creation, the Publish via HTTP option must be checked, or it can be enabled later on in the Repository detail page. For such a large repository like EPEL, it is recommended to use the on-demand download policy and also to customize Satellite 6 squid daemon configuration and cache volume size to handle a large cache .
After initial synchronization which usually takes longer, the key thing is to find out the URL where the content is being published to. This can be done in the Product - Repository detail page as Published At field. It will be something like:
http://sat6.host.lan/pulp/repos/shared/Library/custom/EPEL/EPEL7/The same content is also available under HTTPS but to access content via SSL, a client certificate must be provided. One is available under Organization detail page and it's called Debug Certificate. It is possible to use it to consume the shared content if HTTP is not preferred.
To consume EPEL content, provisioning templates or puppet manifests need to be updated to use the custom repository. As an example, we will leave here a snippet for Anaconda RHEL kickstart. It is recommended to clone the original template and create a custom one associating it with all Operating Systems and setting it as default:
... repo --name=epel --baseurl=http://sat6.host.lan/pulp/repos/shared/Library/custom/EPEL/EPEL7/ ...For HTTPS URL make sure to use --noverifyssl option or use post scriplet to deploy server certificate and yum configuration after installation when SSL server cert verification is a must.
Once everything is tested, Sync Plan can be created. It is also possible to create Content Environments or Content Views and leverage content promotion capabilities in the shared organization. That's how any custom repository can be easily shared.
Posted: 2017-08-07T06:00:00+00:00 -
Satellite 6.2.10 is released
Satellite 6.2.10 has been released today. 6.2.10 introduces many fixes based on customer cases and feedback. There is one erratum for the server [1] and one for the hosts [2]. The install ISOs will be updated next week at the earliest.
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 at [3].
PLEASE NOTE: Customers who have received hotfixes should verify the list below to ensure their hotfix is contained in the release before upgrading. Their hotfixes may be overwritten if they upgrade. Please reach out to the Satellite team if you are unsure.
The list of bugs fixed in in 6.2.10 include:
- The refreshing of manifests process has been improved with several bug fixes and enhancements such as subscription refreshes and a confirmation dialog. (BZ#1455154, BZ#1455199, BZ#1393580, BZ#1436242, BZ#1266827)
- The upgrade process will now execute
foreman-rake katello:correct_repositoriesfor the user. (BZ#1446713, BZ#1365223, BZ#1375075, BZ#1425437) - The subscription status is now consistent across the web UI and CLI. (BZ#1371605)
- Memory leaks in OpenSCAP and the tasks plug-in have been resolved. (BZ#1432263, BZ#1412307)
- Updating a content set associated to a pool with very large numbers of entitlements caused Candlepin to run out of memory. Consequently, updating a custom product with a large number of hosts took a long time. This bug has been fixed and Candlepin performance is now improved in the scenario described. (BZ#1435809)
- Previously, when applying two errata to one thousand hosts the Gofer Agent daemon (goferd) sometimes terminated unexpectedly with a segmentation fault. The code has been improved and goferd no longer fails in the scenario described. (BZ#1418557)
- Several fixes have been made to remote execution. (BZ#1387658, BZ#1417978, BZ#1422690, BZ#1449830, BZ#1413966, BZ#1390931, BZ#1438601)
- Capsule synchronization was failing after upgrade for certain library configurations. These cases have been fixed. (BZ#1456446, BZ#1456559)
[1] https://access.redhat.com/errata/RHBA-2017:1553
[2] https://access.redhat.com/errata/RHBA-2017:1554
[3] https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-serverPosted: 2017-06-20T19:13:25+00:00 -
Satellite 5.8 cdn-sync Performance
Introduction
Red Hat Satellite 5.8.0 comes with a new way to synchronize channel-content from Red Hat:
cdn-sync. Unlikesatellite-sync, which synchronizes content (i.e. channels, packages, errata, and kickstart trees) from RHN Classic servers,cdn-syncretrieves content from Red Hat's CDN servers (the same source which is used by systems registered via subscription-manager).cdn-synccommand attempts to keep option parity withsatellite-syncwhere it makes sense to do so.Although Satellite 5.8.0 itself (when running in connected mode) now registers to Red Hat using
subscription-manager, clients registered to Satellite continue to use the RHN Classic tooling (e.g.rhn-register).While the content-sources differ between
satellite-syncandcdn-sync, the goal is to end up with the same results in the Satellite doing the synchronizing. Red Hat is aware of some discrepancies between the two content-sources, and is working on making them consistent. Also, as content is structured differently on CDN, thecdn-sync-mappingpackage was added, which maps content locations (i.e. repositories with packages or kickstart trees) on CDN to matching channels on Satellites.Performance Comparison
Tests were run concurrently on the same hardware (4 x Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 8 GB RAM) located in same lab. The operating system was a fully updated Red Hat Enterprise Linux 6 Server.
The tables below show the results from a comparison of sync times for the "Red Hat Enterprise Linux Server (v. 7 for 64-bit x86_64)" repository. The comparison is between the following commands:
5.8.0 Beta (build 20170330) and the 5.8.0 Release Candidate (build 20170515):
cdn-sync -c rhel-x86_64-server-7
5.6.0 and 5.7.0:satellite-sync -c rhel-x86_64-server-7Satellite version time cdn-sync/satellite-sync -c rhel-x86_64-server-7Red Hat Satellite 5.6.0 13 hours, 8 minutes, 9 seconds Red Hat Satellite 5.7.0 13 hours, 8 minutes, 10 seconds Red Hat Satellite 5.8.0 Beta 3 hours, 20 minutes, 28 seconds Red Hat Satellite 5.8.0 RC 1 hour, 51 minutes, 7 seconds (On the 5.8.0 Beta, sync was without 7.3 kickstart tree, due to a beta bug)
Conclusion
Initial sync of a channel takes far less time on Red Hat Satellite 5.8.0 when compared to 5.7.0 or 5.6.0 (around two hours instead of thirteen, assuming a fast connection to
cdn.redhat.com). This is primarily the result of the switch to the CDN-based syncing toolcdn-sync, which retrieves content from the content distribution network, fetching content from a source that should be closer to your Satellite Server.Posted: 2017-06-19T19:47:38+00:00 -
Satellite 5.8 is released
Red Hat Satellite 5.8 now generally available
Today, Red Hat is pleased to announce the general availability of Red Hat Satellite 5.8, the last minor release of the Satellite 5 product line. Red Hat Satellite 5.8 builds upon 10 years of enterprise-proven successes, offering a complete lifecycle management solution to help keep Red Hat infrastructure running efficiently and with greater security, helping to reduce costs and overall complexity. Red Hat Satellite 5.8 is now available to all customers with an active Satellite subscription.
Red Hat Satellite 5.8 introduces several new features, enhancements and programs, including:
- Increased speed with channel install and content syncing. For the first time in Satellite 5, customers can now register, activate and update the Satellite server from the Customer Portal, as well as synchronize content via the Red Hat Content Delivery Network. Read more about the improvements in content synchronization in this blog post
- Improved diagnostics of background tasks and jobs. Red Hat Satellite 5.8 Introduces the Taskotop utility, which monitors Taskomatic activities and provides insights and information on the status of jobs, which can now run background tasks individually or in bulk.
- Updated support of Oracle DB and PostgreSQL. Red Hat Satellite 5.8 offers expanded support for two additional databases -- External Oracle Database 12c and Embedded/Managed PostgreSQL 9.5 DB.
- Extended lifecycle support beginning in 2019. Satellite 5.8 is the only minor release of the Satellite 5 product line to offer an Extended Lifecycle Support option beginning in early 2019.
Content Delivery Network Sync process:
The CDN sync process used by Satellite 5.8 is configured to work with products that are available in Satellite 5 today and are not at their end-of-life (EOL). All currently mirrored content will be available after upgrading to Satellite 5.8, but after the upgrade you will not be able to re-sync content that is at
or beyond its EOL. If you are planning a new install of 5.8 rather than an upgrade, and need to be able to sync this content, contact your account team to determine the best practices for your situation.For more information on Satellite 5.8:
- Which product content is supported on Satellite 5.8?
https://access.redhat.com/node/3069161 - Important Changes Coming to Red Hat Satellite 5: https://access.redhat.com/satellite5updates
- Red Hat Satellite Lifecycle Support page: https://access.redhat.com/support/policy/updates/satellite/
Posted: 2017-06-19T19:35:28+00:00 -
Satellite 6.2.9 is released
Satellite 6.2.9 has been released today. 6.2.9 introduces many fixes based on delivering high priority fixes and RFEs. 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 at [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 the Satellite team in these cases.
The list of bugs in 6.2.9 are:
- The katello backup script no longer stops services unnecessarily and does not reset directory permissions. (BZ#1388145, BZ#1399244)
- Several issues with the bootstrap script have been addressed. (BZ#1361339, BZ#1422236, BZ#1422756, BZ#1425606)
- Performance improvements have been made to many parts of the application. (BZ#1428307, BZ#1388296, BZ#1419667, BZ#1422304, BZ#1427618, BZ#1328984, BZ#1402423)
- Satellite can now pull down the correct Certificate Authority when provisioning against RHEV 4.0. (BZ#1370169)
- Users will now be able to configure content synchronization to force a resynchronization of content. (BZ#1427618)
- Multiple bugs with Host navigation were addressed. (BZ#1408438, BZ#1408555, BZ#1432184)
- The installer will no longer delete virtual machines during the upgrade process. (BZ#1418892)
- Session IDs have been introduced to the logs, and other logging improvements were also made. (BZ#1408420, BZ#1429642, BZ#1367162)
- Large files can now be uploaded into Satellite repositories. (BZ#1404345)
- Satellite has improved how it cleans up content during synchronization and promoting. (BZ#1307207, BZ#1409856, BZ#1417689)
- Remote Execution has been enhanced to support alternative ports per host. (BZ#1426709)
- A few improvements were made to Smart Variables. (BZ#1382356, BZ#1353968)
- The upgrade process has been improved based on customer feedback. (BZ#1389802, BZ#1419721, BZ#1390931)
- Customers can now delete cloned roles. (BZ#1353788, BZ#1378544)
- In Satellite 6.2.7, the "foreman-rake katello:reindex" script was renamed to "katello:reimport". This update adds a depreciation warning that "foreman-rake katello:reindex" is now "katello:reimport", and that "katello:reindex" will be removed in Satellite 6.3.
Please reach out with any questions or concerns.
- [1] https://access.redhat.com/errata/RHBA-2017:1191
- [2] https://access.redhat.com/errata/RHBA-2017:1192
- [3] https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server
Posted: 2017-04-30T14:05:02+00:00 -
Red Hat Satellite 5.8 Beta Now Available for Testing
Red Hat Satellite 5.8 Beta Now Available for Testing
The Red Hat Satellite team is pleased to announce the beta release of Red Hat Satellite 5.8.
The Satellite 5.8 Beta represents the last minor release of the Satellite 5 product line. For customers planning to stay on Satellite 5 through the end of production and access extended life cycle support in early 2019, we encourage you to test the Satellite 5.8 Beta to plan your eventual upgrade.
WHAT’S COMING IN 5.8?:
- Increased speed with channel install and content syncing: Register, activate and update the Satellite server from the Customer Portal, as well as synchronize content via our Content Delivery Network.
- Improved diagnostics of background tasks and jobs: Introducing the Taskotop utility, which monitors Taskomatic activities and provides insights on the status of jobs, which can now run individually or in bulk.
- Updated support of Oracle DB & PostgreSQL: Receive expanded support for two additional databases -- External Oracle Database 12c and Embedded/Managed PostgreSQL 9.5 DB.
BETA PROGRAM DETAILS:
The Red Hat Satellite 5.8 beta is now available to all customers with an active Red Hat Satellite subscription. To learn more and request temporary beta subscriptions, please visit: https://access.redhat.com/products/red-hat-satellite/beta
NOTE - Only your company’s Org Admin can request and receive access to the additional beta subscriptions.
ADDITIONAL RESOURCES:
Posted: 2017-04-06T15:02:21+00:00 -
Questions and Answers from the February 2017 Satellite Ask-Me-Anything session
Satellite 6 Ask Me Anything FAQ
As promised, listed below are the responses to the questions we received in our Feb 2017 Satellite Ask Me Anything session.
AMA Feb Questions
January AMA Q&A: https://access.redhat.com/blogs/1169563/posts/2918221
Next steps: Create 2nd blog post before Tuesday AMA (linking to January Q&A as reference); Later in March, create Satellite 6 Technical FAQ
Content Views
Question: Does a composite content view duplicate all content in the content views it contains?
Answer: No. Content views (and composite views) are merely references to the content on disk. RPM are only stored once on disk. Each content view does having unique yum metadata, but this is measured in the 10s of megabytes.Question: What are the best practices for creating a content view?
Answer: See 2015 - 10 Steps to Build an SOE: How Red Hat Satellite 6 Supports Setting up a Standard Operating Environment https://access.redhat.com/articles/1585273Puppet
Question: Puppet Enterprise only supports integration with Satellite 6 for RHEL 7 or higher puppet masters. Is there any way for RHEL 6 PE users to integrate Satellite with Puppet Enterprise?
Answer: The integration module is available only for RHEL7 Puppet Masters.
Question: Is a Continuous Integration/Deployment Workflow possible with Jenkins, r10k and Git possible with Puppet in Satellite 6?
Answer: Yes. Take a look at the soe-ci to see an example of how one can implement a CI/CD workflow with Satellite 6 + Jenkins
Question: Is puppet required for provisioning?
Answer: NoInstall & Upgrades
Question: I have upgraded my Satellite server from 6.1 to 6.2. However, when viewing my Satellite under access.redhat.com and Subscriptions, it still shows my Satellite Server as version 6.1. Is this serious?
Answer: It is not serious and you should not be concerned. This is a known bug that will be addressed in future releases of Satellite 6.
Question: How to automate the installation of RHEL in an environment where dns and dhcp already exists?
Answer: Simply do not install the DNS and DHCP components on the Satellite.
Question: We have a number of clients with hostnames that include underscores (''). These clients reported in fine to Satellite 6.1. In order to upgrade to 6.2, I had to delete them in order for the upgrade to be successful. I now find that I cannot add them back. What has changed and why?
Answer: In Satellite 6.0 and 6.1, there were two definitions of a host, one that was used for provisioning/configuration and another that was used for content/subscription. The content/subscription definition allowed hostnames that were arbitrary, and those could include shortnames & other characters (such as underscores). In Satellite 6.2, one of the major changes was that these definitions were unified, and all hostnames needed to be proper FQDNs. As part of bz1426424, bootstrap.py will allow you to supply an arbitrary hostname when registering that differs from your configured hostname.Multi-Org
Question: We have certain organizations within our organization, which would like to manage their own hosts. How does this work in Satellite 6.x and what's needed to setup multi-org?
Answer: For each organization, you need to
- Create a subscription manifest in the Customer Portal
- Create a new organization in Satellite
- Import the subscription manifest.
Question: Is there a way to avoid duplication of sync'd repo data between organizations? We have multiple organizations, and each org seems to need a new copy of repos that are already present in other organizations.
Answer: RPMs are already deduplicated between organizations. However, each organization needs to 'sync' the repositories that they wish to use in order to get their own copy of them.
Disconnected Satellites
Question: My customer is air-gapped from the internet. How can I transfer patches/errata from one Satellite to customer air-gapped Satellite?
Answer: See Red Hat Satellite 6.2 Feature Overview: Inter-Satellite Sync
Question: If I have an air-gapped DMZ where I deploy a separate Satellite, will I need to get my subscriptions split as well?
Answer: Each Satellite will require its own subscription manifest. However, you only need to allocate the subscriptions required to manage each host to the respective Satellite.
Misc
Question: What do I need in Satellite 6 to execute remote commands on the guest?
Answer: SSH Keys need to be setup for each host. Many methods on how to deploy these keys are described in Making systems ready for Satellite 6.2's remote execution
Question: Any way to extract metadata from Foreman using either hammer or other utilities? I'd like to update our CMDB with this information.
Answer: Yes, depending on which data you are looking for, this will be accessible via hammer or via the API. Note: hammer can output to CSV, YAML or JSON.Question: When should we expect system profile backup feature in Satellite 6?
Answer: This is currently not planned for an upcoming release of Satellite.Question: What do I need to configure our install in order to enable reporting for all hosts under the Host tab?
Answer: Reporting refers to 'configuration management' reporting. Puppet needs to be installed for this.
Question: I just applied an errata to a group of systems and it broke and application. How do I figure out what packages were installed if I do not have a profile backup to compare?
Answer: Each job such as an errata installation submits a background task. You can view these tasks (via Monitor->Tasks) to see which packages were installed.
Question: We have several VMWare vCenters. What is your recommendation on creating Compute Resources? Should I create 1 Compute Resource for each vCenter?
Answer: Compute Resources only support a single vCenter, so 1 Compute Resource per vCenter.
Posted: 2017-03-14T09:36:28+00:00