mtpti5iD/redhat-docs_dataset huggingface dataset:
7.2. Using iptables The first step in using iptables is to start the iptables service. This can be done with the command: Warning The ip6tables services should be turned off to use the iptables service with the following commands: To make iptables start by default whenever the system is booted, you must change runlevel status on the service using chkconfig . The syntax of iptables is separated into tiers. The main tier is the chain . A chain specifies the state at which a packet is manipulated. The usage is as follows: The -A option appends a rule at the end of an existing ruleset. The chain is the name of the chain for a rule. The three built-in chains of iptables (that is, the chains that affect every packet which traverses a network) are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted. The -j target option specifies the location in the iptables ruleset where this particular rule should jump . Some built in targets are ACCEPT, DROP, and REJECT. New chains (also called user-defined chains) can be created by using the -N option. Creating a new chain is useful for customizing granular or elaborate rules. 7.2.1. Basic Firewall Policies Establishing basic firewall policies creates a foundation for building more detailed, user-defined rules. iptables uses policies ( -P ) to create default rules. Security-minded administrators usually elect to drop all packets as a policy and only allow specific packets on a case-by-case basis. The following rules block all incoming and outgoing packets on a network gateway: Additionally, it is recommended that any forwarded packets - network traffic that is to be routed from the firewall to its destination node - be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule: After setting the policy chains, you can create new rules for your particular network and security requirements. The following sections outline some rules you may implement in the course of building your iptables firewall.

Commands:
service iptables start
service ip6tables stop chkconfig ip6tables off
chkconfig --level 345 iptables on
iptables -A chain -j target
iptables -P INPUT DROP iptables -P OUTPUT DROP
iptables -P FORWARD DROP
3.3. Deployment cpuspeed component, BZ# 626893 Some HP Proliant servers may report incorrect CPU frequency values in /proc/cpuinfo or /sys/device/system/cpu/*/cpufreq . This is due to the firmware manipulating the CPU frequency without providing any notification to the operating system. To avoid this ensure that the HP Power Regulator option in the BIOS is set to OS Control . An alternative available on more recent systems is to set Collaborative Power Control to Enabled . releng component, BZ# 644778 Some packages in the Optional repositories on RHN have multilib file conflicts. Consequently, these packages cannot have both the primary architecture (for example, x86_64) and secondary architecture (for example, i686) copies of the package installed on the same machine simultaneously. To work around this issue, install only one copy of the conflicting package. grub component, BZ# 695951 On certain UEFI-based systems, you may need to type BOOTX64 rather than bootx64 to boot the installer due to case sensitivity issues. grub component, BZ# 698708 When rebuilding the grub package on the x86_64 architecture, the glibc-static.i686 package must be used. Using the glibc-static.x86_64 package will not meet the build requirements.

Commands:
A.12. KVM Networking Performance By default, KVM virtual machines are assigned a virtual Realtek 8139 (rtl8139) NIC (network interface controller). The rtl8139 virtualized NIC works fine in most environments,but this device can suffer from performance degradation problems on some networks, such as a 10 Gigabit Ethernet. To improve performance, you can switch to the paravirtualized network driver. Note Note that the virtualized Intel PRO/1000 ( e1000 ) driver is also supported as an emulated driver choice. To use the e1000 driver, replace virtio in the procedure below with e1000 . For the best performance it is recommended to use the virtio driver. Procedure A.6. Switching to the virtio driver Shut down the guest operating system. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name): The virsh edit command uses the USDEDITOR shell variable to determine which editor to use. Find the network interface section of the configuration. This section resembles the snippet below: Change the type attribute of the model element from 'rtl8139' to 'virtio' . This will change the driver from the rtl8139 driver to the virtio driver. Save the changes and exit the text editor Restart the guest operating system. Creating New Guests Using Other Network Drivers Alternatively, new guests can be created with a different network driver. This may be required if you are having difficulty installing guests over a network connection. This method requires you to have at least one guest already created (possibly installed from CD or DVD) to use as a template. Create an XML template from an existing guest (in this example, named Guest1 ): Copy and edit the XML file and update the unique fields: virtual machine name, UUID, disk image, MAC address, and any other unique parameters. Note that you can delete the UUID and MAC address lines and virsh will generate a UUID and MAC address. Add the model line in the network interface section: Create the new virtual machine:

Commands:
virsh edit GUEST
<interface type='network'> [output truncated] <model type='rtl8139' /> </interface>
<interface type='network'> [output truncated] <model type= 'virtio' /> </interface>
virsh dumpxml Guest1 > /tmp/ guest-template .xml
cp /tmp/ guest-template .xml /tmp/ new-guest .xml vi /tmp/ new-guest .xml
<interface type='network'> [output truncated] <model type='virtio' /> </interface>
virsh define /tmp/new-guest.xml virsh start new-guest
7. Authentication 7.1. Technology Previews certmonger The certmonger service aims to manage certificates on behalf of services running on client systems. It warns administrators when a certificate which it has been asked to watch is nearing the end of its validity period, and can be told to attempt to automatically obtain a new certificate when this happens. It supports certificates and private keys stored in either PEM or NSS database formats. It can interact with CAs running either IPA or certmaster, and is intended to be extensible to support other implementations. ipa-client IPA is an integrated solution to provide centrally managed Identity (machine,user, virtual machines, groups, authentication credentials). This package includes client-side functionality that when combined with a supported server can be used to provide features like kerberized sshd.

Commands:
5.356. wordnet 5.356.1. RHBA-2012:0932 - wordnet bug fix update Updated wordnet packages that fix one bug are now available for Red Hat Enterprise Linux 6. WordNet provides a set of utilities and a lexical database to manage English words in sets of synonyms (synsets). Wordnet uses these synsets to generate a combination of dictionary and thesaurus and to support automatic text analysis. Bug Fix BZ# 658043 Prior to this update, WordNet encountered file conflicts when trying to install wordnet packages for 32-bit and 64-bit architectures on the same host. As a consequence, installing the second package failed. This update removes the conflicting auxiliary files from the packages. Now, WordNet is multi-architecture safe. All users of wordnet are advised to upgrade to these updated packages, which fix this bug.

Commands:
2.5. Virtual Disk Storage Allocation Policies Preallocated Storage All of the storage required for a virtual disk is allocated prior to virtual machine creation. If a 20 GB disk image is created for a virtual machine, the disk image uses 20 GB of storage domain capacity. Preallocated disk images cannot be enlarged. Preallocating storage can mean faster write times because no storage allocation takes place during runtime, at the cost of flexibility. Allocating storage this way reduces the capacity of the Red Hat Virtualization Manager to overcommit storage. Preallocated storage is recommended for virtual machines used for high intensity I/O tasks with less tolerance for latency in storage. Generally, server virtual machines fit this description. Note If thin provisioning functionality provided by your storage back-end is being used, preallocated storage should still be selected from the Administration Portal when provisioning storage for virtual machines. Sparsely Allocated Storage The upper size limit for a virtual disk is set at virtual machine creation time. Initially, the disk image does not use any storage domain capacity. Usage grows as the virtual machine writes data to disk, until the upper limit is reached. Capacity is not returned to the storage domain when data in the disk image is removed. Sparsely allocated storage is appropriate for virtual machines with low or medium intensity I/O tasks with some tolerance for latency in storage. Generally, desktop virtual machines fit this description. Note If thin provisioning functionality is provided by your storage back-end, it should be used as the preferred implementation of thin provisioning. Storage should be provisioned from the graphical user interface as preallocated, leaving thin provisioning to the back-end solution.

Commands:
4.130. libcgroup 4.130.1. RHBA-2011:1225 - libcgroup bug fix update An updated libcgroup package that fixes one bug is now available for Red Hat Enterprise Linux 6. The libcgroup package provides tools and libraries to control and monitor control groups. Bug Fix BZ# 715413 Prior to this update, when installing the libcgroup package, a new group "cgred" was erroneously created as a user group (starting with GID 500) and not as a system group (with GID lower than 500). As a result, newly created users could have had UID different to GID. With this update, the "cgred" group is now created correctly as the system group with GID lower than 500. This update does not change GID of the "cgred" group if the group already exists on the system. All users are advised to upgrade to this updated libcgroup package, which fixes this bug.

Commands:
Chapter 23. Storage I/O Alignment and Size Recent enhancements to the SCSI and ATA standards allow storage devices to indicate their preferred (and in some cases, required) I/O alignment and I/O size . This information is particularly useful with newer disk drives that increase the physical sector size from 512 bytes to 4k bytes. This information may also be beneficial for RAID devices, where the chunk size and stripe size may impact performance. The Linux I/O stack has been enhanced to process vendor-provided I/O alignment and I/O size information, allowing storage management tools ( parted , lvm , mkfs. * , and the like) to optimize data placement and access. If a legacy device does not export I/O alignment and size data, then storage management tools in Red Hat Enterprise Linux 7 will conservatively align I/O on a 4k (or larger power of 2) boundary. This will ensure that 4k-sector devices operate correctly even if they do not indicate any required/preferred I/O alignment and size. For information on determining the information that the operating system obtained from the device, see the Section 23.2, "Userspace Access" . This data is subsequently used by the storage management tools to determine data placement. The IO scheduler has changed for Red Hat Enterprise Linux 7. Default IO Scheduler is now Deadline , except for SATA drives. CFQ is the default IO scheduler for SATA drives. For faster storage, Deadline outperforms CFQ and when it is used there is a performance increase without the need of special tuning. If default is not right for some disks (for example, SAS rotational disks), then change the IO scheduler to CFQ. This instance will depend on the workload. 23.1. Parameters for Storage Access The operating system uses the following information to determine I/O alignment and size: physical_block_size Smallest internal unit on which the device can operate logical_block_size Used externally to address a location on the device alignment_offset The number of bytes that the beginning of the Linux block device (partition/MD/LVM device) is offset from the underlying physical alignment minimum_io_size The device's preferred minimum unit for random I/O optimal_io_size The device's preferred unit for streaming I/O For example, certain 4K sector devices may use a 4K physical_block_size internally but expose a more granular 512-byte logical_block_size to Linux. This discrepancy introduces potential for misaligned I/O. To address this, the Red Hat Enterprise Linux 7 I/O stack will attempt to start all data areas on a naturally-aligned boundary ( physical_block_size ) by making sure it accounts for any alignment_offset if the beginning of the block device is offset from the underlying physical alignment. Storage vendors can also supply I/O hints about the preferred minimum unit for random I/O ( minimum_io_size ) and streaming I/O ( optimal_io_size ) of a device. For example, minimum_io_size and optimal_io_size may correspond to a RAID device's chunk size and stripe size respectively.

Commands:
4.9. Attaching and Configuring the Data Disk From the Google Developers Console, click Compute > Compute Engine > VM instances > rhgs-primary-n01 > Attach > rhgs-primary-n01-data . Choose the mode as Read/write . Connect to the rhgs-primary-n01 instance via SSH, and configure the data disk: Confirm the data disk is visible as /dev/sdb: Configure LVM, format the filesystem, and mount the data disk: The script below can be used to complete this process per documented recommendations. Warning This script assumes a large enough block device to accommodate the maximum supported metadata LV size of 16 GB for LVM thin provisioning needed for snapshots. You should understand what each step in the script is doing before using it.

Commands:
ssh username@instance_external_ip
fdisk -l /dev/sdb Disk /dev/sdb: 10984.4 GB, 10984378859520 bytes 255 heads, 63 sectors/track, 1335441 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000
#!/bin/bash pvcreate /dev/sdb vgcreate rhgs_vg /dev/sdb Create metadata LV with the maximum supported size of 16GB lvcreate -L 16777216K --name rhgs_pool_meta rhgs_vg Create data LV with the remainder of the VG space lvcreate -l 100%FREE --name rhgs_pool rhgs_vg The lvconvert command below required 4096 free extents, so reduce the LV lvreduce -f -l 4096 /dev/rhgs_vg/rhgs_pool Convert our LVs to a thin pool lvconvert --yes --thinpool rhgs_vg/rhgs_pool --poolmetadata rhgs_vg/rhgs_pool_meta Disable zeroing of thin pool chunks for performance boost lvchange --zero n rhgs_vg/rhgs_pool The -V flag for lvcreate does not allow a '100%FREE' option like -l does. So we'll get the size of rhgs_pool from lvs for maximum efficiency LVSIZE=USD(lvs --units g | grep rhgs_pool | awk '{print USD4}' | awk -F. '{print USD1}') Create the thin LV for the bricks lvcreate -V USD{LVSIZE}G -T rhgs_vg/rhgs_pool -n rhgs_lv Create the XFS filesystem with 512B inode size and 8KB directory block size This step may take a while mkfs.xfs -f -i size=512 -n size=8192 -L rhgs_lv /dev/rhgs_vg/rhgs_lv Create mountpoint and fstab entry mkdir -p /rhgs/bricks echo "LABEL=rhgs_lv /rhgs/bricks xfs rw,inode64,noatime,nouuid 1 2" >> /etc/fstab mount /rhgs/bricks df -h /rhgs/bricks
Part III. The Red Hat build of OptaPlanner solver Solving a planning problem with OptaPlanner consists of the following steps: Model your planning problem as a class annotated with the @PlanningSolution annotation (for example, the NQueens class). Configure a Solver (for example a First Fit and Tabu Search solver for any NQueens instance). Load a problem data set from your data layer (for example a Four Queens instance). That is the planning problem. Solve it with Solver.solve(problem) , which returns the best solution found.

Commands:
12.6. Override Execution Properties You can override execution properties for any translator in the vdb.xml file: The above XML fragment is overriding the oracle translator and altering the behavior of RequiresCriteria property setting it to true. Note that the modified translator is only available in the scope of this VDB.

Commands:
<translator type="oracle-override" name="oracle"> <property name="RequiresCriteria" value="true"/> </translator>
Chapter 24. Verifying system certificates using IdM Healthcheck Learn more about identifying issues with system certificates in Identity Management (IdM) by using the Healthcheck tool. For details, see Healthcheck in IdM . Prerequisites The Healthcheck tool is only available on RHEL 8.1 or newer. 24.1. System certificates Healthcheck tests The Healthcheck tool includes several tests for verifying system (DogTag) certificates. To see all tests, run the ipa-healthcheck with the --list-sources option: You can find all tests under the ipahealthcheck.dogtag.ca source: DogtagCertsConfigCheck This test compares the CA (Certificate Authority) certificates in its NSS database to the same values stored in CS.cfg . If they do not match, the CA fails to start. Specifically, it checks: auditSigningCert cert-pki-ca against ca.audit_signing.cert ocspSigningCert cert-pki-ca against ca.ocsp_signing.cert caSigningCert cert-pki-ca against ca.signing.cert subsystemCert cert-pki-ca against ca.subsystem.cert Server-Cert cert-pki-ca against ca.sslserver.cert If Key Recovery Authority (KRA) is installed: transportCert cert-pki-kra against ca.connector.KRA.transportCert DogtagCertsConnectivityCheck This test verifies connectivity. This test is equivalent to the ipa cert-show 1 command which checks: The PKI proxy configuration in Apache IdM being able to find a CA The RA agent client certificate Correctness of CA replies to requests Note that the test checks a certificate with serial #1 because you want to verify that a cert-show can be executed and get back an expected result from CA (either the certificate or a not found). Note Run these tests on all IdM servers when trying to find an issue. 24.2. Screening system certificates using Healthcheck Follow this procedure to run a standalone manual test of Identity Management (IdM) certificates using the Healthcheck tool. Since, the Healthcheck tool includes many tests, you can narrow the results by including only DogTag tests: --source=ipahealthcheck.dogtag.ca Procedure To run Healthcheck restricted to DogTag certificates, enter: An example of a successful test: An example of a failed test: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.dogtag.ca
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: SUCCESS", "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c", "when: 20191008135826Z", "duration: 0.252280", "kw:" { "key": "Server-Cert cert-pki-ca", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg" } }
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: CRITICAL", "uuid: 59d66200-1447-4b3b-be01-89810c803a98", "when: 20191008135912Z", "duration: 0.002022", "kw:" { "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized", } }
Chapter 1. Long Term Support for AMQ Broker 7.10 AMQ Broker 7.10 has been designated as a Long Term Support (LTS) release version. For details of the terms of an LTS release, see How long are AMQ LTS releases supported? Support for Red Hat Enterprise Linux and OpenShift Container Platform The AMQ Broker 7.10 LTS version supports: Red Hat Enterprise Linux 7 and 8 OpenShift Container Platform 4.12, 4.13, 4.14 or 4.15. Red Hat strives to ensure that AMQ Broker remains compatible with future versions of OpenShift Container Platform; however this compatibility cannot be guaranteed. Interoperability testing is performed for each new OpenShift Container Platform version. If no compatibility issues are found, the new OpenShift Container Platform version is added to the Red Hat AMQ Broker 7 Supported Configurations .

Commands:
Chapter 100. KafkaTopicStatus schema reference Used in: KafkaTopic Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. topicName string Topic name. topicId string The topic's id. For a KafkaTopic with the ready condition, this will change only if the topic gets deleted and recreated with the same name. replicasChange ReplicasChangeStatus Replication factor change status.

Commands:
Chapter 11. Configuring Smart Router for TLS support You can configure Smart Router (KIE Server Router) for Transport Layer Security (TLS) support to allow HTTPS traffic. In addition, you can disable unsecure HTTP connections to Smart Router. Prerequisites KIE Server is installed on each node of a Red Hat JBoss EAP 7.4 cluster. Smart Router is installed and configured. For more information, see Installing and configuring Red Hat Process Automation Manager in a Red Hat JBoss EAP clustered environment . Procedure To start Smart Router, use one of the following methods: To start Smart Router with TLS support and HTTPS enabled as well as allowing HTTP connections, enter the following command: java -Dorg.kie.server.router.tls.keystore = <KEYSTORE_PATH> -Dorg.kie.server.router.tls.keystore.password = <KEYSTORE_PASSWORD> -Dorg.kie.server.router.tls.keystore.keyalias = <KEYSTORE_ALIAS> -Dorg.kie.server.router.tls.port = <HTTPS_PORT> -jar rhpam-7.13.5-smart-router.jar In this example, replace the following variables: <KEYSTORE_PATH> : The path where the keystore will be stored. <KEYSTORE_PASSWORD> : The keystore password. <KEYSTORE_ALIAS> : The alias name used to store the certificate. <HTTPS_PORT> : The HTTPS port. The default HTTPS port is 9443 . To start Smart Router with TLS support and HTTPS enabled and with HTTP connections disabled, enter the following command: java -Dorg.kie.server.router.tls.keystore = <KEYSTORE_PATH> -Dorg.kie.server.router.tls.keystore.password = <KEYSTORE_PASSWORD> -Dorg.kie.server.router.tls.keystore.keyalias = <KEYSTORE_ALIAS> -Dorg.kie.server.router.tls.port = <HTTPS_PORT> -Dorg.kie.server.router.port=0 -jar rhpam-7.13.5-smart-router.jar When the org.kie.server.router.port system property is set to 0 , then the HTTP listener is not registered. If TLS is configured and the HTTP listener is not registered, then Smart Router listens only on the HTTPS port. Note If TLS is not configured and you disable HTTP by setting org.kie.server.router.port to 0 , then an error occurs and Smart Router stops.

Commands:
java -Dorg.kie.server.router.tls.keystore = <KEYSTORE_PATH> -Dorg.kie.server.router.tls.keystore.password = <KEYSTORE_PASSWORD> -Dorg.kie.server.router.tls.keystore.keyalias = <KEYSTORE_ALIAS> -Dorg.kie.server.router.tls.port = <HTTPS_PORT> -jar rhpam-7.13.5-smart-router.jar
java -Dorg.kie.server.router.tls.keystore = <KEYSTORE_PATH> -Dorg.kie.server.router.tls.keystore.password = <KEYSTORE_PASSWORD> -Dorg.kie.server.router.tls.keystore.keyalias = <KEYSTORE_ALIAS> -Dorg.kie.server.router.tls.port = <HTTPS_PORT> -Dorg.kie.server.router.port=0 -jar rhpam-7.13.5-smart-router.jar