mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. About OpenShift Service Mesh Red Hat OpenShift Service Mesh, which is based on the open source Istio project , addresses a variety of problems in a microservice architecture by creating a centralized point of control in an application. 1.1. Introduction to Red Hat OpenShift Service Mesh Red Hat OpenShift Service Mesh adds a transparent layer on existing distributed applications without requiring any changes to the application code. The mesh introduces an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provides more complex operational functionality, including A/B testing, canary releases, access control, and end-to-end authentication. Microservice architectures split the work of enterprise applications into modular services, which can make scaling and maintenance easier. However, as an enterprise application built on a microservice architecture grows in size and complexity, it becomes difficult to understand and manage. Service Mesh can address those architecture problems by capturing or intercepting traffic between services and can modify, redirect, or create new requests to other services. 1.2. Core features Red Hat OpenShift Service Mesh provides a number of key capabilities uniformly across a network of services: Traffic Management - Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions. Service Identity and Security - Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustworthiness. Policy Enforcement - Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code. Telemetry - Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.

Commands:
Chapter 7. New Packages 7.1. RHEA-2014:1521 - new package: convmv A new convmv package is now available for Red Hat Enterprise Linux 6. The convmv package contains a tool for converting the character-set encoding of file names. It is particularly useful for converting file names encoded in a legacy charset encoding such as ISO-8859 to UTF-8, or EUC to UTF-8. This enhancement update adds the convmv package to Red Hat Enterprise Linux 6. (BZ# 1005068 ) All users who require convmv are advised to install this new package.

Commands:
Appendix A. Revision History Revision History Revision 1-0.48 Thu Jan 21 2016 Lenka Spackova Added information about the removed systemtap-grapher package to the Deprecated Functionality Chapter. Revision 1-0.47 Tue Jan 27 2015 Milan Navratil Updated the Red Hat Enterprise Linux 6.5 Technical Notes. Revision 1-0.42 Mon Oct 20 2014 Miroslav Svoboda Updated the Red Hat Enterprise Linux 6.5 Technical Notes with the latest kernel changes. Revision 1-0.32 Fri Jun 20 2014 Miroslav Svoboda Updated the Red Hat Enterprise Linux 6.5 Technical Notes with the latest kernel erratum, RHSA-2014-0771. Revision 1-0.30 Mon Jun 02 2014 Eliska Slobodova Clarified that iSCSI and FCoE boot are fully supported features in Red Hat Enterprise Linux 6.5. Revision 1-0.29 Thu May 08 2014 Miroslav Svoboda Updated the Red Hat Enterprise Linux 6.5 Technical Notes with the latest kernel erratum, RHSA-2014-0475. Revision 1-0.25 Tue Feb 18 2014 Eliska Slobodova Added a Mellanox SR-IOV Technology Preview. Revision 1-0.23 Wed Feb 12 2014 Miroslav Svoboda Updated the Red Hat Enterprise Linux 6.5 Technical Notes with the latest kernel erratum, RHSA-2014-0159. Revision 1-0.22 Wed Jan 22 2014 Eliska Slobodova Added the missing eCryptfs Technology Preview. Revision 1-0.21 Fri Jan 10 2014 Eliska Slobodova Fixed several typos. Revision 1-0.17 Fri Dec 13 2013 Miroslav Svoboda Updated the Red Hat Enterprise Linux 6.5 Technical Notes with the latest kernel erratum, RHSA-2013-1801. Revision 1-0.15 Thu Nov 21 2013 Eliska Slobodova Release of the Red Hat Enterprise Linux 6.5 Technical Notes. Revision 1-0.0 Thu Oct 03 2013 Eliska Slobodova Release of the Red Hat Enterprise Linux 6.5 Beta Technical Notes.

Commands:
Chapter 7. Windows node upgrades You can ensure your Windows nodes have the latest updates by upgrading the Windows Machine Config Operator (WMCO). 7.1. Windows Machine Config Operator upgrades When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is upgraded based on the upgrade channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO upgrade results in the Kubernetes components in the Windows machine being upgraded. Because WMCO 6.0.0 uses containerd as the default container runtime instead of Docker, note the following changes that are made during the upgrade: For nodes created using a machine set: All machine objects are deleted, which results in the draining and deletion of any Windows nodes. New Windows nodes are created. The upgraded WMCO configures the new Windows nodes with containerd as the default runtime. After the new Windows nodes join the OpenShift Container Platform cluster, you can deploy pods on those nodes. For Bring-Your-Own-Host (BYOH) nodes: The kubelet, kube-proxy, CNI, and the hybrid-overlay components, which were installed by the WMCO, are all uninstalled. Any Windows OS-specific configurations that were created as part of configuring the instance, such as HNS networks, are deleted or reverted. The WMCO installs containerd as the default runtime, and reinstalls the kubelet, kube-proxy, CNI, and hybrid-overlay components. The kubelet service starts. After the new Windows nodes join the OpenShift Container Platform cluster, you can deploy pods on those nodes. If any Docker service is present, it continues to run. Alternatively, you can manually uninstall Docker. Note If you are upgrading to a new version of the WMCO and want to use cluster monitoring, you must have the openshift.io/cluster-monitoring=true label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display. For a non-disruptive upgrade, the WMCO terminates the Windows machines configured by the version of the WMCO and recreates them using the current version. This is done by deleting the Machine object, which results in the drain and deletion of the Windows node. To facilitate an upgrade, the WMCO adds a version annotation to all the configured nodes. During an upgrade, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an upgrade, the WMCO only updates one Windows machine at a time. Important The WMCO is only responsible for updating Kubernetes components, not for Windows operating system updates. You provide the Windows image when creating the VMs; therefore, you are responsible for providing an updated image. You can provide an updated Windows image by changing the image configuration in the MachineSet spec. For more information on Operator upgrades using the Operator Lifecycle Manager (OLM), see Updating installed Operators .

Commands:
Chapter 10. Publishing on the catalog After submitting your test results through the Red Hat certification portal, your application is scanned for vulnerabilities. When the scanning is completed, you can publish your product on the the Red Hat Ecosystem Catalog . A RHOSP application certification is generated if, you have performed the following: You ran the required tests successfully. Red Hat reviewed the testing configuration report, and found it was valid and appropriate for the certification. Perform the following steps to publish your product on the catalog: Procedure Navigate to your Product listing page. Click Publish . Your certified application is now published on the Red Hat Ecosystem Catalog.

Commands:
Chapter 2. Package Namespace Change for JBoss EAP 8.0 This section provides additional information for the package namespace changes in JBoss EAP 8.0. JBoss EAP 8.0 provides full support for Jakarta EE 10 and many other implementations of the Jakarta EE 10 APIs. An important change supported by Jakarta EE 10 for JBoss EAP 8.0 is the package namespace change. 2.1. javax to jakarta Namespace change A key difference between Jakarta EE 8 and EE 10 is the renaming of the EE API Java packages from javax.* to jakarta.* . This follows the move of Java EE to the Eclipse Foundation and the establishment of Jakarta EE. Adapting to this namespace change is the biggest task of migrating an application from JBoss EAP 7 to JBoss EAP 8. To migrate applications to Jakarta EE 10, you must complete the following steps: Update any import statements or other source code uses of EE API classes from the javax package to the jakarta package. Update the names of any EE-specified system properties or other configuration properties that begin with javax to begin with jakarta . For any application-provided implementations of EE interfaces or abstract classes that are bootstrapped using the java.util.ServiceLoader mechanism, change the name of the resource that identifies the implementation class from META-INF/services/javax.[rest_of_name] to META-INF/services/jakarta.[rest_of_name] . Note The Red Hat Migration Toolkit can assist in updating the namespaces in the application source code. For more information, see How to use Red Hat Migration Toolkit for Auto-Migration of an Application to the Jakarta EE 10 Namespace . In cases where source code migration is not an option, the Open Source Eclipse Transformer project provides bytecode transformation tooling to transform existing Java archives from the javax namespace to the jakarta namespace. Note This change does not affect javax packages that are part of Java SE. Additional resources For more information, see The javax to jakarta Package Namespace Change .

Commands:
B.106. xorg-x11-drv-wacom and wacomcpl B.106.1. RHBA-2011:0341 - xorg-x11-drv-wacom and wacomcpl bug fix update Updated xorg-x11-drv-wacom and wacomcpl packages that resolve several issues are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-wacom package provides an X Window System input device driver that allows the X server to handle Wacom tablets with extended functionality. The wacomcpl package provides a graphical user interface (GUI) for the xorg-x11-drv-wacom X input device driver. These updated xorg-x11-drv-wacom and wacomcpl packages provide fixes for the following bugs: BZ# 675908 Changing the screen mapping caused the wacompl GUI to become unresponsive. With this update, changing the screen mapping works as expected. BZ# 642915 Attempting to calibrate a device could have failed with an error message. With this update, calibration now succeeds. All users of xorg-x11-drv-wacom and wacomcpl are advised to upgrade to these updated packages, which resolve these issues.

Commands:
Chapter 4. Managing users on dashboard As a storage administrator, you can create, edit, and delete users on the dashboard. 4.1. Creating users on dashboard The dashboard allows you to create users on the dashboard. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. Note The Red Hat Ceph Storage Dashboard does not support any email verification when changing a users password. This behavior is intentional, because the Dashboard supports Single Sign-On (SSO) and this feature can be delegated to the SSO provider. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : On Users tab, click the Create button: In the CreateUser window, set the Username and other parameters including the roles, and then click the _CreateUser_button: A notification towards the top right corner of the page indicates the user was created successfully. Additional Resources See the Creating roles on dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details. 4.2. Editing users on dashboard The dashboard allows you to edit users on the dashboard. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. User created on the dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : To edit the user, click the row: On Users tab, select Edit from the Edit dropdown menu: In the EditUser window, edit parameters including, and then click the EditUser button: A notification towards the top right corner of the page indicates the user was updated successfully. Additional Resources See the Creating users on the dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details. 4.3. Deleting users on dashboard The dashboard allows you to delete users on the dashboard. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. User created on the dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : To delete the user, click the row: On Users tab, select Delete from the Edit dropdown menu: In the Delete User dialog window, Click the Yes, I am sure box and then Click Delete user to save the settings: Additional Resources See the Creating users on the dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details.

Commands:
Chapter 8. Migrating upstream Keycloak to Red Hat build of Keycloak 22.0 Starting with version 22, minimal differences exist between Red Hat build of Keycloak and upstream Keycloak. The following differences exist: For upstream Keycloak, the distribution artifacts are on keycloak.org ; for Red Hat build of Keycloak, the distribution artifacts are on the Red Hat customer portal . Oracle and MSSQL database drivers are bundled with upstream Keycloak, but not bundled with Red Hat build of Keycloak. See Configuring the database for detailed steps on how to install those drivers. The GELF log handler is not available in Red Hat build of Keycloak. The migration process depends on the version of Keycloak to be migrated and the type of Keycloak installation. See the following sections for details. 8.1. Matching Keycloak version The migration process depends on the version of Keycloak to be migrated. If your Keycloak project version matches the Red Hat build of Keycloak version, migrate Keycloak by using the Red Hat build of Keycloak artifacts on the Red Hat customer portal . If your Keycloak project version is an older version, use the Keycloak Upgrading Guide to upgrade Keycloak to match the Red Hat build of Keycloak version. Then, migrate Keycloak using the artifacts on the Red Hat customer portal . If your Keycloak project version is greater than the Red Hat build of Keycloak version, you cannot migrate to Red Hat build of Keycloak. Instead, create a new deployment of Red Hat build of Keycloak or wait for a future Red Hat build of Keycloak release. 8.2. Migration based on type of Keycloak installation Once you have a matching version of Keycloak, migrate Keycloak based on the type of installation. If you installed Keycloak from a ZIP distribution, migrate Keycloak by using the artifacts on the Red Hat customer portal . If you deployed the Keycloak Operator, uninstall it and install the Red Hat build of Keycloak Operator by using the Operator guide . The CRs are compatible between upstream Keycloak and Red Hat build of Keycloak. If you created a custom server container image, rebuild it by using the Red Hat build of Keycloak image. See Running Keycloak in a Container .

Commands:
9.6.3. Related Books Managing NFS and NIS by Hal Stern, Mike Eisler, and Ricardo Labiaga; O'Reilly &Associates - Makes an excellent reference guide for the many different NFS export and mount options available. NFS Illustrated by Brent Callaghan; Addison-Wesley Publishing Company - Provides comparisons of NFS to other network file systems and shows, in detail, how NFS communication occurs. System Administrators Guide ; Red Hat, Inc - The Network File System (NFS) chapter explains concisely how to set up an NFS clients and servers. Security Guide ; Red Hat, Inc - The Server Security chapter explains ways to secure NFS and other services.

Commands:
Chapter 1. Ansible development tools Ansible development tools ( ansible-dev-tools ) is a suite of tools provided with Ansible Automation Platform to help automation creators to create, test, and deploy playbook projects, execution environments, and collections. The Ansible VS Code extension by Red Hat integrates most of the Ansible development tools: you can use these tools from the VS Code user interface. Use Ansible development tools during local development of playbooks, local testing, and in a CI pipeline (linting and testing). This document describes how to use Ansible development tools to create a playbook project that contains playbooks and roles that you can reuse within the project. It also describes how to test the playbooks and deploy the project on your Ansible Automation Platform instance so that you can use the playbooks in automation jobs. 1.1. Ansible development tools components You can operate some Ansible development tools from the VS Code UI when you have installed the Ansible extension, and the remainder from the command line. VS Code is a free open-source code editor available on Linux, Mac, and Windows. Ansible VS Code extension This is not packaged with the Ansible Automation Platform RPM package, but it is an integral part of the automation creation workflow. From the VS Code UI, you can use the Ansible development tools for the following tasks: Scaffold directories for a playbook project or a collection. Write playbooks with the help of syntax highlighting and auto-completion. Debug your playbooks with a linter. Execute playbooks with Ansible Core using ansible-playbook . Execute playbooks in an execution environment with ansible-navigator . From the VS Code extension, you can also connect to Red Hat Ansible Lightspeed with IBM watsonx Code Assistant. Command-line Ansible development tools You can perform the following tasks with Ansible development tools from the command line, including the terminal in VS Code: Create an execution environment. Test your playbooks, roles, modules, plugins and collections.

Commands:
Chapter 11. Setting up PKI ACME Responder This chapter describes the installation and initial configuration on an ACME responder on a PKI server that already has a CA subsystem. Note The following assumes you installed the CA with the default instance name (i.e. pki-tomcat ). For information on how to manage PKI ACME Responder, see the Managing PKI ACME Responder chapter in the Red Hat Certificate System Administration Guide . 11.1. Installing PKI ACME Responder To install PKI ACME Responder on your PKI server, First download and install the pki-acme RPM package: Create an ACME responder in a PKI server instance using the following command: This creates the initial configuration files in the /etc/pki/pki-tomcat/acme directory. For more information, see the pki-server-acme manpage.

Commands:
dnf install pki-acme
pki-server acme-create
Chapter 2. Why Use Virtualization? Virtualization can be useful both for server deployments and individual desktop stations. Desktop virtualization offers cost-efficient centralized management and better disaster recovery. In addition, by using connection tools such as ssh , it is possible to connect to a desktop remotely. When used for servers, virtualization can benefit not only larger networks, but also deployments with more than a single server. Virtualization provides live migration, high availability, fault tolerance, and streamlined backups. 2.1. Virtualization Costs Virtualization can be expensive to introduce, but it often saves money in the long term. Consider the following benefits: Less power Using virtualization negates much of the need for multiple physical platforms. This equates to less power being drawn for machine operation and cooling, resulting in reduced energy costs. The initial cost of purchasing multiple physical platforms, combined with the machines' power consumption and required cooling, is drastically cut by using virtualization. Less maintenance Provided that adequate planning is performed before migrating physical systems to virtualized ones, less time is needed to maintain them. This means less money needs to be spent on parts and labor. Extended life for installed software Older versions of software may not be able to run directly on more recent bare-metal machines. By running older software virtually on a larger, faster system, the life of the software may be extended while taking advantage of better performance from a newer system. Predictable costs A Red Hat Enterprise Linux subscription provides support for virtualization at a fixed rate, making it easy to predict costs. Less space Consolidating servers onto fewer machines means less physical space is required for computer systems.

Commands:
3.3. Enabling IP Ports Before deploying the Red Hat High Availability Add-On, you must enable certain IP ports on the cluster nodes and on computers that run luci (the Conga user interface server). The following sections identify the IP ports to be enabled: Section 3.3.1, "Enabling IP Ports on Cluster Nodes" Section 3.3.2, "Enabling the IP Port for luci " The following section provides the iptables rules for enabling IP ports needed by the Red Hat High Availability Add-On: Section 3.3.3, "Configuring the iptables Firewall to Allow Cluster Components" 3.3.1. Enabling IP Ports on Cluster Nodes To allow the nodes in a cluster to communicate with each other, you must enable the IP ports assigned to certain Red Hat High Availability Add-On components. Table 3.1, "Enabled IP Ports on Red Hat High Availability Add-On Nodes" lists the IP port numbers, their respective protocols, and the components to which the port numbers are assigned. At each cluster node, enable IP ports for incoming traffic according to Table 3.1, "Enabled IP Ports on Red Hat High Availability Add-On Nodes" . You can use system-config-firewall to enable the IP ports. Table 3.1. Enabled IP Ports on Red Hat High Availability Add-On Nodes IP Port Number Protocol Component 5404, 5405 UDP corosync/cman (Cluster Manager) 11111 TCP ricci (propagates updated cluster information) 21064 TCP dlm (Distributed Lock Manager) 16851 TCP modclusterd

Commands: