mtpti5iD/redhat-docs_dataset huggingface dataset:
Preface Red Hat Trusted Application Pipeline (RHTAP) is not really a single product. Instead, it is a set of products that combine to form a highly automated, customizable, and secure platform for building applications. RHTAP includes the following products: Red Hat Developer Hub : a self-service portal for developers. OpenShift GitOps : to manage Kubernetes deployments and their infrastructure. OpenShift Pipelines : to enable automation and provide visibility for continuous integration and continuous delivery (CI/CD) of software. Trusted Artifact Signer : to sign and validate the artifacts that RHTAP produces. Trusted Profile Analyzer : to deliver actionable information about your security posture. It also depends on the following products: Quay.io : a container registry, where RHTAP stores your artifacts. Advanced Cluster Security (ACS) : a security tool that RHTAP uses to scan your artifacts. Note To see exactly which versions of these products RHTAP supports, reference the compatibility and support matrix in our Release notes . Because a fully-operational instance of RHTAP involves all of the products listed above, installing RHTAP takes time and effort. However, we have automated this process where possible, and are providing instructions here that we hope are helpful and concise. Additionally, be aware that the RHTAP installer is not a manager: it does not support upgrades. The installer generates your first deployment of RHTAP. After installation, you manage each product within RHTAP individually. Before you can begin installation, you must meet six prerequisites. Then you must complete seven procedures. Prerequisites ClusterAdmin access to an OpenShift Container Platform (OCP) cluster, through both the CLI and the web console An instance of Red Hat Advanced Cluster Security, as well as the following values from that instance: ACS API token. You can follow the instructions for the prerequisites here to create an API token. ACS central endpoint URL. You can follow the instructions here to configure the endpoint. To enable ACS to access private repositories in image registries, ACS will need to be configured for your specific registry For Quay.io, under Integrations->Image Integrations select the Quay.io card Add your OAUTH tokens to access your specific Quay.io instance Validate the access via the test button. This will ensure if the RHTAP is asked to scan a private image, ACS will have access A Quay.io account The Helm CLI tool A GitHub account Procedures Creating a GitHub application for RHTAP Forking the template catalog Creating a GitOps git token Creating the Docker configuration value Creating a private-values.yaml file Installing RHTAP in your cluster Finalizing your GitHub application The following pages of this document explain each of those procedures in detail. If you have the prerequisites, you are ready to start the installation process by creating a GitHub application.

Commands:
5.3.6. Activating and Mounting the Original Logical Volume Since you had to deactivate the logical volume mylv , you need to activate it again before you can mount it.

Commands:
root@tng3-1 ~]# lvchange -a y mylv mount /dev/myvg/mylv /mnt df Filesystem 1K-blocks Used Available Use% Mounted on /dev/yourvg/yourlv 24507776 32 24507744 1% /mnt /dev/myvg/mylv 24507776 32 24507744 1% /mnt
Chapter 6. Review the State of a Node If you have a deployment of the Uchiwa dashboard, you can use it with the Sensu server to review the state of your nodes: Login to the Uchiwa dashboard and click the Data Center tab to confirm that the Data Center is operational. Check that all overcloud nodes are in a Connected state. At a suitable time, reboot one of the overcloud nodes and review the rebooted node's status in the Uchiwa dashboard. After the reboot completes, verify that the node successfully re-connects to the Sensu server and starts executing checks.

Commands:
http://<SERVER_IP_ADDRESS>/uchiwa
3.13. Additional Resources Subsystem-Specific Kernel Documentation All of the following files are located under the /usr/share/doc/kernel-doc- <kernel_version> /Documentation/cgroups/ directory (provided by the kernel-doc package). blkio subsystem - blkio-controller.txt cpuacct subsystem - cpuacct.txt cpuset subsystem - cpusets.txt devices subsystem - devices.txt freezer subsystem - freezer-subsystem.txt memory subsystem - memory.txt net_prio subsystem - net_prio.txt Additionally, refer to the following files for further information about the cpu subsystem: Real-Time scheduling - /usr/share/doc/kernel-doc- <kernel_version> /Documentation/scheduler/sched-rt-group.txt CFS scheduling - /usr/share/doc/kernel-doc- <kernel_version> /Documentation/scheduler/sched-bwc.txt

Commands:
3.3.5. Thinly-Provisioned Logical Volumes (Thin Volumes) As of the Red Hat Enterprise Linux 6.4 release, logical volumes can be thinly provisioned. This allows you to create logical volumes that are larger than the available extents. Using thin provisioning, you can manage a storage pool of free space, known as a thin pool, which can be allocated to an arbitrary number of devices when needed by applications. You can then create devices that can be bound to the thin pool for later allocation when an application actually writes to the logical volume. The thin pool can be expanded dynamically when needed for cost-effective allocation of storage space. Note Thin volumes are not supported across the nodes in a cluster. The thin pool and all its thin volumes must be exclusively activated on only one cluster node. By using thin provisioning, a storage administrator can over-commit the physical storage, often avoiding the need to purchase additional storage. For example, if ten users each request a 100GB file system for their application, the storage administrator can create what appears to be a 100GB file system for each user but which is backed by less actual storage that is used only when needed. When using thin provisioning, it is important that the storage administrator monitor the storage pool and add more capacity if it starts to become full. To make sure that all available space can be used, LVM supports data discard. This allows for re-use of the space that was formerly used by a discarded file or other block range. For information on creating thin volumes, see Section 5.4.4, "Creating Thinly-Provisioned Logical Volumes" . Thin volumes provide support for a new implementation of copy-on-write (COW) snapshot logical volumes, which allow many virtual devices to share the same data in the thin pool. For information on thin snapshot volumes, see Section 3.3.7, "Thinly-Provisioned Snapshot Volumes" .

Commands:
6.9. Connectors Connectors define how the TPS communicates with other subsystems - namely CA, KRA, and TKS. In general, these parameters are set up during TPS installation. The following is an example of connector configuration: TPS profiles refer to these connectors by their IDs. For example Multiple connector of the same kind (for example, multiple CA connectors) can be defined. This may be useful when one TPS instance serves multiple backend Certificate System servers for different groups of tokens. Note Automatic failover for connectors in TPS is currently not supported. A manual failover procedure must be performed to point the TPS to alternate CA, KRA, or TKS, as long as they are clones of the original systems.

Commands:
tps.connector.ca1.enable=true tps.connector.ca1.host=host1.EXAMPLE.com tps.connector.ca1.maxHttpConns=15 tps.connector.ca1.minHttpConns=1 tps.connector.ca1.nickName=subsystemCert cert-pki-tomcat tps.connector.ca1.port=8443 tps.connector.ca1.timeout=30 tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.getcert=/ca/ee/ca/displayBySerial tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke tps.connector.kra1.enable=true tps.connector.kra1.host=host1.EXAMPLE.com tps.connector.kra1.maxHttpConns=15 tps.connector.kra1.minHttpConns=1 tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat tps.connector.kra1.port=8443 tps.connector.kra1.timeout=30 tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery tps.connector.tks1.enable=true tps.connector.tks1.generateHostChallenge=true tps.connector.tks1.host=host1.EXAMPLE.com tps.connector.tks1.keySet=defKeySet tps.connector.tks1.maxHttpConns=15 tps.connector.tks1.minHttpConns=1 tps.connector.tks1.nickName=subsystemCert cert-pki-tomcat tps.connector.tks1.port=8443 tps.connector.tks1.serverKeygen=true tps.connector.tks1.timeout=30 tps.connector.tks1.tksSharedSymKeyName=sharedSecret tps.connector.tks1.uri.computeRandomData=/tks/agent/tks/computeRandomData tps.connector.tks1.uri.computeSessionKey=/tks/agent/tks/computeSessionKey tps.connector.tks1.uri.createKeySetData=/tks/agent/tks/createKeySetData tps.connector.tks1.uri.encryptData=/tks/agent/tks/encryptData
op.enroll.userKey.keyGen.signing.ca.conn= ca1
B.85. scsi-target-utils B.85.1. RHSA-2011:0332 - Important: scsi-target-utils security update An updated scsi-target-utils package that fixes one security issue is now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. The scsi-target-utils package contains the daemon and tools to set up and monitor SCSI targets. Currently, iSCSI software and iSER targets are supported. CVE-2011-0001 A double-free flaw was found in scsi-target-utils' tgtd daemon. A remote attacker could trigger this flaw by sending carefully-crafted network traffic, causing the tgtd daemon to crash. Red Hat would like to thank Emmanuel Bouillon of NATO C3 Agency for reporting this issue. All scsi-target-utils users should upgrade to this updated package, which contains a backported patch to correct this issue. All running scsi-target-utils services must be restarted for the update to take effect.

Commands:
Chapter 7. Upgrading from Red Hat Gluster Storage 3.4 to Red Hat Gluster Storage 3.5 in a Red Hat Enterprise Virtualization-Red Hat Gluster Storage Environment This section describes the upgrade methods for a Red Hat Gluster Storage and Red Hat Enterprise Virtualization integrated environment. You can upgrade Red Hat Gluster Storage 3.4 to Red Hat Gluster Storage 3.5 using an ISO or yum . Warning Before you upgrade, be aware of changed requirements that exist after Red Hat Gluster Storage 3.1.3. If you want to access a volume being provided by a Red Hat Gluster Storage 3.1.3 or higher server, your client must also be using Red Hat Gluster Storage 3.1.3 or higher. Accessing volumes from other client versions can result in data becoming unavailable and problems with directory operations. This requirement exists because Red Hat Gluster Storage 3.1.3 contained a number of changes that affect how the Distributed Hash Table works in order to improve directory consistency and remove the effects seen in BZ#1115367 and BZ#1118762 . Important RHEL 8 is supported only for new installations of Red Hat Gluster Storage 3.5.2. Upgrades to RHEL 8 based Red Hat Gluster Storage 3.5.2 are not supported . Important In Red Hat Enterprise Linux 7 based Red Hat Gluster Storage, updating to 3.1 or higher reloads firewall rules. All runtime-only changes made before the reload are lost. 7.1. Prerequisites Verify that no self-heal operations are in progress. Ensure that the gluster volume corresponding to Glusterfs Storage Domain does not have any pending self heal by executing the following command:

Commands:
gluster volume heal volname info
gluster volume heal volname info summary
7. Clustering Clusters are multiple computers (nodes) working in concert to increase reliability, scalability, and availability to critical production services. High Availability using Red Hat Enterprise Linux 6 can be deployed in a variety of configurations to suit varying needs for performance, high-availability, load balancing, and file sharing. Note The Cluster Suite Overview document provides an overview of Red Hat Cluster Suite for Red Hat Enterprise Linux 6. Additionally, the High Availability Administration document describes the configuration and management of Red Hat cluster systems for Red Hat Enterprise Linux 6. 7.1. Corosync Cluster Engine Red Hat Enterprise Linux 6 utilizes the Corosync Cluster Engine for core cluster functionality. 7.2. Unified Logging Configuration The various daemons that High Availability employs now utilize a shared unified logging configuration. This allows system administrators to enable, capture and read cluster system logs via a single command in the cluster configuration. 7.3. High Availability Administration Conga is an integrated set of software components that provides centralized configuration and management for Red Hat Enterprise Linux High Availability. One of the primary components of Conga is luci, a server that runs on one computer and communicates with multiple clusters and computers. In Red Hat Enterprise Linux 6 the web interface that is used to interact with luci has been redesigned. 7.4. General High Availability Improvements In addition to the features and improvements detailed above, the following features and enhancements to clustering have been implemented for Red Hat Enterprise Linux 6. Enhanced support for Internet Protocol version 6 (IPv6) SCSI persistent reservation fencing support is improved. Virtualized KVM guests can now be run as managed services.

Commands:
probe::ioscheduler_trace.unplug_io Name probe::ioscheduler_trace.unplug_io - Fires when a request queue is unplugged; Synopsis Values name Name of the probe point rq_queue request queue Description Either, when number of pending requests in the queue exceeds threshold or, upon expiration of timer that was activated when queue was plugged.

Commands:
ioscheduler_trace.unplug_io
5.233. perl-DBD-Pg 5.233.1. RHSA-2012:1116 - Moderate: perl-DBD-Pg security update An updated perl-DBD-Pg package that fixes two security issues is now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Perl DBI is a database access Application Programming Interface (API) for the Perl language. perl-DBD-Pg allows Perl applications to access PostgreSQL database servers. Security Fix CVE-2012-1151 Two format string flaws were found in perl-DBD-Pg. A specially-crafted database warning or error message from a server could cause an application using perl-DBD-Pg to crash or, potentially, execute arbitrary code with the privileges of the user running the application. All users of perl-DBD-Pg are advised to upgrade to this updated package, which contains a backported patch to fix these issues. Applications using perl-DBD-Pg must be restarted for the update to take effect.

Commands:
Chapter 1. Kickstart Installations 1.1. What are Kickstart Installations? Many system administrators would prefer to use an automated installation method to install Red Hat Enterprise Linux on their machines. To answer this need, Red Hat, Inc created the kickstart installation method. Using kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation. Kickstart files can be kept on a single server system and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators. Kickstart provides a way for users to automate a Red Hat Enterprise Linux installation.

Commands:
6.11. RHEA-2013:0339 - new packages: tbb New tbb packages are now available for Red Hat Enterprise Linux 6. The tbb packages contain a C++ runtime library that abstracts the low-level threading details necessary for optimal multi-core performance. This enhancement update adds the tbb packages to Red Hat Enterprise Linux 6. (BZ# 844976 ) All users who require tbb are advised to install these new packages.

Commands:
C.21. Transactions org.infinispan.interceptors.TxInterceptor The Transactions component manages the cache's participation in JTA transactions. Table C.33. Attributes Name Description Type Writable commits Number of transaction commits performed since last reset. long No prepares Number of transaction prepares performed since last reset. long No rollbacks Number of transaction rollbacks performed since last reset. long No statisticsEnabled Enables or disables the gathering of statistics by this component. boolean Yes Table C.34. Operations Name Description Signature resetStatistics Resets statistics gathered by this component. void resetStatistics() 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
7.47. eclipse-nls 7.47.1. RHBA-2013:0357 - eclipse-nls bug fix and enhancement update Updated eclipse-nls packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The eclipse-nls packages provide Native Language Support langpacks for the Eclipse IDE that contain translations into many languages. Note The clipse-nls packages have been upgraded to upstream version 3.6.0.v20120721114722, which updates the language packs and provides a number of bug fixes and enhancements over the version. (BZ# 692358 ) All users of eclipse-nls are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
2.2.9. Ruby The ruby package provides the Ruby interpreter and adds support for the Ruby programming language. The ruby-devel package contains the libraries and header files required for developing Ruby extensions. Red Hat Enterprise Linux also ships with numerous ruby -related packages. By convention, the names of these packages have a ruby or rubygem prefix or suffix. Such packages are either library extensions or Ruby bindings to an existing library. Examples of ruby -related packages include: ruby-flexmock rubygem-flexmock rubygems ruby-irb ruby-libguestfs ruby-libs ruby-qpid ruby-rdoc ruby-ri ruby-saslwrapper ruby-static ruby-tcltk For information about updates to the Ruby language in Red Hat Enterprise Linux 6, see the following resources: file:///usr/share/doc/ruby- version /NEWS file:///usr/share/doc/ruby- version /NEWS- version 2.2.9.1. Ruby Documentation For more information about Ruby, see man ruby . You can also install ruby-docs , which provides HTML manuals and references in the following location: file:///usr/share/doc/ruby-docs- version / The main site for the development of Ruby is hosted on http://www.ruby-lang.org . The http://www.ruby-doc.org site also contains Ruby documentation.

Commands:
Chapter 3. Known issues ENTMQIC-1980 - Symbolic ports in HTTP listeners do not work When configuring a listener in the router with the http option enabled (for console or WebSocket access), the port attribute must be expressed numerically. Symbolic port names do not work with HTTP listeners. If a listener is configured as: It should be changed to: Revised on 2020-10-08 11:22:32 UTC

Commands:
listener { port: amqp http: yes }
listener { port: 5672 http: yes }
A.3. Synchronizing Quotas with the gfs2_quota Command GFS2 stores all quota information in its own internal file on disk. A GFS2 node does not update this quota file for every file system write; rather, by default it updates the quota file once every 60 seconds. This is necessary to avoid contention among nodes writing to the quota file, which would cause a slowdown in performance. As a user or group approaches their quota limit, GFS2 dynamically reduces the time between its quota-file updates to prevent the limit from being exceeded. The normal time period between quota synchronizations is a tunable parameter, quota_quantum . You can change this from its default value of 60 seconds using the quota_quantum= mount option, as described in Table 4.2, "GFS2-Specific Mount Options" . The quota_quantum parameter must be set on each node and each time the file system is mounted. Changes to the quota_quantum parameter are not persistent across unmounts. You can update the quota_quantum value with the mount -o remount . You can use the gfs2_quota sync command to synchronize the quota information from a node to the on-disk quota file between the automatic updates performed by GFS2. Usage Synchronizing Quota Information MountPoint Specifies the GFS2 file system to which the actions apply. Tuning the Time Between Synchronizations MountPoint Specifies the GFS2 file system to which the actions apply. secs Specifies the new time period between regular quota-file synchronizations by GFS2. Smaller values may increase contention and slow down performance. Examples This example synchronizes the quota information from the node it is run on to file system /mygfs2 . This example changes the default time period between regular quota-file updates to one hour (3600 seconds) for file system /mnt/mygfs2 when remounting that file system on logical volume /dev/volgroup/logical_volume .

Commands:
gfs2_quota sync -f MountPoint
mount -o quota_quantum= secs ,remount BlockDevice MountPoint
gfs2_quota sync -f /mygfs2
mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2
6.4. Setting the Size of the DN Cache The entryrdn index is used to associate DNs and RDNs with entries. It enables the server to efficiently perform subtree rename , entry move , and moddn operations. The DN cache is used to cache the in-memory representation of the entryrdn index to avoid expensive file I/O and transformation operations. For best performance, especially with but not limited to entry rename and move operations, set the DN cache to a size that enables Directory Server to cache all DNs in the database. If a DN is not stored in the cache, Directory Server reads the DN from the entryrdn.db index database file and converts the DNs from the on-disk format to the in-memory format. DNs that are stored in the cache enable the server to skip the disk I/O and conversion steps. 6.4.1. Setting the Size of the DN Cache Using the Command Line To set the DN cache size of a database using the command line: Display the suffixes and their corresponding back end: This command displays the name of the back end database to each suffix. You require the suffix's database name in the step. To disable database and entry cache auto-sizing, enter: To set the DN cache size, enter: This command sets the DN cache for the userRoot database to 20 megabytes. Restart the Directory Service instance: 6.4.2. Setting the Size of the DN Cache Using the Web Console To set DN cache size of a database using the Web Console: Open the Directory Server user interface in the web console. For details, see Logging Into Directory Server Using the Web Console section in the Red Hat Directory Server Administration Guide . Select the instance. On the Database tab, select the suffix for which you want to set the DN cache size. Enter the size in bytes into the DN Cache Size (bytes) field. Click Save Configuration . Click the Actions button, and select Restart Instance .

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com suffix list dc=example,dc=com ( userroot )
dsconf -D "cn=Directory Manager" ldap://server.example.com backend config set --cache-autosize=0
dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --dncache-memsize= 20971520 userRoot
dsctl instance_name restart