mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. ComponentStatus [v1] Description ComponentStatus (and ComponentStatusList) holds the cluster validation info. Deprecated: This API is deprecated in v1.19+ Type object 4.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources conditions array List of component conditions observed conditions[] object Information about the condition of a component. kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ObjectMeta Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata 4.1.1. .conditions Description List of component conditions observed Type array 4.1.2. .conditions[] Description Information about the condition of a component. Type object Required type status Property Type Description error string Condition error code for a component. For example, a health check error code. message string Message about the condition for a component. For example, information about a health check. status string Status of the condition for a component. Valid values for "Healthy": "True", "False", or "Unknown". type string Type of condition for a component. Valid value: "Healthy" 4.2. API endpoints The following API endpoints are available: /api/v1/componentstatuses GET : list objects of kind ComponentStatus /api/v1/componentstatuses/{name} GET : read the specified ComponentStatus 4.2.1. /api/v1/componentstatuses HTTP method GET Description list objects of kind ComponentStatus Table 4.1. HTTP responses HTTP code Reponse body 200 - OK ComponentStatusList schema 401 - Unauthorized Empty 4.2.2. /api/v1/componentstatuses/{name} Table 4.2. Global path parameters Parameter Type Description name string name of the ComponentStatus HTTP method GET Description read the specified ComponentStatus Table 4.3. HTTP responses HTTP code Reponse body 200 - OK ComponentStatus schema 401 - Unauthorized Empty

Commands:
Chapter 55. TlsSidecar schema reference The type TlsSidecar has been deprecated. Used in: CruiseControlSpec , EntityOperatorSpec Full list of TlsSidecar schema properties The TLS sidecar type is not used anymore. If set, it will be ignored 55.1. TlsSidecar schema properties Property Property type Description image string The docker image for the container. resources ResourceRequirements CPU and memory resources to reserve. livenessProbe Probe Pod liveness checking. readinessProbe Probe Pod readiness checking. logLevel string (one of [emerg, debug, crit, err, alert, warning, notice, info]) The log level for the TLS sidecar. Default value is notice .

Commands:
Chapter 3. Unsupported features and deprecated features 3.1. Unsupported features Support for some technologies is removed due to the high maintenance cost, low community interest, and better alternative solutions. The following features are not supported in JBoss EAP XP 5.0: MicroProfile Metrics MicroProfile Metrics is no longer supported, and is replaced by Micrometer. MicroProfile OpenTracing MicroProfile OpenTracing is no longer supported, and is replaced by OpenTelemetry Tracing. Red Hat OpenShift Streams for Apache Kafka Since Red Hat no longer offers Red Hat OpenShift Streams for Apache Kafka (RHOSAK), the MicroProfile Reactive Messaging with Kafka quickstart has been updated to not demonstrate connecting to RHOSAK. Snappy compression disabled for Windows systems JBoss EAP XP 5.0 does not support Snappy compression on Windows platforms for the MicroProfile Reactive Messaging Kafka connector. The Kafka connector for MicroProfile Reactive Messaging introduced Snappy compression in JBoss EAP XP 4.0.2 using Snappy version 1.1.8.4. However, Java Snappy compression was removed in version 1.1.9.0 of Snappy due to data corruption concerns. JBoss EAP XP 5.0 now uses the latest version of Snappy, 1.1.10.5, which uses native code for compression. The Red Hat build of the Snappy jar includes only the Linux natives. MicroProfile Reactive Messaging Kafka client The MicroProfile Reactive Messaging Kafka client available with JBoss EAP XP 5.0 is not supported on Windows platforms. For a complete list of unsupported features in JBoss EAP 8.0, see the Unsupported features section in JBoss EAP 8.0 Release Notes. 3.2. Deprecated features Some features have been deprecated with this release. This means that no enhancements are made to these features, and they might be removed in the future, usually the major release. For more information, see Deprecated features in Red Hat JBoss Enterprise Application Platform expansion pack (EAP XP) 5 . Red Hat continues to provide full support and bug fixes under our standard support terms and conditions. For more information about the Red Hat support policy for JBoss EAP XP, see the Red Hat JBoss Enterprise Application Platform expansion pack life cycle and support policies located on the Red Hat Customer Portal. Important All of the features that were deprecated in Red Hat JBoss Enterprise Application Platform 8.0 are also deprecated in JBoss EAP XP 5.0.0. For more information about deprecated features in JBoss EAP 8.0, see Deprecated features in the Release notes for Red Hat JBoss Enterprise Application Platform 8.0 . JBoss EAP OpenShift templates JBoss EAP templates for OpenShift are removed. Legacy patching for bootable jar The legacy patching feature for bootable jar is removed.

Commands:
14.9. Rebasing a Backing File of an Image The qemu-img rebase changes the backing file of an image. The backing file is changed to backing_file and (if the format of filename supports the feature), the backing file format is changed to backing_format . Note Only the qcow2 format supports changing the backing file (rebase). There are two different modes in which rebase can operate: safe and unsafe . safe mode is used by default and performs a real rebase operation. The new backing file may differ from the old one and the qemu-img rebase command will take care of keeping the guest virtual machine-visible content of filename unchanged. In order to achieve this, any clusters that differ between backing_file and old backing file of filename are merged into filename before making any changes to the backing file. Note that safe mode is an expensive operation, comparable to converting an image. The old backing file is required for it to complete successfully. unsafe mode is used if the -u option is passed to qemu-img rebase . In this mode, only the backing file name and format of filename is changed, without any checks taking place on the file contents. Make sure the new backing file is specified correctly or the guest-visible content of the image will be corrupted. This mode is useful for renaming or moving the backing file. It can be used without an accessible old backing file. For instance, it can be used to fix an image whose backing file has already been moved or renamed.

Commands:
qemu-img rebase [-f fmt ] [-t cache ] [-p] [-u] -b backing_file [-F backing_fmt ] filename
17.3. Build the Application Procedure 17.3. Build the Application Open a command line and navigate to the root directory of this quickstart. Execute the following command to build the archive: Copy the application to the appropriate server: For Linux: For Windows: When domain mode is used, deploy the applications in the following way: For Linux: For Windows: Report a bug

Commands:
mvn clean install
cp adminApp/ear/target/jboss-eap-application-adminApp.ear EAP_HOME1/standalone/deployments cp appOne/ear/target/jboss-eap-application-AppOne.ear EAP_HOME2/standalone/deployments cp appTwo/ear/target/jboss-eap-application-AppTwo.ear EAP_HOME3/standalone/deployments cp appTwo/ear/target/jboss-eap-application-AppTwo.ear EAP_HOME4/standalone/deployments
copy adminApp\ear\target\jboss-eap-application-adminApp.ear EAP_HOME1\standalone\deployments copy appOne\ear\target\jboss-eap-application-AppOne.ear EAP_HOME2\standalone\deployments copy appTwo\ear\target\jboss-eap-application-AppTwo.ear EAP_HOME3\standalone\deployments copy appTwo\ear\target\jboss-eap-application-AppTwo.ear EAP_HOME4\standalone\deployments
EAP_HOME/bin/jboss-cli.sh -c --file=QUICKSTART_HOME/deploy-domain.cli
EAP_HOME\bin\jboss-cli.bat -c --file=QUICKSTART_HOME/deploy-domain.cli
6.6. Removing Lost Physical Volumes from a Volume Group If you lose a physical volume, you can activate the remaining physical volumes in the volume group with the --partial argument of the vgchange command. You can remove all the logical volumes that used that physical volume from the volume group with the --removemissing argument of the vgreduce command. It is recommended that you run the vgreduce command with the --test argument to verify what you will be destroying. Like most LVM operations, the vgreduce command is reversible in a sense if you immediately use the vgcfgrestore command to restore the volume group metadata to its state. For example, if you used the --removemissing argument of the vgreduce command without the --test argument and find you have removed logical volumes you wanted to keep, you can still replace the physical volume and use another vgcfgrestore command to return the volume group to its state.

Commands:
Preface Depending on your organization's security policies, you might require to identify and authorize users before giving them access to resources, such as Red Hat Developer Hub. In Developer Hub, authentication and authorization are two separate processes: Authentication defines the user identity, and passes on this information to Developer Hub. Read the following chapters to configure authentication in Developer Hub. Authorization defines what the authenticated identity can access or do in Developer Hub. See Authorization . Not recommended for production To explore Developer Hub features, you can enable the guest user to skip configuring authentication and authorization, log in as the guest user, and access all the features. The authentication system in Developer Hub is handled by external authentication providers. Developer Hub supports following authentication providers: Red Hat Single-Sign On (RHSSO) GitHub Microsoft Azure To identify users in Developer Hub, configure: One (and only one) authentication provider for sign-in and identification. Optionally, additional authentication providers for identification, to add more information to the user identity, or enable access to additional external resources. For each authentication provider, set up the shared secret that the authentication provider and Developer Hub require to communicate, first in the authentication provider, then in Developer Hub. Developer Hub stores user identity information in the Developer Hub software catalog. Not recommended for production To explore the authentication system and use Developer Hub without authorization policies, you can bypass the Developer Hub software catalog and start using Developer Hub without provisioning the Developer Hub software catalog. To get, store, and update additional user information, such as group or team ownership, with the intention to use this data to define authorization policies, provision users and groups in the Developer Hub software catalog. Important Developer Hub uses a one-way synchronization system to provision users and groups from your authentication system to the Developer Hub software catalog. Therefore, deleting users and groups by using Developer Hub Web UI or REST API might have unintended consequences.

Commands:
Chapter 148. KafkaNodePoolSpec schema reference Used in: KafkaNodePool Property Property type Description replicas integer The number of pods in the pool. storage EphemeralStorage , PersistentClaimStorage , JbodStorage Storage configuration (disk). Cannot be updated. roles string (one or more of [controller, broker]) array The roles that the nodes in this pool will have when KRaft mode is enabled. Supported values are 'broker' and 'controller'. This field is required. When KRaft mode is disabled, the only allowed value if broker . resources ResourceRequirements CPU and memory resources to reserve. jvmOptions JvmOptions JVM Options for pods. template KafkaNodePoolTemplate Template for pool resources. The template allows users to specify how the resources belonging to this pool are generated.

Commands:
11.3.3.6. Informational or Debugging Options Certain options used after the fetchmail command can supply important information. --configdump - Displays every possible option based on information from .fetchmailrc and Fetchmail defaults. No email is retrieved for any users when using this option. -s - Executes Fetchmail in silent mode, preventing any messages, other than errors, from appearing after the fetchmail command. -v - Executes Fetchmail in verbose mode, displaying every communication between Fetchmail and remote email servers. -V - Displays detailed version information, lists its global options, and shows settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when using this option.

Commands:
Chapter 2. Running Red Hat Quay in debug mode Red Hat recommends gathering your debugging information when opening a support case. Running Red Hat Quay in debug mode provides verbose logging to help administrators find more information about various issues. Enabling debug mode can speed up the process to reproduce errors and validate a solution for things like geo-replication deployments, Operator deployments, standalone Red Hat Quay deployments, object storage issues, and so on. Additionally, it helps the Red Hat Support to perform a root cause analysis. 2.1. Running a standalone Red Hat Quay deployment in debug mode Running Red Hat Quay in debug mode provides verbose logging to help administrators find more information about various issues. Enabling debug mode can speed up the process to reproduce errors and validate a solution. Use the following procedure to run a standalone deployment of Red Hat Quay in debug mode. Procedure Enter the following command to run your standalone Red Hat Quay deployment in debug mode: USD podman run -p 443:8443 -p 80:8080 -e DEBUGLOG=true -v /config:/conf/stack -v /storage:/datastorage -d {productrepo}/{quayimage}:{productminv} To view the debug logs, enter the following command: USD podman logs quay 2.2. Running the Red Hat Quay Operator in debug mode Use the following procedure to run the Red Hat Quay Operator in debug mode. Procedure Enter the following command to edit the QuayRegistry custom resource definition: USD oc edit quayregistry <quay_registry_name> -n <quay_namespace> Update the QuayRegistry to add the following parameters: spec: - kind: quay managed: true overrides: env: - name: DEBUGLOG value: "true" After the Red Hat Quay Operator has restarted with debugging enabled, try pulling an image from the registry. If it is still slow, dump all dogs from all Quay pods to a file, and check the files for more information.

Commands:
podman run -p 443:8443 -p 80:8080 -e DEBUGLOG=true -v /config:/conf/stack -v /storage:/datastorage -d {productrepo}/{quayimage}:{productminv}
podman logs quay
oc edit quayregistry <quay_registry_name> -n <quay_namespace>
spec: - kind: quay managed: true overrides: env: - name: DEBUGLOG value: "true"
E.2. Metadata Contents The volume group metadata contains: Information about how and when it was created Information about the volume group: The volume group information contains: Name and unique id A version number which is incremented whenever the metadata gets updated Any properties: Read/Write? Resizeable? Any administrative limit on the number of physical volumes and logical volumes it may contain The extent size (in units of sectors which are defined as 512 bytes) An unordered list of physical volumes making up the volume group, each with: Its UUID, used to determine the block device containing it Any properties, such as whether the physical volume is allocatable The offset to the start of the first extent within the physical volume (in sectors) The number of extents An unordered list of logical volumes. each consisting of An ordered list of logical volume segments. For each segment the metadata includes a mapping applied to an ordered list of physical volume segments or logical volume segments

Commands:
Chapter 35. Configuring TLS for Identity Management This document describes how to configure an Identity Management server to require the TLS protocol version 1.2 in Red Hat Enterprise Linux 7.3 and later. TLS 1.2 is considered more secure than versions of TLS. If your IdM server is deployed in an environment with high security requirements, you can configure it to forbid communication using protocols that are less secure than TLS 1.2. Important Repeat these steps on every IdM server where you want to use TLS 1.2. 35.1. Configuring the httpd Daemon Open the /etc/httpd/conf.d/nss.conf file, and set the following values for the NSSProtocol and NSSCipherSuite entries: Alternatively, use the following commands to set the values for you: Restart the httpd daemon:

Commands:
NSSProtocol TLSv1.2 NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
sed -i 's/^NSSProtocol .*/NSSProtocol TLSv1.2/' /etc/httpd/conf.d/nss.conf sed -i 's/^NSSCipherSuite .*/NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha/' /etc/httpd/conf.d/nss.conf
systemctl restart httpd
8.25. ca-certificates 8.25.1. RHEA-2014:1500 - ca-certificates enhancement update Updated ca-certificates package that adds various enhancements is now available for Red Hat Enterprise Linux 6. The ca-certificates package contains a set of CA certificates chosen by the Mozilla Foundation for use with the Internet Public Key Infrastructure (PKI). The ca-certificate package has been upgraded to version 2014.1.98, released with Network Security Services (NSS) version 3.16.1, which provides a number of enhancements over the version. (BZ# 1035355 ) Users of ca-certificates are advised to upgrade to this updated package, which adds these enhancements.

Commands:
Preface An administrator can install Red Hat Fuse on Red Hat JBoss Enterprise Application Platform so that programmers can develop Fuse applications that run on JBoss EAP. For information about JBoss EAP, see Introduction to JBoss EAP . To install Fuse on JBoss EAP, see: Chapter 1, Installing Fuse on JBoss EAP Chapter 2, Starting Fuse on JBoss EAP server Chapter 3, Verifying installation of Fuse on JBoss EAP Chapter 4, Adding Fuse users to JBoss EAP Chapter 5, Stopping JBoss EAP Chapter 6, Patching a Fuse on JBoss EAP installation Chapter 7, Setting up Maven locally

Commands:
Chapter 4. AMQP AMQP is an open internet protocol for reliably sending and receiving messages. It is supported by multiple software vendors and major institutions. AMQP 1.0 became an OASIS standard in 2012 and an ISO standard in 2014. A framed protocol with session multiplexing Supports peer-to-peer and client-server connections Provides a standard type system for lossless data exchange Offers flow control, heartbeating, and resource limits for increased reliability in distributed systems Uses a space-efficient binary encoding and pipelining to reduce latency 4.1. AMQP delivery guarantees The AMQP model for settlement is based on the lifecycle of a message delivery. At each end of a link, an entity representing a message transfer is created, it exists for some period of time, and finally it is "settled", meaning it can be forgotten. There are four events of interest in the combined lifecycle of a delivery. The delivery is created at the sender. The delivery is created at the receiver. The delivery is settled at the sender. The delivery is settled at the receiver. Because the sender and receiver are operating concurrently, these events can occur in various orders, and the order of these events results in differing message delivery guarantees. At-most-once delivery At-most-once delivery is also known as "presettled" or "fire and forget" delivery. The delivery is created at the sender. The delivery is settled at the sender. The delivery is created at the receiver. The delivery is settled at the receiver. In this configuration the sender settles (that is, forgets) the delivery before it reaches the receiver, and if anything happens to the delivery in flight, the sender has no basis for resending. This mode is suited to applications where temporary message loss is acceptable, such as for periodic sensor data, or when the application itself can detect the failure and resend. At-least-once delivery The delivery is created at the sender. The delivery is created at the receiver. The delivery is settled at the receiver. The delivery is settled at the sender. In this configuration, the receiver settles the delivery when it has received it, and the sender settles once it sees the receiver has settled. If anything happens to the delivery in flight, the sender can resend. The receiver, however, has already forgotten the delivery, so a resend will result in a duplicate message delivery. Applications can use unique message IDs to filter out duplicates.

Commands:
1.2. Comparing Static to Dynamic IP Addressing Static IP addressing When a device is assigned a static IP address, the address does not change over time unless changed manually. It is recommended to use static IP addressing if you want: To ensure network address consistency for servers such as DNS , and authentication servers. To use out-of-band management devices that work independently of other network infrastructure. All the configuration tools listed in Section 3.1, "Selecting Network Configuration Methods" allow assigning static IP addresses manually. The nmcli tool is also suitable, described in Section 3.3.8, "Adding and Configuring a Static Ethernet Connection with nmcli" . For more information on automated configuration and management, see the OpenLMI chapter in the Red Hat Enterprise Linux 7 System Administrators Guide . The Red Hat Enterprise Linux 7 Installation Guide documents the use of a Kickstart file which can also be used for automating the assignment of network settings. Dynamic IP addressing When a device is assigned a dynamic IP address, the address changes over time. For this reason, it is recommended for devices that connect to the network occasionally because IP address might be changed after rebooting the machine. Dynamic IP addresses are more flexible, easier to set up and administer. The dynamic host control protocol ( DHCP ) is a traditional method of dynamically assigning network configurations to hosts. See Section 14.1, "Why Use DHCP?" for more information. You can also use the nmcli tool, described in Section 3.3.7, "Adding and Configuring a Dynamic Ethernet Connection with nmcli" . Note There is no strict rule defining when to use static or dynamic IP address. It depends on user's needs, preferences and the network environment. By default, NetworkManager calls the DHCP client, dhclient .

Commands:
32.3.4. Displaying a Process Status To display status of processes in the system, type the ps command at the interactive prompt. You can use ps pid to display the status of the selected process. Example 32.5. Displaying status of processes in the system Type help ps for more information on the command usage.

Commands:
crash> ps PID PPID CPU TASK ST %MEM VSZ RSS COMM > 0 0 0 c09dc560 RU 0.0 0 0 [swapper] > 0 0 1 f7072030 RU 0.0 0 0 [swapper] 0 0 2 f70a3a90 RU 0.0 0 0 [swapper] > 0 0 3 f70ac560 RU 0.0 0 0 [swapper] 1 0 1 f705ba90 IN 0.0 2828 1424 init ... several lines omitted 5566 1 1 f2592560 IN 0.0 12876 784 auditd 5567 1 2 ef427560 IN 0.0 12876 784 auditd 5587 5132 0 f196d030 IN 0.0 11064 3184 sshd > 5591 5587 2 f196d560 RU 0.0 5084 1648 bash