mtpti5iD/redhat-docs_dataset huggingface dataset:
4.4. Boosting Lucene uses boosting to attach more importance to specific fields or documents over others. Lucene differentiates between index and search-time boosting. Report a bug 4.4.1. Static Index Time Boosting The @Boost annotation is used to define a static boost value for an indexed class or property. This annotation can be used within @Field , or can be specified directly on the method or class level. In the following example: the probability of Essay reaching the top of the search list will be multiplied by 1.7. @Field.boost and @Boost on a property are cumulative, therefore the summary field will be 3.0 (2 x 1.5), and more important than the ISBN field. The text field is 1.2 times more important than the ISBN field. Example 4.7. Different ways of using @Boost Report a bug 4.4.2. Dynamic Index Time Boosting The @Boost annotation defines a static boost factor that is independent of the state of the indexed entity at runtime. However, in some cases the boost factor may depend on the actual state of the entity. In this case, use the @DynamicBoost annotation together with an accompanying custom BoostStrategy . @Boost and @DynamicBoost annotations can both be used in relation to an entity, and all defined boost factors are cumulative. The @DynamicBoost can be placed at either class or field level. In the following example, a dynamic boost is defined on class level specifying VIPBoostStrategy as implementation of the BoostStrategy interface used at indexing time. Depending on the annotation placement, either the whole entity is passed to the defineBoost method or only the annotated field/property value. The passed object must be cast to the correct type. Example 4.8. Dynamic boost example In the provided example all indexed values of a VIP would be twice the importance of the values of a non-VIP. Note The specified BoostStrategy implementation must define a public no argument constructor. Report a bug

Commands:
@Indexed @Boost(1.7f) public class Essay { @Field(name = "Abstract", store=Store.YES, boost = @Boost(2f)) @Boost(1.5f) public String getSummary() { return summary; } @Field(boost = @Boost(1.2f)) public String getText() { return text; } @Field public String getISBN() { return isbn; } }
public enum PersonType { NORMAL, VIP } @Indexed @DynamicBoost(impl = VIPBoostStrategy.class) public class Person { private PersonType type; } public class VIPBoostStrategy implements BoostStrategy { public float defineBoost(Object value) { Person person = (Person) value; if (person.getType().equals(PersonType.VIP)) { return 2.0f; } else { return 1.0f; } } }
27.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with Red Hat Gluster Storage. Different types allow you to configure flexible access: Process types glusterd_t The Gluster processes are associated with the glusterd_t SELinux type. Types on executables glusterd_initrc_exec_t The SELinux-specific script type context for the Gluster init script files. glusterd_exec_t The SELinux-specific executable type context for the Gluster executable files. Port Types gluster_port_t This type is defined for glusterd . By default, glusterd uses 204007-24027, and 38465-38469 TCP ports. File Contexts glusterd_brick_t This type is used for files threated as glusterd brick data. glusterd_conf_t This type is associated with the glusterd configuration data, usually stored in the /etc directory. glusterd_log_t Files with this type are treated as glusterd log data, usually stored under the /var/log/ directory. glusterd_tmp_t This type is used for storing the glusterd temporary files in the /tmp directory. glusterd_var_lib_t This type allows storing the glusterd files in the /var/lib/ directory. glusterd_var_run_t This type allows storing the glusterd files in the /run/ or /var/run/ directory.

Commands:
5.59. elinks 5.59.1. RHSA-2013:0250 - Moderate: elinks security update An updated elinks package that fixes one security issue is now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. ELinks is a text-based web browser. ELinks does not display any images, but it does support frames, tables, and most other HTML tags. Security Fix CVE-2012-4545 It was found that ELinks performed client credentials delegation during the client-to-server GSS security mechanisms negotiation. A rogue server could use this flaw to obtain the client's credentials and impersonate that client to other servers that are using GSSAPI. This issue was discovered by Marko Myllynen of Red Hat. All ELinks users are advised to upgrade to this updated package, which contains a backported patch to resolve the issue.

Commands:
Appendix A. Revision History Revision History Revision 6-9.2 Mon 3 April 2017 Robert Kratky Version for 6.9 GA release Revision 2-32 Sun Jun 26 2016 Mirek Jahoda Async release with fixes Revision 2-30 Wed May 3 2016 Robert Kratky Version for 6.8 GA release Revision 2-23 Tue Feb 17 2013 Jacquelynn East Version for 6.4 GA release Revision 2-22 Tue May 17 2011 Jacquelynn East BZ#598956 Revision 2-18 Mon May 16 2011 Jacquelynn East BZ#698956 Revision 2-15 Mon Nov 29 2010 Michael Hideo-Smith Initialized Revision 2-14 Thu Nov 18 2010 Jacquelynn East Minor edits Revision 2-13 Thu Nov 18 2010 Jacquelynn East Minor edits

Commands:
Chapter 3. Enabling Linux control group version 1 (cgroup v1) As of OpenShift Container Platform 4.14, OpenShift Container Platform uses Linux control group version 2 (cgroup v2) in your cluster. If you are using cgroup v1 on OpenShift Container Platform 4.13 or earlier, migrating to OpenShift Container Platform 4.18 will not automatically update your cgroup configuration to version 2. A fresh installation of OpenShift Container Platform 4.14 or later will use cgroup v2 by default. However, you can enable Linux control group version 1 (cgroup v1) upon installation. Enabling cgroup v1 in OpenShift Container Platform disables all cgroup v2 controllers and hierarchies in your cluster. Important cgroup v1 is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality that has been deprecated or removed within OpenShift Container Platform, refer to the Deprecated and removed features section of the OpenShift Container Platform release notes. cgroup v2 is the current version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as Pressure Stall Information , and enhanced resource management and isolation. However, cgroup v2 has different CPU, memory, and I/O management characteristics than cgroup v1. Therefore, some workloads might experience slight differences in memory or CPU usage on clusters that run cgroup v2. You can switch between cgroup v1 and cgroup v2, as needed, by editing the node.config object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section. 3.1. Enabling Linux cgroup v1 during installation You can enable Linux control group version 1 (cgroup v1) when you install a cluster by creating installation manifests. Important cgroup v1 is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality that has been deprecated or removed within OpenShift Container Platform, refer to the Deprecated and removed features section of the OpenShift Container Platform release notes. Procedure Create or edit the node.config object to specify the v1 cgroup: apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2" Proceed with the installation as usual. Additional resources OpenShift Container Platform installation overview Configuring the Linux cgroup on your nodes

Commands:
apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2"
Chapter 4. Entry Point A user begins interacting with the API through a GET request on the entry point URI consisting of a host and base . Example 4.1. Accessing the API Entry Point If the host is www.example.com and the base is /ovirt-engine/api , the entry point appears with the following request: Note For simplicity, all other examples omit the Host: and Authorization: request headers and assume the base is the default /ovirt-engine/api path. This base path differs depending on your implementation. 4.1. Product Information The entry point contains a product_info element to help an API user determine the legitimacy of the Red Hat Virtualization environment. This includes the name of the product, the vendor and the version . Example 4.2. Verify a genuine Red Hat Virtualization environment The follow elements identify a genuine Red Hat Virtualization 4.0 environment:

Commands:
GET /ovirt-engine/api HTTP/1.1 Accept: application/xml Host: www.example.com Authorization: [base64 encoded credentials] HTTP/1.1 200 OK Content-Type: application/xml <api> <link rel="hosts" href="/ovirt-engine/api/hosts"/> <link rel="vms" href="/ovirt-engine/api/vms"/> <product_info> <name>Red Hat Virtualization</name> <vendor>Red Hat</vendor> <version revision="0" build="0" minor="0" major="4"/> </product_info> <special_objects> <link rel="templates/blank" href="..."/> <link rel="tags/root" href="..."/> </special_objects> <summary> <vms> <total>10</total> <active>3</active> </vms> <hosts> <total>2</total> <active>2</active> </hosts> <users> <total>8</total> <active>2</active> </users> <storage_domains> <total>2</total> <active>2</active> </storage_domains> </summary> </ovirt-engine/api>
<api> <product_info> <name>Red Hat Virtualization</name> <vendor>Red Hat</vendor> <version> <build>2</build> <full_version>4.0.2.3-0.1.el7ev</full_version> <major>4</major> <minor>0</minor> <revision>0</revision> </version> </product_info> </ovirt-engine/api>
25.3.3. Mapping Subchannels and Network Device Names The DEVICE= option in the ifcfg file does not determine the mapping of subchannels to network device names. Instead, the udev rules file /etc/udev/rules.d/70-persistent-net.rules determines which network device channel gets which network device name. When configuring a new network device on System z, the system automatically adds a new rule to that file and assigns the unused device name. You can then edit the values assigned to the NAME= variable for each device. Example content of /etc/udev/rules.d/70-persistent-net.rules :

Commands:
This file was automatically generated by the /lib/udev/write_net_rules program run by the persistent-net-generator.rules rules file. # You can modify it,as long as you keep each rule on a single line. S/390 qeth device at 0.0.f5f0 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.f5f0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" S/390 ctcm device at 0.0.1000 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ctcm", KERNELS=="0.0.1000", ATTR{type}=="256", KERNEL=="ctc*", NAME="ctc0" S/390 qeth device at 0.0.8024 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8024", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi0" S/390 qeth device at 0.0.8124 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8124", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi1" S/390 qeth device at 0.0.1017 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1017", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" S/390 qeth device at 0.0.8324 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8324", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi3" S/390 qeth device at 0.0.8224 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.8224", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi2" S/390 qeth device at 0.0.1010 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1010", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" S/390 lcs device at 0.0.1240 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="lcs", KERNELS=="0.0.1240", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" S/390 qeth device at 0.0.1013 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.1013", ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi4"
20.6. Understanding Password Expiration Controls When a user authenticates to Directory Server using a valid password, and if the password is expired, will expire soon, or needs to be reset, the server sends the following LDAP controls back to the client: Expired control ( 2.16.840.1.113730.3.4.4 ): Indicates that the password is expired. Directory Server sends this control in the following situations: The password is expired, and grace logins have been exhausted. The server rejects the bind with an Error 49 message. The password is expired, but grace logins are still available. The bind will be allowed. If passwordMustChange is enabled in the cn=config entry, and a user needs to reset the password after an administrator changed it. The bind is allowed, but any subsequent operation, other than changing the password, results in an Error 53 message. Expiring control ( 2.16.840.1.113730.3.4.5 ): Indicates that the password will expire soon. Directory Server sends this control in the following situations: The password will expire within the password warning period set in the passwordWarning attribute in the cn=config entry. If the password policy configuration option is enabled in the passwordSendExpiringTime attribute in the cn=config entry, the expiring control is always returned, regardless of whether the password is within the warning period. Bind response control ( 1.3.6.1.4.1.42.2.27.8.5.1 ): The control contains detailed information about the state of the password that is about to expire or will expire soon. Note Directory Server only sends the bind response control if the client requested it. For example, if you use ldapsearch , you must pass the -e ppolicy parameter to the command to request the bind response control. Example 20.1. Requesting the Bind Response Control in a Query If you request the bind response control, for example by passing the -e ppolicy parameter to the ldapsearch command, the server returns detailed information about account expiration. For example:

Commands:
ldapsearch -D "uid= user_name ,dc=example,dc=com" -xLLL -W -b "dc=example,dc=com" -e ppolicy ldap_bind: Success (0); Password expired (Password expired, 1 grace logins remain)
12.5.4. Creating an iSCSI-based Storage Pool with virsh Use pool-define-as to define the pool from the command line Storage pool definitions can be created with the virsh command line tool. Creating storage pools with virsh is useful for systems administrators using scripts to create multiple storage pools. The virsh pool-define-as command has several parameters which are accepted in the following format: The parameters are explained as follows: type defines this pool as a particular type, iscsi for example name must be unique and sets the name for the storage pool source-host and source-path the host name and iSCSI IQN respectively source-dev and source-name these parameters are not required for iSCSI-based pools, use a - character to leave the field blank. target defines the location for mounting the iSCSI device on the host physical machine The example below creates the same iSCSI-based storage pool as the step. Verify the storage pool is listed Verify the storage pool object is created correctly and the state reports as inactive . Start the storage pool Use the virsh command pool-start for this. pool-start enables a directory storage pool, allowing it to be used for volumes and guest virtual machines. Turn on autostart Turn on autostart for the storage pool. Autostart configures the libvirtd service to start the storage pool when the service starts. Verify that the iscsirhel6guest pool has autostart set: Verify the storage pool configuration Verify the storage pool was created correctly, the sizes reported correctly, and the state reports as running . An iSCSI-based storage pool is now available.

Commands:
virsh pool-define-as name type source-host source-path source-dev source-name target
virsh pool-define-as --name scsirhel6guest --type iscsi --source-host server1.example.com --source-dev iqn.2010-05.com.example.server1:iscsirhel6guest --target /dev/disk/by-path Pool iscsirhel6guest defined
virsh pool-list --all Name State Autostart ----------------------------------------- default active yes iscsirhel6guest inactive no
virsh pool-start guest_images_disk Pool guest_images_disk started virsh pool-list --all Name State Autostart ----------------------------------------- default active yes iscsirhel6guest active no
virsh pool-autostart iscsirhel6guest Pool iscsirhel6guest marked as autostarted
virsh pool-list --all Name State Autostart ----------------------------------------- default active yes iscsirhel6guest active yes
virsh pool-info iscsirhel6guest Name: iscsirhel6guest UUID: afcc5367-6770-e151-bcb3-847bc36c5e28 State: running Persistent: unknown Autostart: yes Capacity: 100.31 GB Allocation: 0.00 Available: 100.31 GB
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) IBM Z clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. Note Only internal OpenShift Data Foundation clusters are supported on IBM Z. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, follow the appropriate deployment process for your environment: Internal Attached Devices mode Deploy using local storage devices

Commands:
2.14. Additional Resources The ultimate documentation for cgroup commands is available on the manual pages provided with the libcgroup package. The section numbers are specified in the list of man pages below. The libcgroup Man Pages man 1 cgclassify - the cgclassify command is used to move running tasks to one or more cgroups. man 1 cgclear - the cgclear command is used to delete all cgroups in a hierarchy. man 5 cgconfig.conf - cgroups are defined in the cgconfig.conf file. man 8 cgconfigparser - the cgconfigparser command parses the cgconfig.conf file and mounts hierarchies. man 1 cgcreate - the cgcreate command creates new cgroups in hierarchies. man 1 cgdelete - the cgdelete command removes specified cgroups. man 1 cgexec - the cgexec command runs tasks in specified cgroups. man 1 cgget - the cgget command displays cgroup parameters. man 1 cgsnapshot - the cgsnapshot command generates a configuration file from existing subsystems. man 5 cgred.conf - cgred.conf is the configuration file for the cgred service. man 5 cgrules.conf - cgrules.conf contains the rules used for determining when tasks belong to certain cgroups. man 8 cgrulesengd - the cgrulesengd service distributes tasks to cgroups. man 1 cgset - the cgset command sets parameters for a cgroup. man 1 lscgroup - the lscgroup command lists the cgroups in a hierarchy. man 1 lssubsys - the lssubsys command lists the hierarchies containing the specified subsystems.

Commands:
probe::nfs.aop.writepages Name probe::nfs.aop.writepages - NFS client writing several dirty pages to the NFS server Synopsis nfs.aop.writepages Values for_reclaim a flag of writeback_control, indicates if it's invoked from the page allocator wpages write size (in pages) nr_to_write number of pages attempted to be written in this execution for_kupdate a flag of writeback_control, indicates if it's a kupdate writeback ino inode number size number of pages attempted to be written in this execution wsize write size dev device identifier Description The priority of wb is decided by the flags for_reclaim and for_kupdate .

Commands:
Chapter 17. Jakarta Security 17.1. About Jakarta Security Jakarta Security defines plug-in interfaces for authentication and identity stores, and a new injectable-type SecurityContext interface that provides an access point for programmatic security. For details about the specifications, see Jakarta Security Specification . 17.2. Configure Jakarta Security Using Elytron Enabling Jakarta Security Using the elytron Subsystem The SecurityContext interface defined in Jakarta Security uses the Jakarta Authorization policy provider to access the current authenticated identity. To enable your deployments to use the SecurityContext interface, you must configure the elytron subsystem to manage the Jakarta Authorization configuration and define a default Jakarta Authorization policy provider. Disable Jakarta Authorization in the legacy security subsystem. Skip this step if Jakarta Authorization is already configured to be managed by Elytron. Define a Jakarta Authorization policy provider in the etlyron subsystem and reload the server. Enabling Jakarta Security for Web Applications To enable Jakarta Security for a web application, the web application needs to be associated with either an Elytron http-authentication-factory or a security-domain . This installs the Elytron security handlers and activates the Elytron security framework for the deployment. The minimal steps to enable Jakarta Security are: Leave the default-security-domain attribute on the undertow subsystem undefined so that it defaults to other . Add an application-security-domain mapping from other to an Elytron security domain: When integrated-jaspi is set to false , ad-hoc identities are created dynamically. Jakarta Security is built on Jakarta Authentication. For information about configuring Jakarta Authentication, see Configure Jakarta Authentication Security Using Elytron .

Commands:
/subsystem=security:write-attribute(name=initialize-jacc, value=false)
/subsystem=elytron/policy=jacc:add(jacc-policy={}) reload
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain, integrated-jaspi=false)