mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 26. Data objects Data objects are the building blocks for the rule assets that you create. Data objects are custom data types implemented as Java objects in specified packages of your project. For example, you might create a Person object with data fields Name , Address , and DateOfBirth to specify personal details for loan application rules. These custom data types determine what data your assets and your decision services are based on. 26.1. Creating data objects The following procedure is a generic overview of creating data objects. It is not specific to a particular business asset. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Data Object . Enter a unique Data Object name and select the Package where you want the data object to be available for other rule assets. Data objects with the same name cannot exist in the same package. In the specified DRL file, you can import a data object from any package. Importing data objects from other packages You can import an existing data object from another package directly into the asset designers like guided rules or guided decision table designers. Select the relevant rule asset within the project and in the asset designer, go to Data Objects New item to select the object to be imported. To make your data object persistable, select the Persistable checkbox. Persistable data objects are able to be stored in a database according to the JPA specification. The default JPA is Hibernate. Click Ok . In the data object designer, click add field to add a field to the object with the attributes Id , Label , and Type . Required attributes are marked with an asterisk (*). Id: Enter the unique ID of the field. Label: (Optional) Enter a label for the field. Type: Enter the data type of the field. List: (Optional) Select this check box to enable the field to hold multiple items for the specified type. Figure 26.1. Add data fields to a data object Click Create to add the new field, or click Create and continue to add the new field and continue adding other fields. Note To edit a field, select the field row and use the general properties on the right side of the screen.

Commands:
Chapter 2. Installation checklist Before you begin installing Red Hat Update Infrastructure (RHUI), refer to the following checklist to ensure that you have all the necessary components and information required for installation. Table 2.1. List of components required for installing RHUI Required Information Information Usage Resources and Notes Red Hat Credentials Red Hat credentials to manage subscription and access to Red Hat repositories. Red Hat Customer Portal Network and Firewall access Network and firewall requirements for the Red Hat Update Appliance (RHUA) and Content Delivery Server (CDS) nodes. It is possible for a CDS to have a client-facing host name that differs from the host name used for intra-Red Hat Update Infrastructure communication. If you are using client-facing host names, note each CDS's client-facing FQDN and the corresponding IP address. Proxy settings Proxy for access to the Red Hat content delivery network. Proxy settings for RHUI are set automatically during installation on the RHUA and CDS nodes. They are set in the /etc/rhsm/rhsm.conf files. Content Repository Size Storage space for the RPM packages required by Red Hat Update Infrastructure. See Preparing your Environment for Installation for specific storage requirements, or use the du command from the command line interface to determine its size. Also, all repositories are placed in the /var/lib/rhui/remote_share directory which the system creates by default during the installation process. However, if you need to create a new mount point for it, you can manually create this directory. Client Profiles RHUI content available to the client A client profile determines the RHUI content that is available to the client and the CDS from which the client downloads that content. Important Use a separate storage volume for the installation if you expect to store a large amount of data. In addition, each RHUI server (RHUA node or CDS node) requires a separate file system of the required size. It is important to use technologies such as LVM, SAN, or NAS storage that allow you to increase the size of the content repository if needed.

Commands:
Chapter 7. Scaling hyperconverged nodes To scale HCI nodes up or down, the same principles and methods for scaling Compute nodes or Red Hat Ceph Storage nodes apply. 7.1. Scaling up hyperconverged nodes in HCI environments To scale up hyperconverged nodes in HCI environments follow the same procedure for scaling up non-hyperconverged nodes. For more information, see Adding nodes to the overcloud . Note When you tag new nodes, remember to use the right flavor. 7.2. Scaling down hyperconverged nodes in HCI environments To scale down hyperconverged nodes in HCI environments you must rebalance the Ceph OSD services on the HCI node, migrate instances from the HCI nodes, and remove the Compute nodes from the overcloud. Procedure Disable and rebalance the Ceph OSD services on the HCI node. This step is necessary because director does not automatically rebalance the Red Hat Ceph Storage cluster when you remove HCI or Red Hat Ceph Storage nodes. For more information, see Scaling the Ceph Storage cluster in Deploying Red Hat Ceph Storage and Red Hat OpenStack Platform together with director for more information. Migrate the instances from the HCI nodes. For more information, see Migrating virtual machines between Compute nodes in the Configuring the Compute service for instance creation guide. Remove the Compute nodes from the overcloud. For more information, see Removing Compute nodes .

Commands:
4.4.5. Static Configuration without Resource Labeling Primarily used in MLS (multi-level security) or otherwise strictly controlled environments, static configuration without resource relabeling is possible. Static labels allow the administrator to select a specific label, including the MCS/MLS field, for a virtual machine. Administrators who run statically-labeled virtual machines are responsible for setting the correct label on the image files. The virtual machine will always be started with that label, and the sVirt system will never modify the label of a statically-labelled virtual machine's content. The following guest XML configuration demonstrates an example of this scenario:

Commands:
<seclabel type='static' model='selinux' relabel='no'> <label>system_u:system_r:svirt_custom_t:s0:c87,c520</label> </seclabel>
7.17. RHEA-2014:1523 - new packages: numatop New numatop packages are now available for Red Hat Enterprise Linux 6. NumaTOP is an observation tool for runtime memory locality characterization and analysis of processes and threads running on a Non-Uniform Memory Access (NUMA) system. NumaTOP can help the user characterize the NUMA behavior of processes and threads and locate NUMA-related performance problems. This enhancement update adds the numatop packages to Red Hat Enterprise Linux 6. (BZ# 1066152 ) All users who require numatop are advised to install these new packages.

Commands:
Chapter 10. Installation and Booting Using an HTTPS source for kickstart files is now supported With this update, it is now possible to specify HTTPS sources for kickstart files. (BZ# 1259880 ) Increased debug logging for NetworkManager The default log level of the NetworkManager utility has been increased to make debugging the installation process easier. (BZ#831777) Automatic network device configuration using 802.1q VLAN tags from the iBFT The installer configures network devices automatically, based on the iSCSI Boot Firmware Table (iBFT). Before this update, if 802.1q VLAN tagging was required for a device, the installer was not able to apply this information to the installed system. Now, if the 802.1q VLAN ID of a device is specified in the iBFT, the installer will use this information to automatically configure the device on the installed system. (BZ#831002)

Commands:
Chapter 12. Adding custom SSL/TLS certificates when Red Hat Quay is deployed on Kubernetes When deployed on Kubernetes, Red Hat Quay mounts in a secret as a volume to store config assets. Currently, this breaks the upload certificate function of the superuser panel. As a temporary workaround, base64 encoded certificates can be added to the secret after Red Hat Quay has been deployed. Use the following procedure to add custom SSL/TLS certificates when Red Hat Quay is deployed on Kubernetes. Prerequisites Red Hat Quay has been deployed. You have a custom ca.crt file. Procedure Base64 encode the contents of an SSL/TLS certificate by entering the following command: USD cat ca.crt | base64 -w 0 Example output ...c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= Enter the following kubectl command to edit the quay-enterprise-config-secret file: USD kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret Add an entry for the certificate and paste the full base64 encoded stringer under the entry. For example: custom-cert.crt: c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= Use the kubectl delete command to remove all Red Hat Quay pods. For example: USD kubectl delete pod quay-operator.v3.7.1-6f9d859bd-p5ftc quayregistry-clair-postgres-7487f5bd86-xnxpr quayregistry-quay-app-upgrade-xq2v6 quayregistry-quay-database-859d5445ff-cqthr quayregistry-quay-redis-84f888776f-hhgms Afterwards, the Red Hat Quay deployment automatically schedules replace pods with the new certificate data.

Commands:
cat ca.crt | base64 -w 0
...c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
custom-cert.crt: c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl delete pod quay-operator.v3.7.1-6f9d859bd-p5ftc quayregistry-clair-postgres-7487f5bd86-xnxpr quayregistry-quay-app-upgrade-xq2v6 quayregistry-quay-database-859d5445ff-cqthr quayregistry-quay-redis-84f888776f-hhgms
2.4. Limiting Access To the Piranha Configuration Tool The Piranha Configuration Tool prompts for a valid username and password combination. However, because all of the data passed to the Piranha Configuration Tool is in plain text, it is recommended that you restrict access only to trusted networks or to the local machine. The easiest way to restrict access is to use the Apache HTTP Server's built in access control mechanisms by editing /etc/sysconfig/ha/web/secure/.htaccess . After altering the file you do not have to restart the piranha-gui service because the server checks the .htaccess file each time it accesses the directory. By default, the access controls for this directory allow anyone to view the contents of the directory. Here is what the default access looks like: To limit access of the Piranha Configuration Tool to only the localhost change the .htaccess file to allow access from only the loopback device (127.0.0.1). For more information on the loopback device, see the chapter titled Network Scripts in the Red Hat Enterprise Linux Reference Guide . You can also allow specific hosts or subnets as seen in this example: In this example, only Web browsers from the machine with the IP address of 192.168.1.100 and machines on the 172.16.57/24 network can access the Piranha Configuration Tool . Warning Editing the Piranha Configuration Tool .htaccess file limits access to the configuration pages in the /etc/sysconfig/ha/web/secure/ directory but not to the login and the help pages in /etc/sysconfig/ha/web/ . To limit access to this directory, create a .htaccess file in the /etc/sysconfig/ha/web/ directory with order , allow , and deny lines identical to /etc/sysconfig/ha/web/secure/.htaccess .

Commands:
Order deny,allow Allow from all
Order deny,allow Deny from all Allow from 127.0.0.1
Order deny,allow Deny from all Allow from 192.168.1.100 Allow from 172.16.57
2.2. Creating a Cluster with the pcsd Web UI From the Manage Clusters page, you can create a new cluster, add an existing cluster to the Web UI, or remove a cluster from the Web UI. To create a cluster, click on Create New and enter the name of the cluster to create and the nodes that constitute the cluster. You can also configure advanced cluster options from this screen, including the transport mechanism for cluster communication, as described in Section 2.2.1, "Advanced Cluster Configuration Options" . After entering the cluster information, click Create Cluster . To add an existing cluster to the Web UI, click on Add Existing and enter the host name or IP address of a node in the cluster that you would like to manage with the Web UI. Once you have created or added a cluster, the cluster name is displayed on the Manage Cluster page. Selecting the cluster displays information about the cluster. Note When using the pcsd Web UI to configure a cluster, you can move your mouse over the text describing many of the options to see longer descriptions of those options as a tooltip display. 2.2.1. Advanced Cluster Configuration Options When creating a cluster, you can click on Advanced Options to configure additional cluster options, as shown in Figure 2.2, "Create Clusters page" . For information about the options displayed, move your mouse over the text for that option. Note that you can configure a cluster with Redundant Ring Protocol by specifying the interfaces for each node. The Redundant Ring Protocol settings display will change if you select UDP rather than the default value of UDPU as the transport mechanism for the cluster. Figure 2.2. Create Clusters page 2.2.2. Setting Cluster Management Permissions There are two sets of cluster permissions that you can grant to users: Permissions for managing the cluster with the Web UI, which also grants permissions to run pcs commands that connect to nodes over a network. This section describes how to configure those permissions with the Web UI. Permissions for local users to allow read-only or read-write access to the cluster configuration, using ACLs. Configuring ACLs with the Web UI is described in Section 2.3.4, "Configuring ACLs" . For further information on user permissions, see Section 4.5, "Setting User Permissions" . You can grant permission for specific users other than user hacluster to manage the cluster through the Web UI and to run pcs commands that connect to nodes over a network by adding them to the group haclient . You can then configure the permissions set for an individual member of the group haclient by clicking the Permissions tab on the Manage Clusters page and setting the permissions on the resulting screen. From this screen, you can also set permissions for groups. You can grant the following permissions: Read permissions, to view the cluster settings Write permissions, to modify cluster settings (except for permissions and ACLs) Grant permissions, to modify cluster permissions and ACLs Full permissions, for unrestricted access to a cluster, including adding and removing nodes, with access to keys and certificates

Commands:
Chapter 1. About networking Red Hat OpenShift Networking is an ecosystem of features, plugins and advanced networking capabilities that extend Kubernetes networking with the advanced networking-related features that your cluster needs to manage its network traffic for one or multiple hybrid clusters. This ecosystem of networking capabilities integrates ingress, egress, load balancing, high-performance throughput, security, inter- and intra-cluster traffic management and provides role-based observability tooling to reduce its natural complexities. The following list highlights some of the most commonly used Red Hat OpenShift Networking features available on your cluster: Primary cluster network provided by either of the following Container Network Interface (CNI) plugins: OVN-Kubernetes network plugin , the default plugin OpenShift SDN network plugin Certified 3rd-party alternative primary network plugins Cluster Network Operator for network plugin management Ingress Operator for TLS encrypted web traffic DNS Operator for name assignment MetalLB Operator for traffic load balancing on bare metal clusters IP failover support for high-availability Additional hardware network support through multiple CNI plugins, including for macvlan, ipvlan, and SR-IOV hardware networks IPv4, IPv6, and dual stack addressing Hybrid Linux-Windows host clusters for Windows-based workloads Red Hat OpenShift Service Mesh for discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring of services Single-node OpenShift Network Observability Operator for network debugging and insights Submariner for inter-cluster networking Red Hat Service Interconnect for layer 7 inter-cluster networking

Commands:
3.4.2. Attaching New Users to Groups The useradd command creates a User Private Group ( UPG , a group assigned to a user account to which that user exclusively belongs) whenever a new user is added to the system and names the group after the user. For example, when the account robert is created, an UPG named robert is created at the same time, the only member of which is the user robert . If you do not want to create a User Private Group for a user for whatever reason, execute the useradd command with the following option: Instead of automatically creating UPG or not creating it at all, you can specify the user's group membership with -g and -G options. While the -g option specifies the primary group membership, -G refers to supplementary groups into which the user is also included. The group names you specify must already exist on the system. Example 3.7. Adding a User to a Group The useradd -g "friends" -G "family,schoolmates" emily command creates the user emily but emily 's primary group is set to friends as specified by the -g option. emily is also a group member of the supplementary groups family and schoolmates . Provided the user already exists and you want to add them to certain supplementary group(s), use the usermod command with the -G option and a list of groups divided by commas, no spaces:

Commands:
useradd -N username
~]# useradd -g "friends" -G "family,schoolmates" emily
usermod -G group_1,group_2,group_3
5.6. Pinning a Virtual Machine to Multiple Hosts Virtual machines can be pinned to multiple hosts. Multi-host pinning allows a virtual machine to run on a specific subset of hosts within a cluster, instead of one specific host or all hosts in the cluster. The virtual machine cannot run on any other hosts in the cluster even if all of the specified hosts are unavailable. Multi-host pinning can be used to limit virtual machines to hosts with, for example, the same physical hardware configuration. If a host fails, a highly available virtual machine is automatically restarted on one of the other hosts to which the virtual machine is pinned. Pinning Virtual Machines to Multiple Hosts Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Host tab. Select the Specific Host(s) radio button under Start Running On and select two or more hosts from the list. Click the High Availability tab. Select the Highly Available check box. Select Low , Medium , or High from the Priority drop-down list. When migration is triggered, a queue is created in which the high priority virtual machines are migrated first. If a cluster is running low on resources, only the high priority virtual machines are migrated. Click OK .

Commands:
Chapter 13. Review feedback After you submit your results, the Red Hat certification team will analyze the content and award the credit for each passing test that is part of the test plan. As they verify each passing test, the team sets each test plan item to Confirmed , which you can see under the Results tab on the catalog. Figure 13.1. Certification Test Plan If any problem is found, the Red Hat certification team will update the certification request, which will automatically be emailed to the person who submitted the cert. You can also attempt to debug the results on the testing page. Note You can discuss results or problems from the Dialog tab in the certification.

Commands:
Chapter 1. About the Migration Toolkit for Virtualization You can use the Migration Toolkit for Virtualization (MTV) to migrate virtual machines from the following source providers to OpenShift Virtualization destination providers: VMware vSphere Red Hat Virtualization (RHV) OpenStack Open Virtual Appliances (OVAs) that were created by VMware vSphere Remote OpenShift Virtualization clusters Additional resources Performance recommendations for migrating from VMware vSphere to OpenShift Virtualization . Performance recommendations for migrating from Red Hat Virtualization to OpenShift Virtualization .

Commands:
Chapter 1. Requirements for a high availability automation hub Before deploying a high availability (HA) automation hub, ensure that you have a shared filesystem installed in your environment and that you have configured your network storage system, if applicable. 1.1. Required shared filesystem A high availability automation hub requires you to have a shared file system, such as NFS, already installed in your environment. Before you run the Red Hat Ansible Automation Platform installer, verify that you installed the /var/lib/pulp directory across your cluster as part of the shared file system installation. The Red Hat Ansible Automation Platform installer returns an error if /var/lib/pulp is not detected in one of your nodes, causing your high availability automation hub setup to fail. 1.2. Network Storage Installation Requirements If you intend to install a HA automation hub using a network storage on the automation hub nodes itself, you must first install and use firewalld to open the necessary ports as required by your shared storage system before running the Ansible Automation Platform installer. Install and configure firewalld by executing the following commands: Install the firewalld daemon: USD dnf install firewalld Add your network storage under <service> using the following command: USD firewall-cmd --permanent --add-service=<service> Note For a list of supported services, use the USD firewall-cmd --get-services command Reload to apply the configuration: USD firewall-cmd --reload

Commands:
dnf install firewalld
firewall-cmd --permanent --add-service=<service>
firewall-cmd --reload