mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 117. GZip DataFormat Available as of Camel version 2.0 The GZip Data Format is a message compression and de-compression format. It uses the same deflate algorithm that is used in Zip DataFormat , although some additional headers are provided. This format is produced by popular gzip / gunzip tool. Messages marshalled using GZip compression can be unmarshalled using GZip decompression just prior to being consumed at the endpoint. The compression capability is quite useful when you deal with large XML and Text based payloads or when you read messages previously comressed using gzip tool. 117.1. Options The GZip dataformat supports 1 options, which are listed below. Name Default Java Type Description contentTypeHeader false Boolean Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. 117.2. Marshal In this example we marshal a regular text/XML payload to a compressed payload employing gzip compression format and send it an ActiveMQ queue called MY_QUEUE. from("direct:start").marshal().gzip().to("activemq:queue:MY_QUEUE"); 117.3. Unmarshal In this example we unmarshal a gzipped payload from an ActiveMQ queue called MY_QUEUE to its original format, and forward it for processing to the UnGZippedMessageProcessor . from("activemq:queue:MY_QUEUE").unmarshal().gzip().process(new UnGZippedMessageProcessor()); 117.4. Dependencies This data format is provided in camel-core so no additional dependencies is needed.

Commands:
from("direct:start").marshal().gzip().to("activemq:queue:MY_QUEUE");
from("activemq:queue:MY_QUEUE").unmarshal().gzip().process(new UnGZippedMessageProcessor());
Chapter 18. PersistentClaimStorage schema reference Used in: JbodStorage , KafkaClusterSpec , KafkaNodePoolSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the PersistentClaimStorage type from EphemeralStorage . It must have the value persistent-claim for the type PersistentClaimStorage . Property Property type Description id integer Storage identification number. It is mandatory only for storage volumes defined in a storage of type 'jbod'. type string Must be persistent-claim . size string When type=persistent-claim , defines the size of the persistent volume claim, such as 100Gi. Mandatory when type=persistent-claim . kraftMetadata string (one of [shared]) Specifies whether this volume should be used for storing KRaft metadata. This property is optional. When set, the only currently supported value is shared . At most one volume can have this property set. class string The storage class to use for dynamic volume allocation. selector map Specifies a specific persistent volume to use. It contains key:value pairs representing labels for selecting such a volume. deleteClaim boolean Specifies if the persistent volume claim has to be deleted when the cluster is un-deployed. overrides PersistentClaimStorageOverride array The overrides property has been deprecated. The storage overrides for individual brokers are deprecated and will be removed in the future. Please use multiple KafkaNodePool custom resources with different storage classes instead. Overrides for individual brokers. The overrides field allows you to specify a different configuration for different brokers.

Commands:
Chapter 5. Configuring the web console in OpenShift Container Platform You can modify the OpenShift Container Platform web console to set a logout redirect URL or disable the console. 5.1. Prerequisites Deploy an OpenShift Container Platform cluster. 5.2. Configuring the web console You can configure the web console settings by editing the console.config.openshift.io resource. Edit the console.config.openshift.io resource: USD oc edit console.config.openshift.io cluster The following example displays the sample resource definition for the console: apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2 1 Specify the URL of the page to load when a user logs out of the web console. If you do not specify a value, the user returns to the login page for the web console. Specifying a logoutRedirect URL allows your users to perform single logout (SLO) through the identity provider to destroy their single sign-on session. 2 The web console URL. To update this to a custom value, see Customizing the web console URL . 5.3. Disabling quick starts in the web console You can use the Administrator perspective of the web console to disable one or more quick starts. Prerequisites You have cluster administrator permissions and are logged in to the web console. Procedure In the Administrator perspective, navigate to Administation Cluster Settings . On the Cluster Settings page, click the Configuration tab. On the Configuration page, click the Console configuration resource with the description operator.openshift.io . From the Action drop-down list, select Customize , which opens the Cluster configuration page. On the General tab, in the Quick starts section, you can select items in either the Enabled or Disabled list, and move them from one list to the other by using the arrow buttons. To enable or disable a single quick start, click the quick start, then use the single arrow buttons to move the quick start to the appropriate list. To enable or disable multiple quick starts at once, press Ctrl and click the quick starts you want to move. Then, use the single arrow buttons to move the quick starts to the appropriate list. To enable or disable all quick starts at once, click the double arrow buttons to move all of the quick starts to the appropriate list.

Commands:
oc edit console.config.openshift.io cluster
apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2
Chapter 16. Installing and configuring RH-SSO A realm is a security policy domain defined for a web or application server. Security realms are used to restrict access for different application resources. You should create a new realm whether your RH-SSO instance is private or shared with other products. You can keep the master realm as a place for super administrators to create and manage the realms in your system. If you are integrating with an RH-SSO instance that is shared with other product installations to achieve single sign-on with those applications, all of those applications must use the same realm. To create an RH-SSO realm, download, install, and configure RH-SSO 7.5. Note If Business Central and KIE Server are installed on different servers, complete this procedure on both servers. Procedure Navigate to the Software Downloads page in the Red Hat Customer Portal (login required) and then select the product and version from the drop-down options: Product: Red Hat Single Sign-On Version: 7.5 Download Red Hat Single Sign-On 7.5.0 Server ( rh-sso-7.5.0.zip ) and the latest server patch. To install and configure a basic RH-SSO standalone server, follow the instructions in the Red Hat Single Sign On Getting Started Guide . For advanced settings for production environments, see the Red Hat Single Sign On Server Administration Guide . Note If you want to run both RH-SSO and Red Hat Decision Manager servers on the same system, ensure that you avoid port conflicts by taking one of the following actions: Update the RHSSO_HOME /standalone/configuration/standalone-full.xml file and set the port offset to 100. For example: Use an environment variable to set the port offset when running the server:

Commands:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="USD{jboss.socket.binding.port-offset:100}">
bin/standalone.sh -Djboss.socket.binding.port-offset=100
Chapter 17. Uninstalling OpenShift Logging You can remove the logging subsystem from your OpenShift Container Platform cluster. 17.1. Uninstalling the logging subsystem for Red Hat OpenShift You can stop log aggregation by deleting the ClusterLogging custom resource (CR). After deleting the CR, there are other logging subsystem components that remain, which you can optionally remove. Deleting the ClusterLogging CR does not remove the persistent volume claims (PVCs). To preserve or delete the remaining PVCs, persistent volumes (PVs), and associated data, you must take further action. Prerequisites The Red Hat OpenShift Logging and Elasticsearch Operators must be installed. Procedure To remove OpenShift Logging: Use the OpenShift Container Platform web console to remove the ClusterLogging CR: Switch to the Administration Custom Resource Definitions page. On the Custom Resource Definitions page, click ClusterLogging . On the Custom Resource Definition Details page, click Instances . Click the Options menu to the instance and select Delete ClusterLogging . Optional: Delete the custom resource definitions (CRD): Switch to the Administration Custom Resource Definitions page. Click the Options menu to ClusterLogForwarder and select Delete Custom Resource Definition . Click the Options menu to ClusterLogging and select Delete Custom Resource Definition . Click the Options menu to Elasticsearch and select Delete Custom Resource Definition . Optional: Remove the Red Hat OpenShift Logging Operator and OpenShift Elasticsearch Operator: Switch to the Operators Installed Operators page. Click the Options menu to the Red Hat OpenShift Logging Operator and select Uninstall Operator . Click the Options menu to the OpenShift Elasticsearch Operator and select Uninstall Operator . Optional: Remove the OpenShift Logging and Elasticsearch projects. Switch to the Home Projects page. Click the Options menu to the openshift-logging project and select Delete Project . Confirm the deletion by typing openshift-logging in the dialog box and click Delete . Click the Options menu to the openshift-operators-redhat project and select Delete Project . Important Do not delete the openshift-operators-redhat project if other global operators are installed in this namespace. Confirm the deletion by typing openshift-operators-redhat in the dialog box and click Delete . To keep the PVCs for reuse with other pods, keep the labels or PVC names that you need to reclaim the PVCs. Optional: If you do not want to keep the PVCs, you can delete them. Warning Releasing or deleting PVCs can delete PVs and cause data loss. Switch to the Storage Persistent Volume Claims page. Click the Options menu to each PVC and select Delete Persistent Volume Claim . If you want to recover storage space, you can delete the PVs. Additional resources Reclaiming a persistent volume manually

Commands:
15.3. Applying Custom Object Classes to New Group Entries As with user entries, administrators may create custom object classes with custom attributes. These can be added automatically by adding the object classes to the IdM server configuration. Note that after an administrator modifies the list of default object classes, new entries will contain the custom object classes but the old entries are not automatically modified. 15.3.1. From the Web UI Add all of the custom schema elements to the 389 Directory Server instance used by Identity Management. Adding schema elements is described in the schema chapter of the Directory Server Administrator's Guide . Open the IPA Server tab. Select the Configuration subtab. Scroll to the Group Options area. Figure 15.3. Group Options in Server Configuration Click Add to include a new field for another object class. Important Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. When the changes are complete, click Save at the top of the Configuration page. 15.3.2. From the Command Line Add all of the custom schema elements to the 389 Directory Server instance used by Identity Management. Adding schema elements is described in the schema chapter of the Directory Server Administrator's Guide . Add the new object class to the list of object classes added to entries. The option for group object classes is --groupobjectclasses . Important Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. All object classes must be included in the list of object classes. The information passed with the config-mod command overwrites the values. This can be done by specifying each object class with a --groupobjectclasses argument or by listing all of the object classes in a comma-separated list inside curly braces with no spaces allowed, such as {attr1,attr2,attr3} . Especially for long lists, it can be easier to use the curly braces than multiple options. For example:

Commands:
[bjensen@server ~]USD ipa config-mod --groupobjectclasses= {top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser, employeegroup }
Chapter 5. Designate test The designate test uses the Tempest framework to verify whether the Designate DNS service works appropriately with the Neutron plugin that you are certifying. The test performs the following actions: Ensures that CRUD operations are successful for the following objects : Records Domains Servers Blacklists Pools Quotas Record sets Top-level domains Transaction signatures Ensures that only administrative users can perform operations on blacklists, quotas, pools, and transaction signatures. Checks that record sets not in compliance with the DNS RFC specification are rejected. For example, record sets containing trailing spaces or invalid characters are rejected. Checks that record sets that contain wildcard characters ( * ) match requests for non-existent domains. Ensures that zone transfers across DNS servers are possible. Ensures that zone creation and zone deletion propagates across DNS servers. Success criteria All operations and verifications are successful.

Commands:
Chapter 2. Installing the MTR extension for Visual Studio Code You can install the MTR extension for Visual Studio Code (VS Code). Prerequisites The following are the prerequisites for the Migration Toolkit for Runtimes (MTR) installation: Java Development Kit (JDK) is installed. MTR supports the following JDKs: OpenJDK 11 OpenJDK 17 Oracle JDK 11 Oracle JDK 17 Eclipse TemurinTM JDK 11 Eclipse TemurinTM JDK 17 8 GB RAM macOS installation: the value of maxproc must be 2048 or greater. Procedure Set the environmental variable JAVA_HOME : USD export JAVA_HOME=jdk11 In VS Code, click the Extensions icon on the Activity bar to open the Extensions view. Enter Migration Toolkit for Runtimes in the Search field. Select the Migration Toolkit for Runtimes extension and click Install . The MTR extension icon ( ) is displayed on the Activity bar.

Commands:
export JAVA_HOME=jdk11
5.4. Uploading QCOW2 image to OpenStack Image Builder can generate images suitable for uploading to OpenStack cloud deployments, and starting instances there. This describes steps to upload an QCOW2 image to OpenStack. Prerequisites You must have an OpenStack-specific image created by Image Builder. Use the openstack output type in CLI or OpenStack Image (.qcow2) in GUI when creating the image. Warning Image Builder also offers a generic QCOW2 image type output format as qcow2 or QEMU QCOW2 Image (.qcow2). Do not mistake it with the OpenStack image type which is also in the QCOW2 format, but contains further changes specific to OpenStack. Procedure 1. Upload the image to OpenStack and start an instance from it. Use the Images interface to do this: Figure 5.5. Virtualization type 2. Start an instance with that image: Figure 5.6. Virtualization type 3. You can run the instance using any mechanism (CLI or OpenStack web UI) from the snapshot. Use your private key via SSH to access the resulting instance. Log in as cloud-user.

Commands:
Chapter 4. Configuring the Load Balancer Add-On with Piranha Configuration Tool The Piranha Configuration Tool provides a structured approach to creating the necessary configuration file for the Load Balancer Add-On - /etc/sysconfig/ha/lvs.cf . This chapter describes the basic operation of the Piranha Configuration Tool and how to activate Load Balancer Add-On once configuration is complete. Important The configuration file for the Load Balancer Add-On follows strict formatting rules. Using the Piranha Configuration Tool is the best way to prevent syntax errors in the lvs.cf and therefore prevent software failures. 4.1. Necessary Software The piranha-gui service must be running on the primary LVS router to use the Piranha Configuration Tool . To configure the Load Balancer Add-On, you minimally need a text-only Web browser, such as links . If you are accessing the LVS router from another machine, you also need an ssh connection to the primary LVS router as the root user. While configuring the primary LVS router it is a good idea to keep a concurrent ssh connection in a terminal window. This connection provides a secure way to restart pulse and other services, configure network packet filters, and monitor /var/log/messages during trouble shooting. The four sections walk through each of the configuration pages of the Piranha Configuration Tool and give instructions on using it to set up the Load Balancer Add-On.

Commands:
6.2. Standard Users Table 6.1, "Standard Users" lists the standard users configured in the /etc/passwd file by an Everything installation. The groupid (GID) in this table is the primary group for the user. See Section 6.3, "Standard Groups" for a listing of standard groups. Table 6.1. Standard Users User UID GID Home Directory Shell root 0 0 /root /bin/bash bin 1 1 /bin /sbin/nologin daemon 2 2 /sbin /sbin/nologin adm 3 4 /var/adm /sbin/nologin lp 4 7 /var/spool/lpd /sbin/nologin sync 5 0 /sbin /bin/sync shutdown 6 0 /sbin /sbin/shutdown halt 7 0 /sbin /sbin/halt mail 8 12 /var/spool/mail /sbin/nologin news 9 13 /etc/news uucp 10 14 /var/spool/uucp /sbin/nologin operator 11 0 /root /sbin/nologin games 12 100 /usr/games /sbin/nologin gopher 13 30 /var/gopher /sbin/nologin ftp 14 50 /var/ftp /sbin/nologin nobody 99 99 / /sbin/nologin rpm 37 37 /var/lib/rpm /sbin/nologin vcsa 69 69 /dev /sbin/nologin dbus 81 81 / /sbin/nologin ntp 38 38 /etc/ntp /sbin/nologin canna 39 39 /var/lib/canna /sbin/nologin nscd 28 28 / /sbin/nologin rpc 32 32 / /sbin/nologin postfix 89 89 /var/spool/postfix /sbin/nologin mailman 41 41 /var/mailman /sbin/nologin named 25 25 /var/named /bin/false amanda 33 6 /var/lib/amanda/ /bin/bash postgres 26 26 /var/lib/pgsql /bin/bash exim 93 93 /var/spool/exim /sbin/nologin sshd 74 74 /var/empty/sshd /sbin/nologin rpcuser 29 29 /var/lib/nfs /sbin/nologin nsfnobody 65534 65534 /var/lib/nfs /sbin/nologin pvm 24 24 /usr/share/pvm3 /bin/bash apache 48 48 /var/www /sbin/nologin xfs 43 43 /etc/X11/fs /sbin/nologin gdm 42 42 /var/gdm /sbin/nologin htt 100 101 /usr/lib/im /sbin/nologin mysql 27 27 /var/lib/mysql /bin/bash webalizer 67 67 /var/www/usage /sbin/nologin mailnull 47 47 /var/spool/mqueue /sbin/nologin smmsp 51 51 /var/spool/mqueue /sbin/nologin squid 23 23 /var/spool/squid /sbin/nologin ldap 55 55 /var/lib/ldap /bin/false netdump 34 34 /var/crash /bin/bash pcap 77 77 /var/arpwatch /sbin/nologin radiusd 95 95 / /bin/false radvd 75 75 / /sbin/nologin quagga 92 92 /var/run/quagga /sbin/login wnn 49 49 /var/lib/wnn /sbin/nologin dovecot 97 97 /usr/libexec/dovecot /sbin/nologin

Commands:
2.3. SELinux Architecture SELinux is a Linux security module that is built into the Linux kernel. SELinux is driven by loadable policy rules. When security-relevant access is taking place, such as when a process attempts to open a file, the operation is intercepted in the kernel by SELinux. If an SELinux policy rule allows the operation, it continues, otherwise, the operation is blocked and the process receives an error. SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). When using these cached decisions, SELinux policy rules need to be checked less, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first.

Commands:
Chapter 17. Atomic Host and Containers Red Hat Enterprise Linux Atomic Host Red Hat Enterprise Linux Atomic Host is a secure, lightweight, and minimal-footprint operating system optimized to run Linux containers. The Atomic Host and Containers Release Notes are now published in a separate book. For the latest new features, known issues, and Technology Previews, see https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/7/single/release-notes/ .

Commands:
Chapter 5. Using oc and kubectl commands The Kubernetes command-line interface (CLI), kubectl , can be used to run commands against a Kubernetes cluster. Because MicroShift is a certified Kubernetes distribution, you can use the supported kubectl CLI tool or you can gain extended functionality by using the OpenShift CLI ( oc ). 5.1. The kubectl CLI tool You can use the kubectl CLI tool to interact with Kubernetes primitives on your MicroShift cluster. You can also use existing kubectl workflows and scripts for users coming from another Kubernetes environment, or for those who prefer to use the kubectl CLI. The kubectl CLI tool is included in the archive when you download oc . For more information, see the Kubernetes CLI tool documentation . 5.2. The oc CLI tool The oc CLI tool offers the same capabilities as the kubectl CLI tool, but it extends to natively support additional OpenShift Container Platform features, including: Route resource The Route resource object is specific to OpenShift Container Platform distributions, and builds upon standard Kubernetes primitives. Additional commands The additional command oc new-app , for example, makes it easier to get new applications started using existing source code or pre-built images. Important If you installed an earlier version of oc , you might not be able use it to complete all of the commands in MicroShift 4.18. If you want the latest features, you must download and install the latest version of oc that corresponds with your MicroShift version. Using new capabilities often requires the latest oc binary. A 4.18 server might have additional capabilities that a 4.16 oc binary cannot use and a 4.18 oc binary might have additional capabilities that are unsupported by a 4.15 server. Table 5.1. Compatibility Matrix X.Y ( oc Client) X.Y+N footnote:versionpolicyn[Where N is a number greater than or equal to 1.] ( oc Client) X.Y (Server) Fully compatible. The oc CLI tool might provide options and features that are not compatible with the accessed server. X.Y+N footnote:versionpolicyn[] (Server) The oc CLI tool might not be able to access server features. Fully compatible.

Commands: