mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Learn more about OpenShift Container Platform Use the following sections to find content to help you learn about and use OpenShift Container Platform. 2.1. Architect Learn about OpenShift Container Platform Plan an OpenShift Container Platform deployment Additional resources Enterprise Kubernetes with OpenShift Tested platforms OpenShift blog Architecture Security and compliance What's new in OpenShift Container Platform Networking OpenShift Container Platform life cycle Backup and restore 2.2. Cluster Administrator Learn about OpenShift Container Platform Deploy OpenShift Container Platform Manage OpenShift Container Platform Additional resources Enterprise Kubernetes with OpenShift Installing OpenShift Container Platform Using Insights to identify issues with your cluster Getting Support Architecture Machine configuration overview Logging OpenShift Knowledgebase articles OpenShift Interactive Learning Portal Networking About OpenShift Container Platform monitoring OpenShift Container Platform Life Cycle Storage Backup and restore Updating a cluster 2.3. Application Site Reliability Engineer (App SRE) Learn about OpenShift Container Platform Deploy and manage applications Additional resources OpenShift Interactive Learning Portal Projects Getting Support Architecture Operators OpenShift Knowledgebase articles Logging OpenShift Container Platform Life Cycle Blogs about logging Monitoring 2.4. Developer Learn about application development in OpenShift Container Platform Deploy applications Getting started with OpenShift for developers (interactive tutorial) Creating applications Red Hat Developers site Builds Red Hat OpenShift Dev Spaces (formerly Red Hat CodeReady Workspaces) Operators Images Developer-focused CLI

Commands:
8.18. conman 8.18.1. RHBA-2013:1677 - conman bug fix and enhancement update Updated conman packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. ConMan is a serial console management program designed to support a large number of console devices and simultaneous users. ConMan currently supports local serial devices and remote terminal servers. Note The conman packages have been upgraded to upstream version 0.2.7, which provides a number of bug fixes and enhancements over the version. With this update, support for the ipmiopts directive in the conman.conf configuration file has been included. (BZ# 951698 ) Bug Fix BZ# 891938 Previously, the length range of timezone strings was not sufficient to process all known timezone codes. As a consequence, the conmand daemon failed to start if the timezone name consisted of five or more characters. The maximum string length has been set to 32, and conmand now always starts as expected. Users of conman are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
5.2.2. Enable root login over SSH Now that virt-v2v is installed, the conversion server must be prepared to accept P2V client connections. The P2V client connects to the conversion server as root using SSH, so root login over SSH must be allowed on the conversion server. Enable root login over SSH: As root, edit the sshd_config file in /etc/ssh/sshd_config : Add a line in the Authentication section of the file that says PermitRootLogin yes . This line may already exist and be commented out with a "#". In this case, remove the "#". Save the updated /etc/ssh/sshd_config file. Restart the SSH server: You can now connect to the conversion server as root over SSH.

Commands:
nano /etc/ssh/sshd_config
Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
service sshd restart
Chapter 9. Accessing an overcloud deployed with the director Operator After you deploy the overcloud with the director Operator, you can access it and run commands with the openstack client tool. The main access point for the overcloud is through the OpenStackClient pod that the director Operator deploys as a part of the OpenStackControlPlane resource that you create. 9.1. Accessing the OpenStackClient pod The OpenStackClient pod is the main access point to run commands against the overcloud. This pod contains the client tools and authentication details that you require to perform actions on your overcloud. To access the pod from your workstation, you must use the oc command on your workstation to connect to the remote shell for the pod. Note When you access an overcloud that you deploy without the director Operator, you usually run the source ~/overcloudrc command to set environment variables to access the overcloud. You do not require this step with an overcloud that you deploy with the director Operator. Prerequisites Ensure your OpenShift Container Platform cluster is operational and you have installed the director Operator correctly. Deploy and configure an overcloud that runs in your OCP cluster. Ensure that you have installed the oc command line tool on your workstation. Procedure Access the remote shell for openstackclient : Change to the cloud-admin home directory: Run your openstack commands. For example, you can create a default network with the following command: Additional resources "Creating basic overcloud flavors" "Creating a default tenant network" "Creating a default floating IP network" "Creating a default provider network" 9.2. Accessing the overcloud dashboard Access the dashboard of an overcloud that you deploy with the director Operator with the same method as a standard overcloud. Access the IP address of the overcloud host name or public VIP, which you usually set with the PublicVirtualFixedIPs heat parameter, with a web browser and log in to the overcloud dashboard with your username and password. Prerequisites Ensure your OpenShift Container Platform cluster is operational and you have installed the director Operator correctly. Deploy and configure an overcloud that runs in your OCP cluster. Ensure that you have installed the oc command line tool on your workstation. Procedure Optional: To login as the admin user, obtain the admin password from the AdminPassword parameter in the tripleo-passwords secret: Open your web browser. Enter the host name or public VIP of the overcloud dashboard in the URL field. Log in to the dashboard with your chosen username and password.

Commands:
oc rsh -n openstack openstackclient
cd /home/cloud-admin
openstack network create default
oc get secret tripleo-passwords -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d
Chapter 1. Installing Fuse on JBoss EAP To develop Fuse applications on JBoss EAP, install JBoss EAP, and then install Fuse. Prerequisites Red Hat Customer Portal login credentials. A supported version of a Java runtime is installed. Red Hat Fuse Supported Runtimes lists the Java runtimes that are supported on different operating systems. Procedure Install JBoss EAP 7.4.16: Go to the Enterprise Application Platform Software Downloads page on the Red Hat Customer Portal. When prompted, log in to your customer account. In the Version dropdown menu, select 7.4 . Click the Download link for the Red Hat JBoss Enterprise Application Platform 7.4 Installer package. Run the downloaded installer. In the following example, replace DOWNLOAD_LOCATION with the location of the JBoss EAP installer on your system: Accept the terms and conditions. Choose your preferred installation path, which is represented by EAP_HOME for the JBoss EAP runtime. Create an administrative user and be sure to note this administrative user's credentials. You need them to log in to the Fuse Management Console. Accept the default settings on the remaining screens. Check the Red Hat Fuse Supported Configurations page for any notes or advice on the compatibility of JBoss EAP patches with Red Hat Fuse. If relevant, install any additional JBoss EAP patches. Install Fuse 7.13 on JBoss EAP 7.4.16: Go to the Red Hat Fuse Software Downloads page on the Red Hat Customer Portal. When prompted, log in to your customer account. In the Version dropdown menu, select 7.13.0 . Click the Download link for the Red Hat Fuse 7.13.0 on EAP Installer package. Open a shell prompt (or a command prompt on Windows). Change to the EAP_HOME directory, which is the root directory of the fresh Red Hat JBoss Enterprise Application Platform installation. Run the downloaded installer. In the following example, replace DOWNLOAD_LOCATION with the location of the downloaded Fuse installer on your system: The installer runs without prompts and logs its activity to the screen. steps Start JBoss EAP, verify that Fuse is running, and then add Fuse users to JBoss EAP. The chapters explain how to perform these tasks. Optional but recommended: set up Maven for local use with Fuse projects. This is explained in Chapter 7, Setting up Maven locally . Additional resources For more detailed information about installing JBoss EAP, see the JBoss EAP Installation Guide . For more detailed information about installing JBoss EAP patches, see the JBoss EAP Patching and Upgrading Guide .

Commands:
java -jar DOWNLOAD_LOCATION/jboss-eap-7.4.0-installer.jar
java -jar DOWNLOAD_LOCATION/fuse-eap-installer-7.13.0.fuse-7_13_0-00011-redhat-00001.jar
7.291. ypbind 7.291.1. RHBA-2013:0426 - ypbind bug fix update Updated ypbind packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ypbind packages provide the ypbind daemon to bind NIS clients to an NIS domain. The ypbind daemon must be running on any machines that run NIS client programs. Bug Fix BZ# 647495 Prior to this update, ypbind started too late in the boot sequence, which caused problems in some environments, where it needed to be started before netfs. This update changes the priority of the ypbind service. Now, ypbind starts as expected. All users of ypbind are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 4. Dynamically provisioned OpenShift Data Foundation deployed on Google cloud 4.1. Replacing operational or failed storage devices on Google Cloud installer-provisioned infrastructure When you need to replace a device in a dynamically created storage cluster on an Google Cloud installer-provisioned infrastructure, you must replace the storage node. For information about how to replace nodes, see: Replacing operational nodes on Google Cloud installer-provisioned infrastructure Replacing failed nodes on Google Cloud installer-provisioned infrastructures .

Commands:
7.3.2.2.5. Optimising for sustained metadata modifications The size of the log is the main factor in determining the achievable level of sustained metadata modification. The log device is circular, so before the tail can be overwritten all the modifications in the log must be written to the real locations on disk. This can involve a significant amount of seeking to write back all dirty metadata. The default configuration scales the log size in relation to the overall file system size, so in most cases log size will not require tuning. A small log device will result in very frequent metadata writeback - the log will constantly be pushing on its tail to free up space and so frequently modified metadata will be frequently written to disk, causing operations to be slow. Increasing the log size increases the time period between tail pushing events. This allows better aggregation of dirty metadata, resulting in better metadata writeback patterns, and less writeback of frequently modified metadata. The trade-off is that larger logs require more memory to track all outstanding changes in memory. If you have a machine with limited memory, then large logs are not beneficial because memory constraints will cause metadata writeback long before the benefits of a large log can be realised. In these cases, smaller rather than larger logs will often provide better performance because metadata writeback from the log running out of space is more efficient than writeback driven by memory reclamation. You should always try to align the log to the underlying stripe unit of the device that contains the file system. mkfs does this by default for MD and DM devices, but for hardware RAID it may need to be specified. Setting this correctly avoids all possibility of log I/O causing unaligned I/O and subsequent read-modify-write operations when writing modifications to disk. Log operation can be further improved by editing mount options. Increasing the size of the in-memory log buffers ( logbsize ) increases the speed at which changes can be written to the log. The default log buffer size is MAX (32 KB, log stripe unit), and the maximum size is 256 KB. In general, a larger value results in faster performance. However, under fsync-heavy workloads, small log buffers can be noticeably faster than large buffers with a large stripe unit alignment. The delaylog mount option also improves sustained metadata modification performance by reducing the number of changes to the log. It achieves this by aggregating individual changes in memory before writing them to the log: frequently modified metadata is written to the log periodically instead of on every modification. This option increases the memory usage of tracking dirty metadata and increases the potential lost operations when a crash occurs, but can improve metadata modification speed and scalability by an order of magnitude or more. Use of this option does not reduce data or metadata integrity when fsync , fdatasync or sync are used to ensure data and metadata is written to disk.

Commands:
Chapter 9. Detach volumes after non-graceful node shutdown This feature allows drivers to automatically detach volumes when a node goes down non-gracefully. Important Detach CSI volumes after non-graceful node shutdown is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . 9.1. Overview A graceful node shutdown occurs when the kubelet's node shutdown manager detects the upcoming node shutdown action. Non-graceful shutdowns occur when the kubelet does not detect a node shutdown action, which can occur because of system or hardware failures. Also, the kubelet may not detect a node shutdown action when the shutdown command does not trigger the Inhibitor Locks mechanism used by the kubelet on Linux, or because of a user error, for example, if the shutdownGracePeriod and shutdownGracePeriodCriticalPods details are not configured correctly for that node. With this feature, when a non-graceful node shutdown occurs, you can manually add an out-of-service taint on the node to allow volumes to automatically detach from the node. 9.2. Adding an out-of-service taint manually for automatic volume detachment Prerequisites Access to the cluster with cluster-admin privileges. Procedure To allow volumes to detach automatically from a node after a non-graceful node shutdown: After a node is detected as unhealthy, shut down the worker node. Ensure that the node is shutdown by running the following command and checking the status: oc get node <node name> 1 1 <node name> = name of the non-gracefully shutdown node Important If the node is not completely shut down, do not proceed with tainting the node. If the node is still up and the taint is applied, filesystem corruption can occur. Taint the corresponding node object by running the following command: Important Tainting a node this way deletes all pods on that node. This also causes any pods that are backed by statefulsets to be evicted, and replacement pods to be created on a different node. oc adm taint node <node name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 1 1 <node name> = name of the non-gracefully shutdown node After the taint is applied, the volumes detach from the shutdown node allowing their disks to be attached to a different node. Example The resulting YAML file resembles the following: spec: taints: - effect: NoExecute key: node.kubernetes.io/out-of-service value: nodeshutdown Restart the node. Remove the taint.

Commands:
get node <node name> 1
adm taint node <node name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 1
spec: taints: - effect: NoExecute key: node.kubernetes.io/out-of-service value: nodeshutdown
Appendix E. Command Line Tools Summary Table E.1, "Command Line Tool Summary" summarizes preferred command-line tools for configuring and managing the High Availability Add-On. For more information about commands and variables, see the man page for each command-line tool. Table E.1. Command Line Tool Summary Command Line Tool Used With Purpose ccs_config_dump - Cluster Configuration Dump Tool Cluster Infrastructure ccs_config_dump generates XML output of running configuration. The running configuration is, sometimes, different from the stored configuration on file because some subsystems store or set some default information into the configuration. Those values are generally not present on the on-disk version of the configuration but are required at runtime for the cluster to work properly. For more information about this tool, see the ccs_config_dump(8) man page. ccs_config_validate - Cluster Configuration Validation Tool Cluster Infrastructure ccs_config_validate validates cluster.conf against the schema, cluster.rng (located in /usr/share/cluster/cluster.rng on each node). For more information about this tool, see the ccs_config_validate(8) man page. clustat - Cluster Status Utility High-availability Service Management Components The clustat command displays the status of the cluster. It shows membership information, quorum view, and the state of all configured user services. For more information about this tool, see the clustat(8) man page. clusvcadm - Cluster User Service Administration Utility High-availability Service Management Components The clusvcadm command allows you to enable, disable, relocate, and restart high-availability services in a cluster. For more information about this tool, see the clusvcadm(8) man page. cman_tool - Cluster Management Tool Cluster Infrastructure cman_tool is a program that manages the CMAN cluster manager. It provides the capability to join a cluster, leave a cluster, kill a node, or change the expected quorum votes of a node in a cluster. For more information about this tool, see the cman_tool(8) man page. fence_tool - Fence Tool Cluster Infrastructure fence_tool is a program used to join and leave the fence domain. For more information about this tool, see the fence_tool(8) man page.

Commands:
B.10. Could not add rule to fixup DHCP response checksums on network 'default' Symptom This message appears: Investigation Although this message appears to be evidence of an error, it is almost always harmless. Solution Unless the problem you are experiencing is that the guest virtual machines are unable to acquire IP addresses through DHCP, this message can be ignored. If this is the case, refer to Section B.8, "PXE Boot (or DHCP) on Guest Failed" for further details on this situation.

Commands:
Could not add rule to fixup DHCP response checksums on network 'default'
15.13. Configuring Changelog Encryption To increase security, Directory Server supports encrypting the changelog. This section explains how to enable this feature. Prerequisites The server must have a certificate and key stored in the network security services (NSS) database. Therefor, enable TLS encryption on the server as described in Section 9.4.1, "Enabling TLS in Directory Server" . Procedure To enable changelog encryption: Except for the server on which you want to enable changelog encryption, stop all instances in the replication topology by entering the following command: On the server where you want to enable changelog encryption: Export the changelog, for example, to the /tmp/changelog.ldif file: Stop the instance: Add the following setting to the dn: cn=changelog5,cn=config entry in the /etc/dirsrv/slapd- instance_name /dse.ldif file: Start the instance: Import the changelog from the /tmp/changelog.ldif file: Start all instances on the other servers in the replication topology using the following command: Verification To verify that the changelog is encrypted, run the following steps on the server with the encrypted changelog: Make a change in the LDAP directory, such as updating an entry. Stop the instance: Enter the following command to display parts of the changelog: If the changelog is encrypted, you see only encrypted data. Start the instance: Additional Resources Section 15.15, "Exporting the Replication Changelog" Section 15.16, "Importing the Replication Changelog from an LDIF-formatted Changelog Dump"

Commands:
dsctl instance_name stop
dsconf -D "cn=Directory Manager" ldap://server.example.com replication dump-changelog -o /tmp/changelog.ldif
dsctl instance_name stop
nsslapd-encryptionalgorithm: AES
dsctl instance_name start
dsconf -D "cn=Directory Manager" ldap://server.example.com replication restore-changelog from-ldif /tmp/changelog.ldif
dsctl instance_name start
dsctl stop instance_name
dbscan -f /var/lib/dirsrv/slapd- instance_name /changelogdb/ replica_name _ replGen .db | tail -50
dsctl start instance_name
Chapter 8. New Model Wizards 8.1. Launch New Model Wizards Models are the primary resource used by the Teiid Designer . Creating models can be accomplished by either directly importing existing metadata or by creating them using one of several New Model wizard options. This section describes these wizards in detail. Use one of the following options to launch the New Model Wizard. Click File > New > Teiid Metadata Model action . Select a project or folder in the Model Explorer View and choose the same action in the right-click menu. Select the New button on the main toolbar and select the Teiid Metadata Model action . Note Model names are required to be unique within Teiid Designer . When specifying model names in new model wizards and dialogs error messages will be presented and you will prevented from entering an existing name.

Commands: