mtpti5iD/redhat-docs_dataset huggingface dataset:
8.4.3. Using Yum Variables You can use and reference the following built-in variables in yum commands and in all Yum configuration files (that is, /etc/yum.conf and all .repo files in the /etc/yum.repos.d/ directory): USDreleasever You can use this variable to reference the release version of Red Hat Enterprise Linux. Yum obtains the value of USDreleasever from the distroverpkg= value line in the /etc/yum.conf configuration file. If there is no such line in /etc/yum.conf , then yum infers the correct value by deriving the version number from the redhat-release-server package. The value of USDreleasever typically consists of the major release number and the variant of Red Hat Enterprise Linux, for example 6Client , or 6Server . USDarch You can use this variable to refer to the system's CPU architecture as returned when calling Python's os.uname() function. Valid values for USDarch include i686 and x86_64 . USDbasearch You can use USDbasearch to reference the base architecture of the system. For example, i686 machines have a base architecture of i386 , and AMD64 and Intel 64 machines have a base architecture of x86_64 . USDYUM0-9 These ten variables are each replaced with the value of any shell environment variables with the same name. If one of these variables is referenced (in /etc/yum.conf for example) and a shell environment variable with the same name does not exist, then the configuration file variable is not replaced. To define a custom variable or to override the value of an existing one, create a file with the same name as the variable (without the " USD " sign) in the /etc/yum/vars/ directory, and add the desired value on its first line. For example, repository descriptions often include the operating system name. To define a new variable called USDosname , create a new file with " Red Hat Enterprise Linux " on the first line and save it as /etc/yum/vars/osname : Instead of " Red Hat Enterprise Linux 6 " , you can now use the following in the .repo files:

Commands:
~]# echo "Red Hat Enterprise Linux" > /etc/yum/vars/osname
name=USDosname USDreleasever
Connecting to Red Hat Insights through Insights proxy Red Hat Insights 1-latest Insights proxy allows those with constraints preventing Internet access to connect to Red Hat Insights Red Hat Customer Content Services

Commands:
subscription-manager repos --enable=insights-proxy-for-rhel-9-x86_64-rpms
subscription-manager repos--enable=insights-proxy-for-rhel-9-aarch64-rpms
dnf install -y rhproxy
rpm -q rhproxy
useradd rhproxy
id rhproxy
[rhproxy@server ~]USD podman login registry.redhat.io
firewall-cmd --permanent --add-port=3128/tcp
firewall-cmd --permanent --add-port=8443/tcp
firewall-cmd --reload
[rhproxy@server ~] USD rhproxy install
[rhproxy@server ~] USD rhproxy start
[rhproxy@server ~] USD rhproxy status
[rhproxy@server ~]USD curl -L -x http://USD(hostname):3128 https://mirrors.fedoraproject.org/
curl -k -L https://<rhproxy-hostname>:8443/download/bin/configure-client.sh -o configure-client.sh
chmod +x configure-client.sh
./configure-client.sh --configure --proxy-host <rhproxy-hostname>
insights-client --test-connection
[rhproxy@server ~]USD rhproxy status
[rhproxy@server ~]USD rhproxy restart
curl -x http://USD(hostname):3128 https://<host name>
[rhpproxy@server ~]USD rhproxy restart
[root@client ~] ./configure-client.sh --unconfigure
https://cert-api.access.redhat.com:443
https://cert.cloud.redhat.com:443
https://cert.console.redhat.com:443
https://console.redhat.com:443
https://sso.redhat.com:443
proxy_hostname =
proxy_scheme = http
proxy_port =
proxy_user =
proxy_password =
no_proxy =
/etc/insights-client/insights-client.conf
insights-client --test-connection --net-debug
End API URL Connection Test: SUCCESS Connectivity tests completed successfully See `/var/log/insights-client/insights-client.log` for more details.
5.6. Performing a Two-Administrator Enrollment Enrolling machines as clients in the IdM domain is a two-part process. A host entry is created for the client (and stored in the 389 Directory Server instance), and then a keytab is created to provision the client. Both parts are performed automatically by the ipa-client-install command. It is also possible to perform those steps separately; this allows for administrators to prepare machines and the IdM server configuration in advance of actually configuring the clients. This allows more flexible setup scenarios, including bulk deployments. When performing a manual enrollment, the host entry is created separately, and then enrollment is completed when the client script is run, which creates the requisite keytab. Note There are two ways to set the password. You can either supply your own or have IdM generate a random one. There may be a situation where an administrator in one group is prohibited from creating a host entry and, therefore, from simply running the ipa-client-install command and allowing it to create the host. However, that administrator may have the right to run the command after a host entry exists. In that case, one administrator can create the host entry manually, then the second administrator can complete the enrollment by running the ipa-client-install command. An administrator creates the host entry, as described in Section 5.4.2, "Other Examples of Adding a Host Entry" . The second administrator installs the IdM client packages on the machine, as in Section 5.3, "Configuring a Linux System as an IdM Client" . When the second administrator runs the setup script, he must pass his Kerberos password and username (principal) with the ipa-client-install command. For example: The keytab is generated on the server and provisioned to the client machine, so that the client machine is not able to connect to the IdM domain. The keytab is saved with root:root ownership and 0600 permissions.

Commands:
ipa-client-install -w secret -p admin2
Chapter 10. Updating SSSD Containers This procedure describes how you can update System Security Services Daemon (SSSD) containers if a new version of the rhel7/sssd image is released. Procedure Stop the SSSD service: If SSSD is running as a system container: If SSSD is running as an application container: Use the docker rm command to remove the image: Install the latest SSSD image: Start the SSSD service: If SSSD runs as a system container: If SSSD runs as an application container, start each container using the atomic start command:

Commands:
systemctl stop sssd
atomic stop <container_name>
docker rm rhel7/sssd
atomic install rhel7/sssd
systemctl start sssd
atomic start <container_name>
6.3. Removing Browser Configuration for Ticket Delegation (For Upgrading from 6.2) As part of establishing Kerberos authentication, a principal is given a ticket granting ticket (TGT). Whenever that principal attempts to contact a service or application within the Kerberos domain, the service checks for an active TGT and then requests its own service-specific ticket from the TGT for that principal to access that service. As part of configuring the web browser used to access the IdM web UI (and any other Kerberos-aware web applications), versions of Identity Management required that the TGT delegation be forwarded to the IdM server. This required adding the delegation-uris parameter to the about:config setup in Firefox: In Red Hat Enterprise Linux 6.3, Identity Management uses the Kerberos Services for User to Proxy (S4U2Proxy), so this additional delegation step is no longer required. Updating Existing Configured Browsers For browsers which have already been configured to use the Identity Management web UI, the delegation-uris setting can be cleared after upgrading to ipa-server-3.0.0 or ipa-client-3.0.0 . There is no need to restart the browser after changing the delegation-uris setting. Updating configure.jar for New Browser Configuration The browser configuration is defined in the configure.jar file. This JAR file is generated when the server is installed and it is not updated with other files when IdM is updated. Any browsers configured will still have the delegation-uris parameter set unnecessarily, even after the IdM server is upgraded. However, the configure.jar file can be updated. The preferences.html file in configure.jar sets the delegation-uris parameter. The updated preferences.html file can be added to configure.jar , and then configure.jar can be re-signed and re-deployed on the IdM servers. Note Only update the configure.jar file on the initial IdM server. This is the master server, and it is the only server which has a signing certificate. Then propagate the updated file to the other servers and replicas. Update the packages on the initial IdM master server (the first instance). This will bring in the 3.0 UI packages, including the configure.jar file. Back up the existing configure.jar file. Create a temporary working directory. Copy the updated preferences.html file to the working directory. Use the signtool command (one of the NSS utilities) to add the new preferences.html file and re-sign the configure.jar file. The -e option tells the tool to sign only files with a .html extension. The -Z option creates a new JAR file. Copy the regenerated configure.jar file to all other IdM servers and replicas.

Commands:
network.negotiate-auth.delegation-uris .example.com
mv /usr/share/ipa/html/configure.jar /usr/share/ipa/html/configure.jar.old
mkdir /tmp/sign
cp /usr/share/ipa/html/preferences.html /tmp/sign
signtool -d /etc/httpd/alias -k Signing-Cert -Z /usr/share/ipa/html/configure.jar -e ".html" -p `cat /etc/httpd/alias/pwdfile.txt` /tmp/sign
1.2. SystemTap Capabilities SystemTap was originally developed to provide functionality for Red Hat Enterprise Linux similar to Linux probing tools such as dprobes and the Linux Trace Toolkit. SystemTap aims to supplement the existing suite of Linux monitoring tools by providing users with the infrastructure to track kernel activity. In addition, SystemTap combines this capability with two attributes: Flexibility: SystemTap's framework allows users to develop simple scripts for investigating and monitoring a wide variety of kernel functions, system calls, and other events that occur in kernel space. With this, SystemTap is not so much a tool as it is a system that allows you to develop your own kernel-specific forensic and monitoring tools. Ease-of-Use: as mentioned earlier, SystemTap allows users to probe kernel-space events without having to resort to the lengthy instrument, recompile, install, and reboot the kernel process. Most of the SystemTap scripts enumerated in Chapter 4, Useful SystemTap Scripts demonstrate system forensics and monitoring capabilities not natively available with other similar tools (such as top , OProfile , or ps ). These scripts are provided to give readers extensive examples of the application of SystemTap, which in turn will educate them further on the capabilities they can employ when writing their own SystemTap scripts.

Commands:
Chapter 5. Installing the multi-model serving platform For deploying small and medium-sized models, OpenShift AI includes a multi-model serving platform that is based on the ModelMesh component. On the multi-model serving platform, multiple models can be deployed from the same model server and share the server resources. To install the multi-model serving platform or ModelMesh, follow the steps described in Installing Red Hat OpenShift AI components by using the web console .

Commands:
16.3. Configuring a DHCPv4 Client To configure a DHCP client manually, modify the /etc/sysconfig/network file to enable networking and the configuration file for each network device in the /etc/sysconfig/network-scripts directory. In this directory, each device should have a configuration file named ifcfg-eth0 , where eth0 is the network device name. Make sure that the /etc/sysconfig/network-scripts/ifcfg-eth0 file contains the following lines: To use DHCP, set a configuration file for each device. Other options for the network script include: DHCP_HOSTNAME - Only use this option if the DHCP server requires the client to specify a host name before receiving an IP address. PEERDNS= <answer> , where <answer> is one of the following: yes - Modify /etc/resolv.conf with information from the server. This is the default. no - Do not modify /etc/resolv.conf . If you prefer using a graphical interface, see Chapter 10, NetworkManager for instructions on using NetworkManager to configure a network interface to use DHCP. Note For advanced configurations of client DHCP options such as protocol timing, lease requirements and requests, dynamic DNS support, aliases, as well as a wide variety of values to override, prepend, or append to client-side configurations, see the dhclient and dhclient.conf man pages.

Commands:
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
15.5. Configuring Bootstrap Credentials When you use bind distinguished name (DN) groups in a replication agreement, there can be situations where the group is not present or outdated: During online initialization where you must authenticate to the replica before the database is initialized When you use GSSAPI as authentication method and the Kerberos credentials are changed If you configured bootstrap credentials in a replication agreement, Directory Server uses these credentials in case that the connection failed because one of the following errors: LDAP_INVALID_CREDENTIALS (err=49) LDAP_INAPPROPRIATE_AUTH (err=48) LDAP_NO_SUCH_OBJECT (err=32) If the bind succeeds with the bootstrap credentials, the server establishes the replication connection and a new replication session begins. This allows any updates to the bind DN group members to be updated. By default on the replication session, Directory Server uses the default credentials in the agreement, that now succeeds. The bootstrap credentials also fail, Directory Server stops trying to connect. Procedure To set the bootstrap credentials when you create a replication agreement: To set the bootstrap credentials in an existing replication agreement:

Commands:
dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt create ... --bootstrap-bind-dn " bind_DN " --bootstrap-bind-passwd " password " --bootstrap-bind-method bind_method --bootstrap-conn-protocol connection protocol
dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set --suffix=" suffix " --bootstrap-bind-dn " bind_DN " --bootstrap-bind-passwd " password " --bootstrap-bind-method bind_method --bootstrap-conn-protocol connection protocol agreement_name
Managing security compliance Red Hat Satellite 6.16 Plan and configure SCAP compliance policies, deploy the policies to hosts, and monitor compliance of your hosts Red Hat Satellite Documentation Team satellite-doc-list@redhat.com

Commands:
hammer scap-content list --location " My_Location " --organization " My_Organization "
hammer scap-content bulk-upload --type default
rpm2cpio scap-security-guide-0.1.69-3.el8_6.noarch.rpm | cpio -iv --to-stdout ./usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml > ssg-rhel-8.6-ds.xml
hammer scap-content bulk-upload --type directory --directory /usr/share/xml/scap/my_content/ --location " My_Location " --organization " My_Organization "
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml | grep "WARNING" WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2' points out to the remote 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2'. Use '--fetch-remote-resources' option to download it. WARNING: Skipping 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2' file which is referenced from datastream
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml | grep "WARNING" WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2' points out to the remote 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2'. Use '--fetch-remote-resources' option to download it. WARNING: Skipping 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2' file which is referenced from datastream
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml Referenced check files: ssg-rhel8-oval.xml system: http://oval.mitre.org/XMLSchema/oval-definitions-5 ssg-rhel8-ocil.xml system: http://scap.nist.gov/schema/ocil/2 security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 system: http://oval.mitre.org/XMLSchema/oval-definitions-5
curl -o security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2
curl -o /root/ security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 http:// satellite.example.com /pulp/content/ My_Organization_Label /Library/custom/ My_Product_Label / My_Repo_Label / security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2
failed > 5
host ~ prod- AND date > "Jan 1, 2023"
"1 hour ago" AND compliance_policy = date = "1 hour ago" AND compliance_policy = rhel7_audit
xccdf_rule_passed = xccdf_org.ssgproject.content_rule_firefox_preferences-auto-download_actions
xccdf_rule_failed = xccdf_org.ssgproject.content_rule_firefox_preferences-auto-download_actions
xccdf_rule_othered = xccdf_org.ssgproject.content_rule_firefox_preferences-auto-download_actions
Architecture OpenShift Dedicated 4 Architecture overview. Red Hat OpenShift Documentation Team

Commands:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: None
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: Unknown
Chapter 1. About OpenShift Virtualization Learn about OpenShift Virtualization's capabilities and support scope. 1.1. What you can do with OpenShift Virtualization OpenShift Virtualization is an add-on to OpenShift Container Platform that allows you to run and manage virtual machine workloads alongside container workloads. OpenShift Virtualization adds new objects into your OpenShift Container Platform cluster via Kubernetes custom resources to enable virtualization tasks. These tasks include: Creating and managing Linux and Windows virtual machines Connecting to virtual machines through a variety of consoles and CLI tools Importing and cloning existing virtual machines Managing network interface controllers and storage disks attached to virtual machines Live migrating virtual machines between nodes An enhanced web console provides a graphical portal to manage these virtualized resources alongside the OpenShift Container Platform cluster containers and infrastructure. OpenShift Virtualization is tested with OpenShift Container Storage (OCS) and designed to use with OCS features for the best experience. You can use OpenShift Virtualization with the OVN-Kubernetes , OpenShift SDN , or one of the other certified default Container Network Interface (CNI) network providers listed in Certified OpenShift CNI Plugins . 1.1.1. OpenShift Virtualization supported cluster version OpenShift Virtualization 4.9 is supported for use on OpenShift Container Platform 4.9 clusters. To use the latest z-stream release of OpenShift Virtualization, you must first upgrade to the latest version of OpenShift Container Platform.

Commands:
Chapter 16. Installing a three-node cluster on AWS In OpenShift Container Platform version 4.14, you can install a three-node cluster on Amazon Web Services (AWS). 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 AWS Marketplace image is not supported. 16.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 user-provisioned infrastructure in AWS by using CloudFormation 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: {} 16.2. steps Installing a cluster on AWS with customizations Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation 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: {}
8.187. rubygems 8.187.1. RHBA-2013:1694 - rubygems bug fix and enhancement update Updated rubygems packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. RubyGems is the Ruby standard for publishing and managing third-party libraries. Bug Fix BZ# 559707 Previously, the specification file listed an incorrect license. The specification file has been updated to fix the license, which is MIT now. Enhancement BZ# 788001 New release of rubygems package introduces rubygems-devel subpackage with RPM macros for easier packaging and better compatibility with Fedora. Users of rubygems are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands: