mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Supported standards and protocols Skupper supports the following protocols for your service network: TCP - default HTTP1 HTTP2 When exposing or creating a service, you can specify the protocol, for example: USD skupper expose deployment hello-world-backend --port 8080 --protocol <protocol> where <protocol> can be: tcp http http2 When choosing which protocol to specify, note the following: tcp supports any protocol overlayed on TCP, for example, HTTP1 and HTTP2 work when you specify tcp . If you specify http or http2 , the IP address reported by a client may not be accessible. All service network traffic is converted to AMQP messages in order to traverse the service network. TCP is implemented as a single streamed message, whereas HTTP1 and HTTP2 are implemented as request/response message routing.

Commands:
skupper expose deployment hello-world-backend --port 8080 --protocol <protocol>
14.2. Installing from a Different Source You can install Red Hat Enterprise Linux from the ISO images stored on hard disk, or from a network using NFS, FTP, HTTP, or HTTPS methods. Experienced users frequently use one of these methods because it is often faster to read data from a hard disk or network server than from a DVD. The following table summarizes the different boot methods and recommended installation methods to use with each: Table 14.1. Boot methods and installation sources Boot method Installation source Installation DVD DVD, network, or hard disk Installation USB flash drive Installation DVD, network, or hard disk Minimal boot CD or USB, rescue CD Network or hard disk Refer to Section 3.7, "Selecting an Installation Method" for information about installing from locations other than the media with which you booted the system.

Commands:
Chapter 1. Introduction SystemTap is a tracing and probing tool that allows users to study and monitor the activities of the operating system (particularly, the kernel) in fine detail. It provides information similar to the output of tools like netstat , ps , top , and iostat ; however, SystemTap is designed to provide more filtering and analysis options for collected information. SystemTap can be used by system administrators as a performance monitoring tool for Red Hat Enterprise Linux 5 or later. It is most useful when other similar tools cannot precisely pinpoint a bottleneck in the system, thus requiring a deep analysis of system activity. In the same manner, application developers can also use SystemTap to monitor, in fine detail, how their application behaves within the Linux system. 1.1. Documentation Goals SystemTap provides the infrastructure to monitor the running Linux system for detailed analysis. This can assist administrators and developers in identifying the underlying cause of a bug or performance problem. Without SystemTap, monitoring the activity of a running kernel would require a tedious instrument, recompile, install, and reboot sequence. SystemTap is designed to eliminate this, allowing users to gather the same information by simply running user-written SystemTap scripts. However, SystemTap was initially designed for users with intermediate to advanced knowledge of the Linux kernel. This makes SystemTap less useful to administrators or developers with limited knowledge of and experience with the kernel. Moreover, much of the existing SystemTap documentation is similarly aimed at knowledgeable and experienced users. To lower these barriers the SystemTap Beginners Guide was written with the following goals: To introduce users to SystemTap, familiarize them with its architecture, and provide setup instructions for all kernel types. To provide pre-written SystemTap scripts for monitoring detailed activity in different components of the system, along with instructions on how to run them and analyze their output.

Commands:
8.237. xorg-x11-drv-ati 8.237.1. RHBA-2013:1597 - xorg-x11-drv-ati bug fix and enhancement update Updated xorg-x11-drv-ati packages that fix one bug and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-ati packages provide a driver for ATI graphics cards for the X.Org implementation of the X Window System. Bug Fix BZ# 907616 Previously, the hot plug detection and mode setting were not performed automatically. As a consequence, the user had to run the utility program to enforce the changes when plugging in multiple monitors. The driver has been updated, and the hotplug detection and mode setting now work as expected. Enhancements BZ# 795919 Support for new graphics processing unit (GPU) hardware has been added. BZ# 822280 , BZ# 879102 , BZ# 882086 Support for hardware acceleration, including OpenGL, of the Radeon HD 7000 Series has been added. Users of xorg-x11-drv-ati are advised to upgrade to these updated packages, which fix this bug and add these enhancements.

Commands:
Preface Businesses increasingly need to access data residing in multiple disparate data sources. Therefore, you need to consider ways of making this information readily available for them to use. Red Hat JBoss Data Virtualization is a data integration solution used to integrate data from sources such as relational databases, text files, web services, and ERP/CRM mainframe systems, as well as "big data" datasources such as Apache Hadoop (Hive) and MongoDB. Red Hat JBoss Data Virtualization provides a unified virtualized view of information combined from multiple disparate sources. It hides details from the end user about the physical data sources, such as location, structure, API, access language and storage technology. This allows for more effort to be spent on data analysis and manipulation rather than on technical issues regarding the physical separation of the data. A virtual database (VDB) is used to map physical data sources to integrated views. At runtime, queries submitted against these views are coordinated among the dependent physical data sources, according to query criteria and the mappings defined by the VDB.

Commands:
Preface Red Hat Quay is an enterprise-quality registry for building, securing and serving container images. The documents in this section detail how to deploy Red Hat Quay for proof of concept , or non-production, purposes. The primary objectives of this document includes the following: How to deploy Red Hat Quay for basic non-production purposes. Asses Red Hat Quay's container image management, including how to push, pull, tag, and organize images. Explore availability and scalability. How to deploy an advanced Red Hat Quay proof of concept deployment using SSL/TLS certificates. Beyond the primary objectives of this document, a proof of concept deployment can be used to test various features offered by Red Hat Quay, such as establishing superusers, setting repository quota limitations, enabling Splunk for action log storage, enabling Clair for vulnerability reporting, and more. See the " steps" section for a list of some of the features available after you have followed this guide. This proof of concept deployment procedure can be followed on a single machine, either physical or virtual.

Commands:
Preface A service account grants a system service access to specific resources. While users can create service accounts, only an Organization Administrator or a user with the User Access Admin role can assign service accounts to user groups. The service account will have the permissions that are granted to the user group. Making open source more inclusive Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message .

Commands:
Chapter 5. Testing the configured back ends After you deploy the back ends to the overcloud, test that you can successfully create volumes on them. Procedure Run the following command as the stack user to load the environment variables defined in home/stack/overcloudrec : Note For more information, see Accessing the overcloud in the Installing and managing Red Hat OpenStack Platform with director guide. Create a volume type for each back end. Log in to the Controller node of the overcloud as the stack user and run the following command: These commands create the volume types backend1 and backend2 , one for each back end that is defined with the cinder::config::cinder_config class of the environment file that you created. Map each volume type to the volume_backend_name of a back end that is enabled with the cinder_user_enabled_backends class of the environment file that you created The following commands map the volume type backend1 to netapp1 and backend2 to netapp2 : Run the following command to test that it is possible to create a back end on netapp1 by invoking the backend1 volume type: Create a similar volume on the netapp2 back end by invoking the backend2 volume type:

Commands:
source /home/stack/overcloudrc
cinder type-create backend1 cinder type-create backend2
cinder type-key backend1 set volume_backend_name=netapp1 cinder type-key backend2 set volume_backend_name=netapp2
cinder create --volume-type backend1 --display_name netappvolume_1 1
cinder create --volume-type backend2 --display_name netappvolume_2 1
A.3. IdM Server Problems A.3.1. There are SASL, GSS-API, and Kerberos errors in the 389 Directory Server logs when the replica starts. When the replica starts, there can be a series of SASL bind errors recorded in the 389 Directory Server logs stating that the GSS-API connection failed because it could not find a credentials cache: The replica is looking for a credentials cache in /tmp/krb5cc_496 (where 496 is the 389 Directory Server user ID) and cannot find it. There may also be messages that the server could not obtain Kerberos credentials for the host principal: These errors are both related to how and when the 389 Directory Server instance loads its Kerberos credentials cache. While 389 Directory Server itself supports multiple different authentication mechanisms, Identity Management only uses GSS-API for Kerberos connections. The 389 Directory Server instance for Identity Management keeps its Kerberos credentials cache in memory. When the 389 Directory Server process ends - like when the IdM replica is stopped - the credentials cache is destroyed. Also, the 389 Directory Server is used as the backend storage for the principal information for the KDC. When the replica then restarts, the 389 Directory Server instance starts first, since it supplies information for the KDC, and then the KDC server starts. This start order is what causes the GSS-API and Kerberos connection errors. The 389 Directory Server attempts to open a GSS-API connection, but since there is no credentials cache yet and the KDC is not started, the GSS connection fails. Likewise, any attempt to obtain the host credentials also fails. These errors are transient. The 389 Directory Server re-attempts the GSS-API connection after the KDC starts and it has a credentials cache. The 389 Directory Server logs then record a bind resumed message. These startup GSS-API connection failures can be ignored as long as that connection is successfully established.

Commands:
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found))
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
Appendix A. MSI-based installer properties The Red Hat build of OpenJDK for Windows MSI-based installer includes the JDK Files component and the following optional properties: Table A.1. Red Hat build of OpenJDK for Windows MSI-based installer properties Property Description Default value OpenJDK Runtime - Windows Registry Sets registry keys that other software can use to locate JDK installation files. Yes OpenJDK Runtime - Path Variable Adds the Runtime to the Path variable so it is available from the command line. Yes OpenJDK Runtime - JAVA_HOME System Variable JAVA_HOME is used by some programs to find the Java runtime. No OpenJDK Runtime - REDHAT_JAVA_HOME System Variable REDHAT_JAVA_HOME can be used by some programs to find the Red Hat build of OpenJDK runtime. No OpenJDK Runtime - Jar Files Association This enables Jar files to be run from within Windows Explorer. No Mission Control - Files Contains files that are installed in the <installdir> \missioncontrol directory. No Mission Control - Path Variable Appends <installdir> \missioncontrol to the system PATH environment variable. No Revised on 2024-05-09 14:55:33 UTC

Commands:
8.148. perl-Socket6 8.148.1. RHBA-2013:0777 - perl-Socket6 bug fix update Updated perl-Socket6 packages that fix one bug are now available for Red Hat Enterprise Linux 6. This module supports the getaddrinfo() and getnameinfo() functions to intend to enable protocol independent programing. If the user's environment supports IPv6, IPv6 related defines such as AF_INET6 are included. Bug Fix BZ#953873 When invoking a manual page for Socket6, no manual page was found. The build script has been fixed to convert POD (Plain Old Documentation) to manual pages. As a result, the "man Socket6" command correctly shows the Socket6(3) manual page for the Socket6 Perl module as expected. Users of perl-Socket6 are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 26. Fibre Channel This section discusses the Fibre Channel API, native Red Hat Enterprise Linux 6 Fibre Channel drivers, and the Fibre Channel capabilities of these drivers. 26.1. Fibre Channel API Following is a list of /sys/class/ directories that contain files used to provide the userspace API. In each item, host numbers are designated by H , bus numbers are B , targets are T , logical unit numbers (LUNs) are L , and remote port numbers are R . Important If your system is using multipath software, Red Hat recommends that you consult your hardware vendor before changing any of the values described in this section. Transport: /sys/class/fc_transport/target H : B : T / port_id - 24-bit port ID/address node_name - 64-bit node name port_name - 64-bit port name Remote Port: /sys/class/fc_remote_ports/rport- H : B - R / port_id node_name port_name dev_loss_tmo : controls when the scsi device gets removed from the system. After dev_loss_tmo triggers, the scsi device is removed. In multipath.conf , you can set dev_loss_tmo to infinity , which sets its value to 2,147,483,647 seconds, or 68 years, and is the maximum dev_loss_tmo value. In Red Hat Enterprise Linux 6, fast_io_fail_tmo is not set by default, hence dev_loss_tmo value is capped to 600 seconds. fast_io_fail_tmo : specifies the number of seconds to wait before it marks a link as "bad". Once a link is marked bad, existing running I/O or any new I/O on its corresponding path fails. If I/O is in a blocked queue, it will not be failed until dev_loss_tmo expires and the queue is unblocked. If fast_io_fail_tmo is set to any value except off , dev_loss_tmo is uncapped. If fast_io_fail_tmo is set to off , no I/O fails until the device is removed from the system. If fast_io_fail_tmo is set to a number, I/O fails immediately when fast_io_fail_tmo triggers. Host: /sys/class/fc_host/host H / port_id issue_lip : instructs the driver to rediscover remote ports.

Commands:
Chapter 9. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 9.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 9.2. Expanding the node port range You can expand the node port range for the cluster. Important You can expand the node port range into the protected port range, which is between 0 and 32767. However, after expansion, you cannot change the range. Attempting to change the range returns the following error: The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the range 0-32767 . Before making changes, ensure that the new range you set is appropriate for your cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 9.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]
API overview OpenShift Container Platform 4.16 Overview content for the OpenShift Container Platform API Red Hat OpenShift Documentation Team

Commands:
oc debug node/<node>
chroot /host
systemctl cat kubelet
/etc/systemd/system/kubelet.service.d/20-logging.conf [Service] Environment="KUBELET_LOG_LEVEL=2"
echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-master-kubelet-loglevel spec: config: ignition: version: 3.2.0 systemd: units: - name: kubelet.service enabled: true dropins: - name: 30-logging.conf contents: | [Service] Environment="KUBELET_LOG_LEVEL=2"
oc adm node-logs --role master -u kubelet
oc adm node-logs --role worker -u kubelet
journalctl -b -f -u kubelet.service
sudo tail -f /var/log/containers/*
- for n in USD(oc get node --no-headers | awk '{print USD1}'); do oc adm node-logs USDn | gzip > USDn.log.gz; done
Preface Red Hat OpenStack Platform (Red Hat OpenStack Platform) provides the foundation to build a private or public Infrastructure-as-a-Service (IaaS) cloud on top of Red Hat Enterprise Linux. It offers a massively scalable, fault-tolerant platform for the development of cloud-enabled workloads. This guide discusses procedures for creating and managing images, and instances. It also mentions the procedure for configuring the storage for instances for Red Hat OpenStack Platform. You can manage the cloud using either the OpenStack dashboard or the command-line clients. Most procedures can be carried out using either method; some of the more advanced procedures can only be executed on the command line. This guide provides procedures for the dashboard where possible. Note For the complete suite of documentation for Red Hat OpenStack Platform, see Red Hat OpenStack Platform Documentation Suite .

Commands:
3.14. Example: Attach ISO Image to Virtual Machine The boot media for our example virtual machine requires an CD-ROM or DVD ISO image for an operating system installation. This example uses a Red Hat Enterprise Server 6 ISO image for installation. ISO images must be available in the iso1 ISO domain for the virtual machines to use. Red Hat Virtualization Platform provides an uploader tool that ensures that the ISO images are uploaded into the correct directory path with the correct user permissions. Once the ISO is uploaded, an API user requests the ISO storage domain's files sub-collection to view the file resource: Example 3.16. View the files sub-collection in an ISO storage domain Request: cURL command: The API returns the following representation of the files sub-collection: An API user attaches the rhel-server-6.0-x86_64-dvd.iso to our example virtual machine. Attaching an ISO image is equivalent to using the Change CD button in the Administration or User Portal. Example 3.17. Attach an ISO image to the virtual machine Request: cURL command:

Commands:
GET /ovirt-engine/api/storagedomains/00f0d9ce-da15-4b9e-9e3e-3c898fa8b6da/files HTTP/1.1 Accept: application/xml
curl -X GET -H "Accept: application/xml" -u [USER:PASS] --cacert [CERT] https:// [RHEVM Host] :443/ovirt-engine/api/storagedomains/00f0d9ce-da15-4b9e-9e3e-3c898fa8b6da/files
<files> <file id="rhel-server-6.0-x86_64-dvd.iso" href="/ovirt-engine/api/storagedomains/00f0d9ce-da15-4b9e-9e3e-3c898fa8b6da/ files/rhel-server-6.0-x86_64-dvd.iso.iso"> <name>rhel-server-6.0-x86_64-dvd.iso.iso</name> <storage_domain id="00f0d9ce-da15-4b9e-9e3e-3c898fa8b6da" href="/ovirt-engine/api/storagedomains/00f0d9ce-da15-4b9e-9e3e-3c898fa8b6da"/> </file> </files>
POST /ovirt-engine/api/vms/6efc0cfa-8495-4a96-93e5-ee490328cf48/cdroms HTTP/1.1 Accept: application/xml Content-type: application/xml <cdrom> <file id="rhel-server-6.0-x86_64-dvd.iso"/> </cdrom>
curl -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" -u [USER:PASS] --cacert [CERT] -d "<cdrom><file id='rhel-server-6.0-x86_64-dvd.iso'/></cdrom>" https:// [RHEVM Host] :443/ovirt-engine/api/vms/6efc0cfa-8495-4a96-93e5-ee490328cf48/cdroms
1.4. Storage Red Hat Virtualization uses a centralized storage system for virtual disks, templates, snapshots, and ISO files. Storage is logically grouped into storage pools, which are comprised of storage domains. A storage domain is a combination of storage capacity and metadata that describes the internal structure of the storage. See Storage Domain Types The data domain is the only one required by each data center. A data storage domain is exclusive to a single data center. Export and ISO domains are optional. Storage domains are shared resources, and must be accessible to all hosts in a data center.

Commands:
4.181. mksh 4.181.1. RHBA-2011:0923 - mksh bug fix update An updated mksh package that fixes one bug is now available for Red Hat Enterprise Linux 6. The mksh package provides the MirBSD version of the Korn Shell, which implements the ksh-88 programming language for both interactive and shell script use. Bug Fix BZ# 712355 Prior to this update, the mksh package did not specify all requirements for RPM scriptlets. As a result, the requirements were not installed during the post install setup and the scriptlets were not able to work correctly. With this update, the bug has been fixed, and the mksh package now specifies the requirements and installs them as expected. All users of mksh are advised to upgrade to this updated package, which fixes this bug.

Commands: