mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 80. Decision engine in Red Hat Decision Manager The decision engine is the rules engine in Red Hat Decision Manager. The decision engine stores, processes, and evaluates data to execute the business rules or decision models that you define. The basic function of the decision engine is to match incoming data, or facts , to the conditions of rules and determine whether and how to execute the rules. The decision engine operates using the following basic components: Rules: Business rules or DMN decisions that you define. All rules must contain at a minimum the conditions that trigger the rule and the actions that the rule dictates. Facts: Data that enters or changes in the decision engine that the decision engine matches to rule conditions to execute applicable rules. Production memory: Location where rules are stored in the decision engine. Working memory: Location where facts are stored in the decision engine. Agenda: Location where activated rules are registered and sorted (if applicable) in preparation for execution. When a business user or an automated system adds or updates rule-related information in Red Hat Decision Manager, that information is inserted into the working memory of the decision engine in the form of one or more facts. The decision engine matches those facts to the conditions of the rules that are stored in the production memory to determine eligible rule executions. (This process of matching facts to rules is often referred to as pattern matching .) When rule conditions are met, the decision engine activates and registers rules in the agenda, where the decision engine then sorts prioritized or conflicting rules in preparation for execution. The following diagram illustrates these basic components of the decision engine: Figure 80.1. Overview of basic decision engine components For more details and examples of rule and fact behavior in the decision engine, see Chapter 82, Inference and truth maintenance in the decision engine . These core concepts can help you to better understand other more advanced components, processes, and sub-processes of the decision engine, and as a result, to design more effective business assets in Red Hat Decision Manager.

Commands:
Chapter 29. Keyboard Configuration The installation program allows users to configure a keyboard layout for their systems. To configure a different keyboard layout after installation, use the Keyboard Configuration Tool . To start the Keyboard Configuration Tool , select Applications (the main menu on the panel) => System Settings => Keyboard , or type the command system-config-keyboard at a shell prompt. Figure 29.1. Keyboard Configuration Select a keyboard layout from the list (for example, U.S. English ) and click OK . For changes to take effect, you should log out of your graphical desktop session and log back in.

Commands:
Chapter 1. About Red Hat AMQ 7 Red Hat AMQ provides fast, lightweight, and secure messaging for Internet-scale applications. AMQ Broker supports multiple protocols and fast message persistence. AMQ Interconnect leverages the AMQP protocol to distribute and scale your messaging resources across the network. AMQ Clients provides a suite of messaging APIs for multiple languages and platforms. Think of the AMQ components as tools inside a toolbox. They can be used together or separately to build and maintain your messaging application, and AMQP is the glue in the toolbox that binds them together. AMQ components share a common management console, so you can manage them from a single interface. Note Red Hat AMQ 7 includes AMQ Streams. It is based on Apache Kafka, and does not support AMQP. 1.1. Key features AMQ enables developers to build messaging applications that are fast, reliable, and easy to administer. Messaging at internet scale AMQ contains the tools to build advanced, multi-datacenter messaging networks. It can connect clients, brokers, and stand-alone services in a seamless messaging fabric. Top-tier security and performance AMQ offers modern SSL/TLS encryption and extensible SASL authentication. AMQ delivers fast, high-volume messaging and class-leading JMS performance. Broad platform and language support AMQ works with multiple languages and operating systems, so your diverse application components can communicate. AMQ supports C++, Java, JavaScript, Python, Ruby, and .NET applications, as well as Linux, Windows, and JVM-based environments. Focused on standards AMQ implements the Java JMS 1.1 and 2.0 API specifications. Its components support the ISO-standard AMQP 1.0 and MQTT messaging protocols, as well as STOMP and WebSocket. Centralized management With AMQ, you can administer all AMQ components from a single management interface. You can use JMX or the REST interface to manage servers programmatically.

Commands:
3.2. Starting the Virtual Machine Using the Run Once Option 3.2.1. Installing Windows on VirtIO-Optimized Hardware Install VirtIO-optimized disk and network device drivers during your Windows installation by attaching the virtio-win.vfd diskette to your virtual machine. These drivers provide a performance improvement over emulated device drivers. Use the Run Once option to attach the diskette in a one-off boot different from the Boot Options defined in the New Virtual Machine window. This procedure presumes that you added a Red Hat VirtIO network interface and a disk that uses the VirtIO interface to your virtual machine. Note The virtio-win.vfd diskette is placed automatically on ISO storage domains that are hosted on the Manager. You can upload it manually to a data storage domain. See Uploading Images to a Data Storage Domain in the Administration Guide for details. Installing VirtIO Drivers during Windows Installation Click Compute Virtual Machines and select a virtual machine. Click Run Run Once . Expand the Boot Options menu. Select the Attach Floppy check box, and select virtio-win.vfd from the drop-down list. Select the Attach CD check box, and select the required Windows ISO from the drop-down list. Move CD-ROM to the top of the Boot Sequence field. Configure the rest of your Run Once options as required. See Section A.2, "Explanation of Settings in the Run Once Window" for more details. Click OK . The Status of the virtual machine changes to Up , and the operating system installation begins. Open a console to the virtual machine if one does not open automatically. Windows installations include an option to load additional drivers early in the installation process. Use this option to load drivers from the virtio-win.vfd diskette that was attached to your virtual machine as A: . For each supported virtual machine architecture and Windows version, there is a folder on the disk containing optimized hardware device drivers. 3.2.2. Opening a Console to a Virtual Machine Use Remote Viewer to connect to a virtual machine. Connecting to Virtual Machines Install Remote Viewer if it is not already installed. See Section 1.4.1, "Installing Console Components" . Click Compute Virtual Machines and select a virtual machine. Click Console . If the connection protocol is set to SPICE, a console window will automatically open for the virtual machine. If the connection protocol is set to VNC, a console.vv file will be downloaded. Click on the file and a console window will automatically open for the virtual machine. Note You can configure the system to automatically connect to a virtual machine. See Section 2.2.4, "Automatically Connecting to a Virtual Machine" .

Commands:
Chapter 1. Monitoring high availability services Red Hat OpenStack Services on OpenShift (RHOSO) high availability (HA) uses Red Hat OpenShift Container Platform (RHOCP) operations to orchestrate failover and recovery deployment. When you plan your deployment, ensure that you review the considerations for different aspects of the environment, such as hardware assignments and network configuration. The following shared control plane services are required to implement HA: Galera RabbitMQ memcached These services run as pods, and they are managed by operators and monitored by RHOCP. You can use the RHOCP client command line interface ( oc ) to interact with the platform and retrieve information about the status of the RHOSO control plane services. For example, you can use the oc to complete the following actions: Monitor the startup and the state and availability of the RHOSO HA services. Investigate the pods of the RHOSO HA services. Investigate the operators of the RHOSO HA services. Describe the statefulset of the RHOSO HA services. Investigate the RHOSO HA services. Test the resilience of the RHOSO HA services.

Commands:
Chapter 12. ca This chapter describes the commands under the ca command. 12.1. ca get Retrieve a CA by providing its URI. Usage: Table 12.1. Positional arguments Value Summary URI The uri reference for the ca. Table 12.2. Command arguments Value Summary -h, --help Show this help message and exit Table 12.3. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 12.4. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 12.5. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 12.6. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show. 12.2. ca list List CAs. Usage: Table 12.7. Command arguments Value Summary -h, --help Show this help message and exit --limit LIMIT, -l LIMIT Specify the limit to the number of items to list per page (default: 10; maximum: 100) --offset OFFSET, -o OFFSET Specify the page offset (default: 0) --name NAME, -n NAME Specify the ca name (default: none) Table 12.8. Output formatter options Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated Table 12.9. CSV formatter options Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 12.10. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 12.11. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack ca get [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] URI
openstack ca list [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN] [--limit LIMIT] [--offset OFFSET] [--name NAME]
35.2. Configuring an iface for Software iSCSI As mentioned earlier, an iface configuration is required for each network object that will be used to bind a session. Before To create an iface configuration for software iSCSI, run the following command: This will create a new empty iface configuration with a specified iface_name . If an existing iface configuration already has the same iface_name , then it will be overwritten with a new, empty one. To configure a specific setting of an iface configuration, use the following command: Example 35.4. Set MAC address of iface0 For example, to set the MAC address ( hardware_address ) of iface0 to 00:0F:1F:92:6B:BF , run: Warning Do not use default or iser as iface names. Both strings are special values used by iscsiadm for backward compatibility. Any manually-created iface configurations named default or iser will disable backwards compatibility.

Commands:
iscsiadm -m iface -I iface_name --op=new
iscsiadm -m iface -I iface_name --op=update -n iface. setting -v hw_address
iscsiadm -m iface -I iface0 --op=update -n iface.hwaddress -v 00:0F:1F:92:6B:BF
Chapter 9. Viewing logs for a resource You can view the logs for various resources, such as builds, deployments, and pods by using the OpenShift CLI (oc) and the web console. Note Resource logs are a default feature that provides limited log viewing capability. To enhance your log retrieving and viewing experience, it is recommended that you install OpenShift Logging . The logging subsystem aggregates all the logs from your OpenShift Container Platform cluster, such as node system audit logs, application container logs, and infrastructure logs, into a dedicated log store. You can then query, discover, and visualize your log data through the Kibana interface . Resource logs do not access the logging subsystem log store. 9.1. Viewing resource logs You can view the log for various resources in the OpenShift CLI (oc) and web console. Logs read from the tail, or end, of the log. Prerequisites Access to the OpenShift CLI (oc). Procedure (UI) In the OpenShift Container Platform console, navigate to Workloads Pods or navigate to the pod through the resource you want to investigate. Note Some resources, such as builds, do not have pods to query directly. In such instances, you can locate the Logs link on the Details page for the resource. Select a project from the drop-down menu. Click the name of the pod you want to investigate. Click Logs . Procedure (CLI) View the log for a specific pod: USD oc logs -f <pod_name> -c <container_name> where: -f Optional: Specifies that the output follows what is being written into the logs. <pod_name> Specifies the name of the pod. <container_name> Optional: Specifies the name of a container. When a pod has more than one container, you must specify the container name. For example: USD oc logs ruby-58cd97df55-mww7r USD oc logs -f ruby-57f7f4855b-znl92 -c ruby The contents of log files are printed out. View the log for a specific resource: USD oc logs <object_type>/<resource_name> 1 1 Specifies the resource type and name. For example: USD oc logs deployment/ruby The contents of log files are printed out.

Commands:
oc logs -f <pod_name> -c <container_name>
oc logs ruby-58cd97df55-mww7r
oc logs -f ruby-57f7f4855b-znl92 -c ruby
oc logs <object_type>/<resource_name> 1
oc logs deployment/ruby
Chapter 3. Getting started with OpenShift Virtualization You can install and configure a basic OpenShift Virtualization environment to explore its features and functionality. Note Cluster configuration procedures require cluster-admin privileges. 3.1. Before you begin Prepare your cluster for OpenShift Virtualization. Review the storage requirements for cloning, snapshots, and live migration. Install the OpenShift Virtualization Operator . Install the virtctl tool . 3.1.1. Additional resources Using a CSI-enabled storage provider . Configuring local storage for virtual machines. About the Kubernetes NMState Operator . Specifying nodes for virtual machines . 3.2. Getting started Create a virtual machine: Quick create a virtual machine using the web console. Create and customize Windows boot sources . Install VirtIO drivers and the QEMU guest agent on the virtual machine. Connect to a virtual machine: Connect to a virtual machine Connect to the serial console or VNC console of a virtual machine using the web console. Connect to a virtual machine using SSH . Connect to a Windows virtual machine using RDP . Manage a virtual machine Stop, start, pause, and restart a virtual machine from the web console . Manage a virtual machine, expose a port, and connect to the serial console of a virtual machine from the command line with virtctl . 3.3. steps Connect VMs to secondary networks Connect a virtual machine to a Linux bridge network . Connect a virtual machine to an SR-IOV network . Monitor your OpenShift Virtualization environment Monitor resources, details, status, and top consumers on the Virtualization Overview page . View high-level information about your virtual machines on the Virtual Machines dashboard . View virtual machine logs . Automating deployments Automate Windows virtual machine deployments with sysprep . 3.3.1. Additional resources Creating virtual machine templates Live migration Virtual machine templates Configuring local storage Backup and restore

Commands:
Chapter 3. Defining Camel routes Camel Extensions for Quarkus supports the Java DSL language to define Camel Routes. 3.1. Java DSL Extending org.apache.camel.builder.RouteBuilder and using the fluent builder methods available there is the most common way of defining Camel Routes. Here is a simple example of a route using the timer component: import org.apache.camel.builder.RouteBuilder; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from("timer:foo?period=1000") .log("Hello World"); } } 3.1.1. Endpoint DSL Since Camel 3.0, you can use fluent builders also for defining Camel endpoints. The following is equivalent with the example: import org.apache.camel.builder.RouteBuilder; import static org.apache.camel.builder.endpoint.StaticEndpointBuilders.timer; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from(timer("foo").period(1000)) .log("Hello World"); } } Note Builder methods for all Camel components are available via camel-quarkus-core , but you still need to add the given component's extension as a dependency for the route to work properly. In case of the above example, it would be camel-quarkus-timer .

Commands:
import org.apache.camel.builder.RouteBuilder; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from("timer:foo?period=1000") .log("Hello World"); } }
import org.apache.camel.builder.RouteBuilder; import static org.apache.camel.builder.endpoint.StaticEndpointBuilders.timer; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from(timer("foo").period(1000)) .log("Hello World"); } }
Chapter 73. token This chapter describes the commands under the token command. 73.1. token issue Issue new token Usage: Table 73.1. Command arguments Value Summary -h, --help Show this help message and exit Table 73.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 73.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 73.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 73.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show. 73.2. token revoke Revoke existing token Usage: Table 73.6. Positional arguments Value Summary <token> Token to be deleted Table 73.7. Command arguments Value Summary -h, --help Show this help message and exit

Commands:
openstack token issue [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty]
openstack token revoke [-h] <token>
Chapter 2. Automating Network Intrusion Detection and Prevention Systems (IDPS) with Ansible You can use Ansible to automate your Intrusion Detection and Prevention System (IDPS). For the purpose of this guide, we use Snort as the IDPS. Use Ansible automation hub to consume content collections, such as tasks, roles, and modules to create automated workflows. 2.1. Requirements and prerequisites Before you begin automating your IDPS with Ansible, ensure that you have the proper installations and configurations necessary to successfully manage your IDPS. You have installed Ansible 2.9 or later. SSH connection and keys are configured. IDPS software (Snort) is installed and configured. You have access to the IDPS server (Snort) to enforce new policies. 2.1.1. Verifying your IDPS installation To verify that Snort has been configured successfully, call it via sudo and ask for the version: USD sudo snort --version ,,_ -*> Snort! <*- o" )~ Version 2.9.13 GRE (Build 15013) "" By Martin Roesch & The Snort Team: http://www.snort.org/contact#team Copyright (C) 2014-2019 Cisco and/or its affiliates.

Commands:
sudo snort --version ,,_ -*> Snort! <*- o" )~ Version 2.9.13 GRE (Build 15013) "" By Martin Roesch & The Snort Team: http://www.snort.org/contact#team Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved. Copyright (C) 1998-2013 Sourcefire, Inc., et al. Using libpcap version 1.5.3 Using PCRE version: 8.32 2012-11-30 Using ZLIB version: 1.2.7
sudo systemctl status snort ● snort.service - Snort service Loaded: loaded (/etc/systemd/system/snort.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-08-26 17:06:10 UTC; 1s ago Main PID: 17217 (snort) CGroup: /system.slice/snort.service └─17217 /usr/sbin/snort -u root -g root -c /etc/snort/snort.conf -i eth0 -p -R 1 --pid-path=/var/run/snort --no-interface-pidfile --nolock-pidfile [...]
ansible-galaxy install ansible_security.ids_rule
- name: Add Snort rule hosts: snort
- name: Add Snort rule hosts: snort become: true
- name: Add Snort rule hosts: snort become: true vars: ids_provider: snort
- name: Add Snort rule hosts: snort become: true vars: ids_provider: snort tasks: - name: Add snort password attack rule include_role: name: "ansible_security.ids_rule" vars: ids_rule: 'alert tcp any any -> any any (msg:"Attempted /etc/passwd Attack"; uricontent:"/etc/passwd"; classtype:attempted-user; sid:99000004; priority:1; rev:1;)' ids_rules_file: '/etc/snort/rules/local.rules' ids_rule_state: present
ansible-navigator run add_snort_rule.ym --mode stdout
Chapter 2. Bug fixes This section describes bugs fixed in OpenShift sandboxed containers 1.8. Pod VM image is now deleted when deleting KataConfig on Azure Previously, when you deleted the KataConfig custom resource, the pod VM image might not have been deleted. A workaround required using the Azure CLI to check the pod VM gallery for the image and delete it manually, if necessary. This issue is now resolved in the 1.8.1 release of OpenShift sandboxed containers. Jira:KATA-3462

Commands: