mtpti5iD/redhat-docs_dataset huggingface dataset:
3.2.2. Adding Cluster Nodes Note It is highly recommended that you add nodes to existing clusters only during a production maintenance window. This allows you to perform appropriate resource and deployment testing for the new node and its fencing configuration. Use the following procedure to add a new node to an existing cluster. In this example, the existing cluster nodes are clusternode-01.example.com , clusternode-02.example.com , and clusternode-03.example.com . The new node is newnode.example.com . On the new node to add to the cluster, perform the following tasks. Install the cluster packages. If the cluster uses SBD, you must manually install the sbd package on the new node as well. To prevent corosync from starting without cman , execute the following command: Set a password for the user ID hacluster . It is recommended that you use the same password for each node in the cluster. Start and enable pcsd on the new node: On a node in the existing cluster, perform the following tasks. Authenticate user hacluster on the new cluster node. Add the new node to the existing cluster. This command also syncs the cluster configuration file cluster.conf to all nodes in the cluster, including the new node you are adding. On the new node to add to the cluster, perform the following tasks. Enable cluster services on the new node. In Red Hat Enterprise Linux 6, the new node is started automatically by PCS. Ensure that you configure and test a fencing device for the new cluster node. For information on configuring fencing devices, see Chapter 4, Fencing: Configuring STONITH .

Commands:
yum install -y pacemaker cman pcs
chkconfig corosync off
passwd hacluster Changing password for user hacluster. New password: Retype new password: passwd: all authentication tokens updated successfully.
service pcsd start chkconfig pcsd on
pcs cluster auth newnode.example.com Username: hacluster Password: newnode.example.com: Authorized
pcs cluster node add newnode.example.com clusternode-01.example.com: Corosync updated clusternode-02.example.com: Corosync updated clusternode-03.example.com: Corosync updated newnode.example.com: Updated cluster.conf newnode.example.com: Starting Cluster
pcs cluster enable
5.2. Resizing an Online Multipath Device If you need to resize an online multipath device, use the following procedure. Resize your physical device. Execute the following command to find the paths to the LUN: Resize your paths. For SCSI devices, writing a 1 to the rescan file for the device causes the SCSI driver to rescan, as in the following command: Ensure that you run this command for each of the path devices. For example, if your path devices are sda , sdb , sde , and sdf , you would run the following commands: Resize your multipath device by executing the multipathd resize command: Resize the file system (assuming no LVM or DOS partitions are used):

Commands:
multipath -l
echo 1 > /sys/block/ path_device /device/rescan
echo 1 > /sys/block/sda/device/rescan echo 1 > /sys/block/sdb/device/rescan echo 1 > /sys/block/sde/device/rescan echo 1 > /sys/block/sdf/device/rescan
multipathd resize map multipath_device
resize2fs /dev/mapper/mpatha
Chapter 34. Tuning Jakarta Messaging If you use the Jakarta Messaging API, review the following information for tips on how to improve performance. Disable the message ID. If you do not need message IDs, disable them by using the setDisableMessageID() method on the MessageProducer class. Setting the value to true eliminates the overhead of creating a unique ID and decreases the size of the message. Disable the message timestamp. If you do not need message timestamps, disable them by using the setDisableMessageTimeStamp() method on the MessageProducer class. Setting the value to true eliminates the overhead of creating the timestamp and decreases the size of the message. Avoid using ObjectMessage . ObjectMessage is used to send a message that contains a serialized object, meaning the body of the message, or payload, is sent over the wire as a stream of bytes. The Java serialized form of even small objects is quite large and takes up a lot of space on the wire. It is also slow when compared to custom marshalling techniques. Use ObjectMessage only if you cannot use one of the other message types, for example, if you do not know the type of the payload until runtime. Avoid AUTO_ACKNOWLEDGE . The choice of acknowledgement mode in a consumer impacts performance because of the additional overhead and traffic incurred by sending the acknowledgment message sent over the network. AUTO_ACKNOWLEDGE incurs this overhead because it requires an acknowledgement to be sent from the server for each message received on the client. If you can, use DUPS_OK_ACKNOWLEDGE , which acknowledges messages in a lazy manner, CLIENT_ACKNOWLEDGE , meaning the client code will call a method to acknowledge the message, or batch up many acknowledgements with one acknowledge or commit in a transacted session. Avoid durable messages. By default, Jakarta Messaging messages are durable. If you do not need durable messages, set them to be non-durable . Durable messages incur a lot of overhead because they are persisted to storage. Use TRANSACTED_SESSION mode to send and receive messages in a single transaction. By batching messages in a single transaction, the ActiveMQ Artemis server integrated in JBoss EAP requires only one network round trip on the commit, not on every send or receive.

