mtpti5iD/redhat-docs_dataset huggingface dataset:
2.10. RHEA-2011:0624 - new package: ipa-pki-theme A new ipa-pki-theme package is now available for Red Hat Enterprise Linux 6. ipa-pki-theme provides IPA theme components for PKI packages. The Certificate System (CS) manages enterprise Public Key Infrastructure (PKI) deployments and requires a theme for the specific type of PKI deployment with which it is used. Previously, no PKI theme existed for Identity, Policy, Audit (IPA) deployments on Red Hat Enterprise Linux 6. This new package makes an IPA theme available for CS, and therefore makes it possible for users of Red Hat Enterprise Linux 6 to use CS to manage IPA deployments. Important -- this theme is mutually exclusive with the PKI themes for other types of PKI deployments, such as dogtag-pki-theme for Dogtag Certificate System deployments and redhat-pki-theme for Red Hat Certificate System deployments. (BZ# 643543 ) Users who want to use CS to manage IPA deployments are advised to install this new package.

Commands:
Chapter 3. Core Infrastructure and Mechanics Important To use the cpupower command featured in this chapter, ensure you have the cpupowerutils package installed. 3.1. CPU Idle States CPUs with the x86 architecture support various states in which parts of the CPU are deactivated or run at lower performance settings. These states, known as C-states , allow systems to save power by partially deactivating CPUs that are not in use. C-states are numbered from C0 upwards, with higher numbers representing decreased CPU functionality and greater power saving. C-States of a given number are broadly similar across processors, although the exact details of the specific feature sets of the state may vary between processor families. C-States 0-3 are defined as follows: C0 the operating or running state. In this state, the CPU is working and not idle at all. C1, Halt a state where the processor is not executing any instructions but is typically not in a lower power state. The CPU can continue processing with practically no delay. All processors offering C-States need to support this state. Pentium 4 processors support an enhanced C1 state called C1E that actually is a state for lower power consumption. C2, Stop-Clock a state where the clock is frozen for this processor but it keeps the complete state for its registers and caches, so after starting the clock again it can immediately start processing again. This is an optional state. C3, Sleep a state where the processor really goes to sleep and does not need to keep its cache up to date. Waking up from this state takes considerably longer than from C2 due to this. Again this is an optional state. To view available idle states and other statistics for the CPUidle driver, run the following command: Recent Intel CPUs with the "Nehalem" microarchitecture feature a new C-State, C6, which can reduce the voltage supply of a CPU to zero, but typically reduces power consumption by between 80% and 90%. The kernel in Red Hat Enterprise Linux 6 includes optimizations for this new C-State.

Commands:
cpupower idle-info
6.7. Using nftables to limit the amount of connections You can use nftables to limit the number of connections or to block IP addresses that attempt to establish a given amount of connections to prevent them from using too many system resources. 6.7.1. Limiting the number of connections using nftables The ct count parameter of the nft utility enables administrators to limit the number of connections. The procedure describes a basic example of how to limit incoming connections. Prerequisites The base example_chain in example_table exists. Procedure 6.19. Limiting the number of connections using nftables Add a rule that allows only two simultaneous connections to the SSH port ( 22 ) from an IPv4 address and rejects all further connections from the same IP: Optionally, display the meter created in the step: The elements entry displays addresses that currently match the rule. In this example, elements lists IP addresses that have active connections to the SSH port. Note that the output does not display the number of active connections or if connections were rejected. 6.7.2. Blocking IP addresses that attempt more than ten new incoming TCP connections within one minute The nftables framework enables administrators to dynamically update sets. This section explains how you use this feature to temporarily block hosts that are establishing more than ten IPv4 TCP connections within one minute. After five minutes, nftables automatically removes the IP address from the deny list. Procedure 6.20. Blocking IP addresses that attempt more than ten new incoming TCP connections within one minute Create the filter table with the ip address family: Add the input chain to the filter table: Add a set named denylist to the filter table: This command creates a dynamic set for IPv4 addresses. The timeout 5m parameter defines that nftables automatically removes entries after 5 minutes from the set. Add a rule that automatically adds the source IP address of hosts that attempt to establish more than ten new TCP connections within one minute to the denylist set: Add a rule that drops all connections from IP addresses in the denylist set: 6.7.3. Additional resources For more information, see Section 6.4.2, "Using named sets in nftables"

Commands:
nft add rule ip example_table example_chain tcp dport ssh meter example_meter { ip saddr ct count over 2 } counter reject
nft list meter ip example_table example_meter table ip example_table { meter example_meter { type ipv4_addr size 65535 elements = { 192.0.2.1 : ct count over 2 , 192.0.2.2 : ct count over 2 } } }
nft add table ip filter
nft add chain ip filter input { type filter hook input priority 0 \; }
nft add set ip filter denylist { type ipv4_addr \; flags dynamic, timeout \; timeout 5m \; }
nft add rule ip filter input ip protocol tcp ct state new, untracked limit rate over 10/minute add @denylist { ip saddr }
nft add rule ip filter input ip saddr @denylist drop
Chapter 10. Clair security scans Clair security scanner is not enabled for Red Hat Quay by default. To enable Clair, see Clair on Red Hat Quay . Clair security scans can be viewed on the UI, or by the API. Procedure Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan. To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view. Click a relevant link under See Child Manifests , for example, 1 Unknown to be redirected to the Security Scanner page. The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available. Note Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user. Red Hat Quay superusers do not act on found vulnerabilities. 10.1. Viewing Clair security scans by using the UI You can view Clair security scans on the UI. Procedure Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan. To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view. Click a relevant link under See Child Manifests , for example, 1 Unknown to be redirected to the Security Scanner page. The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available. Note Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user. Red Hat Quay superusers do not act on found vulnerabilities. 10.2. View Clair security scans by using the API You can view Clair security scans by using the API. Procedure Use the GET /api/v1/repository/{repository}/manifest/{manifestref}/security endpoint to retrieve security information about a specific manifest in a repository. For example: USD curl -X GET \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ "https://quay-server.example.com/api/v1/repository/<namespace>/<repository>/manifest/<manifest_digest>/security?vulnerabilities=<true_or_false>" Example output {"status": "queued", "data": null}

Commands:
curl -X GET -H "Authorization: Bearer <bearer_token>" -H "Accept: application/json" "https://quay-server.example.com/api/v1/repository/<namespace>/<repository>/manifest/<manifest_digest>/security?vulnerabilities=<true_or_false>"
status: queued
Chapter 3. Data Grid on OpenShift 3.1. Data Grid 8.5 images Data Grid 8.5 includes two container images, the Data Grid Operator image and Data Grid Server image. Data Grid images are hosted on the Red Hat Container Registry, where you can find health indexes for the images along with information about each tagged version. Custom Data Grid Deployments Red Hat does not support customization of any 8.5 images from the Red Hat Container Registry through the Source-to-Image (S2I) process or ConfigMap API. As a result it is not possible to use custom: Discovery protocols JGroups SYM_ENCRYPT or ASYM_ENCRYPT encryption mechanisms Additional resources Data Grid Container Images 3.2. Embedded caches on OpenShift Using embedded Data Grid caches in applications running on OpenShift, which was referred to as Library Mode in releases, is intended for specific uses only: Using local or distributed caching in custom Java applications to retain full control of the cache lifecycle. Additionally, when using features that are available only with embedded Data Grid such as distributed streams. Reducing network latency to improve the speed of cache operations. The Hot Rod protocol provides near-cache capabilities that achieve equivalent performance to a standard client-server architecture. Requirements Embedding Data Grid in applications running on OpenShift requires you to use a discovery mechanism so Data Grid nodes can form clusters to replicate and distribute data. Red Hat supports only DNS_PING as the cluster discovery mechanism. DNS_PING exposes a port named ping that Data Grid nodes use to perform discovery and join clusters. TCP is the only supported protocol for the ping port, as in the following example for a pod on OpenShift: spec: ... ports: - name: ping port: 8888 protocol: TCP targetPort: 8888 Limitations Embedding Data Grid in applications running on OpenShift also has some specific limitations: Persistent cache stores are not currently supported. UDP is not supported with embedded Data Grid. Custom caching services Red Hat highly discourages embedding Data Grid to build custom caching servers to handle remote client requests. To benefit from regular, automatic updates with performance improvements and fix security issues, you should create Data Grid clusters with the Data Grid Operator instead. Additional resources Embedding Data Grid in Java Applications

Commands:
spec: ports: - name: ping port: 8888 protocol: TCP targetPort: 8888
13.12. Installation Source To specify a file or a location to install Red Hat Enterprise Linux from, select Installation Source from the Installation Summary screen. On this screen, you can choose between locally available installation media, such as a DVD or an ISO file, or a network location. Figure 13.9. Installation Source Screen Select one of the following options: Auto-detected installation media If you started the installation using the full installation DVD or USB drive, the installation program will detect it and display basic information under this option. Click the Verify button to ensure that the media is suitable for installation. This integrity test is the same as the one performed if you selected Test this media & Install Red Hat Enterprise Linux in the boot menu, or if you used the rd.live.check boot option. ISO file This option will appear if the installation program detected a partitioned hard drive with mountable file systems. Select this option, click the Choose an ISO button, and browse to the installation ISO file's location on your system. Then click Verify to ensure that the file is suitable for installation. On the network To specify a network location, select this option and choose from the following options in the drop-down menu: http:// https:// ftp:// nfs Using your selection as the start of the location URL, type the rest into the address box. If you choose NFS, another box will appear for you to specify any NFS mount options. Important When selecting an NFS-based installation source, you must specify the address with a colon ( : ) character separating the host name from the path. For example: To configure a proxy for an HTTP or HTTPS source, click the Proxy setup button. Check Enable HTTP proxy and type the URL into the Proxy URL box. If your proxy requires authentication, check Use Authentication and enter a user name and password. Click Add . If your HTTP or HTTPS URL refers to a repository mirror list, mark the check box under the input field. You can also specify additional repositories to gain access to more installation environments and software add-ons. See Section 13.14, "Software Selection" for more information. To add a repository, click the + button. To delete a repository, click the - button. Click the arrow icon to revert to the list of repositories, that is, to replace current entries with those that were present at the time you entered the Installation Source screen. To activate or deactivate a repository, click the check box in the Enabled column at each entry in the list. In the right part of the form, you can name your additional repository and configure it the same way as the primary repository on the network. Once you have selected your installation source, click Done to return to the Installation Summary screen.

Commands:
server.example.com : /path/to/directory
20.16.5. Device Leases When using a lock manager, you have the option to record device leases against a guest virtual machine. The lock manager will ensure that the guest virtual machine does not start unless the leases can be acquired. When configured using conventional management tools, the following section of the domain xml is effected: ... <devices> ... <lease> <lockspace>somearea</lockspace> <key>somekey</key> <target path='/some/lease/path' offset='1024'/> </lease> ... </devices> ... Figure 20.27. Devices - device leases The lease section can have the following arguments: lockspace - an arbitrary string that identifies lockspace within which the key is held. Lock managers may impose extra restrictions on the format, or length of the lockspace name. key - an arbitrary string, that uniquely identies the lease to be acquired. Lock managers may impose extra restrictions on the format, or length of the key. target - the fully qualified path of the file associated with the lockspace. The offset specifies where the lease is stored within the file. If the lock manager does not require a offset, set this value to 0 .

Commands:
<devices> <lease> <lockspace>somearea</lockspace> <key>somekey</key> <target path='/some/lease/path' offset='1024'/> </lease> </devices>
Chapter 64. Interceptor Providers Overview Interceptor providers are objects in the Apache CXF runtime that have interceptor chains attached to them. They all implement the org.apache.cxf.interceptor.InterceptorProvider interface. Developers can attach their own interceptors to any interceptor provider. List of providers The following objects are interceptor providers: AddressingPolicyInterceptorProvider ClientFactoryBean ClientImpl ClientProxyFactoryBean CorbaBinding CXFBusImpl org.apache.cxf.jaxws.EndpointImpl org.apache.cxf.endpoint.EndpointImpl ExtensionManagerBus JAXRSClientFactoryBean JAXRSServerFactoryBean JAXRSServiceImpl JaxWsClientEndpointImpl JaxWsClientFactoryBean JaxWsEndpointImpl JaxWsProxyFactoryBean JaxWsServerFactoryBean JaxwsServiceBuilder MTOMPolicyInterceptorProvider NoOpPolicyInterceptorProvider ObjectBinding RMPolicyInterceptorProvider ServerFactoryBean ServiceImpl SimpleServiceBuilder SoapBinding WrappedEndpoint WrappedService XMLBinding

Commands:
A.2. System Requirements The biosdevname program uses information from the system's BIOS, specifically the type 9 (System Slot) and type 41 (Onboard Devices Extended Information) fields contained within the SMBIOS. If the system's BIOS does not have SMBIOS version 2.6 or higher and this data, the new naming convention will not be used. Most older hardware does not support this feature because of a lack of BIOSes with the correct SMBIOS version and field information. For BIOS or SMBIOS version information, contact your hardware vendor. For this feature to take effect, the biosdevname package must also be installed. The biosdevname package is part of the base package group in Red Hat Enterprise Linux 6. All install options, except for Minimal Install , include this package. It is not installed on upgrades of Red Hat Enterprise Linux 6.0 to RHEL 6.1.

Commands:
10.3. Severity and Impact Rating of JBoss Security Patches To communicate the risk of each JBoss security flaw, Red Hat uses a four-point severity scale of low, moderate, important and critical, in addition to Common Vulnerability Scoring System (CVSS) version 2 base scores which can be used to identify the impact of the flaw. Table 10.1. Severity Ratings of JBoss Security Patches Severity Description Critical This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as critical impact. Important This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service. Moderate This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a critical impact or important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations. Low This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. The impact component of a CVSS v2 score is based on a combined assessment of three potential impacts: Confidentiality (C), Integrity (I) and Availability (A). Each of these can be rated as None (N), Partial (P) or Complete (C). Because the JBoss server process runs as an unprivileged user and is isolated from the host operating system, JBoss security flaws are only rated as having impacts of either None (N) or Partial (P). Example 10.1. CVSS v2 Impact Score The example below shows a CVSS v2 impact score, where exploiting the flaw would have no impact on system confidentiality, partial impact on system integrity and complete impact on system availability (that is, the system would become completely unavailable for any use, for example, via a kernel crash). Combined with the severity rating and the CVSS score, organizations can make informed decisions on the risk each issue places on their unique environment and schedule upgrades accordingly. For more information about CVSS2, please see: CVSS2 Guide .

Commands:
C:N/I:P/A:C
8.68. icedtea-web 8.68.1. RHBA-2013:1584 - icedtea-web bug fix and enhancement update Updated icedtea-web packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The IcedTea-Web project provides a Java web browser plug-in and an implementation of Java Web Start, which is based on the Netx project. It also contains a configuration tool for managing deployment settings for the plug-in and Web Start implementations. Note The icedtea-web packages have been upgraded to upstream version 1.4.1, which provides a number of bug fixes and enhancements over the version including support for updated versions of OpenJDK6 and OpenJDK7. (BZ# 916161 , BZ# 975098 ) Users of icedtea-web are advised to upgrade to these updated packages, which fix these bugs and add these enhancements

Commands:
11.3. Configuring ACME Issuer This section describes how to configure an issuer for PKI ACME Responder. The configuration for ACME Issuer is located at /etc/pki/pki-tomcat/acme/issuer.conf . You can configure the issuer via command-line using the pki-server acme-issuer-mod command. Invoking this command without any parameters launches an interactive mode, for example: Invoking the command with the --type parameter creates a new configuration based on the specified type. Invoking the command with other parameters updates the specified parameters. 11.3.1. Configuring PKI Issuer You can configure PKI ACME Responder to issue certificates using PKI Issuer . A sample configuration is available at /usr/share/pki/acme/issuer/pki/issuer.conf . To configure a PKI issuer, copy this sample issuer.conf into the /etc/pki/pki-tomcat/acme directory or execute the following command to customize some of the parameters: Customize the configuration as needed. The issuer.conf file should look like the following: The url parameter specifies the PKI issuer location. The profile parameter specifies the certificate profile to use. To use client certificate authentication, specify the client certificate nickname in the nickname parameter. To use basic authentication, specify the username in the username parameter as well as the password in the password parameter.

Commands:
pki-server acme-issuer-mod The current value is displayed in the square brackets. To keep the current value, simply press Enter. To change the current value, enter the new value. To remove the current value, enter a blank space. Enter the type of the certificate issuer. Available types: nss, pki. Issuer Type: pki Enter the location of the PKI server (e.g. https://localhost.localdomain:8443). Server URL [https://localhost.localdomain:8443]: Enter the certificate nickname for client authentication. This might be the CA agent certificate. Enter blank to use basic authentication. Client Certificate: Enter the username of the CA agent for basic authentication. Enter blank if a CA agent certificate is used for client authentication. Agent Username [caadmin]: Enter the CA agent password for basic authentication. Enter blank if the password is already stored in a separate property file or if a CA agent certificate is used for client authentication. Agent Password [********]: Enter the certificate profile for issuing ACME certificates (e.g. acmeServerCert). Certificate Profile [acmeServerCert]:
pki-server acme-issuer-mod --type pki -Dusername=caadmin -Dpassword=Secret.123
class=org.example.acme.issuer.PKIIssuer url=https://localhost.localdomain:8443 profile=acmeServerCert username=caadmin password=Secret.123