mtpti5iD/redhat-docs_dataset huggingface dataset:
9.4. Methods 9.4.1. Creating a New Data Center Creation of a new data center requires the name and local elements. Example 9.3. Creating a data center 9.4.2. Updating a Data Center The name , description , storage_type , version , storage_format and mac_pool elements are updatable post-creation. Example 9.4. Updating a data center 9.4.3. Removing a Data Center Removal of a data center requires a DELETE request. Example 9.5. Removing a data center

Commands:
POST /ovirt-engine/api/datacenters HTTP/1.1 Accept: application/xml Content-type: application/xml <data_center> <name>NewDatacenter</name> <local>false</local> </data_center>
PUT /ovirt-engine/api/datacenters/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <data_center> <name>UpdatedName</name> <description>An updated description for the data center</description> </data_center>
DELETE /ovirt-engine/api/datacenters/00000000-0000-0000-0000-000000000000 HTTP/1.1 HTTP/1.1 204 No Content
Chapter 5. What to do ? As a storage administrator, once you have installed and configured Red Hat Ceph Storage 5, you are ready to perform "Day Two" operations for your storage cluster. These operations include adding metadata servers (MDS) and object gateways (RGW), and configuring services such as iSCSI and NFS. For more information about how to use the cephadm orchestrator to perform "Day Two" operations, refer to the Red Hat Ceph Storage 5 Operations Guide . To deploy, configure, and administer the Ceph Object Gateway on "Day Two" operations, refer to the Red Hat Ceph Storage 5 Object Gateway Guide .

Commands:
1.3. Components that Support the Manager Red Hat JBoss Enterprise Application Platform Red Hat JBoss Enterprise Application Platform is a Java application server. It provides a framework to support efficient development and delivery of cross-platform Java applications. The Red Hat Virtualization Manager is delivered using Red Hat JBoss Enterprise Application Platform. Important The version of the Red Hat JBoss Enterprise Application Platform bundled with Red Hat Virtualization Manager is not to be used to serve other applications. It has been customized for the specific purpose of serving the Red Hat Virtualization Manager. Using the Red Hat JBoss Enterprise Application Platform that is included with the Manager for additional purposes adversely affects its ability to service the Red Hat Virtualization environment. Gathering Reports and Historical Data The Red Hat Virtualization Manager includes a data warehouse that collects monitoring data about hosts, virtual machines, and storage. A number of pre-defined reports are available. Customers can analyze their environments and create reports using any query tools that support SQL. The Red Hat Virtualization Manager installation process creates two databases. These databases are created on a Postgres instance which is selected during installation. The engine database is the primary data store used by the Red Hat Virtualization Manager. Information about the virtualization environment like its state, configuration, and performance are stored in this database. The ovirt_engine_history database contains configuration information and statistical metrics which are collated over time from the engine operational database. The configuration data in the engine database is examined every minute, and changes are replicated to the ovirt_engine_history database. Tracking the changes to the database provides information on the objects in the database. This enables you to analyze and enhance the performance of your Red Hat Virtualization environment and resolve difficulties. For more information on generating reports based on the ovirt_engine_history database see the History Database in the Red Hat Virtualization Data Warehouse Guide . Important The replication of data to the ovirt_engine_history database is performed by the RHEVM History Service , ovirt-engine-dwhd. Directory services Directory services provide centralized network-based storage of user and organizational information. Types of information stored include application settings, user profiles, group data, policies, and access control. The Red Hat Virtualization Manager supports Active Directory, Identity Management (IdM), OpenLDAP, and Red Hat Directory Server 9. There is also a local, internal domain for administration purposes only. This internal domain has only one user: the admin user.

Commands:
14.14. Managing Virtual Networks This section covers managing virtual networks with the virsh command. To list virtual networks: This command generates output similar to: To view network information for a specific virtual network: This displays information about a specified virtual network in XML format: Other virsh commands used in managing virtual networks are: virsh net-autostart network-name - Autostart a network specified as network-name . virsh net-create XMLfile - generates and starts a new network using an existing XML file. virsh net-define XMLfile - generates a new network device from an existing XML file without starting it. virsh net-destroy network-name - destroy a network specified as network-name . virsh net-name networkUUID - convert a specified networkUUID to a network name. virsh net-uuid network-name - convert a specified network-name to a network UUID. virsh net-start nameOfInactiveNetwork - starts an inactive network. virsh net-undefine nameOfInactiveNetwork - removes the definition of an inactive network.

Commands:
virsh net-list
virsh net-list Name State Autostart ----------------------------------------- default active yes vnet1 active yes vnet2 active yes
virsh net-dumpxml NetworkName
virsh net-dumpxml vnet1 <network> <name>vnet1</name> <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid> <forward dev='eth0'/> <bridge name='vnet0' stp='on' forwardDelay='0' /> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.128' end='192.168.100.254' /> </dhcp> </ip> </network>
25.10. Accessing The Server To access your secure server, use a URL similar to the following: Your non-secure server can be accessed using an URL similar to the following: The standard port for secure Web communications is port 443. The standard port for non-secure Web communications is port 80. The secure server default configuration listens on both of the two standard ports. Therefore, do not need to specify the port number in a URL (the port number is assumed). However, if you configure your server to listen on a non-standard port (for example, anything other than 80 or 443), you must specify the port number in every URL which is intended to connect to the server on the non-standard port. For example, you may have configured your server so that you have a virtual host running non-secured on port 12331. Any URLs intended to connect to that virtual host must specify the port number in the URL. The following URL example attempts to connect to a non-secure server listening on port 12331:

Commands:
https:// server.example.com
http:// server.example.com
http:// server.example.com :12331
Chapter 6. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2025:0429 RHSA-2025:0430 RHEA-2025:0432 For information about downloading Windows or Portable Linux distributions of Red Hat build of OpenJDK 11.0.26, see https://access.redhat.com/downloads/content/975/ . Revised on 2025-01-29 17:30:33 UTC

Commands:
Chapter 1. Secure, protect, and connect APIs on OpenShift with Connectivity Link This guide walks you through using Connectivity Link on OpenShift to secure, protect, and connect an API exposed by a Gateway that is based on Kubernetes Gateway API. You can use this walkthrough for a Gateway deployed on a single OpenShift cluster or a Gateway distributed across multiple OpenShift clusters with a shared HTTPS listener hostname. This guide shows how the platform engineer and application developer user roles can each use Connectivity Link to achieve their goals. 1.1. What Connectivity Link can do in multicluster environments You can leverage Connectivity Link's capabilities in single or multiple OpenShift clusters. The following features are designed to work across multiple clusters as well as in a single-cluster environment: Multicluster ingress: Connectivity Link provides multicluster ingress connectivity using DNS to bring traffic to your Gateways by using a strategy defined in a DNSPolicy . Global rate limiting: Connectivity Link can enable global rate limiting use cases when configured to use a shared Redis or Dragonfly store for counters based on limits defined by a RateLimitPolicy . Global auth: You can configure a Connectivity Link AuthPolicy to leverage external auth providers to ensure that different clusters exposing the same API authenticate and authorize in the same way. Automatic TLS certificate generation: You can configure a TLSPolicy to automatically provision TLS certificates based on Gateway listener hosts by using integration with cert-manager and ACME providers such as Let's Encrypt. Integration with federated metrics stores: Connectivity Link has example dashboards and metrics for visualizing your Gateways and observing traffic hitting those Gateways across multiple clusters. 1.2. User role workflows Platform engineer : This guide walks through deploying a Gateway that provides secure communication and is protected and ready for use by application development teams to deploy an API. It then walks through using this Gateway in clusters in different geographic regions, leveraging Connectivity Link to bring specific traffic to your geo-located Gateways. This approach reduces latency and distributes load, while still protecting and securing with global rate limiting and auth. Application developer : This guide walks through deploying your application API and shows how to override your Gateway-level global auth and rate limiting policies to configure your application-level auth and rate limiting requirements. Note For details on how both user roles can observe and monitor Gateways when the OpenShift observability stack and user workload monitoring are deployed, see Connectivity Link Observability Guide . 1.3. Deployment management tooling While this guide uses kubectl commands for simplicity, working with multiple clusters is complex. It is best to use a tool such as Argo CD to manage the deployment of resources to multiple clusters.

Commands:
5.3.6. /proc/irq/ This directory is used to set IRQ to CPU affinity, which allows the system to connect a particular IRQ to only one CPU. Alternatively, it can exclude a CPU from handling any IRQs. Each IRQ has its own directory, allowing for the individual configuration of each IRQ. The /proc/irq/prof_cpu_mask file is a bitmask that contains the default values for the smp_affinity file in the IRQ directory. The values in smp_affinity specify which CPUs handle that particular IRQ. For more information about the /proc/irq/ directory, refer to the following installed documentation:

Commands:
/usr/share/doc/kernel-doc- <version> /Documentation/filesystems/proc.txt
Getting Started with Red Hat Trusted Application Pipeline Red Hat Trusted Application Pipeline 1.4 Learn how to get started with Red Hat Trusted Application Pipeline. Red Hat Trusted Application Pipeline Documentation Team

Commands:
delete application your-app-name-app-of-apps -n rhtap 1
cosign download sbom <the-sbom-url-you-copied>
cosign download sbom <the-sbom-url-you-copied> > sbom.txt
{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:89146fc4-342f-496b-9cc9-07a6a1554220", "version": 1, "metadata": { }, "components": [ { "bom-ref": "pkg:pypi/flask@2.1.0?package-id=d6ad7ed5aac04a8", "type": "library", "author": "Armin Ronacher <armin.ronacher@active-4.com>", "name": "Flask", "version": "2.1.0", "licenses": [ { "license": { "id": "BSD-3-Clause" } } ], "cpe": "cpe:2.3:a:armin-ronacher:python-Flask:2.1.0:*:*:*:*:*:*:*", "purl": "pkg:pypi/Flask@2.1.0", "properties": [ { "name": "syft:package:foundBy", "value": "python-package-cataloger"
12.4. Editing a Virtual Machine Pool After a virtual machine pool has been created, its properties can be edited. The properties available when editing a virtual machine pool are identical to those available when creating a new virtual machine pool except that the Number of VMs property is replaced by Increase number of VMs in pool by . Note When editing a virtual machine pool, the changes introduced affect only new virtual machines. Virtual machines that existed already at the time of the introduced changes remain unaffected. Editing a Virtual Machine Pool Click Compute Pools and select a virtual machine pool. Click Edit . Edit the properties of the virtual machine pool. Click Ok .

Commands:
Chapter 1. Operators overview Operators are among the most important components of OpenShift Container Platform. Operators are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and oc commands. They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. While both follow similar Operator concepts and goals, Operators in OpenShift Container Platform are managed by two different systems, depending on their purpose: Cluster Operators, which are managed by the Cluster Version Operator (CVO), are installed by default to perform cluster functions. Optional add-on Operators, which are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications. With Operators, you can create applications to monitor the running services in the cluster. Operators are designed specifically for your applications. Operators implement and automate the common Day 1 operations such as installation and configuration as well as Day 2 operations such as autoscaling up and down and creating backups. All these activities are in a piece of software running inside your cluster. 1.1. For developers As a developer, you can perform the following Operator tasks: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , and Helm-based Operators . Use Operator SDK to build,test, and deploy an Operator . Install and subscribe an Operator to your namespace . Create an application from an installed Operator through the web console . 1.2. For administrators As a cluster administrator, you can perform the following Operator tasks: Manage custom catalogs Allow non-cluster administrators to install Operators Install an Operator from OperatorHub View Operator status . Manage Operator conditions Upgrade installed Operators Delete installed Operators Configure proxy support Use Operator Lifecycle Manager on restricted networks To know all about the cluster Operators that Red Hat provides, see Cluster Operators reference . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
Chapter 7. Known issues This section lists the known issues for Streams for Apache Kafka 2.7 on RHEL. 7.1. Incompatibility with RHEL 7 There are known incompatibility issues when using RHEL 7 with Kafka 3.7. As a result, RHEL 7 is no longer supported. The issues arise due to an outdated GCC (GNU Compiler Collection) version on RHEL 7, which is incompatible with the version of the RocksDB JNI library ( org.rocksdb:rocksdbjni:7.9.2 ) required by Kafka 3.7. RocksDB JNI version 7.9.2 requires a newer version of the GCC and the associated libstdc++ library than what is available on RHEL 7. Snappy compression and Kafka Streams, which depend on RocksDB, will not function correctly on RHEL 7 due to these outdated libraries. Recommendation Upgrade your clients and brokers running on RHEL 7 to RHEL 8 to ensure compatibility with Kafka 3.7 and the latest Streams for Apache Kafka features. If you wish to continue using RHEL 7, consider using Streams for Apache Kafka 2.5 LTS or 2.6. 7.2. JMX authentication when running in FIPS mode When running Streams for Apache Kafka in FIPS mode with JMX authentication enabled, clients may fail authentication. To work around this issue, do not enable JMX authentication while running in FIPS mode. We are investigating the issue and working to resolve it in a future release.

Commands:
2.4. Enabling Dynamic DNS Updates AD allows its clients to refresh their DNS records automatically. AD also actively maintains DNS records to make sure they are updated, including timing out (aging) and removing (scavenging) inactive records. DNS scavenging is not enabled by default on the AD side. SSSD allows the Linux system to imitate a Windows client by refreshing its DNS record, which also prevents its record from being marked inactive and removed from the DNS record. When dynamic DNS updates are enabled, the client's DNS record is refreshed: when the identity provider comes online (always) when the Linux system reboots (always) at a specified interval (optional configuration); by default, the AD provider updates the DNS record every 24 hours You can set this behavior to the same interval as the DHCP lease. In this case, the Linux client is renewed after the lease is renewed. DNS updates are sent to the AD server using Kerberos/GSSAPI for DNS (GSS-TSIG). This means that only secure connections need to be enabled. The dynamic DNS configuration is set for each domain. For example: For details on these options, see the sssd-ad (5) man page.

Commands:
[domain/ad.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = ad dyndns_update = true dyndns_refresh_interval = 43200 dyndns_update_ptr = true dyndns_ttl = 3600
5.229. pango 5.229.1. RHBA-2012:1498 - pango bug fix update Updated pango packages that fix one bug are now available for Red Hat Enterprise Linux 6. Pango is a library for laying out and rendering of text, with an emphasis on internationalization. Pango forms the core of text and font handling for GTK+ widget toolkit. Bug Fix BZ# 878772 Due to a regression in the pangoft2 module, an incorrect calculation caused that the approximate width of a character was reported as zero. Consequently, some applications using the Pango library failed with an assertion. With this update, the approximate character width is always set correctly and the failures no longer occur. User of pango should upgrade to these updated packages, which fix this bug.

Commands:
5.4. acroread 5.4.1. RHSA-2013:0150 - Critical: acroread security update Updated acroread packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Adobe Reader allows users to view and print documents in Portable Document Format (PDF). Security Fix CVE-2012-1530 , CVE-2013-0601 , CVE-2013-0602 , CVE-2013-0603 , CVE-2013-0604 , CVE-2013-0605 , CVE-2013-0606 , CVE-2013-0607 , CVE-2013-0608 , CVE-2013-0609 , CVE-2013-0610 , CVE-2013-0611 , CVE-2013-0612 , CVE-2013-0613 , CVE-2013-0614 , CVE-2013-0615 , CVE-2013-0616 , CVE-2013-0617 , CVE-2013-0618 , CVE-2013-0619 , CVE-2013-0620 , CVE-2013-0621 , CVE-2013-0623 , CVE-2013-0626 This update fixes several security flaws in Adobe Reader. These flaws are detailed in the Adobe Security bulletin APSB13-02 . A specially-crafted PDF file could cause Adobe Reader to crash or, potentially, execute arbitrary code as the user running Adobe Reader when opened. All Adobe Reader users should install these updated packages. They contain Adobe Reader version 9.5.3, which is not vulnerable to these issues. All running instances of Adobe Reader must be restarted for the update to take effect.

Commands:
Chapter 1. Console APIs 1.1. ConsoleCLIDownload [console.openshift.io/v1] Description ConsoleCLIDownload is an extension for configuring openshift web console command line interface (CLI) downloads. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.2. ConsoleExternalLogLink [console.openshift.io/v1] Description ConsoleExternalLogLink is an extension for customizing OpenShift web console log links. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.3. ConsoleLink [console.openshift.io/v1] Description ConsoleLink is an extension for customizing OpenShift web console links. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.4. ConsoleNotification [console.openshift.io/v1] Description ConsoleNotification is the extension for configuring openshift web console notifications. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.5. ConsolePlugin [console.openshift.io/v1] Description ConsolePlugin is an extension for customizing OpenShift web console by dynamically loading code from another service running on the cluster. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.6. ConsoleQuickStart [console.openshift.io/v1] Description ConsoleQuickStart is an extension for guiding user through various workflows in the OpenShift web console. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.7. ConsoleSample [console.openshift.io/v1] Description ConsoleSample is an extension to customizing OpenShift web console by adding samples. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.8. ConsoleYAMLSample [console.openshift.io/v1] Description ConsoleYAMLSample is an extension for customizing OpenShift web console YAML samples. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object

Commands:
8.230. virt-who 8.230.1. RHEA-2013:1715 - virt-who enhancement update Updated virt-who packages that add various enhancements are now available for Red Hat Enterprise Linux 6. The virt-who packages provide an agent that collects information about virtual guests present in the system and reports them to the Red Hat Subscription Manager tool. Enhancements BZ# 923757 With this update, support for the VMware ESXi hosts has been added to the virt-who package BZ# 1001416 This update adds support for sending information from the virt-who agent to Red Hat Satellite 5. BZ# 1002058 With this update, the virt-who package has been modified to support listing of VMware ESX virtual guest with more than 100 results. Users of virt-who are advised to upgrade to these updated packages, which add these enhancements.

Commands: