mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 81. Mail Microsoft Oauth Since Camel 3.18.4 . The Mail Microsoft OAuth2 provides an implementation of org.apache.camel.component.mail.MailAuthenticator to authenticate IMAP/POP/SMTP connections and access to Email via Spring's Mail support and the underlying JavaMail system. 81.1. Dependencies Add the following dependency to your pom.xml for this component: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-mail-microsoft-oauth</artifactId> </dependency> Importing camel-mail-microsoft-oauth will automatically import camel-mail component. 81.2. Microsoft Exchange Online OAuth2 Mail Authenticator IMAP sample To use OAuth, an application must be registered with Azure Active Directory. Follow the instructions to register a new application. Procedure Enable the application to access Exchange mailboxes via client credentials flow. For more information, see Authenticate an IMAP, POP or SMTP connection using OAuth Once everything is set up, declare and register in the registry, an instance of org.apache.camel.component.mail.MicrosoftExchangeOnlineOAuth2MailAuthenticator . For Example, in a Spring Boot application: @BindToRegistry("auth") public MicrosoftExchangeOnlineOAuth2MailAuthenticator exchangeAuthenticator(){ return new MicrosoftExchangeOnlineOAuth2MailAuthenticator(tenantId, clientId, clientSecret, "jon@doe.com"); } Then reference it in the Camel URI as follows: from("imaps://outlook.office365.com:993" + "?authenticator=#auth" + "&mail.imaps.auth.mechanisms=XOAUTH2" + "&debugMode=true" + "&delete=false")

Commands:
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-mail-microsoft-oauth</artifactId> </dependency>
@BindToRegistry("auth") public MicrosoftExchangeOnlineOAuth2MailAuthenticator exchangeAuthenticator(){ return new MicrosoftExchangeOnlineOAuth2MailAuthenticator(tenantId, clientId, clientSecret, "jon@doe.com"); }
from("imaps://outlook.office365.com:993" + "?authenticator=#auth" + "&mail.imaps.auth.mechanisms=XOAUTH2" + "&debugMode=true" + "&delete=false")
A.3. Explanation of Settings in the New Network Interface and Edit Network Interface Windows These settings apply when you are adding or editing a virtual machine network interface. If you have more than one network interface attached to a virtual machine, you can put the virtual machine on more than one logical network. Table A.20. Network Interface Settings Field Name Description Power cycle required? Name The name of the network interface. This text field has a 21-character limit and must be a unique name with any combination of uppercase and lowercase letters, numbers, hyphens, and underscores. No. Profile The vNIC profile and logical network that the network interface is placed on. By default, all network interfaces are put on the ovirtmgmt management network. No. Type The virtual interface the network interface presents to virtual machines. rtl8139 and e1000 device drivers are included in most operating systems. VirtIO is faster but requires VirtIO drivers. Red Hat Enterprise Linux 5 and later include VirtIO drivers. Windows does not include VirtIO drivers, but they can be installed from the guest tools ISO or virtual floppy disk. PCI Passthrough enables the vNIC to be directly connected to a virtual function (VF) of an SR-IOV-enabled NIC. The vNIC will then bypass the software network virtualization and connect directly to the VF for direct device assignment. The selected vNIC profile must also have Passthrough enabled. Yes. Custom MAC address Choose this option to set a custom MAC address. The Red Hat Virtualization Manager automatically generates a MAC address that is unique to the environment to identify the network interface. Having two devices with the same MAC address online in the same network causes networking conflicts. Yes. Link State Whether or not the network interface is connected to the logical network. Up : The network interface is located on its slot. When the Card Status is Plugged , it means the network interface is connected to a network cable, and is active. When the Card Status is Unplugged , the network interface will automatically be connected to the network and become active once plugged. Down : The network interface is located on its slot, but it is not connected to any network. Virtual machines will not be able to run in this state. No. Card Status Whether or not the network interface is defined on the virtual machine. Plugged : The network interface has been defined on the virtual machine. If its Link State is Up , it means the network interface is connected to a network cable, and is active. If its Link State is Down , the network interface is not connected to a network cable. Unplugged : The network interface is only defined on the Manager, and is not associated with a virtual machine. If its Link State is Up , when the network interface is plugged it will automatically be connected to a network and become active. If its Link State is Down , the network interface is not connected to any network until it is defined on a virtual machine. No.

Commands:
Chapter 4. Configuration The AMQ JMS Pool ConnectionFactory implementation exposes several configuration options that control the behavior of the pool and the JMS resources it manages. The configuration options are exposed as set methods on the JmsPoolConnectionFactory object. For example, the maxConnections option is set using the setMaxConnections(int) method. 4.1. Connection options These options affect how the JMS pool creates and manages the connections in the pool. The pooled ConnectionFactory creates a pool of connections for each user and password combination used to create a connection, plus a separate pool for those without a username or password. If you require a more fine-grained division of connections into pools, you must explicitly create distinct pool instances. maxConnections The maximum number of connections for a single pool. The default is 1. connectionIdleTimeout The time in milliseconds before a connection not currently on loan can be evicted from the pool. The default is 30 seconds. A value of 0 disables the timeout. connectionCheckInterval The time in milliseconds between periodic checks for expired connections. The default is 0, meaning the check is disabled. useProviderJMSContext If enabled, use the JMSContext classes of the underlying JMS provider. It is disabled by default. In normal operation, the pool uses its own generic JMSContext implementation to wrap connections from the pool instead of using the provider implementation. The generic implementation might have limitations the provider implementation does not. However, when enabled, connections from the JMSContext API are not managed by the pool. 4.2. Session options These options affect the behavior of sessions that are created from pooled connections. maxSessionsPerConnection The maximum number of sessions for each connection. The default is 500. A negative value removes any limit. If the limit is exceeded, createSession() either blocks or throws an exception, depending on configuration. blockIfSessionPoolIsFull If enabled, block createSession() until a session becomes available in the pool. It is enabled by default. If disabled, calls to createSession() throw an IllegalStateException if no session is available. blockIfSessionPoolIsFullTimeout The time in milliseconds before a blocked call to createSession() throws an IllegalStateException . The default is -1, meaning the call blocks forever. useAnonymousProducers If enabled, use a single anonymous JMS MessageProducer for all calls to createProducer() . It is enabled by default. In rare cases, this behavior is undesirable. If disabled, every call to createProducer() results in a new MessageProducer instance.

Commands:
13.2.27. Seeding Users into the SSSD Cache During Kickstart Note Adding user accounts manually requires the sssd-tools package to be installed. With SSSD, users in a remote domain are not available in a local system until that identity is retrieved from the identity provider. However, some network interfaces are not available until a user has logged in - which is not possible if the user identity is somewhere over the network. In that case, it is possible to seed the SSSD cache with that user identity, associated with the appropriate domain, so that the user can log in locally and active the appropriate interfaces. This is done using the sss_seed utility: This utility requires options that identify, at a minimum, the user name, domain name, and password. --domain gives the domain name from the SSSD configuration. This domain must already exist in the SSSD configuration. --username for the short name of the user account. --password-file for the path and name of a file containing a temporary password for the seed entry. If the user account already exists in the SSSD cache, then the temporary password in this file overwrites the stored password in the SSSD cache. Additional account configuration options are listed in the sss_seed(8) man page. This would almost always be run as part of a kickstart or automated setup, so it would be part of a larger set of scripts, which would also enable SSSD, set up an SSSD domain, and create the password file. For example:

Commands:
sss_seed --domain EXAMPLE.COM --username testuser --password-file /tmp/sssd-pwd.txt
function make_sssd { cat <<- _EOF_ [sssd] domains = LOCAL services = nss,pam [nss] [pam] [domain/LOCAL] id_provider = local auth_provider = local access_provider = permit _EOF_ } make_sssd >> /etc/sssd/sssd.conf authconfig --enablesssd --enablesssdauth --update function make_pwdfile { cat <<1 _EOF_ password _EOF_ } make_pwdfile >> /tmp/sssd-pwd.txt sss_seed --domain EXAMPLE.COM --username testuser --password-file /tmp/sssd-pwd.txt
10.4.2. Capturing the Core When the Daemon Crashes By default, the /etc/init.d/functions script blocks core files from daemons called by /etc/init.d/rgmanager . For the daemon to create application cores, you must enable that option. This procedure must be done on all cluster nodes that need an application core caught. For creating a core file when the rgmanager daemon crashes, edit the /etc/sysconfig/cluster file. The DAEMONCOREFILELIMIT parameter allows the daemon to create core files if the process crashes. There is a -w option that prevents the watchdog process from running. The watchdog daemon is responsible for rebooting the cluster node if rgmanager crashes and, in some cases, if the watchdog daemon is running then the core file will not be generated, so it must be disabled to capture core files. Restart rgmanager to activate the new configuration options: Note If cluster services are running on this cluster node, then it could leave the running services in a bad state. The core file will be written when it is generated from a crash of the rgmanager process. The output should appear similar to the following: Move or delete any old cores files under the / directory before restarting rgmanager to capture the application core. The cluster node that experienced the rgmanager crash should be rebooted or fenced after the core is captured to ensure that the watchdog process was not running.

Commands:
DAEMONCOREFILELIMIT="unlimited" RGMGR_OPTS="-w"
service rgmanager restart
ls /core*
/core.11926
Chapter 16. Messaging Parameters You can modify the message queue service with messaging parameters. Parameter Description RpcCertificateKeySize Override the private key size used when creating the certificate for this service. RpcPassword The password for messaging backend. RpcPort The network port for messaging backend. The default value is 5672 . RpcUserName The username for messaging backend. The default value is guest . RpcUseSSL Messaging client subscriber parameter to specify an SSL connection to the messaging host. The default value is false .

Commands:
Chapter 1. Issue: Auto-reboot during Argo CD sync with machine configurations In the Red Hat OpenShift Container Platform, nodes are updated automatically through the Red Hat OpenShift Machine Config Operator (MCO). A Machine Config Operator (MCO) is a custom resource that is used by the cluster to manage the complete life cycle of its nodes. When an MCO resource is created or updated in a cluster, the MCO picks up the update, performs the necessary changes to the selected nodes, and restarts the nodes gracefully by cordoning, draining, and rebooting those nodes. It handles everything from the kernel to the kubelet. However, interactions between the MCO and the GitOps workflow can introduce major performance issues and other undesired behaviors. This section shows how to make the MCO and the Argo CD GitOps orchestration tool work well together. 1.1. Solution: Enhance performance in machine configurations and Argo CD When you are using a Machine Config Operator as part of a GitOps workflow, the following sequence can produce suboptimal performance: Argo CD starts an automated sync job after a commit to the Git repository that contains application resources. If Argo CD notices a new or an updated machine configuration while the sync operation is in process, MCO picks up the change to the machine configuration and starts rebooting the nodes to apply the change. If a rebooting node in the cluster contains the Argo CD application controller, the application controller terminates, and the application sync is aborted. As the MCO reboots the nodes in sequential order, and the Argo CD workloads can be rescheduled on each reboot, it can take some time for the sync to be completed. This results in an undefined behavior until the MCO has rebooted all nodes affected by the machine configurations within the sync. 1.2. Additional resources Preventing nodes from auto-rebooting during Argo CD sync with machine configs

Commands:
13.10. Preventing the Computer from Suspending when Closing the Lid When closing the lid of your laptop, your computer suspends in order to save power. You can prevent the computer from suspending when closing the lid by changing the setting for that behavior. Warning Some laptops can overheat if they are left running with the lid closed, especially if they are in a confined place like a backpack. Therefore, consider if changing the default setting (suspend) is the best option in your case. Procedure 13.10. Configuring the lid switch Open the /etc/systemd/logind.conf file for editing. Find the HandleLidSwitch=suspend line in the file. If it is quoted out with the # character at the start, unquote it. If the line is not present in the file, add it. Replace the default suspend parameter with lock for the screen to lock; ignore for nothing to happen; poweroff for the computer to switch off. For example: Save your changes and close the editor. Run the following command so that your changes preserve the restart of the system: Warning Keep in mind that restarting the service forcibly interrupts any currently running GNOME session of any desktop user who is logged in. This can result in users losing unsaved data. For more information on the /etc/systemd/logind.conf file, see the logind.conf(5) man page.

Commands:
[Login] HandleLidSwitch= lock
systemctl restart systemd-logind.service
Chapter 1. Overview Troubleshooting OpenShift Data Foundation is written to help administrators understand how to troubleshoot and fix their Red Hat OpenShift Data Foundation cluster. Most troubleshooting tasks focus on either a fix or a workaround. This document is divided into chapters based on the errors that an administrator may encounter: Chapter 2, Downloading log files and diagnostic information using must-gather shows you how to use the must-gather utility in OpenShift Data Foundation. Chapter 3, Commonly required logs for troubleshooting shows you how to obtain commonly required log files for OpenShift Data Foundation. Chapter 6, Troubleshooting alerts and errors in OpenShift Data Foundation shows you how to identify the encountered error and perform required actions.

Commands:
Chapter 16. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premises. 16.1. Red Hat Marketplace features Cluster administrators can use the Red Hat Marketplace to manage software on OpenShift Dedicated, give developers self-service access to deploy application instances, and correlate application usage against a quota. 16.1.1. Connect OpenShift Dedicated clusters to the Marketplace Cluster administrators can install a common set of applications on OpenShift Dedicated clusters that connect to the Marketplace. They can also use the Marketplace to track cluster usage against subscriptions or quotas. Users that they add by using the Marketplace have their product usage tracked and billed to their organization. During the cluster connection process , a Marketplace Operator is installed that updates the image registry secret, manages the catalog, and reports application usage. 16.1.2. Install applications Cluster administrators can install Marketplace applications from within OperatorHub in OpenShift Dedicated, or from the Marketplace web application . You can access installed applications from the web console by clicking Operators > Installed Operators . 16.1.3. Deploy applications from different perspectives You can deploy Marketplace applications from the web console's Administrator and Developer perspectives. The Developer perspective Developers can access newly installed capabilities by using the Developer perspective. For example, after a database Operator is installed, a developer can create an instance from the catalog within their project. Database usage is aggregated and reported to the cluster administrator. This perspective does not include Operator installation and application usage tracking. The Administrator perspective Cluster administrators can access Operator installation and application usage information from the Administrator perspective. They can also launch application instances by browsing custom resource definitions (CRDs) in the Installed Operators list.

Commands:
Chapter 8. Running a SpringBoot business application on Red Hat OpenShift Container Platform To run your Red Hat Decision Manager SpringBoot business application on Red Hat OpenShift Container Platform, create an immutable image and push this image to your Red Hat OpenShift Container Platform environment. Prerequisites You have developed a Red Hat Decision Manager SpringBoot business application. For instructions about creating the application, see Section 3.1, "Creating a Spring Boot business application from Maven archetypes" . If necessary, you have configured Spring security for the application. For instructions about configuring Spring security, see Chapter 4, Spring Security with Red Hat Decision Manager . You have completed any necessary additional Spring configuration for the business application. For instructions about Spring configuration for your business application, see Chapter 5, Red Hat Decision Manager Spring Boot configuration . You created a single JAR file for the business application. For instructions about creating a single JAR file for your SpringBoot business application, see Chapter 6, Creating a self-contained Red Hat Decision Manager Spring Boot JAR file . You are logged on to your Red Hat OpenShift Container Platform environment using the oc command and the required project is active. Procedure Outside the business application project directories, create an ocp-image directory with the following subdirectories: Copy the single JAR file for your business application into the root/opt/spring-service subdirectory. For example: In the ocp-image directory, create a Dockerfile file with the following content: Replace <FILENAME>.jar with the name of the single JAR file for your business application. To build the initial image and deploy it in your Red Hat OpenShift Container Platform environment, complete the following steps: To build the image, run the following commands in the ocp-image directory: Optional: replace openshift-kie-springboot with a custom application name in these commands and all subsequent commands. To deploy the image in the Red Hat OpenShift Container Platform environment, run the following command: Optional: To expose the route for the image, run the following command: If you already built and deployed the image and need to update it, for example if you built the JAR file for a new version of Red Hat Decision Manager or of Spring Boot, run the following command in the ocp-image directory:

Commands:
ocp-image |--/root |--/opt |-- /spring-service
cd ../business-application-service cp target/business-application-service-1.0-SNAPSHOT.jar ../ocp-image/root/opt/spring-service/
FROM registry.access.redhat.com/ubi8/openjdk-11:latest COPY root / EXPOSE 8090 WORKDIR /opt/spring-service/ CMD ["sh","-c", "java USD{JAVA_OPTIONS} -Dorg.kie.server.mode=PRODUCTION -jar /opt/spring-service/<FILENAME>.jar"]
new-build --binary --strategy=docker --name openshift-kie-springboot start-build openshift-kie-springboot --from-dir=. --follow
new-app openshift-kie-springboot
expose service/openshift-kie-springboot --port=8090
start-build openshift-kie-springboot --from-dir=. --follow
A.2. Wake-ups Many applications scan configuration files for changes. In many cases, the scan is performed at a fixed interval, for example, every minute. This can be a problem, because it forces a disk to wake up from spindowns. The best solution is to find a good interval, a good checking mechanism, or to check for changes with inotify and react to events. Inotify can check variety of changes on a file or a directory. Example A.1. Using inotify int fd; fd = inotify_init(); int wd; /* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { inotify_cant_be_used(); switching_back_to_previous_checking(); } ... fd_set rdfs; struct timeval tv; int retval; FD_ZERO(&rdfs); FD_SET(0, &rdfs); tv.tv_sec = 5; value = select(1, &rdfs, NULL, NULL, &tv); if (value == -1) perror(select); else { do_some_stuff(); } ... The advantage of this approach is the variety of checks that you can perform. The main limitation is that only a limited number of watches are available on a system. The number can be obtained from /proc/sys/fs/inotify/max_user_watches and although it can be changed, this is not recommended. Furthermore, in case inotify fails, the code has to fall back to a different check method, which usually means many occurrences of #if #define in the source code. For more information on inotify , refer to the inotify(7) man page.

Commands:
int fd; fd = inotify_init(); int wd; /* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { inotify_cant_be_used(); switching_back_to_previous_checking(); } fd_set rdfs; struct timeval tv; int retval; FD_ZERO(&rdfs); FD_SET(0, &rdfs); tv.tv_sec = 5; value = select(1, &rdfs, NULL, NULL, &tv); if (value == -1) perror(select); else { do_some_stuff(); }