mtpti5iD/redhat-docs_dataset huggingface dataset:
8.227. strace 8.227.1. RHBA-2014:1415 - strace bug fix update Updated strace packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The strace utility intercepts and records the system calls that are made and received by a running process and prints a record of each system call, its arguments, and its return value to standard error output or a file. It is often used for problem diagnoses, debugging, and for instructional purposes. Bug Fixes BZ# 862321 Previously, the strace utility incorrectly assumed that the size of the integer data type and the size of the long data type was the same. As a consequence, strace incorrectly printed the options of a getsockopt call on targets with different sizes of integer and long. A patch has been applied to address this bug, and strace no longer returns incorrect values in the described situation. BZ# 1044605 Previously, invalid system calls were not required to have names in the system calls table. As a consequence, running the "strace -c -S name" command resulted in a segmentation fault under certain circumstances. With this update, invalid system calls are properly handled, and sorting calls by name now works as expected. Users of strace are advised to upgrade to these updated packages, which fix these bugs.

Commands:
7.3. Common iptables Filtering Keeping remote attackers out of a LAN is an important aspect of network security, if not the most important. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules. However, with a default policy set to block all incoming, outgoing, and forwarded packets, it is impossible for the firewall/gateway and internal LAN users to communicate with each other or with external resources. To allow users to perform network-related functions and use networking applications, administrators must open certain ports for communication. For example, to allow access to port 80 on the firewall , append the following rule: This allows regular Web browsing from websites that communicate via port 80. To allow access to secure websites (such as https://www.example.com/), you must open port 443, as well. Important When creating an iptables ruleset, it is critical to remember that order is important. For example, if one chain that specifies that any packets from the local 192.168.100.0/24 subnet be dropped, and then another chain is appended ( -A ) to allow packets from 192.168.100.13 (which is within the dropped restricted subnet), then the appended rule is ignored. You must set a rule to allow 192.168.100.13 first, and then set a drop rule on the subnet. To arbitrarily insert a rule in an existing chain of rules, use -I , followed by the chain in which to insert the rule, and a rule number (1,2,3,...,n) for where the rule should reside. For example: The rule is inserted as the first rule in the INPUT chain to allow local loopback device traffic. There may be times when you require remote access to the LAN from outside the LAN. Secure services such as SSH, can be used for encrypted remote connection to LAN services. For administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dial-up access can be used to circumvent firewall barriers securely, as modem connections are typically behind a firewall/gateway because they are direct connections. However, for remote users with broadband connections, special cases can be made. You can configure iptables to accept connections from remote SSH clients. For example, to allow remote SSH access, the following rules may be used: There are other services for which you may need to define rules. Refer to the Reference Guide for comprehensive information on iptables and its various options. These rules allow incoming and outbound access for an individual system, such as a single PC directly connected to the Internet or a firewall/gateway. However, they do not allow nodes behind the firewall/gateway to access these services. To allow LAN access to these services, you can use NAT with iptables filtering rules.

Commands:
iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -I INPUT 1 -i lo -p all -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p udp --sport 22 -j ACCEPT
Chapter 6. Troubleshooting the Red Hat build of OpenTelemetry The OpenTelemetry Collector offers multiple ways to measure its health as well as investigate data ingestion issues. 6.1. Getting the OpenTelemetry Collector logs You can get the logs for the OpenTelemetry Collector as follows. Procedure Set the relevant log level in the OpenTelemetryCollector custom resource (CR): config: | service: telemetry: logs: level: debug 1 1 Collector's log level. Supported values include info , warn , error , or debug . Defaults to info . Use the oc logs command or the web console to retrieve the logs. 6.2. Exposing the metrics The OpenTelemetry Collector exposes the metrics about the data volumes it has processed. The following metrics are for spans, although similar metrics are exposed for metrics and logs signals: otelcol_receiver_accepted_spans The number of spans successfully pushed into the pipeline. otelcol_receiver_refused_spans The number of spans that could not be pushed into the pipeline. otelcol_exporter_sent_spans The number of spans successfully sent to the destination. otelcol_exporter_enqueue_failed_spans The number of spans failed to be added to the sending queue. The operator creates a <cr_name>-collector-monitoring telemetry service that you can use to scrape the metrics endpoint. Procedure Enable the telemetry service by adding the following lines in the OpenTelemetryCollector custom resource: config: | service: telemetry: metrics: address: ":8888" 1 1 The address at which the internal collector metrics are exposed. Defaults to :8888 . Retrieve the metrics by running the following command, which uses the port-forwarding Collector pod: USD oc port-forward <collector_pod> Access the metrics endpoint at http://localhost:8888/metrics . 6.3. Debug exporter You can configure the debug exporter to export the collected data to the standard output. Procedure Configure the OpenTelemetryCollector custom resource as follows: config: | exporters: debug: verbosity: detailed service: pipelines: traces: exporters: [debug] metrics: exporters: [debug] logs: exporters: [debug] Use the oc logs command or the web console to export the logs to the standard output.

Commands:
config: | service: telemetry: logs: level: debug 1
config: | service: telemetry: metrics: address: ":8888" 1
oc port-forward <collector_pod>
config: | exporters: debug: verbosity: detailed service: pipelines: traces: exporters: [debug] metrics: exporters: [debug] logs: exporters: [debug]
Appendix B. Using AMQ Broker with the examples The Red Hat build of Rhea examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. B.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . B.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... B.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. B.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2023-12-07 10:11:47 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
2.4. Business and Technical Metadata Metadata can include different types of information about a piece of data. Technical metadata describes the information required to access the data, such as where the data resides or the structure of the data in its native environment. Business metadata details other information about the data, such as keywords related to the meta object or notes about the meta object. Note The terms technical and business metadata, refer to the content of the metadata, namely what type of information is contained in the metadata. Do not confuse these with the terms physical and view metadata that indicate what the metadata represents.

Commands:
18.7. The Remote Cache Store The RemoteCacheStore is an implementation of the cache loader that stores data in a remote Red Hat JBoss Data Grid cluster. The RemoteCacheStore uses the Hot Rod client-server architecture to communicate with the remote cluster. For remote cache stores, Hot Rod provides load balancing, fault tolerance and the ability to fine tune the connection between the RemoteCacheStore and the cluster. Report a bug 18.7.1. Remote Cache Store Configuration (Remote Client-Server Mode) The following is a sample remote cache store configuration for Red Hat JBoss Data Grid's Remote Client-Server mode: For details about the elements and parameters used in this sample configuration, see Section 18.3, "Cache Store Configuration Details (Remote Client-Server Mode)" . Report a bug 18.7.2. Remote Cache Store Configuration (Library Mode) The following is a sample remote cache store configuration for Red Hat JBoss Data Grid's Library mode: For details about the elements and parameters used in this sample configuration, see Section 18.2, "Cache Store Configuration Details (Library Mode)" . Report a bug 18.7.3. Define the Outbound Socket for the Remote Cache Store The Hot Rod server used by the remote cache store is defined using the outbound-socket-binding element in a standalone.xml file. An example of this configuration in the standalone.xml file is as follows: Example 18.1. Define the Outbound Socket Report a bug

Commands:
<remote-store cache="default" socket-timeout="60000" tcp-no-delay="true" hotrod-wrapping="true"> <remote-server outbound-socket-binding="remote-store-hotrod-server" /> </remote-store>
<persistence passivation="false"> <remoteStore xmlns="urn:infinispan:config:remote:6.0" remoteCacheName="default" fetchPersistentState="false" shared="true" preload="false" ignoreModifications="false" purgeOnStartup="false" tcpNoDelay="true" pingOnStartup="true" keySizeEstimate="62" valueSizeEstimate="512" forceReturnValues="false"> <servers> <server host="127.0.0.1" port="19711"/> </servers> <connectionPool maxActive="99" maxIdle="97" maxTotal="98" /> </remoteStore> </persistence>
<server> <!-- Additional configuration elements here --> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="USD{jboss.socket.binding.port-offset:0}"> <!-- Additional configuration elements here --> <outbound-socket-binding name="remote-store-hotrod-server"> <remote-destination host="remote-host" port="11222"/> </outbound-socket-binding> </socket-binding-group> </server>
Chapter 2. New features and enhancements This section describes new features and enhancements in Red Hat OpenShift AI. 2.1. New features This release includes enhancements only. 2.2. Enhancements Additional training images tested and verified for distributed workloads The following additional training images are tested and verified: ROCm-compatible KFTO cluster image : A new ROCm-compatible KFTO cluster image, quay.io/modh/training:py311-rocm62-torch241 , is tested and verified. This image is compatible with AMD accelerators that are supported by ROCm 6.2. ROCm-compatible Ray cluster image : A new ROCm-compatible Ray cluster image, quay.io/modh/ray:2.35.0-py311-rocm62 , is tested and verified. This image is compatible with AMD accelerators that are supported by ROCm 6.2. For more information about the available training images in Red Hat OpenShift AI, see the Red Hat OpenShift AI: Supported Configurations Knowledgebase article. Updated Kueue version In OpenShift AI, the version of Kueue has been updated to 0.10.1. Note You must disable the API Priority and Fairness configuration for the Visibility API, as described in the Enabling/Disabling API Priority and Fairness section in the Kueue Cluster Administration guide.

Commands:
Chapter 1. Introduction to Service Telemetry Framework release This release of Service Telemetry Framework (STF) provides new features and resolved issues specific to STF. STF uses components from other Red Hat products. For specific information pertaining to the support of these components, see https://access.redhat.com/site/support/policy/updates/openstack/platform/ and https://access.redhat.com/support/policy/updates/openshift/ . STF 1.5 is compatible with OpenShift Container Platform version 4.10 and 4.12 as the deployment platform. 1.1. Product support The Red Hat Customer Portal offers resources to guide you through the installation and configuration of Service Telemetry Framework. The following types of documentation are available through the Customer Portal: Product documentation Knowledge base articles and solutions Technical briefs Support case management You can access the Customer Portal at https://access.redhat.com/ .

Commands:
Chapter 6. Deleting a compliance report Prerequisites Login access to the Red Hat Hybrid Cloud Console. Procedure Navigate to Red Hat Insights > Compliance > Reports. The list of available reports displays. Optional. Use the search filters to search for the report you want to delete. You may filter the reports by policy name, policy type, operating system, or by systems meeting compliance. Click the name of the report you want to delete. The report displays and shows the list of systems included in the report. Click Delete report on the upper right side of the report. The Delete report dialog box appears with the message Deleting a report is permanent and cannot be undone. Click the Delete report button to confirm that you want to delete the report.

Commands:
Chapter 6. Setting up to Develop Applications Using Java Red Hat Enterprise Linux supports the development of applications in Java. During the system installation, select the Java Platform Add-on to install OpenJDK as the default Java version. Alternatively, follow the instructions in the Installation Guide for Red Hat CodeReady Studio, Chapter 2.2, Installing OpenJDK 1.8.0 on RHEL to install OpenJDK separately. For an integrated graphical development environment, install the Eclipse-based Red Hat CodeReady Studio , which offers extensive support for Java development. Follow the instructions in the Installation Guide for Red Hat CodeReady Studio .

Commands:
probe::tcp.receive Name probe::tcp.receive - Called when a TCP packet is received Synopsis Values urg TCP URG flag protocol Packet protocol from driver psh TCP PSH flag name Name of the probe point rst TCP RST flag dport TCP destination port saddr A string representing the source IP address daddr A string representing the destination IP address ack TCP ACK flag fin TCP FIN flag syn TCP SYN flag sport TCP source port iphdr IP header address

Commands:
tcp.receive
3.2. Search Syntax and Examples The syntax of the search queries for Red Hat Virtualization resources is as follows: result type: {criteria} [sortby sort_spec] Syntax Examples The following examples describe how the search query is used and help you to understand how Red Hat Virtualization assists with building search queries. Table 3.1. Example Search Queries Example Result Hosts: Vms.status = up page 2 Displays page 2 of a list of all hosts running virtual machines that are up. Vms: domain = qa.company.com Displays a list of all virtual machines running on the specified domain. Vms: users.name = Mary Displays a list of all virtual machines belonging to users with the user name Mary. Events: severity > normal sortby time Displays the list of all Events whose severity is higher than Normal, sorted by time.

Commands:
9.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with mysql . Different types allow you to configure flexible access: mysqld_db_t This type is used for the location of the MySQL database. In Red Hat Enterprise Linux, the default location for the database is /var/lib/mysql/ , however this can be changed. If the location for the MySQL database is changed, the new location must be labeled with this type. Refer to the following example for instructions on how to change the default database location and how to label the new section appropriately. mysqld_etc_t This type is used for the MySQL main configuration file /etc/my.cnf and any other configuration files in the /etc/mysql/ directory. mysqld_exec_t This type is used for the mysqld binary located at /usr/libexec/mysqld , which is the default location for the MySQL binary on Red Hat Enterprise Linux. Other systems may locate this binary at /usr/sbin/mysqld which should also be labeled with this type. mysqld_initrc_exec_t This type is used for the initialization file for MySQL, located at /etc/rc.d/init.d/mysqld by default in Red Hat Enterprise Linux. mysqld_log_t Logs for MySQL need to be labeled with this type for proper operation. All log files in /var/log/ matching the mysql.* wildcard must be labeled with this type. mysqld_var_run_t This type is used by files in /var/run/mysqld/ , specifically the process id (PID) named /var/run/mysqld/mysqld.pid which is created by the mysqld daemon when it runs. This type is also used for related socket files such as /var/lib/mysql/mysql.sock . Files such as these must be labeled correctly for proper operation as a confined service.

Commands:
Appendix A. ConnectionBuilder Methods The following table outlines the key methods available to the ConnectionBuilder class used in V4 of the Java software development kit. Table A.1. ConnectionBuilder Methods Method Argument Type Description user String The name of the user with which to connect to the Manager. You must specify both the user name and domain, such as admin@internal . This method must be used together with the password method. password String The password of the user with which to connect to the Manager. compress Boolean Specifies whether responses from the server where the Manager is hosted should be compressed. This option is disabled by default, so this method is only required to enable this option. timeout Integer The timeout, in seconds, to wait for responses to requests. If a request takes longer than this value to respond, the request is cancelled, and an exception is thrown. This argument is optional. ssoUrl String The base URL of the server where the Manager is hosted. For example, https://server.example.com/ovirt-engine/sso/oauth/token?\grant_type=password&scope=ovirt-app-api for password authentication. ssoRevokeUrl String The base URL of the SSO revoke service. This option only needs to be specified when you use an external authentication service. By default, this URL is automatically calculated from the value of the url option so that SSO token revoke is performed using the SSO service that is part of the engine. ssoTokenName String The token name in the JSON SSO response returned from the SSO server. By default, this value is access_token . insecure Boolean Enables or disables verification of the host name in the SSL certificate presented by the server where the Manager is hosted. By default, the identity of host names is verified, and the connection is rejected if the host name is not correct, so this method is only required to disable this option. trustStoreFile String Specifies the location of a file containing the CA certificate used to verify the certificate presented by the server where the Manager is hosted. This method must be used together with the trustStorePassword method. trustStorePassword String The password used to access the keystore file specified in the trustStorePath method.

Commands:
3.14. Searching for Volumes The following table describes all search options for volumes. Table 3.10. Searching for Volumes Property (of resource or resource-type) Type Description (Reference) Cluster String The name of the cluster associated with the volume. Cluster. cluster-prop Depends on property type (examples: name, description, comment, architecture) The property of the clusters associated with the volume. name String The human readable name that identifies the volume. type String Can be one of distribute, replicate, distributed_replicate, stripe, or distributed_stripe. transport_type Integer Can be one of TCP or RDMA. replica_count Integer Number of replica. stripe_count Integer Number of stripes. status String The status of the volume. Can be one of Up or Down. sortby List Sorts the returned results by one of the resource properties. page Integer The page number of results to display. Example Volume: transport_type = rdma and stripe_count >= 2 This example returns a list of volumes with transport type set to RDMA, and with 2 or more stripes.

Commands: