mtpti5iD/redhat-docs_dataset huggingface dataset:
13.12. Interoperability Between Hot Rod C++ and Hot Rod Java Client Red Hat JBoss Data Grid provides interoperability between Hot Rod Java and Hot Rod C++ clients to access structured data. This is made possible by structuring and serializing data using Google's Protobuf format. For example, using interoperability between languages would allow a Hot Rod C++ client to write the following Person object structured and serialized using Protobuf, and the Java C++ client can read the same Person object structured as Protobuf. Example 13.10. Using Interoperability Between Languages Although it is neither enforced or supported, it is recommended that the Hot Rod Java client use the shipped Protostream library for serializing Protobuf objects. Protobuf library is a recommended serialization solution for C++ ( https://code.google.com/p/protobuf/ ). Interoperability between C++ and Hot Rod Java Client is fully supported for primitive data types, strings, and byte arrays, as Protobuf and Protostream are not required for these types of interoperability. For information about how the C++ client can read Protobuf encoded data, see https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remote-query/src/main/cpp . Report a bug

Commands:
package sample; message Person { required int32 age = 1; required string name = 2; }
Chapter 7. Recommended minimum hardware requirements for the Red Hat Ceph Storage Dashboard The Red Hat Ceph Storage Dashboard has minimum hardware requirements. Minimum requirements 4 core processor at 2.5 GHz or higher 8 GB RAM 50 GB hard disk drive 1 Gigabit Ethernet network interface Additional Resources For more information, see Monitoring a Ceph storage cluster with the Red Hat Ceph Storage Dashboard in the Administration Guide .

Commands:
18.12.6. Reserved Variables Table 18.2, "Reserved variables" shows the variables that are considered reserved and are used by libvirt: Table 18.2. Reserved variables Variable Name Definition MAC The MAC address of the interface IP The list of IP addresses in use by an interface IPV6 Not currently implemented: the list of IPV6 addresses in use by an interface DHCPSERVER The list of IP addresses of trusted DHCP servers DHCPSERVERV6 Not currently implemented: The list of IPv6 addresses of trusted DHCP servers CTRL_IP_LEARNING The choice of the IP address detection mode

Commands:
Chapter 1. Workload Availability for Red Hat OpenShift 24.3 release notes Workload Availability for Red Hat OpenShift version 24.3 is now available. 1.1. New features and enhancements This release adds improvements related to the following components and concepts. The Self Node Remediation (SNR) Operator now includes an update to the the minimum time duration that the Operator waits before recovering affected workloads running on an unhealthy node. Previously, when configuring the safeTimeToAssumeNodeRebootedSeconds parameter, you could not specify a value that was lower than the minimum value calculated as it prevented the Operator from functioning. With this release, the safeTimeToAssumeNodeRebootedSeconds parameter is now optional, and the validation of the value is postponed from configuration time to remediation time. This improved calculation method means the minimum value is dynamically calculated against the current cluster's conditions, with the result that the Operator will function. For more information on the safeTimeToAssumeNodeRebootedSeconds parameter, see the Understanding the Self Node Remediation Operator configuration section of the documentation. The Node Health Check (NHC) Operator can be used with different remediation providers to remediate unhealthy nodes, known as escalatingRemediations . Previously, each remediation provider was limited to be used on only one occasion. With this release, the NHC Operator allows the usage of different templates of the same remediation provider, as long as the remediation provider also supports this usage. The latest releases of the remediation providers, Self Node Remediation Operator and Fence Agents Remediation Operator, support this feature. For more information on the escalatingRemediations parameter, see the About the Node Health Check Operator section of the documentation. A section detailing the flow of events that is required to detect, fence, and remediate unhealthy nodes, and to restore workloads, and the node, to health. For more information on the flow of events, see the Flow of events during fencing and remediation section of the documentation. 1.2. Deprecated and removed features No features were deprecated and/or removed in this release. 1.3. Bug fixes Self Node Remediation (SNR) is unable to function when the specified time is lower that the calculated time. ( ECOPROJECT-1875 ) Cause: Specifying the safeTimeToAssumeNodeRebootedSeconds parameter with a value that is lower than the calculated minTimeToAssumeNodeRebooted minimum value. Consequence: The SNR Operator is prevented from functioning. Fix: The SNR safeTimeToAssumeNodeRebootedSeconds parameter is now optional, and the method to calculate the minTimeToAssumeNodeRebooted minimum value is improved. Result: You can now specify the safeTimeToAssumeNodeRebootedSeconds parameter with a value lower that the calculated minTimeToAssumeNodeRebooted minimum value and the SNR Operator will still function. 1.4. Technology preview features There are no new Technology preview features in this release. 1.5. Known issues No known issues were identified in this release.

Commands:
Chapter 6. Prerequisites and Preparation for Installation The Red Hat Certificate System installation process requires some preparation of the environment. This chapter describes the requirements, dependencies, and other prerequisites when installing Certificate System subsystems. 6.1. Installing Red Hat Enterprise Linux Red Hat Certificate System 10.6 requires the Red Hat Enterprise Linux 8.8 version. For details about installing Red Hat Enterprise Linux, see Performing a standard RHEL installation . To enable the Federal Information Processing Standard (FIPS) on Red Hat Enterprise Linux, see the Red Hat Security Hardening Guide . Important FIPS mode must be enabled on the RHEL host before you install Certificate System. To ensure FIPS mode is enabled: If the returned value is 1 , FIPS mode is enabled.

Commands:
sysctl crypto.fips_enabled
Chapter 4. General Updates New variable for disabling colored output for systemd This update introduces the SYSTEMD_COLORS environment variable for systemd , which enables turning on or off systemd color output. SYSTEMD_COLORS should be set to a valid boolean value. (BZ# 1265749 ) systemd units can now be enabled using aliases The systemd init system uses aliases. Aliases are symbolic links to the service files, and can be used in commands instead of the actual names of services. For example, the package providing the /usr/lib/systemd/system/nfs-server.service service file also provides an alias /usr/lib/systemd/system/nfs.service , which is a symbolic link to the nfs-server.service . This enables, for example, using the systemctl status nfs.service command instead of systemctl status nfs-server.service . Previously, running the systemctl enable command using an alias instead of the real service name failed with an error. With this update, the bug is fixed, and systemctl enable successfully enables units referred to by their aliases. (BZ#1142378) New systemd option: RandomizedDelaySec This update introduces the RandomizedDelaySec option for systemd timers, which schedules an event to occur later by a random number of seconds. For example, setting the option to 10 will postpone the event by a random number of seconds between 0 and 10. The new option is useful for spreading workload over a longer time period to avoid several events executing at the same time. (BZ# 1305279 )

Commands:
probe::nfs.fop.aio_read Name probe::nfs.fop.aio_read - NFS client aio_read file operation Synopsis nfs.fop.aio_read Values ino inode number cache_time when we started read-caching this inode file_name file name buf the address of buf in user space dev device identifier pos current position of file attrtimeo how long the cached information is assumed to be valid. We need to revalidate the cached attrs for this inode if jiffies - read_cache_jiffies > attrtimeo. count read bytes parent_name parent dir name cache_valid cache related bit mask flag

Commands:
8.4. Create a New XML Document View Model Important Please note that XML Document Modeling has been deprecated. 8.4.1. Create a New XML Document View Model To create a new empty XML document view model: Launch the New Model Wizard . Specify a unique model name. Select XML option from Model Class drop-down menu. Select View Model from Model Type drop-down menu. Click Finish . Note You can change the target location (i.e. project or folder) by selecting the Browse... button and selecting a project or folder within your workspace. In addition to creating a new empty XML document view model, the following builder options are available: Copy from existing model of the same model class. Build XML documents from XML schema. 8.4.2. Copy an Existing XML Document View Model This builder option performs a structural copy of the contents of an existing model to a newly defined model. You can choose a full copy or select individual model components for copy. To create a new XML document view model by copying contents from another XML document view model, complete first 4 steps from the Create a New XML Document View Model section and continue with these additional steps: Select the model builder labeled Copy from existing model of the same model class and click > . The Copy Existing Model dialog will be displayed. Select an existing XML document from the workspace using the browse button. Select the Copy all descriptions option if desired. Click Finish . 8.4.3. Build an XML Document View Model This option creates an XML View document model based on a selected XML schema and its dependencies. To create a new XML document view model by from XML schema, complete first 4 steps from the Create a Xml Document View Model section and continue with these additional steps: Select the model builder labeled Build XML documents from XML schema and click > . The Select XML Schema dialog will be displayed. Select an existing schema model from the workspace using the browse button. Note An existing model will be preselected if an XSD model in the workspace is selected in the VDB explorer prior to starting the new model wizard. The schema must be found in the workspace so if you need to get one or more into the workspace use the XSD Schemas on file system importer. Move the available schema root elements you want to become virtual documents in the new model over to the Virtual Documents list by using the arrow button to move all elements. Select the appropriate document options and mapping options. Click Finish . Click Finish to create a model of all selected document entities or (optional) click > to view Selected Documents Statistics page which shows document entity statistics and gives you an idea the size of the model being created. (Optional) Click Finish to create a model of all selected document entities or click > to view Preview Generated Documents page that allows you to exclude document specific entities then click Finish . Note For deeply nested schema, your total entity count may be large. If so, displaying the preview may take some time.

Commands:
4.4.8. Growing Logical Volumes To increase the size of a logical volume, use the lvextend command. After extending the logical volume, you will need to increase the size of the associated file system to match. When you extend the logical volume, you can indicate how much you want to extend the volume, or how large you want it to be after you extend it. The following command extends the logical volumne /dev/myvg/homevol to 12 gigabytes. The following command adds another gigabyte to the logical volume /dev/myvg/homevol . As with the lvcreate command, you can use the -l argument of the lvextend command to specify the number of extents by which to increase the size of the logical volume. You can also use this argument to specify a percentage of the volume group, or a percentage of the remaining free space in the volume group. The following command extends the logical volume called testlv to fill all of the unallocated space in the volume group myvg . After you have extended the logical volume it is necessary to increase the file system size to match. By default, most file system resizing tools will increase the size of the file system to be the size of the underlying logical volume so you do not need to worry about specifying the same size for each of the two commands.

Commands:
lvextend -L12G /dev/myvg/homevol lvextend -- extending logical volume "/dev/myvg/homevol" to 12 GB lvextend -- doing automatic backup of volume group "myvg" lvextend -- logical volume "/dev/myvg/homevol" successfully extended
lvextend -L+1G /dev/myvg/homevol lvextend -- extending logical volume "/dev/myvg/homevol" to 13 GB lvextend -- doing automatic backup of volume group "myvg" lvextend -- logical volume "/dev/myvg/homevol" successfully extended
lvextend -l +100%FREE /dev/myvg/testlv Extending logical volume testlv to 68.59 GB Logical volume testlv successfully resized
5.225. ORBit2 5.225.1. RHBA-2012:1457 - ORBit2 bug fix update Updated ORBit2 packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ORBit2 packages provide a high-performance Object Request Broker (ORB) for Common Object Request Broker Architecture (CORBA). ORBit allows programs to send requests and receive replies from other programs, regardless of where the programs are located. CORBA is a standard that enables communication between program objects, regardless of the programming language and platform used. Bug Fix BZ# 866469 ORBit2 connection code was unable to process the EAGAIN error, which can be returned by an AF_UNIX socket due to too many simultaneous connection requests. This could cause gconfd-2 clients to fail to connect to the gconfd daemon. Consequently, various errors were emitted when logging in to the GNOME 2 session and the server was under a heavy load. This update adds the patch that enables the ORBit2 request broker to wait for the defined time period if the EAGAIN error is received, and then retry to establish the connection. Errors no longer occur when logging in to the GNOME 2 session in this scenario. All users of ORBit2 are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 8. Basic Red Hat Ceph Storage client setup As a storage administrator, you have to set up client machines with basic configuration to interact with the storage cluster. Most client machines only need the ceph-common package and its dependencies installed. It will supply the basic ceph and rados commands, as well as other commands like mount.ceph and rbd . 8.1. Configuring file setup on client machines Client machines generally need a smaller configuration file than a full-fledged storage cluster member. You can generate a minimal configuration file which can give details to clients to reach the Ceph monitors. Prerequisites A running Red Hat Ceph Storage cluster. Root access to the nodes. Procedure On the node where you want to set up the files, create a directory ceph in the /etc folder: Example Navigate to /etc/ceph directory: Example Generate the configuration file in the ceph directory: Example The contents of this file should be installed in /etc/ceph/ceph.conf path. You can use this configuration file to reach the Ceph monitors. 8.2. Setting-up keyring on client machines Most Ceph clusters are run with the authentication enabled, and the client needs the keys in order to communicate with cluster machines. You can generate the keyring which can give details to clients to reach the Ceph monitors. Prerequisites A running Red Hat Ceph Storage cluster. Root access to the nodes. Procedure On the node where you want to set up the keyring, create a directory ceph in the /etc folder: Example Navigate to /etc/ceph directory in the ceph directory: Example Generate the keyring for the client: Syntax Example Verify the output in the ceph.keyring file: Example The resulting output should be put into a keyring file, for example /etc/ceph/ceph.keyring .

Commands:
mkdir /etc/ceph/
cd /etc/ceph/
ceph config generate-minimal-conf minimal ceph.conf for 417b1d7a-a0e6-11eb-b940-001a4a000740 [global] fsid = 417b1d7a-a0e6-11eb-b940-001a4a000740 mon_host = [v2:10.74.249.41:3300/0,v1:10.74.249.41:6789/0]
mkdir /etc/ceph/
cd /etc/ceph/
ceph auth get-or-create client. CLIENT_NAME -o /etc/ceph/ NAME_OF_THE_FILE
ceph auth get-or-create client.fs -o /etc/ceph/ceph.keyring
cat ceph.keyring [client.fs] key = AQAvoH5gkUCsExAATz3xCBLd4n6B6jRv+Z7CVQ==
6.14.4. Logging You can enable debugging for all daemons in a cluster, or you can enable logging for specific cluster processing. To enable debugging for all daemons, execute the following command. By default, logging is directed to the /var/log/cluster/ daemon .log file. For example, the following command enables debugging for all daemons. Note that this command resets all other properties that you can set with the --setlogging option to their default values, as described in Section 6.1.5, "Commands that Overwrite Settings" . To enable debugging for an individual cluster process, execute the following command. Per-daemon logging configuration overrides the global settings. For example, the following commands enable debugging for the corosync and fenced daemons. To remove the log settings for individual daemons, use the following command. For example, the following command removes the daemon-specific log settings for the fenced daemon For a list of the logging daemons for which you can enable logging as well as the additional logging options you can configure for both global and per-daemon logging, see the cluster.conf (5) man page. Note that when you have finished configuring all of the components of your cluster, you will need to sync the cluster configuration file to all of the nodes, as described in Section 6.15, "Propagating the Configuration File to the Cluster Nodes" .

Commands:
ccs -h host --setlogging [logging options]
ccs -h node1.example.com --setlogging debug=on
ccs -h host --addlogging [logging daemon options]
ccs -h node1.example.com --addlogging name=corosync debug=on ccs -h node1.example.com --addlogging name=fenced debug=on
ccs -h host --rmlogging name= clusterprocess
ccs -h host --rmlogging name=fenced
Preface Several standalone CLIs are available to you as part of Red Hat Trusted Application Pipeline through its components and related products. With the help of the standalone CLIs, you can customize the CI experience, along with automating and securing the process of building and testing your applications. You can enhance the software supply chain security by, for example, running enhanced security checks, signing and verifying your software artifacts, managing compliance with security policies, or generating SBOMs. You can use these CLI tools with an instance of RHTAP running on an OpenShift cluster, or you can install them on your workstation to build and test your applications locally in a more automated and secure way.

Commands:
Chapter 89. JaegerTracing schema reference The type JaegerTracing has been deprecated. Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec The type property is a discriminator that distinguishes use of the JaegerTracing type from OpenTelemetryTracing . It must have the value jaeger for the type JaegerTracing . Property Property type Description type string Must be jaeger .

Commands:
Release notes Red Hat Service Interconnect 1.8 Latest information about features and issues in this release

Commands:
skupper update
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: skupper-non-admin rules: - apiGroups: - "" resources: - configmaps - pods - pods/exec - services - secrets - serviceaccounts verbs: - get - list - watch - create - update - delete - apiGroups: - apps resources: - deployments - statefulsets - daemonsets verbs: - get - list - watch - create - update - delete - apiGroups: - route.openshift.io resources: - routes verbs: - get - list - watch - create - delete - apiGroups: - networking.k8s.io resources: - ingresses - networkpolicies verbs: - get - list - watch - create - delete - apiGroups: - projectcontour.io resources: - httpproxies verbs: - get - list - watch - create - delete - apiGroups: - rbac.authorization.k8s.io resources: - rolebindings - roles verbs: - get - list - watch - create - delete
oc apply -f role.yaml oc policy add-role-to-user skupper-non-admin <username> -n <namespace-name> --role-namespace=<namespace-name>
Appendix D. Creating New Logical Volumes for an Existing Cluster The Red Hat High Availability Add-On provides support for high availability LVM volumes (HA-LVM) in a failover configuration. Note In Red Hat Enterprise Release 6 HA Cluster with Pacemaker, clvmd is not supported in combination with the LVM resource agent used by Pacemaker when using the volumes in an exclusive, active/passive manner. To create new volumes, either volumes need to be added to a managed volume group on the node where it is already activated by the service, or the volume_list must be temporarily bypassed or overridden to allow for creation of the volumes until they can be prepared to be configured by a cluster resource. To create a new logical volume on the same node where the LVM resource for that volume group is already started,m use the following procedure: The volume group should already be tagged on the node owning that service, so simply create the volumes with a standard lvcreate command on that node. Determine the current owner of the relevant service. On the node where the service is started, create the logical volume. Add the volume into the service configuration in whatever way is necessary. To create a new volume group entirely, use the following procedure. Create the volume group on one node with the tag pacemaker while overriding the volume_list to allow this tag. Specify any desired settings for this volume group as normal and specify the --addtag and --config options as in the following example: Create logical volumes within this volume group as in the following example, otherwise perform any necessary administration on the volume group. This example creates a logical volume that is 1G in size. Create the filesystem as well on the logical volume if required. When the volume group activity is complete, deactivate the volume group and remove the tag, as in the following example. Note Use the same tag as you used previously, if you used a tag other than pacemaker . When you add the volume group as a resource in the cluster, all the logical volumes in that volume group will get activated on a single node. Create the volume group resource, as in the following example.

Commands:
pcs resource
lvcreate -l 100%FREE -n lv2 myVG
vgcreate myNewVG /dev/mapper/mpathb --addtag pacemaker --config 'activation { volume_list = [ "@pacemaker" ] }'
lvcreate --addtag pacemaker -L +1G -n testlv1 myNewVG --config 'activation { volume_list = [ "@pacemaker" ] }' Logical volume "testlv1" created
lvchange -an myNewVG/testlv1 --deltag pacemaker Logical volume "testlv1" changed. vgchange -an myNewVG --deltag pacemaker Volume group "myNewVG" successfully changed 0 logical volume(s) in volume group "myNewVG" now active
pcs resource create mynewvg LVM volgrpname=myNewVG exclusive=true