Commands:
Chapter 7. Troubleshooting for CodeReady Workspaces end users 7.1. Restarting a CodeReady Workspaces workspace in debug mode after start failure This section describes how to restart the Red Hat CodeReady Workspaces workspace in debug mode after a failure during workspace start. Prerequisites A running instance of Red Hat CodeReady Workspaces. To install an instance of Red Hat CodeReady Workspaces, see the CodeReady Workspaces 2.1 Installation GuideCodeReady Workspaces 'quick-starts' . An existing workspace that failed to start. Procedure Find the target workspace from the recent workspaces. Click on the target workspace to see the logs. Click the link for restarting in debug mode. Download full logs after start fail with the Download logs link. 7.2. Starting a CodeReady Workspaces workspace in debug mode This section describes how to start the Red Hat CodeReady Workspaces workspace in debug mode. Prerequisites A running instance of Red Hat CodeReady Workspaces. To install an instance of Red Hat CodeReady Workspaces, see the CodeReady Workspaces 2.1 Installation GuideCodeReady Workspaces quick-starts . An existing workspace defined on this instance of Red Hat CodeReady Workspaces. See Creating a new workspace . Procedure Find the target workspace from the recent workspaces. Right-click the workspace name to open a context menu. Select the Run in debug mode item. Click the target workspace to see the logs. The workspace logs are displayed.

Commands:
B.27. glibc B.27.1. RHSA-2010:0872 - Important: glibc security and bug fix update Updated glibc packages that fix two security issues and two bugs are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. 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. The glibc packages contain the standard C libraries used by multiple programs on the system. These packages contain the standard C and the standard math libraries. Without these two libraries, a Linux system cannot function properly. CVE-2010-3847 It was discovered that the glibc dynamic linker/loader did not handle the USDORIGIN dynamic string token set in the LD_AUDIT environment variable securely. A local attacker with write access to a file system containing setuid or setgid binaries could use this flaw to escalate their privileges. CVE-2010-3856 It was discovered that the glibc dynamic linker/loader did not perform sufficient safety checks when loading dynamic shared objects (DSOs) to provide callbacks for its auditing API during the execution of privileged programs. A local attacker could use this flaw to escalate their privileges via a carefully-chosen system DSO library containing unsafe constructors. Red Hat would like to thank Tavis Ormandy for reporting the CVE-2010-3847 issue, and Ben Hawkes and Tavis Ormandy for reporting the CVE-2010-3856 issue. Bug Fixes BZ# 643341 Previously, the generic implementation of the strstr() and memmem() functions did not handle certain periodic patterns correctly and could find a false positive match. This error has been fixed, and both functions now work as expected. BZ# 643343 The "TCB_ALIGNMENT" value has been increased to 32 bytes to prevent applications from crashing during symbol resolution on 64-bit systems with support for Intel AVX vector registers. All users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
Introduction Red Hat is pleased to announce the availability of Red Hat Enterprise Linux 7, the generation of Red Hat's comprehensive suite of operating systems, designed for mission-critical enterprise computing and certified by top enterprise software and hardware vendors. In this release, Red Hat brings together improvements across the server, systems, and the overall Red Hat open source experience. Among others, Red Hat Enterprise Linux 7 introduces: XFS as the default file system; a new boot loader and a fully redesigned graphical installer; the systemd system and service manager; the kernel patching utility, kpatch , Technology Preview, which allows users to patch the kernel without rebooting; the Docker environment that allows users to deploy any application as a lightweight and portable container; the Hardware Event Report Mechanism (HERM) that refactors the Error Detection and Correction (EDAC) mechanism of dual in-line memory module (DIMM) error reporting; the OpenLMI project providing a common infrastructure for the management of Linux systems. For detailed information about new features, see the respective categories in Part I, "New Features" . Known problems are listed in Part III, "Known Issues" . If you are upgrading from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, consult the Migration Planning Guide for assistance with the migration process. Capabilities and limits of Red Hat Enterprise Linux 7 as compared to the versions of the system are available in the following Knowledge Base article: https://access.redhat.com/site/articles/rhel-limits

Commands:
Chapter 7. Downgrading Red Hat Quay Red Hat Quay only supports rolling back, or downgrading, to z-stream versions, for example, 3.7.2 3.7.1. Rolling back to y-stream versions (3.7.0 3.6.0) is not supported. This is because Red Hat Quay updates might contain database schema upgrades that are applied when upgrading to a new version of Red Hat Quay. Database schema upgrades are not considered backwards compatible. Important Downgrading to z-streams is neither recommended nor supported by either Operator based deployments or virtual machine based deployments. Downgrading should only be done in extreme circumstances. The decision to rollback your Red Hat Quay deployment must be made in conjunction with the Red Hat Quay support and development teams. For more information, contact Red Hat Quay support.

Commands:
Chapter 4. Important links AMQ Clients 2.9.x Resolved Issues Red Hat AMQ 7 Supported Configurations Red Hat AMQ 7 Component Details AMQ Clients 2.8 Release Notes AMQ Clients 2.7 Release Notes AMQ Clients 2.6 Release Notes AMQ Clients 2.5 Release Notes AMQ Clients 2.4 Release Notes AMQ Clients 2.3 Release Notes AMQ Clients 2.2 Release Notes AMQ Clients 2.1 Release Notes AMQ Clients 2.0 Release Notes AMQ Clients 1.2 Release Notes AMQ Clients 1.1 Release Notes Revised on 2021-05-19 08:48:21 UTC

Commands:
Chapter 3. Designing the Directory Schema The site survey conducted in Chapter 2, Planning the Directory Data revealed information about the data which will be stored in the directory. The directory schema describes the types of data in the directory, so determining what schema to use reflects decisions on how to represent the data stored in the directory. During the schema design process, each data element is mapped to an LDAP attribute, and related elements are gathered into LDAP object classes. A well-designed schema helps to maintain the integrity of the directory data. This chapter describes the directory schema and how to design a schema for unique organizational needs. For information on replicating a schema, see Section 7.4.4, "Schema Replication" . 3.1. Schema Design Process Overview During the schema design process, select and define the object classes and attributes used to represent the entries stored by Red Hat Directory Server. Schema design involves the following steps: Choosing predefined schema elements to meet as many of data needs as possible. Extending the standard Directory Server schema to define new elements to meet other remaining needs. Planning for schema maintenance. The simplest and most easily-maintained option is to use existing schema elements defined in the standard schema provided with Directory Server. Choosing standard schema elements helps ensure compatibility with directory-enabled applications. Because the schema is based on the LDAP standard, it has been reviewed and agreed to by a wide number of directory users.

Commands:
3.8. Appendix - Performance Categorization There are a number of infrastructure and architectural factors that determine the potential performance that Red Hat Gluster Storage within Microsoft Azure can deliver. 3.8.1. Storage Type Microsoft Azure offers two classes of physical storage: standard and premium. Standard storage is backed by hard disk drives, whereas premium storage is delivered by solid state drives. These classes of storage provide an IOPS target of 500 IOPS and 5,000 IOPS per disk, respectively. A more general consideration is how the data are protected. By default, Microsoft Azure protects the data by synchronously storing three copies of data in separate failure domains, and then asynchronously places another three copies of the data in a secondary datacenter (a default GRS replication scheme). 3.8.2. Bandwidth A simple test was performed using iperf to determine the upper limit between the client and Red Hat Gluster Storage node. This testing showed that a single network interface can be expected to deliver between 600 - 700 Mbit. 3.8.3. Disk Latencies Four disks were attached to a Standard Tier/A2 instance and aggregated to form a RAID0 set using the mdadm tool. The LUN was then configured using recommended best practices, based on LVM, dm-thinp, and the XFS file system. The fio tool was then used to reveal the random read profile of the underlying disks at increasing levels of concurrency. Figure 3.3. Disk Latencies This benchmark does not produce a definitive result, but it indicates the potential I/O profile of the underlying storage. Observations Typical latencies are in the 20 - 50 ms range. Attaining higher IOPS requires a multi-threaded workload; that is, one thread=32 IOPS, 32 threads = 961 IOPS. Combining the virtual drives with mdadm allows the LUN to deliver IOPS beyond that of a single virtual disk. 3.8.4. GlusterFS The performance tests for Gluster Storage are only indicative and illustrate the expected performance from a similar environment. For the purposes of benchmarking, the smallfile tool has been used to simulate multiple concurrent file creations that are typical of user environments. The create workload creates a series of 10 MB files within a nested directory hierarchy, exercising metadata operations as well as file creation and throughput. Figure 3.4. Gluster Performance: Small File "Create" Workload Observations: Although the native file system starts well, a performance cross-over occurs between 8 - 12 threads, with the native file system fading and the GlusterFS volume continuing to scale. The throughput of the GlusterFS volume scales linearly with the increase in client workload. At higher concurrency, the GlusterFS volume outperforms the local file system by up to 47%. During high concurrency, the native file system slows down under load. Examining the disk subsystems statistics during the test run revealed the issue was increased I/O wait times (70 - 90%).

Commands:
probe::ioblock_trace.request Name probe::ioblock_trace.request - Fires just as a generic block I/O request is created for a bio. Synopsis ioblock_trace.request Values q request queue on which this bio was queued. size total size in bytes idx offset into the bio vector array phys_segments - number of segments in this bio after physical address coalescing is performed. vcnt bio vector count which represents number of array element (page, offset, length) which make up this I/O request bdev target block device p_start_sect points to the start sector of the partition structure of the device ino i-node number of the mapped file rw binary trace for read/write request name name of the probe point sector beginning sector for the entire bio bdev_contains points to the device object which contains the partition (when bio structure represents a partition) devname block device name flags see below BIO_UPTODATE 0 ok after I/O completion BIO_RW_BLOCK 1 RW_AHEAD set, and read/write would block BIO_EOF 2 out-out-bounds error BIO_SEG_VALID 3 nr_hw_seg valid BIO_CLONED 4 doesn't own data BIO_BOUNCED 5 bio is a bounce bio BIO_USER_MAPPED 6 contains user pages BIO_EOPNOTSUPP 7 not supported bytes_done number of bytes transferred Context The process makes block I/O request

Commands:
Inspecting your SBOM using Red Hat Trusted Profile Analyzer Red Hat Trusted Application Pipeline 1.4 Learn how to scan your SBOM to gain actionable information about the security posture of your application. Red Hat Customer Content Services

Commands:
cosign download sbom quay.io/redhat/rhtap-app:8d34c03188cf294a77339b2a733b1f6811263a369b309e6b170d9b489abc0334 > /tmp/sbom.json
vim /tmp/sbom.json "component": { "bom-ref": "fdef64df97f1d419", "type": "file", "name": "/var/lib/containers/storage/vfs/dir/3b3009adcd335d2b3902c5a7014d22b2beb6392b1958f1d9c7aabe24acab2deb" #Replace this with a meaningful name }
bombastic_api_url="https://USD(oc -n rhtap-tpa get route --selector app.kubernetes.io/name=bombastic-api -o jsonpath='{.items[].spec.host}')"
token_issuer_url=https://USD(oc -n rhtap-keycloak get route --selector app=keycloak -o jsonpath='{.items[].spec.host}')/realms/chicken/protocol/openid-connect/token
TPA__OIDC__WALKER_CLIENT_SECRET=USD(kubectl get -n rhtap secrets/rhtap-trustification-integration --template={{.data.oidc_client_secret}} | base64 -d)
tpa_token=USD(curl -d 'client_id=walker' -d "client_secret=USDTPA__OIDC__WALKER_CLIENT_SECRET" -d 'grant_type=client_credentials' "USDtoken_issuer_url" | jq -r .access_token)
curl -H "authorization: Bearer USDtpa_token" -H "transfer-encoding: chunked" -H "content-type: application/json" --data @/tmp/sbom.json "USDbombastic_api_url/api/v1/sbom?id=my-sbom"
syft convert /tmp/sbom.json -o cyclonedx-json@1.4=/tmp/sbom-1-4.json
curl -H "authorization: Bearer USDtpa_token" -H "transfer-encoding: chunked" -H "content-type: application/json" --data @/tmp/sbom-1-4.json "USDbombastic_api_url/api/v1/sbom?id=my-sbom"
Appendix B. Revision History Revision History Revision 11-85 Fri Mar 10 2017 Jiri Herrmann Prepared the guide for 6.9 GA publication Revision 11-83 Mon Jan 02 2017 Jiri Herrmann Prepared the guide for 6.9 beta publication Revision 11-82 Mon May 02 2016 Jiri Herrmann Prepared the guide for 6.8 GA publication Revision 11-81 Tue Mar 01 2016 Jiri Herrmann Updated the guide for 6.8 beta publication Revision 11-80 Thu Oct 08 2015 Jiri Herrmann Cleaned up the Revision History Revision 11-79 Wed July 15 2015 Dayle Parker Version for 6.7 GA release.

Commands:
Chapter 10. Distributed tracing The client offers distributed tracing based on the Jaeger implementation of the OpenTracing standard. 10.1. Enabling distributed tracing Use the following steps to enable tracing in your application: Procedure Add the Jaeger client dependency to your POM file. <dependency> <groupId>io.jaegertracing</groupId> <artifactId>jaeger-client</artifactId> <version> USD{jaeger-version} </version> </dependency> USD{jaeger-version} must be 1.0.0 or later. Add the jms.tracing option to your connection URI. Set the value to opentracing . Example: A connection URI with tracing enabled Register the global tracer. Example: Global tracer registration import io.jaegertracing.Configuration; import io.opentracing.Tracer; import io.opentracing.util.GlobalTracer; public class Example { public static void main(String[] args) { Tracer tracer = Configuration.fromEnv(" <service-name> ").getTracer(); GlobalTracer.registerIfAbsent(tracer); // ... } } Configure your environment for tracing. Example: Tracing configuration USD export JAEGER_SAMPLER_TYPE=const USD export JAEGER_SAMPLER_PARAM=1 USD java -jar example.jar net.example.Example The configuration shown here is for demonstration purposes. For more information about Jaeger configuration, see Configuration via Environment and Jaeger Sampling . To view the traces your application captures, use the Jaeger Getting Started to run the Jaeger infrastructure and console.

Commands:
<dependency> <groupId>io.jaegertracing</groupId> <artifactId>jaeger-client</artifactId> <version> USD{jaeger-version} </version> </dependency>
amqps://example.net? jms.tracing=opentracing
import io.jaegertracing.Configuration; import io.opentracing.Tracer; import io.opentracing.util.GlobalTracer; public class Example { public static void main(String[] args) { Tracer tracer = Configuration.fromEnv(" <service-name> ").getTracer(); GlobalTracer.registerIfAbsent(tracer); // } }
export JAEGER_SAMPLER_TYPE=const export JAEGER_SAMPLER_PARAM=1 java -jar example.jar net.example.Example
8.193. sblim-sfcc 8.193.1. RHBA-2013:1692 - sblim-sfcc bug fix update Updated sblim-sfcc packages that fix one bug are now available for Red Hat Enterprise Linux 6. The small footprint CIM client library (sblim-sfcc) is a C API allowing client applications to interface with CIM (Common Information Model) implementations (e.g. CIM servers). Due to its small memory and disk footprint it is well-suited for embedded environments. Bug Fix BZ# 875011 Previously, when the attribute "EnumerateInstances" was present in a KEYVALUE pair, the sfcc client failed to parse the XML file and the client terminated unexpectedly with a core dump being generated. This bug has been fixed and the sfcc client now successfully parses XML files with the aforementioned attribute. Users of sblim-sfcc are advised to upgrade to these updated packages, which fix this bug.

Commands: