2.3. Managing Multiple Organizations

Red Hat Satellite supports the creation and management of multiple organizations within one Satellite installation, allowing for the division of systems, content, and subscriptions across different organizations or specific groups. This section guides the user through basic setup tasks and explains the concepts of multiple organization creation and management within Red Hat Satellite.

2.3.1. Modeling your Satellite for Multi-Organization Use

The following examples detail two possible scenarios using the multiple organizations (or multi-organization) feature. It is a good idea to create an additional organization and use it on a trial basis for a limited set of systems/users to fully understand the impact of a multi-organization Satellite on your organization's processes and policies. Centrally-Managed Satellite for A Multi-Department Organization

In this first scenario, the Red Hat Satellite is maintained by a central group within a business or other organization (see Section, “Centrally-Managed Satellite for A Multi-Department Organization”). The Satellite administrator of Organization 1 (the administrative organization created during Satellite configuration) treats Organization 1 (the 'Administrative Organization') as a staging area for software and system subscriptions and entitlements.
The Satellite administrator's responsibilities include the configuration of the Satellite (any tasks available under the Admin area of the web interface), the creation and deletion of additional Satellite organizations, and the allocation and removal of software and system subscriptions and entitlements.
Additional organizations in this example are mapped to departments within a company. One way to decide what level to divide the various departments in an organization is to think about the lines along which departments purchase subscriptions and entitlements for use with Red Hat Satellite. To maintain centralized control over organizations in the Satellite, create an Organization Administrator account in each subsequently created organization so that you may access that organization for any reason.
Centralized Satellite Management for Multi-Department Organization

Figure 2.1. Centralized Satellite Management for Multi-Department Organization Decentralized Management of Multiple Third Party Organizations

In this example, the Satellite is maintained by a central group, but each organization is treated separately without relations or ties to the other organizations on the Satellite. Each organization may be a customer of the group that manages the Satellite application itself.
While a Satellite consisting of sub-organizations that are all part of the same company may be an environment more tolerant of sharing systems and content between organizations, in this decentralized example sharing is less tolerable. Administrators can allocate entitlements in specific amounts to each organization. Each organization will have access to all Red Hat content synced to the Satellite if the organization has software channel entitlements for the content.
However, if one organization pushes custom content to their organization, it will not be available to other organizations. You cannot provide custom content that is available to all or select organizations without re-pushing that content into each organization.
In this scenario, Satellite Administrators might want to reserve an account in each organization to have login access. For example, if you are using Satellite to provide managed hosting services to external parties, reserve an account for yourself to access systems in that organization and push content.
Decentralized Satellite Management for Multi-Department Organization

Figure 2.2. Decentralized Satellite Management for Multi-Department Organization Recommendations for Multi-Organization Use

Regardless of the specific model you choose in the management of your multi-organization Satellite, these recommendations should be noted.
Administrative organizations (organization #1) should not be used to register systems and create users in any situation, unless you intend to:
  • Use the Satellite as a single organization Satellite
  • Are in the process of migrating from a single organization Satellite to a multiple organization Satellite
This is due to the following reasons:
  1. The administrative organization is treated as a special case with respect to entitlements. You can only add or remove entitlements to this organization implicitly by removing them or adding them from the other organizations on the Satellite.
  2. The administrative organization is a staging area for subscriptions and entitlements. When you associate the Satellite with a new certificate, any new entitlements will be granted to this organization by default. In order to make those new entitlements available to other organizations on the Satellite, you will need to explicitly allocate those entitlements to the other organizations from the administrative organization.
  3. The Satellite server may only contain as many systems as there are entitlements in the Satellite certificate. Evaluate each organization's entitlement usage on the Satellite and decide how many entitlements are required for each organization to function properly. Each organization administrator should be aware of the entitlement constraint and manage the system profiles as required. Should there be any issues, the Satellite administrator can step in to mediate entitlement concerns.


    When logged in under a Satellite administrator, you cannot decrement the allocated entitlements to an organization below the number of entitlements that organization has actively associated with system profiles.

2.3.2. Configuring Systems in an Organization

Now that an organization has been created and requisite entitlements assigned to it, you can then assign systems to each organization.
There are two basic ways to register a system against a particular organization:
  1. Registering Using Login and Password - If you provide a login and password created for a specified organization, the system will be registered to that organization. For example, if user-123 is a member of the Central IT organization on the Satellite, the following command on any system would register that system to the Central IT organization on your Satellite:
    # rhnreg_ks --username=user-123 --password=foobaz


    The --orgid (for Red Hat Enterprise Linux 5) parameter in rhnreg_ks are not related to Satellite registration or Red Hat Satellite's multiple organizations support.
  2. Registering Using An Activation Key - You can also register a system to an organization using an activation key from the organization. Activation keys will register systems to the organization in which the activation key was created. Activation keys are a good registration method to use if you want to allow users to register systems into an organization without providing them login access to that organization. If you want to move systems between organizations, you may also automate the move with scripts using the activation keys.


    Activation keys have a new format since Red Hat Satellite 5.1.0, so the first few characters of the activation key are used to indicate which organization (by ID number) owns the activation.

2.3.3. Managing Organizational Trusts

Organizations can share their resources with each other by establishing an organizational trust in the Satellite. An organizational trust is bi-directional, meaning that once a Satellite Administrator establishes a trust between two or more organizations, the Organization Administrator from each organization is free to share as much or as little of their resources as they need to. It is up to each Organization Administrator to determine what resources to share, and what shared resources from other organizations in the trust to use.


Only Organization Administrators are able to share their custom content; Satellite Administrators only allocate system and software entitlements to each organization. Establishing an Organizational Trust

A Satellite Administrator can create a trust between two or more organizations. To do this, click the Organizations link on the side menu on the Admin main page.
Click the name of one of the organizations and within the Details page, click the Trusts subtab.
On the Trusts subtab, there is a listing of all the other trusts on the Red Hat Satellite. Here you may use the Filter by Organization text box to narrow down a long list of organizations to a specific subset.
Click the checkbox next to the names of the organizations you want to be in the organizational trust with the current organization and click the Modify Trusts button. Sharing Content Channels between Organizations in a Trust

Once an organizational trust has been established, organizations can now share content such as custom software channels with the other organizations in the trust. There are also three levels of channel sharing that can be applied to each channel for finer-grained channel access control.


Organizations cannot share Red Hat Channels because they are available to all organizations that have entitlements to those channels.
To share a custom channel with another organization, perform the following steps:
  1. Log in to the Satellite with the username of the Organization Administrator.
  2. Click on the ChannelsManage Software Channels.
  3. Click the custom channel that you want to share with the other organizations.
  4. From the Channel Access Control section of the Details page, there are three choices for sharing in Organizational Sharing.
    • Private - Make the channel private so that it cannot be accessed by any organizations except the channel's owner.
    • Protected - Allow the channel to be accessed by specific trusted organizations of your choice.


      Choosing Protected sharing displays a separate page that prompts you to confirm that you are granting channel access to the organizations by clicking Grant Access and Confirm.
    • Public - Allow all organizations within the trust to access the custom channel.
    Click the radio button next to your selection and click Update Channel.
Now, any other Organization Administrators within the trust for which you have granted access to your custom channel can allow their client systems to install and update packages from the shared channel.


If you have a system subscribed to a shared channel, and the organizational administrator of the shared channel changes access rights to the channel, then the system loses that channel. If the administrator changes a base channel, the system has no base channel on the Systems page and will not receive updates. Migrating Systems from One Trusted Organization to Another

In addition to sharing software channels, organizations in a trust can migrate systems to other trusted organizations. There are two methods of doing this, one through the Satellite web interface and the other, by using a utility called migrate-system-profile.


The Satellite Administrator can migrate a system from one trusted organization to any other in the trust. However, Organization Administrators can only migrate a system from their own organization to another in the trust. Using the Satellite Interface to Migrate Systems

Procedure 2.1. To Migrate a System Between Organizations:

  1. Click the Systems tab and then click the name of the system that you want to migrate.
  2. Click DetailsMigrate and select the name of the organization that you want to migrate the system to.
  3. Click Migrate System. Using migrate-system-profile
migrate-system-profile usage is based on the command-line, and uses systemIDs and orgIDs as arguments to specify what is being moved and its destination organization.
To use the migrate-system-profile command, you must have the spacewalk-utils package installed. You do not need to be logged into the Satellite server to use migrate-system-profile; however, if you do not you will need specify the hostname or IP address of the server as a command-line switch.


When an organization migrates a system with the migrate-system-profile command, the system does not carry any of the previous entitlements or channel subscriptions from the source organization. However, the system's history is preserved, and can be accessed by the new Organization Administrator in order to simplify the rest of the migration process, which includes subscribing to a base channels and granting entitlements.
Verify the ID of the system to be migrated, the ID of the organization the system will migrate to, and the hostname or IP address of the Satellite server if you are running the command from another machine.


Find the system ID and organization ID using either the Web UI or the spacewalk-report tool.
Once you have this data, the usage from the command line is as follows:
# migrate-system-profile --satellite {SATELLITE HOSTNAME OR IP} --systemId={SYSTEM ID} --to-org-id={DESTINATION ORGANIZATION ID}

Example 2.1. Migration from one department to another

The Finance department wants to migrate a workstation from the Engineering department but the Finance Organization Administrator does not have shell access to the Red Hat Satellite server. This example uses the following data:
  • Finance department organization ID is 2
  • The workstation has a system ID of 10001020
  • The Red Hat Satellite hostname is satserver.example.com
The Finance Organization Administrator would type the following from a shell prompt:
# migrate-system-profile --satellite=satserver.example.com --systemId=10001020 --to-org-id=2
The Finance Organization Administrator is then prompted for their username and password (unless they specified it using --username= and --password= at the command-line).
The Finance Organization Administrator would then be able to see the system from the Systems page when logged into the Red Hat Satellite web interface. The Finance Organization Administrator can then finish the migration process by assigning a base channel and granting entitlements to the client like any other system registered to his organization, which is available from the system's History page in the Events subtab.
Satellite Administrators that need to migrate several systems at once can use the --csv option of migrate-system-profile to automate the process using a simple comma-separated list of systems to migrate.
A line in the CSV file should contain the ID of the system to be migrated as well as destination organization's ID in the following format:
A compatible CSV could look like the following:
For more information about using migrate-system-profile see the manual page by typing man migrate-system-profile or for a basic help screen type migrate-system-profile -h.