mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 31. VDO Evaluation 31.1. Introduction VDO is software that provides inline block-level deduplication, compression, and thin provisioning capabilities for primary storage. VDO installs within the Linux device mapper framework, where it takes ownership of existing physical block devices and remaps these to new, higher-level block devices with data-efficiency properties. Specifically, VDO can multiply the effective capacity of these devices by ten or more. These benefits require additional system resources, so it is therefore necessary to measure VDO's impact on system performance. Storage vendors undoubtedly have existing in-house test plans and expertise that they use to evaluate new storage products. Since the VDO layer helps to identify deduplication and compression, different tests may be required. An effective test plan requires studying the VDO architecture and exploring these items: VDO-specific configurable properties (performance tuning end-user applications) Impact of being a native 4 KB block device Response to access patterns and distributions of deduplication and compression Performance in high-load environments (very important) Analyze cost vs. capacity vs. performance, based on application Failure to consider such factors up front has created situations that have invalidated certain tests and required customers to repeat testing and data collection efforts. 31.1.1. Expectations and Deliverables This Evaluation Guide is meant to augment, not replace, a vendor's internal evaluation effort. With a modest investment of time, it will help evaluators produce an accurate assessment of VDO's integration into existing storage devices. This guide is designed to: Help engineers identify configuration settings that elicit optimal responses from the test device Provide an understanding of basic tuning parameters to help avoid product misconfigurations Create a performance results portfolio as a reference to compare against "real" application results Identify how different workloads affect performance and data efficiency Expedite time-to-market with VDO implementations The test results will help Red Hat engineers assist in understanding VDO's behavior when integrated into specific storage environments. OEMs will understand how to design their deduplication and compression capable devices, and also how their customers can tune their applications to best use those devices. Be aware that the procedures in this document are designed to provide conditions under which VDO can be most realistically evaluated. Altering test procedures or parameters may invalidate results. Red Hat Sales Engineers are available to offer guidance when modifying test plans.

Commands:
Chapter 41. Performance tuning considerations with Business Central The following key concepts or suggested practices can help you optimize Business Central configuration and Red Hat Decision Manager performance. These concepts are summarized in this section as a convenience and are explained in more detail in the cross-referenced documentation, where applicable. This section will expand or change as needed with new releases of Red Hat Decision Manager. Ensure that development mode is enabled during development You can set KIE Server or specific projects in Business Central to use production mode or development mode. By default, KIE Server and all new projects in Business Central are in development mode. This mode provides features that facilitate your development experience, such as flexible project deployment policies, and features that optimize KIE Server performance during development, such as disabled duplicate GAV detection. Use development mode until your Red Hat Decision Manager environment is established and completely ready for production mode. For more information about configuring the environment mode or duplicate GAV detection, see the following resources: Chapter 36, Configuring the environment mode in KIE Server and Business Central Packaging and deploying an Red Hat Decision Manager project Disable verification and validation of complex guided decision tables The decision table verification and validation feature of Business Central is enabled by default. This feature helps you validate your guided decision tables, but with complex guided decision tables, this feature can hinder decision engine performance. You can disable this feature by setting the org.kie.verification.disable-dtable-realtime-verification system property value to true . For more information about guided decision table validation, see Designing a decision service using guided decision tables . Disable automatic builds if you have many large projects In Business Central, when you navigate between projects in the Project Explorer side panel, the selected project is built automatically so that the Alerts window is updated to show any build errors for the project. If you have large projects or frequently switch between many projects that are under active development, this feature can hinder Business Central and decision engine performance. To disable automatic project builds, set the org.kie.build.disable-project-explorer system property to true .

Commands:
4.7. BIND There are several major changes in BIND configuration: Default ACL configuration In Red Hat Enterprise Linux 5, the default ACL configuration allowed queries and offered recursion for all hosts. By default in Red Hat Enterprise Linux 6, all hosts can make queries for authoritative data but only hosts from the local network can make recursive queries. New allow-query-cache option The allow-recursion option has been deprecated in favor of this option. It is used to control access to server caches, which include all non-authoritative data (like recursive lookups and root nameserver hints). Chroot environment management The bind-chroot-admin script, which was used to create symlinks from a non-chroot environment to a chroot environment, is deprecated and no longer exists. Instead, configuration can be managed directly in a non-chroot environment and init scripts automatically mount needed files to the chroot environment during named startup in the case that files are not already present in the chroot. /var/named directory permissions The /var/named directory is no longer writable. All zone files that need to be writable (such as dynamic DNS zones, DDNS) must be placed in the new writable directory: /var/named/dynamic . dnssec [yes|no] option removed The global dnssec [yes|no] options have been split into two new options: dnssec-enable and dnssec-validation . The dnssec-enable option enables DNSSEC support. The dnssec-validation option enables DNSSEC validation. Note that setting dnssec-enable to "no" on recursive server means that it cannot be used as a forwarder by another server that performs DNSSEC validation. Both options are set to yes by default. controls statement not required You no longer need to specify the controls statement in /etc/named.conf if you use the rndc management utility. The named service automatically allows control connections using the loopback device and both named and rndc use the same secret key generated during installation (located in /etc/rndc.key ). In a default installation, BIND is installed with DNSSEC validation enabled, and uses the ISC DLV register. This means all signed domains (such as gov., se., cz.), that have their key in the ISC DLV register, are cryptographically validated on the recursive server. If validation fails due to attempts at cache poisoning, then the end user will not be given this forged/spoofed data. DNSSEC deployment is fully supported in Red Hat Enterprise Linux 6. DNSSEC is an important step in making the Internet more secure for end users, and is widely implemented. As previously mentioned, DNSSEC validation is controlled with the dnssec-validation option in /etc/named.conf .

Commands:
20.2. Setting Password Administrators The Directory Manager can add the password administrator role to a user or a group of users. Since access control instructions (ACI) need to be set, it is recommended that a group is used to allow just a single ACI set to manage all password administrators. A password administrator can perform any user password operations, including the following: forcing the user to change their password, changing a user's password to a different storage scheme defined in the password policy, bypassing the password syntax checks, and adding already hashed passwords. As explained in Section 20.1, "Setting User Passwords" , it is recommended that ordinary password updates are done by an existing role in the database with permissions to update only the userPassword attribute. Red Hat recommends not to use the password administrator account for these ordinary tasks. You can specify a user or a group as password administrator: In a local policy. For example: In a global policy. For example: Note You can add a new passwordAdminSkipInfoUpdate: on/off setting under the cn=config entry to provide a fine grained control over password updates performed by password administrators. When you enable this setting, passwords updates do not update certain attributes, for example, passwordHistory , passwordExpirationTime , passwordRetryCount , pwdReset , and passwordExpWarned .

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set ou=people,dc=example,dc=com --pwdadmin " cn=password_admins,ou=groups,dc=example,dc=com "
dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdadmin " cn=password_admins,ou=groups,dc=example,dc=com "
Chapter 14. Using TLS certificates for applications accessing RGW Most of the S3 applications require TLS certificate in the forms such as an option included in the Deployment configuration file, passed as a file in the request, or stored in /etc/pki paths. TLS certificates for RADOS Object Gateway (RGW) are stored as Kubernetes secret and you need to fetch the details from the secret. Prerequisites A running OpenShift Data Foundation cluster. Procedure For internal RGW server Get the TLS certificate and key from the kubernetes secret: <secret_name> The default kubernetes secret name is <objectstore_name>-cos-ceph-rgw-tls-cert . Specify the name of the object store. For external RGW server Get the the TLS certificate from the kubernetes secret: <secret_name> The default kubernetes secret name is ceph-rgw-tls-cert and it is an opaque type of secret. The key value for storing the TLS certificates is cert .

Commands:
oc get secrets/<secret_name> -o jsonpath='{.data..tls\.crt}' | base64 -d oc get secrets/<secret_name> -o jsonpath='{.data..tls\.key}' | base64 -d
oc get secrets/<secret_name> -o jsonpath='{.data.cert}' | base64 -d
4.147. libtasn1 4.147.1. RHSA-2012:0427 - Important: libtasn1 security update Updated libtasn1 packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. libtasn1 is a library developed for ASN.1 (Abstract Syntax Notation One) structures management that includes DER (Distinguished Encoding Rules) encoding and decoding. Security Fix CVE-2012-1569 A flaw was found in the way libtasn1 decoded DER data. An attacker could create carefully-crafted DER encoded input (such as an X.509 certificate) that, when parsed by an application that uses libtasn1 (such as applications using GnuTLS), could cause the application to crash. Red Hat would like to thank Matthew Hall of Mu Dynamics for reporting this issue. Users of libtasn1 are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. For the update to take effect, all applications linked to the libtasn1 library must be restarted, or the system rebooted.

Commands:
C.10. Interpreter org.infinispan.cli.interpreter.Interpreter The Interpreter component executes command line interface ( CLI operations). Table C.17. Attributes Name Description Type Writable cacheNames Retrieves a list of caches for the cache manager. String[] No Table C.18. Operations Name Description Signature createSessionId Creates a new interpreter session. String createSessionId(String cacheName) execute Parses and executes IspnCliQL statements. String execute(String p0, String p1) 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
27.3. Delegating Permissions over Users Delegation is very similar to roles in that one group of users is assigned permission to manage the entries for another group of users. However, the delegated authority is much more similar to self-service rules in that complete access is granted but only to specific user attributes, not to the entire entry. Also, the groups in delegated authority are existing IdM user groups instead of roles specifically created for access controls. 27.3.1. Delegating Access to User Groups in the Web UI Open the IPA Server tab in the top menu, and select the Delegations subtab. Click the Add link at the top of the list of delegation ACIs. Name the new delegation ACI. Set the permissions by selecting the checkboxes whether users will have the right to view the given attributes (read) and add or change the given attributes (write). Some users may have a need to see information, but should not be able to edit it. In the User group drop-down menu, select the group who is being granted permissions to the entries of users in the user group. In the Member user group drop-down menu, select the group whose entries can be edited by members of the delegation group. In the attributes box, select the checkboxes by the attributes to which the member user group is being granted permission. Click the Add button to save the new delegation ACI. 27.3.2. Delegating Access to User Groups in the Command Line A new delegation access control rule is added using the delegation-add command. There are three required arguments: --group , the group who is being granted permissions to the entries of users in the user group. --membergroup , the group whose entries can be edited by members of the delegation group. --attrs , the attributes which users in the member group are allowed to edit. For example: Delegation rules are edited using the delegation-mod command. The --attrs option overwrites whatever the list of supported attributes was, so always include the complete list of attributes along with any new attributes. Important Include all of the attributes when modifying a delegation rule, including existing ones.

Commands:
ipa delegation-add "basic manager attrs" --attrs=manager,title,employeetype,employeenumber --group=engineering_managers --membergroup=engineering -------------------------------------- Added delegation "basic manager attrs" -------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber Member user group: engineering User group: engineering_managers
ipa delegation-mod "basic manager attrs" --attrs=manager,title,employeetype,employeenumber,displayname ----------------------------------------- Modified delegation "basic manager attrs" ----------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber, displayname Member user group: engineering User group: engineering_managers
10.2. Setting up a Cache Currently, Red Hat Enterprise Linux 7 only provides the cachefiles caching back end. The cachefilesd daemon initiates and manages cachefiles . The /etc/cachefilesd.conf file controls how cachefiles provides caching services. The first setting to configure in a cache back end is which directory to use as a cache. To configure this, use the following parameter: Typically, the cache back end directory is set in /etc/cachefilesd.conf as /var/cache/fscache , as in: If you want to change the cache back end directory, the selinux context must be same as /var/cache/fscache : Replace /path/to/cache with the directory name while setting up cache. Note If the given commands for setting selinux context did not work, use the following commands: FS-Cache will store the cache in the file system that hosts /path/to/cache . On a laptop, it is advisable to use the root file system ( / ) as the host file system, but for a desktop machine it would be more prudent to mount a disk partition specifically for the cache. File systems that support functionalities required by FS-Cache cache back end include the Red Hat Enterprise Linux 7 implementations of the following file systems: ext3 (with extended attributes enabled) ext4 Btrfs XFS The host file system must support user-defined extended attributes; FS-Cache uses these attributes to store coherency maintenance information. To enable user-defined extended attributes for ext3 file systems (i.e. device ), use: Alternatively, extended attributes for a file system can be enabled at mount time, as in: The cache back end works by maintaining a certain amount of free space on the partition hosting the cache. It grows and shrinks the cache in response to other elements of the system using up free space, making it safe to use on the root file system (for example, on a laptop). FS-Cache sets defaults on this behavior, which can be configured via cache cull limits . For more information about configuring cache cull limits, refer to Section 10.4, "Setting Cache Cull Limits" . Once the configuration file is in place, start up the cachefilesd service: To configure cachefilesd to start at boot time, execute the following command as root:

Commands:
dir /path/to/cache
dir /var/cache/fscache
semanage fcontext -a -e /var/cache/fscache /path/to/cache # restorecon -Rv /path/to/cache
semanage permissive -a cachefilesd_t # semanage permissive -a cachefiles_kernel_t
tune2fs -o user_xattr /dev/ device
mount /dev/ device /path/to/cache -o user_xattr
systemctl start cachefilesd
systemctl enable cachefilesd
25.3. Getting Help for Vault Commands To display all commands used to manage vaults and vault containers: To display detailed help for a particular command, add the --help option to the command: Vault Commands Fail with vault not found Error Some commands require you to specify the owner or the type of the vault using the following options: --user or --service specify the owner of the vault you want to view --shared specify that the vault you want to view is a shared vault For example, if you attempt to view another user's vault without adding --user , IdM informs you it did not find the vault:

Commands:
ipa help vault
ipa vault-add --help
ipa vault-show user_vault --user user
[admin@server ~]USD ipa vault-show user_vault ipa: ERROR: user_vault: vault not found
22.19. Additional Resources The following sources of information provide additional resources regarding NTP and ntpd . 22.19.1. Installed Documentation ntpd(8) man page - Describes ntpd in detail, including the command-line options. ntp.conf(5) man page - Contains information on how to configure associations with servers and peers. ntpq(8) man page - Describes the NTP query utility for monitoring and querying an NTP server. ntpdc(8) man page - Describes the ntpd utility for querying and changing the state of ntpd . ntp_auth(5) man page - Describes authentication options, commands, and key management for ntpd . ntp_keygen(8) man page - Describes generating public and private keys for ntpd . ntp_acc(5) man page - Describes access control options using the restrict command. ntp_mon(5) man page - Describes monitoring options for the gathering of statistics. ntp_clock(5) man page - Describes commands for configuring reference clocks. ntp_misc(5) man page - Describes miscellaneous options.

Commands:
Chapter 7. LVM Troubleshooting This chapter provide instructions for troubleshooting a variety of LVM issues. 7.1. Troubleshooting Diagnostics If a command is not working as expected, you can gather diagnostics in the following ways: Use the -v , -vv , -vvv , or -vvvv argument of any command for increasingly verbose levels of output. If the problem is related to the logical volume activation, set 'activation = 1' in the 'log' section of the configuration file and run the command with the -vvvv argument. After you have finished examining this output be sure to reset this parameter to 0, to avoid possible problems with the machine locking during low memory situations. Run the lvmdump command, which provides an information dump for diagnostic purposes. For information, see the lvmdump (8) man page. Execute the lvs -v , pvs -a or dmsetup info -c command for additional system information. Examine the last backup of the metadata in the /etc/lvm/backup file and archived versions in the /etc/lvm/archive file. Check the current configuration information by running the lvmconfig command. Check the .cache file in the /etc/lvm directory for a record of which devices have physical volumes on them.

Commands:
Chapter 5. Memory Read this chapter for an overview of the memory management features available in Red Hat Enterprise Linux, and how to use these management features to optimize memory utilization in your system. 5.1. Huge Translation Lookaside Buffer (HugeTLB) Physical memory addresses are translated to virtual memory addresses as part of memory management. The mapped relationship of physical to virtual addresses is stored in a data structure known as the page table. Since reading the page table for every address mapping would be time consuming and resource-expensive, there is a cache for recently-used addresses. This cache is called the Translation Lookaside Buffer (TLB). However, the TLB can only cache so many address mappings. If a requested address mapping is not in the TLB, the page table must still be read to determine the physical to virtual address mapping. This is known as a "TLB miss". Applications with large memory requirements are more likely to be affected by TLB misses than applications with minimal memory requirements because of the relationship between their memory requirements and the size of the pages used to cache address mappings in the TLB. Since each miss involves reading the page table, it is important to avoid these misses wherever possible. The Huge Translation Lookaside Buffer (HugeTLB) allows memory to be managed in very large segments so that more address mappings can be cached at one time. This reduces the probability of TLB misses, which in turn improves performance in applications with large memory requirements. Information about configuring the HugeTLB can be found in the kernel documentation: /usr/share/doc/kernel-doc- version /Documentation/vm/hugetlbpage.txt

Commands:
Chapter 5. Running .NET 9.0 applications in containers Use the ubi8/dotnet-90-runtime image to run a .NET application inside a Linux container. The following example uses Podman. Procedure Create a new MVC project in a directory called mvc_runtime_example : Publish the project: Run your image: View the application running in the container:

Commands:
dotnet new mvc --output mvc_runtime_example
dotnet publish mvc_runtime_example -f net9.0 /p:PublishProfile=DefaultContainer /p:ContainerBaseImage=registry.access.redhat.com/ubi8/dotnet-90-runtime:latest
podman run -rm -p8080:8080 mvc_runtime_example
xdg-open http://127.0.0.1:8080