mtpti5iD/redhat-docs_dataset huggingface dataset:
8.94. libqb 8.94.1. RHBA-2013:1634 - libqb bug fix and enhancement update Updated libqb packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libqb packages provide a library with the primary purpose of providing high performance client server reusable features, such as high performance logging, tracing, inter-process communication, and polling. Note The libqb packages have been upgraded to upstream version 0.16.0, which provides a number of bug fixes and enhancements over the version, including a patch to fix a bug in the qb_log_from_external_source() function that caused the Pacemaker's policy engine to terminate unexpectedly. (BZ# 950403 ) Bug Fix BZ# 889299 Output of the Blackbox window manager did not contain logging information if the string's length or precision was specified. This affected usability of the Blackbox output for debugging purposes, specifically when used with the Pacemaker cluster resource manager. The problem was caused by bugs in the libqb's implementation of the strlcpy() and strlcat() functions and the code responsible for the Blackbox log formatting. This update corrects these bugs so the Blackbox output is now formatted as expected. Users of libqb are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 7. Uninstalling a cluster on Alibaba Cloud You can remove a cluster that you deployed to Alibaba Cloud. 7.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 (UPI) clusters. There might be resources that the installer did not create or that the installer 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. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, 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
Chapter 4. External storage services Red Hat OpenShift Data Foundation can use IBM FlashSystems or make services from an external Red Hat Ceph Storage cluster available for consumption through OpenShift Container Platform clusters running on the following platforms: VMware vSphere Bare metal Red Hat OpenStack platform (Technology Preview) IBM Power IBM Z The OpenShift Data Foundation operators create and manage services to satisfy Persistent Volume (PV) and Object Bucket Claims (OBCs) against the external services. External cluster can serve block, file and object storage classes for applications that run on OpenShift Container Platform. The operators do not deploy or manage the external clusters.

Commands:
Chapter 7. Fixed Common Vulnerabilities and Exposures This section details Common Vulnerabilities and Exposures (CVEs) fixed in the AMQ Broker 7.11 release. ENTMQBR-6630 - CVE-2022-1278 WildFly: possible information disclosure ENTMQBR-7397 - CVE-2022-22970 springframework: DoS via data binding to multipartFile or servlet part ENTMQBR-7398 - CVE-2022-22971 springframework: DoS with STOMP over WebSocket ENTMQBR-7005 - CVE-2022-2047 jetty-http: improver hostname input handling ENTMQBR-7640 - CVE-2022-3782 keycloak: path traversal via double URL encoding

Commands:
Chapter 1. Machine APIs 1.1. ContainerRuntimeConfig [machineconfiguration.openshift.io/v1] Description ContainerRuntimeConfig describes a customized Container Runtime configuration. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. ControllerConfig [machineconfiguration.openshift.io/v1] Description ControllerConfig describes configuration for MachineConfigController. This is currently only used to drive the MachineConfig objects generated by the TemplateController. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.3. ControlPlaneMachineSet [machine.openshift.io/v1] Description ControlPlaneMachineSet ensures that a specified number of control plane machine replicas are running at any given time. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. KubeletConfig [machineconfiguration.openshift.io/v1] Description KubeletConfig describes a customized Kubelet configuration. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. MachineConfig [machineconfiguration.openshift.io/v1] Description MachineConfig defines the configuration for a machine Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.6. MachineConfigPool [machineconfiguration.openshift.io/v1] Description MachineConfigPool describes a pool of MachineConfigs. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.7. MachineHealthCheck [machine.openshift.io/v1beta1] Description MachineHealthCheck is the Schema for the machinehealthchecks API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.8. Machine [machine.openshift.io/v1beta1] Description Machine is the Schema for the machines API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.9. MachineSet [machine.openshift.io/v1beta1] Description MachineSet ensures that a specified number of machines replicas are running at any given time. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object

Commands:
7.96. jss 7.96.1. RHBA-2013:0424 - jss bug fix and enhancement update Updated jss packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. Java Security Services (JSS) provides an interface between Java Virtual Machine and Network Security Services (NSS). It supports most of the security standards and encryption technologies supported by NSS including communication through SSL/TLS network protocols. JSS is primarily utilized by the Certificate Server. Bug Fix BZ#797352 Previously, some JSS calls to certain NSS functions were to be replaced with calls to the JCA interface. The original JSS calls were therefore deprecated and as such caused warnings to be reported during refactoring. However, the deprecated calls have not been fully replaced with their JCA-based implementation in JSS 4.2. With this update, the calls are now no longer deprecated and the warnings now longer occur. Enhancement BZ#804838 This update adds support for Elliptic Curve Cryptography (ECC) key archival in JSS. It provides new methods, such as getCurve(), Java_org_mozilla_jss_asn1_ASN1Util_getTagDescriptionByOid() and getECCurveBytesByX509PublicKeyBytes(). All users of jss are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands:
Chapter 6. References This chapter enumerates other references for more information about SystemTap. It is advisable that you refer to these sources in the course of writing advanced probes and tapsets. SystemTap Wiki The SystemTap Wiki is a collection of links and articles related to the deployment, usage, and development of SystemTap. You can find it at http://sourceware.org/systemtap/wiki/HomePage . SystemTap Tutorial Much of the content in this book comes from the SystemTap Tutorial . The SystemTap Tutorial is a more appropriate reference for users with intermediate to advanced knowledge of C++ and kernel development, and can be found at http://sourceware.org/systemtap/tutorial/ . man stapprobes The stapprobes man page enumerates a variety of probe points supported by SystemTap, along with additional aliases defined by the SystemTap tapset library. The bottom of the man page includes a list of other man pages enumerating similar probe points for specific system components, such as stapprobes.scsi , stapprobes.kprocess , stapprobes.signal and so on. man stapfuncs The stapfuncs man page enumerates numerous functions supported by the SystemTap tapset library, along with the prescribed syntax for each one. Note, however, that this is not a complete list of all supported functions; there are more undocumented functions available. SystemTap Language Reference This document is a comprehensive reference of SystemTap's language constructs and syntax. It is recommended for users with a rudimentary to intermediate knowledge of C++ and other similar programming languages. The SystemTap Language Reference is available to all users at http://sourceware.org/systemtap/langref/ Tapset Developers Guide Once you have sufficient proficiency in writing SystemTap scripts, you can then try your hand out on writing your own tapsets. The Tapset Developers Guide describes how to add functions to your tapset library. Test Suite The systemtap-testsuite package allows you to test the entire SystemTap toolchain without having to build from source. In addition, it also contains numerous examples of SystemTap scripts you can study and test; some of these scripts are also documented in Chapter 4, Useful SystemTap Scripts . By default, the example scripts included in systemtap-testsuite are located in /usr/share/systemtap/testsuite/systemtap.examples .

Commands:
Chapter 3. Using realmd to Connect to an Active Directory Domain The realmd system provides a clear and simple way to discover and join identity domains to achieve direct domain integration. It configures underlying Linux system services, such as SSSD or Winbind, to connect to the domain. Chapter 2, Using Active Directory as an Identity Provider for SSSD describes how to use the System Security Services Daemon (SSSD) on a local system and Active Directory as a back-end identity provider. Ensuring that the system is properly configured for this can be a complex task: there are a number of different configuration parameters for each possible identity provider and for SSSD itself. In addition, all domain information must be available in advance and then properly formatted in the SSSD configuration for SSSD to integrate the local system with AD. The realmd system simplifies that configuration. It can run a discovery search to identify available AD and Identity Management domains and then join the system to the domain, as well as set up the required client services used to connect to the given identity domain and manage user access. Additionally, because SSSD as an underlying service supports multiple domains, realmd can discover and support multiple domains as well. 3.1. Supported Domain Types and Clients The realmd system supports the following domain types: Microsoft Active Directory Red Hat Enterprise Linux Identity Management The following domain clients are supported by realmd : SSSD for both Red Hat Enterprise Linux Identity Management and Microsoft Active Directory Winbind for Microsoft Active Directory

Commands:
Chapter 8. Updating systems in a group If you have several systems using the same image in the edge management application, you can update several systems in a group simultaneously after you update the image. Use the More options icon (...) , select the images that you plan to update. You will be able to choose the package version to update your images. Warning Using RHEL for Edge customized images that were created using the on-site version of RHEL image builder is not supported by the edge management application. There is no support for updating an Edge system by using the CLI. You can only update your Edge systems by using the Red Hat Hybrid Cloud Console. Prerequisites You have a Red Hat Hybrid Cloud Console account. You have the systems registered with Remote Host Configuration and Management. You have an updated image that contains the changes you want to push to your systems. For more information, see Updating an image . Procedure Go to the edge management application in the Red Hat Hybrid Cloud Console platform and log in. In the edge management menu, click Inventory > Groups . Select the group from the list that contains several systems you want to update. Select the systems in the group that have the Update available status and that use the same image. You can check the image each system uses in the Image column. In the Group toolbar, click the Actions for group details menu, which is three vertical dots. Click Update selected . Review the information about the update. Click Update system . Verification Check Inventory > Groups and click the group from which the updates were triggered. If the update was sent to the system, the system status is Up to date . Additional resources How to start the upgrade process of an Edge Management deployed system . Edge Management supportability .

Commands:
Chapter 33. Unregistering from Red Hat Subscription Management Services A system can only be registered with one subscription service. If you need to change which service your system is registered with or need to delete the registration in general, then the method to unregister depends on which type of subscription service the system was originally registered with. 33.1. Systems Registered with Red Hat Subscription Management Several different subscription services use the same, certificate-based framework to identify systems, installed products, and attached subscriptions. These services are Customer Portal Subscription Management (hosted), Subscription Asset Manager (on-premise subscription service), and CloudForms System Engine (on-premise subscription and content delivery services). These are all part of Red Hat Subscription Management . For all services within Red Hat Subscription Management, the systems are managed with the Red Hat Subscription Manager client tools. To unregister a system registered with a Red Hat Subscription Management server, use the unregister command as root without any additional parameters: For additional information, see Using and Configuring Red Hat Subscription Manager .

Commands:
subscription-manager unregister
Preface This document describes steps for an in-place upgrade from RHEL 6 to RHEL 7. The available in-place upgrade path is from RHEL 6.10 to RHEL 7.9. Note that for RHEL 6.10, only the Extended Life Phase (ELP) support is available. If you are using SAP HANA, follow How do I upgrade from RHEL 6 to RHEL 7 with SAP HANA instead. Note that the upgrade path for RHEL with SAP HANA might differ. The process of upgrading from the latest version of RHEL 6 to the latest version of RHEL 7 consists of the following steps: Check that an upgrade of your system is available. See Chapter 1, Planning an upgrade for more information. Prepare your system for the upgrade by installing required repositories and packages and by removing unsupported packages. See Chapter 2, Preparing a RHEL 6 system for the upgrade got more information. Check your system for problems that might affect your upgrade using the Preupgrade Assistant. See Chapter 3, Assessing upgrade suitability for more information. Upgrade your system by running the Red Hat Upgrade Tool. See Chapter 4, Upgrading your system from RHEL 6 to RHEL 7 for more information.

Commands:
probe::scsi.iocompleted Name probe::scsi.iocompleted - SCSI mid-layer running the completion processing for block device I/O requests Synopsis scsi.iocompleted Values device_state The current state of the device dev_id The scsi device id req_addr The current struct request pointer, as a number data_direction_str Data direction, as a string device_state_str The current state of the device, as a string lun The lun number goodbytes The bytes completed data_direction The data_direction specifies whether this command is from/to the device channel The channel number host_no The host number

Commands:
Chapter 7. Enabling notifications and integrations You can enable the notifications service on Red Hat Hybrid Cloud Console to send notifications whenever a compliance policy is triggered. For example, you can configure the notifications service to automatically send an email message whenever a compliance policy falls below a certain threshold, or to send an email digest of all the compliance policy events that take place each day. Using the notifications service frees you from having to continually check the Red Hat Insights for RHEL dashboard for compliance event-triggered notifications. Enabling the notifications service requires three main steps: First, an Organization Administrator creates a User access group with the Notifications administrator role, and then adds account members to the group. , a Notifications administrator sets up behavior groups for events in the notifications service. Behavior groups specify the delivery method for each notification. For example, a behavior group can specify whether email notifications are sent to all users, or just to Organization administrators. Finally, users who receive email notifications from events must set their user preferences so that they receive individual emails for each event or a daily digest of all compliance events. In addition to sending email messages, you can configure the notifications service to send event data in other ways: Using an authenticated client to query Red Hat Insights APIs for event data Using webhooks to send events to third-party applications that accept inbound requests Integrating notifications with applications such as Splunk to route compliance events to the application dashboard Additional resources For more information about how to set up notifications for compliance events, see Configuring notifications on the Red Hat Hybrid Cloud Console .

Commands:
5.3. Enabling Referential Integrity This section describes how to enable the Referential Integrity Postoperation plug-in. 5.3.1. Enabling Referential Integrity Using the Command Line To enable the Referential Integrity Postoperation plug-in using the command line: Use the dsconf utility to enable the plug-in: Restart the instance: 5.3.2. Enabling Referential Integrity Using the Web Console To enable the Referential Integrity plug-in using the web console: 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. Select the Plugins menu. Select the Referential Integrity plug-in and click Show Advanced Settings . Change the status to ON to enable the plug-in.

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity enable
dsctl instance_name restart
2.8.9.6. IPTables and IPv6 If the iptables-ipv6 package is installed, netfilter in Red Hat Enterprise Linux can filter the -generation IPv6 Internet protocol. The command used to manipulate the IPv6 netfilter is ip6tables . Most directives for this command are identical to those used for iptables , except the nat table is not yet supported. This means that it is not yet possible to perform IPv6 network address translation tasks, such as masquerading and port forwarding. Rules for ip6tables are saved in the /etc/sysconfig/ip6tables file. rules saved by the ip6tables initscripts are saved in the /etc/sysconfig/ip6tables.save file. Configuration options for the ip6tables init script are stored in /etc/sysconfig/ip6tables-config , and the names for each directive vary slightly from their iptables counterparts. For example, for the iptables-config directive IPTABLES_MODULES the equivalent in the ip6tables-config file is IP6TABLES_MODULES .

Commands:
Chapter 5. Configuring Visual Studio Code - Open Source ("Code - OSS") Learn how to configure Visual Studio Code - Open Source ("Code - OSS"). Section 5.1, "Configuring single and multiroot workspaces" 5.1. Configuring single and multiroot workspaces With the multi-root workspace feature, you can work with multiple project folders in the same workspace. This is useful when you are working on several related projects at once, such as product documentation and product code repositories. Tip See What is a VS Code "workspace" for better understanding and authoring the workspace files. Note The workspace is set to open in multi-root mode by default. Once workspace is started, the /projects/.code-workspace workspace file is generated. The workspace file will contain all the projects described in the devfile. { "folders": [ { "name": "project-1", "path": "/projects/project-1" }, { "name": "project-2", "path": "/projects/project-2" } ] } If the workspace file already exist, it will be updated and all missing projects will be taken from the devfile. If you remove a project from the devfile, it will be left in the workspace file. You can change the default behavior and provide your own workspace file or switch to a single-root workspace. Procedure Provide your own workspace file. Put a workspace file with the name .code-workspace into the root of your repository. After workspace creation, the Visual Studio Code - Open Source ("Code - OSS") will use the workspace file as it is. { "folders": [ { "name": "project-name", "path": "." } ] } Important Be careful when creating a workspace file. In case of errors, an empty Visual Studio Code - Open Source ("Code - OSS") will be opened instead. Important If you have several projects, the workspace file will be taken from the first project. If the workspace file does not exist in the first project, a new one will be created and placed in the /projects directory. Specify alternative workspace file. Define the VSCODE_DEFAULT_WORKSPACE environment variable in your devfile and specify the right location to the workspace file. env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file" Open a workspace in a single-root mode. Define VSCODE_DEFAULT_WORKSPACE environment variable and set it to the root. env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"

Commands:
{ "folders": [ { "name": "project-1", "path": "/projects/project-1" }, { "name": "project-2", "path": "/projects/project-2" } ] }
{ "folders": [ { "name": "project-name", "path": "." } ] }
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"