mtpti5iD/redhat-docs_dataset huggingface dataset:
8.2. Create a local cache Creating a local cache, using default configuration options as defined by the JCache API specification, is as simple as doing the following: Warning By default, the JCache API specifies that data should be stored as storeByValue , so that object state mutations outside of operations to the cache, won't have an impact in the objects stored in the cache. JBoss Data Grid has so far implemented this using serialization/marshalling to make copies to store in the cache, and that way adhere to the spec. Hence, if using default JCache configuration with Infinispan, data stored must be marshallable. Alternatively, JCache can be configured to store data by reference. To do that simply call: Library Mode With Library mode a CacheManager may be configured by specifying the location of a configuration file via the URL parameter of CachingProvider.getCacheManager . This allows the opportunity to define clustered caches, which a reference can be later obtained to using the CacheManager.getCache method; otherwise local caches can only be used, created from the CacheManager.createCache . Client-Server Mode With Client-Server mode specific configurations of a remote CacheManager is performed by passing standard HotRod client properties via properties parameter of CachingProvider.getCacheManager . The remote servers referenced must be running and able to receive the request. If not specified the default address and port will be used (127.0.0.1:11222). In addition, contrary to Library mode, the first time a cache reference is obtained CacheManager.createCache must be used so that the cache may be registered internally. Subsequent queries may be performed via CacheManager.getCache . Report a bug

Commands:
import javax.cache.*; import javax.cache.configuration.*; // Retrieve the system wide cache manager CacheManager cacheManager = Caching.getCachingProvider().getCacheManager(); // Define a named cache with default JCache configuration Cache<String, String> cache = cacheManager.createCache("namedCache", new MutableConfiguration<String, String>());
Cache<String, String> cache = cacheManager.createCache("namedCache", new MutableConfiguration<String, String>().setStoreByValue(false));
function::bytes_to_string Name function::bytes_to_string - Human readable string for given bytes Synopsis Arguments bytes Number of bytes to translate. Description Returns a string representing the number of bytes (up to 1024 bytes), the number of kilobytes (when less than 1024K) postfixed by 'K', the number of megabytes (when less than 1024M) postfixed by 'M' or the number of gigabytes postfixed by 'G'. If representing K, M or G, and the number is amount is less than 100, it includes a '.' plus the remainer. The returned string will be 5 characters wide (padding with whitespace at the front) unless negative or representing more than 9999G bytes.

Commands:
bytes_to_string:string(bytes:long)
Chapter 21. Setting read-only permissions for the root file system Sometimes, you need to mount the root file system ( / ) with read-only permissions. Example use cases include enhancing security or ensuring data integrity after an unexpected system power-off. 21.1. Files and directories that always retain write permissions For the system to function properly, some files and directories need to retain write permissions. When the root file system is mounted in read-only mode, these files are mounted in RAM using the tmpfs temporary file system. The default set of such files and directories is read from the /etc/rwtab file. Note that the readonly-root package is required to have this file present in your system. Entries in the /etc/rwtab file follow this format: In this syntax: Replace copy-method with one of the keywords specifying how the file or directory is copied to tmpfs. Replace path with the path to the file or directory. The /etc/rwtab file recognizes the following ways in which a file or directory can be copied to tmpfs : empty An empty path is copied to tmpfs . For example: dirs A directory tree is copied to tmpfs , empty. For example: files A file or a directory tree is copied to tmpfs intact. For example: The same format applies when adding custom paths to /etc/rwtab.d/ . 21.2. Configuring the root file system to mount with read-only permissions on boot With this procedure, the root file system is mounted read-only on all following boots. Procedure In the /etc/sysconfig/readonly-root file, set the READONLY option to yes to mount the file systems as read-only: Add the ro option in the root entry ( / ) in the /etc/fstab file: Enable the ro kernel option: Ensure that the rw kernel option is disabled: If you need to add files and directories to be mounted with write permissions in the tmpfs file system, create a text file in the /etc/rwtab.d/ directory and put the configuration there. For example, to mount the /etc/example/file file with write permissions, add this line to the /etc/rwtab.d/example file: Important Changes made to files and directories in tmpfs do not persist across boots. Reboot the system to apply the changes. Troubleshooting If you mount the root file system with read-only permissions by mistake, you can remount it with read-and-write permissions again using the following command:

Commands:
dirs /var/cache/man dirs /var/gdm <content truncated> empty /tmp empty /var/cache/foomatic <content truncated> files /etc/adjtime files /etc/ntp.conf <content truncated>
copy-method path
empty /tmp
dirs /var/run
files /etc/resolv.conf
READONLY=yes
/dev/mapper/luks-c376919e... / xfs x-systemd.device-timeout=0, ro 1 1
grubby --update-kernel=ALL --args="ro"
grubby --update-kernel=ALL --remove-args="rw"
files /etc/example/file
mount -o remount,rw /
12.5. PCI Device Restrictions Red Hat Enterprise Linux 6 supports 32 PCI device slots per virtual machine, and 8 PCI functions per device slot. This gives a theoretical maximum of 256 PCI functions per guest when multi-function capabilities are enabled. However, this theoretical maximum is subject to the following limitations: Each virtual machine supports a maximum of 8 assigned device functions. 4 PCI device slots are configured with 5 emulated devices (two devices are in slot 1) by default. However, users can explicitly remove 2 of the emulated devices that are configured by default if the guest operating system does not require them for operation (the video adapter device in slot 2; and the memory balloon driver device in the lowest available slot, usually slot 3). This gives users a supported functional maximum of 30 PCI device slots per virtual machine. The following restrictions also apply to PCI device assignment: PCI device assignment (attaching PCI devices to virtual machines) requires host systems to have AMD IOMMU or Intel VT-d support to enable device assignment of PCIe devices. For parallel/legacy PCI, only single devices behind a PCI bridge are supported. Multiple PCIe endpoints connected through a non-root PCIe switch require ACS support in the PCIe bridges of the PCIe switch. To disable this restriction, edit the /etc/libvirt/qemu.conf file and insert the line: relaxed_acs_check=1 Red Hat Enterprise Linux 6 has limited PCI configuration space access by guest device drivers. This limitation could cause drivers that are dependent on PCI configuration space to fail configuration. Red Hat Enterprise Linux 6.2 introduced interrupt remapping as a requirement for PCI device assignment. If your platform does not provide support for interrupt remapping, circumvent the KVM check for this support with the following command as the root user at the command line prompt:

Commands:
relaxed_acs_check=1
echo 1 > /sys/module/kvm/parameters/allow_unsafe_assigned_interrupts
Chapter 14. Configuring GNOME to store user settings on home directories hosted on an NFS share If you use GNOME on a system with home directories hosted on an NFS server, you must change the keyfile backend of the dconf database. Otherwise, dconf might not work correctly. This change affects all users on the host because it changes how dconf manages user settings and configurations stored in the home directories. Procedure Add the following line to the beginning of the /etc/dconf/profile/user file. If the file does not exist, create it. With this setting, dconf polls the keyfile back end to determine whether updates have been made, so settings might not be updated immediately. The changes take effect when the users logs out and in.

Commands:
service-db:keyfile/user
2.8.9.3. Saving IPTables Rules Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root: This executes the iptables init script, which runs the /sbin/iptables-save program and writes the current iptables configuration to /etc/sysconfig/iptables . The existing /etc/sysconfig/iptables file is saved as /etc/sysconfig/iptables.save . The time the system boots, the iptables init script reapplies the rules saved in /etc/sysconfig/iptables by using the /sbin/iptables-restore command. While it is always a good idea to test a new iptables rule before committing it to the /etc/sysconfig/iptables file, it is possible to copy iptables rules into this file from another system's version of this file. This provides a quick way to distribute sets of iptables rules to multiple machines. You can also save the iptables rules to a separate file for distribution, backup, or other purposes. To do so, run the following command as root: iptables-save > <filename> ... where <filename> is a user-defined name for your ruleset. Important If distributing the /etc/sysconfig/iptables file to other machines, type /sbin/service iptables reload or /sbin/service iptables restart for the new rules to take effect. It is better to use the reload command because there is no period of time without a firewall in place. See the description of the reload command in Section 2.8.9.4, "IPTables Control Scripts" . For IPv6 , substitute ip6tables for iptables in the /sbin/service commands listed in this section. For more information about IPv6 and netfilter, see Section 2.8.9.6, "IPTables and IPv6" . Note Note the difference between the iptables command ( /sbin/iptables ), which is used to manipulate the tables and chains that constitute the iptables functionality, and the iptables service ( /sbin/service iptables ), which is used to enable and disable the iptables service itself.

Commands:
~]# /sbin/service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
7.219. rsyslog 7.219.1. RHBA-2013:0450 - rsyslog bug fix update Updated rsyslog packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The rsyslog packages provide an enhanced, multi-threaded syslog daemon. Rsyslog supports MySQL, syslog/TCP, RFC 3195, permitted sender lists, filtering on any message part, and fine grain output format control. Bug Fixes BZ#838148 Prior to this update, the rsyslog packages depended on a newer selinux-policy which the rsyslog spec file did not reflect. The command "yum --security update" updated rsyslog but not the selinux-policy. As a consequence, rsyslog malfunctioned when booting and depending services failed, including login. This update modifies the spec file to prevent installation with an incompatible selinux-policy package and enforce its update if available. BZ# 847568 Prior to this update, the rule that was specified immediately before the "USDIncludeConfig" directive to be reordered after the contents of the included configuration file due to handling problem with the configuration file parser. As a consequence, the order of processing was different from the intended one with the potential of message losses. This update modifies the underlying code so that the order of processing is the same as in the configuration file. BZ#886004 Prior to this update, the Unix Socket Input plug-in for rsyslog did not consider the timestamp format specified by the RFC 5424 Syslog Protocol for timestamps derived from RFC 3339. As a consequence, messages sent to the syslog daemon via Unix sockets that used the RFC 3339-derived timestamp format were silently discarded. This update supports this timestamp format. Messages sent to the rsyslog system logging daemon via Unix sockets that use the RFC 3339-derived timestamp format are now accepted and processed properly. All rsyslog users are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads Red Hat OpenShift Data Foundation 4.13 Red Hat OpenShift Data Foundation Metro-DR feature with Red Hat Advanced Cluster Management for Kubernetes 2.8 and Disaster Recovery with stretch cluster is General Available. The Regional-DR solution for both Blocks and Files is offered as Technology Preview and is subject to Technology Preview support limitations. Red Hat Storage Documentation Team Abstract The intent of this solution guide is to detail the steps necessary to deploy OpenShift Data Foundation for disaster recovery with Advanced Cluster Management and stretch cluster to achieve a highly available storage infrastructure.

Commands:
8.155. opencryptoki 8.155.1. RHBA-2014:1613 - opencryptoki bug fix update Updated opencryptoki packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The opencryptoki packages contain version 2.11 of the PKCS#11 API, implemented for IBM Cryptocards, such as IBM 4764 and 4765 crypto cards. This package includes support for the IBM 4758 Cryptographic CoProcessor (with the PKCS#11 firmware loaded), the IBM eServer Cryptographic Accelerator (FC 4960 on IBM eServer System p), the IBM Crypto Express2 (FC 0863 or FC 0870 on IBM System z), and the IBM CP Assist for Cryptographic Function (FC 3863 on IBM System z). The opencryptoki package also brings a software token implementation that can be used without any cryptographic hardware. This package contains the Slot Daemon (pkcsslotd) and general utilities. Bug Fixes BZ# 1027606 Previously, on the IBM System z architecture, the opencryptoki Common Cryptographic Architecture (CCA) token was sending incorrect information to the CKA_ECDSA_PARAMS attribute when generating an EC key pair. As a consequence, opencryptoki failed to verify the public key. This bug has been fixed and the CCA token now sends the correct information to CKA_ECDSA_PARAMS, and public keys are verified successfully. BZ# 1131745 Prior to this update, the IBM Crypto Accelerator (ICA) token did not handle the chunk size or tail calculation correctly in case of zero message sizes. As a consequence, an overflow occurred leading to a general protection fault (GPF). The underlying source code has been fixed, and GPFs no longer occur. Users of opencryptoki are advised to upgrade to these updated packages, which fix these bugs.

Commands:
E.3. Table Editor E.3.1. Table Editor The Table Editor provides a table-based object type structured view of the contents of a model. The figure below shows a relational model viewed in the Table Editor. Common object types are displayed in individual folders/tables. All base tables, for instance, are shown in one table independent of their parentage. Figure E.9. Table Editor Example You can customize Table Editor properties via Table Editor Preferences . These are the primary features of the Table Editor: Edit existing properties. Add, remove or edit objects, via the main Edit menu and context menu ( Cut, Copy, Paste, Clone, Delete, Rename, Insert Rows ). Paste information from your clipboard into the table. Print your tables. When a Table Editor is in focus, the Insert Table Rows action is added to the application's main toolbar. A few Table Editor actions are contributed to the right-click menu for selected table rows. These actions, described and shown below include: Table Paste - Paste common spreadsheet data (like Microsoft Excel) to set object properties. Table Editor Preferences - Change table editor preferences, including customizing visible properties. Insert Rows - Create multiple new sibling objects. Refresh Table - Refreshes the contents of the current Table Editor to insure it is in sync with the model. Figure E.10. Table Editor Example E.3.2. Editing Properties You can edit properties for an object by double-clicking a table cell. For String properties, the table cell will become an in-place text editor field. Figure E.11. Editing String Property If a property is of a boolean (true or false) type or has multiple, selectable values, a combo box will be displayed to change the value. Figure E.12. Editing Boolean Value Figure E.13. Editing Multi-Value Property For multi-valued properties where the available values are dynamic (i.e. can change based on available models or data), a picker button .... will be displayed. Figure E.14. Editing Multi-Value With Picker An example of this type is the relational column datatype property. Editing via the table cell and clicking the ... button for datatype will display the following dialog. Figure E.15. Editing Datatype Values E.3.3. Inserting Table Rows The Insert Rows action provides an additional way to create objects in a model. Insert Rows action performs the same function as Insert Sibling action, but allows you to create multiple children at the same time. All new rows will correspond to an object of the same type as the selected object and be located under the same parent as the selected object. To Insert Rows in a table: Select a table row to insert rows after. Right-click select Insert Rows action or click the Insert Rows action on the main toolbar. The following dialog will be displayed. Figure E.16. Editing String Property Edit the Number of Rows value in the dialog, or use the up/down buttons to change the value. Click OK in dialog. The desired number of rows (new model objects) will be added after the original selected table row.

Commands:
probe::socket.aio_read.return Name probe::socket.aio_read.return - Conclusion of message received via sock_aio_read Synopsis Values success Was receive successful? (1 = yes, 0 = no) protocol Protocol value flags Socket flags value name Name of this probe state Socket state value size Size of message received (in bytes) or error code if success = 0 type Socket type value family Protocol family value Context The message receiver. Description Fires at the conclusion of receiving a message on a socket via the sock_aio_read function

Commands:
socket.aio_read.return
3.5. Bonds A bond is an aggregation of multiple network interface cards into a single software-defined device. Because bonded network interfaces combine the transmission capability of the network interface cards included in the bond to act as a single network interface, they can provide greater transmission speed than that of a single network interface card. Also, because all network interface cards in the bond must fail for the bond itself to fail, bonding provides increased fault tolerance. However, one limitation is that the network interface cards that form a bonded network interface must be of the same make and model to ensure that all network interface cards in the bond support the same options and modes. The packet dispersal algorithm for a bond is determined by the bonding mode used. Important Modes 1, 2, 3 and 4 support both virtual machine (bridged) and non-virtual machine (bridgeless) network types. Modes 0, 5 and 6 support non-virtual machine (bridgeless) networks only.

Commands:
Chapter 32. The kdump Crash Recovery Service When the kdump crash dumping mechanism is enabled, the system is booted from the context of another kernel. This second kernel reserves a small amount of memory and its only purpose is to capture the core dump image in case the system crashes. Being able to analyze the core dump significantly helps to determine the exact cause of the system failure, and it is therefore strongly recommended to have this feature enabled. This chapter explains how to configure, test, and use the kdump service in Red Hat Enterprise Linux, and provides a brief overview of how to analyze the resulting core dump using the crash debugging utility. 32.1. Installing the kdump Service In order to use the kdump service on your system, make sure you have the kexec-tools package installed. To do so, type the following at a shell prompt as root : For more information on how to install new packages in Red Hat Enterprise Linux, see Section 8.2.4, "Installing Packages" .

Commands:
~]# yum install kexec-tools
Chapter 3. Building blocks multi-site deployments The following building blocks are needed to set up a multi-site deployment with synchronous replication. The building blocks link to a blueprint with an example configuration. They are listed in the order in which they need to be installed. Note We provide these blueprints to show a minimal functionally complete example with a good baseline performance for regular installations. You would still need to adapt it to your environment and your organization's standards and security best practices. 3.1. Prerequisites Understanding the concepts laid out in the Concepts for multi-site deployments chapter. 3.2. Two sites with low-latency connection Ensures that synchronous replication is available for both the database and the external Data Grid. Suggested setup: Two AWS Availability Zones within the same AWS Region. Not considered: Two regions on the same or different continents, as it would increase the latency and the likelihood of network failures. Synchronous replication of databases as services with Aurora Regional Deployments on AWS is only available within the same region. 3.3. Environment for Red Hat build of Keycloak and Data Grid Ensures that the instances are deployed and restarted as needed. Suggested setup: Red Hat OpenShift Service on AWS (ROSA) deployed in each availability zone. Not considered: A stretched ROSA cluster which spans multiple availability zones, as this could be a single point of failure if misconfigured. 3.4. Database A synchronously replicated database across two sites. Blueprint: Deploy AWS Aurora in multiple availability zones . 3.5. Data Grid A deployment of Data Grid that leverages the Data Grid's Cross-DC functionality. Blueprint: Deploy Data Grid for HA with the Data Grid Operator using the Data Grid Operator, and connect the two sites using Data Grid's Gossip Router. Not considered: Direct interconnections between the Kubernetes clusters on the network layer. It might be considered in the future. 3.6. Red Hat build of Keycloak A clustered deployment of Red Hat build of Keycloak in each site, connected to an external Data Grid. Blueprint: Deploy Red Hat build of Keycloak for HA with the Red Hat build of Keycloak Operator that includes connecting to the Aurora database and the Data Grid server. 3.7. Load balancer A load balancer which checks the /lb-check URL of the Red Hat build of Keycloak deployment in each site, plus an automation to detect Data Grid connectivity problems between the two sites. Blueprint: Deploy an AWS Global Accelerator load balancer together with Deploy an AWS Lambda to disable a non-responding site.

Commands: