mtpti5iD/redhat-docs_dataset huggingface dataset:
B.84.2. RHSA-2011:0305 - Important: samba security update Updated samba packages that fix one security issue are now available for Red Hat Enterprise Linux 4, 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. Samba is a suite of programs used by machines to share files, printers, and other information. CVE-2011-0719 A flaw was found in the way Samba handled file descriptors. If an attacker were able to open a large number of file descriptors on the Samba server, they could flip certain stack bits to "1" values, resulting in the Samba server (smbd) crashing. Red Hat would like to thank the Samba team for reporting this issue. Users of Samba are advised to upgrade to these updated packages, which contain a backported patch to resolve this issue. After installing this update, the smb service will be restarted automatically.

Commands:
Chapter 3. Retrieving the container images Use the following procedure, and its example file contents, to retrieve the container images you need for deployments with separate heat stacks. For more information, see Preparing container images . Procedure Add your Registry Service Account credentials to containers.yaml . Generate the environment file as ~/containers-env-file.yaml : In Deploying the central controllers and Deploying HCI nodes to the distributed compute node (DCN) site , the resulting ~/containers-env-file.yaml file is included as part of the overcloud deployment procedure.

Commands:
parameter_defaults: NeutronMechanismDrivers: ovn ContainerImagePrepare: - push_destination: 192.168.24.1:8787 set: ceph_namespace: registry.redhat.io/rhceph ceph_image: rhceph-4-rhel8 ceph_tag: latest name_prefix: openstack- namespace: registry.redhat.io/rhosp16-rhel8 tag: latest ContainerImageRegistryCredentials: # https://access.redhat.com/RegistryAuthentication registry.redhat.io: registry-service-account-username: registry-service-account-password
openstack tripleo container image prepare -e containers.yaml --output-env-file ~/containers-env-file.yaml
Chapter 22. Upgrade Parameters You can modify the behavior of the upgrade process with upgrade parameters. Parameter Description UpgradeInitCommand Command or script snippet to run on all overcloud nodes to initialize the upgrade process. For example, a repository switch. UpgradeInitCommonCommand Common commands required by the upgrades process. This should not normally be modified by the operator and is set and unset in the major-upgrade-composable-steps.yaml and major-upgrade-converge.yaml environment files. UpgradeLeappCommandOptions Additional command line options to append to the Leapp command. UpgradeLeappDebug Print debugging output when running Leapp. The default value is true . UpgradeLeappDevelSkip Skip Leapp checks by setting env variables when running Leapp in development/testing. For example, LEAPP_DEVEL_SKIP_RHSM=1. UpgradeLeappEnabled Use Leapp for operating system upgrade. The default value is false . UpgradeLeappPostRebootDelay Maximum (seconds) to wait for machine to reboot and respond to a test command. The default value is 120 . UpgradeLeappRebootTimeout Timeout (seconds) for the OS upgrade phase via Leapp. The default value is 3600 . UpgradeLeappToInstall List of packages to install after Leapp upgrade. UpgradeLeappToRemove List of packages to remove during Leapp upgrade.

Commands:
10.2. Model Object Editors The primary actions for editing model objects are: Cut - Deletes the selected object(s) and copies it to the clipboard. Copy - Copies the selected object(s) to the clipboard. Paste - Pastes the contents of the clipboard to the selected context. Clone - Duplicates the selected object in the same location with the same name; user is able to rename the new object right in the tree. Delete - Deletes the selected object(s). Rename - Allows a user to rename an object. These actions are presented in Teiid Designer's Edit menu and also in the right-click context menus for model objects selected in the Model Explorer, Dialog Editor and Table Editor. Modeling Sub-Menu In addition to the New Child/Sibling/Association menus available for object creation Teiid Designer provides a Modeling sub-menu which presents various object-specific actions which can be performed. If you select a source table, for instance, the Modeling menu below would be presented: Figure 10.11. Modeling Sub-Menu for Source Table If a view table is selected, the menu would reflect the actions related to virtual operations: Figure 10.12. Modeling Sub-Menu for Source Table Teiid Designer also provides specialized object editors to handle complex model objects and their unique properties.

Commands:
About Builds builds for Red Hat OpenShift 1.1 Introduction to Builds Red Hat OpenShift Documentation Team

Commands:
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: https://github.com/username/taxi strategy: name: buildah kind: ClusterBuildStrategy output: image: registry.mycompany.com/my-org/taxi-app:latest
apiVersion: shipwright.io/v1beta1 kind: ClusterBuildStrategy metadata: name: buildah spec: steps: - name: build-and-push image: quay.io/containers/buildah:v1.31.0 workingDir: USD(params.shp-source-root) command: - /bin/bash #
Chapter 1. Introduction to Metro-DR stretch cluster Red Hat OpenShift Data Foundation deployment can be stretched between two different geographical locations to provide the storage infrastructure with disaster recovery capabilities. When faced with a disaster, such as one of the two locations is partially or totally not available, OpenShift Data Foundation deployed on the OpenShift Container Platform deployment must be able to survive. This solution is available only for metropolitan spanned data centers with specific latency requirements between the servers of the infrastructure. Note Currently, you can deploy the Metro-DR solution using stretch cluster where latencies do not exceed four milliseconds round-trip time (RTT) between the OpenShift Container Platform nodes in different locations. Contact Red Hat Customer Support if you are planning to deploy with higher latencies. The following diagram shows the simplest deployment for a Metro-DR stretched cluster: OpenShift nodes and OpenShift Data Foundation daemons In the diagram the OpenShift Data Foundation monitor pod deployed in the Arbiter zone has a built-in tolerance for the master nodes. The diagram shows the master nodes in each Data Zone which are required for a highly available OpenShift Container Platform control plane. Also, it is important that the OpenShift Container Platform nodes in one of the zones have network connectivity with the OpenShift Container Platform nodes in the other two zones.

Commands:
Chapter 79. JSON Gson Gson is a Data Format which uses the Gson Library . from("activemq:My.Queue"). marshal().json(JsonLibrary.Gson). to("mqseries:Another.Queue"); 79.1. Gson Options The JSON Gson dataformat supports 3 options, which are listed below. Name Default Java Type Description prettyPrint Boolean To enable pretty printing output nicely formatted. Is by default false. unmarshalType String Class name of the java type to use when unmarshalling. contentTypeHeader Boolean Whether the data format should set the Content-Type header with the type from the data format. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSON. 79.2. Dependencies To use Gson in your camel routes you need to add the dependency on camel-gson which implements this data format. If you use maven you could 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-gson</artifactId> <version>{CamelSBVersion}</version> <!-- use the same version as your Camel core version --> </dependency> 79.3. Spring Boot Auto-Configuration When using json-gson with Spring Boot make sure to use the following Maven dependency to have support for auto configuration: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-gson-starter</artifactId> </dependency> The component supports 4 options, which are listed below. Name Description Default Type camel.dataformat.json-gson.content-type-header Whether the data format should set the Content-Type header with the type from the data format. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSON. true Boolean camel.dataformat.json-gson.enabled Whether to enable auto configuration of the json-gson data format. This is enabled by default. Boolean camel.dataformat.json-gson.pretty-print To enable pretty printing output nicely formatted. Is by default false. false Boolean camel.dataformat.json-gson.unmarshal-type Class name of the java type to use when unmarshalling. String

Commands:
from("activemq:My.Queue"). marshal().json(JsonLibrary.Gson). to("mqseries:Another.Queue");
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-gson</artifactId> <version>{CamelSBVersion}</version> <!-- use the same version as your Camel core version --> </dependency>
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-gson-starter</artifactId> </dependency>
Chapter 9. Red Hat JBoss Data Grid Security: Authorization and Authentication 9.1. Red Hat JBoss Data Grid Security: Authorization and Authentication Red Hat JBoss Data Grid is able to perform authorization on CacheManagers and Caches. JBoss Data Grid authorization is built on standard security features available in a JDK, such as JAAS and the SecurityManager. If an application attempts to interact with a secured CacheManager and Cache, it must provide an identity which JBoss Data Grid's security layer can validate against a set of required roles and permissions. Once validated, the client is issued a token for subsequent operations. Where access is denied, an exception indicating a security violation is thrown. When a cache has been configured for with authorization, retrieving it returns an instance of SecureCache . SecureCache is a simple wrapper around a cache, which checks whether the "current user" has the permissions required to perform an operation. The "current user" is a Subject associated with the AccessControlContext . JBoss Data Grid maps Principals names to roles, which in turn, represent one or more permissions. The following diagram represents these relationships: Figure 9.1. Roles and Permissions Mapping Report a bug

Commands:
2.2. Types of Storage Backing Storage Domains Storage domains can be implemented using block based and file based storage. File Based Storage The file based storage types supported by Red Hat Virtualization are NFS, GlusterFS, other POSIX compliant file systems, and storage local to hosts. File based storage is managed externally to the Red Hat Virtualization environment. NFS storage is managed by a Red Hat Enterprise Linux NFS server, or other third party network attached storage server. Hosts can manage their own local storage file systems. Block Based Storage Block storage uses unformatted block devices. Block devices are aggregated into volume groups by the Logical Volume Manager (LVM). An instance of LVM runs on all hosts, unaware of the instances running on other hosts. VDSM adds clustering logic on top of LVM by scanning volume groups for changes. When changes are detected, VDSM updates individual hosts by telling them to refresh their volume group information. The hosts divide the volume group into logical volumes, writing logical volume metadata to disk. If more storage capacity is added to an existing storage domain, the Red Hat Virtualization Manager causes VDSM on each host to refresh volume group information. A Logical Unit Number (LUN) is an individual block device. One of the supported block storage protocols, iSCSI or Fibre Channel, is used to connect to a LUN. The Red Hat Virtualization Manager manages software iSCSI connections to the LUNs. All other block storage connections are managed externally to the Red Hat Virtualization environment. Any changes in a block based storage environment, such as the creation of logical volumes, extension or deletion of logical volumes and the addition of a new LUN are handled by LVM on a specially selected host called the Storage Pool Manager. Changes are then synced by VDSM which storage metadata refreshes across all hosts in the cluster.

Commands:
Appendix A. GFS2 Quota Management with the gfs2_quota Command As of the Red Hat Enterprise Linux 6.1 release, GFS2 supports the standard Linux quota facilities. In order to use this you will need to install the quota RPM. This is the preferred way to administer quotas on GFS2 and should be used for all new deployments of GFS2 using quotas. For information on using the standard Linux quota facilities, see Section 4.5, "GFS2 Quota Management" . For earlier releases of Red Hat Enterprise Linux, GFS2 required the gfs2_quota command to manage quotas. This appendix documents the use of the gfs2_quota command for managing GFS2 file system quotas. A.1. Setting Quotas with the gfs2_quota command Two quota settings are available for each user ID (UID) or group ID (GID): a hard limit and a soft limit . A hard limit is the amount of space that can be used. The file system will not let the user or group use more than that amount of disk space. A hard limit value of zero means that no limit is enforced. A soft limit is usually a value less than the hard limit. The file system will notify the user or group when the soft limit is reached to warn them of the amount of space they are using. A soft limit value of zero means that no limit is enforced. You can set limits using the gfs2_quota command. The command only needs to be run on a single node where GFS2 is mounted. By default, quota enforcement is not set on GFS2 file systems. To enable quota accounting, use the quota= of the mount command when mounting the GFS2 file system, as described in Section A.4, "Enabling/Disabling Quota Enforcement" . Usage Setting Quotas, Hard Limit Setting Quotas, Warn Limit User A user ID to limit or warn. It can be either a user name from the password file or the UID number. Group A group ID to limit or warn. It can be either a group name from the group file or the GID number. Size Specifies the new value to limit or warn. By default, the value is in units of megabytes. The additional -k , -s and -b flags change the units to kilobytes, sectors, and file system blocks, respectively. MountPoint Specifies the GFS2 file system to which the actions apply. Examples This example sets the hard limit for user Bert to 1024 megabytes (1 gigabyte) on file system /mygfs2 . This example sets the soft limit for group ID 21 to 50 kilobytes on file system /mygfs2 .

Commands:
gfs2_quota limit -u User -l Size -f MountPoint
gfs2_quota limit -g Group -l Size -f MountPoint
gfs2_quota warn -u User -l Size -f MountPoint
gfs2_quota warn -g Group -l Size -f MountPoint
gfs2_quota limit -u Bert -l 1024 -f /mygfs2
gfs2_quota warn -g 21 -l 50 -k -f /mygfs2
5.344. valgrind 5.344.1. RHBA-2012:0936 - valgrind bug fix and enhancement update Updated valgrind packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The valgrind packages provide a programming utility for debugging memory, detecting memory leaks, and profiling. Bug Fix BZ# 757728 Prior to this update, the "memalign" and "posix_memalign" replacements could only handle alignments of 1 MB maximum. As a consequence, running qemu-kvm in valgrind could cause alignment errors. This update modifies the underlying code so that memalign and posix_memalign replacement can now handle alignments up to 4 MB. Enhancement BZ# 739143 With this update, valgrind has been updated to provide complete support for IBM POWER7 Series and VPN-1 Power VSX hardware as well as support for Decimal Floating Point (DFP). All users of valgrind are advised to upgrade to these updated packages, which fix this bug add this enhancement.

Commands:
Preface This document provides instructions on how to convert your operating system from the following Linux distributions to Red Hat Enterprise Linux (RHEL) 7, RHEL 8, and RHEL 9: Alma Linux CentOS Linux Oracle Linux Rocky Linux The conversion is performed by the Convert2RHEL utility. Note The conversion from Scientific Linux to RHEL is not currently supported by Red Hat. For information about an unsupported conversion, see How to perform an unsupported conversion from a RHEL-derived Linux distribution to RHEL .

Commands:
Chapter 1. What is Red Hat Ceph Storage? Red Hat Ceph Storage is a scalable, open, software-defined storage platform that combines an enterprise-hardened version of the Ceph storage system with a Ceph management platform, deployment utilities, and support services. Red Hat Ceph Storage is designed for cloud infrastructure and web-scale object storage. Red Hat Ceph Storage clusters consist of the following types of nodes: Red Hat Ceph Storage Ansible administration The Ansible administration node replaces the traditional Ceph administration node used in versions of Red Hat Ceph Storage. The Ansible administration node provides the following functions: Centralized storage cluster management. The Ceph configuration files and keys. Optionally, local repositories for installing Ceph on nodes that cannot access the Internet for security reasons. Ceph Monitor Each Ceph Monitor node runs the ceph-mon daemon, which maintains a master copy of the storage cluster map. The storage cluster map includes the storage cluster topology. A client connecting to the Ceph storage cluster retrieves the current copy of the storage cluster map from the Ceph Monitor, which enables the client to read from and write data to the storage cluster. Important The storage cluster can run with only one Ceph Monitor; however, to ensure high availability in a production storage cluster, Red Hat will only support deployments with at least three Ceph Monitor nodes. Red Hat recommends deploying a total of 5 Ceph Monitors for storage clusters exceeding 750 Ceph OSDs. Ceph OSD Each Ceph Object Storage Device (OSD) node runs the ceph-osd daemon, which interacts with logical disks attached to the node. The storage cluster stores data on these Ceph OSD nodes. Ceph can run with very few OSD nodes, which the default is three, but production storage clusters realize better performance beginning at modest scales. For example, 50 Ceph OSDs in a storage cluster. Ideally, a Ceph storage cluster has multiple OSD nodes, allowing for the possibility to isolate failure domains by configuring the CRUSH map accordingly. Ceph MDS Each Ceph Metadata Server (MDS) node runs the ceph-mds daemon, which manages metadata related to files stored on the Ceph File System (CephFS). The Ceph MDS daemon also coordinates access to the shared storage cluster. Ceph Object Gateway Ceph Object Gateway node runs the ceph-radosgw daemon, and is an object storage interface built on top of librados to provide applications with a RESTful access point to the Ceph storage cluster. The Ceph Object Gateway supports two interfaces: S3 Provides object storage functionality with an interface that is compatible with a large subset of the Amazon S3 RESTful API. Swift Provides object storage functionality with an interface that is compatible with a large subset of the OpenStack Swift API. Additional Resources For details on the Ceph architecture, see the Red Hat Ceph Storage Architecture Guide . For the minimum hardware recommendations, see the Red Hat Ceph Storage Hardware Selection Guide .

Commands:
Deploying and managing OpenShift Data Foundation using Red Hat OpenStack Platform Red Hat OpenShift Data Foundation 4.11 Instructions on deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install and manage Red Hat OpenShift Data Foundation using Red Hat OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP). Important Deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Commands:
Chapter 14. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 14.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 14.2. Expanding the node port range You can expand the node port range for the cluster. Important You can expand the node port range into the protected port range, which is between 0 and 32767. However, after expansion, you cannot change the range. Attempting to change the range returns the following error: The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the range 0-32767 . Before making changes, ensure that the new range you set is appropriate for your cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 14.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]