mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Installing Service Registry on OpenShift This chapter explains how to install Service Registry on OpenShift Container Platform: Section 2.1, "Installing Service Registry from the OpenShift OperatorHub" Prerequisites Read the introduction in the Service Registry User Guide . 2.1. Installing Service Registry from the OpenShift OperatorHub You can install the Service Registry Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators. For more details, see Understanding OperatorHub . Note You can install more than one instance of Service Registry depending on your environment. The number of instances depends on the number and type of artifacts stored in Service Registry and on your chosen storage option. Prerequisites You must have cluster administrator access to an OpenShift cluster. Procedure In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges. Create a new OpenShift project: In the left navigation menu, click Home , Project , and then Create Project . Enter a project name, for example, my-project , and click Create . In the left navigation menu, click Operators and then OperatorHub . In the Filter by keyword text box, enter registry to find the Red Hat Integration - Service Registry Operator . Read the information about the Operator, and click Install to display the Operator subscription page. Select your subscription settings, for example: Update Channel : Select one of the following: 2.x : Includes all minor and patch updates, such as 2.3.0 and 2.0.3. For example, an installation on 2.0.x will upgrade to 2.3.x. 2.0.x : Includes patch updates only, such as 2.0.1 and 2.0.2. For example, an installation on 2.0.x will ignore 2.3.x. Installation Mode : Select one of the following: All namespaces on the cluster (default) A specific namespace on the cluster and then my-project Approval Strategy : Select Automatic or Manual Click Install , and wait a few moments until the Operator is ready for use. Additional resources Adding Operators to an OpenShift cluster Apicurio Registry Operator community in GitHub

Commands:
32.8.5. Changing partition layout The following example %pre script generates a different set of partitioning commands depending on whether the system has two drives or not. Adding the following line after the %pre script then instructs Kickstart to execute the commands that were generated by the script above:

Commands:
%pre #!/bin/sh hds="" mymedia="" for file in /proc/ide/h* do mymedia=`cat USDfile/media` if [ USDmymedia == "disk" ] ; then hds="USDhds `basename USDfile`" fi done set USDhds numhd=`echo USD#` drive1=`echo USDhds | cut -d' ' -f1` drive2=`echo USDhds | cut -d' ' -f2` #Write out partition scheme based on whether there are 1 or 2 hard drives if [ USDnumhd == "2" ] ; then #2 drives echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "zerombr" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75 --ondisk hda" >> /tmp/part-include echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include echo "part swap --recommended --ondisk USDdrive1" >> /tmp/part-include echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include else #1 drive echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75" >> /tmp/part-include echo "part swap --recommended" >> /tmp/part-include echo "part / --fstype ext3 --size 2048" >> /tmp/part-include echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include fi %end
%include /tmp/part-include
4.174. mcelog 4.174.1. RHEA-2011:1579 - mcelog enhancement update An enhanced mcelog package is now available for Red Hat Enterprise Linux 6. mcelog is a daemon that collects and decodes Machine Check Exception data on AMD64 and Intel 64 machines. Enhancement BZ# 699592 This update enables full Predictive Failure Analysis (PFA) support in mcelog. Predictive Failure Analysis (PFA) is a technology for monitoring the probability of hard disk drive failure. In addition, mcelog is now able to collect and log data by default upon package installation. Users of mcelog are advised to upgrade to this updated package, which adds these enhancements.

Commands:
7.239. ypbind 7.239.1. RHBA-2015:1332 - ypbind bug fix and enhancement update Updated ypbind packages that fix several bugs and add one enhancement 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 Fixes BZ# 829487 Previously, the localhost was not treated specifically in the domains list of the ypbind program. Consequently, when the network connection was not established the ypbind did not bind to the ypserv utility on the localhost. With this update, a check for the localhost has been added, and now ypbind works even if the network connection is off. BZ# 842228 Prior to this update, the SIGPIPE signal was not in the proper signal set. Consequently, when a loss of network connectivity occurred, the ypbind utility terminated unexpectedly. Adding SIGPIPE to the proper signal set fixes this bug, and ypbind no longer crashes. BZ# 888778 Previously, the ypbind program's init script did not check for the presence of the ypbind line in the /etc/rpc file. As a consequence, if the ypbind line was not present, ypbind failed to start. This update adds a patch to check for the presence of the ypbind line in /etc/rpc. As a result, ypbind provides a warning message in the log files when its line is missing in /etc/rpc. Enhancement BZ# 918276 This update adds a configurable option for setting the time interval which is used by the ypbind program to retry rebinding. Previously, ypbind checked for the fastest NIS server every 15 minutes. This in some cases led to intermittent failures when the default timeout interval on a server firewall was set to 10 minutes. The added configurable option allows to set a specific time interval after which ypbind performs a check for the fastest NIS server, and thus avoids the intermittent failures during the rebinding process. Users of ypbind are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

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. 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 Upgrading installed Operators .

Commands:
6.12. RHEA-2013:0336 - new package: tuna A new tuna package is now available for Red Hat Enterprise Linux 6. The tuna package provides an interface for changing both scheduler and IRQ tunables, at whole CPU, per-thread or per-IRQ levels. tuna allows CPUs to be isolated for use by a specific application and threads and interrupts to be moved to a CPU simply by dragging and dropping them. This enhancement update adds the tuna package to Red Hat Enterprise Linux 6. (BZ#812455) All users who require tuna should install this new package.

Commands:
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) IBM Power clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. Note Only internal OpenShift Data Foundation clusters are supported on IBM Power. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, follow the appropriate deployment process: Internal-Attached Devices mode Deploy using local storage devices Deploy standalone Multicloud Object Gateway component

Commands:
Chapter 5. Downloading the test plan from Red Hat Certification Portal Procedure Log in to Red Hat Certification portal . Search for the case number related to your product certification, and copy it. Click Cases enter the product case number. Optional: To list the components that are tested during the test run, click Test Plans . Click Download Test Plan . steps If you plan to use Cockpit to run the tests, see Configuring the systems and running tests by using Cockpit . If you plan to use CLI to run the tests, see Configuring the systems and running tests by using CLI .

Commands:
Chapter 11. File-based configuration AMQ JavaScript can read the configuration options used to establish connections from a local file named connect.json . This enables you to configure connections in your application at the time of deployment. The library attempts to read the file when the application calls the container connect method without supplying any connection options. 11.1. File locations If set, AMQ JavaScript uses the value of the MESSAGING_CONNECT_FILE environment variable to locate the configuration file. If MESSAGING_CONNECT_FILE is not set, AMQ JavaScript searches for a file named connect.json at the following locations and in the order shown. It stops at the first match it encounters. On Linux: USDPWD/connect.json , where USDPWD is the current working directory of the client process USDHOME/.config/messaging/connect.json , where USDHOME is the current user home directory /etc/messaging/connect.json On Windows: %cd%/connect.json , where %cd% is the current working directory of the client process If no connect.json file is found, the library uses default values for all options. 11.2. The file format The connect.json file contains JSON data, with additional support for JavaScript comments. All of the configuration attributes are optional or have default values, so a simple example need only provide a few details: Example: A simple connect.json file { "host": "example.com", "user": "alice", "password": "secret" } SASL and SSL/TLS options are nested under "sasl" and "tls" namespaces: Example: A connect.json file with SASL and SSL/TLS options { "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } } 11.3. Configuration options The option keys containing a dot (.) represent attributes nested inside a namespace. Table 11.1. Configuration options in connect.json Key Value type Default value Description scheme string "amqps" "amqp" for cleartext or "amqps" for SSL/TLS host string "localhost" The hostname or IP address of the remote host port string or number "amqps" A port number or port literal user string None The user name for authentication password string None The password for authentication sasl.mechanisms list or string None (system defaults) A JSON list of enabled SASL mechanisms. A bare string represents one mechanism. If none are specified, the client uses the default mechanisms provided by the system. sasl.allow_insecure boolean false Enable mechanisms that send cleartext passwords tls.cert string None The filename or database ID of the client certificate tls.key string None The filename or database ID of the private key for the client certificate tls.ca string None The filename, directory, or database ID of the CA certificate tls.verify boolean true Require a valid server certificate with a matching hostname

Commands:
host: example.com
user: alice
password: secret
{ "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } }
9.6. Random Number Generator (RNG) Device virtio-rng is a virtual RNG ( random number generator ) device that feeds RNG data to the guest virtual machine's operating system, thereby providing fresh entropy for guest virtual machines on request. Using an RNG is particularly useful when a device such as a keyboard, mouse and other inputs are not enough to generate sufficient entropy on the guest virtual machine. The virtio-rng device is available for both Red Hat Enterprise Linux and Windows guest virtual machines. Refer to the Note for instructions on installing the Windows requirements. Unless noted, the following descriptions are for both Red Hat Enterprise Linux and Windows guest virtual machines. When virtio-rng is enabled on a Linux guest virtual machine, a chardev is created in the guest virtual machine at the location /dev/hwrng/ . This chardev can then be opened and read to fetch entropy from the host physical machine. In order for guest virtual machines' applications to benefit from using randomness from the virtio-rng device transparently, the input from /dev/hwrng/ must be relayed to the kernel entropy pool in the guest virtual machine. This can be accomplished if the information in this location is coupled with the rgnd daemon (contained within the rng-tools). This coupling results in the entropy to be routed to the guest virtual machine's /dev/random file. The process is done manually in Red Hat Enterprise Linux 6 guest virtual machines. Red Hat Enterprise Linux 6 guest virtual machines are coupled by running the following command: For more assistance, run the man rngd command for an explanation of the command options shown here. For further examples, refer to Procedure 9.11, "Implementing virtio-rng with the command line tools" for configuring the virtio-rng device. Note Windows guest virtual machines require the driver viorng to be installed. Once installed, the virtual RNG device will work using the CNG (crypto generation) API provided by Microsoft. Once the driver is installed, the virtrng device appears in the list of RNG providers. Procedure 9.11. Implementing virtio-rng with the command line tools Shut down the guest virtual machine. In a terminal window, using the virsh edit domain-name command, open the XML file for the desired guest virtual machine. Edit the <devices> element to include the following: ... <devices> <rng model='virtio'> <rate period="2000" bytes="1234"/> <backend model='random'>/dev/random</backend> <source mode='bind' service='1234'> <source mode='connect' host='192.0.2.1' service='1234'> </backend> </rng> </devices> ...

Commands:
rngd -b -r /dev/hwrng/ -o /dev/random/
<devices> <rng model='virtio'> <rate period="2000" bytes="1234"/> <backend model='random'>/dev/random</backend> <source mode='bind' service='1234'> <source mode='connect' host='192.0.2.1' service='1234'> </backend> </rng> </devices>
Chapter 8. Known issues ENTMQIC-1980 - Symbolic ports in HTTP listeners do not work When configuring a listener in the router with the http option enabled (for console or WebSocket access), the port attribute must be expressed numerically. Symbolic port names do not work with HTTP listeners. If a listener is configured as: It should be changed to: Revised on 2022-08-19 13:58:16 UTC

Commands:
listener { port: amqp http: yes }
listener { port: 5672 http: yes }
4.2. Logging Into the Piranha Configuration Tool When configuring the Load Balancer Add-On, you should always begin by configuring the primary router with the Piranha Configuration Tool . To do this,verify that the piranha-gui service is running and an administrative password has been set, as described in Section 2.2, "Setting a Password for the Piranha Configuration Tool" . If you are accessing the machine locally, you can open http://localhost:3636 in a Web browser to access the Piranha Configuration Tool . Otherwise, type in the host name or real IP address for the server followed by :3636 . Once the browser connects, you will see the screen shown in Figure 4.1, "The Welcome Panel" . Figure 4.1. The Welcome Panel Click on the Login button and enter piranha for the Username and the administrative password you created in the Password field. The Piranha Configuration Tool is made of four main screens or panels . In addition, the Virtual Servers panel contains four subsections . The CONTROL/MONITORING panel is the first panel after the login screen.

Commands:
Chapter 3. Deploying Kafka components using the AMQ Streams operator When installed on Openshift, the AMQ Streams operator makes Kafka components available for installation from the user interface. The following Kafka components are available for installation: Kafka Kafka Connect Kafka MirrorMaker Kafka MirrorMaker 2 Kafka Topic Kafka User Kafka Bridge Kafka Connector Kafka Rebalance You select the component and create an instance. As a minimum, you create a Kafka instance. This procedure describes how to create a Kafka instance using the default settings. You can configure the default installation specification before you perform the installation. The process is the same for creating instances of other Kafka components. Prerequisites The AMQ Streams operator is installed on the OpenShift cluster . Procedure Navigate in the web console to the Operators > Installed Operators page and click Red Hat Integration - AMQ Streams to display the operator details. From Provided APIs , you can create instances of Kafka components. Click Create instance under Kafka to create a Kafka instance. By default, you'll create a Kafka cluster called my-cluster with three Kafka broker nodes and three ZooKeeper nodes. The cluster uses ephemeral storage. Click Create to start the installation of Kafka. Wait until the status changes to Ready .

Commands:
Chapter 25. Events 25.1. Event Elements The rel="events" link obtained from the entry point URI accesses the events collection and lists system events from Red Hat Virtualization Manager. Table 25.1. Event elements Element Type Description description string A description of the system event code integer The integer event code. severity One of normal , warning , error or alert The level of severity for the event. time xsd:dateTime format: YYYY-MM-DDThh:mm:ss The timestamp indicating when the event happened. correlation_id string The identification string for an action that is spread across layers of Red Hat Virtualization. user id= GUID The identification code for the user who triggered the event. origin string The source of the event. Standard events are reported by oVirt . custom_id integer A custom identification number for custom events. Standard events have a custom_id of -1 . flood_rate integer The time, in seconds, during which the same event cannot reoccur in the event list. The default value is 30 . external_status complex The external health status of a host. Contains the state element, which can be one of ok , info , error , warning , or failure .

Commands:
4.315. system-switch-java 4.315.1. RHBA-2011:1744 - system-switch-java bug fix update An updated system-switch-java package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The system-switch-java package provides a tool that allows you to select the Java environment from the list of the installed Java alternatives. The tool supports graphical user interface (GUI) and text user interface (TUI) mode. Bug Fixes BZ# 725718 When switching to OpenJDK, the system-switch-java utility failed to switch the web plug-in to the IcedTea plug-in. This happened because system-switch-java was looking for the plug-in in a wrong location. With this update, system-switch-java searches for the web plug-in in the correct location (/usr/lib/IcedTeaPlugin.so) and the plug-in is applied when requested. BZ# 745457 On system-switch-java 1.1.5, the command "system-switch-java --version" printed the value "1.1.4". The underlying code has been updated and the command now returns the correct version number. All users of system-switch-java are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) using Red Hat OpenStack Platform clusters. Note Both internal and external OpenShift Data Foundation clusters are supported on Red Hat OpenStack Platform. See Planning your deployment for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the appropriate deployment process based on your requirement: Internal mode Deploying OpenShift Data Foundation on Red Hat OpenStack Platform in internal mode Deploy standalone Multicloud Object Gateway component External mode Deploying OpenShift Data Foundation on Red Hat OpenStack Platform in external mode

Commands:
function::remote_id Name function::remote_id - The index of this instance in a remote execution. Synopsis Arguments None Description This function returns a number 0..N, which is the unique index of this particular script execution from a swarm of " stap --remote A --remote B ... " runs, and is the same number " stap --remote-prefix " would print. The function returns -1 if the script was not launched with " stap --remote " , or if the remote staprun/stapsh are older than version 1.7.

Commands:
remote_id:long()