mtpti5iD/redhat-docs_dataset huggingface dataset:
A.5. Enabling Quota Accounting It is possible to keep track of disk usage and maintain quota accounting for every user and group without enforcing the limit and warn values. To do this, mount the file system with the quota=account option specified. Usage -o quota=account Specifies that user and group usage statistics are maintained by the file system, even though the quota limits are not enforced. BlockDevice Specifies the block device where the GFS2 file system resides. MountPoint Specifies the directory where the GFS2 file system should be mounted. Example In this example, the GFS2 file system on /dev/vg01/lvol0 is mounted on the /mygfs2 directory with quota accounting enabled.

Commands:
mount -o quota=account BlockDevice MountPoint
mount -o quota=account /dev/vg01/lvol0 /mygfs2
2.6.2.2.4. Expansions Expansions, when used in conjunction with the spawn and twist directives, provide information about the client, server, and processes involved. The following is a list of supported expansions: %a - Returns the client's IP address. %A - Returns the server's IP address. %c - Returns a variety of client information, such as the user name and hostname, or the user name and IP address. %d - Returns the daemon process name. %h - Returns the client's hostname (or IP address, if the hostname is unavailable). %H - Returns the server's hostname (or IP address, if the hostname is unavailable). %n - Returns the client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed. %N - Returns the server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed. %p - Returns the daemon's process ID. %s -Returns various types of server information, such as the daemon process and the host or IP address of the server. %u - Returns the client's user name. If unavailable, unknown is printed. The following sample rule uses an expansion in conjunction with the spawn command to identify the client host in a customized log file. When connections to the SSH daemon ( sshd ) are attempted from a host in the example.com domain, execute the echo command to log the attempt, including the client hostname (by using the %h expansion), to a special file: Similarly, expansions can be used to personalize messages back to the client. In the following example, clients attempting to access FTP services from the example.com domain are informed that they have been banned from the server: For a full explanation of available expansions, as well as additional access control options, see section 5 of the man pages for hosts_access ( man 5 hosts_access ) and the man page for hosts_options . Refer to Section 2.6.5, "Additional Resources" for more information about TCP Wrappers.

Commands:
sshd : .example.com : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log : deny
vsftpd : .example.com : twist /bin/echo "421 %h has been banned from this server!"
Chapter 1. Customizing your taxonomy tree You can modify a taxonomy tree with knowledge or skills data in your RHEL AI environment to create your own custom Granite Large Language Model (LLM). On RHEL AI, knowledge and skills created data sets are formatted in YAML. This YAML configuration is called a qna.yaml file, where "qna" stands for question and answer. A taxonomy tree is a categorization and information classification method that holds your qna.yaml files. The following documentation sections describe how to create skill and knowledge qna.yaml files for your taxonomy tree. Adding knowledge to your taxonomy tree Adding skills to your taxonomy tree There are a few supported knowledge document types that you can use for training the starter Granite LLM. The current supported document types include: Markdown PDF 1.1. Overview of skill and knowledge You can use skill and knowledge sets and specify domain-specific information to teach your custom model. Knowledge A dataset that consists of information and facts. When creating knowledge data for a model, you are providing it with additional data and information so the model can answer questions more accurately. Skills A dataset where you can teach the model how to do a task. Skills on RHEL AI are split into categories: Compositional skill: Compositional skills allow AI models to perform specific tasks or functions. There are two types of composition skills: Freeform compositional skills: These are performative skills that to not require additional context or information to function. Grounded compositional skills: These are performative skills that require additional context. For example, you can teach the model to read a table, where the additional context is an example of the table layout. Foundation skills: Foundational skills are skills that involve math, reasoning, and coding. Additional Resources Sample knowledge specifications

Commands:
Chapter 5. Stopping JBoss EAP The following procedure uses the Management command line interface (CLI) to stop JBoss EAP. Prerequisites JBoss EAP 7.4.16 is running. Procedure Launch the Management CLI by running: Connect to the server by running the connect command: Stop the server by running the shutdown command: Close the Management CLI by running the quit command: Alternative Here is another way to stop JBoss EAP: Navigate to the terminal where JBoss EAP is running. Press Ctrl+C to stop JBoss Enterprise Application Platform.

Commands:
EAP_HOME/bin/jboss-cli.sh
[disconnected /] connect
[standalone@localhost:9999 /] shutdown
[standalone@localhost:9999 /] quit
7.175. quota 7.175.1. RHBA-2015:1262 - quota bug fix update Updated quota packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The quota packages contain a suite of system administration tools for monitoring and limiting user and group disk usage on file systems. Bug Fixes BZ# 1007785 A regression caused incomplete synchronization of the clustered Global File System 2 (GFS2). As as consequence, queries for quota limits over the network timed out. With this update, the algorithm for translating quota values to the network format has been changed to prevent indefinite cycling in the rpc.rquotad server. As a result, a file system with negative quota values can no longer make the remote procedure call quota service unresponsive. BZ# 1009397 Previously, the reported disk usage exceeded the file system capacity because of listing disk usage on a clustered GFS2 file system when a local node was not fully synchronized. Now, disk usage and quotas are printed as signed numbers to reflect the fact that negative fluctuations in disk usage accounting do occur in unsynchronized nodes of clustered file systems. As a result, negative disk usage values are properly reported. BZ# 1024097 Prior to this update, the rpc.quotad server terminated with the "Too many autofs mount points." error when querying for disk quotas over the network to a server that has automounted more than 64 file systems. To fix this bug, the code enumerating automounted file systems has been altered. Now, quota tools suppressing automounted file systems do not impose any limit on their number. Users of quota are advised to upgrade to these updated packages, which fix these bugs.

Commands:
7.8.3. Related Documentation Red Hat Linux Firewalls , by Bill McCarty; Red Hat Press - a comprehensive reference to building network and server firewalls using open source packet filtering technology such as Netfilter and iptables . It includes such topics as analyzing firewall logs, developing firewall rules, and customizing your firewall with graphical tools such as lokkit . Linux Firewalls , by Robert Ziegler; New Riders Press - contains a wealth of information on building firewalls using both 2.2 kernel ipchains as well as Netfilter and iptables . Additional security topics such as remote access issues and intrusion detection systems are also covered.

Commands:
2.8. SSSD Clients and Active Directory DNS Site Autodiscovery Active Directory forests can be very large, with numerous different domain controllers, domains and child domains, and physical sites. Active Directory uses the concept of sites to identify the physical location for its domain controllers. This enables clients to connect to the domain controller that is geographically closest, which increases client performance. By default, SSSD clients use autodiscovery to find its AD site and connect to the closest domain controller. The process consists of these steps: SSSD queries SRV records from the DNS server in the AD forest. The returned records contain the names of DCs in the forest. SSSD sends an LDAP ping to each of these DCs. If a DC does not respond within a configured interval, the request times out and SSSD sends the LDAP ping to the one. If the connection succeeds, the response contains information about the AD site the SSSD client belongs to. SSSD then queries SRV records from the DNS server to locate DCs within the site it belongs to, and connects to one of them. Note SSSD remembers the AD site it belongs to by default. In this way, SSSD can send the LDAP ping directly to a DC in this site during the autodiscovery process to refresh the site information. Consequently, the procedure of autodiscovery is very fast as no timeouts occur normally. If the site no longer exists or the client has meanwhile been assigned to a different site, SSSD starts querying for SRV records in the forest and goes through the whole process again. To override the autodiscovery, specify the AD site to which you want the client to connect by using the ad_site option in the [domain] section of the /etc/sssd/sssd.conf file. Additional Resources See the sssd-ad (5) man page for details on ad_site . For environments with a trust between Identity Management and Active Directory, see Section 5.6, "Restricting Identity Management or SSSD to Selected Active Directory Servers or Sites in a Trusted Active Directory Domain" .

Commands:
8.9. Accelerated RFS Accelerated RFS boosts the speed of RFS by adding hardware assistance. Like RFS, packets are forwarded based on the location of the application consuming the packet. Unlike traditional RFS, however, packets are sent directly to a CPU that is local to the thread consuming the data: either the CPU that is executing the application, or a CPU local to that CPU in the cache hierarchy. Accelerated RFS is only available if the following conditions are met: Accelerated RFS must be supported by the network interface card. Accelerated RFS is supported by cards that export the ndo_rx_flow_steer() netdevice function. ntuple filtering must be enabled. Once these conditions are met, CPU to queue mapping is deduced automatically based on traditional RFS configuration. That is, CPU to queue mapping is deduced based on the IRQ affinities configured by the driver for each receive queue. Refer to Section 8.8, "Receive Flow Steering (RFS)" for details on configuring traditional RFS. Red Hat recommends using accelerated RFS wherever using RFS is appropriate and the network interface card supports hardware acceleration.

Commands:
12.2. Partition-based Storage Pools This section covers using a pre-formatted block device, a partition, as a storage pool. For the following examples, a host physical machine has a 500GB hard drive ( /dev/sdc ) partitioned into one 500GB, ext4 formatted partition ( /dev/sdc1 ). We set up a storage pool for it using the procedure below. 12.2.1. Creating a Partition-based Storage Pool Using virt-manager This procedure creates a new storage pool using a partition of a storage device. Procedure 12.1. Creating a partition-based storage pool with virt-manager Open the storage pool settings In the virt-manager graphical interface, select the host physical machine from the main window. Open the Edit menu and select Connection Details Figure 12.1. Connection Details Click on the Storage tab of the Connection Details window. Figure 12.2. Storage tab Create the new storage pool Add a new pool (part 1) Press the + button (the add pool button). The Add a New Storage Pool wizard appears. Choose a Name for the storage pool. This example uses the name guest_images_fs . Change the Type to fs: Pre-Formatted Block Device . Figure 12.3. Storage pool name and type Press the Forward button to continue. Add a new pool (part 2) Change the Target Path , Format , and Source Path fields. Figure 12.4. Storage pool path and format Target Path Enter the location to mount the source device for the storage pool in the Target Path field. If the location does not already exist, virt-manager will create the directory. Format Select a format from the Format list. The device is formatted with the selected format. This example uses the ext4 file system, the default Red Hat Enterprise Linux file system. Source Path Enter the device in the Source Path field. This example uses the /dev/sdc1 device. Verify the details and press the Finish button to create the storage pool. Verify the new storage pool The new storage pool appears in the storage list on the left after a few seconds. Verify the size is reported as expected, 458.20 GB Free in this example. Verify the State field reports the new storage pool as Active . Select the storage pool. In the Autostart field, click the On Boot check box. This will make sure the storage device starts whenever the libvirtd service starts. Figure 12.5. Storage list confirmation The storage pool is now created, close the Connection Details window.

Commands:
33.2. Single-User Mode Single-user mode provides a Linux environment for a single user that allows you to recover your system from problems that cannot be resolved in networked multi-user environment. You do not need an external boot device to be able to boot into single-user mode , and you can switch into it directly while the system is running. To switch into single-user mode on the running system, issue the following command from the command line: In single-user mode , the system boots with your local file systems mounted, many important services running, and a usable maintenance shell that allows you to perform many of the usual system commands. Therefore, single-user mode is mostly useful for resolving problems when the system boots but does not function properly or you cannot log into it. Warning The single-user mode automatically tries to mount your local file systems. Booting to single-user mode could result in loss of data if any of your local file systems cannot be successfully mounted. To boot into single-user mode follow this procedure: Procedure 33.2. Booting into Single-User Mode At the GRUB boot screen, press any key to enter the GRUB interactive menu. Select Red Hat Enterprise Linux with the version of the kernel that you want to boot and press the a to append the line. Type single as a separate word at the end of the line and press Enter to exit GRUB edit mode. Alternatively, you can type 1 instead of single.

Commands:
~]# init 1
6.2. Annotating Objects for Marshalling Using @SerializeWith Objects can be marshalled by providing an Externalizer implementation for the type that needs to be marshalled or unmarshalled, then annotating the marshalled type class with @SerializeWith indicating the Externalizer class to use. Example 6.1. Using the @SerializeWith Annotation In the provided example, the object has been defined as marshallable due to the @SerializeWith annotation. JBoss Marshalling will therefore marshall the object using the Externalizer class passed. This method of defining externalizers is user friendly, however it has the following disadvantages: The payload sizes generated using this method are not the most efficient. This is due to some constraints in the model, such as support for different versions of the same class, or the need to marshall the Externalizer class. This model requires the marshalled class to be annotated with @SerializeWith , however an Externalizer may need to be provided for a class for which source code is not available, or for any other constraints, it cannot be modified. Annotations used in this model may be limiting for framework developers or service providers that attempt to abstract lower level details, such as the marshalling layer, away from the user. Advanced Externalizers are available for users affected by these disadvantages. Note To make Externalizer implementations easier to code and more typesafe, define type <t> as the type of object that is being marshalled or unmarshalled. Report a bug

Commands:
import org.infinispan.commons.marshall.Externalizer; import org.infinispan.commons.marshall.SerializeWith; @SerializeWith(Person.PersonExternalizer.class) public class Person { final String name; final int age; public Person(String name, int age) { this.name = name; this.age = age; } public static class PersonExternalizer implements Externalizer<Person> { @Override public void writeObject(ObjectOutput output, Person person) throws IOException { output.writeObject(person.name); output.writeInt(person.age); } @Override public Person readObject(ObjectInput input) throws IOException, ClassNotFoundException { return new Person((String) input.readObject(), input.readInt()); } } }
Chapter 15. Enabling Red Hat build of Keycloak Health checks Red Hat build of Keycloak has built in support for health checks. This chapter describes how to enable and use the Keycloak health checks. 15.1. Red Hat build of Keycloak Health checks Red Hat build of Keycloak exposed health endpoints are three: /health /health/live /health/ready The result is returned in json format and it looks as follows: { "status": "UP", "checks": [] } 15.2. Enabling the health checks It is possible to enable the health checks using the build time option health-enabled : bin/kc.[sh|bat] build --health-enabled=true By default, no check is returned from the health endpoints. 15.3. Using the health checks It is recommended that the health endpoints be monitored by external HTTP requests. Due to security measures that remove curl and other packages from the Red Hat build of Keycloak container image, local command-based monitoring will not function easily. If you are not using Red Hat build of Keycloak in a container, use whatever you want to access the health check endpoints. 15.3.1. curl You may use a simple HTTP HEAD request to determine the live or ready state of Red Hat build of Keycloak. curl is a good HTTP client for this purpose. If Red Hat build of Keycloak is deployed in a container, you must run this command from outside it due to the previously mentioned security measures. For example: curl --head -fsS http://localhost:8080/health/ready If the command returns with status 0, then Red Hat build of Keycloak is live or ready , depending on which endpoint you called. Otherwise there is a problem. 15.3.2. Kubernetes Define a HTTP Probe so that Kubernetes may externally monitor the health endpoints. Do not use a liveness command. 15.3.3. HEALTHCHECK The Dockerfile image HEALTHCHECK instruction defines a command that will be periodically executed inside the container as it runs. The Red Hat build of Keycloak container does not have any CLI HTTP clients installed. Consider installing curl as an additional RPM, as detailed by the Running Red Hat build of Keycloak in a container chapter. Note that your container may be less secure because of this. 15.4. Available Checks The table below shows the available checks. Check Description Requires Metrics Database Returns the status of the database connection pool. Yes For some checks, you'll need to also enable metrics as indicated by the Requires Metrics column. To enable metrics use the metrics-enabled option as follows: bin/kc.[sh|bat] build --health-enabled=true --metrics-enabled=true 15.5. Relevant options Value health-enabled 🛠 If the server should expose health check endpoints. If enabled, health checks are available at the /health , /health/ready and /health/live endpoints. CLI: --health-enabled Env: KC_HEALTH_ENABLED true , false (default)

Commands:
{ "status": "UP", "checks": [] }
bin/kc.[sh|bat] build --health-enabled=true
curl --head -fsS http://localhost:8080/health/ready
bin/kc.[sh|bat] build --health-enabled=true --metrics-enabled=true
Chapter 3. Configuration of HawtIO HawtIO and its plugins can configure their behaviours through System properties. 3.1. Configuration properties The following table lists the configuration properties for the HawtIO core system and various plugins. System Default Description hawtio.disableProxy false With this property set to true, ProxyServlet (/hawtio/proxy/*) can be disabled. This makes the Connect plugin unavailable, which means HawtIO can no longer connect to remote JVMs, but sometimes users might want to do so because of security if the Connect plugin is not used. hawtio.localAddressProbing true Whether local address probing for proxy allowlist is enabled or not upon startup. Set this property to false to disable it. hawtio.proxyAllowlist localhost, 127.0.0.1 Comma-separated allowlist for target hosts that Connect plugin can connect to via ProxyServlet. All hosts not listed in this allowlist are denied to connect for security reasons. This option can be set to * to allow all hosts. Prefixing an element of the list with "r:" allows to define a regex (example: localhost,r:myserver[0-9]+.mydomain.com) hawtio.redirect.scheme The scheme is to redirect the URL to the login page when authentication is required. hawtio.sessionTimeout The maximum time interval, in seconds, that the servlet container will keep this session open between client accesses. If this option is not configured, then HawtIO uses the default session timeout of the servlet container. 3.1.1. Quarkus For Quarkus, all those properties are configurable in application.properties or application.yaml with the quarkus.hawtio prefix. For example: quarkus.hawtio.disableProxy = true 3.1.2. Spring Boot For Spring Boot, all those properties are configurable in application.properties or application.yaml as is. For example: hawtio.disableProxy = true 3.2. Configuring Jolokia through system properties The Jolokia agent is deployed automatically with io.hawt.web.JolokiaConfiguredAgentServlet that extends Jolokia native org.jolokia.http.AgentServlet class, defined in hawtio-war/WEB-INF/web.xml . If you want to customize the Jolokia Servlet with the configuration parameters that are defined in the Jolokia documentation , you can pass them as System properties prefixed with jolokia . For example: jolokia.policyLocation = file:///opt/hawtio/my-jolokia-access.xml 3.2.1. RBAC Restrictor For some runtimes that support HawtIO RBAC (role-based access control), HawtIO provides a custom Jolokia Restrictor implementation that provides an additional layer of protection over JMX operations based on the ACL (access control list) policy. Warning You cannot use HawtIO RBAC with Quarkus and Spring Boot yet. Enabling the RBAC Restrictor on those runtimes only imposes additional load without any gains. To activate the HawtIO RBAC Restrictor, configure the Jolokia parameter restrictorClass via System property to use io.hawt.web.RBACRestrictor as follows: jolokia.restrictorClass = io.hawt.system.RBACRestrictor

Commands:
quarkus.hawtio.disableProxy = true
hawtio.disableProxy = true
jolokia.policyLocation = file:///opt/hawtio/my-jolokia-access.xml
jolokia.restrictorClass = io.hawt.system.RBACRestrictor