Importing content
This chapter outlines how you can import different types of content to orcharhino. For example, you can use the following chapters for information on specific types of content but the underlying procedures are the same:
Products and repositories in orcharhino
You can organize content in Products. Products bundle an arbitrary number of repositories.
Products require a subscription for hosts to access. orcharhino creates a subscription for each product you create.
Importing custom SSL certificates
Before you synchronize content from an external source, you might need to import SSL certificates into your product. This might include client certs and keys or CA certificates for the upstream repositories you want to synchronize.
If you require SSL certificates and keys to download packages, you can add them to orcharhino.
To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Content Credentials. In the Content Credentials window, click Create Content Credential.
-
In the Name field, enter a name for your SSL certificate.
-
From the Type list, select SSL Certificate.
-
In the Content Credentials Content field, paste your SSL certificate, or click Browse to upload your SSL certificate.
-
Click Save.
-
Copy the SSL certificate to your orcharhino Server:
$ scp My_SSL_Certificate root@orcharhino.example.com:~/.
Or download the SSL certificate to your orcharhino Server from an online source:
$ wget -P ~ http://upstream-orcharhino.example.com/pub/katello-server-ca.crt
-
Upload the SSL Certificate to orcharhino:
# hammer content-credential create \ --content-type cert \ --name "My_SSL_Certificate" \ --organization "My_Organization" \ --path ~/My_SSL_Certificate
Creating a product
Create a product so that you can add repositories to the product. To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Products, click Create Product.
-
In the Name field, enter a name for the product. orcharhino automatically completes the Label field based on what you have entered for Name.
-
Optional: From the GPG Key list, select the GPG key for the product.
-
Optional: From the SSL CA Cert list, select the SSL CA certificate for the product.
-
Optional: From the SSL Client Cert list, select the SSL client certificate for the product.
-
Optional: From the SSL Client Key list, select the SSL client key for the product.
-
Optional: From the Sync Plan list, select an existing sync plan or click Create Sync Plan and create a sync plan for your product requirements.
-
In the Description field, enter a description of the product.
-
Click Save.
To create the product, enter the following command:
# hammer product create \ --name "My_Product" \ --sync-plan "Example Plan" \ --description "Content from My Repositories" \ --organization "My_Organization"
Best Practices for Products and Repositories
-
We recommend keeping products as small as possible. For example, one product each for
PostgreSQL-7.0
,PostgreSQL-7.1
, andPostgreSQL-8.1
with one repository each is better than a singlePostgreSQL
product including multiple repositories for different versions. Likewise, we recommend separate products for things likeDebian-12
,Apache 2.0
,MySQL-5.1
, andPostgreSQL 7.1
rather than a singleWebServer
product. Because products correspond to subscriptions, small products give you greater control over what subscriptions and what content is used through your activation keys. -
Separate products by major release, for example
Debian 12
. -
Use one content type per product and content view, for example
deb
oryum
only. -
Make
file
repositories available through HTTP. Using TLS is currently only working with a global debugging certificate. -
Add sync plans to products.
-
Spread out starting sync plans over a large time span. We do not recommend to start synchronizing a lot of repositories at the same time.
-
Synchronize your content regularly to avoid overly large changes in repositories. We recommend synchronizing content rather each night than only once a month.
-
Use file repositories for installation media. File repositories require a Pulp Manifest file which you can create using
pulp-manifest /path/to/files
. Use local repositories withfile:///path/to/files
as Upstream URL in orcharhino, for example for installation media. Alternatively, place the installation media file repositories on a web server that can be reached from hosts during provisioning.ATIX provides file repositories for installation media. Once synchronized, you can perform offline host deployments using a local installation media. See ATIX Service Portal for the upstream URL.
ATIX provides the following installation media as file repository:
-
Debian 9, 10, and 11
-
Ubuntu 18.04
-
Ubuntu 20.04
-
-
Use a Hammer script or Ansible Playbook to create a lot of products and repositories when starting with a fresh orcharhino installation.
-
We do not recommend uploading content to repositories with an Upstream URL. Instead, create a repository to synchronize content, for example Debian or nginx, and create a repository to upload content to without setting an Upstream URL.
If you upload content to a repository that already synchronizes another repository, there might be unwanted side effects depending on the mirroring policy and content type.
Extracting GPG public key fingerprints from Release files
You can use GPG public keys to verify the authenticity of Deb repositories by verifying the signature of the Release
file.
This example verifies the signature for the Release
file from Debian 11.
-
Download the
Release
andRelease.gpg
files:$ wget https://deb.debian.org/debian/dists/bullseye/Release $ wget https://deb.debian.org/debian/dists/bullseye/Release.gpg
-
Verify the signature:
$ gpg --verify Release.gpg Release
Note the GPG key fingerprint for any missing public GPG keys above the
Can’t check signature: No public key
message. These fingerprints will be used in the next step. -
If you cannot verify the signature, import the missing GPG public keys based on their fingerprint:
$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9 $ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 4CB50190207B4758A3F73A796ED0E7B82643E131 $ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys A4285295FC7B1A81600062A9605C66F00D6C9793
-
Optional: Verify the signature again:
$ gpg --verify Release.gpg Release
-
Export the ASCII-armored GPG public keys to a file:
$ gpg --armor --export A7236886F3CCCAAD148A27F80E98404D386FA1D9 4CB50190207B4758A3F73A796ED0E7B82643E131 A4285295FC7B1A81600062A9605C66F00D6C9793 > debian_11.txt
Ensure that
gpg
returns aGood signature
message for each signature.Upload the .txt file to orcharhino. For more information, see Importing a Custom GPG Key into orcharhino.
Adding Deb repositories
Use this procedure to add Deb repositories in orcharhino. To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Products and select the product that you want to use, and then click New Repository.
-
In the Name field, enter a name for the repository. orcharhino automatically completes the Label field based on what you have entered for Name.
-
Optional: In the Description field, enter a description for the repository.
-
From the Type list, select
deb
as type of repository. -
Optional: In the Upstream URL field, enter the URL of the external repository to use as a source. You can find the upstream URLs on Debian-based systems in
/etc/apt/sources.list
.If you do not enter an upstream URL, you can manually upload packages.
-
In the Releases/Distributions field, set one or multiple releases separated by whitespace. The distributions specify the path from the repository root to the
Release
file. Repositories that omit thedists
directory are using the deprecated flat repository structure. To synchronize a flat repository, you must specify exactly one distribution that ends with a/
.For official Debian repositories, set a codename in the Releases/Distributions field, for example
buster
for Debian 10 orbullseye
for Debian 11. Avoid usingstable
ortesting
because the codename they reference changes over time. This helps to avoid drastic changes once a new Debian version is released and the reference is changed. To keep things easy to manage and to avoid potential performance and network issues during synchronization, create one repository per release in orcharhino. For official Ubuntu repositories, use the Ubuntu suite, for examplefocal
orfocal-updates
. -
Optional: In the Components field, enter a component. This indicates the licensing terms of the software packages.
In Debian, it is divided into
main
,contrib
, andnon-free
. For official Debian or Ubuntu repositories, ATIX AG recommends leaving this field empty to synchronize all available components. Note that some third party Debian repositories use the components in ways that may require setting an explicit selection.Ensure that you enter both Releases and Components exactly as they are in an
/etc/apt/sources.list
file. -
Optional: In the Architectures field, enter one or multiple architectures. If you want to make the repository available to all hosts regardless of the architecture, ensure to select No restriction.
-
Optional: In the Errata URL field, enter the URL of an errata service.
The ATIX AG Debian and Ubuntu Errata service provides errata for Debian and Ubuntu. When creating a repository of type
deb
, point the Errata URL to ATIX AG Debian and Ubuntu Errata service. Usehttps://dep.atix.de/dep/api/v1/debian
for Debian,https://dep.atix.de/dep/api/v1/ubuntu
for Ubuntu, andhttps://dep.atix.de/dep/api/v1/ubuntu-esm
for Ubuntu-ESM.An erratum contains the information which packages have to be updated to fix a security issue. Debian and Ubuntu errata are derived from the Debian security announcements (DSA) and the Ubuntu security notices (USN).
You must add Debian and Ubuntu errata to the security repository. For Debian, you need the
My_Debian_Release-security
repository, for example,bookworm-security
. For Ubuntu, you need theMy_Ubuntu_Release-security
repository, for example,jammy-security
. -
Optional: Select the Verify SSL checkbox if you want to verify that the upstream repository’s SSL certificates are signed by a trusted CA.
-
Optional: In the Upstream Username field, enter the user name for the upstream repository if required for authentication. Clear this field if the repository does not require authentication.
-
Optional: In the Upstream Password field, enter the corresponding password for the upstream repository. Clear this field if the repository does not require authentication.
-
Optional: In the Upstream Authentication Token field, provide the token of the upstream repository user for authentication. Leave this field empty if the repository does not require authentication.
-
From the Download Policy list, select the type of synchronization orcharhino Server performs. For more information, see Download Policies Overview.
-
From the Mirroring Policy list, select the type of content synchronization orcharhino Server performs. For more information, see Mirroring Policies Overview.
-
Optional: In the HTTP Proxy Policy field, select an HTTP proxy.
-
Optional: You can clear the Unprotected checkbox to require a subscription entitlement certificate for accessing this repository. By default, the repository is published through HTTP.
-
Optional: From the GPG Key list, select the GPG key if you want to verify the signatures of the
Release
files associated with the Debian repository. -
Optional: In the SSL CA Cert field, select the SSL CA Certificate for the repository.
-
Optional: In the SSL Client cert field, select the SSL Client Certificate for the repository.
-
Optional: In the SSL Client Key field, select the SSL Client Key for the repository.
-
Click Save to create the repository.
-
Enter the following command to create the repository:
# hammer repository create \ --content-type "deb" \ --deb-architectures "My_Deb_Architectures" \ --deb-components "_My_Deb_Components" \ --deb-releases "My_Deb_Releases" \ --gpg-key-id "My_GPG_Key_ID" \ --name "_My_Repository" \ --organization "My_Organization" \ --product "My_Product" \ --publish-via-http true \ --url My_Upstream_URL
Continue to synchronize the repository.
Adding upstream repositories for Debian 12
This example creates a product and repositories for Debian 12.
-
Extract the GPG public keys from the
Release
file. -
Import the content credentials into orcharhino.
-
In the orcharhino management UI, navigate to Content > Products.
-
Click Create Product to create a product named
Debian 12
. -
On the Repositories tab, click New Repository to create three
deb
repositories with the following parameter values:-
Debian 12 main
-
Upstream URL:
http://deb.debian.org/debian/
-
Releases/Distributions:
bookworm
-
Component:
main
-
Architecture:
amd64
-
-
Debian 12 updates
-
Upstream URL:
http://deb.debian.org/debian/
-
Releases/Distributions:
bookworm-updates
-
Component:
main
-
Architecture:
amd64
-
-
Debian 12 security
-
Upstream URL:
http://deb.debian.org/debian-security/
-
Releases/Distributions:
bookworm-security
-
Component:
main
-
Architecture:
amd64
-
-
-
Click Create Product to create a product named
Debian 12 client
. -
On the Repositories tab, click New Repository to create a
deb
repository with the following parameter values:-
Debian 12 client
-
Upstream URL: see ATIX Service Portal
-
Releases/Distributions:
stable
-
Component:
main
-
Architecture:
amd64
-
-
-
To create a product, see Creating a Custom Product.
-
To create a repository, see Adding Custom Deb Repositories.
Adding upstream repositories for Debian 11
This example creates a product and repositories for Debian 11.
-
Extract the GPG public keys from the
Release
file. -
Import the content credentials into orcharhino.
-
In the orcharhino management UI, navigate to Content > Products.
-
Click Create Product to create a product named
Debian 11
. -
On the Repositories tab, click New Repository to create three
deb
repositories with the following parameter values:-
Debian 11 main
-
Upstream URL:
http://deb.debian.org/debian/
-
Releases/Distributions:
bullseye
-
Component:
main
-
Architecture:
amd64
-
-
Debian 11 updates
-
Upstream URL:
http://deb.debian.org/debian/
-
Releases/Distributions:
bullseye-updates
-
Component:
main
-
Architecture:
amd64
-
-
Debian 11 security
-
Upstream URL:
http://deb.debian.org/debian-security/
-
Releases/Distributions:
bullseye-security
-
Component:
main
-
Architecture:
amd64
-
-
-
Click Create Product to create a product named
Debian 11 client
. -
On the Repositories tab, click New Repository to create a
deb
repository with the following parameter values:-
Debian 11 client
-
Upstream URL: see ATIX Service Portal
-
Releases/Distributions:
stable
-
Component:
main
-
Architecture:
amd64
-
-
-
To create a product, see Creating a Custom Product.
-
To create a repository, see Adding Custom Deb Repositories.
The ATIX AG Debian and Ubuntu Errata service provides errata for Debian and Ubuntu.
When creating a repository of type An erratum contains the information which packages have to be updated to fix a security issue. Debian and Ubuntu errata are derived from the Debian security announcements (DSA) and the Ubuntu security notices (USN). You must add Debian and Ubuntu errata to the security repository.
For Debian, you need the |
Adding orcharhino Clients for Debian
orcharhino Clients are required to register hosts to orcharhino. You can add them to your orcharhino during the installation process or afterwards. For more information, see Adding orcharhino Clients manually and Using orcharhino Clients gen2 in the ATIX Service Portal.
-
Create a product named
orcharhino Clients for Debian
. For more information, see Creating a Custom Product. -
Create a repository for Debian 12. You can find the upstream URL of all orcharhino Clients in the ATIX Service Portal. For more information, see Adding Custom deb Repositories.
-
Synchronize the orcharhino Clients for Debian to your orcharhino. For more information, see Synchronizing Repositories.
-
Create a content view to make the
.deb
packages consumable by content hosts. For more information, see Creating an Activation Key. -
Create an activation key to register content hosts to orcharhino. For more information, see Creating an Activation Key.
-
Optional: Create a host group to simplify the process of creating hosts. For more information, see Creating a Host Group.
Changing the repository sets status for a host in orcharhino
Repository sets show repositories available to each host. A host will be able to access content from a given repository if that repository is enabled.
-
In the orcharhino management UI, navigate to Hosts > All Hosts and select a host.
-
Select the Content tab, then select the Repository sets subtab. On the tab, there is a set of repositories available to each host with a status of Enabled or Disabled.
-
You can override the default status by using the action menus on each table row by changing the status to Override to disabled, Override to enabled, or Reset to default.
-
You can also bulk select the checkboxes on each table row, and use the vertical ellipsis icon at the top.
For hosts not in the default content view and lifecycle environment, the Repository sets tab shows a toggle group with two options, Limit to environment and Show all. The Limit to environment option shows only repositories that are relevant to the host. The Show all option shows all available repositories including those that may not be in the host’s content view and lifecycle environment. On the Overview tab, click Content view details to view the environment for the host.
Synchronizing repositories
You must synchronize repositories to download content into orcharhino. You can use this procedure for an initial synchronization of repositories or to synchronize repositories manually as you need.
You can also sync all repositories in an organization. For more information, see Synchronizing All Repositories in an Organization.
Create a sync plan to ensure updates on a regular basis. For more information, see Creating a Sync Plan.
The synchronization duration depends on the size of each repository and the speed of your network connection. The following table provides estimates of how long it would take to synchronize content, depending on the available Internet bandwidth:
Single Package (10Mb) | Minor Release (750Mb) | Major Release (6Gb) | |
---|---|---|---|
256 Kbps |
5 Mins 27 Secs |
6 Hrs 49 Mins 36 Secs |
2 Days 7 Hrs 55 Mins |
512 Kbps |
2 Mins 43.84 Secs |
3 Hrs 24 Mins 48 Secs |
1 Day 3 Hrs 57 Mins |
T1 (1.5 Mbps) |
54.33 Secs |
1 Hr 7 Mins 54.78 Secs |
9 Hrs 16 Mins 20.57 Secs |
10 Mbps |
8.39 Secs |
10 Mins 29.15 Secs |
1 Hr 25 Mins 53.96 Secs |
100 Mbps |
0.84 Secs |
1 Min 2.91 Secs |
8 Mins 35.4 Secs |
1000 Mbps |
0.08 Secs |
6.29 Secs |
51.54 Secs |
-
In the orcharhino management UI, navigate to Content > Products and select the Product that contains the repositories that you want to synchronize.
-
Select the repositories that you want to synchronize and click Sync Now.
-
Optional: To view the progress of the synchronization in the orcharhino management UI, navigate to Content > Sync Status and expand the corresponding Product or repository tree.
-
Synchronize an entire Product:
# hammer product synchronize \ --name "My_Product" \ --organization "My_Organization"
-
Synchronize an individual repository:
# hammer repository synchronize \ --name "My_Repository" \ --organization "My_Organization" \ --product "My Product"
Synchronizing all repositories in an organization
Use this procedure to synchronize all repositories within an organization.
-
Log in to your orcharhino Server using SSH.
-
Run the following Bash script:
ORG="My_Organization" for i in $(hammer --no-headers --csv repository list --organization $ORG --fields Id) do hammer repository synchronize --id ${i} --organization $ORG --async done
Download policies overview
orcharhino provides multiple download policies for synchronizing Deb and Yum content and container images. For example, you might want to download only the content metadata while deferring the actual content download for later.
orcharhino Server has the following policies:
- Immediate
-
orcharhino Server downloads all metadata and packages during synchronization.
- On Demand
-
orcharhino Server downloads only the metadata during synchronization. orcharhino Server only fetches and stores packages on the file system when orcharhino Proxies or directly connected clients request them. This setting has no effect if you set a corresponding repository on a orcharhino Proxy to Immediate because orcharhino Server is forced to download all the packages.
The On Demand policy acts as a Lazy Synchronization feature because they save time synchronizing content. The lazy synchronization feature must be used only for Deb and Yum repositories. You can add the packages to content views and promote to lifecycle environments as normal.
orcharhino Proxy has the following policies:
- Immediate
-
orcharhino Proxy downloads all metadata and packages during synchronization. Do not use this setting if the corresponding repository on orcharhino Server is set to On Demand as orcharhino Server is forced to download all the packages.
- On Demand
-
orcharhino Proxy only downloads the metadata during synchronization. orcharhino Proxy fetches and stores packages only on the file system when directly connected clients request them. When you use an On Demand download policy, content is downloaded from orcharhino Server if it is not available on orcharhino Proxy.
- Inherit
-
orcharhino Proxy inherits the download policy for the repository from the corresponding repository on orcharhino Server.
- Streamed Download Policy
-
Streamed Download Policy for orcharhino Proxies permits orcharhino Proxies to avoid caching any content. When content is requested from the orcharhino Proxy, it functions as a proxy and requests the content directly from the orcharhino.
Changing the default download policy
You can set the default download policy that orcharhino applies to repositories that you create in all organizations.
Depending on whether it is a Red Hat, SUSE, or repository, orcharhino uses separate settings. Changing the default value does not change existing settings.
-
In the orcharhino management UI, navigate to Administer > Settings.
-
Click the Content tab.
-
Change the default download policy depending on your requirements:
-
To change the default download policy for a Red Hat repository, change the value of the Default Red Hat Repository download policy setting.
-
To change the default download policy for a non-Red Hat repository, change the value of the Default Custom Repository download policy setting.
-
-
To change the default download policy for Red Hat repositories to one of
immediate
oron_demand
, enter the following command:# hammer settings set \ --name default_redhat_download_policy \ --value immediate
-
To change the default download policy for a repository to one of
immediate
oron_demand
, enter the following command:# hammer settings set \ --name default_download_policy \ --value immediate
Changing the download policy for a repository
You can set the download policy for a repository.
-
In the orcharhino management UI, navigate to Content > Products.
-
Select the required product name.
-
On the Repositories tab, click the required repository name, locate the Download Policy field, and click the edit icon.
-
From the list, select the required download policy and then click Save.
-
List the repositories for an organization:
# hammer repository list \ --organization-label My_Organization_Label
-
Change the download policy for a repository to
immediate
oron_demand
:# hammer repository update \ --download-policy immediate \ --name "My_Repository" \ --organization-label My_Organization_Label \ --product "My_Product"
Mirroring policies overview
Mirroring keeps the local repository exactly in synchronization with the upstream repository. If any content is removed from the upstream repository since the last synchronization, with the next synchronization, it will be removed from the local repository as well.
You can use mirroring policies for finer control over mirroring of repodata and content when synchronizing a repository. For example, if it is not possible to mirror the repodata for a repository, you can set the mirroring policy to mirror only content for this repository.
orcharhino Server has the following mirroring policies:
- Additive
-
Neither the content nor the repodata is mirrored. Thus, only new content added since the last synchronization is added to the local repository and nothing is removed.
- Content Only
-
Mirrors only content and not the repodata. Some repositories do not support metadata mirroring, in such cases you can set the mirroring policy to content only to only mirror the content.
- Complete Mirroring
-
Mirrors content as well as repodata. This is the fastest method. This mirroring policy is only available for Yum content.
Avoid republishing metadata for repositories with Complete Mirror mirroring policy. This also applies to content views containing repositories with the Complete Mirror mirroring policy.
Changing the mirroring policy for a repository
You can set the mirroring policy for a repository.
To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Products.
-
Select the product name.
-
On the Repositories tab, click the repository name, locate the Mirroring Policy field, and click the edit icon.
-
From the list, select a mirroring policy and click Save.
-
List the repositories for an organization:
# hammer repository list \ --organization-label My_Organization_Label
-
Change the mirroring policy for a repository to
additive
,mirror_complete
, ormirror_content_only
:# hammer repository update \ --id 1 \ --mirroring-policy mirror_complete
Refreshing content counts on orcharhino Proxy
If your orcharhino Proxies have synchronized content enabled, you can refresh the number of content counts available to the environments associated with the orcharhino Proxy. This displays the content views inside those environments available to the orcharhino Proxy. You can then expand the content view to view the repositories associated with that content view version.
-
In the orcharhino management UI, navigate to Infrastructure > orcharhino Proxies, and select the orcharhino Proxy where you want to see the synchronized content.
-
Select the Overview tab.
-
Under Content Sync, toggle the Synchronize button to do an Optimized Sync or a Complete Sync to synchronize the orcharhino Proxy which refreshes the content counts.
-
Select the Content tab.
-
Choose an Environment to view content views available to those orcharhino Proxies by clicking >.
-
Expand the content view by clicking > to view repositories available to the content view and the specific version for the environment.
-
View the number of content counts under Packages specific to APT repositories.
-
View the number of errata, package groups, files, container tags, container manifests, and Ansible collections under Additional content.
-
Click the vertical ellipsis in the column to the right next to the environment and click Refresh counts to refresh the content counts synchronized on the orcharhino Proxy under Packages.
Configuring SELinux to permit content synchronization on custom ports
SELinux permits access of orcharhino for content synchronization only on specific ports. By default, connecting to web servers running on the following ports is permitted: 80, 81, 443, 488, 8008, 8009, 8443, and 9000.
-
On orcharhino, to verify the ports that are permitted by SELinux for content synchronization, enter a command as follows:
# semanage port -l | grep ^http_port_t http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
-
To configure SELinux to permit a port for content synchronization, for example 10011, enter a command as follows:
# semanage port -a -t http_port_t -p tcp 10011
Recovering a corrupted repository
In case of repository corruption, you can recover it by using an advanced synchronization, which has three options:
- Optimized Sync
-
Synchronizes the repository bypassing packages that have no detected differences from the upstream packages.
- Complete Sync
-
Synchronizes all packages regardless of detected changes. Use this option if specific packages could not be downloaded to the local repository even though they exist in the upstream repository.
-
In the orcharhino management UI, navigate to Content > Products.
-
Select the product containing the corrupted repository.
-
Select the name of a repository you want to synchronize.
-
To perform optimized sync or complete sync, select Advanced Sync from the Select Action menu.
-
Select the required option and click Sync.
-
Optional: To verify the checksum, click Verify Content Checksum from the Select Action menu.
-
Obtain a list of repository IDs:
# hammer repository list \ --organization "My_Organization"
-
Synchronize a corrupted repository using the necessary option:
-
For the optimized synchronization:
# hammer repository synchronize \ --id My_ID
-
For the complete synchronization:
# hammer repository synchronize \ --id My_ID \ --skip-metadata-check true
-
For the validate content synchronization:
# hammer repository synchronize \ --id My_ID \ --validate-contents true
-
Republishing repository metadata
You can republish repository metadata when a repository distribution does not have the content that should be distributed based on the contents of the repository.
Use this procedure with caution. ATIX AG recommends a complete repository sync or publishing a new content view version to repair broken metadata.
-
In the orcharhino management UI, navigate to Content > Products.
-
Select the product that includes the repository for which you want to republish metadata.
-
On the Repositories tab, select a repository.
-
To republish metadata for the repository, click Republish Repository Metadata from the Select Action menu.
This action is not available for repositories that use the Complete Mirroring policy because the metadata is copied verbatim from the upstream source of the repository.
Republishing content view metadata
Use this procedure to republish content view metadata.
-
In the orcharhino management UI, navigate to Content > Lifecycle > Content Views.
-
Select a content view.
-
On the Versions tab, select a content view version.
-
To republish metadata for the content view version, click Republish repository metadata from the vertical ellipsis icon.
Republishing repository metadata will regenerate metadata for all repositories in the content view version that do not adhere to the Complete Mirroring policy.
Adding an HTTP proxy
Use this procedure to add HTTP proxies to orcharhino. You can then specify which HTTP proxy to use for Products, repositories, and supported compute resources.
To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Infrastructure > HTTP Proxies and select New HTTP Proxy.
-
In the Name field, enter a name for the HTTP proxy.
-
In the URL field, enter the URL for the HTTP proxy, including the port number.
-
If your HTTP proxy requires authentication, enter a Username and Password.
-
Optional: In the Test URL field, enter the HTTP proxy URL, then click Test Connection to ensure that you can connect to the HTTP proxy from orcharhino.
-
Click the Locations tab and add a location.
-
Click the Organization tab and add an organization.
-
Click Submit.
-
On orcharhino Server, enter the following command to add an HTTP proxy:
# hammer http-proxy create \ --name proxy-name \ --url proxy-URL:port-number
If your HTTP proxy requires authentication, add the
--username name
and--password password
options.
Changing the HTTP proxy policy for a product
For granular control over network traffic, you can set an HTTP proxy policy for each Product. A Product’s HTTP proxy policy applies to all repositories in the Product, unless you set a different policy for individual repositories.
To set an HTTP proxy policy for individual repositories, see Changing the HTTP Proxy Policy for a Repository.
-
In the orcharhino management UI, navigate to Content > Products and select the checkbox next to each of the Products that you want to change.
-
From the Select Action list, select Manage HTTP Proxy.
-
Select an HTTP Proxy Policy from the list:
-
Global Default: Use the global default proxy setting.
-
No HTTP Proxy: Do not use an HTTP proxy, even if a global default proxy is configured.
-
Use specific HTTP Proxy: Select an HTTP Proxy from the list. You must add HTTP proxies to orcharhino before you can select a proxy from this list. For more information, see Adding an HTTP Proxy.
-
-
Click Update.
Changing the HTTP proxy policy for a repository
For granular control over network traffic, you can set an HTTP proxy policy for each repository. To use the CLI instead of the orcharhino management UI, see the CLI procedure.
To set the same HTTP proxy policy for all repositories in a Product, see Changing the HTTP Proxy Policy for a Product.
-
In the orcharhino management UI, navigate to Content > Products and click the name of the Product that contains the repository.
-
In the Repositories tab, click the name of the repository.
-
Locate the HTTP Proxy field and click the edit icon.
-
Select an HTTP Proxy Policy from the list:
-
Global Default: Use the global default proxy setting.
-
No HTTP Proxy: Do not use an HTTP proxy, even if a global default proxy is configured.
-
Use specific HTTP Proxy: Select an HTTP Proxy from the list. You must add HTTP proxies to orcharhino before you can select a proxy from this list. For more information, see Adding an HTTP Proxy.
-
-
Click Save.
-
On orcharhino Server, enter the following command, specifying the HTTP proxy policy you want to use:
# hammer repository update \ --http-proxy-policy HTTP_Proxy_Policy \ --id Repository_ID
Specify one of the following options for
--http-proxy-policy
:-
none
: Do not use an HTTP proxy, even if a global default proxy is configured. -
global_default_http_proxy
: Use the global default proxy setting. -
use_selected_http_proxy
: Specify an HTTP proxy using either--http-proxy My_HTTP_Proxy_Name
or--http-proxy-id My_HTTP_Proxy_ID
. To add a new HTTP proxy to orcharhino, see Adding an HTTP Proxy.
-
Creating a sync plan
A sync plan checks and updates the content at a scheduled date and time. In orcharhino, you can create a sync plan and assign products to the plan.
To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Sync Plans and click New Sync Plan.
-
In the Name field, enter a name for the plan.
-
Optional: In the Description field, enter a description of the plan.
-
From the Interval list, select the interval at which you want the plan to run.
-
From the Start Date and Start Time lists, select when to start running the synchronization plan.
-
Click Save.
-
To create the synchronization plan, enter the following command:
# hammer sync-plan create \ --description "My_Description" \ --enabled true \ --interval daily \ --name "My_Products" \ --organization "My_Organization" \ --sync-date "2023-01-01 01:00:00"
-
View the available sync plans for an organization to verify that the sync plan has been created:
# hammer sync-plan list --organization "My_Organization"
Best Practices for Sync Plans
-
Use sync plans to periodically synchronize content to orcharhino.
-
Sync plans are associated with products.
-
Use cron line to specify recurring synchronization using cron expressions.
-
We recommend distributing synchronization tasks over several hours if possible to reduce the task load by creating multiple sync plans with cron line. Using a single sync plan would start all sync tasks at the same time resulting in a high load significantly lowering the performance of your orcharhino. This might also lead to occasional difficulties in the correct assigning of the Pulp tasks.
Table 1. Cron Expression Examples Cron Expression Explanation 0 22 * * 1-5
every night at 22:00 from Monday through Friday
30 3 * * 6,0
at 03:30 on each Saturday and Sunday
15 1-9/2 * * *
15 minutes past every second hour from 1 through 9
30 2 8-14 * *
at 02:30 every day of the month from 8 through 14
Assigning a sync plan to a product
A sync plan checks and updates the content at a scheduled date and time. In orcharhino, you can assign a sync plan to products to update content regularly.
To use the CLI instead of the orcharhino management UI, see the CLI procedure.
-
In the orcharhino management UI, navigate to Content > Products.
-
Select a product.
-
On the Details tab, select a Sync Plan from the drop down menu.
-
Assign a sync plan to a product:
# hammer product set-sync-plan \ --name "My_Product_Name" \ --organization "My_Organization" \ --sync-plan "My_Sync_Plan_Name"
Assigning a sync plan to multiple products
Use this procedure to assign a sync plan to the products in an organization that have been synchronized at least once and contain at least one repository.
-
Run the following Bash script:
ORG="My_Organization" SYNC_PLAN="daily_sync_at_3_a.m" hammer sync-plan create --name $SYNC_PLAN --interval daily --sync-date "2023-04-5 03:00:00" --enabled true --organization $ORG for i in $(hammer --no-headers --csv --csv-separator="|" product list --organization $ORG --per-page 999 | grep -vi not_synced | awk -F'|' '$5 != "0" { print $1}') do hammer product set-sync-plan --sync-plan $SYNC_PLAN --organization $ORG --id $i done
-
After executing the script, view the products assigned to the sync plan:
# hammer product list --organization $ORG --sync-plan $SYNC_PLAN
Limiting synchronization concurrency
By default, each Repository Synchronization job can fetch up to ten files at a time. This can be adjusted on a per repository basis.
Increasing the limit may improve performance, but can cause the upstream server to be overloaded or start rejecting requests. If you are seeing Repository syncs fail due to the upstream servers rejecting requests, you may want to try lowering the limit.
# hammer repository update \ --download-concurrency 5 \ --id Repository_ID \ --organization "My_Organization"
GPG Keys for Debian
You can download the official GPG public keys from debian.org.
You can check which GPG public key is required to verify the Release.gpg
file.
$ wget http://ftp.debian.org/debian/dists/bookworm/Release && wget http://ftp.debian.org/debian/dists/bookworm/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
$ gpg --keyserver keys.gnupg.net --recv-key A7236886F3CCCAAD148A27F80E98404D386FA1D9
$ gpg --keyserver keys.gnupg.net --recv-key 4D64FEC119C2029067D6E791F8D2585B8783D481
$ gpg --armor --export 0146DC6D4A0B2914BDED34DB648ACFD622F3D138 A7236886F3CCCAAD148A27F80E98404D386FA1D9 4D64FEC119C2029067D6E791F8D2585B8783D481 > debian_bookworm_main.txt
$ wget http://ftp.debian.org/debian/dists/bookworm-updates/Release && wget http://ftp.debian.org/debian/dists/bookworm-updates/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key A7236886F3CCCAAD148A27F80E98404D386FA1D9
$ gpg --keyserver keys.gnupg.net --recv-key 4CB50190207B4758A3F73A796ED0E7B82643E131
$ gpg --armor --export A7236886F3CCCAAD148A27F80E98404D386FA1D9 4CB50190207B4758A3F73A796ED0E7B82643E131 > debian_bookworm_updates.txt
$ wget https://security.debian.org/debian-security/dists/bookworm-security/Release && wget https://security.debian.org/debian-security/dists/bookworm-security/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key ED541312A33F1128F10B1C6C54404762BBB6E853
$ gpg --keyserver keys.gnupg.net --recv-key B0CAB9266E8C3929798B3EEEBDE6D2B9216EC7A8
$ gpg --armor --export ED541312A33F1128F10B1C6C54404762BBB6E853 B0CAB9266E8C3929798B3EEEBDE6D2B9216EC7A8 > debian_bookworm_security.txt
$ wget http://ftp.debian.org/debian/dists/bullseye/Release && wget http://ftp.debian.org/debian/dists/bullseye/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver pgp.mit.edu --recv-key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
$ gpg --keyserver pgp.mit.edu --recv-key A4285295FC7B1A81600062A9605C66F00D6C9793
$ gpg --keyserver pgp.mit.edu --recv-key A7236886F3CCCAAD148A27F80E98404D386FA1D9
$ gpg --armor --export DC30D7C23CBBABEE 605C66F00D6C9793 73A4F27B8DD47936 > debian_bullseye_main.txt
$ wget http://ftp.debian.org/debian/dists/bullseye-updates/Release && wget http://ftp.debian.org/debian/dists/bullseye-updates/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver pgp.mit.edu --recv-key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
$ gpg --keyserver pgp.mit.edu --recv-key A7236886F3CCCAAD148A27F80E98404D386FA1D9
$ gpg --armor --export DC30D7C23CBBABEE 73A4F27B8DD47936 > debian_bullseye_updates.txt
$ wget https://security.debian.org/debian-security/dists/bullseye-security/Release && wget https://security.debian.org/debian-security/dists/bullseye-security/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver pgp.mit.edu --recv-key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
$ gpg --keyserver pgp.mit.edu --recv-key ED541312A33F1128F10B1C6C54404762BBB6E853
$ gpg --armor --export 4DFAB270CAA96DFA A48449044AAD5C5D > debian_bullseye_security.txt
$ wget http://ftp.debian.org/debian/dists/buster/Release && wget http://ftp.debian.org/debian/dists/buster/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
$ gpg --keyserver keys.gnupg.net --recv-key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
$ gpg --keyserver keys.gnupg.net --recv-key 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517
$ gpg --armor --export E0B11894F66AEC98 DC30D7C23CBBABEE DCC9EFBF77E11517 > debian_buster_main.txt
$ wget http://ftp.debian.org/debian/dists/buster-updates/Release && wget http://ftp.debian.org/debian/dists/buster-updates/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
$ gpg --keyserver keys.gnupg.net --recv-key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
$ gpg --armor --export E0B11894F66AEC98 DC30D7C23CBBABEE > debian_buster_updates.txt
$ wget http://security.debian.org/debian-security/dists/buster/updates/Release && wget http://security.debian.org/debian-security/dists/buster/updates/Release.gpg
$ gpg --verify Release.gpg Release
$ gpg --keyserver keys.gnupg.net --recv-key 379483D8B60160B155B372DDAA8E81B4331F7F50
$ gpg --keyserver keys.gnupg.net --recv-key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
$ gpg --armor --export EDA0D2388AE22BA9 4DFAB270CAA96DFA > debian_buster_security.txt
The text and illustrations on this page are licensed by ATIX AG under a Creative Commons Attribution Share Alike 4.0 International ("CC BY-SA 4.0") license. This page also contains text from the official Foreman documentation which uses the same license ("CC BY-SA 4.0"). |