mtpti5iD/redhat-docs_dataset huggingface dataset:
8.4.2. Socket Queue Like the NIC hardware queue, the socket queue is filled by the network stack from the softirq context. Applications then drain the queues of their corresponding sockets via calls to read , recvfrom , and the like. To monitor the status of this queue, use the netstat utility; the Recv-Q column displays the queue size. Generally speaking, overruns in the socket queue are managed in the same way as NIC hardware buffer overruns (i.e. Section 8.4.1, "NIC Hardware Buffer" ): Input traffic The first option is to slow down input traffic by configuring the rate at which the queue fills. To do so, either filter frames or pre-emptively drop them. You can also slow down input traffic by lowering the NIC's device weight [6] . Queue depth You can also avoid socket queue overruns by increasing the queue depth. To do so, increase the value of either the rmem_default kernel parameter or the SO_RCVBUF socket option. For more information on both, refer to Section 8.2, "Optimized Network Settings" . Application call frequency Whenever possible, optimize the application to perform calls more frequently. This involves modifying or reconfiguring the network application to perform more frequent POSIX calls (such as recv , read ). In turn, this allows an application to drain the queue faster. For many administrators, increasing the queue depth is the preferable solution. This is the easiest solution, but it may not always work long-term. As networking technologies get faster, socket queues will continue to fill more quickly. Over time, this means having to re-adjust the queue depth accordingly. The best solution is to enhance or configure the application to drain data from the kernel more quickly, even if it means queuing the data in application space. This lets the data be stored more flexibly, since it can be swapped out and paged back in as needed. [6] Device weight is controlled via /proc/sys/net/core/dev_weight . For more information about device weight and the implications of adjusting it, refer to Section 8.4.1, "NIC Hardware Buffer" .

Commands:
Chapter 1. Installation environment options for Red Hat Decision Manager With Red Hat Process Automation Manager, you can set up a development environment to develop business applications, a runtime environment to run those applications to support decisions, or both. Development environment : Typically consists of one Business Central installation and at least one KIE Server installation. You can use Business Central to design decisions and other artifacts, and you can use KIE Server to execute and test the artifacts that you created. Runtime environment : Consists of one or more KIE Server instances with or without Business Central. Business Central has an embedded Process Automation Manager controller. If you install Business Central, use the Menu Deploy Execution servers page to create and maintain containers. If you want to automate KIE Server management without Business Central, you can use the headless Process Automation Manager controller. You can also cluster both development and runtime environments. A clustered development or runtime environment consists of a unified group or cluster of two or more servers. The primary benefit of clustering Red Hat Process Automation Manager development environments is high availability and enhanced collaboration, while the primary benefit of clustering Red Hat Process Automation Manager runtime environments is high availability and load balancing. High availability decreases the chance of data loss when a single server fails. When a server fails, another server fills the gap by providing a copy of the data that was on the failed server. When the failed server comes online again, it resumes its place in the cluster. Note Clustering of the runtime environment is currently supported on Red Hat JBoss EAP 7.4 and Red Hat OpenShift Container Platform only. Additional resources Planning a Red Hat Decision Manager installation Red Hat Decision Manager 7 Supported Configurations Red Hat Decision Manager 7 Component Details

Commands:
5.273. rdesktop 5.273.1. RHBA-2012:1276 - rdesktop bug fix update Updated rdesktop packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. The rdesktop packages provide a client for the Remote Desktop Server in Microsoft Windows. The rdesktop client uses the Remote Desktop Protocol (RDP) to remotely present a user's desktop. Bug Fixes BZ# 680917 , BZ# 772020 Prior to this update, redundant conversions functions did not handle the PC/SC (Personal Computer/Smart Card) integration correctly. As a consequence, the rdesktop on AMD64 and Intel 64 platforms failed to connect and incorrectly. This update removes these redundant functions. This update also adds smart card reader support for AMD64 and Intel 64 platforms. Now, the rdesktop connects as expected. BZ# 680926 Prior to this update, the rdesktop code for smart card integration with PC/SC caused a buffer overflow on AMD64 and Intel 64 platforms. As a consequence, the glibc function "free()" was aborted with a segmentation fault. This update uses the correct structure and the glibc function "free()" works now as expected. BZ# 782494 Prior to this update, the server generated a cursor-related command that the rdesktop client did not support when using rdesktop to connect to Windows Server 2008 R2 platforms. As a consequence, the mouse pointer was all black. With this update, the mouse pointer is drawn correctly when connecting to Windows Server 2008 R2. BZ# 820008 Prior to this update, the specification file incorrectly listed the libao-devel package as an install dependency for rdesktop. This update removes the libao-devel dependency from the specification file. BZ# 831095 Prior to this update, the rdesktop client did not handle the licenses correctly, As a consequence, certain Terminal Services failed to connect after the first connection with the error message "disconnect: Internal licensing error". This update modifies the underlying code to handle licenses as expected. Now, Terminal Services connect as expected. All users of rdesktop are advised to upgrade to these updated packages, which fix these bugs.

Commands:
18.12.10.5. IPv4 Protocol ID: ip Rules of this type should either go into the root or ipv4 chain. Table 18.7. IPv4 protocol types Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcmacmask MAC_MASK Mask applied to MAC address of sender dstmacaddr MAC_ADDR MAC address of destination dstmacmask MAC_MASK Mask applied to MAC address of destination srcipaddr IP_ADDR Source IP address srcipmask IP_MASK Mask applied to source IP address dstipaddr IP_ADDR Destination IP address dstipmask IP_MASK Mask applied to destination IP address protocol UINT8, STRING Layer 4 protocol identifier. Valid strings for protocol are: tcp, udp, udplite, esp, ah, icmp, igmp, sctp srcportstart UINT16 Start of range of valid source ports; requires protocol srcportend UINT16 End of range of valid source ports; requires protocol dstportstart UNIT16 Start of range of valid destination ports; requires protocol dstportend UNIT16 End of range of valid destination ports; requires protocol comment STRING text string up to 256 characters

Commands:
32.5. User Private Groups Red Hat Enterprise Linux uses a user private group ( UPG ) scheme, which makes UNIX groups easier to manage. A UPG is created whenever a new user is added to the system. A UPG has the same name as the user for which it was created and that user is the only member of the UPG. UPGs make it safe to set default permissions for a newly created file or directory, allowing both the user and the group of that user to make modifications to the file or directory. The setting which determines what permissions are applied to a newly created file or directory is called a umask and is configured in the /etc/bashrc file. Traditionally on UNIX systems, the umask is set to 022 , which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, including members of the creator's group , are not allowed to make any modifications. However, under the UPG scheme, this "group protection" is not necessary since every user has their own private group. 32.5.1. Group Directories Many IT organizations like to create a group for each major project and then assign people to the group if they need to access that project's files. Using this traditional scheme, managing files has been difficult; when someone creates a file, it is associated with the primary group to which they belong. When a single person works on multiple projects, it is difficult to associate the right files with the right group. Using the UPG scheme, however, groups are automatically assigned to files created within a directory with the setgid bit set. The setgid bit makes managing group projects that share a common directory very simple because any files a user creates within the directory are owned by the group which owns the directory. Let us say, for example, that a group of people need to work on files in the /usr/share/emacs/site-lisp/ directory. Some people are trusted to modify the directory, but certainly not everyone is trusted. First create an emacs group, as in the following command: To associate the contents of the directory with the emacs group, type: Now, it is possible to add the proper users to the group with the gpasswd command: To allow users to create files within the directory, use the following command: When a user creates a new file, it is assigned the group of the user's default private group. , set the setgid bit, which assigns everything created in the directory the same group permission as the directory itself ( emacs ). Use the following command: At this point, because the default umask of each user is 002, all members of the emacs group can create and edit files in the /usr/share/emacs/site-lisp/ directory without the administrator having to change file permissions every time users write new files.

Commands:
/usr/sbin/groupadd emacs
chown -R root.emacs /usr/share/emacs/site-lisp
/usr/bin/gpasswd -a <username> emacs
chmod 775 /usr/share/emacs/site-lisp
chmod 2775 /usr/share/emacs/site-lisp
Chapter 1. About Red Hat OpenShift GitOps Red Hat OpenShift GitOps is an Operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using Red Hat OpenShift GitOps, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. Red Hat OpenShift GitOps is based on the open source project Argo CD and provides a similar set of features to what the upstream offers, with additional automation, integration into Red Hat {OCP} and the benefits of Red Hat's enterprise support, quality assurance and focus on enterprise security. Note Because Red Hat OpenShift GitOps releases on a different cadence from Red Hat OpenShift Service on AWS, the Red Hat OpenShift GitOps documentation is now available as a separate documentation set at Red Hat OpenShift GitOps .

Commands:
function::tokenize Name function::tokenize - Return the non-empty token in a string Synopsis Arguments input string to tokenize. If empty, returns the non-empty token in the string passed in the call to tokenize . delim set of characters that delimit the tokens Description This function returns the non-empty token in the given input string, where the tokens are delimited by characters in the delim string. If the input string is non-empty, it returns the first token. If the input string is empty, it returns the token in the string passed in the call to tokenize. If no delimiter is found, the entire remaining input string is returned. It returns empty when no more tokens are available.

Commands:
tokenize:string(input:string,delim:string)
4.361. xulrunner 4.361.1. RHSA-2012:0143 - Critical: xulrunner security update Updated xulrunner packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having critical security impact. A 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. XULRunner provides the XUL Runtime environment for applications using the Gecko layout engine. Security Fix CVE-2011-3026 A heap-based buffer overflow flaw was found in the way XULRunner handled PNG (Portable Network Graphics) images. A web page containing a malicious PNG image could cause an application linked against XULRunner (such as Firefox) to crash or, potentially, execute arbitrary code with the privileges of the user running the application. All XULRunner users should upgrade to these updated packages, which correct this issue. After installing the update, applications using XULRunner must be restarted for the changes to take effect.

Commands:
Chapter 2. What are the benefits and limitations of simple content access? The foundational benefit of simple content access is that it offers a less restrictive and more flexible way to consume your Red Hat subscriptions. However, this flexibility does include some limitations. 2.1. Benefits Simple content access enables a better experience with the tools that help you manage subscriptions. By removing the need to attach subscriptions at the system level, simple content access streamlines the process of registering systems, enabling repositories, and consuming content so that you can more easily install the products that you want where you want them. 2.2. Limitations Although simple content access allows much more freedom in the consumption of your subscriptions, you should note the following limitations for content access: Simple content access does not provide access to repositories that you have not previously purchased. For example, if you have subscriptions for RHEL only, simple content access does not provide access to any other Red Hat product subscription, such as a Red Hat JBoss Enterprise Application Platform subscription. Simple content access does not provide access within Satellite to repositories that are not included in the subscription manifest. The subscription manifest contains the following information: A list of subscriptions and attached quantities. Metadata and certificates that Satellite uses to synchronize the repositories.

Commands:
5.183. man-pages-fr 5.183.1. RHBA-2012:0463 - man-pages-fr bug fix update An updated man-pages-fr package that fixes one bug is now available for Red Hat Enterprise Linux 6. The man-pages-fr package contains a collection of manual pages from the man-pages Project, translated into French. It also includes supplemental pages provided by Dr. Patrick Atlas and Dr. Gerard Delafond. Bug Fix BZ# 613622 Prior to this update, the mansupfr.tar.bz2 tarball that contains supplemental French manual pages, was not correctly extracted. As a consequence, some manual pages were not installed. With this update, supplemental manual pages are added back when no known file conflicts appear, and the supplemental French manual pages are again available. All users, requiring localized manual pages in French, are advised to upgrade to this updated package, which fixes this bug.

Commands:
Appendix B. S3 common response status codes The following table lists the valid common HTTP response status and its corresponding code. Table B.1. Response Status HTTP Status Response Code 100 Continue 200 Success 201 Created 202 Accepted 204 NoContent 206 Partial content 304 NotModified 400 InvalidArgument 400 InvalidDigest 400 BadDigest 400 InvalidBucketName 400 InvalidObjectName 400 UnresolvableGrantByEmailAddress 400 InvalidPart 400 InvalidPartOrder 400 RequestTimeout 400 EntityTooLarge 403 AccessDenied 403 UserSuspended 403 RequestTimeTooSkewed 404 NoSuchKey 404 NoSuchBucket 404 NoSuchUpload 405 MethodNotAllowed 408 RequestTimeout 409 BucketAlreadyExists 409 BucketNotEmpty 411 MissingContentLength 412 PreconditionFailed 416 InvalidRange 422 UnprocessableEntity 500 InternalError

Commands:
7.173. python-virtinst 7.173.1. RHBA-2015:1372 - python-virtinst bug fix update An updated python-virtinst package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The python-virtinst package contains several command-line utilities, including virt-install for building and installing new virtual machines, and virt-clone for cloning existing virtual machines. Bug Fixes BZ# 1172407 Previously, the virt-manager tool generated an invalid XML code when defining a bridge interface. As a consequence, bridge devices could not be created. With this update, virt-manager generates the correct definition XML and creating bridge devices no longer fails. BZ# 1167998 Prior to this update, input from the user was validated incorrectly by the virt-install utility. Consequently, a non-sparse LVM could not be created and an error message was displayed. This update fixes the input validation and virt-install can now create a non-sparse LVM as expected and an error no longer occurs. BZ# 1167072 Previously, changing the processor type to "copy from host" caused all CPU extensions to be copied manually, even extensions that were not supported for migration. As a consequence, running the "virsh save" command after reboot failed, and an error message was displayed. With this update, when the "--cpu=host" option is specified, the "cpu mode='host-model'" option is used. As a result, unsupported extensions are not no longer manually copied, and the described error no longer occurs. Users of python-virtinst are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 2. Running Java applications with Shenandoah garbage collector You can run your Java application with the Shenandoah garbage collector (GC). Prerequisites Installed Red Hat build of OpenJDK. See Installing Red Hat build of OpenJDK 21 on Red Hat Enterprise Linux in the Installing and using Red Hat build of OpenJDK 17 on RHEL guide. Procedure Run your Java application with Shenandoah GC by using -XX:+UseShenandoahGC JVM option. USD java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC

Commands:
java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC
3.3. LDAP Based Authentication Module The following is an example of what would appear in the server configuration file for an LDAPExtended authentication module defined for the ldap_security_domain security domain. For more information about EAP security, the LDAPExtended module, or any of the provided authentication modules, refer to the JBoss Enterprise Application Platform Security Guide . Note If using SSL to connect to the LDAP server, you would also need to ensure the Corporate CA Certificate is added to the JRE truststore. See Also: Section 1.3, "Configure Authentication in a Security Domain"

Commands:
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="ldap_security_domain"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /> <module-option name="java.naming.provider.url" value="ldap://mydomain.org:389" /> <module-option name="java.naming.security.authentication" value="simple" /> <module-option name="bindDN" value="myuser" /> <module-option name="bindCredential" value="mypasswd" /> <module-option name="baseCtxDN" value="ou=People,dc=XXXX,dc=ca" /> <module-option name="baseFilter" value="(cn={0})" /> <module-option name="rolesCtxDN" value="ou=Webapp-Roles,ou=Groups,dc=XXXX,dc=ca" /> <module-option name="roleFilter" value="(member={1})" /> <module-option name="uidAttributeID" value="member" /> <module-option name="roleAttributeID" value="cn" /> <module-option name="roleAttributeIsDN" value="true" /> <module-option name="roleNameAttributeID" value="cn" /> <module-option name="roleRecursion" value="-1" /> <module-option name="searchScope" value="ONELEVEL_SCOPE" /> <module-option name="allowEmptyPasswords" value="false" /> <module-option name="throwValidateError" value="true" /> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
Release notes for the Red Hat build of Cryostat 3.0 Red Hat build of Cryostat 3 Red Hat Customer Content Services

Commands:
apiVersion: operator.cryostat.io/v1beta2 kind: Cryostat metadata: name: cryostat-sample spec: networkOptions: coreConfig: externalHost: cryostat.example.com
java -jar target/<agent_jar_file> <pid>
java -jar target/cryostat-agent-0.4.0.jar 1234
java -jar target/cryostat-agent-0.4.0.jar -Dcryostat.agent.baseuri=http://cryostat.local --smartTrigger=[ProcessCpuLoad>0.2]~profile @/deployment/app/moreAgentArgs 1234
Error "failed calling webhook "vcryostat.kb.io": failed to call webhook: Post "https://cryostat-operator-controller-manager-service.openshift-operators.svc:443/validate-operator-cryostat-io-v1beta2-cryostat?timeout=10s": tls: failed to verify certificate: x509: certificate is valid for infinispan-operator-controller-manager-service.openshift-operators, infinispan-operator-controller-manager-service.openshift-operators.svc, not cryostat-operator-controller-manager-service.openshift-operators.svc" for field "undefined".
9.3. Date Specifications Date specifications are used to create cron-like expressions relating to time. Each field can contain a single number or a single range. Instead of defaulting to zero, any field not supplied is ignored. For example, monthdays="1" matches the first day of every month and hours="09-17" matches the hours between 9am and 5pm (inclusive). However, you cannot specify weekdays="1,2" or weekdays="1-2,5-6" since they contain multiple ranges. Table 9.4. Properties of a Date Specification Field Description id A unique name for the date hours Allowed values: 0-23 monthdays Allowed values: 0-31 (depending on month and year) weekdays Allowed values: 1-7 (1=Monday, 7=Sunday) yeardays Allowed values: 1-366 (depending on the year) months Allowed values: 1-12 weeks Allowed values: 1-53 (depending on week and year) years Year according the Gregorian calendar weekyears May differ from Gregorian years; for example, 2005-001 Ordinal is also 2005-01-01 Gregorian is also 2004-W53-6 Weekly moon Allowed values: 0-7 (0 is new, 4 is full moon).

Commands:
Chapter 1. Introduction Welcome. In this tutorial, you learn how to incorporate data science and artificial intelligence and machine learning (AI/ML) into an OpenShift development workflow. You use an example fraud detection model to complete the following tasks in Red Hat OpenShift AI without the need to install anything on your computer: Explore a pre-trained fraud detection model by using a Jupyter notebook. Deploy the model by using OpenShift AI model serving. Refine and train the model by using automated pipelines. Learn how to train the model by using Ray, a distributed computing framework. 1.1. About the example fraud detection model The example fraud detection model monitors credit card transactions for potential fraudulent activity. It analyzes the following credit card transaction details: The geographical distance from the credit card transaction. The price of the current transaction, compared to the median price of all the user's transactions. Whether the user completed the transaction by using the hardware chip in the credit card, by entering a PIN number, or by making an online purchase. Based on this data, the model outputs the likelihood of the transaction being fraudulent. 1.2. Before you begin You should have access to an OpenShift cluster where Red Hat OpenShift AI is installed. If don't have access to a cluster that includes an instance of OpenShift AI, see the Red Hat OpenShift AI page on the Red Hat Developer website . There, you can create an account and access the free Red Hat Developer Sandbox or you can learn how to install OpenShift AI on your own OpenShift cluster . Important If your cluster uses self-signed certificates, before you begin the tutorial, your OpenShift AI administrator must add self-signed certificates for OpenShift AI as described in Working with certificates . If you're ready, start the tutorial .

Commands: