mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Vulnerabilities You can use the Insights Inventory application to check for vulnerabilities and update systems if necessary to address those vulnerabilities identified by the system. 7.1. Checking a system for vulnerabilities You can use the Insights Inventory application to check for CVEs or other vulnerabilities in systems you have registered with the Insights Inventory application. Prerequisites You have a Red Hat Hybrid Cloud Console account You have a system registered with the Insights Inventory application. Procedure Access Red Hat Hybrid Cloud Console platform and log in. From the dashboard, navigate to Red Hat Insights > RHEL > Inventory > Security > Systems . Check for vulnerabilities for one of your systems. Click the name of the system, then navigate to the system details page and click the Vulnerability tab. If there are Common Vulnerabilities and Exposures (CVEs) present in your system, you can address them immediately in the Vulnerability tab. See Addressing vulnerabilities in a system . 7.2. Addressing vulnerabilities in a system After you check for vulnerabilities, if a CVE is found, you can remediate it by updating the image from the Vulnerabilities tab. Prerequisites You have a Red Hat Hybrid Cloud Console account. You have a system registered with the Insights Inventory application. Procedure Access Red Hat Hybrid Cloud Console platform and log in. From the console dashboard, navigate to Red Hat Insights > RHEL > Inventory > Security > Systems . In the edge management menu, click Inventory > Security > Systems . Click the name of the system, then click the Vulnerability tab. Click Update Image and follow the prompts. Review the details about the update and click Update Image to build an updated image. The build might take a few minutes. After the update completes, the status column shows that an update is available. You can now send the update to the system. In the edge management menu, click Inventory > Systems . Click the name of the system you want to update. On the system details page, click Vulnerabilities > Update system . Review the information about the update and then click Update system . Verification If the update was successful, after your system reboots, it automatically sends confirmation to the Insights Inventory application. Check the system status on the system details page. While the system is updating, the system status is Updating . If the update was successful, the status column for the system is Up to date . If there is an Error status, click Error to check the reason. You can click Retry to attempt to update your system again.

Commands:
7.88. iok 7.88.1. RHBA-2012:1164 - iok bug fix update Updated iok packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The iok package contains an Indic on-screen virtual keyboard that supports the Assamese, Bengali, Gujarati, Hindi, Kannada, Marathi, Malayalam, Punjabi, Oriya, Sindhi, Tamil and Telugu languages. Currently, iok works with Inscript and xkb keymaps for Indian languages, and is able to parse and display non-Inscript keymaps as well. Bug Fixes BZ# 814541 , BZ#814548 Previously, when saving a keymap with a specified name, predefined naming convention was followed and the file name was saved with the "-" prefix without noticing the user. With this update, if the user attempts to save a keymap, a dialog box displaying the required file name format appears. BZ#819795 This update provides the complete iok translation for all supported locales. All users of iok are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Registry Red Hat OpenShift Service on AWS 4 Red Hat OpenShift Service on AWS can build images from your source code, deploy them, and manage their lifecycle. Red Hat OpenShift Documentation Team

Commands:
podman login registry.redhat.io Username:<your_registry_account_username> Password:<your_registry_account_password>
podman pull registry.redhat.io/<repository_name>
oc get pods -n openshift-image-registry
NAME READY STATUS RESTARTS AGE image-registry-79fb4469f6-llrln 1/1 Running 0 77m node-ca-hjksc 1/1 Running 0 73m node-ca-tftj6 1/1 Running 0 77m node-ca-wb6ht 1/1 Running 0 77m node-ca-zvt9q 1/1 Running 0 74m
oc logs deployments/image-registry -n openshift-image-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown" 2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler" 2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
Chapter 44. TieredStorageCustom schema reference Used in: KafkaClusterSpec Full list of TieredStorageCustom schema properties Enables custom tiered storage for Kafka. If you want to use custom tiered storage, you must first add a tiered storage for Kafka plugin to the Streams for Apache Kafka image by building a custom container image. Custom tiered storage configuration enables the use of a custom RemoteStorageManager configuration. RemoteStorageManager is a Kafka interface for managing the interaction between Kafka and remote tiered storage. If custom tiered storage is enabled, Streams for Apache Kafka uses the TopicBasedRemoteLogMetadataManager for Remote Log Metadata Management (RLMM). Warning Tiered storage is an early access Kafka feature, which is also available in Streams for Apache Kafka. Due to its current limitations , it is not recommended for production environments. Example custom tiered storage configuration kafka: tieredStorage: type: custom remoteStorageManager: className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager classPath: /opt/kafka/plugins/tiered-storage-s3/* config: # A map with String keys and String values. # Key properties are automatically prefixed with `rsm.config.` # and appended to Kafka broker config. storage.bucket.name: my-bucket config: ... # Additional RLMM configuration can be added through the Kafka config # under `spec.kafka.config` using the `rlmm.config.` prefix. rlmm.config.remote.log.metadata.topic.replication.factor: 1 44.1. TieredStorageCustom schema properties The type property is a discriminator that distinguishes use of the TieredStorageCustom type from other subtypes which may be added in the future. It must have the value custom for the type TieredStorageCustom . Property Property type Description remoteStorageManager RemoteStorageManager Configuration for the Remote Storage Manager. type string Must be custom .

Commands:
kafka: tieredStorage: type: custom remoteStorageManager: className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager classPath: /opt/kafka/plugins/tiered-storage-s3/* config: # A map with String keys and String values. # Key properties are automatically prefixed with `rsm.config.` # and appended to Kafka broker config. storage.bucket.name: my-bucket config: # Additional RLMM configuration can be added through the Kafka config # under `spec.kafka.config` using the `rlmm.config.` prefix. rlmm.config.remote.log.metadata.topic.replication.factor: 1
8.6. Creating a Remediation Ansible Playbook to Align the System with a Specific Baseline Use this procedure to create an Ansible playbook containing only the remediations that are needed to align your system with a specific baseline. This example uses the Protection Profile for General Purpose Operating Systems (OSPP). With this procedure, you create a smaller playbook that does not cover already satisfied requirements. By following these steps, you do not modify your system in any way, you only prepare a file for later application. Prerequisites The scap-security-guide package is installed on your system. Procedure Scan the system and save the results: Generate an Ansible playbook based on the file generated in the step: The ospp-remediations.yml file contains Ansible remediations for rules that failed during the scan performed in step 1. After you review this generated file, you can apply it with the ansible-playbook ospp-remediations.yml command. Verification In a text editor of your choice, review that the ospp-remediations.yml file contains rules that failed in the scan performed in step 1. Additional Resources scap-security-guide(8) and oscap(8) man pages Ansible Documentation

Commands:
~]# oscap xccdf eval --profile ospp --results ospp-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
~]# oscap xccdf generate fix --fix-type ansible --profile ospp --output ospp-remediations.yml ospp-results.xml
Appendix A. Component Versions This appendix provides a list of key components and their versions in the Red Hat Enterprise Linux 7.9 release. Table A.1. Component Versions Component Version kernel 3.10.0-1160 kernel-alt 4.14.0-115 QLogic qla2xxx driver 10.01.00.22.07.9-k QLogic qla4xxx driver 5.04.00.00.07.02-k0 Emulex lpfc driver 0:12.0.0.13 iSCSI initiator utils ( iscsi-initiator-utils ) 6.2.0.874-19 DM-Multipath ( device-mapper-multipath ) 0.4.9-133 LVM ( lvm2 ) 2.02.187-6 qemu-kvm [a] 1.5.3-175 qemu-kvm-ma [b] 2.12.0-33 [a] The qemu-kvm packages provide KVM virtualization on AMD64 and Intel 64 systems. [b] The qemu-kvm-ma packages provide KVM virtualization on IBM POWER8, IBM POWER9, and IBM Z. Note that KVM virtualization on IBM POWER9 and IBM Z also requires using the kernel-alt packages.

Commands:
Chapter 14. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.13, you can install a three-node cluster on Google Cloud Platform (GCP). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 14.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: compute: - name: worker platform: {} replicas: 0 If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 14.2. steps Installing a cluster on GCP with customizations Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates

Commands:
compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 217. LZF Deflate Compression DataFormat Available as of Camel version 2.17 The LZF Data Format is a message compression and de-compression format. It uses the LZF deflate algorithm. Messages marshalled using LZF compression can be unmarshalled using LZF decompression just prior to being consumed at the endpoint. The compression capability is quite useful when you deal with large XML and Text based payloads or when you read messages previously comressed using LZF algotithm. 217.1. Options The LZF Deflate Compression dataformat supports 2 options, which are listed below. Name Default Java Type Description usingParallelCompression false Boolean Enable encoding (compress) using multiple processing cores. contentTypeHeader false Boolean Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. 217.2. Spring Boot Auto-Configuration The component supports 3 options, which are listed below. Name Description Default Type camel.dataformat.lzf.content-type-header Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. false Boolean camel.dataformat.lzf.enabled Enable lzf dataformat true Boolean camel.dataformat.lzf.using-parallel-compression Enable encoding (compress) using multiple processing cores. false Boolean ND 217.3. Marshal In this example we marshal a regular text/XML payload to a compressed payload employing LZF compression format and send it an ActiveMQ queue called MY_QUEUE. from("direct:start").marshal().lzf().to("activemq:queue:MY_QUEUE"); 217.4. Unmarshal In this example we unmarshal a LZF payload from an ActiveMQ queue called MY_QUEUE to its original format, and forward it for processing to the UnGZippedMessageProcessor . from("activemq:queue:MY_QUEUE").unmarshal().lzf().process(new UnCompressedMessageProcessor()); 217.5. Dependencies To useLZF compression in your camel routes you need to add a dependency on camel-lzf which implements this data format. If you use Maven you can just add the following to your pom.xml , substituting the version number for the latest & greatest release (see the download page for the latest versions ). <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-lzf</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>

Commands:
from("direct:start").marshal().lzf().to("activemq:queue:MY_QUEUE");
from("activemq:queue:MY_QUEUE").unmarshal().lzf().process(new UnCompressedMessageProcessor());
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-lzf</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
Chapter 2. Acknowledgments The Ceph Storage project is seeing amazing growth in the quality and quantity of contributions from individuals and organizations in the Ceph community. We would like to thank all members of the Red Hat Ceph Storage team, all of the individual contributors in the Ceph community, and additionally, but not limited to, the contributions from organizations such as: Intel(R) Fujitsu (R) UnitedStack Yahoo TM Ubuntu Kylin Mellanox (R) CERN TM Deutsche Telekom Mirantis (R) SanDisk TM SUSE

Commands:
5.6. Backing Up and Restoring the luci Configuration As of the Red Hat Enterprise Linux 6.2 release, you can use the following procedure to make a backup of the luci database, which is stored in the /var/lib/luci/data/luci.db file. This is not the cluster configuration itself, which is stored in the cluster.conf file. Instead, it contains the list of users and clusters and related properties that luci maintains. By default, the backup this procedure creates will be written to the same directory as the luci.db file. Execute service luci stop . Execute service luci backup-db . Optionally, you can specify a file name as a parameter for the backup-db command, which will write the luci database to that file. For example, to write the luci database to the file /root/luci.db.backup , you can execute the command service luci backup-db /root/luci.db.backup . Note, however, that backup files that are written to places other than /var/lib/luci/data/ (for backups whose filenames you specify when using service luci backup-db ) will not show up in the output of the list-backups command. Execute service luci start . Use the following procedure to restore a luci database. Execute service luci stop . Execute service luci list-backups and note the file name to restore. Execute service luci restore-db /var/lib/luci/data/ lucibackupfile where lucibackupfile is the backup file to restore. For example, the following command restores the luci configuration information that was stored in the backup file luci-backup20110923062526.db : Execute service luci start . If you need to restore a luci database but you have lost the host.pem file from the machine on which you created the backup because of a complete reinstallation, for example, you will need to add your clusters back to luci manually in order to re-authenticate the cluster nodes. Use the following procedure to restore a luci database onto a different machine than the one on which the backup was created. Note that in addition to restoring the database itself, you also need to copy the SSL certificate file to ensure that luci has been authenticated to the ricci nodes. In this example, the backup is created on the machine luci1 and the backup is restored on the machine luci2 . Execute the following sequence of commands to create a luci backup on luci1 and copy both the SSL certificate file and the luci backup onto luci2 . On the luci2 machine, ensure that luci has been installed and is not running. Install the package, if is not already installed. Execute the following sequence of commands to ensure that the authentications are in place and to restore the luci database from luci1 onto luci2 .

Commands:
service luci restore-db /var/lib/luci/data/luci-backup20110923062526.db
service luci stop service luci backup-db service luci list-backups /var/lib/luci/data/luci-backup20120504134051.db scp /var/lib/luci/certs/host.pem /var/lib/luci/data/luci-backup20120504134051.db root@luci2:
cp host.pem /var/lib/luci/certs/ chown luci: /var/lib/luci/certs/host.pem /etc/init.d/luci restore-db ~/luci-backup20120504134051.db shred -u ~/host.pem ~/luci-backup20120504134051.db service luci start
Chapter 2. Component overview Red Hat AMQ consists of AMQ Broker, AMQ Interconnect, and AMQ Clients. They work together to enable network communication in distributed applications. AMQ Broker AMQ Interconnect AMQ Clients 2.1. AMQ Broker AMQ Broker is a full-featured, message-oriented middleware broker. It offers advanced addressing and queueing, fast message persistence, and high availability. AMQ Broker supports multiple protocols and operating environments, enabling you to use your existing assets. AMQ Broker supports integration with Red Hat JBoss Enterprise Application Platform. For more information, see Getting Started with AMQ Broker . 2.2. AMQ Interconnect AMQ Interconnect provides flexible routing of messages between AMQP-enabled endpoints, including clients, brokers, and standalone services. With a single connection into a network of AMQ Interconnect routers, a client can exchange messages with any other endpoint connected to the network. AMQ Interconnect does not use master-slave clusters for high availability. It is typically deployed in topologies of multiple routers with redundant network paths, which it uses to provide reliable connectivity. AMQ Interconnect can distribute messaging workloads across the network and achieve new levels of scale with very low latency. For more information, see Using AMQ Interconnect . 2.3. AMQ Clients AMQ Clients is a suite of AMQP 1.0 and JMS clients, adapters, and libraries. It includes JMS 2.0 support and new, event-driven APIs to enable integration into existing applications. For more information, see AMQ Clients Overview . AMQP clients AMQ C++ AMQ JavaScript AMQ JMS (Java) AMQ .NET AMQ Python AMQ Ruby JMS clients AMQ JMS (AMQP 1.0) AMQ Core Protocol JMS AMQ OpenWire JMS Adapters and libraries AMQ JMS Pool AMQ Spring Boot Starter 2.4. Component compatibility The following table lists the supported languages, platforms, and protocols of AMQ components. Note that any components supporting the same protocol can interoperate, even if their languages and platforms differ. For instance, AMQ Python can communicate with AMQ JMS. Table 2.1. AMQ component compatibility Component Languages Platforms Protocols AMQ Broker - JVM AMQP 1.0, MQTT, OpenWire, STOMP, Core Protocol AMQ Interconnect - Linux AMQP 1.0 AMQ C++ C++ Linux, Windows AMQP 1.0 AMQ JavaScript JavaScript Node.js, browsers AMQP 1.0 AMQ JMS Java JVM AMQP 1.0 AMQ .NET C# .NET AMQP 1.0 AMQ Python Python Linux AMQP 1.0 AMQ Ruby Ruby Linux AMQP 1.0 AMQ Spring Boot Starter Java JVM AMQP 1.0 AMQ Core Protocol JMS Java JVM Core Protocol AMQ OpenWire JMS Java JVM OpenWire AMQ JMS Pool Java JVM - For more information, see Red Hat AMQ 7 Supported Configurations .

Commands:
5.3.11. /proc/tty/ This directory contains information about the available and currently used tty devices on the system. Originally called teletype devices , any character-based data terminals are called tty devices. In Linux, there are three different kinds of tty devices. Serial devices are used with serial connections, such as over a modem or using a serial cable. Virtual terminals create the common console connection, such as the virtual consoles available when pressing Alt + <F-key> at the system console. Pseudo terminals create a two-way communication that is used by some higher level applications, such as XFree86. The drivers file is a list of the current tty devices in use, as in the following example: The /proc/tty/driver/serial file lists the usage statistics and status of each of the serial tty lines. In order for tty devices to be used as network devices, the Linux kernel enforces line discipline on the device. This allows the driver to place a specific type of header with every block of data transmitted over the device, making it possible for the remote end of the connection to a block of data as just one in a stream of data blocks. SLIP and PPP are common line disciplines, and each are commonly used to connect systems to one other over a serial link. Registered line disciplines are stored in the ldiscs file, and more detailed information is available within the ldisc/ directory.

Commands:
serial /dev/cua 5 64-127 serial:callout serial /dev/ttyS 4 64-127 serial pty_slave /dev/pts 136 0-255 pty:slave pty_master /dev/ptm 128 0-255 pty:master pty_slave /dev/ttyp 3 0-255 pty:slave pty_master /dev/pty 2 0-255 pty:master /dev/vc/0 /dev/vc/0 4 0 system:vtmaster /dev/ptmx /dev/ptmx 5 2 system /dev/console /dev/console 5 1 system:console /dev/tty /dev/tty 5 0 system:/dev/tty unknown /dev/vc/%d 4 1-63 console