mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Red Hat Advanced Cluster Security for Kubernetes 4.6 Documentation Welcome to the official Red Hat Advanced Cluster Security for Kubernetes documentation, where you can learn about Red Hat Advanced Cluster Security for Kubernetes and start exploring its features. To go to the Red Hat Advanced Cluster Security for Kubernetes documentation, you can use one of the following methods: Use the left navigation bar to browse the documentation. Select the task that interests you from the contents of this Welcome page. 1.1. Installation activities Understanding installation methods for different platforms : Determine the best installation method for your product and platform. 1.2. Operating Red Hat Advanced Cluster Security for Kubernetes Explore various activities you can perform by using Red Hat Advanced Cluster Security for Kubernetes: Viewing the dashboard : Find information about the Red Hat Advanced Cluster Security for Kubernetes real-time interactive dashboard. Learn how to use it to view key metrics from all your hosts, containers, and services. Compliance feature overview : Understand how to run automated checks and validate compliance based on industry standards, including CIS, NIST, PCI, and HIPAA. Managing vulnerabilities : Learn how to identify and prioritize vulnerabilities for remediation. Responding to violations : Learn how to view policy violations, drill down to the actual cause of the violation, and take corrective actions. 1.3. Configuring Red Hat Advanced Cluster Security for Kubernetes Explore the following typical configuration tasks in Red Hat Advanced Cluster Security for Kubernetes: Adding custom certificates : Learn how to use a custom TLS certificate with Red Hat Advanced Cluster Security for Kubernetes. After you set up a certificate, users and API clients do not have to bypass the certificate security warnings. Backing up Red Hat Advanced Cluster Security for Kubernetes : Learn how to perform manual and automated data backups for Red Hat Advanced Cluster Security for Kubernetes and use these backups for data restoration in the case of an infrastructure disaster or corrupt data. Configuring automatic upgrades for secured clusters : Stay up to date by automating the upgrade process for each secured cluster. 1.4. Integrating with other products Learn how to integrate Red Hat Advanced Cluster Security for Kubernetes with the following products: Integrating with PagerDuty : Learn how to integrate with PagerDuty and forward alerts from Red Hat Advanced Cluster Security for Kubernetes to PagerDuty. Integrating with Slack : Learn how to integrate with Slack and forward alerts from Red Hat Advanced Cluster Security for Kubernetes to Slack. Integrating with Sumo Logic : Learn how to integrate with Sumo Logic and forward alerts from Red Hat Advanced Cluster Security for Kubernetes to Sumo Logic. Integrating by using the syslog protocol : Learn how to integrate with a security information and event management (SIEM) system or a syslog collector for data retention and security investigations.

Commands:
5.103. hsqldb 5.103.1. RHBA-2012:0993 - hsqldb enhancement update Updated hsqldb packages that add an enhancement are now available for Red Hat Enterprise Linux 6. HSQLDB is a relational database engine written in Java, with a JDBC driver, supporting a subset of ANSI-92 SQL. It offers a small (about 100k), fast database engine which offers both in-memory and disk-based tables. Embedded and server modes are available. Additionally, it includes tools such as a minimal web server, in-memory query and management tools (which can be run as applets or servlets), and a number of demonstration examples. Enhancement BZ# 816735 HSQLdb has been updated to add stubs for JDBC 4.1 Users of hsqldb are advised to upgrade to these updated packages, which add this enhancement.

Commands:
7.221. udisks 7.221.1. RHBA-2015:1336 - udisks bug fix and enhancement update Updated udisks packages that fix one bug and add two enhancements are now available for Red Hat Enterprise Linux 6. The udisks packages provide a daemon, D-Bus API, and command-line tools for managing disks and storage devices. Bug Fix BZ# 1121742 Prior to this update, an external storage device could be unmounted forcefully when a device entered the DM_SUSPENDED=1 state for a moment while performing a set of changes during the cleanup procedure. To fix this bug, an exception for ignoring such a device in the cleanup procedure has been added to the UDisks daemon. As a result, DeviceMapper devices are no longer unmounted forcefully in the described situation. Enhancements BZ# 673102 With this update, additional mount points and a list of allowed mount options can be specified by means of udev rules. Flexibility of the udev rules format enables the system administrator to write custom rules to enforce or limit specific mount options for a specific set of devices. For example, USB drives can be limited to be always mounted as read-only. BZ# 681875 This update enables the user to configure the udisks tool to enforce the "noexec" global option on all unprivileged users mount points. On desktop systems, the "noexec" option can protect users from mistakenly running certain applications. Users of udisks are advised to upgrade to these updated packages, which fix this bug and add these enhancements.

Commands:
7.68. gnome-desktop 7.68.1. RHBA-2012:1352 - gnome-desktop bug fix update Updated gnome-desktop packages that fix a bug are now available. The gnome-desktop package contains an internal library (libgnome-desktop) used to implement some portions of the GNOME desktop, and also some data files and other shared components of the GNOME user environment. Bug Fix BZ# 829891 Previously, when a user hit the system's hot-key (most commonly Fn+F7) to change display configurations, the system could potentially switch to an invalid mode, which would fail to display. With this update, gnome-desktop now selects valid XRandR modes and correctly switching displays with the hot-key works as expected. All users of gnome-desktop are advised to upgrade to these updated packages, which fix this bug.

Commands:
1.10.4.3. EDIT MONITORING SCRIPTS Subsection Click on the MONITORING SCRIPTS link at the top of the page. The EDIT MONITORING SCRIPTS subsection allows the administrator to specify a send/expect string sequence to verify that the service for the virtual server is functional on each real server. It is also the place where the administrator can specify customized scripts to check services requiring dynamically changing data. Figure 1.38. The EDIT MONITORING SCRIPTS Subsection Sending Program For more advanced service verification, you can use this field to specify the path to a service-checking script. This function is especially helpful for services that require dynamically changing data, such as HTTPS or SSL. To use this function, you must write a script that returns a textual response, set it to be executable, and type the path to it in the Sending Program field. Note If an external program is entered in the Sending Program field, then the Send field is ignored. Send A string for the nanny daemon to send to each real server in this field. By default the send field is completed for HTTP. You can alter this value depending on your needs. If you leave this field blank, the nanny daemon attempts to open the port and assume the service is running if it succeeds. Only one send sequence is allowed in this field, and it can only contain printable, ASCII characters as well as the following escape characters: \n for new line. \r for carriage return. \t for tab. \ to escape the character which follows it. Expect The textual response the server should return if it is functioning properly. If you wrote your own sending program, enter the response you told it to send if it was successful.

Commands:
13.8. Put Request Example The following is the coded request from a sample put request using Hot Rod: Table 13.43. Put Request Example Byte 0 1 2 3 4 5 6 7 8 0xA0 0x09 0x41 0x01 0x07 0x4D ('M') 0x79 ('y') 0x43 ('C') 16 0x61 ('a') 0x63 ('c') 0x68 ('h') 0x65 ('e') 0x00 0x03 0x00 0x00 24 0x00 0x05 0x48 ('H') 0x65 ('e') 0x6C ('l') 0x6C ('l') 0x6F ('o') 0x00 32 0x00 0x05 0x57 ('W') 0x6F ('o') 0x72 ('r') 0x6C ('l') 0x64 ('d') - The following table contains all header fields and their values for the example request: Table 13.44. Example Request Field Names and Values Field Name Byte Value Magic 0 0xA0 Version 2 0x41 Cache Name Length 4 0x07 Flag 12 0x00 Topology ID 14 0x00 Transaction ID 16 0x00 Key 18-22 'Hello' Max Idle 24 0x00 Value 26-30 'World' Message ID 1 0x09 Opcode 3 0x01 Cache Name 5-11 'MyCache' Client Intelligence 13 0x03 Transaction Type 15 0x00 Key Field Length 17 0x05 Lifespan 23 0x00 Value Field Length 25 0x05 The following is a coded response for the sample put request: Table 13.45. Coded Response for the Sample Put Request Byte 0 1 2 3 4 5 6 7 8 0xA1 0x09 0x01 0x00 0x00 - - - The following table contains all header fields and their values for the example response: Table 13.46. Example Response Field Names and Values Field Name Byte Value Magic 0 0xA1 Opcode 2 0x01 Topology Change Marker 4 0x00 Message ID 1 0x09 Status 3 0x00 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
Chapter 92. TgzArtifact schema reference Used in: Plugin Property Property type Description url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure. type string Must be tgz .

Commands:
Chapter 12. Resource Management Control Groups Red Hat Enterprise Linux 7 features control groups, cgroups, which is a concept for organizing processes in a tree of named groups for the purpose of resource management. They provide a way to hierarchically group and label processes and a way to apply resource limits to these groups. In Red Hat Enterprise Linux 7, control groups are exclusively managed through systemd . Control groups are configured in systemd unit files and are managed with systemd's command line interface (CLI) tools. Control groups and other resource management features are discussed in detail in the Resource Management and Linux Containers Guide .

Commands:
Chapter 5. Configuring network access Configure network access for your Data Grid deployment and find out about internal network services. 5.1. Exposing Data Grid clusters on the network Make Data Grid clusters available on the network so you can access Data Grid Console as well as REST and Hot Rod endpoints. By default, the Data Grid chart exposes deployments through a Route but you can configure it to expose clusters via Load Balancer or Node Port. You can also configure the Data Grid chart so that deployments are not exposed on the network and only available internally to the OpenShift cluster. Procedure Specify one of the following for the deploy.expose.type field: Option Description Route Exposes Data Grid through a route. This is the default value. LoadBalancer Exposes Data Grid through a load balancer service. NodePort Exposes Data Grid through a node port service. "" (empty value) Disables exposing Data Grid on the network. Optionally specify a hostname with the deploy.expose.host field if you expose Data Grid through a route. Optionally specify a port with the deploy.expose.nodePort field if you expose Data Grid through a node port service. Install or upgrade your Data Grid Helm release. 5.2. Retrieving network service details Get network service details so you can connect to Data Grid clusters. Prerequisites Expose your Data Grid cluster on the network. Have an oc client. Procedure Use one of the following commands to retrieve network service details: If you expose Data Grid through a route: If you expose Data Grid through a load balancer or node port service: 5.3. Network services The Data Grid chart creates default network services for internal access. Service Port Protocol Description <helm_release_name> 11222 TCP Provides access to Data Grid Hot Rod and REST endpoints. <helm_release_name> 11223 TCP Provides access to Data Grid metrics. <helm_release_name>-ping 8888 TCP Allows Data Grid pods to discover each other and form clusters. You can retrieve details about internal network services as follows:

Commands:
oc get routes
oc get services
oc get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) infinispan ClusterIP 192.0.2.0 <none> 11222/TCP,11223/TCP infinispan-ping ClusterIP None <none> 8888/TCP
Chapter 96. ExternalConfigurationVolumeSource schema reference The type ExternalConfigurationVolumeSource has been deprecated. Please use AdditionalVolume instead. Used in: ExternalConfiguration Property Property type Description name string Name of the volume which will be added to the Kafka Connect pods. secret SecretVolumeSource Reference to a key in a Secret. Exactly one Secret or ConfigMap has to be specified. configMap ConfigMapVolumeSource Reference to a key in a ConfigMap. Exactly one Secret or ConfigMap has to be specified.

Commands:
14.6.3. WINS (Windows Internetworking Name Server) Either a Samba server or a Windows NT server can function as a WINS server. When a WINS server is used with NetBIOS enabled, UDP unicasts can be routed which allows name resolution across networks. Without a WINS server, the UDP broadcast is limited to the local subnet and therefore cannot be routed to other subnets, workgroups, or domains. If WINS replication is necessary, do not use Samba as your primary WINS server, as Samba does not currently support WINS replication. In a mixed NT/2000/2003 server and Samba environment, it is recommended that you use the Microsoft WINS capabilities. In a Samba-only environment, it is recommended that you use only one Samba server for WINS. The following is an example of the smb.conf file in which the Samba server is serving as a WINS server: Note All servers (including Samba) should connect to a WINS server to resolve NetBIOS names. Without WINS, browsing only occurs on the local subnet. Furthermore, even if a domain-wide list is somehow obtained, hosts are not resolvable for the client without WINS.

Commands:
[global] wins support = Yes
Chapter 2. Installation This chapter guides you through the steps to install AMQ JMS Pool in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ JMS Pool, you must install Apache Maven . To use AMQ JMS Pool, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.messaginghub</groupId> <artifactId>pooled-jms</artifactId> <version>1.1.1.redhat-00003</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ JMS Pool can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Clients 2.8.0 JMS Pool Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-clients-2.8.0-jms-pool-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" . 2.4. Installing the examples Procedure Use the git clone command to clone the source repository to a local directory named pooled-jms : USD git clone https://github.com/messaginghub/pooled-jms.git pooled-jms Change to the pooled-jms directory and use the git checkout command to switch to the 1.1.1 branch: USD cd pooled-jms USD git checkout 1.1.1 The resulting local directory is referred to as <source-dir> throughout this document.

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.messaginghub</groupId> <artifactId>pooled-jms</artifactId> <version>1.1.1.redhat-00003</version> </dependency>
unzip amq-clients-2.8.0-jms-pool-maven-repository.zip
git clone https://github.com/messaginghub/pooled-jms.git pooled-jms
cd pooled-jms git checkout 1.1.1
9.9. Set the Root Password Setting up a root account and password is one of the most important steps during your installation. The root account is used to install packages, upgrade RPMs, and perform most system maintenance. Logging in as root gives you complete control over your system. Note The root user (also known as the superuser) has complete access to the entire system; for this reason, logging in as the root user is best done only to perform system maintenance or administration. Figure 9.32. Root Password Use the root account only for system administration. Create a non-root account for your general use and use the su command to change to root only when you need to perform tasks that require superuser authorization. These basic rules minimize the chances of a typo or an incorrect command doing damage to your system. Note To become root, type su - at the shell prompt in a terminal window and then press Enter . Then, enter the root password and press Enter . The installation program prompts you to set a root password [2] for your system. . You cannot proceed to the stage of the installation process without entering a root password. The root password must be at least six characters long; the password you type is not echoed to the screen. You must enter the password twice; if the two passwords do not match, the installation program asks you to enter them again. You should make the root password something you can remember, but not something that is easy for someone else to guess. Your name, your phone number, qwerty , password, root , 123456 , and anteater are all examples of bad passwords. Good passwords mix numerals with upper and lower case letters and do not contain dictionary words: Aard387vark or 420BMttNT , for example. Remember that the password is case-sensitive. If you write down your password, keep it in a secure place. However, it is recommended that you do not write down this or any password you create. Warning Do not use one of the example passwords offered in this manual. Using one of these passwords could be considered a security risk. To change your root password after you have completed the installation, run the passwd command as root . If you forget the root password, see Resolving Problems in System Recovery Modes in the Red Hat Enterprise Linux 6 Deployment Guide for instructions on how to set a new one. [2] A root password is the administrative password for your Red Hat Enterprise Linux system. You should only log in as root when needed for system maintenance. The root account does not operate within the restrictions placed on normal user accounts, so changes made as root can have implications for your entire system.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ Python examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:25 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Appendix A. About Nodeshift Nodeshift is a module for running OpenShift deployments with Node.js projects. Important Nodeshift assumes you have the oc CLI client installed, and you are logged into your OpenShift cluster. Nodeshift also uses the current project the oc CLI client is using. Nodeshift uses resource files in the .nodeshift folder located at the root of the project to handle creating OpenShift Routes, Services and DeploymentConfigs. More details on Nodeshift are available on the Nodeshift project page .

Commands: