mtpti5iD/redhat-docs_dataset huggingface dataset:
17.4.3. Altering xinetd Configuration Files There are a large assortment of directives available for xinetd protected services. This section highlights some of the more commonly used options. 17.4.3.1. Logging Options The following logging options are available for both /etc/xinetd.conf and the service-specific configuration files within the /etc/xinetd.d/ directory. Below is a list of some of the more commonly used logging options: ATTEMPT - Logs the fact that a failed attempt was made ( log_on_failure ). DURATION - Logs the length of time the service is used by a remote system ( log_on_success ). EXIT - Logs the exit status or termination signal of the service ( log_on_success ). HOST - Logs the remote host's IP address ( log_on_failure and log_on_success ). PID - Logs the process ID of the server receiving the request ( log_on_success ). USERID - Logs the remote user using the method defined in RFC 1413 for all multi-threaded stream services ( log_on_failure and log_on_success ). For a complete list of logging options, refer to the xinetd.conf man page.

Commands:
40.5. Analyzing the Data Periodically, the OProfile daemon, oprofiled , collects the samples and writes them to the /var/lib/oprofile/samples/ directory. Before reading the data, make sure all data has been written to this directory by executing the following command as root: Each sample file name is based on the name of the executable. For example, the samples for the default event on a Pentium III processor for /bin/bash becomes: The following tools are available to profile the sample data once it has been collected: opreport opannotate Use these tools, along with the binaries profiled, to generate reports that can be further analyzed. Warning The executable being profiled must be used with these tools to analyze the data. If it must change after the data is collected, backup the executable used to create the samples as well as the sample files. Samples for each executable are written to a single sample file. Samples from each dynamically linked library are also written to a single sample file. While OProfile is running, if the executable being monitored changes and a sample file for the executable exists, the existing sample file is automatically deleted. Thus, if the existing sample file is needed, it must be backed up, along with the executable used to create it before replacing the executable with a new version. Refer to Section 40.4, "Saving Data" for details on how to backup the sample file. 40.5.1. Using opreport The opreport tool provides an overview of all the executables being profiled. The following is part of an example output: Each executable is listed on its own line. The first column is the number of samples recorded for the executable. The second column is the percentage of samples relative to the total number of samples. The third column is the name of the executable. Refer to the opreport man page for a list of available command line options, such as the -r option used to sort the output from the executable with the smallest number of samples to the one with the largest number of samples.

Commands:
opcontrol --dump
\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000
Profiling through timer interrupt TIMER:0| samples| %| ------------------ 25926 97.5212 no-vmlinux 359 1.3504 pi 65 0.2445 Xorg 62 0.2332 libvte.so.4.4.0 56 0.2106 libc-2.3.4.so 34 0.1279 libglib-2.0.so.0.400.7 19 0.0715 libXft.so.2.1.2 17 0.0639 bash 8 0.0301 ld-2.3.4.so 8 0.0301 libgdk-x11-2.0.so.0.400.13 6 0.0226 libgobject-2.0.so.0.400.7 5 0.0188 oprofiled 4 0.0150 libpthread-2.3.4.so 4 0.0150 libgtk-x11-2.0.so.0.400.13 3 0.0113 libXrender.so.1.2.2 3 0.0113 du 1 0.0038 libcrypto.so.0.9.7a 1 0.0038 libpam.so.0.77 1 0.0038 libtermcap.so.2.0.8 1 0.0038 libX11.so.6.2 1 0.0038 libgthread-2.0.so.0.400.7 1 0.0038 libwnck-1.so.4.9.0
Chapter 3. Managing certificates Red Hat Virtualization Manager uses certificates to enable encrypted communications. These RHV certificates follow a standard 398 day lifetime and must be renewed once per year. Warning Do not let certificates expire. If they expire, the environment becomes non-responsive and recovery is an error-prone and time-consuming process. Starting in RHV 4.4, you will receive warning notifications 120 days before expiration and error notifications 30 days before expiration. Do not ignore these notifications. For information on renewing certificates, see Renewing certificates before they expire in the Administration Guide .

Commands:
Chapter 1. Postinstallation configuration overview After installing OpenShift Container Platform, a cluster administrator can configure and customize the following components: Machine Bare metal Cluster Node Network Storage Users Alerts and notifications 1.1. Post-installation configuration tasks You can perform the post-installation configuration tasks to configure your environment to meet your need. The following lists details these configurations: Configure operating system features : The Machine Config Operator (MCO) manages MachineConfig objects. By using the MCO, you can configure nodes and custom resources. Configure cluster features . You can modify the following features of an OpenShift Container Platform cluster: Image registry Networking configuration Image build behavior Identity provider The etcd configuration Machine set creation to handle the workloads Cloud provider credential management Configuring a private cluster : By default, the installation program provisions OpenShift Container Platform by using a publicly accessible DNS and endpoints. To make your cluster accessible only from within an internal network, configure the following components to make them private: DNS Ingress Controller API server Perform node operations : By default, OpenShift Container Platform uses Red Hat Enterprise Linux CoreOS (RHCOS) compute machines. You can perform the following node operations: Add and remove compute machines. Add and remove taints and tolerations. Configure the maximum number of pods per node. Enable Device Manager. Configure users : OAuth access tokens allow users to authenticate themselves to the API. You can configure OAuth to perform the following tasks: Specify an identity provider Use role-based access control to define and supply permissions to users Install an Operator from OperatorHub Configuring alert notifications : By default, firing alerts are displayed on the Alerting UI of the web console. You can also configure OpenShift Container Platform to send alert notifications to external systems.

Commands:
function::proc_mem_string Name function::proc_mem_string - Human readable string of current proc memory usage Synopsis Arguments None Description Returns a human readable string showing the size, rss, shr, txt and data of the memory used by the current process. For example " size: 301m, rss: 11m, shr: 8m, txt: 52k, data: 2248k " .

Commands:
proc_mem_string:string()
4.177. microcode_ctl 4.177.1. RHEA-2011:1594 - microcode_ctl bug fix and enhancement update An updated microcode_ctl package that fixes a bug and adds various enhancements is now available for Red Hat Enterprise Linux 6. The microcode_ctl package provides microcode updates for Intel and AMD processors. Bug Fix BZ# 684009 A update introduced a memory leak when loading the updated microcode into memory prior to conversion of said microcode into a format suitable for the CPU. This update includes a corrected patch that de-allocates the memory correctly, ensuring memory does not leak. Enhancements BZ# 696582 The Intel CPU microcode file has been updated to version 20110915, which is the most recent version of the microcode available from Intel. BZ# 682668 The AMD CPU microcode file version 20110111 is now included in the package. Note that the system must be rebooted in order for these changes to take effect. Users are advised to upgrade to this updated microcode_ctl package, which fixes this bug and adds these enhancements.

Commands:
Chapter 3. Deprecated features This section describes features that are supported, but have been deprecated from AMQ Broker. OpenWire protocol Starting in 7.9, the OpenWire protocol is a deprecated feature. If you are creating a new AMQ Broker-based system, use one of the other supported protocols. This feature will be removed in a future release. Hawtio dispatch console plugin Starting in 7.3, AMQ Broker no longer ships with the Hawtio dispatch console plugin, dispatch-hawtio-console.war . Previously, the dispatch console was used to manage AMQ Interconnect. However, AMQ Interconnect now uses its own, standalone web console. Network pinger Starting in 7.5, network pinging is a deprecated feature. Network pinging cannot protect a broker cluster from network isolation issues that can lead to irrecoverable message loss. This feature will be removed in a future release. Red Hat continues to support existing AMQ Broker deployments that use network pinging. However, Red Hat no longer recommends use of network pinging in new deployments. For guidance on configuring a broker cluster for high availability and to avoid network isolation issues, see Implementing high availability in Configuring AMQ Broker ..

Commands:
2.3. Creating the Cluster Use the following procedure to create a cluster. To access the High Availability management web interface, point your browser to the link provided by the luci service and log in using the root account on the node hosting luci . Logging in to luci displays the luci Homebase page. To create a cluster, click on Manage Clusters from the menu on the left navigation pane of the Homebase page. This displays the clusters page. From the clusters page, click the Create button. This displays the Create New Cluster screen. Figure 2.1. Clusters menu On the Create New Cluster screen, enter the parameters for the cluster you are creating. The Password field will be the ricci password you defined for the indicated node. For more detailed information about the parameters on this screen and information about verifying the certificate fingerprint of the ricci server, see Section 4.4, "Creating a Cluster" . Figure 2.2. Create New Cluster screen After you have completed entering the parameters for the cluster, click the Create Cluster button. A progress bar is displayed with the cluster is formed. Once cluster creation has completed, luci displays the cluster general properties. Verify the cluster status by running the clustat command on either node of the cluster. If you cannot create the cluster, double check the firewall settings, as described in Section 3.3.3, "Configuring the iptables Firewall to Allow Cluster Components" . If you can create the cluster (there is an /etc/cluster/cluster.conf on each node) but the cluster will not form, you may have multicast issues. To test this, change the transport mode from UDP multicast to UDP unicast, as described in Section 3.12, "UDP Unicast Traffic" . Note, however, that in unicast mode there is a traffic increase compared to multicast mode, which adds to the processing load of the node.

Commands:
clustat Cluster Status for exampleHA @ Thu Sep 29 12:17:39 2011 Member Status: Quorate Member Name ID Status ------ ---- ---- ------ node1.example.com 1 Online, Local node2.example.com 2 Online
B.2. Fencing Configuration You must configure a fencing device for each node in the cluster. For general information about configuring fencing devices, see Chapter 4, Fencing: Configuring STONITH . Note When configuring a fencing device, you should ensure that your fencing device does not share power with the node that it controls. This example uses the APC power switch with a host name of zapc.example.com to fence the nodes, and it uses the fence_apc_snmp fencing agent. Because both nodes will be fenced by the same fencing agent, you can configure both fencing devices as a single resource, using the pcmk_host_map and pcmk_host_list options. You create a fencing device by configuring the device as a stonith resource with the pcs stonith create command. The following command configures a stonith resource named myapc that uses the fence_apc_snmp fencing agent for nodes z1.example.com and z2.example.com . The pcmk_host_map option maps z1.example.com to port 1, and z2.example.com to port 2. The login value and password for the APC device are both apc . By default, this device will use a monitor interval of 60s for each node. Note that you can use an IP address when specifying the host name for the nodes. Note When you create a fence_apc_snmp stonith device, you may see the following warning message, which you can safely ignore: The following command displays the parameters of an existing STONITH device.

Commands:
pcs stonith create myapc fence_apc_snmp ipaddr="zapc.example.com" pcmk_host_map="z1.example.com:1;z2.example.com:2" pcmk_host_check="static-list" pcmk_host_list="z1.example.com,z2.example.com" login="apc" passwd="apc"
Warning: missing required option(s): 'port, action' for resource type: stonith:fence_apc_snmp
pcs stonith show myapc Resource: myapc (class=stonith type=fence_apc_snmp) Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2 pcmk_host_check=static-list pcmk_host_list=z1.example.com,z2.example.com login=apc passwd=apc Operations: monitor interval=60s (myapc-monitor-interval-60s)
2.5. Tuned Tuned is a profile-based system tuning tool that uses the udev device manager to monitor connected devices, and enables both static and dynamic tuning of system settings. Dynamic tuning is an experimental feature and is turned off by default in Red Hat Enterprise Linux 7. Tuned offers predefined profiles to handle common use cases, such as high throughput, low latency, or power saving. You can modify the Tuned rules for each profile and customize how to tune a particular device. For instructions on how to create custom Tuned profiles, from PowerTOP suggestions, see the section called "Using powertop2tuned" . A profile is automatically set as default based on the product in use. You can use the tuned-adm recommend command to determine which profile Red Hat recommends as the most suitable for a particular product. If no recommendation is available, the balanced profile is set. The balanced profile, which is suitable for most workloads, balances energy consumption, performance, and latency. With the balanced profile, finishing a task quickly with the maximum available computing power usually requires less energy than performing the same task over a longer period of time with less computing power. Using the powersave profile can prolong battery life if a laptop is in an idle state, or performing only computationally undemanding operations. For such operations, higher latency in return for lower energy consumption is generally acceptable, or the operations do not need to be finished quickly, for example using IRC, viewing simple web pages, or playing audio and video files. For detailed information on Tuned and power-saving profiles provided with tuned-adm , see the Tuned chapter in the Red Hat Enterprise Linux 7 Performance Tuning Guide . Using powertop2tuned The powertop2tuned utility allows you to create custom Tuned profiles from PowerTOP suggestions. For information on PowerTOP , see Section 2.2, "PowerTOP" . To install the powertop2tuned utility, use: To create a custom profile, use: By default, powertop2tuned creates profiles in the /etc/tuned/ directory, and bases the custom profile on the currently selected Tuned profile. For safety reasons, all PowerTOP tunings are initially disabled in the new profile. To enable tunings, uncomment them in the /etc/tuned/ profile_name /tuned.conf file. You can use the --enable or -e option to generate a new profile that enables most of the tunings suggested by PowerTOP . Certain potentially problematic tunings, such as the USB autosuspend, are disabled by default and need to be uncommented manually. By default, the new profile is not activated. To activate it, use: For a complete list of options that powertop2tuned supports, use:

Commands:
~]# yum install tuned-utils
~]# powertop2tuned new_profile_name
~]# tuned-adm profile new_profile_name
~]USD powertop2tuned --help
Chapter 13. Scoping tokens 13.1. About scoping tokens You can created scoped tokens to delegate some of your permissions to another user or service account. For example, a project administrator might want to delegate the power to create pods. A scoped token is a token that identifies as a given user but is limited to certain actions by its scope. Only a user with the cluster-admin role can create scoped tokens. Scopes are evaluated by converting the set of scopes for a token into a set of PolicyRules . Then, the request is matched against those rules. The request attributes must match at least one of the scope rules to be passed to the "normal" authorizer for further authorization checks. 13.1.1. User scopes User scopes are focused on getting information about a given user. They are intent-based, so the rules are automatically created for you: user:full - Allows full read/write access to the API with all of the user's permissions. user:info - Allows read-only access to information about the user, such as name and groups. user:check-access - Allows access to self-localsubjectaccessreviews and self-subjectaccessreviews . These are the variables where you pass an empty user and groups in your request object. user:list-projects - Allows read-only access to list the projects the user has access to. 13.1.2. Role scope The role scope allows you to have the same level of access as a given role filtered by namespace. role:<cluster-role name>:<namespace or * for all> - Limits the scope to the rules specified by the cluster-role, but only in the specified namespace . Note Caveat: This prevents escalating access. Even if the role allows access to resources like secrets, rolebindings, and roles, this scope will deny access to those resources. This helps prevent unexpected escalations. Many people do not think of a role like edit as being an escalating role, but with access to a secret it is. role:<cluster-role name>:<namespace or * for all>:! - This is similar to the example above, except that including the bang causes this scope to allow escalating access.

Commands:
Chapter 91. KafkaConnectTemplate schema reference Used in: KafkaConnectSpec , KafkaMirrorMaker2Spec Property Property type Description deployment DeploymentTemplate The deployment property has been deprecated. Kafka Connect and MirrorMaker 2 operands do not use Deployment resources anymore. This field will be ignored. Template for Kafka Connect Deployment . podSet ResourceTemplate Template for Kafka Connect StrimziPodSet resource. pod PodTemplate Template for Kafka Connect Pods . apiService InternalServiceTemplate Template for Kafka Connect API Service . headlessService InternalServiceTemplate Template for Kafka Connect headless Service . connectContainer ContainerTemplate Template for the Kafka Connect container. initContainer ContainerTemplate Template for the Kafka init container. podDisruptionBudget PodDisruptionBudgetTemplate Template for Kafka Connect PodDisruptionBudget . serviceAccount ResourceTemplate Template for the Kafka Connect service account. clusterRoleBinding ResourceTemplate Template for the Kafka Connect ClusterRoleBinding. buildPod PodTemplate Template for Kafka Connect Build Pods . The build pod is used only on OpenShift. buildContainer ContainerTemplate Template for the Kafka Connect Build container. The build container is used only on OpenShift. buildConfig BuildConfigTemplate Template for the Kafka Connect BuildConfig used to build new container images. The BuildConfig is used only on OpenShift. buildServiceAccount ResourceTemplate Template for the Kafka Connect Build service account. jmxSecret ResourceTemplate Template for Secret of the Kafka Connect Cluster JMX authentication.

Commands:
5.120. java-1.5.0-ibm 5.120.1. RHSA-2012:1465 - Critical: java-1.5.0-ibm security update Updated java-1.5.0-ibm packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. 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. IBM J2SE version 5.0 includes the IBM Java Runtime Environment and the IBM Java Software Development Kit. Security Fix CVE-2012-1531 , CVE-2012-3143 , CVE-2012-3216 , CVE-2012-4820 , CVE-2012-4822 , CVE-2012-5069 , CVE-2012-5071 , CVE-2012-5073 , CVE-2012-5075 , CVE-2012-5079 , CVE-2012-5081 , CVE-2012-5083 , CVE-2012-5084 , CVE-2012-5089 This update fixes several vulnerabilities in the IBM Java Runtime Environment and the IBM Java Software Development Kit. Detailed vulnerability descriptions are linked from the IBM Security alerts page . All users of java-1.5.0-ibm are advised to upgrade to these updated packages, containing the IBM J2SE 5.0 SR15 release. All running instances of IBM Java must be restarted for this update to take effect. 5.120.2. RHSA-2012:1245 - Critical: java-1.5.0-ibm security update Updated java-1.5.0-ibm packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. 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. IBM J2SE version 5.0 includes the IBM Java Runtime Environment and the IBM Java Software Development Kit. Security Fix CVE-2012-1713 , CVE-2012-1716 , CVE-2012-1717 , CVE-2012-1718 , CVE-2012-1719 , CVE-2012-1725 This update fixes several vulnerabilities in the IBM Java Runtime Environment and the IBM Java Software Development Kit. Detailed vulnerability descriptions are linked from the IBM Security alerts page . All users of java-1.5.0-ibm are advised to upgrade to these updated packages, containing the IBM J2SE 5.0 SR14 release. All running instances of IBM Java must be restarted for this update to take effect.

Commands:
4.3. Configuring Kerberos (with LDAP or NIS) Using authconfig Both LDAP and NIS authentication stores support Kerberos authentication methods. Using Kerberos has a couple of benefits: It uses a security layer for communication while still allowing connections over standard ports. It automatically uses credentials caching with SSSD, which allows offline logins. Note Using Kerberos authentication requires the krb5-libs and krb5-workstation packages. 4.3.1. Configuring Kerberos Authentication from the UI The Kerberos password option from the Authentication Method drop-down menu automatically opens the fields required to connect to the Kerberos realm. Figure 4.2. Kerberos Fields Realm gives the name for the realm for the Kerberos server. The realm is the network that uses Kerberos, composed of one or more key distribution centers (KDC) and a potentially large number of clients. KDCs gives a comma-separated list of servers that issue Kerberos tickets. Admin Servers gives a list of administration servers running the kadmind process in the realm. Optionally, use DNS to resolve server host name and to find additional KDCs within the realm. 4.3.2. Configuring Kerberos Authentication from the Command Line Both LDAP and NIS allow Kerberos authentication to be used in place of their native authentication mechanisms. At a minimum, using Kerberos authentication requires specifying the realm, the KDC, and the administrative server. There are also options to use DNS to resolve client names and to find additional admin servers.

Commands:
authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update