mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 24. Publishing the certified Operator 24.1. Publishing certified Operators The certification is considered complete and your Operator will appear in the Red Hat Container Catalog and embedded OperatorHub within OpenShift after all the tests have passed successfully, and the certification pipeline is enabled to submit results to Red Hat. Additionally, the entry will appear on Red Hat Certification Ecosystem . 24.2. Publishing validated Operators After submitting your Operators for validation, the Red Hat certification team will review and verify the entered details of the validation questionnaire. If at a later date you want to certify your partner validated application, complete the Certification details. The Red Hat certification team will review the submitted test results. After successful verification, to publish your product on the Red Hat Ecosystem Catalog , go to the Product Listings page to attach the Partner Validated or Certified application. Important Red Hat OpenShift software certification or validation does not conduct testing of the Partner's product in how it functions or performs outside of the Operator constructs and its impact on the Red Hat platform on which it was installed and executed. Any and all aspects of the certification candidate product's quality assurance remains the Partner's sole responsibility.

Commands:
8.215. system-config-lvm 8.215.1. RHBA-2013:1570 - system-config-lvm bug fix update An updated system-config-lvm package that fixes one bug is now available for Red Hat Enterprise Linux 6. The system-config-lvm utility enables users to configure logical volumes using a GUI. Bug Fix BZ# 923643 Due to a bug in the system-config-lvm utility, the utility terminated unexpectedly when striped mirrored devices were found on the system. With this update, the underlying source code has been modified so that the users can now fully interact with supported devices. However, volume group information may not always render properly for stripped mirrored devices. Users of system-config-lvm are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 2. Using the Argo CD plugin You can use the Argo CD plugin to visualize the Continuous Delivery (CD) workflows in OpenShift GitOps. This plugin provides a visual overview of the application's status, deployment details, commit message, author of the commit, container image promoted to environment and deployment history. Prerequisites You have enabled the Argo CD plugin in Red Hat Developer Hub RHDH. Procedures Select the Catalog tab and choose the component that you want to use. Select the CD tab to view insights into deployments managed by Argo CD. Select an appropriate card to view the deployment details (for example, commit message, author name, and deployment history). Click the link icon ( ) to open the deployment details in Argo CD. Select the Overview tab and navigate to the Deployment summary section to review the summary of your application's deployment across namespaces. Additionally, select an appropriate Argo CD app to open the deployment details in Argo CD, or select a commit ID from the Revision column to review the changes in GitLab or GitHub. Additional resources For more information on dynamic plugins, see Dynamic plugin installation .

Commands:
4.20. IBM BladeCenter over SNMP Table 4.21, "IBM BladeCenter SNMP" lists the fence device parameters used by fence_ibmblade , the fence agent for IBM BladeCenter over SNMP. Table 4.21. IBM BladeCenter SNMP luci Field cluster.conf Attribute Description Name name A name for the IBM BladeCenter SNMP device connected to the cluster. IP Address or Hostname ipaddr The IP address or host name assigned to the device. UDP/TCP Port (optional) udpport UDP/TCP port to use for connections with the device; the default value is 161. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. SNMP Version snmp_version The SNMP version to use (1, 2c, 3); the default value is 1. SNMP Community community The SNMP community string. SNMP Security Level snmp_sec_level The SNMP security level (noAuthNoPriv, authNoPriv, authPriv). SNMP Authentication Protocol snmp_auth_prot The SNMP authentication protocol (MD5, SHA). SNMP Privacy Protocol snmp_priv_prot The SNMP privacy protocol (DES, AES). SNMP privacy protocol password snmp_priv_passwd The SNMP Privacy Protocol Password. SNMP Privacy Protocol Script snmp_priv_passwd_script The script that supplies a password for SNMP privacy protocol. Using this supersedes the SNMP privacy protocol password parameter. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Port (Outlet) Number port Physical plug number or name of virtual machine. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Figure 4.15, "IBM BladeCenter SNMP" shows the configuration screen for adding an IBM BladeCenter SNMP fence device. Figure 4.15. IBM BladeCenter SNMP The following command creates a fence device instance for an IBM BladeCenter SNMP device: The following is the cluster.conf entry for the fence_ibmblade device:

Commands:
ccs -f cluster.conf --addfencedev bladesnmp1 agent=fence_ibmblade community=private ipaddr=192.168.0.1 login=root passwd=password123 snmp_priv_passwd=snmpasswd123 power_wait=60
<fencedevices> <fencedevice agent="fence_ibmblade" community="private" ipaddr="192.168.0.1" login="root" name="bladesnmp1" passwd="password123" power_wait="60" snmp_priv_passwd="snmpasswd123" udpport="161"/> </fencedevices>
2.5.5. Setting Up NFS Over GFS2 Due to the added complexity of the GFS2 locking subsystem and its clustered nature, setting up NFS over GFS2 requires taking many precautions and careful configuration. This section describes the caveats you should take into account when configuring an NFS service over a GFS2 file system. Warning If the GFS2 file system is NFS exported, and NFS client applications use POSIX locks, then you must mount the file system with the localflocks option. The intended effect of this is to force POSIX locks from each server to be local: that is, non-clustered, independent of each other. (A number of problems exist if GFS2 attempts to implement POSIX locks from NFS across the nodes of a cluster.) For applications running on NFS clients, localized POSIX locks means that two clients can hold the same lock concurrently if the two clients are mounting from different servers. If all clients mount NFS from one server, then the problem of separate servers granting the same locks independently goes away. If you are not sure whether to mount your file system with the localflocks option, you should not use the option; it is always safer to have the locks working on a clustered basis. In addition to the locking considerations, you should take the following into account when configuring an NFS service over a GFS2 file system. Red Hat supports only Red Hat High Availability Add-On configurations using NFSv3 with locking in an active/passive configuration with the following characteristics: The back-end file system is a GFS2 file system running on a 2 to 16 node cluster. An NFSv3 server is defined as a service exporting the entire GFS2 file system from a single cluster node at a time. The NFS server can fail over from one cluster node to another (active/passive configuration). No access to the GFS2 file system is allowed except through the NFS server. This includes both local GFS2 file system access as well as access through Samba or Clustered Samba. There is no NFS quota support on the system. This configuration provides HA for the file system and reduces system downtime since a failed node does not result in the requirement to execute the fsck command when failing the NFS server from one node to another. The fsid= NFS option is mandatory for NFS exports of GFS2. If problems arise with your cluster (for example, the cluster becomes inquorate and fencing is not successful), the clustered logical volumes and the GFS2 file system will be frozen and no access is possible until the cluster is quorate. You should consider this possibility when determining whether a simple failover solution such as the one defined in this procedure is the most appropriate for your system.

Commands:
Preface To enable your Jenkins pipeline to perform essential tasks, such as vulnerability scanning, image signing, and attestation, follow these steps. The table outlines the actions you need to take and when you need to complete them. Action When to complete Adding secrets to Jenkins for secure integration with external tools Before you use secure software templates to create an application, add secrets to Jenkins. This ensures seamless integration with ACS, Quay, and GitOps. Add your application to Jenkins After creating the application and source repositories, add them to Jenkins. This enables you to review various aspects of the Jenkins pipeline on the Red Hat Developer Hub platform. By completing these steps, you enable Jenkins to integrate seamlessly with ACS (Advanced Cluster Security), Quay, and GitOps, and utilize Cosign for signing and verifying container images.

Commands:
5.88. gnome-keyring 5.88.1. RHBA-2012:1334 - gnome-keyring bug fix update Updated gnome-keyring packages that fix one bug are now available for Red Hat Enterprise Linux 6. The gnome-keyring session daemon manages passwords and other types of secrets for the user, storing them encrypted with a main password. Applications can use the gnome-keyring library to integrate with the key ring. Bug Fix BZ# 860644 Due to a bug in the thread-locking mechanism, the gnome-keyring daemon could sporadically become unresponsive while reading data. This update fixes the thread-locking mechanism and no more deadlocks occur in gnome-keyring in the described scenario. All gnome-keyring users are advised to upgrade to these updated packages, which fix this bug. 5.88.2. RHBA-2012:0878 - gnome-keyring bug fix update Updated gnome-keyring packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The gnome-keyring session daemon manages passwords and other types of secrets for the user, storing them encrypted with a main password. Applications can use the gnome-keyring library to integrate with the keyring. Bug Fixes BZ# 708919 , BZ# 745695 Previously, the mechanism for locking threads was missing. Due to this, gnome-keyring could have, under certain circumstances, terminated unexpectedly on multiple key requests from the integrated ssh-agent. With this update, the missing mechanism has been integrated into gnome-keyring so that gnome-keyring now works as expected. All users of gnome-keyring are advised to upgrade to these updated packages, which fix these bugs.

Commands:
14.11.2. Creating, Defining, and Starting Storage Pools This section provides information about creating, defining, and starting storage pools. 14.11.2.1. Building a storage pool The pool-build pool-or-uuid --overwrite --no-overwrite command builds a pool with a specified pool name or UUID . The options --overwrite and --no-overwrite can only be used for a pool whose type is file system. If neither option is specified, and the pool is a file system type pool, then the resulting build will only make the directory. If --no-overwrite is specified, it probes to determine if a file system already exists on the target device, returning an error if it exists, or using mkfs to format the target device if it does not. If --overwrite is specified, then the mkfs command is executed and any existing data on the target device is overwritten.

Commands:
Chapter 7. Known issues Known issues in Red Hat 3scale API Management 2.15: Table 7.1. Known issues Issue number Description THREESCALE-7514 Nginx filter policy is not working as expected when using content-caching THREESCALE-9033 Some special characters in Application Keys are not supported THREESCALE-10761 Problem with special chars in application_id in utilization THREESCALE-10762 Command from Configuration page cause apicast to return 403 THREESCALE-10763 Command from Configuration page cause apicast to return 403 THREESCALE-10875 DeveloperAccount backup and restore needs to be hardened THREESCALE-11532 Backend clients cannot re-establish the connection Issue resolved in 2.15.2

Commands:
8.11. Installation Source To specify a file or a location to install Red Hat Enterprise Linux from, select Installation Source from the Installation Summary screen. On this screen, you can choose between locally available installation media, such as a DVD or an ISO file, or a network location. Figure 8.9. Installation Source Screen Select one of the following options: Auto-detected installation media If you started the installation using the full installation DVD or USB drive, the installation program will detect it and display basic information under this option. Click the Verify button to ensure that the media is suitable for installation. This integrity test is the same as the one performed if you selected Test this media & Install Red Hat Enterprise Linux in the boot menu, or if you used the rd.live.check boot option. ISO file This option will appear if the installation program detected a partitioned hard drive with mountable file systems. Select this option, click the Choose an ISO button, and browse to the installation ISO file's location on your system. Then click Verify to ensure that the file is suitable for installation. On the network To specify a network location, select this option and choose from the following options in the drop-down menu: http:// https:// ftp:// nfs Using your selection as the start of the location URL, type the rest into the address box. If you choose NFS, another box will appear for you to specify any NFS mount options. Important When selecting an NFS-based installation source, you must specify the address with a colon ( : ) character separating the host name from the path. For example: To configure a proxy for an HTTP or HTTPS source, click the Proxy setup button. Check Enable HTTP proxy and type the URL into the Proxy URL box. If your proxy requires authentication, check Use Authentication and enter a user name and password. Click Add . If your HTTP or HTTPS URL refers to a repository mirror list, mark the check box under the input field. You can also specify additional repositories to gain access to more installation environments and software add-ons. See Section 8.13, "Software Selection" for more information. To add a repository, click the + button. To delete a repository, click the - button. Click the arrow icon to revert to the list of repositories, that is, to replace current entries with those that were present at the time you entered the Installation Source screen. To activate or deactivate a repository, click the check box in the Enabled column at each entry in the list. In the right part of the form, you can name your additional repository and configure it the same way as the primary repository on the network. Once you have selected your installation source, click Done to return to the Installation Summary screen.

Commands:
server.example.com : /path/to/directory
10.8. Ports Used by Red Hat JBoss Data Virtualization Red Hat JBoss Data Virtualization inherits the ports used by JBoss Enterprise Application Platform. You can find a full list here: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Network_Ports_Used_By_JBoss_Enterprise_Application_Platform_62.html In addition, to these, ports 31000 and 35432 must also be kept open.

Commands:
10.11. Unusual Failover Behavior A common problem with cluster servers is unusual failover behavior. Services will stop when other services start or services will refuse to start on failover. This can be due to having complex systems of failover consisting of failover domains, service dependency, and service exclusivity. Try scaling back to a simpler service or failover domain configuration and see if the issue persists. Avoid features like service exclusivity and dependency unless you fully understand how those features may effect failover under all conditions.

Commands:
Appendix D. Trusted Artifact Signer components and version numbers The following tables list Red Hat's Trusted Artifact Signer (RHTAS) software components and their corresponding version numbers for the 1.1.1 release. Table D.1. Binaries Component Version cosign 2.4.1 gitsign 0.11.0 rekor-cli 1.3.7 ec 0.2.1 createtree 1.7.0 updatetree 1.7.0 tuftool 0.12.0 tuffer 0.17.1 Table D.2. Trillian Component Version logserver 1.7.0 logsigner 1.7.0 database 1.7.0 redis 1.7.0 Table D.3. Rekor Component Version rekor-server 1.3.7 backfill-redis 1.3.7 rekor-search-ui 1.3.7 Table D.4. Fulcio Component Version fulcio-server 1.6.5 Table D.5. Certificate Transparency Component Version certificate-transparency-go 1.3.0 Table D.6. Timestamp Authority Component Version timestamp-authority 1.2.3 Additional resources For more information about Trillian, see the project page on GitHub . For more information about Sigstore's Rekor, see the project page on GitHub . For more information about Sigstore's Fulcio, see the project page on GitHub . For more information about Sigstore's Timestamp Authority, see the project page on GitHub . For more information about TUF, see their home page hosted by the Linux Foundation.

Commands:
Chapter 16. Uninstalling Fuse on OpenShift To uninstall Fuse on OpenShift, remove the imagestreams and templates from registry.redhat.io , with the oc delete command. 16.1. Uninstalling Fuse imagestreams and templates on the OpenShift 4.x server Procedure + Find the BASEURL for your version and define it as a variable for use in commands below. + Delete the Spring Boot 2 quickstart templates. Delete Fuse on OpenShift quickstart templates. Delete the imagestreams. Remove items in the Samples Operator. Edit the configuration of Samples Operator: Remove the Fuse and Spring Boot 2 templates from the skippedImagestreams and skippedTemplates section. Built-in imagestreams Some imagestreams and templates are built-in for common use cases. These are managed by the Sample Operator, so you cannot remove them manually. You can ignore them while uninstalling. Built-in imagestreams are configured with the samples.operator.openshift.io/managed: "true" label in the manifest, so you can verify if it is managed with the oc get and grep commands. Example

Commands:
BASEURL=https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001
for template in spring-boot-2-camel-amq-template.json spring-boot-2-camel-config-template.json spring-boot-2-camel-drools-template.json spring-boot-2-camel-infinispan-template.json spring-boot-2-camel-rest-3scale-template.json spring-boot-2-camel-rest-sql-template.json spring-boot-2-camel-template.json spring-boot-2-camel-xa-template.json spring-boot-2-camel-xml-template.json spring-boot-2-cxf-jaxrs-template.json spring-boot-2-cxf-jaxws-template.json spring-boot-2-cxf-jaxrs-xml-template.json spring-boot-2-cxf-jaxws-xml-template.json ; do oc delete -n openshift -f USD{BASEURL}/quickstarts/USD{template} done
for template in eap-camel-amq-template.json eap-camel-cdi-template.json eap-camel-cxf-jaxrs-template.json eap-camel-cxf-jaxws-template.json karaf-camel-amq-template.json karaf-camel-log-template.json karaf-camel-rest-sql-template.json karaf-cxf-rest-template.json ; do oc delete -n openshift -f USD{BASEURL}/quickstarts/USD{template} done
delete -n openshift -f USD{BASEURL}/fis-image-streams.json
edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
]USD oc get is fuse7-eap-openshift -n openshift -o yaml | grep 'samples.operator.openshift.io/managed' samples.operator.openshift.io/managed: "true" ]USD
Chapter 5. Pools, placement groups, and CRUSH configuration As a storage administrator, you can choose to use the Red Hat Ceph Storage default options for pools, placement groups, and the CRUSH algorithm or customize them for the intended workload. Prerequisites Installation of the Red Hat Ceph Storage software. 5.1. Pools placement groups and CRUSH When you create pools and set the number of placement groups for the pool, Ceph uses default values when you do not specifically override the defaults. Important Red Hat recommends overriding some of the defaults. Specifically, set a pool's replica size and override the default number of placement groups. You can set these values when running pool commands. By default, Ceph makes 3 replicas of objects. If you want to set 4 copies of an object as the default value, a primary copy and three replica copies, reset the default values as shown in osd_pool_default_size . If you want to allow Ceph to write a lesser number of copies in a degraded state, set osd_pool_default_min_size to a number less than the osd_pool_default_size value. Example Ensure you have a realistic number of placement groups. Red Hat recommends approximately 100 per OSD. For example, total number of OSDs multiplied by 100 divided by the number of replicas, that is, osd_pool_default_size . For 10 OSDs and osd_pool_default_size = 4, we would recommend approximately (100 * 10) / 4 = 250. Example Additional resources See all the Red Hat Ceph Storage pool, placement group, and CRUSH configuration options in l Appendix E for specific option descriptions and usage.

Commands:
ceph config set global osd_pool_default_size 4 # Write an object 4 times. ceph config set global osd_pool_default_min_size 1 # Allow writing one copy in a degraded state.
ceph config set global osd_pool_default_pg_num 250 ceph config set global osd_pool_default_pgp_num 250
Chapter 1. Upgrading Red Hat build of Keycloak This guide describes how to upgrade Red Hat build of Keycloak from version 22.0.x to version 24.0.10. Use the following procedures in this order: Review the migration changes from the version of Red Hat build of Keycloak. Upgrade the Red Hat build of Keycloak server. Upgrade the Red Hat build of Keycloak adapters. Upgrade the Red Hat build of Keycloak Admin Client. For Red Hat Single Sign-On 7.6 customers, use the Migration Guide instead of this guide.

Commands: