mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Keystone integration configuration options You can integrate your configuration options into Keystone. See below for a detailed description of the available Keystone integration configuration options: Important After updating the Ceph configuration file, you must copy the new Ceph configuration file to all Ceph nodes in the storage cluster. rgw_s3_auth_use_keystone Description If set to true , the Ceph Object Gateway will authenticate users using Keystone. Type Boolean Default false nss_db_path Description The path to the NSS database. Type String Default "" rgw_keystone_url Description The URL for the administrative RESTful API on the Keystone server. Type String Default "" rgw_keystone_admin_token Description The token or shared secret that is configured internally in Keystone for administrative requests. Type String Default "" rgw_keystone_admin_user Description The keystone admin user name. Type String Default "" rgw_keystone_admin_password Description The keystone admin user password. Type String Default "" rgw_keystone_admin_tenant Description The Keystone admin user tenant for keystone v2.0. Type String Default "" rgw_keystone_admin_project Description The Keystone admin user project for keystone v3. Type String Default "" rgw_keystone_admin_domain Description The Keystone admin user domain. Type String Default "" rgw_keystone_api_version Description The version of the Keystone API to use. Valid options are 2 or 3 . Type Integer Default 2 rgw_keystone_accepted_roles Description The roles required to serve requests. Type String Default "Member, admin" rgw_keystone_accepted_admin_roles Description The list of roles allowing a user to gain administrative privileges. Type String Default "" rgw_keystone_token_cache_size Description The maximum number of entries in the Keystone token cache. Type Integer Default 10000 rgw_keystone_revocation_interval Description The number seconds between tokens revocation check. Type Integer Default 15 * 60 rgw_keystone_verify_ssl Description If true Ceph will try to verify Keystone's SSL certificate. Type Boolean Default true rgw_keystone_implicit_tenants Description Create new users in their own tenants of the same name. Set this to true or false under most circumstances. For compatibility with versions of Red Hat Ceph Storage, it is also possible to set this to s3 or swift . This has the effect of splitting the identity space such that only the indicated protocol will use implicit tenants. Some older versions of Red Hat Ceph Storage only supported implicit tenants with Swift. Type String Default false

Commands:
1.2. Overview of DM-Multipath DM-Multipath can be used to provide: Redundancy DM-Multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the cable, switch, or controller) fails, DM-Multipath switches to an alternate path. Improved Performance DM-Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, DM-Multipath can detect loading on the I/O paths and dynamically re-balance the load. Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" shows an active/passive configuration with two I/O paths from the server to a RAID device. There are 2 HBAs on the server, 2 SAN switches, and 2 RAID controllers. Figure 1.1. Active/Passive Multipath Configuration with One RAID Device In this configuration, there is one I/O path that goes through hba1, SAN1, and controller 1 and a second I/O path that goes through hba2, SAN2, and controller2. There are many points of possible failure in this configuration: HBA failure FC cable failure SAN switch failure Array controller port failure With DM-Multipath configured, a failure at any of these points will cause DM-Multipath to switch to the alternate I/O path. Figure 1.2, "Active/Passive Multipath Configuration with Two RAID Devices" shows a more complex active/passive configuration with 2 HBAs on the server, 2 SAN switches, and 2 RAID devices with 2 RAID controllers each. Figure 1.2. Active/Passive Multipath Configuration with Two RAID Devices In the example shown in Figure 1.2, "Active/Passive Multipath Configuration with Two RAID Devices" , there are two I/O paths to each RAID device (just as there are in the example shown in Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" ). With DM-Multipath configured, a failure at any of the points of the I/O path to either of the RAID devices will cause DM-Multipath to switch to the alternate I/O path for that device. Figure 1.3, "Active/Active Multipath Configuration with One RAID Device" shows an active/active configuration with 2 HBAs on the server, 1 SAN switch, and 2 RAID controllers. There are four I/O paths from the server to a storage device: hba1 to controller1 hba1 to controller2 hba2 to controller1 hba2 to controller2 In this configuration, I/O can be spread among those four paths. Figure 1.3. Active/Active Multipath Configuration with One RAID Device

Commands:
Chapter 6. Generating a catalog 6.1. Overview By default, every Kaoto release includes the latest Camel version available at the moment of the build, nevertheless, generating a different set of catalogs is possible. 6.2. Catalog generator CLI Kaoto provides a Camel catalog generator CLI to ease this process, it supports the following runtimes: Main Quarkus Springboot 6.2.1. Using Camel catalog Clone the Kaoto project Navigate to the packages/catalog-generator directory Install the project dependencies: ./mvnw install Run the project with the following command: ./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.6.0 -m 4.6.0 -n "My Catalog" This will generate a Catalog library containing: Camel Main 4.6.0 Camel Kamelets 4.6.0 The resulting files will be in the packages/catalog-generator/dist/camel-catalog folder Providing that folder through a http server will make it available for using it in Kaoto 6.2.2. Creating a Catalog library with different runtimes In order to add multiple runtimes to the Catalog library, we can provide each runtime with its version using the following flags: -m,--main <version> Camel Main version. If not specified, it will use the generator installed version -q,--quarkus <version> Camel Extensions for Quarkus version -s,--springboot <version> Camel SpringBoot version For instance, running the following command will create a Catalog library with Camel Main 4.6.0 and Camel extensions for Quarkus 3.8.0: ./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.6.0 -m 4.6.0 -q 3.8.0 -n "My Catalog" For a different Kamelets catalog version, the --kamelets or -k flag can be specified. ./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.5.0 -m 4.6.0 -n "My Catalog" 6.2.3. Instructing Kaoto to use a specific Catalog library In VSCode, go to the settings page and look for "Kaoto" In the TextField , provide the URL of the index.json file that specifies the location of the subsequent catalogs, for instance, the public Kaoto catalog can be used: Restart Kaoto for the changes to have effect

Commands:
./mvnw install
./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.6.0 -m 4.6.0 -n "My Catalog"
-m,--main <version> Camel Main version. If not specified, it will use the generator installed version -q,--quarkus <version> Camel Extensions for Quarkus version -s,--springboot <version> Camel SpringBoot version
./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.6.0 -m 4.6.0 -q 3.8.0 -n "My Catalog"
./mvnw package; java -jar ./target/catalog-generator-0.0.1-SNAPSHOT.jar -o ./dist/camel-catalog -k 4.5.0 -m 4.6.0 -n "My Catalog"
Chapter 6. Mirroring data for hybrid and Multicloud buckets You can use the simplified process of the Multicloud Object Gateway (MCG) to span data across cloud providers and clusters. Before you create a bucket class that reflects the data management policy and mirroring, you must add a backing storage that can be used by the MCG. For information, see Chapter 4, Chapter 3, Adding storage resources for hybrid or Multicloud . You can set up mirroring data by using the OpenShift UI, YAML or MCG command-line interface. See the following sections: Section 6.1, "Creating bucket classes to mirror data using the MCG command-line-interface" Section 6.2, "Creating bucket classes to mirror data using a YAML" 6.1. Creating bucket classes to mirror data using the MCG command-line-interface Prerequisites Ensure to download Multicloud Object Gateway (MCG) command-line interface. Procedure From the Multicloud Object Gateway (MCG) command-line interface, run the following command to create a bucket class with a mirroring policy: Set the newly created bucket class to a new bucket claim to generate a new bucket that will be mirrored between two locations: 6.2. Creating bucket classes to mirror data using a YAML Apply the following YAML. This YAML is a hybrid example that mirrors data between local Ceph storage and AWS: Add the following lines to your standard Object Bucket Claim (OBC): For more information about OBCs, see Chapter 9, Object Bucket Claim .

Commands:
noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
noobaa obc create mirrored-bucket --bucketclass=mirror-to-aws
apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <bucket-class-name> namespace: openshift-storage spec: placementPolicy: tiers: - backingStores: - <backing-store-1> - <backing-store-2> placement: Mirror
additionalConfig: bucketclass: mirror-to-aws
1.2. Security Controls Computer security is often divided into three distinct master categories, commonly referred to as controls : Physical Technical Administrative These three broad categories define the main objectives of proper security implementation. Within these controls are sub-categories that further detail the controls and how to implement them. 1.2.1. Physical Controls Physical control is the implementation of security measures in a defined structure used to deter or prevent unauthorized access to sensitive material. Examples of physical controls are: Closed-circuit surveillance cameras Motion or thermal alarm systems Security guards Picture IDs Locked and dead-bolted steel doors Biometrics (includes fingerprint, voice, face, iris, handwriting, and other automated methods used to recognize individuals) 1.2.2. Technical Controls Technical controls use technology as a basis for controlling the access and usage of sensitive data throughout a physical structure and over a network. Technical controls are far-reaching in scope and encompass such technologies as: Encryption Smart cards Network authentication Access control lists (ACLs) File integrity auditing software 1.2.3. Administrative Controls Administrative controls define the human factors of security. They involve all levels of personnel within an organization and determine which users have access to what resources and information by such means as: Training and awareness Disaster preparedness and recovery plans Personnel recruitment and separation strategies Personnel registration and accounting

Commands:
16.4. Configuring a Domain Blacklist in Squid Frequently, administrators want to block access to specific domains. This section describes how to configure a domain blacklist in Squid. Prerequisites Squid is configured, and users can use the proxy. Procedure Edit the /etc/squid/squid.conf file and add the following settings: Important Add these entries before the first http_access allow statement that allows access to users or clients. Create the /etc/squid/domain_blacklist.txt file and add the domains you want to block. For example, to block access to example.com including subdomains and to block example.net , add: Important If you referred to the /etc/squid/domain_blacklist.txt file in the squid configuration, this file must not be empty. If the file is empty, Squid fails to start. Restart the squid service:

Commands:
acl domain_blacklist dstdomain "/etc/squid/domain_blacklist.txt" http_access deny all domain_blacklist
.example.com example.net
systemctl restart squid
17.16. Setting vLAN Tags virtual local area network (vLAN) tags are added using the virsh net-edit command. This tag can also be used with PCI device assignment with SR-IOV devices. For more information, see Section 16.2.3, "Configuring PCI Assignment with SR-IOV Devices" . <network> <name>ovs-net</name> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> <vlan trunk='yes'> <tag id='42' nativeMode='untagged'/> <tag id='47'/> </vlan> <portgroup name='dontpanic'> <vlan> <tag id='42'/> </vlan> </portgroup> </network> Figure 17.30. vSetting VLAN tag (on supported network types only) If (and only if) the network type supports vlan tagging transparent to the guest, an optional <vlan> element can specify one or more vlan tags to apply to the traffic of all guests using this network. (openvswitch and type='hostdev' SR-IOV networks do support transparent vlan tagging of guest traffic; everything else, including standard linux bridges and libvirt's own virtual networks, do not support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches provide their own way (outside of libvirt) to tag guest traffic onto specific vlans.) As expected, the tag attribute specifies which vlan tag to use. If a network has more than one <vlan> element defined, it is assumed that the user wants to do VLAN trunking using all the specified tags. If vlan trunking with a single tag is required, the optional attribute trunk='yes' can be added to the vlan element. For network connections using openvswitch it is possible to configure the 'native-tagged' and 'native-untagged' vlan modes. This uses the optional nativeMode attribute on the <tag> element: nativeMode may be set to 'tagged' or 'untagged'. The id attribute of the element sets the native vlan. <vlan> elements can also be specified in a <portgroup> element, as well as directly in a domain's <interface> element. If a vlan tag is specified in multiple locations, the setting in <interface> takes precedence, followed by the setting in the <portgroup> selected by the interface config. The <vlan> in <network> will be selected only if none is given in <portgroup> or <interface> .

Commands:
<network> <name>ovs-net</name> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> <vlan trunk='yes'> <tag id='42' nativeMode='untagged'/> <tag id='47'/> </vlan> <portgroup name='dontpanic'> <vlan> <tag id='42'/> </vlan> </portgroup> </network>
4.3. Power Management The Red Hat Virtualization Manager is capable of rebooting hosts that have entered a non-operational or non-responsive state, as well as preparing to power off under-utilized hosts to save power. This functionality depends on a properly configured power management device. The Red Hat Virtualization environment supports the following power management devices: American Power Conversion ( apc ) IBM Bladecenter ( Bladecenter ) Cisco Unified Computing System ( cisco_ucs ) Dell Remote Access Card 5 ( drac5 ) Dell Remote Access Card 7 ( drac7 ) Electronic Power Switch ( eps ) HP BladeSystem ( hpblade ) Integrated Lights Out ( ilo , ilo2 , ilo3 , ilo4 ) Intelligent Platform Management Interface ( ipmilan ) Remote Supervisor Adapter ( rsa ) Fujitsu-Siemens RSB ( rsb ) Western Telematic, Inc ( wti ) Red Hat recommends that HP servers use ilo3 or ilo4 , Dell servers use drac5 or Integrated Dell Remote Access Controllers ( idrac ), and IBM servers use ipmilan . Integrated Management Module (IMM) uses the IPMI protocol, and therefore IMM users can use ipmilan . Note APC 5.x power management devices are not supported by the apc fence agent. Use the apc_snmp fence agent instead. In order to communicate with the listed power management devices, the Red Hat Virtualization Manager makes use of fence agents. The Red Hat Virtualization Manager allows administrators to configure a fence agent for the power management device in their environment with parameters the device will accept and respond to. Basic configuration options can be configured using the graphical user interface. Special configuration options can also be entered, and are passed un-parsed to the fence device. Special configuration options are specific to a given fence device, while basic configuration options are for functionalities provided by all supported power management devices. The basic functionalities provided by all power management devices are: Status : check the status of the host. Start : power on the host. Stop : power down the host. Restart : restart the host. Actually implemented as stop, wait, status, start, wait, status. Best practice is to test the power management configuration once when initially configuring it, and occasionally after that to ensure continued functionality. Resilience is provided by properly configured power management devices in all of the hosts in an environment. Fencing agents allow the Red Hat Virtualization Manager to communicate with host power management devices to bypass the operating system on a problem host, and isolate the host from the rest of its environment by rebooting it. The Manager can then reassign the SPM role, if it was held by the problem host, and safely restart any highly available virtual machines on other hosts.

Commands:
2.3. LVM Architecture Overview For the Red Hat Enterprise Linux 4 release of the Linux operating system, the original LVM1 logical volume manager was replaced by LVM2, which has a more generic kernel framework than LVM1. LVM2 provides the following improvements over LVM1: flexible capacity more efficient metadata storage better recovery format new ASCII metadata format atomic changes to metadata redundant copies of metadata LVM2 is backwards compatible with LVM1, with the exception of snapshot and cluster support. You can convert a volume group from LVM1 format to LVM2 format with the vgconvert command. For information on converting LVM metadata format, see the vgconvert (8) man page. The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. This device is initialized as an LVM physical volume (PV). To create an LVM logical volume, the physical volumes are combined into a volume group (VG). This creates a pool of disk space out of which LVM logical volumes (LVs) can be allocated. This process is analogous to the way in which disks are divided into partitions. A logical volume is used by file systems and applications (such as databases). Figure 2.1, "LVM Logical Volume Components" shows the components of a simple LVM logical volume: Figure 2.1. LVM Logical Volume Components For detailed information on the components of an LVM logical volume, see Chapter 3, LVM Components .

Commands:
7.15. bash 7.15.1. RHBA-2015:1277 - bash bug fix update Updated bash packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The bash packages provide the Bash (Bourne-again shell) shell, which is the default shell for Red Hat Enterprise Linux. Bug Fixes BZ# 1148507 Prior to this update, Bash refused to import previously exported functions whose names contained a hyphen. As a consequence, scripts that used such functions did not work properly, and Bash printed the following error message: bash: error importing function definition for `BASH_FUNC_function-name' With this update, Bash accepts hyphens in the names of imported functions. BZ# 1150544 , BZ# 1155455 Previously, Bash incorrectly parsed function definitions containing a here-document that ended with the end-of-file or end-of-string character. Consequently, Bash accessed an invalid memory segment when the parsed function was copied, and Bash terminated with a segmentation fault. This problem has been fixed. As a result, Bash no longer crashes when the aforementioned function definitions are used. BZ# 1119587 The section in the Bash man page describing the ulimit command did not contain the fact that 512-byte blocks are used for the "-c" and "-f" options in POSIX mode. This information has now been added. Users of bash are advised to upgrade to these updated packages, which fix these bugs.

Commands:
7.229. slf4j 7.229.1. RHBA-2012:1239 - slf4j bug fix update Updated slf4j packages that fix one bug are now available for Red Hat Enterprise Linux 6. The Simple Logging Facade (SLF4J) for Java serves as a simple facade for various logging APIs allowing the end-user to plug in the desired implementation at deployment time. Bug Fix BZ# 831933 , BZ# 828644 The slf4j packages contained a non-functional dummy API implementation which was not supposed to be used. This dummy implementation was always selected instead of other implementations and UnsupportedOperationException was thrown. The dummy API implementation has been removed, so that user-supplied implementation is now always chosen, and slf4j works as expected. All users of slf4j are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 9. Importing and deploying business assets projects in Business Central You can import a business assets project that is part of a Red Hat Decision Manager business application into Business Central and then deploy that project to a business application. Prerequisites You have a business application project running in development mode. Red Hat Decision Manager Business Central is installed. Procedure Navigate to the <BUSINESS-APPLICATION>/<BUSINESS-APPLICATION>-kjar folder, where <BUSINESS-APPLICATION> is the name of your Spring Boot project. Execute the following following commands to initialize the Git repository for your project: Log in to Business Central and go to Menu Design Projects . Select Import Project and enter the following URL: Click Import and confirm the project to be imported. After the business assets project is imported into Business Central, open the project and click Add Assets to add assets such as rules and decision tables to your business assets project. Click Deploy on your project page to deploy your project to a running business application. Note You can also select the Build & Install option to build the project and publish the KJAR file to the configured Maven repository without deploying to a KIE Server. In a development environment, you can click Deploy to deploy the built KJAR file to a KIE Server without stopping any running instances (if applicable), or click Redeploy to deploy the built KJAR file and replace all instances. The time you deploy or redeploy the built KJAR, the deployment unit (KIE container) is automatically updated in the same target KIE Server. In a production environment, the Redeploy option is disabled and you can click Deploy only to deploy the built KJAR file to a new deployment unit (KIE container) on a KIE Server. To configure the KIE Server environment mode, set the org.kie.server.mode system property to org.kie.server.mode=development or org.kie.server.mode=production . To configure the deployment behavior for a corresponding project in Business Central, go to project Settings General Settings Version and toggle the Development Mode option. By default, KIE Server and all new projects in Business Central are in development mode. You cannot deploy a project with Development Mode turned on or with a manually added SNAPSHOT version suffix to a KIE Server that is in production mode. To review project deployment details, click View deployment details in the deployment banner at the top of the screen or in the Deploy drop-down menu. This option directs you to the Menu Deploy Execution Servers page.

Commands:
git init git add -A git commit -m "Initial project structure"
file:///<business-application-path>/<business-application-name>-kjar