mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 88. DockerOutput schema reference Used in: Build The type property is a discriminator that distinguishes use of the DockerOutput type from ImageStreamOutput . It must have the value docker for the type DockerOutput . Property Property type Description image string The full name which should be used for tagging and pushing the newly built image. For example quay.io/my-organization/my-custom-connect:latest . Required. pushSecret string Container Registry Secret with the credentials for pushing the newly built image. additionalKanikoOptions string array Configures additional options which will be passed to the Kaniko executor when building the new Connect image. Allowed options are: --customPlatform, --insecure, --insecure-pull, --insecure-registry, --log-format, --log-timestamp, --registry-mirror, --reproducible, --single-snapshot, --skip-tls-verify, --skip-tls-verify-pull, --skip-tls-verify-registry, --verbosity, --snapshotMode, --use-new-run. These options will be used only on OpenShift where the Kaniko executor is used. They will be ignored on OpenShift. The options are described in the Kaniko GitHub repository . Changing this field does not trigger new build of the Kafka Connect image. type string Must be docker .

Commands:
Chapter 7. Configuring router properties By default, AMQ Interconnect operates in standalone mode with a randomly-generated ID. If you want to use this router in a router network, you must change these properties. Procedure Open the /etc/qpid-dispatch/qdrouterd.conf configuration file. In the router section, specify the mode and ID. This example shows a router configured to operate in interior mode: mode Specify one of the following modes: standalone - Use this mode if the router does not communicate with other routers and is not part of a router network. When operating in this mode, the router only routes messages between directly connected endpoints. interior - Use this mode if the router is part of a router network and needs to collaborate with other routers. edge - Use this mode if the router is an edge router that will connect to a network of interior routers. id The unique identifier for the router. This ID will also be the container name at the AMQP protocol level. If necessary, configure any additional properties for the router. For information about additional attributes, see router in the qdrouterd.conf man page.

Commands:
router { mode: interior id: Router.A }
7.315. xulrunner 7.315.1. RHSA-2013:0614 - Critical: xulrunner security update Updated xulrunner packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having critical security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link associated with the description below. XULRunner provides the XUL Runtime environment for applications using the Gecko layout engine. Security Fix CVE-2013-0787 A flaw was found in the way XULRunner handled malformed web content. A web page containing malicious content could cause an application linked against XULRunner (such as Mozilla Firefox) to crash or execute arbitrary code with the privileges of the user running the application. Red Hat would like to thank the Mozilla project for reporting this issue. Upstream acknowledges VUPEN Security via the TippingPoint Zero Day Initiative project as the original reporter. For technical details regarding this flaw, refer to the Mozilla security advisories . All XULRunner users should upgrade to these updated packages, which correct this issue. After installing the update, applications using XULRunner must be restarted for the changes to take effect.

Commands:
Chapter 13. Installing a three-node cluster on Azure In OpenShift Container Platform version 4.14, you can install a three-node cluster on Microsoft Azure. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an Azure Marketplace image is not supported. 13.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on Azure using ARM templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 13.2. steps Installing a cluster on Azure with customizations Installing a cluster on Azure using ARM templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
20.3.4. Generating Key Pairs If you do not want to enter your password every time you use ssh , scp , or sftp to connect to a remote machine, you can generate an authorization key pair. Keys must be generated for each user. To generate keys for a user, use the following steps as the user who wants to connect to remote machines. If you complete the steps as root, only root will be able to use the keys. Starting with OpenSSH version 3.0, ~/.ssh/authorized_keys2 , ~/.ssh/known_hosts2 , and /etc/ssh_known_hosts2 are obsolete. SSH Protocol 1 and 2 share the ~/.ssh/authorized_keys , ~/.ssh/known_hosts , and /etc/ssh/ssh_known_hosts files. Red Hat Enterprise Linux 4 uses SSH Protocol 2 and RSA keys by default. Note If you reinstall and want to save your generated key pair, backup the .ssh directory in your home directory. After reinstalling, copy this directory back to your home directory. This process can be done for all users on your system, including root. 20.3.4.1. Generating an RSA Key Pair for Version 2 Use the following steps to generate an RSA key pair for version 2 of the SSH protocol. This is the default starting with OpenSSH 2.9. To generate an RSA key pair to work with version 2 of the protocol, type the following command at a shell prompt: Accept the default file location of ~/.ssh/id_rsa . Enter a passphrase different from your account password and confirm it by entering it again. The public key is written to ~/.ssh/id_rsa.pub . The private key is written to ~/.ssh/id_rsa . Never distribute your private key to anyone. Change the permissions of the .ssh directory using the following command: Copy the contents of ~/.ssh/id_rsa.pub into the file ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys exist, append the contents of the file ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys on the other machine. Change the permissions of the authorized_keys file using the following command: If you are running GNOME, skip to Section 20.3.4.4, "Configuring ssh-agent with GNOME" . If you are not running the X Window System, skip to Section 20.3.4.5, "Configuring ssh-agent " .

Commands:
ssh-keygen -t rsa
chmod 755 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
Chapter 1. Product overview Red Hat Decision Manager is an open-source decision management platform that combines business rules management, complex event processing, Decision Model & Notation (DMN) execution, and Red Hat build of OptaPlanner for solving planning problems. It automates business decisions and makes that logic available to the entire business. Business assets such as rules, decision tables, and DMN models are stored in a central repository. This ensures consistency, transparency, and the ability to audit across the business. Business users can modify business logic without requiring assistance from IT personnel. Red Hat Decision Manager 7.13 provides increased stability, several fixed issues, and new features. Red Hat Decision Manager is fully supported on Red Hat OpenShift Container Platform and can be installed on various platforms. For information about the support policy for Red Hat Decision Manager, see the Release maintenance plan for Red Hat Decision Manager 7.x and Red Hat Process Automation Manager 7.x .

Commands:
Chapter 6. Users and Groups The control of users and groups is a core element of Red Hat Enterprise Linux system administration. Users can be either people, meaning accounts tied to physical users, or accounts which exist for specific applications to use. Groups are logical expressions of organization, tying users together for a common purpose. Users within a group can read, write, or execute files owned by that group. Each user and group has a unique numerical identification number called a userid ( UID ) and a groupid ( GID ) respectively. A user who creates a file is also the owner and group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and everyone else. The file owner can be changed only by the root user as well as access permissions can be changed by both the root user and the owner of the file. Red Hat Enterprise Linux supports access control lists ( ACLs ) for files and directories which allow permissions for specific users outside of the owner to be set. For more information about using ACLs, refer to the chapter titled Access Control Lists in the System Administrators Guide . Proper management of users and groups as well as the effective management of file permissions are among the most important tasks a system administrator undertakes. For a detailed look at strategies for managing users and groups, refer to the chapter titled Managing User Accounts and Resource Access in the Red Hat Enterprise Linux Introduction to System Adminitration guide. 6.1. User and Group Management Tools Managing users and groups can be a tedious task, but Red Hat Enterprise Linux provides tools and conventions to make their management easier. The easiest way to manage users and groups is through the graphical application, User Manager ( system-config-users ). For more information on User Manager , refer to the chapter titled User and Group Configuration in the System Administrators Guide . The following command line tools can also be used to manage users and groups: useradd , usermod , and userdel - Industry-standard methods of adding, deleting and modifying user accounts. groupadd , groupmod , and groupdel - Industry-standard methods of adding, deleting, and modifying user groups. gpasswd - Industry-standard method of administering the /etc/group file. pwck , grpck - Tools used for the verification of the password, group, and associated shadow files. pwconv , pwunconv - Tools used for the conversion of passwords to shadow passwords and back to standard passwords. For an overview of users and group management, refer to the Red Hat Enterprise Linux Introduction to System Adminitration . For a detailed look at command line tools for managing users and groups, see the chapter titled User and Group Configuration in the System Administrators Guide .

Commands:
Chapter 12. 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 6 and Red Hat Enterprise Linux 7 on AMD64 and Intel 64 architectures. 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 allows for optional use of alternative package versions on Red Hat Enterprise Linux. By using the scl utility, users can pick and choose which package version they want to run at any time. Red Hat Developer Toolset is now a part of Red Hat Software Collections. It is included as a separate Software Collection. 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, Eclipse development platform, and other development, debugging, and performance monitoring tools. 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:
Chapter 6. Verifying the optimal number of KDC worker processes using IdM Healthcheck You can use the Healthcheck tool in Identity Management (IdM) to verify that the Kerberos Key Distribution Center (KDC) is configured to use the optimal number of krb5kdc worker processes, which should be equal to the number of CPU cores on the host. You can find the test for the correct number of KDC worker processes under the ipahealthcheck.ipa.kdc source. As the Healthcheck tool includes many tests, you can narrow down the results by including only the KDC worker tests by adding the --source ipahealthcheck.ipa.kdc option. Prerequisites The KDC worker process Healthcheck tool is only available on RHEL 8.7 or newer. You must perform Healthcheck tests as the root user. Procedure To run the check for KDC worker processes, enter: If the number of KDC worker processes matches the number of CPU cores, the test returns SUCCESS as a result: The test returns a WARNING if the number of worker processes does not match the number of CPU cores. In the following example, a host with 2 cores is configured to have only one KDC worker process: The test also outputs a WARNING if there are no configured workers. In the following example, the KRB5KDC_ARGS variable is missing from the /etc/sysconfig/krb5kdc configuration file: Additional resources man ipa-healthcheck

Commands:
ipa-healthcheck --source ipahealthcheck.ipa.kdc
{ "source": "ipahealthcheck.ipa.kdc", "check": "KDCWorkersCheck", "result": " SUCCESS ", "uuid": "68f6e20a-0aa9-427d-8fdc-fbb8196d56cd", "when": "20230105162211Z", "duration": "0.000157", "kw": { "key": "workers" } }
{ "source": "ipahealthcheck.ipa.kdc", "check": "KDCWorkersCheck", "result": " WARNING ", "uuid": "972b7782-1616-48e0-bd5c-49a80c257895", "when": "20230105122236Z", "duration": "0.203049", "kw": { "key": 'workers', "cpus": 2, "workers": 1, "expected": " The number of CPUs {cpus} does not match the number of workers {workers} in {sysconfig} " } }
{ "source": "ipahealthcheck.ipa.kdc", "check": "KDCWorkersCheck", "result": " WARNING ", "uuid": "5d63ea86-67b9-4638-a41e-b71f4 56efed7", "when": "20230105162526Z", "duration": "0.000135", "kw": { "key": "workers", "sysconfig": "/etc/sysconfig/krb5kdc", "msg": " KRB5KDC_ARGS is not set in {sysconfig} " } }
Chapter 2. Integrations in Red Hat Developer Hub Red Hat Developer Hub integrates seamlessly with Red Hat OpenShift Container Platform and other tools, enabling comprehensive development and deployment workflows across enterprise. 2.1. Integration with Red Hat OpenShift Container Platform Red Hat Developer Hub is fully integrated with Red Hat OpenShift Container Platform, offering: Operators to manage application lifecycle. Access to advanced OpenShift capabilities such as service mesh, serverless functions, GitOps, and distributed tracing. Pipelines and GitOps plugins for streamlined cloud-native workflows. 2.2. Integration with Red Hat Trusted Application Pipeline Red Hat Trusted Application Pipeline (RHTAP) enhances Red Hat Developer Hub by providing secure CI/CD capabilities that integrate security measures into every stage of the development process. While Red Hat Developer Hub focuses on the inner loop (code, build, and test), RHTAP manages the outer loop, automating: Code scanning Image building Vulnerability detection Deployment RHTAP includes tools like Red Hat Trusted Artifact Signer (TAS) for code integrity, Red Hat Trusted Profile Analyzer (TPA) for automated Software build of Materials (SBOM) creation, and Red Hat Advanced Cluster Security (ACS) for vulnerability scanning. 2.3. Extending Backstage with Red Hat Developer Hub Red Hat Developer Hub which is a fully supported, enterprise-grade productized version of upstream Backstage extends the upstream project by adding: Enhanced search capabilities that aggregate data from CI/CD pipelines, cloud providers, source control, and more. A centralized software catalog for locating applications, APIs, and resources. Automation through open-source plugins that expand Backstage's core functionality. Simplified technical documentation using Markdown and GitHub, with integrated search for easy navigation.

Commands:
Chapter 1. OpenShift Container Platform 4.18 Documentation Welcome to the official OpenShift Container Platform 4.18 documentation, where you can learn about OpenShift Container Platform and start exploring its features. To navigate the OpenShift Container Platform 4.18 documentation, you can use one of the following methods: Use the navigation bar to browse the documentation. Select the task that interests you from Learn more about OpenShift Container Platform . OpenShift Container Platform has a variety of layered offerings to add additional functionality and extend the capabilities of a cluster. For more information, see OpenShift Container Platform Operator Life Cycles

Commands:
3. Driver Updates The kernel-utils package provides microcode_ctl utility code and the microcode data itself - supplied by Intel - to assist the kernel in updating the CPU microcode at system boot time. This microcode supports all current Intel x86- and Intel 64-based CPU models and takes advantage of the mechanism built-in to Linux that allows microcode to be updated after system boot. When loaded, the updated microcode corrects the behavior of various Intel processors, as described in processor specification updates issued by Intel for those processors. In the Red Hat Enterprise Linux 4.9 release the kernel-utils package has been updated with the 2010-09-14 version of Intel's microcode.

Commands:
Appendix A. Component Versions This appendix is a list of components and their versions in the Red Hat Enterprise Linux 6.3 release. Table A.1. Component Versions Component Version Kernel 2.6.32-279 QLogic qla2xxx driver 8.04.00.02.06.3-k QLogic qla2xxx firmware ql23xx-firmware-3.03.27-3.1 ql2100-firmware-1.19.38-3.1 ql2200-firmware-2.02.08-3.1 ql2400-firmware-5.06.05-1 ql2500-firmware-5.06.05-1 Emulex lpfc driver 8.3.5.68.2p iSCSI initiator utils 6.2.0.872-41 DM-Multipath 0.4.9-56 LVM 2.02.95-10

Commands:
Chapter 7. Enabling accelerators Before you can use an accelerator in OpenShift AI, you must install the relevant software components. The installation process varies based on the accelerator type. Prerequisites You have logged in to your OpenShift cluster. You have the cluster-admin role in your OpenShift cluster. You have installed an accelerator and confirmed that it is detected in your environment. Procedure Follow the appropriate documentation to enable your accelerator: NVIDIA GPUs : See Enabling NVIDIA GPUs . Intel Gaudi AI accelerators : See Enabling Intel Gaudi AI accelerators . AMD GPUs : See Enabling AMD GPUs . After installing your accelerator, create an accelerator profile as described in: Working with accelerator profiles . Verification From the Administrator perspective, go to the Operators Installed Operators page. Confirm that the following Operators appear: The Operator for your accelerator Node Feature Discovery (NFD) Kernel Module Management (KMM) The accelerator is correctly detected a few minutes after full installation of the Node Feature Discovery (NFD) and the relevant accelerator Operator. The OpenShift command line interface (CLI) displays the appropriate output for the GPU worker node. For example, here is output confirming that an NVIDIA GPU is detected:

Commands:
Expected output when the accelerator is detected correctly describe node <node name> Capacity: cpu: 4 ephemeral-storage: 313981932Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 16076568Ki nvidia.com/gpu: 1 pods: 250 Allocatable: cpu: 3920m ephemeral-storage: 288292006229 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 12828440Ki nvidia.com/gpu: 1 pods: 250
17.4. Accessing Delegated Services For both services and hosts, if a client has delegated authority, it can obtain a keytab for that principal on the local machine. For services, this has the format service/hostname@REALM . For hosts, the service is host . With kinit , use the -k option to load a keytab and the -t option to specify the keytab. For example: To access a host: To access a service:

Commands:
kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
kinit -kt /etc/httpd/conf/krb5.keytab HTTP/ipa.example.com@EXAMPLE.COM