mtpti5iD/redhat-docs_dataset huggingface dataset:
Access control Red Hat Advanced Cluster Management for Kubernetes 2.12 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
8.138. pam 8.138.1. RHEA-2013:1734 - pam enhancement update Updated pam packages that add one enhancement are now available for Red Hat Enterprise Linux 6. Pluggable Authentication Modules (PAM) provide a system to set up authentication policies without the need to recompile programs to handle authentication. Enhancement BZ# 976033 During TTY auditing, it is usually not necessary or even not desirable to log passwords that are being entered by the audited operator. This update adds an enhancement to the pam_tty_audit PAM module, so that passwords entered in the TTY console are logged only in case the "log_passwd" option is used. As a result, passwords are no longer logged, unless the "log_passwd" option of pam_tty_audit is used. Note that this option is not available in kernel versions available prior to Red Hat Enterprise Linux 6.5. Users of pam are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Chapter 5. Overriding the cluster-wide default node selector for OpenShift Data Foundation post deployment When a cluster-wide default node selector is used for OpenShift Data Foundation, the pods generated by container storage interface (CSI) daemonsets are able to start only on the nodes that match the selector. To be able to use OpenShift Data Foundation from nodes which do not match the selector, override the cluster-wide default node selector by performing the following steps in the command line interface : Procedure Specify a blank node selector for the openshift-storage namespace. Delete the original pods generated by the DaemonSets.

Commands:
oc annotate namespace openshift-storage openshift.io/node-selector=
delete pod -l app=csi-cephfsplugin -n openshift-storage delete pod -l app=csi-rbdplugin -n openshift-storage
Chapter 26. Managing Certificates and Certificate Authorities 26.1. Lightweight Sub-CAs If your IdM installation is configured with the integrated Certificate System (CS) certificate authority (CA), you are able to create lightweight sub-CAs. They enable you to configure services, like virtual private network (VPN) gateways, to accept only certificates issued by one sub-CA. At the same time, you can configure other services to accept only certificates issued by a different sub-CA or the root CA. If you revoke the intermediate certificate of a sub-CA, all certificates issued by this sub-CA are automatically invalid. If you set up IdM using the integrated CA, the automatically created ipa CA is the root CA of the certificate system. All sub-CAs you create, are subordinated to this root CA. 26.1.1. Creating a Lightweight Sub-CA For details on creating a sub-CA, see the section called "Creating a Sub-CA from the Web UI" the section called "Creating a Sub-CA from the Command Line" Creating a Sub-CA from the Web UI To create a new sub-CA named vpn-ca : Open the Authentication tab, and select the Certificates subtab. Select Certificate Authorities and click Add . Enter the name and subject DN for the CA. Figure 26.1. Adding a CA The subject DN must be unique in the IdM CA infrastructure. Creating a Sub-CA from the Command Line To create a new sub-CA named vpn-ca , enter: Name Name of the CA. Authority ID Automatically created, individual ID for the CA. Subject DN Subject distinguished name (DN). The subject DN must be unique in the IdM CA infrastructure. Issuer DN Parent CA that issued the sub-CA certificate. All sub-CAs are created as a child of the IdM root CA. To verify that the new CA signing certificate has been successfully added to the IdM database, run: Note The new CA certificate is automatically transferred to all replicas when they have a certificate system instance installed. 26.1.2. Removing a Lightweight Sub-CA For details on deleting a sub-CA, see the section called "Removing a Sub-CA from the Web UI" the section called "Removing a Sub-CA from the Command Line" Removing a Sub-CA from the Web UI Open the Authentication tab, and select the Certificates subtab. Select Certificate Authorities . Select the sub-CA to remove and click Delete . Click Delete to confirm. Removing a Sub-CA from the Command Line To delete a sub-CA, enter:

Commands:
ipa ca-add vpn-ca --subject=" CN=VPN,O=IDM.EXAMPLE.COM " ------------------- Created CA "vpn-ca" ------------------- Name: vpn-ca Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc Subject DN: CN=VPN,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
certutil -d /etc/pki/pki-tomcat/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u
ipa ca-del vpn-ca ------------------- Deleted CA "vpn-ca" -------------------
function::probe_type Name function::probe_type - The low level probe handler type of the current probe. Synopsis Arguments None Description Returns a short string describing the low level probe handler type for the current probe point. This is for informational purposes only. Depending on the low level probe handler different context functions can or cannot provide information about the current event (for example some probe handlers only trigger in user space and have no associated kernel context). High-level probes might map to the same or different low-level probes (depending on systemtap version and/or kernel used).

Commands:
probe_type:string()
B.83. ruby B.83.1. RHBA-2011:0005 - ruby bug fix update Updated ruby packages that fix a bug are now available for Red Hat Enterprise Linux 6. Ruby is an extensible, interpreted, object-oriented, scripting language. It has features to process text files and to do system management tasks. Bug Fix BZ# 653824 Under some circumstances on the PowerPC 64 architecture, Ruby did not save the context correctly before switching threads. Consequently, when a thread was restored, it had stale context whose use would result in a segmentation fault. This affected nearly any thread-using program on PowerPC 64. With this update, the underlying source code has been modified to address this issue, and the context is now saved correctly. All PowerPC 64 ruby users are advised to upgrade to these updated packages, which resolve this issue.

Commands:
Chapter 5. Tools for application migration Before you migrate your applications from Red Hat build of OpenJDK version 8 or 11 to Red Hat build of OpenJDK 17, you can use tools to test the suitability of your applications to run on Red Hat build of OpenJDK 17. You can use the following steps to enhance your testing process: Update third-party libraries. Compile your application code. Run jdeps on your application's code. Use the migration toolkit for applications (MTA) tool to migrate Java applications from Red Hat build of OpenJDK version 8 or 11 to Red Hat build of OpenJDK 17. Additional resources For more information about the MTA tool, see the Introduction to the Migration Toolkit for Applications guide.

Commands:
1.5. Starting and Stopping a Directory Server Instance 1.5.1. Starting and Stopping a Directory Server Instance Using the Command Line Use the dsctl utility to start, stop, or restart an instance: To start the instance: To stop the instance: To restart the instance: Optionally, you can enable Directory Server instances to automatically start when the system boots: For a single instance: For all instances on a server: For further details, see the Managing System Services section in the Red Hat System Administrator's Guide . 1.5.2. Starting and Stopping a Directory Server Instance Using the Web Console As an alternative to command line, you can use the web console to start, stop, or restart instances. To start, stop, or restart a Directory Server instance: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Click the Actions button and select the action to execute: Start Instance Stop Instance Restart Instance

Commands:
dsctl instance_name start
dsctl instance_name stop
dsctl instance_name restart
systemctl enable dirsrv@ instance_name
systemctl enable dirsrv.target
2.2. Fencing GNBD Server Nodes GNBD server nodes must be fenced using a fencing method that physically removes the nodes from the network. To physically remove a GNBD server node, you can use any fencing device: except the following: fence_brocade fence agent, fence_vixel fence agent, fence_mcdata fence agent, fence_sanbox2 fence agent, fence_scsi fence agent. In addition, you cannot use the GNBD fencing device ( fence_gnbd fence agent) to fence a GNBD server node. For information about configuring fencing for GNBD server nodes, refer to the Global File System manual.

Commands:
9.5. Managing Storage Controllers in a Guest Virtual Machine Starting from Red Hat Enterprise Linux 6.4, it is supported to add SCSI and virtio-SCSI devices to guest virtual machines that are running Red Hat Enterprise Linux 6.4 or later. Unlike virtio disks, SCSI devices require the presence of a controller in the guest virtual machine. Virtio-SCSI provides the ability to connect directly to SCSI LUNs and significantly improves scalability compared to virtio-blk. The advantage of virtio-SCSI is that it is capable of handling hundreds of devices compared to virtio-blk which can only handle 28 devices and exhausts PCI slots. Virtio-SCSI is now capable of inheriting the feature set of the target device with the ability to: attach a virtual hard drive or CD through the virtio-scsi controller, pass-through a physical SCSI device from the host to the guest via the QEMU scsi-block device, and allow the usage of hundreds of devices per guest; an improvement from the 28-device limit of virtio-blk. This section details the necessary steps to create a virtual SCSI controller (also known as "Host Bus Adapter", or HBA) and to add SCSI storage to the guest virtual machine. Procedure 9.10. Creating a virtual SCSI controller Display the configuration of the guest virtual machine ( Guest1 ) and look for a pre-existing SCSI controller: If a device controller is present, the command will output one or more lines similar to the following: If the step did not show a device controller, create the description for one in a new file and add it to the virtual machine, using the following steps: Create the device controller by writing a <controller> element in a new file and save this file with an XML extension. virtio-scsi-controller.xml , for example. Associate the device controller you just created in virtio-scsi-controller.xml with your guest virtual machine (Guest1, for example): In this example the --config option behaves the same as it does for disks. Refer to Procedure 13.2, "Adding physical block devices to guests" for more information. Add a new SCSI disk or CD-ROM. The new disk can be added using the methods in sections Section 13.3.1, "Adding File-based Storage to a Guest" and Section 13.3.2, "Adding Hard Drives and Other Block Devices to a Guest" . In order to create a SCSI disk, specify a target device name that starts with sd . Depending on the version of the driver in the guest virtual machine, the new disk may not be detected immediately by a running guest virtual machine. Follow the steps in the Red Hat Enterprise Linux Storage Administration Guide .

Commands:
# virsh dumpxml Guest1 | grep controller.*scsi
<controller type='scsi' model='virtio-scsi' index='0'/>
<controller type='scsi' model='virtio-scsi'/>
# virsh attach-device --config Guest1 ~/virtio-scsi-controller.xml
# virsh attach-disk Guest1 /var/lib/libvirt/images/FileName.img sdb --cache none
Chapter 4. Custom User Attributes You can add custom user attributes to the registration page and account management console with a custom theme. This chapter describes how to add attributes to a custom theme, but you should refer to the Themes chapter on how to create a custom theme. 4.1. Registration Page To be able to enter custom attributes in the registration page copy the template themes/base/login/register.ftl to the login type of your custom theme. Then open the copy in an editor. As an example to add a mobile number to the registration page add the following snippet to the form: <div class="form-group"> <div class="USD{properties.kcLabelWrapperClass!}"> <label for="user.attributes.mobile" class="USD{properties.kcLabelClass!}">Mobile number</label> </div> <div class="USD{properties.kcInputWrapperClass!}"> <input type="text" class="USD{properties.kcInputClass!}" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(register.formData['user.attributes.mobile']!'')}"/> </div> </div> Ensure the name of the input html element starts with user.attributes. . In the example above, the attribute will be stored by Keycloak with the name mobile . To see the changes make sure your realm is using your custom theme for the login theme and open the registration page. 4.2. Account Management Console To be able to manage custom attributes in the user profile page in the account management console copy the template themes/base/account/account.ftl to the account type of your custom theme. Then open the copy in an editor. As an example to add a mobile number to the account page add the following snippet to the form: <div class="form-group"> <div class="col-sm-2 col-md-2"> <label for="user.attributes.mobile" class="control-label">Mobile number</label> </div> <div class="col-sm-10 col-md-10"> <input type="text" class="form-control" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(account.attributes.mobile!'')}"/> </div> </div> Ensure the name of the input html element starts with user.attributes. . To see the changes make sure your realm is using your custom theme for the account theme and open the user profile page in the account management console.

Commands:
<div class="form-group"> <div class="USD{properties.kcLabelWrapperClass!}"> <label for="user.attributes.mobile" class="USD{properties.kcLabelClass!}">Mobile number</label> </div> <div class="USD{properties.kcInputWrapperClass!}"> <input type="text" class="USD{properties.kcInputClass!}" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(register.formData['user.attributes.mobile']!'')}"/> </div> </div>
<div class="form-group"> <div class="col-sm-2 col-md-2"> <label for="user.attributes.mobile" class="control-label">Mobile number</label> </div> <div class="col-sm-10 col-md-10"> <input type="text" class="form-control" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(account.attributes.mobile!'')}"/> </div> </div>
Chapter 3. Certification lifecycle 3.1. Product certification lifecycle Starting with Red Hat OpenStack Platform (RHOSP) 16, certification is granted on a specific major and minor release of RHOSP. For example, RHOSP 16.0 where 16 is the major release and 0 is the minor release. While the certification remains valid for the life of the major release, in our example RHOSP 16, there are instances where recertification will be required. Those instances are described in Recertification . 3.2. Continual testing You are responsible for your own internal continual testing over the lifespan of their product and the Red Hat OpenStack Platform major version they are certified on. You are encouraged to utilize a CI system such as DCI , that includes testing with the certification tests. Evaluating certification testing results from a CI system are not required to be submitted to Red Hat but should be monitored by the Partner for regressions and unexpected behaviors and to indicate when a recertification may be required. You may have access to pre-released software builds of Red Hat OpenStack Platform and are encouraged to begin their initial and CI testing and engagement with the Red Hat Certification team prior to the Red Hat OpenStack Platform version being made generally available to customers. Final testing and container builds must be conducted on the generally available (GA) released containers for that major release. 3.3. Recertification Red Hat will notify you of, and you are requested to recertify your product in the following cases: A new major release of the Red Hat OpenStack Platform. A new minor release of the Red Hat OpenStack Platform that adds additional features or functionality not previously covered in an earlier certification that the partner desires to add to their certification. A new minor release of the Red Hat OpenStack Platform that updates the kernel and the partner product relies on kernel modules. You will notify Red Hat of, and you are required to recertify their product in the following cases: A new major update of the partner's product that invalidates the original testing conducted in the original certification. A new minor update of the partner's product that would alter the original test plan of the certification. A new certification should be submitted for each of these cases. Where possible, in minor release updates of Red Hat and Partner products, the certification efforts and test plan will focus on the new features and functionality not already tested in prior certification(s) as the established feature functionality is expected to be maintained through the required continual testing. When a customized container image is provided as part of your OpenStack certification, it is important to rebuild this customized container image every time a Red Hat OpenStack Platform z-stream is released for a specific Major-Minor release. This will ensure that your image is taking advantage of the latest bug fixes and CVEs. Note For RHOSP container recertification, it is not required to revalidate the functionality of your product if it has not undergone any modification.

Commands:
5.247. policycoreutils 5.247.1. RHBA-2012:0969 - policycoreutils bug fix update Updated policycoreutils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The policycoreutils packages contain the core utilities that are required for the basic operation of a Security-Enhanced Linux (SELinux) system and its policies. These updated policycoreutils packages provide fixes for the following bugs: BZ# 784595 The semanage utility did not produce correct audit messages in the Common Criteria certified environment. This update modifies semanage so that it now sends correct audit events when the user is assigned to or removed from a new role. This update also modifies behavior of semanage concerning the user's SELinux Multi-Level Security (MLS) and Multi-Category Security (MCS) range. The utility now works with the user's default range of the MLS/MCS security level instead of the lowest. In addition, the semanage(8) manual page has been corrected to reflect the current semanage functionality. BZ# 751313 Prior to this update, the ppc and ppc64 versions of the policycoreutils package conflicted with each other when installed on the same system. This update fixes this bug; ppc and ppc64 versions of the package can now be installed simultaneously. BZ# 684015 The missing exit(1) function call in the underlying code of the sepolgen-ifgen utility could cause the restorecond daemon to access already freed memory when retrieving user's information. This would cause restorecond to terminate unexpectedly with a segmentation fault. With this update, restorecond has been modified to check the return value of the getpwuid() function to avoid this situation. BZ# 786191 When installing packages on the system in Federal Information Processing Standard (FIPS) mode, parsing errors could occur and installation failed. This was caused by the "/usr/lib64/python2.7/site-packages/sepolgen/yacc.py" parser, which used MD5 checksums that are not supported in FIPS mode. This update modifies the parser to use SHA-256 checksums and installation process is now successful. BZ# 786664 Due to a pam_namespace issue which caused a leak of mount points to the parent namespace, polyinstantiated directories could be seen by users other than the owner of that directory. With this update, the mount points no longer leak to the parent namespace, and users can only see directories they own. BZ# 806736 , BZ# 807011 When a user or a program ran the "semanage fcontext" command, a traceback error was returned. This was due to a typographical error in the source code of the semanage command. This updates fixes this error, and executing the semanage fcontext command works as expected. All users of policycoreutils are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 12. steps To start deploying your OpenShift Data Foundation, you can use the internal mode within OpenShift Container Platform or use external mode to make available services from a cluster running outside of OpenShift Container Platform. Depending on your requirement, go to the respective deployment guides. Internal mode Deploying OpenShift Data Foundation using Amazon web services Deploying OpenShift Data Foundation using Bare Metal Deploying OpenShift Data Foundation using VMWare vSphere Deploying OpenShift Data Foundation using Microsoft Azure Deploying OpenShift Data Foundation using Google Cloud Deploying OpenShift Data Foundation using Red Hat OpenStack Platform [Technology Preview] Deploying OpenShift Data Foundation on IBM Power Deploying OpenShift Data Foundation on IBM Z External mode Deploying OpenShift Data Foundation in external mode

Commands: