mtpti5iD/redhat-docs_dataset huggingface dataset:
B.6. Glock Tracepoints The tracepoints are also designed to be able to confirm the correctness of the cache control by combining them with the blktrace output and with knowledge of the on-disk layout. It is then possible to check that any given I/O has been issued and completed under the correct lock, and that no races are present. The gfs2_glock_state_change tracepoint is the most important one to understand. It tracks every state change of the glock from initial creation right through to the final demotion which ends with gfs2_glock_put and the final NL to unlocked transition. The l (locked) glock flag is always set before a state change occurs and will not be cleared until after it has finished. There are never any granted holders (the H glock holder flag) during a state change. If there are any queued holders, they will always be in the W (waiting) state. When the state change is complete then the holders may be granted which is the final operation before the l glock flag is cleared. The gfs2_demote_rq tracepoint keeps track of demote requests, both local and remote. Assuming that there is enough memory on the node, the local demote requests will rarely be seen, and most often they will be created by umount or by occasional memory reclaim. The number of remote demote requests is a measure of the contention between nodes for a particular inode or resource group. The gfs2_glock_lock_time tracepoint provides information on the time taken by requests to the DLM. The blocking ( b ) flag was introduced into the glock specifically to be used in combination with this tracepoint. When a holder is granted a lock, gfs2_promote is called, this occurs as the final stages of a state change or when a lock is requested which can be granted immediately due to the glock state already caching a lock of a suitable mode. If the holder is the first one to be granted for this glock, then the f (first) flag is set on that holder. This is currently used only by resource groups.

Commands:
Chapter 24. Branding a Red Hat Quay deployment on the legacy UI You can brand the UI of your Red Hat Quay deployment by changing the registry title, logo, footer image, and by directing users to a website embedded in the footer image. Procedure Update your Red Hat Quay config.yaml file to add the following parameters: BRANDING: logo: 1 footer_img: 2 footer_url: 3 --- REGISTRY_TITLE: 4 REGISTRY_TITLE_SHORT: 5 1 The URL of the image that will appear at the top of your Red Hat Quay deployment. 2 The URL of the image that will appear at the bottom of your Red Hat Quay deployment. 3 The URL of the website that users will be directed to when clicking the footer image. 4 The long-form title for the registry. This is displayed in frontend of your Red Hat Quay deployment, for example, at the sign in page of your organization. 5 The short-form title for the registry. The title is displayed on various pages of your organization, for example, as the title of the tutorial on your organization's Tutorial page. Restart your Red Hat Quay deployment. After restarting, your Red Hat Quay deployment is updated with a new logo, footer image, and footer image URL.

Commands:
BRANDING: logo: 1 footer_img: 2 footer_url: 3 --- REGISTRY_TITLE: 4 REGISTRY_TITLE_SHORT: 5
17.2. Delegating Host Management Hosts are delegated authority over other hosts through the host-add-managedby utility. This creates a managedby entry. Once the managedby entry is created, then the host can retrieve a keytab for the host over which it has delegated authority. Log in as the admin user. Add the managedby entry. For example, this delegates authority over client2 to client1 . Obtain a ticket as the host client1 : Retrieve a keytab for client2 :

Commands:
kinit admin
ipa host-add-managedby client2.example.com --hosts=client1.example.com
kinit -kt /etc/krb5.keytab host/client1.example.com
ipa-getkeytab -s server.example.com -k /tmp/client2.keytab -p host/client2.example.com Keytab successfully retrieved and stored in: /tmp/client2.keytab
Chapter 4. Publishing applications with .NET 8.0 .NET 8.0 applications can be published to use a shared system-wide version of .NET or to include .NET. The following methods exist for publishing .NET 8.0 applications: Self-contained deployment (SCD) - The application includes .NET. This method uses a runtime built by Microsoft. Framework-dependent deployment (FDD) - The application uses a shared system-wide version of .NET. Note When publishing an application for RHEL, Red Hat recommends using FDD, because it ensures that the application is using an up-to-date version of .NET, built by Red Hat, that uses a set of native dependencies. Prerequisites Existing .NET application. For more information about how to create a .NET application, see Creating an application using .NET . 4.1. Publishing .NET applications The following procedure outlines how to publish a framework-dependent application. Procedure Publish the framework-dependent application: Replace my-app with the name of the application you want to publish. Optional: If the application is for RHEL only, trim out the dependencies needed for other platforms: Replace architecture based on the platform you are using: For Intel: x64 For IBM Z and LinuxONE: s390x For 64-bit Arm: arm64 For IBM Power: ppc64le

Commands:
dotnet publish my-app -f net8.0
dotnet publish my-app -f net8.0 -r rhel.8- architecture --self-contained false
3.14. Virtual Machine Connectivity In Red Hat Virtualization, a virtual machine has its NIC put on a logical network at the time that the virtual machine is created. From that point, the virtual machine is able to communicate with any other destination on the same network. From the host perspective, when a virtual machine is put on a logical network, the VNIC that backs the virtual machine's NIC is added as a member to the bridge device for the logical network. For example, if a virtual machine is on the ovirtmgmt logical network, its VNIC is added as a member of the ovirtmgmt bridge of the host on which that virtual machine runs.

Commands:
Appendix D. Internationalization Red Hat Directory Server allows users to store, manage, and search for entries and their associated attributes in a number of different languages. An internationalized directory can be an invaluable corporate resource, providing employees and business partners with immediate access to the information they need in languages they understand. Directory Server supports all international character sets by default because directory data is stored in UTF-8. Further, Directory Server can use specified matching rules and collation orders based on language preferences in search operations. Note ASCII characters are required for attribute and object class names. D.1. About Locales Directory Server provides support for multiple languages through the use of locales . A locale identifies language-specific information about how users of a specific region, culture, or custom expect data to be presented, including how data of a given language is interpreted and how data is to be sorted, or collated . In addition, the locale information indicates what code page should be used to represent a given language. A code page is an internal table that the operating system uses to relate keyboard keys to character font screen displays. More specifically, a locale defines four things: Collation order. The collation order provides language and cultural-specific information about how the characters of a given language are to be sorted. It identifies things like the sequence of the letters in the alphabet, how to compare letters with accents to letters without accents, and if there are any characters that can be ignored when comparing strings. The collation order also takes into account culture-specific information about a language, such as the direction in which the language is read (left to right, right to left, or up and down). Character type. The character type distinguishes alphabetic characters from numeric or other characters. For example, in some languages, the pipe (|) character is considered punctuation while in others it is considered alphabetic. In addition, it defines the mapping of upper-case to lower-case letters. Monetary format. The monetary format specifies the monetary symbol used by a specific region, whether the symbol goes before or after its value, and how monetary units are represented. Time/date format. The time and date format indicates the customary formatting for times and dates in the region. The time and date format indicates whether dates are customarily represented in the mm/dd/yy (month, day, year) or dd/mm/yy (day, month, year) format and specifies what the days of the week and month are in a given language. For example, the date January 10, 1996, is represented as 10. leden 1996 in Czech and 10 janvier 1996 in French. Because a locale describes cultural, customary, and regional differences in addition to mechanical language differences, the directory data can both be translated into the specific languages understood by users as well as be presented in a way that users in a given region expect.

Commands:
Chapter 17. Managing Instance Groups An Instance Group enables you to group instances in a clustered environment. Policies dictate how instance groups behave and how jobs are executed. The following view displays the capacity levels based on policy algorithms: Additional resources For more information about the policy or rules associated with instance groups, see the Instance groups section of the Configuring automation execution . For more information about connecting your instance group to a container, see Container groups . 17.1. Creating an instance group Use the following procedure to create a new instance group. Procedure From the navigation panel, select Automation Execution Infrastructure Instance Groups . Click Create group and select Create instance group from the list. Enter the appropriate details into the following fields: Name : Names must be unique and must not be named "controller". Policy instance minimum : Enter the minimum number of instances to automatically assign to this group when new instances come online. Policy instance percentage : Use the slider to select a minimum percentage of instances to automatically assign to this group when new instances come online. Note Policy instance fields are not required to create a new instance group. If you do not specify values, then the Policy instance minimum and Policy instance percentage default to 0. Max concurrent jobs : Specify the maximum number of forks that can be run for any given job. Max forks : Specify the maximum number of concurrent jobs that can be run for any given job. Note The default value of 0 for Max concurrent jobs and Max forks denotes no limit. For more information, see Instance group capacity limits . Click Create instance group , or, if you have edited an existing Instance Group click Save instance group When you have successfully created the instance group the Details tab of the newly created instance group enables you to review and edit your instance group information. You can also edit Instances and review Jobs associated with this instance group: 17.1.1. Associating instances to an instance group Procedure Select the Instances tab on the Details page of an Instance Group. Click Associate instance . Click the checkbox to one or more available instances from the list to select the instances you want to associate with the instance group and click Confirm 17.1.2. Viewing jobs associated with an instance group Procedure Select the Jobs tab of the Instance Group window. Click the arrow icon to a job to expand the view and show details about each job. Each job displays the following details: The job status The ID and name The type of job The time it started and completed Who started the job and applicable resources associated with it, such as the template, inventory, project, and execution environment Additional resources The instances are run in accordance with instance group policies. For more information, see Instance group policies .

Commands:
C.8. Log tracepoints The tracepoints in this subsystem track blocks being added to and removed from the journal ( gfs2_pin ), as well as the time taken to commit the transactions to the log ( gfs2_log_flush ). This can be very useful when trying to debug journaling performance issues. The gfs2_log_blocks tracepoint keeps track of the reserved blocks in the log, which can help show if the log is too small for the workload, for example. The gfs2_ail_flush tracepoint (Red Hat Enterprise Linux 6.2 and later) is similar to the gfs2_log_flush tracepoint in that it keeps track of the start and end of flushes of the AIL list. The AIL list contains buffers which have been through the log, but have not yet been written back in place and this is periodically flushed in order to release more log space for use by the filesystem, or when a process requests a sync or fsync.

Commands:
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To provide feedback, open a Jira issue that describes your concerns. Provide as much detail as possible so that your request can be addressed quickly. Prerequisites You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure To provide your feedback, use the following steps: Click the following link: Create Issue In the Summary text box, enter a brief description of the issue. In the Description text box, provide more details about the issue. Include the URL where you found the issue. Provide information for any other required fields. Allow fields that contain default information to remain at the defaults. Click Create to create the Jira issue for the documentation team. A documentation issue will be created and routed to the appropriate documentation team. Thank you for taking the time to provide feedback.

Commands:
14.4. Configuration Examples 14.4.1. Changing the Default OpenShift Directory By default, OpenShift stores its data in the /var/lib/openshift/ directory, which is labeled with the openshift_var_lib_t SELinux type. To allow OpenShift to store data in a different directory, label the new directory with the proper SELinux context. The following procedure shows how to change the default OpenShift directory for storing data to /srv/openshift/ : Procedure 14.1. Changing the Default OpenShift Directory for Storing Data As root, create a new /openshift/ directory within the /srv/ directory. The new directory is labeled with the var_t type: As root, use the semanage utility to map /srv/openshift/ to the proper SELinux context: Then, use the restorecon utility as root to apply the changes: The /srv/openshift/ directory is now labeled with the correct openshift_var_lib_t type:

Commands:
~]# mkdir /srv/openshift
~]USD ls -Zd /srv/openshift drwxr-xr-x. root root unconfined_u:object_r:var_t:s0 openshift/
~]# semanage fcontext -a -e /var/lib/openshift /srv/openshift
~]# restorecon -R -v /srv/openshift
~]USD ls -Zd /srv/openshift drwxr-xr-x. root root unconfined_u:object_r:openshift_var_lib_t:s0 openshift/
8.3. Using SCAP Workbench SCAP Workbench ( scap-workbench ) is a graphical utility that allows users to perform configuration and vulnerability scans on a single local or a remote system, perform remediation of the system, and generate reports based on scan evaluations. Note that compared with the oscap command-line utility, SCAP Workbench has only limited functionality. SCAP Workbench can also process only security content in the form of XCCDF and data-stream files. The following sections explain how to install, start, and utilize SCAP Workbench in order to perform system scans, remediation, scan customization, and display relevant examples for these tasks. 8.3.1. Installing SCAP Workbench To install SCAP Workbench on your system, run the following command as root : This command installs all packages required by SCAP Workbench to function properly, including the scap-workbench package that provides the utility itself. Note that required dependencies, such as the qt and openssh packages, will be automatically updated to the newest available version if the packages are already installed on your system. Before you can start using SCAP Workbench effectively, you also need to install or import some security content on your system. For example, you can install the SCAP Security Guide (SSG) package, scap-security-guide , which contains the currently most evolved and elaborate set of security polices for Linux systems. To install the SCAP Security Guide package on your system, run the following command as root: After you install scap-security-guide on your system, unless specified otherwise, the SSG security content is available under the /usr/share/xml/scap/ssg/content/ directory, and you can proceed with other security compliance operations. To find other possible sources of existing SCAP content that might suit your needs, see Section 8.8, "Additional Resources" .

Commands:
~]# yum install scap-workbench
~]# yum install scap-security-guide
Chapter 11. Using Git Effective revision control is essential to all multi-developer projects. It allows all developers in a team to create, review, revise, and document code in a systematic and orderly manner. Red Hat Enterprise Linux 7 is distributed with an open-source revision control system, Git . A detailed description of Git and its features is beyond the scope of this book. For more information about this revision control system, see the resources listed below. Installed Documentation Linux manual pages for Git and tutorials: Note that many Git commands have their own manual pages. Git User's Manual - HTML documentation for Git is located at /usr/share/doc/git-1.8.3/user-manual.html . Online Documentation The online version of the Pro Git book provides a detailed description of Git , its concepts and its usage - Pro Git Book The online version of the Linux manual pages for Git - Pro Git Reference Sheet

Commands:
man git man gittutorial man gittutorial-2
7.198. spice-server 7.198.1. RHBA-2015:1394 - spice-server bug fix update Updated spice-server packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The Simple Protocol for Independent Computing Environments (SPICE) is a remote display protocol for virtual environments. SPICE users can access a virtualized desktop or server from the local system or any system with network access to the server. SPICE is used in Red Hat Enterprise Linux for viewing virtualized guests running on the Kernel-based Virtual Machine (KVM) hypervisor or on Red Hat Enterprise Virtualization Hypervisors. Bug Fixes BZ# 1135372 Prior to this update, when using the "rhel6.0.0" Quick Emulator (QEMU) machine type, the guest could receive invalid drawing commands. Consequently, spice-server terminated unexpectedly. With this update, spice-server detects these invalid drawing commands and ignores them. As a result, spice-server no longer crashes when using the "rhel6.0.0" QEMU machine type. BZ# 1163480 Previously, when using a client with the spice-gtk package version 0.12 or earlier, spice-server did not correctly handle resetting a guest. Consequently, spice-server could terminate unexpectedly with a segmentation fault when resetting a guest. With this update, spice-server properly handles a NULL pointer dereference in the code that handles the spice agent channel, thus avoiding the segmentation fault. As a result, spice-server no longer crashes in this situation. Users of spice-server are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 10. About Red Hat Decision Manager Red Hat Decision Manager is an open source decision management platform that combines business rules management, complex event processing, Decision Model & Notation (DMN) execution, and Red Hat build of OptaPlanner for solving planning problems. It automates business decisions and makes that logic available to the entire business. Business assets such as rules, decision tables, and DMN models are organized in projects and stored in the Business Central repository. This ensures consistency, transparency, and the ability to audit across the business. Business users can modify business logic without requiring assistance from IT personnel. The product is made up of Business Central and KIE Server. KIE Server is the server where rules and other artifacts are executed. It is used to instantiate and execute rules and solve planning problems. KIE Server provides the runtime environment for business assets and accesses the data stored in the assets repository (knowledge store). Business Central is the graphical user interface where you create and manage business rules that KIE Server executes. Business Central is also available as a standalone JAR file. You can use the Business Central standalone JAR file to run Business Central without needing to deploy it to an application server. Red Hat JBoss Enterprise Application Platform (Red Hat JBoss EAP) 7.4 is a certified implementation of the Java Enterprise Edition 8 (Java EE 8) full and web profile specifications. Red Hat JBoss EAP provides preconfigured options for features such as high availability, clustering, messaging, and distributed caching. It also enables users to write, deploy, and run applications using the various APIs and services that Red Hat JBoss EAP provides. The instructions in this document explain how to install Red Hat Process Automation Manager in a Red Hat JBoss EAP 7.4 server instance. Note Red Hat Decision Manager is a subset of Red Hat Process Automation Manager. You must install Red Hat Process Automation Manager in order to use Red Hat Decision Manager. For instructions on how to install Red Hat Process Automation Manager in other environments, see the following documents: Installing and configuring KIE Server on IBM WebSphere Application Server Installing and configuring KIE Server on Oracle WebLogic Server Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 4 using Operators Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 3 using templates For information about supported components, see the following documents: What is the mapping between Red Hat Process Automation Manager and the Maven library version? Red Hat Process Automation Manager 7 Supported Configurations

Commands:
Chapter 20. Viewing a component's JMX statistics Overview The tooling collects all JMX statistics reported by Fuse components and displays them in the Properties view. This statistical information can provide significant insight into what is happening in your integration application. JMX statistics are grouped into three categories: Properties , Processor , and Profile . Procedure To see a Fuse component's statistics: In the JMX Navigator view, locate the node for the component. You may have to expand nodes on the tree to locate low-level components. Select the node of the Fuse component whose statistics you want to review. Open the Properties view. The Properties page displays the JMX properties for the selected component: Click Processors to check exchange metrics for the selected component: Click Profile to check message metrics for the selected node and its subnodes:

Commands:
3.6. Listing Domains The realm list command lists every configured domain for the system, as well as the full details and default configuration for that domain. This is the same information as is returned by the realm discovery command, only for a domain that is already in the system configuration. The most notable options accepted by realm list are: --all The --all option lists all discovered domains, both configured and unconfigured. --name-only The --name-only option limits the results to the domain names and does not display the domain configuration details. For more information about the realm list command, see the realm (8) man page.

Commands:
realm list --all --name-only ad.example.com