mtpti5iD/redhat-docs_dataset huggingface dataset:
6.10. Metadata Repositories Traditionally the metadata for a Virtual Database is built by Teiid Designer and supplied to Teiid engine through a VDB archive file. This VDB file contains .INDEX metadata files. By default they are loaded by a MetadataRepository with the name INDEX. Other built-in metadata repositories include the following: NATIVE This is only applicable on source models (and is also the default), when used the metadata for the model is retrieved from the source database itself. DDL This is applicable to both source and view models. See DDL Metadata for more information on how to use this feature. DDL-FILE DDL is applicable to both source and view models in zip VDB deployments. See DDL Metadata for more information on how to use this feature. Chaining Repositories When defining the metadata type for a model, multiple metadata elements can be used. All the repository instances defined are consulted in the order configured to gather the metadata for the given model. For the above model, NATIVE importer is first used, then DDL importer used to add additional metadata to NATIVE imported metadata.

Commands:
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE"></metadata> </model> </vdb>
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="DDL"> **DDL Here** </metadata> </model> </vdb>
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="DDL-FILE">/accounts.ddl</metadata> </model> </vdb>
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE"/> <metadata type="DDL"> **DDL Here** </metadata> </model> </vdb>
Part IV. Administration: Managing Identities This part details how to manage user accounts, hosts, as well as user groups and host groups. In addition, it details how to assign and view unique UID and GID numbers and how user and group schema works. The following chapter deals with managing services and delegating access to hosts and services. The final chapters provide instruction on how to define Access Control for Identity Management users, how to manage Kerberos flags and principal aliases, and how to integrate with NIS domains and Netgroups .

Commands:
Chapter 6. Guest Virtual Machine Installation Overview After you have installed the virtualization packages on the host system you can create guest operating systems. This chapter describes the general processes for installing guest operating systems on virtual machines. You can create guest virtual machines using the New button in virt-manager or use the command line interface virt-install . Both methods are covered by this chapter. Detailed installation instructions are available in the following chapters for specific versions of Red Hat Enterprise Linux and Microsoft Windows. 6.1. Guest Virtual Machine Prerequisites and Considerations Various factors should be considered before creating any guest virtual machines. Not only should the role of a virtual machine be considered before deployment, but regular ongoing monitoring and assessment based on variable factors (load, amount of clients) should be performed. Some factors include: Performance Guest virtual machines should be deployed and configured based on their intended tasks. Some guest systems (for instance, guests running a database server) may require special performance considerations. Guests may require more assigned CPUs or memory based on their role and projected system load. Input/Output requirements and types of Input/Output Some guest virtual machines may have a particularly high I/O requirement or may require further considerations or projections based on the type of I/O (for instance, typical disk block size access, or the amount of clients). Storage Some guest virtual machines may require higher priority access to storage or faster disk types, or may require exclusive access to areas of storage. The amount of storage used by guests should also be regularly monitored and taken into account when deploying and maintaining storage. Networking and network infrastructure Depending upon your environment, some guest virtual machines could require faster network links than other guests. Bandwidth or latency are often factors when deploying and maintaining guests, especially as requirements or load changes. Request requirements SCSI requests can only be issued to guest virtual machines on virtio drives if the virtio drives are backed by whole disks, and the disk device parameter is set to lun , as shown in the following example:

Commands:
<devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='block' device='lun'>
Appendix A. Revision History Revision History Revision 6.6.0-2 Wed 7 Sep 2016 Christian Huffman Updating for 6.6.1. Revision 6.6.0-1 Fri 29 Jan 2016 Christian Huffman BZ-1303142: Included information on Projection Queries in the Infinispan Query DSL. Revision 6.6.0-0 Mon 25 Jan 2016 Christian Huffman Initial draft for 6.6.0. Included Query Aggregation and Continuous Queries. Updated versions.

Commands:
3.3. Putting the Configuration Together After determining which of the preceding routing methods to use, the hardware should be linked together on the network. Important The adapter devices on the LVS routers must be configured to access the same networks. For instance if eth0 connects to public network and eth1 connects to the private network, then these same devices on the backup LVS router must connect to the same networks. Also the gateway listed in the first interface to come up at boot time is added to the routing table and subsequent gateways listed in other interfaces are ignored. This is especially important to consider when configuring the real servers. After physically connecting together the hardware, configure the network interfaces on the primary and backup LVS routers. This can be done using a graphical application such as system-config-network or by editing the network scripts manually. For more information about adding devices using system-config-network , see the chapter titled Network Configuration in the Red Hat Enterprise Linux Deployment Guide . For the remainder of the chapter, example alterations to network interfaces are made either manually or through the Piranha Configuration Tool . 3.3.1. General LVS Networking Tips Configure the real IP addresses for both the public and private networks on the LVS routers before attempting to configure LVS using the Piranha Configuration Tool . The sections on each topology give example network addresses, but the actual network addresses are needed. Below are some useful commands for bringing up network interfaces or checking their status. Bringing Up Real Network Interfaces To bring up a real network interface, use the following command as root, replacing N with the number corresponding to the interface ( eth0 and eth1 ). /sbin/ifup eth N Warning Do not use the ifup scripts to bring up any floating IP addresses you may configure using Piranha Configuration Tool ( eth0:1 or eth1:1 ). Use the service command to start pulse instead (see Section 4.8, "Starting LVS" for details). Bringing Down Real Network Interfaces To bring down a real network interface, use the following command as root, replacing N with the number corresponding to the interface ( eth0 and eth1 ). /sbin/ifdown eth N Checking the Status of Network Interfaces If you need to check which network interfaces are up at any given time, type the following: /sbin/ifconfig To view the routing table for a machine, issue the following command: /sbin/route

Commands:
probe::scheduler.ctxswitch Name probe::scheduler.ctxswitch - A context switch is occuring. Synopsis scheduler.ctxswitch Values prev_tid The TID of the process to be switched out name name of the probe point next_tid The TID of the process to be switched in prev_pid The PID of the process to be switched out prevtsk_state the state of the process to be switched out next_pid The PID of the process to be switched in nexttsk_state the state of the process to be switched in prev_priority The priority of the process to be switched out next_priority The priority of the process to be switched in prev_task_name The name of the process to be switched out next_task_name The name of the process to be switched in

Commands:
10.5.29. DirectoryIndex The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name. When a user requests the page http:// example / this_directory /, they get either the DirectoryIndex page, if it exists, or a server-generated directory list. The default for DirectoryIndex is index.html and the index.html.var type map. The server tries to find either of these files and returns the first one it finds. If it does not find one of these files and Options Indexes is set for that directory, the server generates and returns a listing, in HTML format, of the subdirectories and files within the directory, unless the directory listing feature is turned off.

Commands:
2.5. Network Configuration Figure 2.8. Network Configuration If the system to be installed via kickstart does not have an Ethernet card, do not configure one on the Network Configuration page. Networking is only required if you choose a networking-based installation method (NFS, FTP, or HTTP). Networking can always be configured after installation with the Network Administration Tool ( system-config-network ). Refer to Chapter 17, Network Configuration for details. For each Ethernet card on the system, click Add Network Device and select the network device and network type for the device. Select eth0 to configure the first Ethernet card, eth1 for the second Ethernet card, and so on.

Commands:
2.8.2. Video Card Probe for video card is selected by default. Accept this default to have the installation program probe for the video card during installation. Probing works for most modern video cards. If this option is selected and the installation program cannot successfully probe the video card, the installation program stops at the video card configuration screen. To continue the installation process, select your video card from the list and click . Alternatively, you can select the video card from the list on the Video Card tab as shown in Figure 2.12, "X Configuration - Video Card" . Specify the amount of video RAM the selected video card has from the Video Card RAM pulldown menu. These values are used by the installation program to configure the X Window System. Figure 2.12. X Configuration - Video Card

Commands:
1.4. Installing Supporting Components on Client Machines 1.4.1. Installing Console Components A console is a graphical window that allows you to view the start up screen, shut down screen, and desktop of a virtual machine, and to interact with that virtual machine in a similar way to a physical machine. In Red Hat Virtualization, the default application for opening a console to a virtual machine is Remote Viewer, which must be installed on the client machine prior to use. 1.4.1.1. Installing Remote Viewer on Red Hat Enterprise Linux The Remote Viewer application provides users with a graphical console for connecting to virtual machines. Once installed, it is called automatically when attempting to open a SPICE session with a virtual machine. Alternatively, it can also be used as a standalone application. Remote Viewer is included in the virt-viewer package provided by the base Red Hat Enterprise Linux Workstation and Red Hat Enterprise Linux Server repositories. Installing Remote Viewer on Linux Install the virt-viewer package: Restart your browser for the changes to take effect. You can now connect to your virtual machines using either the SPICE protocol or the VNC protocol. 1.4.1.2. Installing Remote Viewer on Windows The Remote Viewer application provides users with a graphical console for connecting to virtual machines. Once installed, it is called automatically when attempting to open a SPICE session with a virtual machine. Alternatively, it can also be used as a standalone application. Installing Remote Viewer on Windows Open a web browser and download one of the following installers according to the architecture of your system. Virt Viewer for 32-bit Windows: Virt Viewer for 64-bit Windows: Open the folder where the file was saved. Double-click the file. Click Run if prompted by a security warning. Click Yes if prompted by User Account Control. Remote Viewer is installed and can be accessed via Remote Viewer in the VirtViewer folder of All Programs in the start menu. 1.4.2. Installing usbdk on Windows usbdk is a driver that enables remote-viewer exclusive access to USB devices on Windows operating systems. Installing usbdk requires Administrator privileges. Note that the previously supported USB Clerk option has been deprecated and is no longer supported. Installing usbdk on Windows Open a web browser and download one of the following installers according to the architecture of your system. usbdk for 32-bit Windows: usbdk for 64-bit Windows: Open the folder where the file was saved. Double-click the file. Click Run if prompted by a security warning. Click Yes if prompted by User Account Control.

Commands:
yum install virt-viewer
https:// your-manager-fqdn /ovirt-engine/services/files/spice/virt-viewer-x86.msi
https:// your-manager-fqdn /ovirt-engine/services/files/spice/virt-viewer-x64.msi
https:// [your manager's address] /ovirt-engine/services/files/spice/usbdk-x86.msi
https:// [your manager's address] /ovirt-engine/services/files/spice/usbdk-x64.msi
Network APIs OpenShift Container Platform 4.18 Reference guide for network APIs Red Hat OpenShift Documentation Team

Commands:
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
{ Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }
a: [ 10.10.1.1:8675, 10.10.2.2:8675 ], b: [ 10.10.1.1:309, 10.10.2.2:309 ]
B.27.4. RHBA-2011:0321 - glibc bug fix update Updated glibc packages that fix a bug in the dynamic linker are now available for Red Hat Enterprise Linux 6. The glibc packages contain the standard C libraries used by multiple programs on the system. These packages contain the standard C and the standard math libraries. Without these two libraries, a Linux system cannot function properly. Bug Fix BZ# 661396 Due to an error in glibc libraries, a race condition could occur when traversing a list of currently loaded shared libraries, causing an application to terminate with an error. This error has been fixed, the race condition no longer occurs, and the list of shared libraries can now be traversed as expected. All users are advised to upgrade to these updated packages, which resolve this issue.

Commands:
Chapter 3. Features AMQ Streams 2.5 introduces the features described in this section. AMQ Streams 2.5 on RHEL is based on Apache Kafka 3.5.0. Note To view all the enhancements and bugs that are resolved in this release, see the AMQ Streams Jira project . 3.1. AMQ Streams 2.5.x (Long Term Support) AMQ Streams 2.5.x is the Long Term Support (LTS) offering for AMQ Streams. The latest patch release is AMQ Streams 2.5.2. The AMQ Streams binaries have changed to version 2.5.2. Although the supported Kafka version is listed as 3.5.0, it incorporates updates and improvements from Kafka 3.5.2. For information on the LTS terms and dates, see the AMQ Streams LTS Support Policy . 3.2. Kafka 3.5.x support AMQ Streams supports and uses Apache Kafka version 3.5.0. Updates for Kafka 3.5.2 are incorporated with the 2.5.2 patch release. Only Kafka distributions built by Red Hat are supported. For upgrade instructions, see AMQ Streams and Kafka upgrades . Refer to the Kafka 3.5.0 , Kafka 3.5.1 , and Kafka 3.5.2 Release Notes for additional information. Kafka 3.4.x is supported only for the purpose of upgrading to AMQ Streams 2.5. Kafka 3.5.x uses ZooKeeper version 3.6.4, which is a different version to Kafka 3.4.x. We recommend that you perform a rolling update to use the new binaries. Note Kafka 3.5.x provides access to KRaft mode, where Kafka runs without ZooKeeper by utilizing the Raft protocol. KRaft mode is available as a Technology Preview . 3.3. OpenTelemetry for distributed tracing OpenTelemetry for distributed tracing has moved to GA. You can use OpenTelemetry with a specified tracing system. OpenTelemetry has replaced OpenTracing for distributed tracing. Support for OpenTracing is deprecated . By Default, OpenTelemetry uses the OTLP (OpenTelemetry Protocol) exporter for tracing. AMQ Streams with OpenTelemetry is distributed for use with the Jaeger exporter, but you can specify other tracing systems supported by OpenTelemetry. AMQ Streams plans to migrate to using OpenTelemetry with the OTLP exporter by default, and is phasing out support for the Jaeger exporter. See Introducing distributed tracing .

Commands:
Chapter 7. Deprecated functionality This section provides an overview of functionality that has been deprecated in all minor releases up to this release of Red Hat Ceph Storage. Ceph configuration file is now deprecated The Ceph configuration file ( ceph.conf ) is now deprecated in favor of new centralized configuration stored in Ceph Monitors. For details, see the The Ceph configuration database section in the Red Hat Ceph Storage Configuration Guide . The min_compat_client parameter for Ceph File System (CephFS) is now deprecated The min_compat_client parameter is deprecated for Red Hat Ceph Storage 5.0 and new client features are added for setting-up the Ceph File Systems (CephFS). For details, see the Client features section in the Red Hat Ceph Storage File System Guide . The snapshot of Ceph File System subvolume group is now deprecated The snapshot feature of Ceph File System (CephFS) subvolume group is deprecated for Red Hat Ceph Storage 5.0. The existing snapshots can be listed and deleted, whenever needed. For details, see the Listing snapshots of a file system subvolume group and Removing snapshots of a file system subvolume group sections in the Red Hat Ceph Storage Ceph File System guide . The Cockpit Ceph Installer is now deprecated Installing a Red Hat Ceph Storage cluster 5 using Cockpit Ceph Installer is not supported. Use Cephadm to install a Red Hat Ceph Storage cluster. For details, see the Red Hat Ceph Storage Installation guide .

Commands:
Chapter 1. Overview of Red Hat Ansible Automation Platform Red Hat Ansible Automation Platform simplifies the development and operation of automation workloads for managing enterprise application infrastructure lifecycles. Ansible Automation Platform works across multiple IT domains including operations, networking, security, and development, as well as across diverse hybrid environments. Simple to adopt, use, and understand, Ansible Automation Platform provides the tools needed to rapidly implement enterprise-wide automation, no matter where you are in your automation journey. 1.1. What is included in Ansible Automation Platform Ansible Automation Platform Automation controller Automation hub Event-Driven Ansible controller Insights for Ansible Automation Platform 2.4 4.4 4.7 hosted service 1.0 hosted service 1.2. Red Hat Ansible Automation Platform life cycle Red Hat provides different levels of maintenance for each Ansible Automation Platform release. For more information, see Red Hat Ansible Automation Platform Life Cycle . 1.3. Upgrading Ansible Automation Platform When upgrading, do not use yum update . Use the installation program instead. The installation program performs all of the necessary actions required to upgrade to the latest versions of Ansible Automation Platform, including automation controller and private automation hub. Additional resources For information about the components included in Ansible Automation Platform, see the table in What is included in Ansible Automation Platform . For more information about upgrading Ansible Automation Platform, see Red Hat Ansible Automation Platform upgrade and migration guide . For procedures related to using the Ansible Automation Platform installer, see Ansible Automation Platform installation guide .

Commands: