mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Preparing to install on {rh-virtualization-first} 1.1. Prerequisites You reviewed details about the OpenShift Container Platform installation and update processes. You have a supported combination of versions in the Support Matrix for OpenShift Container Platform on Red Hat Virtualization (RHV) . You read the documentation on selecting a cluster installation method and preparing it for users . 1.2. Choosing a method to install OpenShift Container Platform on RHV You can install OpenShift Container Platform on installer-provisioned or user-provisioned infrastructure. The default installation type uses installer-provisioned infrastructure, where the installation program provisions the underlying infrastructure for the cluster. You can also install OpenShift Container Platform on infrastructure that you provision. If you do not use infrastructure that the installation program provisions, you must manage and maintain the cluster resources yourself. See Installation process for more information about installer-provisioned and user-provisioned installation processes. 1.2.1. Installing a cluster on installer-provisioned infrastructure You can install a cluster on Red Hat Virtualization (RHV) virtual machines that are provisioned by the OpenShift Container Platform installation program, by using one of the following methods: Installing a cluster quickly on RHV : You can quickly install OpenShift Container Platform on RHV virtual machines that the OpenShift Container Platform installation program provisions. Installing a cluster on RHV with customizations : You can install a customized OpenShift Container Platform cluster on installer-provisioned guests on RHV. The installation program allows for some customization to be applied at the installation stage. Many other customization options are available post-installation . 1.2.2. Installing a cluster on user-provisioned infrastructure You can install a cluster on RHV virtual machines that you provision, by using one of the following methods: Installing a cluster on RHV with user-provisioned infrastructure : You can install OpenShift Container Platform on RHV virtual machines that you provision. You can use the provided Ansible playbooks to assist with the installation. Installing a cluster on RHV in a restricted network : You can install OpenShift Container Platform on RHV in a restricted or disconnected network by creating an internal mirror of the installation release content. You can use this method to install a user-provisioned cluster that does not require an active internet connection to obtain the software components. You can also use this installation method to ensure that your clusters only use container images that satisfy your organizational controls on external content.

Commands:
2.2.4.4. Do Not Use the no_root_squash Option By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. This changes the owner of all root-created files to nfsnobody , which prevents uploading of programs with the setuid bit set. If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by Trojans for other users to inadvertently execute.

Commands:
Access control Red Hat Advanced Cluster Management for Kubernetes 2.11 Access control

Commands:
create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>
create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:subscription-admin --user=<username>
create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
create rolebinding <role-binding-name> -n <application-namespace> --clusterrole=admin --user=<username>
create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:subscription-admin --user=<username>
create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
create rolebinding <role-binding-name> -n <application-namespace> --clusterrole=view --user=<username>
create clusterrole rhacm-edit-policy --resource=policies.policy.open-cluster-management.io,placementbindings.policy.open-cluster-management.io,policyautomations.policy.open-cluster-management.io,policysets.policy.open-cluster-management.io --verb=create,delete,get,list,patch,update,watch
create rolebinding rhacm-edit-policy -n rhacm-policies --clusterrole=rhacm-edit-policy --user=<username>
create clusterrole rhacm-view-policy --resource=policies.policy.open-cluster-management.io --verb=get,list,watch
create rolebinding rhacm-view-policy -n <cluster name> --clusterrole=rhacm-view-policy --user=<username>
auth can-i create ManagedClusterView -n <managedClusterName> --as=<user>
create role create-managedclusterview --verb=create --resource=managedclusterviews -n <managedClusterName>
create rolebinding user-create-managedclusterview-binding --role=create-managedclusterview --user=<user> -n <managedClusterName>
auth can-i list <resource-type> -n <namespace> --as=<rbac-user>
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: <replace-with-name-of-rolebinding> namespace: <replace-with-name-of-managedcluster-namespace> subjects: - kind: <replace with User|Group|ServiceAccount> apiGroup: rbac.authorization.k8s.io name: <replace with name of User|Group|ServiceAccount> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: view
openssl genrsa -out serverCAKey.pem 2048 openssl genrsa -out clientCAKey.pem 2048
openssl req -x509 -sha256 -new -nodes -key serverCAKey.pem -days 1825 -out serverCACert.pem openssl req -x509 -sha256 -new -nodes -key clientCAKey.pem -days 1825 -out clientCACert.pem
-n open-cluster-management-observability create secret tls observability-server-ca-certs --cert ./serverCACert.pem --key ./serverCAKey.pem
-n open-cluster-management-observability create secret tls observability-client-ca-certs --cert ./clientCACert.pem --key ./clientCAKey.pem
Chapter 8. Validate images used for volume creation The Block Storage Service (cinder) automatically validates the signature of any downloaded, signed image during volume from image creation. The signature is validated before the image is written to the volume. To improve performance, you can use the Block Storage Image-Volume cache to store validated images for creating new volumes. For more information, see Configure and Enable the Image-Volume Cache in the Storage Guide . Note Cinder image signature validation does not work with Red Hat Ceph Storage or RBD volumes. 8.1. Validate the image signature on a new volume This procedure demonstrates how you can use validate a volume signature created from a signed image. Log in to a controller node. View cinder's image validation activities in the Volume log, /var/log/containers/cinder/cinder-volume.log . For example, you can expect the following entry when the instance is booted: Alternatively, you can use the openstack volume list and cinder volume show commands. Use the openstack volume list command to locate the volume ID. Run the cinder volume show command on a compute node: Locate the volume_image_metadata section with the line signature verified : True .

Commands:
2018-05-24 12:48:35.256 1 INFO cinder.image.image_utils [req-7c271904-4975-4771-9d26-cbea6c0ade31 b464b2fd2a2140e9a88bbdacf67bdd8c a3db2f2beaee454182c95b646fa7331f - default default] Image signature verification succeeded for image d3396fa0-2ea2-4832-8a77-d36fa3f2ab27
cinder volume show <VOLUME_ID>
cinder show d0db26bb-449d-4111-a59a-6fbb080bb483 +--------------------------------+-------------------------------------------------+ | Property | Value | +--------------------------------+-------------------------------------------------+ | attached_servers | [] | | attachment_ids | [] | | availability_zone | nova | | bootable | true | | consistencygroup_id | None | | created_at | 2018-10-12T19:04:41.000000 | | description | None | | encrypted | True | | id | d0db26bb-449d-4111-a59a-6fbb080bb483 | | metadata | | | migration_status | None | | multiattach | False | | name | None | | os-vol-host-attr:host | centstack.localdomain@nfs#nfs | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 1a081dd2505547f5a8bb1a230f2295f4 | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available | | updated_at | 2018-10-12T19:05:13.000000 | | user_id | ad9fe430b3a6416f908c79e4de3bfa98 | | volume_image_metadata | checksum : f8ab98ff5e73ebab884d80c9dc9c7290 | | | container_format : bare | | | disk_format : qcow2 | | | image_id : 154d4d4b-12bf-41dc-b7c4-35e5a6a3482a | | | image_name : cirros-0.3.5-x86_64-disk | | | min_disk : 0 | | | min_ram : 0 | | | signature_verified : False | | | size : 13267968 | | volume_type | nfs | +--------------------------------+-------------------------------------------------+
4.215. pam_krb5 4.215.1. RHBA-2011:1704 - pam_krb5 bug fix update An updated pam_krb5 package that fixes various bugs is now available for Red Hat Enterprise Linux 6. The pam_krb5 package allows PAM-aware applications to check user passwords with the help of a Kerberos KDC. Bug Fixes BZ# 690832 When a client logged into a remote host using SSH with GSSAPI authentication, configured to re-delegate credentials when the client obtains fresh credentials, pam_krb5 created a new credential cache on the remote host in addition to the cache created by SSH. Consequently, the credential cache that pam_krb5 had created for the user's session would not be updated when they were renewed on the client. This update prevents pam_krb5 from creating its own cache in the scenario described, so the credential delegation mechanism is not interfered with. BZ# 700520 Prior to this update, when a client attempted to perform a password change after using a non-password-based pre-authentication mechanism (such as a Smart Card), the pam_krb5 module would unnecessarily prompt for the user's PIN (twice). This update corrects this bug. BZ# 720609 , BZ# 722489 , BZ# 733803 When a client, using SSH, logged into a remote host using the PasswordAuthentication mechanism, two credential caches would be created for the user on the remote host, but only one of them would be removed when the user logged out. This update no longer creates the second, redundant cache. All users of pam_krb5 are advised to upgrade to this updated package, which fixes these bugs.

Commands:
18.10. Attaching a Virtual Network to a Guest To attach a virtual network to a guest: In the Virtual Machine Manager window, highlight the guest that will have the network assigned. Figure 18.19. Selecting a virtual machine to display From the Virtual Machine Manager Edit menu, select Virtual Machine Details . Figure 18.20. Displaying the virtual machine details Click the Add Hardware button on the Virtual Machine Details window. Figure 18.21. The Virtual Machine Details window In the Add new virtual hardware window, select Network from the left pane, and select your network name ( network1 in this example) from the Host device menu and click Finish . Figure 18.22. Select your network from the Add new virtual hardware window The new network is now displayed as a virtual network interface that will be presented to the guest upon launch. Figure 18.23. New network shown in guest hardware list

Commands:
9.3. Central Processing Unit (CPU) Each host within a cluster has a number of virtual CPUs (vCPUs). The virtual CPUs are in turn exposed to guests running on the hosts. All virtual CPUs exposed by hosts within a cluster are of the type selected when the cluster was initially created via Red Hat Virtualization Manager. Mixing of virtual CPU types within a cluster is not possible. Each available virtual CPU type has characteristics based on physical CPUs of the same name. The virtual CPU is indistinguishable from the physical CPU to the guest operating system. Note Support for x2APIC: All virtual CPU models provided by Red Hat Enterprise Linux 7 hosts include support for x2APIC. This provides an Advanced Programmable Interrupt Controller (APIC) to better handle hardware interrupts.

Commands:
5.369. yaboot 5.369.1. RHBA-2012:0791 - yaboot bug fix update An updated yaboot package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The yaboot package provides a boot loader for Open Firmware based PowerPC systems. It can be used to boot IBM eServer System p machines. Bug Fixes BZ# 711001 Prior to this update, the /etc/yaboot.conf parser failed during install when the quoted string was too long. This update modifies the code to significantly extend the size of quoted strings. Now, the /etc/yaboot.conf file parses as expected. BZ# 750199 Prior to this update, yaboot could only be build using the mock tool which creates a 32-bit PowerPC environment in chroot. This updated package supports building with rpmbuild. All users of yaboot are advised to upgrade to this updated package, which fixes these bugs.

Commands:
10.5. Troubleshooting virt-who 10.5.1. Why is the hypervisor status red? Scenario: On the server side, you deploy a guest on a hypervisor that does not have a subscription. 24 hours later, the hypervisor displays its status as red. To remedy this situation you must get a subscription for that hypervisor. Or, permanently migrate the guest to a hypervisor with a subscription. 10.5.2. I have subscription status errors, what do I do? Scenario: Any of the following error messages display: System not properly subscribed Status unknown Late binding of a guest to a hypervisor through virt-who (host/guest mapping) To find the reason for the error open the virt-who log file, named rhsm.log , located in the /var/log/rhsm/ directory.

Commands:
Chapter 87. KafkaClientAuthenticationPlain schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationPlain schema properties To configure SASL-based PLAIN authentication, set the type property to plain . The SASL PLAIN authentication mechanism requires a username and password. An example SASL-based PLAIN client authentication configuration for Kafka Connect authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name Warning The SASL PLAIN mechanism will transfer the username and password across the network in cleartext. Only use SASL PLAIN authentication if TLS encryption is enabled. In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, create a text file that contains the password, in cleartext, to use for authentication: echo -n <password> > <my_password>.txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt Example secret for PLAIN client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. 87.1. KafkaClientAuthenticationPlain schema properties The type property is a discriminator that distinguishes use of the KafkaClientAuthenticationPlain type from KafkaClientAuthenticationTls , KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationOAuth . It must have the value plain for the type KafkaClientAuthenticationPlain . Property Property type Description type string Must be plain . username string Username used for the authentication. passwordSecret PasswordSecretSource Reference to the Secret which holds the password.

Commands:
authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name
echo -n <password> > <my_password>.txt
create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm
31.7. Persistent Module Loading As shown in Example 31.1, "Listing information about a kernel module with lsmod" , many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by creating a new <file_name> .modules file in the /etc/sysconfig/modules/ directory, where <file_name> is any descriptive name of your choice. Your <file_name> .modules files are treated by the system startup scripts as shell scripts, and as such should begin with an interpreter directive (also called a " bang line " ) as their first line: Example 31.6. First line of a file_name .modules file Additionally, the <file_name> .modules file should be executable. You can make it executable by running: For example, the following bluez-uinput.modules script loads the uinput module: Example 31.7. /etc/sysconfig/modules/bluez-uinput.modules #!/bin/sh if [ ! -c /dev/input/uinput ] ; then exec /sbin/modprobe uinput >/dev/null 2>&1 fi The if -conditional statement on the third line ensures that the /dev/input/uinput file does not already exist (the ! symbol negates the condition), and, if that is the case, loads the uinput module by calling exec /sbin/modprobe uinput . Note that the uinput module creates the /dev/input/uinput file, so testing to see if that file exists serves as verification of whether the uinput module is loaded into the kernel. The following >/dev/null 2>&1 clause at the end of that line redirects any output to /dev/null so that the modprobe command remains quiet.

Commands:
#!/bin/sh
modules]# chmod +x <file_name> .modules
#!/bin/sh if [ ! -c /dev/input/uinput ] ; then exec /sbin/modprobe uinput >/dev/null 2>&1 fi
Installation overview OpenShift Container Platform 4.12 Overview content for installing OpenShift Container Platform Red Hat OpenShift Documentation Team

Commands:
oc get nodes
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
oc get machines -A
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
capabilities: baselineCapabilitySet: v4.11 1 additionalEnabledCapabilities: 2 - CSISnapshot - Console - Storage
Chapter 15. EL Overview The Unified Expression Language (EL) was originally specified as part of the JSP 2.1 standard (JSR-245), but it is now available as a standalone language. Apache Camel integrates with JUEL ( http://juel.sourceforge.net/ ), which is an open source implementation of the EL language. Adding JUEL package To use EL in your routes you need to add a dependency on camel-juel to your project as shown in Example 15.1, "Adding the camel-juel dependency" . Example 15.1. Adding the camel-juel dependency Static import To use the el() static method in your application code, include the following import statement in your Java source files: Variables Table 15.1, "EL variables" lists the variables that are accessible when using EL. Table 15.1. EL variables Variable Type Value exchange org.apache.camel.Exchange The current Exchange in org.apache.camel.Message The IN message out org.apache.camel.Message The OUT message Example Example 15.2, "Routes using EL" shows two routes that use EL. Example 15.2. Routes using EL

Commands:
<!-- Maven POM File --> <properties> <camel-version>2.23.2.fuse-7_13_0-00013-redhat-00001</camel-version> </properties> <dependencies> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-juel</artifactId> <version>USD{camel-version}</version> </dependency> </dependencies>
import static org.apache.camel.language.juel.JuelExpression.el;
<camelContext> <route> <from uri="seda:foo"/> <filter> <language language="el">USD{in.headers.foo == 'bar'}</language> <to uri="seda:bar"/> </filter> </route> <route> <from uri="seda:foo2"/> <filter> <language language="el">USD{in.headers['My Header'] == 'bar'}</language> <to uri="seda:bar"/> </filter> </route> </camelContext>
12.4. Using rndc BIND includes a utility called rndc which allows command line administration of the named daemon from the localhost or from a remote host. In order to prevent unauthorized access to the named daemon, BIND uses a shared secret key authentication method to grant privileges to hosts. This means an identical key must be present in both /etc/named.conf and the rndc configuration file, /etc/rndc.conf . 12.4.1. Configuring /etc/named.conf In order for rndc to connect to a named service, there must a controls statement in the BIND server's /etc/named.conf file. The controls statement, shown in the following example, allows rndc to connect from the localhost. This statement tells named to listen on the default TCP port 953 of the loopback address and allow rndc commands coming from the localhost, if the proper key is given. The <key-name> specifies a name in the key statement within the /etc/named.conf file. The example illustrates a sample key statement. In this case, the <key-value> uses the HMAC-MD5 algorithm. Use the following command to generate keys using the HMAC-MD5 algorithm: A key with at least a 256-bit length is a good idea. The actual key that should be placed in the <key-value> area can be found in the <key-file-name> file generated by this command. Warning Because /etc/named.conf is world-readable, it is a good idea to place the key statement in a separate file, readable only by root, and then use an include statement to reference it. For example:

Commands:
controls { inet 127.0.0.1 allow { localhost; } keys { <key-name> ; }; };
key " <key-name> " { algorithm hmac-md5; secret " <key-value> "; };
dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>
include "/etc/rndc.key";
probe::ioscheduler_trace.elv_abort_request Name probe::ioscheduler_trace.elv_abort_request - Fires when a request is aborted. Synopsis ioscheduler_trace.elv_abort_request Values disk_major Disk major no of request. disk_minor Disk minor number of request. rq_flags Request flags. elevator_name The type of I/O elevator currently enabled. rq Address of request. name Name of the probe point

Commands: