mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Assigning a Puppet class to a host group Use a host group to assign the ntp Puppet class to multiple hosts at once. Every host you deploy based on this host group has this Puppet class installed. Procedure In the Satellite web UI, navigate to Configure > Host Groups to create a host group or edit an existing one. On the Host Group tab, set the following parameters: The Lifecycle Environment describes the stage in which certain versions of content are available to hosts. The Content View is comprised of products and allows for version control of content repositories. The Environment allows you to supply a group of hosts with their own dedicated configuration. Navigate to the Puppet ENC tab. Add the Puppet class to the Included Classes or to the Included Config Groups if a Puppet config group is configured. Click Submit to save the changes.

Commands:
7.6. SDL 7.6.1. RHBA-2015:0656 - SDL bug fix update Updated SDL packages that fix one bug are now available for Red Hat Enterprise Linux 6. Simple DirectMedia Layer (SDL) is a cross-platform multimedia library designed to provide fast access to the graphics frame buffer and audio device. Bug Fix BZ# 1125304 Due to the changes made to X Virtual Frame Buffer (Xvfb) in Red Hat Enterprise Linux 6.6, the XGrabPointer() function started to return a value of 0 if used on an SDL window placed outside the Xvfb root window boundaries. Consequently, if an SDL program expected the original return value, a problem could occur. With this update, the SDL library conforms to the new behavior, and programs using this library now work as expected. Users of SDL are advised to upgrade to these updated packages, which fix this bug. 7.6.2. RHBA-2015:1435 - SDL bug fix update Updated SDL packages that fix one bug are now available for Red Hat Enterprise Linux 6. Simple DirectMedia Layer (SDL) is a cross-platform multimedia library designed to provide fast access to the graphics frame buffer and audio device. Bug Fix BZ# 1205603 An attempt to upgrade the SDL library without upgrading the libX11 library could result in applications emitting the following error: symbol lookup error: /usr/lib64/libSDL-1.2.so.0: undefined symbol: _XGetRequest after updating SDL This update modifies the SDL spec file to prevent an upgrade on systems with a too outdated libX11 version. As a result, the mentioned error no longer occurs. Users of SDL are advised to upgrade to these updated packages, which fix this bug.

Commands:
6.2.3. Ordered Resource Sets A common situation is for an administrator to create a chain of ordered resources, where, for example, resource A starts before resource B which starts before resource C. If your configuration requires that you create a set of resources that is colocated and started in order, you can configure a resource group that contains those resources, as described in Section 5.5, "Resource Groups" . If, however, you need to configure resources to start in order and the resources are not necessarily colocated, you can create an order constraint on a set or sets of resources with the pcs constraint order set command. You can set the following options for a set of resources with the pcs constraint order set command. sequential , which can be set to true or false to indicate whether the set of resources must be ordered relative to each other. Setting sequential to false allows a set to be ordered relative to other sets in the ordering constraint, without its members being ordered relative to each other. Therefore, this option makes sense only if multiple sets are listed in the constraint; otherwise, the constraint has no effect. require-all , which can be set to true or false to indicate whether all of the resources in the set must be active before continuing. Setting require-all to false means that only one resource in the set needs to be started before continuing on to the set. Setting require-all to false has no effect unless used in conjunction with unordered sets, which are sets for which sequential is set to false . action , which can be set to start , promote , demote or stop , as described in Table 6.2, "Properties of an Order Constraint" . You can set the following constraint options for a set of resources following the setoptions parameter of the pcs constraint order set command. id , to provide a name for the constraint you are defining. score , to indicate the degree of preference for this constraint. For information on this option, see Table 6.3, "Properties of a Colocation Constraint" . If you have three resources named D1 , D2 , and D3 , the following command configures them as an ordered resource set.

Commands:
pcs constraint order set resource1 resource2 [ resourceN ]... [ options ] [set resourceX resourceY ... [ options ]] [setoptions [ constraint_options ]]
pcs constraint order set D1 D2 D3
Chapter 10. Managing custom software repositories You can configure a repository in the /etc/dnf/dnf.conf file or in a .repo file in the /etc/yum.repos.d/ directory. Important Define your repositories in the .repo file instead of /etc/dnf/dnf.conf . The /etc/dnf/dnf.conf file contains the [main] section and can contain one or more repository sections ( [ <repository-ID> ] ) that you can use to set repository-specific options. The values you define in individual repository sections of the /etc/dnf/dnf.conf file override values set in the [main] section. 10.1. DNF repository options The /etc/dnf/dnf.conf configuration file contains repository sections with a unique repository ID in brackets ( [] ). You can use such sections to define individual DNF repositories. Important Repository IDs in [] must be unique. For a complete list of available repository ID options, see the [ <repository-ID> ] OPTIONS section of the dnf.conf(5) man page on your system. 10.2. Adding a DNF repository You can add a DNF repository to your system by using the dnf config-manager --add-repo command. Procedure Add a repository to your system: Note that repositories added by this command are enabled by default. Review and, optionally, update the repository settings that the command has created in the /etc/yum.repos.d/<repository_URL>.repo file: Warning Obtaining and installing software packages from unverified or untrusted sources other than Red Hat certificate-based Content Delivery Network ( CDN ) is a potential security risk, and can lead to security, stability, compatibility, and maintainability issues. 10.3. Enabling a DNF repository You can enable a DNF repository added to your system by using the dnf config-manager command. Procedure Enable a repository: 10.4. Disabling a DNF repository You can disable a DNF repository added to your system by using the dnf config-manager command. Procedure Disable a repository:

Commands:
dnf config-manager --add-repo <repository_URL>
cat /etc/yum.repos.d/ <repository_URL >.repo
dnf config-manager --enable <repository_id>
dnf config-manager --disable <repository_id>
Chapter 12. Configuring kube-rbac-proxy for Serving The kube-rbac-proxy component provides internal authentication and authorization capabilities for Knative Serving. 12.1. Configuring kube-rbac-proxy resources for Serving You can globally override resource allocation for the kube-rbac-proxy container by using the OpenShift Serverless Operator CR. Note You can also override resource allocation for a specific deployment. The following configuration sets Knative Serving kube-rbac-proxy minimum and maximum CPU and memory allocation: KnativeServing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4 1 Sets minimum CPU allocation. 2 Sets minimum RAM allocation. 3 Sets maximum CPU allocation. 4 Sets maximum RAM allocation.

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4
Chapter 4. Adding user preferences You can change the default preferences for your profile to meet your requirements. You can set your default project, topology view (graph/list), editing medium (form or YAML), and language preferences. The changes made to the user preferences are automatically saved. 4.1. Setting user preferences You can set the default user preferences for your cluster. Procedure Log in to the OpenShift Container Platform web console using your login credentials. Use the masthead to access the user preferences under the user profile. In the General section: In the Theme field, you can set the theme that you want to work in. The console defaults to the selected theme each time you log in. In the Perspective field, you can set the default perspective you want to be logged in to. You can select the Administrator or the Developer perspective as required. If a perspective is not selected, you are logged into the perspective you last visited. In the Project field, select a project you want to work in. The console defaults to the project every time you log in. In the Topology field, you can set the topology view to default to the graph or list view. If not selected, the console defaults to the last view you used. In the Create/Edit resource method field, you can set a preference for creating or editing a resource. If both the form and YAML options are available, the console defaults to your selection. In the Language section, select Default browser language to use the default browser language settings. Otherwise, select the language that you want to use for the console. In the Notifications section, you can toggle display notifications created by users for specific projects on the Overview page or notification drawer. In the Applications section: You can view the default Resource type . For example, if the OpenShift Serverless Operator is installed, the default resource type is Serverless Deployment . Otherwise, the default resource type is Deployment . You can select another resource type to be the default resource type from the Resource Type field.

Commands:
Chapter 1. Configuring GitLab Webhooks to enable automated pipeline triggers Set up webhooks in GitLab to automatically trigger pipeline runs in RHDH upon code updates. Prerequisites You must have integrated GitLab during the RHTAP install process. You have a source repository. To locate your application's source code: On the RHDH platform, navigate to the Catalog , select an appropriate application where GitLab is configured as the repository host. Go to the Overview tab and select View Source to open the repository where your application's source code is housed. You have a Webhook URL and a Secret Token. You can find these credentials in your private.env file. Procedure Navigate to your GitLab source repository. On the Red Hat Developer Hub platform, navigate to the Catalog , select an application where GitLab is configured as the repository host. Go to the Overview tab and select View Source to open the repository for your source code. Go to Settings > Webhooks . In the URL field, enter the webhook URL. In the Secret Token field, enter the secret token. In the Trigger section: Select Push events . Select Merge request events . Click Add Webhook . Verification Commit any change to the source repository in GitLab. Navigate to the CI tab in RHDH. Verify that a pipeline run is triggered for your code push.

Commands:
Chapter 3. Getting support 3.1. Getting support Windows Container Support for OpenShift Container Platform is provided and available as an optional, installable component. Windows Container Support for Red Hat OpenShift is not part of the OpenShift Container Platform subscription. It requires an additional Red Hat subscription and is supported according to the Scope of coverage and Service level agreements . You must have this separate subscription to receive support for Windows Container Support for Red Hat OpenShift. Without this additional Red Hat subscription, deploying Windows container workloads in production clusters is not supported. You can request support through the Red Hat Customer Portal . For more information, see the Red Hat OpenShift Container Platform Life Cycle Policy document for Red Hat OpenShift support for Windows Containers .

Commands:
Chapter 22. Red Hat Software Collections Red Hat Software Collections is a Red Hat content set that provides a set of dynamic programming languages, database servers, and related packages that you can install and use on all supported releases of Red Hat Enterprise Linux 7 on AMD64 and Intel 64 architectures, the 64-bit ARM architecture, IBM Z, and IBM POWER, little endian. Certain components are available also for all supported releases of Red Hat Enterprise Linux 6 on AMD64 and Intel 64 architectures. Red Hat Developer Toolset is designed for developers working on the Red Hat Enterprise Linux platform. It provides current versions of the GNU Compiler Collection, GNU Debugger, and other development, debugging, and performance monitoring tools. Red Hat Developer Toolset is included as a separate Software Collection. Dynamic languages, database servers, and other tools distributed with Red Hat Software Collections do not replace the default system tools provided with Red Hat Enterprise Linux, nor are they used in preference to these tools. Red Hat Software Collections uses an alternative packaging mechanism based on the scl utility to provide a parallel set of packages. This set enables optional use of alternative package versions on Red Hat Enterprise Linux. By using the scl utility, users can choose which package version they want to run at any time. Important Red Hat Software Collections has a shorter life cycle and support term than Red Hat Enterprise Linux. For more information, see the Red Hat Software Collections Product Life Cycle . See the Red Hat Software Collections documentation for the components included in the set, system requirements, known problems, usage, and specifics of individual Software Collections. See the Red Hat Developer Toolset documentation for more information about the components included in this Software Collection, installation, usage, known problems, and more.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) Azure clusters. Note Only internal OpenShift Data Foundation clusters are supported on Microsoft Azure. See Planning your deployment for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the appropriate deployment process based on your requirement: Deploy OpenShift Data Foundation on Microsoft Azure Deploy standalone Multicloud Object Gateway component

Commands:
Appendix D. Using AMQ Broker with the examples The AMQ .NET examples require a running message broker with a queue named amq.topic . Use the procedures below to install and start the broker and define the queue. D.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . D.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... D.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named amq.topic . USD <broker-instance-dir> /bin/artemis queue create --name amq.topic --address amq.topic --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. D.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:16 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name amq.topic --address amq.topic --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
21.2.2. Mounting NFS File Systems using autofs A third option for mounting an NFS share is the use of the autofs service. Autofs uses the automount daemon to manage your mount points by only mounting them dynamically when they are accessed. Autofs consults the master map configuration file /etc/auto.master to determine which mount points are defined. It then starts an automount process with the appropriate parameters for each mount point. Each line in the master map defines a mount point and a separate map file that defines the file systems to be mounted under this mount point. For example, the /etc/auto.misc file might define mount points in the /misc directory; this relationship would be defined in the /etc/auto.master file. Each entry in auto.master has three fields. The first field is the mount point. The second field is the location of the map file, and the third field is optional. The third field can contain information such as a timeout value. For example, to mount the directory /proj52 on the remote machine penguin.example.net at the mount point /misc/myproject on your machine, add the following line to auto.master : , add the following line to /etc/auto.misc : The first field in /etc/auto.misc is the name of the /misc subdirectory. This subdirectory is created dynamically by automount. It should not actually exist on the client machine. The second field contains mount options such as rw for read and write access. The third field is the location of the NFS export including the hostname and directory. Note The directory /misc must exist on the local file system. There should be no subdirectories in /misc on the local file system. To start the autofs service, at a shell prompt, type the following command: To view the active mount points, type the following command at a shell prompt: If you modify the /etc/auto.master configuration file while autofs is running, you must tell the automount daemon(s) to reload by typing the following command at a shell prompt: To learn how to configure autofs to start at boot time, and for information on managing services, refer to Chapter 19, Controlling Access to Services .

Commands:
/misc /etc/auto.misc --timeout 60
myproject -rw,soft,intr,rsize=8192,wsize=8192 penguin.example.net:/proj52
/sbin/service autofs restart
/sbin/service autofs status
/sbin/service autofs reload
3.5. GNU Privacy Guard (GPG) GnuPG (GPG) is an open source version of PGP that allows you to sign and and also encrypt a file or an email message. This is useful to maintain integrity of the message or file and also protects the confidentiality of the information contained within the file or email. In the case of email, GPG provides dual protection. Not only can it provide Data at Rest protection but also Data in Motion protection once the message has been sent across the network. Refer to Section 3.1, "Data at Rest" and Section 3.2, "Data in Motion" for more information about these concepts. GPG is used to identify yourself and authenticate your communications, including those with people you do not know. GPG allows anyone reading a GPG-signed email to verify its authenticity. In other words, GPG allows someone to be reasonably certain that communications signed by you actually are from you. GPG is useful because it helps prevent third parties from altering code or intercepting conversations and altering the message. 3.5.1. Creating GPG Keys in GNOME To create a GPG Key in GNOME, follow these steps: Install the Seahorse utility, which makes GPG key management easier: To create a key, from the Applications Accessories menu select Passwords and Encryption Keys , which starts the application Seahorse . From the File menu select New and then PGP Key . Then click Continue . Type your full name, email address, and an optional comment describing who you are (for example: John C. Smith, jsmith@example.com, Software Engineer). Click Create . A dialog is displayed asking for a passphrase for the key. Choose a strong passphrase but also easy to remember. Click OK and the key is created. Warning If you forget your passphrase, you will not be able to decrypt the data. To find your GPG key ID, look in the Key ID column to the newly created key. In most cases, if you are asked for the key ID, prepend 0x to the key ID, as in 0x6789ABCD . You should make a backup of your private key and store it somewhere secure.

Commands:
~]# yum install seahorse
9.6. Actions 9.6.1. Force Remove Data Center Action An API user forces the removal of a data center when encountering unresolvable problems with storage domains, such as the loss of connection to a master storage domain or a lack of available hosts when deleting storage domains. The API includes a force action to help with these situations. This action removes database entries associated with a chosen data center before the API removes the data center from the Red Hat Virtualization environment. This means the API removes the data center regardless of associated storage domains. This action requires a DELETE method. The request body contains an action representation with the force parameter set to true . The request also requires an additional Content-type: application/xml header to process the XML representation in the body. Example 9.16. Force remove action on a data center This action: Deletes all database information for data storage domains associated the data center; Deletes all database information for resources, such as virtual machines and templates, on data storage domains associated the data center; Detaches iso and export storage domains from the data center; and Deletes the database information for the data center. This action overrides the requirement for a data center to be empty before deletion. Important This action only removes the database entries for resources associated with the data center. The data storage domains associated with the data center require manual format before reuse. Metadata for iso and export domains require manual cleaning prior to use on another data center.

Commands:
DELETE /ovirt-engine/api/datacenters/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <force>true</force> </action>