mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. SecretList [image.openshift.io/v1] Description SecretList is a list of Secret. Type object Required items 11.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources items array (Secret) Items is a list of secret objects. More info: https://kubernetes.io/docs/concepts/configuration/secret kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ListMeta Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds 11.2. API endpoints The following API endpoints are available: /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/secrets GET : read secrets of the specified ImageStream 11.2.1. /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/secrets Table 11.1. Global path parameters Parameter Type Description name string name of the SecretList HTTP method GET Description read secrets of the specified ImageStream Table 11.2. HTTP responses HTTP code Reponse body 200 - OK SecretList schema 401 - Unauthorized Empty

Commands:
Chapter 3. Annotating Objects and Querying Once indexing has been enabled, custom objects being stored in Red Hat JBoss Data Grid need to be assigned appropriate annotations. As a basic requirement, all objects required to be indexed must be annotated with @Indexed In addition, all fields within the object that will be searched need to be annotated with @Field . Example 3.1. Annotating Objects with @Field For other annotations and options, see Chapter 4, Mapping Domain Objects to the Index Structure Important When using JBoss EAP modules with JBoss Data Grid with the domain model as a module, add the org.infinispan.query dependency with slot "jdg-6.6" into the module.xml file. The custom annotations are not picked by the queries without the org.infinispan.query dependency and results in an error. Report a bug 3.1. Registering a Transformer via Annotations The key for each value must also be indexed, and the key instance must then be transformed in a String. Red Hat JBoss Data Grid includes some default transformation routines for encoding common primitives, however to use a custom key you must provide an implementation of org.infinispan.query.Transformer . The following example shows how to annotate your key type using org.infinispan.query.Transformer : Example 3.2. Annotating the Key Type The two methods must implement a biunique correspondence. For example, for any object A the following must be true: Example 3.3. Biunique Correspondence This assumes that the transformer is the appropriate Transformer implementation for objects of type A. Report a bug

Commands:
@Indexed public class Person implements Serializable { @Field(store = Store.YES) private String name; @Field(store = Store.YES) private String description; @Field(store = Store.YES) private int age; }
@Transformable(transformer = CustomTransformer.class) public class CustomKey { } public class CustomTransformer implements Transformer { @Override public Object fromString(String s) { return new CustomKey(...); } @Override public String toString(Object customType) { CustomKey ck = (CustomKey) customType; return ck.toString(); } }
A.equals(transformer.fromString(transformer.toString(A));
11.2. Enabling Machine-wide Extensions To make extensions available to all users on the system, install them in the /usr/share/gnome-shell/extensions directory. You need to set the org.gnome.shell.enabled-extensions key in order to set the default enabled extensions. However, there is currently no way to enable additional extensions for users who have already logged in. This does not apply for existing users who have installed and enabled their own GNOME extensions. Procedure 11.2. Enabling machine-wide extensions Create a local database file for machine-wide settings in /etc/dconf/db/local.d/00-extensions : The enabled-extensions key specifies the enabled extensions using the extensions' uuid ( myextension1@myname.example.com and myextension2@myname.example.com ). Update the system databases: Users must log out and back in again before the system-wide settings take effect.

Commands:
List all extensions that you want to have enabled for all users enabled-extensions=[' myextension1@myname.example.com ', ' myextension2@myname.example.com ']
dconf update
Preface Open Java Development Kit (OpenJDK) is a free and open-source implementation of the Java Platform, Standard Edition (Java SE). Eclipse Temurin is available in three LTS versions: OpenJDK 8u, OpenJDK 11u, and OpenJDK 17u. Packages for Eclipse Temurin are made available on Microsoft Windows and on multiple Linux x86 Operating Systems including Red Hat Enterprise Linux and Ubuntu.

Commands:
Chapter 4. Deployment path You can configure a deployment where Streams for Apache Kafka manages a single Kafka cluster in the same namespace, suitable for development or testing. Alternatively, Streams for Apache Kafka can manage multiple Kafka clusters across different namespaces in a production environment. The basic deployment path includes the following steps: Create an OpenShift namespace for the Cluster Operator. Deploy the Cluster Operator based on your chosen deployment method. Deploy the Kafka cluster, including the Topic Operator and User Operator if desired. Optionally, deploy additional components: The Topic Operator and User Operator as standalone components, if not deployed with the Kafka cluster Kafka Connect Kafka MirrorMaker Kafka Bridge Metrics monitoring components The Cluster Operator creates OpenShift resources such as Deployment , Service , and Pod for each component. The resource names are appended with the name of the deployed component. For example, a Kafka cluster named my-kafka-cluster will have a service named my-kafka-cluster-kafka .

Commands:
Chapter 1. Role APIs 1.1. ClusterRoleBinding [authorization.openshift.io/v1] Description ClusterRoleBinding references a ClusterRole, but not contain it. It can reference any ClusterRole in the same namespace or in the global namespace. It adds who information via (Users and Groups) OR Subjects and namespace information by which namespace it exists in. ClusterRoleBindings in a given namespace only have effect in that namespace (excepting the master namespace which has power in all namespaces). Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. ClusterRole [authorization.openshift.io/v1] Description ClusterRole is a logical grouping of PolicyRules that can be referenced as a unit by ClusterRoleBindings. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.3. RoleBindingRestriction [authorization.openshift.io/v1] Description RoleBindingRestriction is an object that can be matched against a subject (user, group, or service account) to determine whether rolebindings on that subject are allowed in the namespace to which the RoleBindingRestriction belongs. If any one of those RoleBindingRestriction objects matches a subject, rolebindings on that subject in the namespace are allowed. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. RoleBinding [authorization.openshift.io/v1] Description RoleBinding references a Role, but not contain it. It can reference any Role in the same namespace or in the global namespace. It adds who information via (Users and Groups) OR Subjects and namespace information by which namespace it exists in. RoleBindings in a given namespace only have effect in that namespace (excepting the master namespace which has power in all namespaces). Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. Role [authorization.openshift.io/v1] Description Role is a logical grouping of PolicyRules that can be referenced as a unit by RoleBindings. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object

Commands:
Chapter 4. The Identity Tab The Identity tab provides an interface for viewing and managing projects and users. The following options are available in the Identity tab: Projects - View, create, edit, and delete projects, view project usage, add or remove users as project members, modify quotas, and set an active project. Users - View, create, edit, disable, and delete users, and change user passwords. The Users tab displays only if you are logged in as a user with administrative privileges. For more information about procedures to manage your cloud using the OpenStack Dashboard, see the following guides: Instances and Images guide , which also contains procedures for volumes and containers. Networking guide Users and Identity Management guide

Commands:
function::user_short_warn Name function::user_short_warn - Retrieves a short value stored in user space. Synopsis Arguments addr The user space address to retrieve the short from. General Syntax user_short_warn:long(addr:long) Description Returns the short value from a given user space address. Returns zero when user space and warns (but does not abort) about the failure.

Commands:
function user_short_warn:long(addr:long)
Chapter 19. Documentation Documentation for Red Hat Enterprise Linux 7 is comprised of several separate documents. Each of these documents belongs to one or more of the following subject areas: Release Documentation; Installation and Deployment; Security Tools and Performance; Clustering Virtualization. 19.1. Release Documentation Release Notes The Release Notes document the major new features in Red Hat Enterprise Linux 7. Migration Planning Guide The Red Hat Enterprise Linux Migration Planning Guide documents migration from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7. Desktop Migration and Administration Guide The Desktop Migration and Administration Guide is a guide to the GNOME 3 Desktop migration planning, deployment, configuration, and administration on Red Hat Enterprise Linux 7.

Commands:
Appendix D. Understanding LVM LVM (Logical Volume Management) partitions provide a number of advantages over standard partitions. LVM partitions are formatted as physical volumes . One or more physical volumes are combined to form a volume group . Each volume group's total storage is then divided into one or more logical volumes . The logical volumes function much like standard partitions. They have a file system type, such as xfs , and a mount point. Important On AMD, Intel, and ARM systems and IBM Power Systems servers, the boot loader cannot read LVM volumes. You must make a standard, non-LVM disk partition for your /boot partition. On IBM Z, the zipl boot loader supports /boot on LVM logical volumes with linear mapping. By default, the installation process always creates the / and swap partitions within LVM volumes, with a separate /boot partition on a physical volume. To understand LVM better, imagine the physical volume as a pile of blocks . A block is a storage unit used to store data. Several piles of blocks can be combined to make a much larger pile, just as physical volumes are combined to make a volume group. The resulting pile can be subdivided into several smaller piles of arbitrary size, just as a volume group is allocated to several logical volumes. An administrator can grow or shrink logical volumes without destroying data, unlike standard disk partitions. If the physical volumes in a volume group are on separate drives or RAID arrays, then administrators can also spread a logical volume across the storage devices. You can lose data if you shrink a logical volume to a smaller capacity than the data on the volume requires. To ensure maximum flexibility, create logical volumes to meet your current needs, and leave excess storage capacity unallocated. You can safely extend logical volumes to use unallocated space, depending on your needs.

Commands:
18.12.10.9. IGMP, ESP, AH, UDPLITE, 'ALL' Protocol ID: igmp, esp, ah, udplite, all The chain parameter is ignored for this type of traffic and should either be omitted or set to root. Table 18.11. IGMP, ESP, AH, UDPLITE, 'ALL' Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcmacmask MAC_MASK Mask applied to the MAC address of the sender dstmacaddr MAD_ADDR MAC address of the destination dstmacmask MAC_MASK Mask applied to the MAC address of the destination srcipaddr IP_ADDR Source IP address srcipmask IP_MASK Mask applied to source IP address dstipaddr IP_ADDR Destination IP address dstipmask IP_MASK Mask applied to destination IP address srcipfrom IP_ADDR start of range of source IP address scripto IP_ADDR end of range of source IP address dstipfrom IP_ADDR Start of range of destination IP address dstipto IP_ADDR End of range of destination IP address comment STRING text string up to 256 characters state STRING comma separated list of NEW,ESTABLISHED,RELATED,INVALID or NONE ipset STRING The name of an IPSet managed outside of libvirt ipsetflags IPSETFLAGS flags for the IPSet; requires ipset attribute

Commands:
Chapter 3. Getting Red Hat Quay release notifications To keep up with the latest Red Hat Quay releases and other changes related to Red Hat Quay, you can sign up for update notifications on the Red Hat Customer Portal . After signing up for notifications, you will receive notifications letting you know when there is new a Red Hat Quay version, updated documentation, or other Red Hat Quay news. Log into the Red Hat Customer Portal with your Red Hat customer account credentials. Select your user name (upper-right corner) to see Red Hat Account and Customer Portal selections: Select Notifications. Your profile activity page appears. Select the Notifications tab. Select Manage Notifications. Select Follow, then choose Products from the drop-down box. From the drop-down box to the Products, search for and select Red Hat Quay: Select the SAVE NOTIFICATION button. Going forward, you will receive notifications when there are changes to the Red Hat Quay product, such as a new release.

Commands:
14.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: openshift_use_nfs Having this Boolean enabled allows installing OpenShift on an NFS share. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, run the following command as root:

Commands:
~]# semanage boolean -l | grep service_name
4.8. Cluster Maintenance In order to perform maintenance on the nodes of your cluster, you may need to stop or move the resources and services running on that cluster. Or you may need to stop the cluster software while leaving the services untouched. Pacemaker provides a variety of methods for performing system maintenance. If you need to stop a node in a cluster while continuing to provide the services running on that cluster on another node, you can put the cluster node in standby mode. A node that is in standby mode is no longer able to host resources. Any resource currently active on the node will be moved to another node, or stopped if no other node is eligible to run the resource. For information on standby mode, see Section 4.4.5, "Standby Mode" . If you need to move an individual resource off the node on which it is currently running without stopping that resource, you can use the pcs resource move command to move the resource to a different node. For information on the pcs resource move command, see Section 8.1, "Manually Moving Resources Around the Cluster" . When you execute the pcs resource move command, this adds a constraint to the resource to prevent it from running on the node on which it is currently running. When you are ready to move the resource back, you can execute the pcs resource clear or the pcs constraint delete command to remove the constraint. This does not necessarily move the resources back to the original node, however, since where the resources can run at that point depends on how you have configured your resources initially. You can relocate a resource to a specified node with the pcs resource relocate run command, as described in Section 8.1.1, "Moving a Resource from its Current Node" . If you need to stop a running resource entirely and prevent the cluster from starting it again, you can use the pcs resource disable command. For information on the pcs resource disable command, see Section 8.4, "Enabling, Disabling, and Banning Cluster Resources" . If you want to prevent Pacemaker from taking any action for a resource (for example, if you want to disable recovery actions while performing maintenance on the resource, or if you need to reload the /etc/sysconfig/pacemaker settings), use the pcs resource unmanage command, as described in Section 8.6, "Managed Resources" . Pacemaker Remote connection resources should never be unmanaged. If you need to put the cluster in a state where no services will be started or stopped, you can set the maintenance-mode cluster property. Putting the cluster into maintenance mode automatically unmanages all resources. For information on setting cluster properties, see Table 12.1, "Cluster Properties" . If you need to perform maintenance on a Pacemaker remote node, you can remove that node from the cluster by disabling the remote node resource, as described in Section 9.4.8, "System Upgrades and pacemaker_remote" .

Commands:
7.3.2.2.2. Optimizing for a large number of files in a single directory Directory block size is fixed for the life of a file system, and cannot be changed except upon initial formatting with mkfs . The minimum directory block is the file system block size, which defaults to MAX (4 KB, file system block size). In general, there is no reason to reduce the directory block size. Because the directory structure is b-tree based, changing the block size affects the amount of directory information that can be retrieved or modified per physical I/O. The larger the directory becomes, the more I/O each operation requires at a given block size. However, when larger directory block sizes are in use, more CPU is consumed by each modification operation compared to the same operation on a file system with a smaller directory block size. This means that for small directory sizes, large directory block sizes will result in lower modification performance. When the directory reaches a size where I/O is the performance-limiting factor, large block size directories perform better. If writing to the file system is more common or more important than reading, such as in a file system that stores backups (where writing backups to the file system happens more frequently than restoring the backups): file systems requiring no more than 1-2 million directory entries (with entry name lengths of 20-40 bytes) perform best with the default configuration of 4 KB file system block size and 4 KB directory block size. file systems requiring between 1-10 million directory entries perform better with a larger block size of 16 KB file systems requiring more than 10 million directory entries perform better with an even larger block size of 64 KB If reading from the file system is more common or more important than writing, for example, in a mirrored download server, the contents of which are viewed more often than modified, the number of entries to which these block sizes apply should be reduced by a factor of ten. For example, the default system and directory block size is best for read-heavy file systems with no more than ten to twenty thousand directory entries.

Commands:
9.2. Red Hat JBoss Data Grid Modules Red Hat JBoss Data Grid directory provider for Hibernate Search are distributed as part of the JBoss Data Grid Library Modules for JBoss EAP 6. Download the files from the Red Hat Customer Portal . Unpack the archive into the modules/ directory in the target JBoss Enterprise Application Platform folder. Add the following entry to the MANIFEST.MF file in the project archive: For more information, see the Generate MANIFEST.MF entries using Maven section in the Red Hat JBoss EAP Development Guide. Report a bug

Commands:
Dependencies: org.hibernate.search.orm services
8.7. Configuring Debug Options You can enable debugging for all daemons in a cluster, or you can enable logging for specific cluster processing. To enable debugging for all daemons, add the following to the /etc/cluster/cluster.conf . By default, logging is directed to the /var/log/cluster/ daemon .log file. To enable debugging for individual cluster processes, add the following lines to the /etc/cluster/cluster.conf file. Per-daemon logging configuration overrides the global settings. For a list of the logging daemons for which you can enable logging as well as the additional logging options you can configure for both global and per-daemon logging, see the cluster.conf (5) man page.

Commands:
<cluster config_version="7" name="rh6cluster"> <logging debug="on"/> </cluster>
<cluster config_version="7" name="rh6cluster"> <logging> <!-- turning on per-subsystem debug logging --> <logging_daemon name="corosync" debug="on" /> <logging_daemon name="fenced" debug="on" /> <logging_daemon name="qdiskd" debug="on" /> <logging_daemon name="rgmanager" debug="on" /> <logging_daemon name="dlm_controld" debug="on" /> <logging_daemon name="gfs_controld" debug="on" /> </logging> </cluster>
Chapter 34. Servers and Services pxlcolor and pxlmono now work correctly Previously, the pxlcolor and the pxlmono drivers in the Ghostscript interpreter did not function correctly. As a consequence, the drivers were likely to ignore a selection of a paper tray for certain printers, therefore only a specific paper tray was selected. This update applies a patch, which fixes the issue. As a result, the selection of different paper trays now works as expected in the described scenario. (BZ#1551782) The nuxwdog service starts correctly when a sub-CA is installed Previously, if a sub-CA was installed, the nuxwdog service did not allocate enough memory. As a consequence, the service failed to start. This update fixes the problem. As a result, nuxwdog starts correctly in the mentioned scenario. (BZ# 1615617 ) Augeas reads /etc/fstab with white spaces more reliably Previously, Augeas was not able to parse lines in the /etc/fstab file if they had white spaces at the beginning. This sometime caused problems in software tools that use Augeas, such as the virt-v2v utility or the Puppet management tool. With this update, the Fstab lens of Augeas correctly ignores white spaces at the beginning of lines. As a result, Augeas now reads /etc/fstab as expected. (BZ# 1544520 )

Commands: