mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 52. Business Central custom dashboards A dashboard is a collection of Business Central pages that contain at least one reporting component. Dashboards often contain data sets, navigation trees, and permissions. There are four stages in the creation of a custom dashboard: Data set authoring: Define a data set for accessing the data and displaying it through the pages. For more information, see Adding data sets . Page authoring: Create the dashboard pages. For more information, see Creating pages . Publication - In this stage, navigation between pages are defined when you create the custom navigation trees or modify the existing default one ( Workbench tree). For more information, see Creating a navigation tree or Editing a navigation tree . Security management - In this stage, role and group permissions are set which defines the privileges that are granted to a user when the user is working on Business Central. For more information, see Security management . Additional resources To migrate dashboards from a version of Business Central, use the Dashbuilder Data Transfer feature described in Section 57.1, "Exporting Business Central dashboard data" .

Commands:
24.7. Additional Resources To learn more about gathering system information, see the following resources. 24.7.1. Installed Documentation ps (1) - The manual page for the ps command. top (1) - The manual page for the top command. free (1) - The manual page for the free command. df (1) - The manual page for the df command. du (1) - The manual page for the du command. lspci (8) - The manual page for the lspci command. snmpd (8) - The manual page for the snmpd service. snmpd.conf (5) - The manual page for the /etc/snmp/snmpd.conf file containing full documentation of available configuration directives.

Commands:
2.3. Using the Batching API 2.3.1. Configure the Batching API To use the Batching API, enable invocation batching in the cache configuration. XML Configuration To configure the Batching API in the XML file, the transactionMode must be TRANSACTIONAL to enable invocationBatching : Programmatic Configuration To configure the Batching API programmatically use: In Red Hat JBoss Data Grid, invocation batching is disabled by default and batching can be used without a defined Transaction Manager. Note Programmatic configurations can only be used with JBoss Data Grid's Library mode. Report a bug 2.3.2. Use the Batching API After the cache is configured to use batching, call startBatch() and endBatch() on the cache as follows to use batching: Example 2.2. Without Using Batch When the cache.put( key , value ); line executes, the values are replaced immediately. Example 2.3. Using Batch When the line cache.endBatch( true ); executes, all modifications made since the batch started are replicated. When the line cache.endBatch( false ); executes, changes made in the batch are discarded. Report a bug 2.3.3. Batching API Usage Example A simple use case that illustrates the Batching API usage is one that involves transferring money between two bank accounts. Example 2.4. Batching API Usage Example Red Hat JBoss Data Grid is used for a transaction that involves transferring money from one bank account to another. If both the source and destination bank accounts are located within JBoss Data Grid, a Batching API is used for this transaction. However, if one account is located within JBoss Data Grid and the other in a database, distributed transactions are required for the transaction. Report a bug

Commands:
<transaction transactionMode="TRANSACTIONAL"> <invocationBatching enabled="true" />
Configuration c = new ConfigurationBuilder().transaction().transactionMode(TransactionMode.TRANSACTIONAL).invocationBatching().enable().build();
Cache cache = cacheManager.getCache();
cache.put("key", "value");
cache.startBatch(); cache.put("k1", "value"); cache.put("k2", "value"); cache.put("k3", "value"); cache.endBatch(true); cache.startBatch(); cache.put("k1", "value"); cache.put("k2", "value"); cache.put("k3", "value"); cache.endBatch(false);
Part VI. Designing a decision service using guided rules As a business analyst or business rules developer, you can define business rules using the guided rules designer in Business Central. These guided rules are compiled into Drools Rule Language (DRL) and form the core of the decision service for your project. Note You can also design your decision service using Decision Model and Notation (DMN) models instead of rule-based or table-based assets. For information about DMN support in Red Hat Decision Manager 7.13, see the following resources: Getting started with decision services (step-by-step tutorial with a DMN decision service example) Designing a decision service using DMN models (overview of DMN support and capabilities in Red Hat Decision Manager) Prerequisites The space and project for the guided rules have been created in Business Central. Each asset is associated with a project assigned to a space. For details, see Getting started with decision services .

Commands:
Part II. Debugging Routing Contexts The Camel debugger includes many features for debugging locally and remotely running routing contexts: Setting conditional and unconditional breakpoints on nodes in the route editor Autolaunching the debugger and switching to the Debug perspective Interacting with the running routing context: Switch between breakpoints to quickly compare variable values of message instances Examine and change the value of variables of interest Add variables of interest to the watch list to track them throughout the debug session Disable and re-enable breakpoints on-the-fly Track message flow graphically in the routing context runtime Examine console logs to track Camel and debugger actions Note Before you can run the Camel debugger, you must set breakpoints on the nodes of interest displayed on the route editor's canvas. Then you can run the Camel debugger on a project's routing context .xml file to find the logic errors in it and fix them. Invoking the Camel debugger runs the routing context in debug mode and opens the Debug Perspective .

Commands:
Chapter 2. Logging into automation controller after installation After you install automation controller, you must log in. Procedure With the login information provided after your installation completed, open a web browser and log in to the automation controller by navigating to its server URL at: https://<CONTROLLER_SERVER_NAME>/ Use the credentials specified during the installation process to login: The default username is admin . The password for admin is the value specified. Click the More Actions icon ... to the desired user. Click Edit . Edit the required details and click Save .

Commands:
Chapter 20. JoSQL Overview The JoSQL (SQL for Java objects) language enables you to evaluate predicates and expressions in Apache Camel. JoSQL employs a SQL-like query syntax to perform selection and ordering operations on data from in-memory Java objects - however, JoSQL is not a database. In the JoSQL syntax, each Java object instance is treated like a table row and each object method is treated like a column name. Using this syntax, it is possible to construct powerful statements for extracting and compiling data from collections of Java objects. For details, see http://josql.sourceforge.net/ . Adding the JoSQL module To use JoSQL in your routes you need to add a dependency on camel-josql to your project as shown in Example 20.1, "Adding the camel-josql dependency" . Example 20.1. Adding the camel-josql dependency Static import To use the sql() static method in your application code, include the following import statement in your Java source files: Variables Table 20.1, "SQL variables" lists the variables that are accessible when using JoSQL. Table 20.1. SQL variables Name Type Description exchange org.apache.camel.Exchange The current Exchange in org.apache.camel.Message The IN message out org.apache.camel.Message The OUT message property Object the Exchange property whose key is property header Object the IN message header whose key is header variable Object the variable whose key is variable Example Example 20.2, "Route using JoSQL" shows a route that uses JoSQL. Example 20.2. Route using JoSQL

Commands:
<!-- Maven POM File --> <dependencies> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-josql</artifactId> <version>USD{camel-version}</version> </dependency> </dependencies>
import static org.apache.camel.builder.sql.SqlBuilder.sql;
<camelContext> <route> <from uri="direct:start"/> <setBody> <language language="sql">select * from MyType</language> </setBody> <to uri="seda:regularQueue"/> </route> </camelContext>
7.3. Diagnosing and Correcting Problems in a Cluster For information about diagnosing and correcting problems in a cluster, see Chapter 10, Diagnosing and Correcting Problems in a Cluster . There are a few simple checks that you can perform with the ccs command, however. To verify that all of the nodes specified in the host's cluster configuration file have identical cluster configuration files, execute the following command: If you have created or edited a configuration file on a local node, you can verify that all of the nodes specified in the local file have identical cluster configuration files with the following command:

Commands:
ccs -h host --checkconf
ccs -f file --checkconf
16.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: ftpd_use_nfs When enabled, this Boolean allows the ftpd daemon to access NFS volumes. cobbler_use_nfs When enabled, this Boolean allows the cobblerd daemon to access NFS volumes. git_system_use_nfs When enabled, this Boolean allows the Git system daemon to read system shared repositories on NFS volumes. httpd_use_nfs When enabled, this Boolean allows the httpd daemon to access files stored on NFS volumes. samba_share_nfs When enabled, this Boolean allows the smbd daemon to share NFS volumes. When disabled, this Boolean prevents smbd from having full access to NFS shares using Samba. sanlock_use_nfs When enabled, this Boolean allows the sanlock daemon to manage NFS volumes. sge_use_nfs When enabled, this Boolean allows the sge scheduler to access NFS volumes. use_nfs_home_dirs When enabled, this Boolean adds support for NFS home directories. virt_use_nfs When enabled, this Boolean allows confident virtual guests to manage files on NFS volumes. xen_use_nfs When enabled, this Boolean allows Xen to manage files on NFS volumes. git_cgi_use_nfs When enabled, this Boolean allows the Git Common Gateway Interface ( CGI ) to access NFS volumes. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
B.50.2. RHBA-2010:0851 - luci bug fix update An updated luci package that fix a bug are now available for Red Hat Enterprise Linux 6. The luci package contains a web-based high availability cluster configuration application. Bug Fix BZ# 642140 Previously, Luci did not allow users to configure unfencing. Due to this, SAN fencing agents and fence_scsi could not be unfenced on system boot. This update adds a default option for the SAN fence configuration pages that enable the unfencing functionality. All luci users are advised to upgrade to this updated package, which fix this bug.

Commands:
Chapter 4. Authenticating to registry.redhat.io for Wasm plug-in access For RateLimitPolicy and AuthPolicy only, you must authenticate to registry.redhat.io to access the Wasm plug-in image used with OpenShift Service Mesh as the Gateway API provider. Prerequisites You have credentials to access registry.redhat.io . If you do not have access, see Creating Registry Service Accounts . Procedure Create the namespace for your Gateway, for example: Create the following secret in your Gateway namespace: Repeat this step in each Gateway namespace in which you deploy a RateLimitPolicy or AuthPolicy.

Commands:
create ns api-gateway
create secret docker-registry wasm-plugin-pull-secret -n api-gateway \ --docker-server=registry.redhat.io \ --docker-username=your-registry-service-account-username \ --docker-password=your-registry-service-account-password
Chapter 2. Overview of the upgrade process The in-place upgrade process from RHEL 7 to RHEL 8 can be summarized as follows: Plan the upgrade Review the system requirements and limitations. Determine whether your system is a good candidate for an in-place upgrade, or if you should perform a clean install of RHEL 8 instead. Prepare for the upgrade Complete required preparatory steps, including creating a backup of your RHEL 7 system, before beginning the upgrade process. Run and review the pre-upgrade report Run the pre-upgrade utility to generate a report that summarizes potential problems that must be resolved before the upgrade. Depending on the severity and impact of the found problems and the amount of work required to resolve them, proceed with one of the following outcomes: Remediate found problems and apply recommended solutions. Rerun the pre-upgrade utility to verify that all serious problems have been resolved. You might need to run the pre-upgrade report and resolve found issues multiple times before your system is ready for the upgrade. Switch to a clean installation of RHEL 8 instead of proceeding with the in-place upgrade. Perform the in-place upgrade Perform the upgrade to RHEL 8 and verify that the upgrade has been completed correctly. If the upgrade encounters issues that cannot be resolved, perform a rollback to your RHEL 7 backup. Perform post-upgrade steps Perform required post-upgrade steps to ensure that the RHEL 8 system is properly set up.

Commands:
Chapter 8. Known issues This section lists the known issues for AMQ Streams 2.5 on RHEL. 8.1. JMX authentication when running in FIPS mode When running AMQ Streams in FIPS mode with JMX authentication enabled, clients may fail authentication. To work around this issue, do not enable JMX authentication while running in FIPS mode. We are investigating the issue and working to resolve it in a future release.

Commands:
8.2.3. Types of Backups If you were to ask a person that was not familiar with computer backups, most would think that a backup was just an identical copy of all the data on the computer. In other words, if a backup was created Tuesday evening, and nothing changed on the computer all day Wednesday, the backup created Wednesday evening would be identical to the one created on Tuesday. While it is possible to configure backups in this way, it is likely that you would not. To understand more about this, we must first understand the different types of backups that can be created. They are: Full backups Incremental backups Differential backups 8.2.3.1. Full Backups The type of backup that was discussed at the beginning of this section is known as a full backup . A full backup is a backup where every single file is written to the backup media. As noted above, if the data being backed up never changes, every full backup being created will be the same. That similarity is due to the fact that a full backup does not check to see if a file has changed since the last backup; it blindly writes everything to the backup media whether it has been modified or not. This is the reason why full backups are not done all the time -- every file is written to the backup media. This means that a great deal of backup media is used even if nothing has changed. Backing up 100 gigabytes of data each night when maybe 10 megabytes worth of data has changed is not a sound approach; that is why incremental backups were created.

Commands:
Chapter 4. Testing the configured back end After you deploy the back ends to the overcloud, test that you can successfully create volumes on them. Procedure Run the following command as the stack user to load the environment variables defined in home/stack/overcloudrec : For more information, see Accessing the overcloud in the Director Installation and Usage guide. Create a volume type for each back end. Log in to the Controller node of the overcloud as the stack user and run the following command: These commands create the volume types backend1 and backend2 , one for each back end that is defined with the cinder::config::cinder_config class of the environment file that you created. Map each volume type to the volume_backend_name of a back end that is enabled with the cinder_user_enabled_backends class of the environment file that you created The following commands map the volume type backend1 to netapp1 and backend2 to netapp2 : Run the following command to test that it is possible to create a back end on netapp1 by invoking the backend1 volume type: Create a similar volume on the netapp2 back end by invoking the backend2 volume type:

Commands:
source /home/stack/overcloudrc
cinder type-create backend1 cinder type-create backend2
cinder type-key backend1 set volume_backend_name=netapp1 cinder type-key backend2 set volume_backend_name=netapp2
cinder create --volume-type backend1 --display_name netappvolume_1 1
cinder create --volume-type backend2 --display_name netappvolume_2 1
Chapter 2. Installing the JBoss EAP collection As a first step toward automating deployments of Red Hat JBoss Enterprise Application Platform (JBoss EAP) by using Ansible, you must download and install the JBoss EAP collection from Ansible automation hub . The JBoss EAP collection is named redhat.eap in Ansible automation hub . Before you install the JBoss EAP collection, you must ensure that your system complies with certain prerequisites. Prerequisites You have installed the ansible-core package version 2.14 or later on a control node in your system by installing Red Hat Ansible Automation Platform 2. x . For more information about installing Red Hat Ansible Automation Platform, see the Red Hat Ansible Automation Platform Installation Guide . You have updated the ansible.cfg file to use Ansible automation hub as your primary source of Ansible collections. For more information about updating the ansible.cfg file, see Getting started with automation hub . Procedure On your Ansible control node, enter the following command: Note If the preceding command produces a Failed to find collection redhat.eap:* error message, ensure that you have updated the ansible.cfg file correctly to use Ansible automation hub, as described in Getting started with automation hub . The preceding command produces the following output: For the sake of brevity, the preceding example uses ellipses to denote omitted text. In the preceding output, <version> represents the latest available versions of the installed redhat.eap , redhat.runtimes_common , and ansible.posix collections. Verification On your Ansible control node, enter the following command: The preceding command displays the list of installed collections. For example: As shown in the preceding example, when you install the redhat.eap collection, the latest versions of the ansible.posix and redhat.runtimes_common collections are also automatically downloaded and installed on your Ansible control node. The redhat.runtimes_common collection provides a set of standard utilities to support the automated deployment of various Red Hat Runtimes products, such as JBoss EAP. Note If the latest versions of the ansible.posix and redhat.runtimes_common collections already exist on your Ansible control node, these collections are not automatically installed again. Additional resources Automation Hub: Connect to Hub

Commands:
ansible-galaxy collection install redhat.eap
Starting galaxy collection install process Process install dependency map Starting collection install process redhat.eap: <version> was installed successfully redhat.runtimes_common: <version> was installed successfully ansible.posix: <version> was installed successfully
ansible-galaxy collection list
Collection Version -------------------------- ------- ansible.posix <version> redhat.eap <version> redhat.runtimes_common <version>
Chapter 1. Overview Installer-provisioned installation on bare metal nodes deploys and configures the infrastructure that an OpenShift Container Platform cluster runs on. This guide provides a methodology to achieving a successful installer-provisioned bare-metal installation. The following diagram illustrates the installation environment in phase 1 of deployment: For the installation, the key elements in the diagram are: Provisioner : A physical machine that runs the installation program and hosts the bootstrap VM that deploys the control plane of a new OpenShift Container Platform cluster. Bootstrap VM : A virtual machine used in the process of deploying an OpenShift Container Platform cluster. Network bridges : The bootstrap VM connects to the bare metal network and to the provisioning network, if present, via network bridges, eno1 and eno2 . API VIP : An API virtual IP address (VIP) is used to provide failover of the API server across the control plane nodes. The API VIP first resides on the bootstrap VM. A script generates the keepalived.conf configuration file before launching the service. The VIP moves to one of the control plane nodes after the bootstrap process has completed and the bootstrap VM stops. In phase 2 of the deployment, the provisioner destroys the bootstrap VM automatically and moves the virtual IP addresses (VIPs) to the appropriate nodes. The keepalived.conf file sets the control plane machines with a lower Virtual Router Redundancy Protocol (VRRP) priority than the bootstrap VM, which ensures that the API on the control plane machines is fully functional before the API VIP moves from the bootstrap VM to the control plane. Once the API VIP moves to one of the control plane nodes, traffic sent from external clients to the API VIP routes to an haproxy load balancer running on that control plane node. This instance of haproxy load balances the API VIP traffic across the control plane nodes. The Ingress VIP moves to the worker nodes. The keepalived instance also manages the Ingress VIP. The following diagram illustrates phase 2 of deployment: After this point, the node used by the provisioner can be removed or repurposed. From here, all additional provisioning tasks are carried out by the control plane. Note For installer-provisioned infrastructure installations, CoreDNS exposes port 53 at the node level, making it accessible from other routable networks. Additional resources Using DNS forwarding Important The provisioning network is optional, but it is required for PXE booting. If you deploy without a provisioning network, you must use a virtual media baseboard management controller (BMC) addressing option such as redfish-virtualmedia or idrac-virtualmedia .

Commands:
1.4. DM-Multipath Components Table 1.1, "DM-Multipath Components" . describes the components of DM-Multipath. Table 1.1. DM-Multipath Components Component Description dm_multipath kernel module Reroutes I/O and supports failover for paths and path groups. mpathconf utility Configures and enables device mapper multipathing. multipath command Lists and configures multipath devices. Normally started up with /etc/rc.sysinit , it can also be started up by a udev program whenever a block device is added. multipathd daemon Monitors paths; as paths fail and come back, it may initiate path group switches. Provides for interactive changes to multipath devices. This must be restarted for any changes to the /etc/multipath.conf file. kpartx command Creates device mapper devices for the partitions on a device It is necessary to use this command for DOS-based partitions with DM-MP. The kpartx is provided in its own package, but the device-mapper-multipath package depends on it.

Commands: