mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Integration of dynamic JFR recordings with the agent harvester for archiving When you enable the Cryostat agent to start dynamic JFR recordings based on MBean custom triggers, you can also integrate these JFR recordings with the agent harvester system. This integration means that any JFR recording data resulting from MBean custom triggers is periodically captured in JFR snapshots and pushed to the Cryostat server for archiving, based on the harvester's configured schedule. MBean custom triggers with agent harvester periods The agent harvester is another configurable feature, which enables the Cryostat agent to start JFR recordings automatically at agent startup based on a given event template. The agent harvester includes a configurable property that you can use to define a schedule for capturing and uploading recording snapshots to the Cryostat server. By defining MBean custom triggers and an agent harvester period without a harvester template, you can achieve a setup where the agent does both of the following: Agent dynamically starts JFR recordings based on MBean custom triggers. Aent uses configured harvester periods to periodically capture snapshots of the recording data and upload this data to the Cryostat server. In this situation, the agent continues to capture recording data until you manually stop the dynamic JFR recording or the host JVM shuts down. Configuration of an agent harvester period When you configure your target application to load the Cryostat agent, you can also configure an agent harvester period to enable regular uploads of JFR recording data. You can specify the value of the harvester period in milliseconds. By default, the Cryostat agent is not enabled to perform any scheduled harvest uploading of JFR recording data. You can configure an agent harvester period in either of the following ways: Using a JVM system property flag The following example shows how to configure a harvester period by using a JVM system property flag: Using an environment variable The following example shows how to configure a harvester period by using an environment variable: The preceding examples show a harvester period value of 1000. Based on this example, the agent uploads JFR recording data for archiving every 1000 milliseconds (that is, at regular 1-second intervals). Note Cryostat supports each of the following different ways to start JFR recordings: You can start recordings manually from the Cryostat web console. The Cryostat agent can start recordings dynamically based on MBean custom triggers. The Cryostat agent can start recordings automatically at agent startup based on a given harvester template. The Cryostat server can send on-demand requests over JMX or an agent HTTP connection to start recordings based on automated rules. In this situation, agent harvester settings control the capture and upload of all JFR recording data regardless of which way JFR recordings are started in the system.

Commands:
-Dcryostat.agent.harvester.period-ms=1000
- name: CRYOSTAT_AGENT_HARVESTER_PERIOD_MS value: 1000
Chapter 1. Overview Red Hat Product Security is committed to providing tools and security data to help you better understand security threats. This data has been available on our Security Data page and is now also available in a machine-consumable format with the Security Data API. This service allows customers to programmatically query the API for data that was previously exposed only through files on our Security Data page. The data provided by the Security Data API is the same as what is found on the Security Data page: Common Security Advisory Framework ( CSAF ) documents, OVAL v2 ( OVAL streams ) and CVE data. Using the API the data can be fetched in JSON or XML format. This effort is a part of Red Hat Product Security's commitment to providing security data to customers in an easy-to-use format. Please Note: Only one version will be maintained and any changes will be noted in the documentation. The Security Data API is provided for information and metrics purposes. For any questions or concerns with the API or the data it provides, please contact Red Hat Product Security . Base URL Supported Formats The API supports JSON, XML, and HTML formats. The format can be specified as an extension to the url like .json or .xml. Compressed 'gzip' Responses By default, responses are returned in compressed 'gzip' format. Most browsers and download utilities will automatically unzip the response data. If uncompressed response data is required, the query parameter isCompressed=false may be added to the query URL. (See the individual sections for parameter descriptions and sample query URLs.) Deprecation Notices The Common Vulnerability Reporting Framework (CVRF) format is now deprecated and no longer supported. See the CVRF compatibility FAQ . Users of this format should migrate to the Common Security Advisory Framework ( CSAF ) format. OVAL v1 files are deprecated and no longer available. See the OVAL v1 deprecation announcement for more information. Users of this format should migrate to OVAL v2 ( OVAL streams ).

Commands:
https://access.redhat.com/hydra/rest/securitydata
7.122. man-pages-ja 7.122.1. RHBA-2015:0665 - man-pages-ja bug fix update An updated man-pages-ja package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The man-pages-ja package contains manual pages in Japanese. Bug Fixes BZ# 1157413 The date(1) man page did not mention options "%n" and "%N". which print a newline character and the number of nanoseconds respectively. This update adds these options and their descriptions to the man page. BZ# 1173391 The nfs(5) man page did not include the remark on the obsolescence of the "intr" and "nointr" options which is part of the English man page. With this update, the Japanese man page now includes this remark. BZ# 1174088 Previously, incorrect location of the output file for an internal state dump, /tmp/xinetd.dump, was specified in the xinetd(8) man page, in the section describing the action that xinetd performs when it receives the SIGUSR1 signal. The correct location is /var/run/xinetd.dump, and it is now written in the man page. BZ# 1140481 The description of the "EINVAL" error code in the shmop(2) man page was accidentally placed on the line describing the preceding error code, "EIDRM". This update moves the description of "EINVAL" into a separate paragraph. Users of man-pages-ja are advised to upgrade to this updated package, which fixes these bugs.

Commands:
8.3.5. Installing via FTP, HTTP, or HTTPS Important When you provide a URL to an installation source, you must explicitly specify http:// or https:// or ftp:// as the protocol. The URL dialog applies only if you are installing from a FTP, HTTP, or HTTPS server (if you selected URL in the Installation Method dialog). This dialog prompts you for information about the FTP, HTTP, or HTTPS server from which you are installing Red Hat Enterprise Linux. If you used the repo=ftp or repo=http boot options, you already specified a server and path. Enter the name or IP address of the FTP, HTTP, or HTTPS site from which you are installing, and the name of the directory that contains the /images directory for your architecture. For example: /mirrors/redhat/rhel-6.9/Server/i386/ To install via a secure HTTPS connection, specify https:// as the protocol. Specify the address of a proxy server, and if necessary, provide a port number, username, and password. If everything was specified properly, a message box appears indicating that files are being retrieved from the server. If your FTP, HTTP, or HTTPS server requires user authentication, specify user and password as part of the URL as follows: {ftp|http|https}://<user>:<password>@<hostname>[:<port>]/<directory>/ For example: http://install:rhel6.9pw@name.example.com/mirrors/redhat/rhel-6.9/Server/i386/ Figure 8.11. URL Setup Dialog Proceed with Chapter 9, Installing Using Anaconda .

Commands:
10.2.2. Legal Considerations Some important aspects of an incident response to consider include legal ramifications. Security plans should be developed with members of legal staff or some form of general counsel. Just as every company should have their own corporate security policy, every company should have its own way of handling incidents from a legal perspective. Local, state, and federal regulatory issues are beyond the scope of this document, but are mentioned because the methodology for performing a post-mortem analysis, at least in part, is dictated by (or in conjunction with) legal counsel. General counsel can alert technical staff of the legal ramifications of security breaches; the hazards of leaking a client's personal, medical, or financial records; and the importance of restoring service in mission-critical environments such as hospitals and banks.

Commands:
Chapter 6. Device drivers 6.1. New drivers Network drivers Realtek 802.11ac wireless 8822b driver (rtw88_8822b.ko.xz) Realtek 802.11ac wireless 8822be driver (rtw88_8822be.ko.xz) Realtek 802.11ac wireless 8822c driver (rtw88_8822c.ko.xz) Realtek 802.11ac wireless 8822ce driver (rtw88_8822ce.ko.xz) Realtek 802.11ac wireless core module (rtw88_core.ko.xz) Realtek 802.11ac wireless PCI driver (rtw88_pci.ko.xz) Interface driver for UDP encapsulated traffic (bareudp.ko.xz) Graphics drivers and miscellaneous drivers Regmap SoundWire Module (regmap-sdw.ko.xz) Intel(R) QuickAssist Technology (qat_4xxx.ko.xz) Intel(R) Data Accelerator Driver (idxd.ko.xz) Oracle VM VirtualBox Graphics Card (vboxvideo.ko.xz) HID driver for gaming keys on Logitech gaming keyboards (hid-lg-g15.ko.xz) Driver for AMD Energy reporting from RAPL MSR via HWMON interface (amd_energy.ko.xz) Elastic Fabric Adapter (EFA) (efa.ko.xz) AMD(R) PCI-E Non-Transparent Bridge Driver (ntb_hw_amd.ko.xz) PCIe NTB Performance Measurement Tool (ntb_perf.ko.xz) PCIe NTB Simple Pingpong Client (ntb_pingpong.ko.xz) PCIe NTB Debugging Tool (ntb_tool.ko.xz) Software Queue-Pair Transport over NTB (ntb_transport.ko.xz) Intel Elkhart Lake PCH pinctrl/GPIO driver (pinctrl-elkhartlake.ko.xz) Dell platform setting control interface (dell-wmi-sysman.ko.xz) DesignWare PWM Controller (pwm-dwc.ko.xz) SoundWire bus (soundwire-bus.ko.xz) Cadence Soundwire Library (soundwire-cadence.ko.xz) SoundWire Generic Bandwidth Allocation (soundwire-generic-allocation.ko.xz) Intel Soundwire Init Library (soundwire-intel.ko.xz) Fast-charge control for Apple "MFi" devices (apple-mfi-fastcharge.ko.xz) TI HD3SS3220 DRP Port Controller Driver (hd3ss3220.ko.xz) STMicroelectronics STUSB160x Type-C controller driver (stusb160x.ko.xz) Nitro Enclaves Driver (nitro_enclaves.ko.xz) 6.2. Updated drivers Graphics and miscellaneous driver updates Standalone drm driver for the VMware SVGA device (vmwgfx.ko.xz) has been updated to version 2.18.0.0. Cisco FCoE HBA Driver (fnic.ko.xz) has been updated to version 1.6.0.53. Driver for HP Smart Array Controller version 3.4.20-200-RH1 (hpsa.ko.xz) has been updated to version 3.4.20-200-RH1. Emulex LightPulse Fibre Channel SCSI driver 12.8.0.5 (lpfc.ko.xz) has been updated to version 0:12.8.0.5. LSI MPT Fusion SAS 3.0 Device Driver (mpt3sas.ko.xz) has been updated to version 35.101.00.00. QLogic Fibre Channel HBA Driver (qla2xxx.ko.xz) has been updated to version 10.02.00.104-k. SCSI debug adapter driver (scsi_debug.ko.xz) has been updated to version 0190. Driver for Microsemi Smart Family Controller version 1.2.16-012 (smartpqi.ko.xz) has been updated to version 1.2.16-012. hpe watchdog driver (hpwdt.ko.xz) has been updated to version 2.0.4.

Commands:
Chapter 17. Managing project quotas 17.1. Configuring project quotas OpenStack Networking (neutron) supports the use of quotas to constrain the number of resources created by tenants/projects. You can set project quotas for various network components in the /var/lib/config-data/neutron/etc/neutron/neutron.conf file. For example, to limit the number of routers that a project can create, change the quota_router value: In this example, each project is limited to a maximum of 10 routers. For a listing of the quota settings, see sections that immediately follow. 17.2. L3 quota options Here are quota options available for layer 3 (L3) networking: quota_floatingip - The number of floating IPs available to a project. quota_network - The number of networks available to a project. quota_port - The number of ports available to a project. quota_router - The number of routers available to a project. quota_subnet - The number of subnets available to a project. quota_vip - The number of virtual IP addresses available to a project. 17.3. Firewall quota options Here are quota options available for managing firewalls for projects: quota_firewall - The number of firewalls available to a project. quota_firewall_policy - The number of firewall policies available to a project. quota_firewall_rule - The number of firewall rules available to a project. 17.4. Security group quota options Here are quota options available for managing the number of security groups that projects can create: quota_security_group - The number of security groups available to a project. quota_security_group_rule - The number of security group rules available to a project. 17.5. Management quota options Here are additonal options available to administrators for managing quotas for projects: default_quota * - The default number of resources available to a project. quota_health_monitor * - The number of health monitors available to a project. Health monitors do not consume resources, however the quota option is available because OpenStack Networking considers health monitors as resource consumers. quota_member - The number of pool members available to a project. Pool members do not consume resources, however the quota option is available because OpenStack Networking considers pool members as resource consumers. quota_pool - The number of pools available to a project.

Commands:
quota_router = 10
5.116. irqbalance 5.116.1. RHBA-2012:1157 - irqbalance bug fix update Updated irqbalance packages that fix one bug are now available for Red Hat Enterprise Linux 6. The irqbalance package provides a daemon that evenly distributes interrupt request (IRQ) load across multiple CPUs for enhanced performance. Bug Fix BZ# 845374 The irqbalance daemon assigns each interrupt source in the system to a "class", which represents the type of the device (for example Networking, Storage or Media). Previously, irqbalance had some problems while classifying certain NIC devices that resulted into performance impact on affected systems. With this update, the NIC classification mechanism has been updated to work with all types of NICs. All users of irqbalance are advised to upgrade to these updated packages, which fix this bug. 5.116.2. RHBA-2012:0807 - irqbalance bug fix update Updated irqbalance packages that fix one bug are now available for Red Hat Enterprise Linux 6. The irqbalance packages provide a daemon that evenly distributes interrupt requests (IRQ) load across multiple CPUs for enhanced performance. Bug Fix BZ# 682211 The irqbalance daemon assigns each interrupt source in the system to a "class", which represents the type of the device (for example Networking, Storage or Media). Previously, irqbalance used the IRQ handler names from the /proc/interrupts file to decide the source class, which caused irqbalance to not recognize network interrupts correctly. As a consequence, systems using biosdevname NIC naming did not have their hardware interrupts distributed and pinned as expected. With this update, the device classification mechanism has been improved, and so ensures a better interrupts distribution. All users of irqbalance are advised to upgrade to these updated packages, which fix this bug.

Commands:
3.3. Installing Samba Using yum To install Samba using yum, install the Samba group using the following command: If you require Samba Active Directory integration with gluster, execute the following command: For more information about installing Red Hat Gluster Storage using yum, see Section 2.4, "Installing Red Hat Gluster Storage Server on Red Hat Enterprise Linux (Layered Install)" . Samba can also be installed by following these steps: To install the basic Samba packages, execute the following command: If you require the smbclient on the server, then execute the following command: If you require an Active directory setup, then execute the following commands: Verify if the following packages are installed. Note For instructions how to configure Samba, see the RedHat Gluster Storage 3.5 Admin Guide SMB .

Commands:
yum groupinstall RH-Gluster-Samba-Server
yum groupinstall RH-Gluster-AD-Integration
yum install samba
yum install samba-client
yum install samba-winbind yum install samba-winbind-clients yum install samba-winbind-krb5-locator
samba-libs samba-winbind-krb5-locator samba-winbind-modules samba-vfs-glusterfs samba-winbind samba-client samba-common samba-winbind-clients samba
Chapter 2. Operating Docker-containerized environments 2.1. Troubleshooting APIcast on the Docker-containerized environment This section describes the most common issues that you can find when working with APIcast on a Docker-containerized environment. 2.1.1. Cannot connect to the Docker daemon error The docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host? error message may be because the Docker service hasn't started. You can check the status of the Docker daemon by running the sudo systemctl status docker.service command. Ensure that you are run this command as the root user because the Docker containerized environment requires root permissions in RHEL by default. For more information, see here ). 2.1.2. Basic Docker command-line interface commands If you started the container in the detached mode ( -d option) and want to check the logs for the running APIcast instance, you can use the log command: sudo docker logs <container> . Where <container> is the container name ( "apicast" in the example above) or the container ID. You can get a list of the running containers and their IDs and names by using the sudo docker ps command. To stop the container, run the sudo docker stop <container> command. You can also remove the container by running the sudo docker rm <container> command. For more information on available commands, see Docker commands reference .

Commands:
Chapter 2. Checking services using IdM Healthcheck You can monitor services used by the Identity Management (IdM) server using the Healthcheck tool. For details, see Healthcheck in IdM . Prerequisites The Healthcheck tool is only available on RHEL 8.1 and newer 2.1. Services Healthcheck test The Healthcheck tool includes a test to check if any IdM services is not running. This test is important because services which are not running can cause failures in other tests. Therefore, check that all services are running first. You can then check all other test results. To see all services tests, run ipa-healthcheck with the --list-sources option: You can find all services tested with Healthcheck under the ipahealthcheck.meta.services source: certmonger dirsrv gssproxy httpd ipa_custodia ipa_dnskeysyncd ipa_otpd kadmin krb5kdc named pki_tomcatd sssd Note Run these tests on all IdM servers when trying to discover issues. 2.2. Screening services using Healthcheck Follow this procedure to run a standalone manual test of services running on the Identity Management (IdM) server using the Healthcheck tool. The Healthcheck tool includes many tests, whose results can be shortened with: Excluding all successful test: --failures-only Including only services tests: --source=ipahealthcheck.meta.services Procedure To run Healthcheck with warnings, errors and critical issues regarding services, enter: A successful test displays empty brackets: If one of the services fails, the result can looks similarly to this example: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.meta.services --failures-only
{ "source": "ipahealthcheck.meta.services", "check": "httpd", "result": "ERROR", "kw": { "status": false, "msg": "httpd: not running" } }
Chapter 1. Deploying Red Hat Insights on systems registered with Red Hat Update Infrastructure This guide is for users who want to deploy Red Hat Insights on an existing, cloud marketplace-purchased Red Hat Enterprise Linux system managed by Red Hat Update Infrastructure (RHUI). To start using Insights, you must perform the following actions on each system you want to monitor and assess: Install the Insights client if it did not come preinstalled. Configure the client to use a form of authentication (activation keys or Red Hat Subscription Manager). Register the system to Insights for Red Hat Enterprise Linux. For more information about authentication, refer to Client Configuration Guide for Red Hat Insights . 1.1. Installing the Insights client Note The Insights client installation procedure is not required on Red Hat Enterprise Linux 8 (RHEL8) systems. Install the client package on each system. Procedure Enter the following command to install the current version of the Insights client package: 1.1.1. Configuring authentication You can use the following methods of authentication with the Insights client: Activation keys (recommended) Red Hat Subscription Manager (RHSM) For more information about how to set up authentication, refer to Client Configuration Guide for Red Hat Insights . 1.2. Registering the system to Red Hat Insights Register the system to communicate with the Red Hat Insights and to view results displayed in the Red Hat Hybrid Cloud Console. Prerequisites Root access to the system Procedure Enter the following command to register the system. 1.3. Viewing your Insights results You can view system and infrastructure results in the Red Hat Insights for Red Hat Enterprise Linux application dashboard. The dashboard provides links to each available Insights service. This includes advisor, vulnerability, compliance, policies and patch. From this starting point, you can proactively identify and manage issues affecting system security, performance, stability and availability. Prerequisites The insights-client package is installed on the system. You are logged in to the Red Hat Hybrid Cloud Console. Procedure Navigate to Red Hat Insights > RHEL > Inventory in the Hybrid Cloud Console. Search for your system name and confirm that it exists in the inventory.

Commands:
yum install insights-client
insights-client --register
Chapter 12. Validating schemas with the Red Hat build of Apicurio Registry You can use the Red Hat build of Apicurio Registry with Streams for Apache Kafka. Apicurio Registry is a datastore for sharing standard event schemas and API designs across API and event-driven architectures. You can use Apicurio Registry to decouple the structure of your data from your client applications, and to share and manage your data types and API descriptions at runtime using a REST interface. Apicurio Registry stores schemas used to serialize and deserialize messages, which can then be referenced from your client applications to ensure that the messages that they send and receive are compatible with those schemas. Apicurio Registry provides Kafka client serializers/deserializers for Kafka producer and consumer applications. Kafka producer applications use serializers to encode messages that conform to specific event schemas. Kafka consumer applications use deserializers, which validate that the messages have been serialized using the correct schema, based on a specific schema ID. You can enable your applications to use a schema from the registry. This ensures consistent schema usage and helps to prevent data errors at runtime. Additional resources Red Hat build of Apicurio Registry product documentation Red Hat build of Apicurio Registry is built on the Apicurio Registry open source community project available on GitHub: Apicurio/apicurio-registry

Commands: