mtpti5iD/redhat-docs_dataset huggingface dataset:
2.9. Storage Pool Manager Selection Process If a host has not been manually assigned the Storage Pool Manager (SPM) role, the SPM selection process is initiated and managed by the Red Hat Virtualization Manager. First, the Red Hat Virtualization Manager requests that VDSM confirm which host has the storage-centric lease. The Red Hat Virtualization Manager tracks the history of SPM assignment from the initial creation of a storage domain onward. The availability of the SPM role is confirmed in three ways: The "getSPMstatus" command: the Manager uses VDSM to check with the host that had SPM status last and receives one of "SPM", "Contending", or "Free". The metadata volume for a storage domain contains the last host with SPM status. The metadata volume for a storage domain contains the version of the last host with SPM status. If an operational, responsive host retains the storage-centric lease, the Red Hat Virtualization Manager marks that host SPM in the administrator portal. No further action is taken. If the SPM host does not respond, it is considered unreachable. If power management has been configured for the host, it is automatically fenced. If not, it requires manual fencing. The Storage Pool Manager role cannot be assigned to a new host until the Storage Pool Manager is fenced. When the SPM role and storage-centric lease are free, the Red Hat Virtualization Manager assigns them to a randomly selected operational host in the data center. If the SPM role assignment fails on a new host, the Red Hat Virtualization Manager adds the host to a list containing hosts the operation has failed on, marking these hosts as ineligible for the SPM role. This list is cleared at the beginning of the SPM selection process so that all hosts are again eligible. The Red Hat Virtualization Manager continues request that the Storage Pool Manager role and storage-centric lease be assumed by a randomly selected host that is not on the list of failed hosts until the SPM selection succeeds. Each time the current SPM is unresponsive or unable to fulfill its responsibilities, the Red Hat Virtualization Manager initiates the Storage Pool Manager selection process.

Commands:
8.90. icedtea-web 8.90.1. RHBA-2014:1417 - icedtea-web bug fix and enhancement update Updated icedtea-web packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The IcedTea-Web project provides a Java web browser plug-in and an implementation of Java Web Start, which is based on the Netx project. It also contains a configuration tool for managing deployment settings for the plug-in and Web Start implementations. Note The icedtea-web packages have been upgraded to upstream version 1.5.1, which provides a number of bug fixes and enhancements over the version. (BZ# 1075790 ) Users of icedtea-web are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Workloads APIs OpenShift Container Platform 4.16 Reference guide for workloads APIs Red Hat OpenShift Documentation Team

Commands:
"postCommit": { "script": "rake test --verbose", }
The above is a convenient form which is equivalent to:
"postCommit": { "command": ["/bin/sh", "-ic"], "args": ["rake test --verbose"] }
"postCommit": { "commit": ["rake", "test", "--verbose"] }
Command overrides the image entrypoint in the exec form, as documented in Docker: https://docs.docker.com/engine/reference/builder/#entrypoint.
"postCommit": { "args": ["rake", "test", "--verbose"] }
This form is only useful if the image entrypoint can handle arguments.
"postCommit": { "script": "rake test USD1", "args": ["--verbose"] }
This form is useful if you need to pass arguments that would otherwise be hard to quote properly in the shell script. In the script, USD0 will be "/bin/sh" and USD1, USD2, etc, are the positional arguments from Args.
"postCommit": { "command": ["rake", "test"], "args": ["--verbose"] }
This form is equivalent to appending the arguments to the Command slice.
"postCommit": { "script": "rake test --verbose", }
The above is a convenient form which is equivalent to:
"postCommit": { "command": ["/bin/sh", "-ic"], "args": ["rake test --verbose"] }
"postCommit": { "commit": ["rake", "test", "--verbose"] }
Command overrides the image entrypoint in the exec form, as documented in Docker: https://docs.docker.com/engine/reference/builder/#entrypoint.
"postCommit": { "args": ["rake", "test", "--verbose"] }
This form is only useful if the image entrypoint can handle arguments.
"postCommit": { "script": "rake test USD1", "args": ["--verbose"] }
This form is useful if you need to pass arguments that would otherwise be hard to quote properly in the shell script. In the script, USD0 will be "/bin/sh" and USD1, USD2, etc, are the positional arguments from Args.
"postCommit": { "command": ["rake", "test"], "args": ["--verbose"] }
This form is equivalent to appending the arguments to the Command slice.
Chapter 8. Integrating with Red Hat Decision Manager You can integrate Red Hat Decision Manager with other products and components, such as Spring Boot, Red Hat Fuse, and Red Hat Single Sign-On. 8.1. Red Hat Decision Manager Spring Boot business applications Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring Boot is a lightweight framework based on Spring Boot starters. Spring Boot starters are pom.xml files that contain a set of dependency descriptors that you can include in your Spring Boot project. Red Hat offers support and maintenance for Red Hat Decision Manager Spring Boot projects as part of Red Hat Runtimes. Red Hat Decision Manager Spring Boot business applications are flexible, UI-agnostic logical groupings of individual services that provide certain business capabilities. Business applications are based on Spring Boot starters. They are usually deployed separately and can be versioned individually. A complete business application enables a domain to achieve specific business goals, for example, order management or accommodation management. After you create and configure your business application, you can deploy it to an existing service or to the cloud, through OpenShift. 8.2. Integrating Red Hat Fuse Fuse is a distributed, cloud-native integration platform that is part of an agile integration solution. Its distributed approach enables teams to deploy integrated services where required. You can install Red Hat Fuse on the Apache Karaf container platform or Red Hat JBoss Enterprise Application Platform and then install and configure Red Hat Decision Manager in that container. 8.3. Integrating Red Hat Single Sign-On Red Hat Single Sign-On (RH-SSO) is a single sign-on solution that you can use to secure your browser applications with your REST web services and Git access. When you integrate Red Hat Decision Manager with RH-SSO, you create an SSO and identity management (IDM) environment for Red Hat Decision Manager. The session management feature of RH-SSO enables you to use a single authentication for different Red Hat Decision Manager environments on the internet. Red Hat Decision Manager supports RH-SSO 7.5 on Red Hat JBoss EAP 7.4.

Commands:
20.3.2. Using the scp Command The scp command can be used to transfer files between machines over a secure, encrypted connection. It is similar to rcp . The general syntax to transfer a local file to a remote system is as follows: The <localfile> specifies the source including path to the file, such as /var/log/maillog . The <remotefile> specifies the destination, which can be a new filename such as /tmp/hostname-maillog . For the remote system, if you do not have a preceding / , the path will be relative to the home directory of username , typically /home/username/ . To transfer the local file shadowman to the home directory of your account on penguin.example.net, type the following at a shell prompt (replace username with your username): This will transfer the local file shadowman to /home/ username /shadowman on penguin.example.net. Alternately, you can leave off the final shadowman in the scp command. The general syntax to transfer a remote file to the local system is as follows: The <remotefile> specifies the source including path, and <newlocalfile> specifies the destination including path. Multiple files can be specified as the source files. For example, to transfer the contents of the directory downloads/ to an existing directory called uploads/ on the remote machine penguin.example.net, type the following at a shell prompt:

Commands:
scp <localfile> username@tohostname:<remotefile>
scp shadowman username @penguin.example.net:shadowman
scp username@tohostname:<remotefile> <newlocalfile>
scp downloads/* username @penguin.example.net:uploads/
Appendix E. Creating an AWS S3 Secret In Red Hat OpenShift, one has the ability to store secrets and use them to authenticate with external services such as Amazon S3. This reference environment takes advantage of an Amazon S3 bucket to satisfy the ReadWriteMany requirement to run automation hub. The following steps show how to create a secret within your Red Hat OpenShift cluster that is to be used during the Chapter 7, Installing automation hub chapter.

Commands:
cat s3-secret.yml
apiVersion: v1 kind: Secret metadata: name: s3-secret namespace: aap stringData: s3-access-key-id: my_key s3-secret-access-key: my_access_key s3-bucket-name: my_bucket s3-region: my_region
oc create -f s3-secret.yml
Chapter 11. File-based configuration Red Hat build of Rhea can read the configuration options used to establish connections from a local file named connect.json . This enables you to configure connections in your application at the time of deployment. The library attempts to read the file when the application calls the container connect method without supplying any connection options. 11.1. File locations If set, Red Hat build of Rhea uses the value of the MESSAGING_CONNECT_FILE environment variable to locate the configuration file. If MESSAGING_CONNECT_FILE is not set, Red Hat build of Rhea searches for a file named connect.json at the following locations and in the order shown. It stops at the first match it encounters. On Linux: USDPWD/connect.json , where USDPWD is the current working directory of the client process USDHOME/.config/messaging/connect.json , where USDHOME is the current user home directory /etc/messaging/connect.json On Windows: %cd%/connect.json , where %cd% is the current working directory of the client process If no connect.json file is found, the library uses default values for all options. 11.2. The file format The connect.json file contains JSON data, with additional support for JavaScript comments. All of the configuration attributes are optional or have default values, so a simple example need only provide a few details: Example: A simple connect.json file { "host": "example.com", "user": "alice", "password": "secret" } SASL and SSL/TLS options are nested under "sasl" and "tls" namespaces: Example: A connect.json file with SASL and SSL/TLS options { "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } } 11.3. Configuration options The option keys containing a dot (.) represent attributes nested inside a namespace. Table 11.1. Configuration options in connect.json Key Value type Default value Description scheme string "amqps" "amqp" for cleartext or "amqps" for SSL/TLS host string "localhost" The hostname or IP address of the remote host port string or number "amqps" A port number or port literal user string None The user name for authentication password string None The password for authentication sasl.mechanisms list or string None (system defaults) A JSON list of enabled SASL mechanisms. A bare string represents one mechanism. If none are specified, the client uses the default mechanisms provided by the system. sasl.allow_insecure boolean false Enable mechanisms that send cleartext passwords tls.cert string None The filename or database ID of the client certificate tls.key string None The filename or database ID of the private key for the client certificate tls.ca string None The filename, directory, or database ID of the CA certificate tls.verify boolean true Require a valid server certificate with a matching hostname

Commands:
host: example.com
user: alice
password: secret
{ "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } }
8.2. Optimized Replication Mode Usage Replication mode is used for state sharing across a cluster; however, if you have a replicated cache and a large number of nodes are in use then there will be many writes to the replicated cache to keep all of the nodes synchronized. The amount of work performed will depend on many factors and on the specific use case, and for this reason it is recommended to ensure that each workload is tested thoroughly to determine if replication mode will be beneficial with the number of planned nodes. For many situations replication mode is not recommended once there are ten servers; however, in some workloads, such as if load read is important, this mode may be beneficial. Red Hat JBoss Data Grid can be configured to use UDP multicast, which improves performance to a limited degree for larger clusters. Report a bug

Commands:
12.4. Configuring the Marshaller using the RemoteCacheManager A Marshaller is specified using the marshaller configuration element in the RemoteCacheManager, the value of which must be the name of the class implementing the Marshaller interface. The default value for this property is org.infinispan.commons.marshall.jboss.GenericJBossMarshaller . The following procedure describes how to define a Marshaller to use with RemoteCacheManager. Procedure 12.1. Define a Marshaller Create a ConfigurationBuilder Create a ConfigurationBuilder and configure it with the required settings. Add a Marshaller Class Add a Marshaller class specification within the Marshaller method. Alternatively, specify a custom Marshaller instance. Start the RemoteCacheManager Build the configuration containing the Marshaller, and start a new RemoteCacheManager with it. At the client level, POJOs need to be either Serializable, Externalizable, or primitive types. Note The Hot Rod Java client does not support providing Externalizer instances to serialize POJOs. This is only available for JBoss Data Grid Library mode. Report a bug

Commands:
ConfigurationBuilder builder = new ConfigurationBuilder(); //... (other configuration)
builder.marshaller(GenericJBossMarshaller.class);
builder.marshaller(new GenericJBossMarshaller());
Configuration configuration = builder.build(); RemoteCacheManager manager = new RemoteCacheManager(configuration);
Chapter 3. Components View all the components from the Product Documentation for Red Hat AMQ Clients page. Additional information Quarkus extension for Qpid JMS (Red Hat build of Apache Qpid JMS) - A Quarkus extension that enables you to build Quarkus applications that use AMQP 1.0 messaging. 3.1. Component compatibility The following table lists the supported languages, platforms, and protocols for the AMQ Clients components. Component Languages Platforms Protocols Red Hat build of Rhea JavaScript Linux, Windows, browsers AMQP 1.0 Red Hat build of Apache Qpid JMS Java JVM AMQP 1.0 AMQ Core Protocol JMS Java JVM Core Protocol Red Hat build of Apache Qpid Proton DotNet C# Linux, Windows AMQP 1.0 Red Hat build of Apache Qpid Proton Python Python Linux, Windows AMQP 1.0 AMQ Spring Boot Starter Java JVM AMQP 1.0 Quarkus extension for Qpid JMS (Red Hat build of Apache Qpid JMS) Java JVM/Native AMQP 1.0 For more information, see Red Hat AMQ Supported Configurations .

Commands:
17.4. Adding or Updating DNS Services After Installation DNS can be configured as part of the IdM server installation, simply by using the --setup-dns option. If DNS is not configured then, it can be configured later using the ipa-dns-install command. The ipa-dns-install command also updates the DNS services on the IdM server. -p gives the password for the Directory Manager user in the 389 Directory Server. All of the DNS entries are stored in the LDAP directory, so this directory must be accessed to add the DNS configuration. --ip-address gives the IP address for the master DNS server. --no-forwarders means that there are no forwarders used with the DNS service, only root servers. Alternatively, use the --forwarder option to define a forward to use; to specify multiple forwarders, use the --forwarder option multiple times. Reverse DNS is configured automatically. It is possible to disable reverse DNS by using the --no-reverse option. If an existing reverse DNS zone is already configured, using the --no-reverse option uses the existing reverse zone rather than creating a new reverse zone. The IdM server, unless it is explicitly disabled, leaves a persistent search open with its Directory Server and capture any new zone changes immediately.

Commands:
ipa-dns-install -p secret --ip-address=1.2.34.56 --no-forwarders
Chapter 2. Accessing the web console The OpenShift Container Platform web console is a user interface accessible from a web browser. Developers can use the web console to visualize, browse, and manage the contents of projects. 2.1. Prerequisites JavaScript must be enabled to use the web console. For the best experience, use a web browser that supports WebSockets . Review the OpenShift Container Platform 4.x Tested Integrations page before you create the supporting infrastructure for your cluster. 2.2. Understanding and accessing the web console The web console runs as a pod on the control plane node. The static assets required to run the web console are served by the pod. After you install OpenShift Container Platform using the openshift-install create cluster command, you can find the web console URL and login credentials for the installed cluster in the CLI output of the installation program. For example: Example output INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided> Use those details to log in and access the web console. For existing clusters that you did not install, you can use oc whoami --show-console to see the web console URL. Important The dir parameter specifies the assets directory, which stores the manifest files, the ISO image, and the auth directory. The auth directory stores the kubeadmin-password and kubeconfig files. As a kubeadmin user, you can use the kubeconfig file to access the cluster with the following setting: export KUBECONFIG=<install_directory>/auth/kubeconfig . The kubeconfig is specific to the generated ISO image, so if the kubeconfig is set and the oc command fails, it is possible that the system did not boot with the generated ISO image. To perform debugging, during the bootstrap process, you can log in to the console as the core user by using the contents of the kubeadmin-password file. Additional resources Enabling feature sets using the web console

Commands:
INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided>
Appendix A. Revision History Revision History Revision 0.1-7 Thu Apr 27 2017 Lenka Spackova Added the deprecated zerombr yes Kickstart command to Deprecated Functionality. Revision 0.1-6 Tue Mar 17 2017 Jiri Herrmann Updated a deprecated feature for virtualization. Revision 0.1-5 Fri Dec 16 2016 Lenka Spackova Removed Indic languages from the International Languages chapter. Revision 0.1-4 Fri Sep 23 2016 Lenka Spackova Added the qla3xxx driver to Deprecated Functionality. Revision 0.1-3 Thu Jul 14 2016 Lenka Spackova Added details regarding support of the i40e driver. Revision 0.1-2 Fri Jun 03 2016 Lenka Spackova Added Bugzilla numbers to individual descriptions. Updated Deprecated Functionality. Revision 0.1-1 Tue May 31 2016 Lenka Spackova Added ypserv and ypbind bug fixes to Authentication and Interoperability. Revision 0.1-0 Mon May 16 2016 Lenka Spackova Added new bug fixes to Clustering (fence agent) and Kernel (iscsi_firmware). Revision 0.0-9 Mon May 09 2016 Lenka Spackova Release of the Red Hat Enterprise Linux 6.8 Technical Notes. Revision 0.0-5 Tue Mar 15 2016 Lenka Spackova Release of the Red Hat Enterprise Linux 6.8 Beta Technical Notes.

Commands:
Chapter 4. Searching for files in GNOME As a user in the GNOME environment, you can search for files using the Files application. 4.1. Performing a basic file search You can search for files in GNOME. This basic search looks for files in your home directory and all folders in it, based on a file name. Procedure Open the Files application. Press the Search button. In the text field, type the file name or a part of the file name that you are searching for. The window now lists all files in your home directory that match the file name. 4.2. Performing an advanced file search You can search for files in GNOME. This advanced search looks for files in a specific location, based on a file name, a time of access, a time of modification, or a file type. Procedure Open the Files application. Navigate to the folder where you want to search for a file. The search recursively descends into all folders contained in this location. Press the Search button. Optional: Type the file name or a part of the file name that you are searching for in the text field. If you do not provide a file name, the search lists all files that match the other criteria, regardless of their file names. Click the triangle button to the text field. In this menu, you can select other search criteria. To specify the access or modification time, click Select dates to the When label. Enter a date or select a time point from the list. Below the time list, you can switch between Last modified and Last used . To specify the file type, click Anything to the What label. Select a file type from the list. To switch between a search based on file content or file names, use the Full Text and File Name buttons, respectively. Note The full-text search only works in indexed locations. You can configure the indexed locations in the Search section of the Settings application. Click the triangle button to the text field to hide the menu. The window now lists all files in the specified directory that match your search criteria.

Commands: