mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Uninstalling a cluster on Azure You can remove a cluster that you deployed to Microsoft Azure. 12.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with user-provisioned infrastructure clusters. There might be resources that the installation program did not create or that the installation program is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. While you can uninstall the cluster using the copy of the installation program that was used to deploy it, using OpenShift Container Platform version 4.13 or later is recommended. The removal of service principals is dependent on the Microsoft Azure AD Graph API. Using version 4.13 or later of the installation program ensures that service principals are removed without the need for manual intervention, if and when Microsoft decides to retire the Azure AD Graph API. Procedure On the computer that you used to install the cluster, go to the directory that contains the installation program, and run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Appendix D. Revision History Revision History Revision 9.1-4 Thu Oct 26 2017 Steven Levine Update to 6.9 GA publication. Revision 9.1-2 Wed Mar 8 2017 Steven Levine Version for 6.9 GA publication. Revision 9.1-1 Fri Dec 16 2016 Steven Levine Version for 6.9 Beta publication. Revision 8.1-5 Wed Apr 27 2016 Steven Levine Preparing document for 6.8 GA publication. Revision 8.1-2 Wed Mar 9 2016 Steven Levine Initial revision for Red Hat Enterprise Linux 6.8 Beta release Revision 7.1-5 Wed Jul 8 2015 Steven Levine Initial revision for Red Hat Enterprise Linux 6.7 Revision 7.1-4 Mon Apr 13 2015 Steven Levine Initial revision for Red Hat Enterprise Linux 6.7 Beta release Revision 7.0-9 Wed Oct 8 2014 Steven Levine Initial revision for Red Hat Enterprise Linux 6.6 Revision 7.0-8 Thu Aug 7 2014 Steven Levine Initial revision for Red Hat Enterprise Linux 6.6 Beta release Revision 6.0-6 Wed Nov 13 2013 Steven Levine Initial revision for Red Hat Enterprise Linux 6.5 Revision 6.0-5 Fri Sep 27 2013 Steven Levine Initial revision for Red Hat Enterprise Linux 6.5 Beta release Revision 5.0-7 Mon Feb 18 2013 Steven Levine Initial revision for Red Hat Enterprise Linux 6.4 Revision 5.0-5 Mon Nov 26 2012 Steven Levine Initial revision for Red Hat Enterprise Linux 6.4 Beta release Revision 4.0-2 Thu Mar 28 2012 Steven Levine Initial revision for Red Hat Enterprise Linux 6.3 Revision 3.0-2 Thu Dec 1 2011 Steven Levine Initial revision for Red Hat Enterprise Linux 6.2 Revision 3.0-1 Mon Sep 19 2011 Steven Levine Initial revision for Red Hat Enterprise Linux 6.2 Beta release Revision 2.0-1 Thu May 19 2011 Steven Levine Initial revision for Red Hat Enterprise Linux 6.1 Revision 1.0-1 Wed Nov 15 2010 Steven Levine Initial revision for Red Hat Enterprise Linux 6

Commands:
Chapter 47. Red Hat Enterprise Linux System Roles Powered by Ansible Red Hat Enterprise Linux System Roles Red Hat Enterprise Linux System Roles, available as a Technology Preview, is a configuration interface for Red Hat Enterprise Linux subsystems, which makes system configuration easier through the inclusion of Ansible Roles . This interface enables managing system configurations across multiple versions of Red Hat Enterprise Linux, as well as adopting new major releases. Since Red Hat Enterprise Linux 7.4, the Red Hat Enterprise Linux System Roles packages have been distributed through the Extras channel. For details regarding Red Hat Enterprise Linux System Roles, see https://access.redhat.com/articles/3050101 . (BZ# 1313263 )

Commands:
Chapter 4. Configuring Authentication Mechanisms Red Hat Enterprise Linux supports several different authentication methods. They can be configured using the authconfig tool or, in some cases, also using Identity Management tools. 4.1. Configuring Local Authentication Using authconfig The Local Authentication Options area defines settings for local system accounts, not the users stored on the back end. These settings define user-based authorization to system services (as defined in /etc/security/access.conf ). Otherwise, authorization policies can be defined within the identity provider or the services themselves. 4.1.1. Enabling Local Access Control in the UI Enable local access control sets the system to check the /etc/security/access.conf file for local user authorization rules. This is PAM authorization. Figure 4.1. Local Accounts Fields 4.1.2. Configuring Local Access Control in the Command Line There are two options for authconfig to enable local authorization controls. --enablelocauthorize skips network authentication and only checks local files for system users. --enablepamaccess configures the system to look for system authorization policies in /etc/security/access.conf .

Commands:
authconfig --enablelocauthorize --enablepamaccess --update
Chapter 2. Acknowledgments Red Hat Ceph Storage version 5.0 contains many contributions from the Red Hat Ceph Storage team. In addition, the Ceph project is seeing amazing growth in the quality and quantity of contributions from individuals and organizations in the Ceph community. We would like to thank all members of the Red Hat Ceph Storage team, all of the individual contributors in the Ceph community, and additionally, but not limited to, the contributions from organizations such as: Intel(R) Fujitsu (R) UnitedStack Yahoo TM Ubuntu Kylin Mellanox (R) CERN TM Deutsche Telekom Mirantis (R) SanDisk TM SUSE Linux(R) Enterprise Server (SLES)

Commands:
20.25. Taking a Screenshot of the Guest Console The virsh screenshot guestname [ imagefilepath ] command takes a screenshot of a current guest virtual machine console and stores it into a file. If no file path is provided, the screenshot is saved to the current directory. If the hypervisor supports multiple displays for a guest virtual machine, use the -- screen screenID option to specify the screen to be captured. Example 20.52. How to take a screenshot of a guest machine's console The following example takes a screenshot of the guest1 machine's console and saves it as /home/username/pics/guest1-screen.png :

Commands:
virsh screenshot guest1 /home/username/pics/guest1-screen.ppm Screenshot saved to /home/username/pics/guest1-screen.ppm, with type of image/x-portable-pixmap
4.2. Prerequisites for Installing a Replica Server Replicas are functionally the same as IdM servers, so they have the same installation requirements and packages. However, replicas are also copies of existing servers, so they must also mirror the originating server configuration. Make sure that the machine meets all of the prerequisites listed in Chapter 2, Prerequisites for Installation . The replica and the master server must be running the same version of IdM. The replica essentially is a copy of a server, based off the existing server configuration. Therefore, the server and the replica (its copy) must be running the same version of Identity Management so that the configuration can be properly copied from the server to the replica. If the master server is running on Red Hat Enterprise Linux 6, IdM version 3.0, then the replica must also run on Red Hat Enterprise Linux 6 and use the IdM 3.0 packages. Important Creating a replica of a different version than the master is not supported . Attempting to create a replica using a different version fails when attempting to configure the 389 Directory Server instance. Apart from the ports listed in Table 2.1, "IdM Ports" , installing a replica also requires port 22 to be free during the replica setup process. This port is required in order to use SSH to connect to the master server. Port 7389 must be free if there is an existing Dogtag Certificate System or Red Hat Certificate System instance on the replica machine during and after the replica configuration. This port is used by the master IdM server to communicate with the replica. Note The ipa-replica-install script includes the ipa-replica-conncheck utility that verifies the status of the required ports. You can also run ipa-replica-conncheck separately for troubleshooting purposes. For information on how to use the utility, see the ipa-replica-conncheck (1) man page. The replica must use the same CA configuration as the server and must have the same root CA. For example, if the server is its own root CA (using Dogtag Certificate System), then that must be the root CA for the replica. If the server used an external CA to issue its certificates, than the replica must use that same external CA.

Commands:
Chapter 11. Troubleshooting The following chapter describes what happens when SELinux denies access; the top three causes of problems; where to find information about correct labeling; analyzing SELinux denials; and creating custom policy modules with audit2allow . 11.1. What Happens when Access is Denied SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Denial messages are logged when SELinux denies access. These denials are also known as "AVC denials", and are logged to a different location, depending on which daemons are running: Daemon Log Location auditd on /var/log/audit/audit.log auditd off; rsyslogd on /var/log/messages setroubleshootd, rsyslogd, and auditd on /var/log/audit/audit.log . Easier-to-read denial messages also sent to /var/log/messages If you are running the X Window System, have the setroubleshoot and setroubleshoot-server packages installed, and the setroubleshootd and auditd daemons are running, a warning is displayed when access is denied by SELinux: Clicking on Show presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access. If you are not running the X Window System, it is less obvious when access is denied by SELinux. For example, users browsing your website may receive an error similar to the following: For these situations, if DAC rules (standard Linux permissions) allow access, check /var/log/messages and /var/log/audit/audit.log for "SELinux is preventing" and "denied" errors respectively. This can be done by running the following commands as the root user:

Commands:
Forbidden You don't have permission to access file name on this server
~]# grep "SELinux is preventing" /var/log/messages
~]# grep "denied" /var/log/audit/audit.log
Appendix D. Removing the standalone Red Hat Virtualization Manager The engine-cleanup command removes all components of the Red Hat Virtualization Manager and automatically backs up the following: the Grafana database, in /var/lib/grafana/ the Manager database in /var/lib/ovirt-engine/backups/ a compressed archive of the PKI keys and configuration in /var/lib/ovirt-engine/backups/ Backup file names include the date and time. Warning You should use this procedure only on a standalone installation of the Red Hat Virtualization Manager. Procedure Run the following command on the Manager machine: # engine-cleanup The Manager service must be stopped before proceeding. You are prompted to confirm. Enter OK to proceed: During execution engine service will be stopped (OK, Cancel) [OK]: You are prompted to confirm that you want to remove all Manager components. Enter OK to remove all components, or Cancel to exit engine-cleanup : All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK engine-cleanup details the components that are removed, and the location of backup files. Remove the Red Hat Virtualization packages: # dnf remove rhvm* vdsm-bootstrap

Commands:
engine-cleanup
During execution engine service will be stopped (OK, Cancel) [OK]:
All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
dnf remove rhvm* vdsm-bootstrap
B.33.2. RHSA-2011:0214 - Moderate: java-1.6.0-openjdk security update Updated java-1.6.0-openjdk 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 moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. These packages provide the OpenJDK 6 Java Runtime Environment and the OpenJDK 6 Software Development Kit. CVE-2010-4476 A denial of service flaw was found in the way certain strings were converted to Double objects. A remote attacker could use this flaw to cause Java-based applications to hang, for instance if they parse Double values in a specially-crafted HTTP request. All users of java-1.6.0-openjdk are advised to upgrade to these updated packages, which resolve this issue. All running instances of OpenJDK Java must be restarted for the update to take effect.

Commands:
Upgrading Guide Red Hat build of Keycloak 26.0 Red Hat Customer Content Services

Commands:
Hostname v1 bin/kc.[sh|bat] start --hostname=mykeycloak.org --https-port=8543 --hostname-path=/auth --hostname-strict-https=true Hostname v2 bin/kc.[sh|bat] start --hostname=https://mykeycloak.org:8543/auth
Hostname v1 bin/kc.[sh|bat] start --hostname=mykeycloak.org --hostname-strict-backchannel=true Hostname v2 bin/kc.[sh|bat] start --hostname=mykeycloak.org --hostname-backchannel-dynamic=false
bin/kc.[sh|bat] start --spi-group-jpa-escape-slashes-in-group-path=true
bin/kc.[sh|bat] --spi-connections-http-client-default-max-consumed-response-size=1000000
http_server_active_requests 1.0 http_server_requests_seconds_count{method="GET",outcome="SUCCESS",status="200",uri="/realms/{realm}/protocol/{protocol}/auth"} 1.0 http_server_requests_seconds_sum{method="GET",outcome="SUCCESS",status="200",uri="/realms/{realm}/protocol/{protocol}/auth"} 0.048717142
npm install keycloak-js
// Before const keycloak = new Keycloak(); // After const keycloak = new Keycloak({ url: "http://keycloak-server", realm: "my-realm", clientId: "my-app" }); // Alternatively, you can pass a URL to a `keycloak.json` file. // Note this is not reccomended as it creates additional network requests, and is prone to change in the future. const keycloak = new Keycloak('http://keycloak-server/path/to/keycloak.json');
// Before keycloak.login(); const loginUrl = keycloak.createLoginUrl(); const registerUrl = keycloak.createRegisterUrl(); // After await keycloak.login(); const loginUrl = await keycloak.createLoginUrl(); const registerUrl = await keycloak.createRegisterUrl();
bin/kc.[sh|bat] start --spi-brute-force-protector-default-brute-force-detector-allow-concurrent-requests=true
kc.[sh|bat] start --spi-connections-liquibase-quarkus-index-creation-threshold=300000
kc.[sh|bat] start --spi-connections-jpa-quarkus-migration-strategy=manual
kc.[sh|bat] start --spi-connections-jpa-quarkus-migration-export=<path>/<file.sql>
diff RHSSO_HOME_OLD/themes/keycloak/login/resources/css/login.css RHSSO_HOME_NEW/themes/keycloak/login/resources/css/login.css
Chapter 2. About migrating from OpenShift Container Platform 3 to 4 OpenShift Container Platform 4 contains new technologies and functionality that result in a cluster that is self-managing, flexible, and automated. OpenShift Container Platform 4 clusters are deployed and managed very differently from OpenShift Container Platform 3. The most effective way to migrate from OpenShift Container Platform 3 to 4 is by using a CI/CD pipeline to automate deployments in an application lifecycle management framework. If you do not have a CI/CD pipeline or if you are migrating stateful applications, you can use the Migration Toolkit for Containers (MTC) to migrate your application workloads. You can use Red Hat Advanced Cluster Management for Kubernetes to help you import and manage your OpenShift Container Platform 3 clusters easily, enforce policies, and redeploy your applications. Take advantage of the free subscription to use Red Hat Advanced Cluster Management to simplify your migration process. To successfully transition to OpenShift Container Platform 4, review the following information: Differences between OpenShift Container Platform 3 and 4 Architecture Installation and upgrade Storage, network, logging, security, and monitoring considerations About the Migration Toolkit for Containers Workflow File system and snapshot copy methods for persistent volumes (PVs) Direct volume migration Direct image migration Advanced migration options Automating your migration with migration hooks Using the MTC API Excluding resources from a migration plan Configuring the MigrationController custom resource for large-scale migrations Enabling automatic PV resizing for direct volume migration Enabling cached Kubernetes clients for improved performance For new features and enhancements, technical changes, and known issues, see the MTC release notes .

Commands:
Chapter 31. Configuring Host-Based Access Control This chapter describes host-based access control (HBAC) in Identity Management (IdM) and explains how you can use HBAC to manage access control in your IdM domain. 31.1. How Host-Based Access Control Works in IdM Host-based access control defines which users (or user groups) can access specified hosts (or host groups) by using specified services (or services in a service group). For example, you can: Limit access to a specified system in your domain to members of a specific user group. Allow only a specific service to be used to access the systems in your domain. The administrator configures host-based access control by using a set of allowing rules named HBAC rules . By default, IdM is configured with a default HBAC rule named allow_all , which allows universal access in the whole IdM domain. Applying HBAC Rules to Groups For centralized and simplified access control management, you can apply HBAC rules to whole user, host, or service groups instead of individual users, hosts, or services. Figure 31.1. Host Groups and Host-Based Access Control When applying HBAC rules to groups, consider using automember rules . See Section 13.6, "Defining Automatic Group Membership for Users and Hosts" .

Commands:
Chapter 1. Monitoring Datadog and Ceph The Datadog integration with Ceph enables Datadog to execute and process the output from: ceph status ceph health detail ceph df detail ceph osd perf ; and, ceph osd pool stats . The integration enables Datadog to: Monitor the status and health of the Red Hat Ceph Storage cluster. Monitor I/O and performance metrics. Track disk usage across storage pools. Using Datadog Using Datadog to monitor Ceph requires installing a Datadog agent on at least one Ceph monitor node. When monitoring Ceph, the Datadog agent will execute Ceph command line arguments. Consequently, each Ceph node must have an appropriate Ceph key providing access to the cluster, usually in /etc/ceph . Once the agent executes the Ceph command, it sends Red Hat Ceph Storage cluster status and statistics back to Datadog. Then, Datadog will present the status and statistics in the Datadog user interface. Since Datadog uses an agent, the Red Hat Ceph Storage cluster must be able to reach the internet. However, the Red Hat Ceph Storage cluster does not have to be reachable from the internet. Note Datadog supports retrieving ceph status with Red Hat Ceph Storage version 2 or higher. Datadog will provide an update to support ceph status for Red Hat Ceph Storage cluster 3 in a subsequent release of its dd-agent . Important Red Hat works with our technology partners to provide this documentation as a service to our customers. However, Red Hat does not provide support for this product. If you need technical assistance for this product, then contact Datadog for support.

Commands:
Chapter 3. Upgrading RHCS 5 to RHCS 6 involving RHEL 8 to RHEL 9 upgrades Upgrade from Red Hat Ceph Storage 5 to Red Hat Ceph Storage 6. The upgrade includes an upgrade from Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9. Important Upgrade to the latest version of Red Hat Ceph Storage 5.3.z5 prior to upgrading to the latest version Red Hat Ceph Storage 6.1. Prerequisites A running Red Hat Ceph Storage 5 cluster on Red Hat Enterprise Linux 8. Backup of Ceph binary ( /usr/sbin/cephadm ), ceph.pub ( /etc/ceph ), and the Ceph cluster's public SSH keys from the admin node. Procedure Upgrade the Red Hat Enterprise Linux version on all hosts of the cluster. For a detailed procedure, see Upgrading a host operating system from RHEL 8 to RHEL 9 to know the steps. After the Red Hat Enterprise Linux upgrade, register the Red Hat Ceph Storage nodes to the CDN and add the necessary repositories. For a detailed procedure, see Registering the Red Hat Ceph Storage nodes to the CDN and attaching subscriptions . Update the Red Hat Ceph Storage. For a detailed procedure, see Upgrade a Red Hat Ceph Storage cluster using cephadm .

Commands: