mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 16. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premises. 16.1. Red Hat Marketplace features Cluster administrators can use the Red Hat Marketplace to manage software on OpenShift Container Platform, give developers self-service access to deploy application instances, and correlate application usage against a quota. 16.1.1. Connect OpenShift Container Platform clusters to the Marketplace Cluster administrators can install a common set of applications on OpenShift Container Platform clusters that connect to the Marketplace. They can also use the Marketplace to track cluster usage against subscriptions or quotas. Users that they add by using the Marketplace have their product usage tracked and billed to their organization. During the cluster connection process , a Marketplace Operator is installed that updates the image registry secret, manages the catalog, and reports application usage. 16.1.2. Install applications Cluster administrators can install Marketplace applications from within OperatorHub in OpenShift Container Platform, or from the Marketplace web application . You can access installed applications from the web console by clicking Operators > Installed Operators . 16.1.3. Deploy applications from different perspectives You can deploy Marketplace applications from the web console's Administrator and Developer perspectives. The Developer perspective Developers can access newly installed capabilities by using the Developer perspective. For example, after a database Operator is installed, a developer can create an instance from the catalog within their project. Database usage is aggregated and reported to the cluster administrator. This perspective does not include Operator installation and application usage tracking. The Administrator perspective Cluster administrators can access Operator installation and application usage information from the Administrator perspective. They can also launch application instances by browsing custom resource definitions (CRDs) in the Installed Operators list.

Commands:
Chapter 10. Using Pluggable Authentication Modules (PAM) Pluggable authentication modules (PAMs) are a common framework for authentication and authorization. Most system applications in Red Hat Enterprise Linux depend on underlying PAM configuration for authentication and authorization. 10.1. About PAM Pluggable Authentication Modules (PAMs) provide a centralized authentication mechanism which system application can use to relay authentication to a centrally configured framework. PAM is pluggable because there is a PAM module for different types of authentication sources (such as Kerberos, SSSD, NIS, or the local file system). Different authentication sources can be prioritized. This modular architecture offers administrators a great deal of flexibility in setting authentication policies for the system. PAM is a useful system for developers and administrators for several reasons: PAM provides a common authentication scheme that can be used with a wide variety of applications. PAM provides significant flexibility and control over authentication for system administrators. PAM provides a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes. 10.1.1. Other PAM Resources PAM has an extensive documentation set with much more detail about both using PAM and writing modules to extend or integrate PAM with other applications. Almost all of the major modules and configuration files with PAM have their own man pages. Additionally, the /usr/share/doc/pam- version# / directory contains a System Administrators' Guide , a Module Writers' Manual , and the Application Developers' Manual , as well as a copy of the PAM standard, DCE-RFC 86.0. The libraries for PAM are available at http://www.linux-pam.org . This is the primary distribution website for the Linux-PAM project, containing information on various PAM modules, frequently asked questions, and additional PAM documentation. 10.1.2. Custom PAM Modules New PAM modules can be created or added at any time for use by PAM-aware applications. PAM-aware programs can immediately use the new module and any methods it defines without being recompiled or otherwise modified. This allows developers and system administrators to use a selection of authentication modules, as well as tests, for different programs without recompiling them. Documentation on writing modules is included in the /usr/share/doc/pam-devel- version# / directory.

Commands:
2.6.4.3.4. Resource Management Options The xinetd daemon can add a basic level of protection from Denial of Service (DoS) attacks. The following is a list of directives which can aid in limiting the effectiveness of such attacks: per_source - Defines the maximum number of instances for a service per source IP address. It accepts only integers as an argument and can be used in both xinetd.conf and in the service-specific configuration files in the xinetd.d/ directory. cps - Defines the maximum number of connections per second. This directive takes two integer arguments separated by white space. The first argument is the maximum number of connections allowed to the service per second. The second argument is the number of seconds that xinetd must wait before re-enabling the service. It accepts only integers as arguments and can be used in either the xinetd.conf file or the service-specific configuration files in the xinetd.d/ directory. max_load - Defines the CPU usage or load average threshold for a service. It accepts a floating point number argument. The load average is a rough measure of how many processes are active at a given time. See the uptime , who , and procinfo commands for more information about load average. There are more resource management options available for xinetd . Refer to the xinetd.conf man page for more information.

Commands:
Introduction Welcome to the System Administrators Guide . The System Administrators Guide contains information on how to customize your Red Hat Enterprise Linux system to fit your needs. If you are looking for a step-by-step, task-oriented guide for configuring and customizing your system, this is the manual for you. This manual discusses many intermediate topics such as the following: Setting up a network interface card (NIC) Performing a Kickstart installation Configuring Samba shares Managing your software with RPM Determining information about your system Upgrading your kernel This manual is divided into the following main categories: Installation-Related Reference File Systems Reference Package Management Network Configuration System Configuration System Monitoring This guide assumes you have a basic understanding of your Red Hat Enterprise Linux system. If you need help installing Red Hat Enterprise Linux, refer to the Installation Guide . For more general information about system administration, refer to the Introduction to System Administration . If you need more advanced documentation such as an overview of file systems, refer to the Reference Guide . If you need security information, refer to the Security Guide . 1. Changes To This Manual This manual has been reorganized for clarity and updated for the latest features of Red Hat Enterprise Linux 4. Some of the changes include: Updated Kernel Modules and Manually Updating the Kernel Chapters The Kernel Modules and the Upgrading the Kernel Manually chapters include updated information in regards to the 2.6 kernel. Special thanks to Arjan van de Ven for his hard work in helping to complete this chapter. An Updated Network File System (NFS) Chapter The Network File System (NFS) chapter has been revised and reorganized to include NFSv4. Special thanks to Steve Dickson for his hard work in helping to complete this chapter. An Updated OProfile Chapter The OProfile chapter has been revised and reorganized to include updated information in regards to the 2.6 kernel. Special thanks to Will Cohen for his hard work in helping to complete this chapter. An Updated X Window System Chapter The X Window System chapter has been revised to include information on the X11R6.8 release developed by the X.Org team. Before reading this guide, you should be familiar with the contents of the Installation Guide concerning installation issues, the Introduction to System Administration for basic administration concepts, the System Administrators Guide for general customization instructions, and the Security Guide for security related instructions. This guide contains information about topics for advanced users.

Commands:
Chapter 89. Drill Component Available as of Camel version 2.19 The drill: component gives you the ability to querying to Apache Drill Cluster Drill is an Apache open-source SQL query engine for Big Data exploration. Drill is designed from the ground up to support high-performance analysis on the semi-structured and rapidly evolving data coming from modern Big Data applications, while still providing the familiarity and ecosystem of ANSI SQL, the industry-standard query language Maven users will need to add the following dependency to their pom.xml for this component: <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-drill</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency> 89.1. URI format drill://host[?options] You can append query options to the URI in the following format, ?option=value&option=value&... 89.2. Drill Producer The producer execute query using CamelDrillQuery header and put results into body. 89.3. Options The Drill component has no options. The Drill endpoint is configured using URI syntax: with the following path and query parameters: 89.3.1. Path Parameters (1 parameters): Name Description Default Type host Required ZooKeeper host name or IP address. Use local instead of a host name or IP address to connect to the local Drillbit String 89.3.2. Query Parameters (5 parameters): Name Description Default Type clusterId (producer) Cluster ID https://drill.apache.org/docs/using-the-jdbc-driver/#determining-the-cluster-id String directory (producer) Drill directory in ZooKeeper String mode (producer) Connection mode: zk: Zookeeper drillbit: Drillbit direct connection https://drill.apache.org/docs/using-the-jdbc-driver/ ZK DrillConnectionMode port (producer) ZooKeeper port number Integer synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 89.4. Spring Boot Auto-Configuration The component supports 2 options, which are listed below. Name Description Default Type camel.component.drill.enabled Enable drill component true Boolean camel.component.drill.resolve-property-placeholders Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true Boolean 89.5. See Also Configuring Camel Component Endpoint Getting Started

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-drill</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
drill://host[?options]
drill:host
5.131. kdebase-workspace 5.131.1. RHBA-2012:1286 - kdebase-workspace bug fix update Updated kdebase-workspace packages that fix one bug are now available for Red Hat Enterprise Linux 6. The kdebase-workspace packages contain utilities for basic operations with the desktop environment. The utilities allow users for example, to change system settings, resize and rotate X screens or set panels and widgets on the workspace. Bug Fix BZ# 749460 Prior to this update, the task manager did not honor the order of manually arranged items. As a consequence, manually arranged taskbar entries were randomly rearranged when the user switched desktops. This update modifies the underlying code to make manually arranged items more persistent. All users of kdebase-workspace are advised to upgrade to these updated packages, which fix this bug. 5.131.2. RHBA-2012:0400 - kdebase-workspace bug fix update Updated kdebase-workspace packages that fix one bug are now available for Red Hat Enterprise Linux 6. KDE is a graphical desktop environment for the X Window System. The kdebase-workspace packages contain utilities for basic operations with the desktop environment. The utilities allow users for example, to change system settings, resize and rotate X screens or set panels and widgets on the workspace. Bug Fix BZ# 724960 Previously, the kdebase-workspace package relied on the bluez-libs-devel package for rebuild. However, bluez-libs-devel was not supported on IBM System z architectures and builds could be created only with help of the fake-build-provides package which is not required behavior. With this update, the bluez-libs-devel package is no longer required as a dependency on IBM System z architecture and rebuilds are successful. All users of kdebase-workspace are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 11. Enabling encryption on a vSphere cluster You can encrypt your virtual machines after installing OpenShift Container Platform 4.13 on vSphere by draining and shutting down your nodes one at a time. While each virtual machine is shutdown, you can enable encryption in the vCenter web interface. 11.1. Encrypting virtual machines You can encrypt your virtual machines with the following process. You can drain your virtual machines, power them down and encrypt them using the vCenter interface. Finally, you can create a storage class to use the encrypted storage. Prerequisites You have configured a Standard key provider in vSphere. For more information, see Adding a KMS to vCenter Server . Important The Native key provider in vCenter is not supported. For more information, see vSphere Native Key Provider Overview . You have enabled host encryption mode on all of the ESXi hosts that are hosting the cluster. For more information, see Enabling host encryption mode . You have a vSphere account which has all cryptographic privileges enabled. For more information, see Cryptographic Operations Privileges . Procedure Drain and cordon one of your nodes. For detailed instructions on node management, see "Working with Nodes". Shutdown the virtual machine associated with that node in the vCenter interface. Right-click on the virtual machine in the vCenter interface and select VM Policies Edit VM Storage Policies . Select an encrypted storage policy and select OK . Start the encrypted virtual machine in the vCenter interface. Repeat steps 1-5 for all nodes that you want to encrypt. Configure a storage class that uses the encrypted storage policy. For more information about configuring an encrypted storage class, see "VMware vSphere CSI Driver Operator". 11.2. Additional resources Working with nodes vSphere encryption Installing a cluster on vSphere with user-provisioned infrastructure

Commands:
function::thread_indent_depth Name function::thread_indent_depth - returns the nested-depth of the current task Synopsis Arguments delta the amount of depth added/removed for each call Description This function returns an integer equal to the nested function-call depth starting from the outermost initial level. This function is useful for saving space (consumed by whitespace) in traces with long nested function calls. Use this function in a similar fashion to thread_indent , i.e., in call-probe, use thread_indent_depth(1) and in return-probe, use thread_indent_depth(-1)

Commands:
thread_indent_depth:long(delta:long)
13.4. Using the HMC vterm The HMC vterm is the console for any partitioned IBM Power system. Open the console by right-clicking on the partition on the HMC, and then selecting Open Terminal Window . Only a single vterm can be connected to the console at a time and there is no console access for partitioned system besides the vterm. This often is referred to as a virtual console , but is different from the virtual consoles in Section 13.2.1, "Accessing Consoles" .

Commands:
8.6. Installing USGCB-Compliant System with Kickstart Starting with Red Hat Enterprise Linux 6.7, a USGCB ( United States Government Configuration Baseline ) benchmark Kickstart file is supplied for the Server variant of Red Hat Enterprise Linux. This allows administrators to install a USGCB -compliant system with a minimum effort. Instead of installing a raw Red Hat Enterprise Linux system, scanning it using USGCB SCAP content, and then reconfiguring the system to achieve compliance, administrators can use the USGCB benchmark Kickstart file to automatically obtain a USGCB compliant system from the start. See the Red Hat Enterprise Linux Installation Guide for more information on using Kickstart files for automated installations (chapter Kickstart Installations ), as well as instructions on how to use the provided USGCB benchmark Kickstart file (section Creating a USGCB or DISA STIG-compliant Installation Image ). The USGCB Kickstart file is included in the scap-security-guide package, and its permanent location is:

Commands:
/usr/share/scap-security-guide/kickstart/ssg-rhel6-usgcb-server-with-gui-ks.cfg
Chapter 136. KafkaMirrorMaker2Spec schema reference Used in: KafkaMirrorMaker2 Property Description version The Kafka Connect version. Defaults to 3.5.0. Consult the user documentation to understand the process required to upgrade or downgrade the version. string replicas The number of pods in the Kafka Connect group. Defaults to 3 . integer image The docker image for the pods. string connectCluster The cluster alias used for Kafka Connect. The alias must match a cluster in the list at spec.clusters . string clusters Kafka clusters for mirroring. KafkaMirrorMaker2ClusterSpec array mirrors Configuration of the MirrorMaker 2 connectors. KafkaMirrorMaker2MirrorSpec array resources The maximum limits for CPU and memory resources and the requested initial resources. For more information, see the external documentation for core/v1 resourcerequirements . ResourceRequirements livenessProbe Pod liveness checking. Probe readinessProbe Pod readiness checking. Probe jvmOptions JVM Options for pods. JvmOptions jmxOptions JMX Options. KafkaJmxOptions logging Logging configuration for Kafka Connect. The type depends on the value of the logging.type property within the given object, which must be one of [inline, external]. InlineLogging , ExternalLogging clientRackInitImage The image of the init container used for initializing the client.rack . string rack Configuration of the node label which will be used as the client.rack consumer configuration. Rack tracing The configuration of tracing in Kafka Connect. The type depends on the value of the tracing.type property within the given object, which must be one of [jaeger, opentelemetry]. JaegerTracing , OpenTelemetryTracing template Template for Kafka Connect and Kafka Mirror Maker 2 resources. The template allows users to specify how the Deployment , Pods and Service are generated. KafkaConnectTemplate externalConfiguration Pass data from Secrets or ConfigMaps to the Kafka Connect pods and use them to configure connectors. ExternalConfiguration metricsConfig Metrics configuration. The type depends on the value of the metricsConfig.type property within the given object, which must be one of [jmxPrometheusExporter]. JmxPrometheusExporterMetrics

Commands:
3. Feedback If you spot a typo, or if you have thought of a way to make this manual better, we would love to hear from you. Please submit a report in Bugzilla ( http://bugzilla.redhat.com/bugzilla/ ) against the component rh-cs . Be sure to mention the manual's identifier: By mentioning this manual's identifier, we know exactly which version of the guide you have. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

Commands:
rh-MPIO(EN)-4.9 (2011-02-16T16:48)
1.2.3. Checking Out a Working Copy To check out a working copy of a project in a Subversion repository, run the following command: svn checkout svn_repository / remote_path [ directory ] This creates a new directory called directory with a working copy of a project in it. Note that svn_repository is a URL of the Subversion repository and remote_path is the subdirectory in which the project is stored. Example 1.6. Checking out a working copy Imagine that you have a Subversion repository in the ~/svn/ directory (in this case, /home/john/svn/ ) and that this repository contains the latest version of a project in the project/trunk subdirectory. To check out a working copy of this project, type:

Commands:
~]USD svn checkout svn:///home/john/svn/project/trunk project A project/AUTHORS A project/doc A project/doc/index.html A project/INSTALL A project/src
Chapter 4. Upgrading Red Hat Single Sign-On Adapters It is important that you upgrade Red Hat Single Sign-On server first, and then upgrade the adapters. Earlier versions of the adapter might work with later versions of Red Hat Single Sign-On server, but earlier versions of Red Hat Single Sign-On server might not work with later versions of the adapter. 4.1. Compatibility with older adapters As mentioned above, we try to support newer release versions of Red Hat Single Sign-On server working with older release versions of the adapters. However, in some cases we need to include fixes on the Red Hat Single Sign-On server side which may break compatibility with older versions of the adapters. For example, when we implement new aspects of the OpenID Connect specification, which older client adapter versions were not aware of. In those cases, we added Compatibility modes. For OpenId Connect clients, there is a section named OpenID Connect Compatibility Modes in the Red Hat Single Sign-On admin console, on the page with client details. Here, you can disable some new aspects of the Red Hat Single Sign-On server to preserve compatibility with older client adapters. More details are available in the tool tips of individual switches. 4.2. Upgrading the EAP Adapter If you originally installed the adapter using a downloaded archive, to upgrade the JBoss EAP adapter, complete the following steps: Download the new adapter archive. Remove the adapter modules by deleting the EAP_HOME/modules/system/add-ons/keycloak/ directory. Unzip the downloaded archive into EAP_HOME. If you originally installed the adapter using RPM, to upgrade the adapter, complete the following steps, which are different depending on whether you are performing a minor or a micro upgrade: For minor upgrades, use Yum to uninstall any adapters you currently have installed and then use Yum to install the new version of the adapters. For micro upgrades, use Yum to upgrade the adapter. This is the only step for micro upgrades. yum update 4.3. Upgrading the JavaScript Adapter To upgrade a JavaScript adapter that has been copied to your web application, complete the following steps: Download the new adapter archive. Overwrite the keycloak.js file in your application with the keycloak.js file from the downloaded archive. 4.4. Upgrading the Node.js Adapter To upgrade a Node.js adapter that has been copied to your web application, complete the following steps: Download the new adapter archive. Remove the existing Node.js adapter directory Unzip the updated file into its place Change the dependency for keycloak-connect in the package.json of your application

Commands:
update
Chapter 3. Guest Security 3.1. Why Guest Security Matters While the security of the host system is critical in ensuring the security of the guests running on the host, it does not remove the need for properly securing the individual guest machines. All of the security risks associated with a conventional, non-virtualized system still exist when the system is run as a virtualized guest. Any resources accessible to the guest system, such as critical business data or sensitive customer information, could be made vulnerable if the guest system were to be compromised.

Commands: