mtpti5iD/redhat-docs_dataset huggingface dataset:
16.12. Assign Storage Devices If you selected more than one storage device on the storage devices selection screen (refer to Section 16.8, "Storage Devices" ), anaconda asks you to select which of these devices should be available for installation of the operating system, and which should only be attached to the file system for data storage. If you selected only one storage device, anaconda does not present you with this screen. During installation, the devices that you identify here as being for data storage only are mounted as part of the file system, but are not partitioned or formatted. Figure 16.33. Assign storage devices The screen is split into two panes. The left pane contains a list of devices to be used for data storage only. The right pane contains a list of devices that are to be available for installation of the operating system. Each list contains information about the devices to help you to identify them. A small drop-down menu marked with an icon is located to the right of the column headings. This menu allows you to select the types of data presented on each device. Reducing or expanding the amount of information presented might help you to identify particular devices. Move a device from one list to the other by clicking on the device, then clicking either the button labeled with a left-pointing arrow to move it to the list of data storage devices or the button labeled with a right-pointing arrow to move it to the list of devices available for installation of the operating system. The list of devices available as installation targets also includes a radio button beside each device. Use this radio button to specify the device that you want to use as the boot device for the system. Important If any storage device contains a boot loader that will chain load the Red Hat Enterprise Linux boot loader, include that storage device among the Install Target Devices . Storage devices that you identify as Install Target Devices remain visible to anaconda during boot loader configuration. Storage devices that you identify as Install Target Devices on this screen are not automatically erased by the installation process unless you selected the Use All Space option on the partitioning screen (refer to Section 16.15, "Disk Partitioning Setup" ). When you have finished identifying devices to be used for installation, click to continue.

Commands:
Chapter 1. Introduction 1.1. About the Rule Development Guide This guide is intended for software engineers who want to create custom YAML-based rules for Migration Toolkit for Applications (MTA) tools. See the Introduction to the Migration Toolkit for Applications for an overview and the CLI Guide for details. 1.1.1. Use of <MTA_HOME> in this guide This guide uses the <MTA_HOME> replaceable variable to denote the path to your MTA installation. The mta-7.1.1-cli<OS>.zip* extracts a single binary called mta-cli . When you encounter <MTA_HOME> in this guide, replace it with the actual path to your MTA installation. 1.2. The MTA rules The Migration Toolkit for Applications (MTA) contains rule-based migration tools (analyzers) that you can use to analyze the application user interfaces (APIs), technologies, and architectures used by the applications you plan to migrate. MTA analyzer rules use the following rule pattern: You can use the MTA rules internally to perform the following tasks: Extract files from archives. Decompile files. Scan and classify file types. Analyze XML and other file content. Analyze the application code. Build the reports. MTA builds a data model based on the rule execution results and stores component data and relationships in a graph database. This database can then be queried and updated as required by the migration rules and for reporting purposes. Note You can create your own custom analyzer rules. You can use custom rules to identify the use of custom libraries or other components that might not be covered by the provided standard migration rules.

Commands:
when(condition) message(message) tag(tags)
1.9. Making the Installation Tree Available The kickstart installation must access an installation tree . An installation tree is a copy of the binary Red Hat Enterprise Linux CD-ROMs with the same directory structure. If you are performing a CD-based installation, insert the Red Hat Enterprise Linux CD-ROM #1 into the computer before starting the kickstart installation. If you are performing a hard drive installation, make sure the ISO images of the binary Red Hat Enterprise Linux CD-ROMs are on a hard drive in the computer. If you are performing a network-based (NFS, FTP, or HTTP) installation, you must make the installation tree available over the network. Refer to the Preparing for a Network Installation section of the Installation Guide for details.

Commands:
4.37. cryptsetup-luks 4.37.1. RHBA-2011:1688 - cryptsetup-luks bug fix and enhancement update Updated cryptsetup-luks packages that fix several bugs and add an enhancement are now available for Red Hat Enterprise Linux 6. The cryptsetup-luks packages provide a utility which allows users to set up encrypted devices with the Device Mapper and the dm-crypt target. Bug Fixes BZ# 713410 When the cryptsetup or libcryptsetup utility was run in FIPS (Federal Information Processing Standards) mode, the "Running in FIPS mode." message was displayed during initialization of all commands. This sometimes caused minor issues with associated scripts. This bug has been fixed and the message is now displayed only in verbose mode. BZ# 732179 Prior to this update, several directives were missing in cryptsetup status command implementation. Therefore, the cryptsetup status command always returned the exit code 0 when verifying the status of a mapped device. To fix this issue, the code has been modified. The cryptsetup status command now returns the 0 value only if the device checked is active. Enhancement BZ# 701936 Previously, the libcryptsetup crypt_get_volume_key() function allowed to perform an action not compliant with FIPS. To conform FIPS requirements, the function is now disabled in FIPS mode and returns an EACCES error code to indicate it. Note that the "luksDump --dump-master-key" command and the key escrow functionality of the volume_key package are also disabled in FIPS mode as a consequence of this update. All users of cryptsetup-luks are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
B.3. Diagram Preferences Several diagram preferences are available to customize your diagrams. Routers - The relationship link type for Package and Custom diagrams (Foreign Key - Primary Key relationships) can be customized. Available options include Orthogonal (default), Directed or Manual (user defined breakpoints). Font Settings - Select font type, style and size. Background Color Settings - Select a unique background color for each diagram type to help differentiate between types. Model Size - Displaying very large diagram may take a considerably long time. This preference allows users to set an upper limit on the number of objects to display in a diagram. If this limit is exceeded, a warning is displayed to the user and the diagram is not constructed. Relationship Options - UML-type relationships can be customized in a couple of ways. Role Names and Multiplicity labels can be shown or hidden using the checkboxes labeled Show Role Names and Show Multiplicity . Figure B.2. Diagram Preferences Panel

Commands:
Chapter 19. Adding execution nodes to Red Hat Ansible Automation Platform Operator You can enable the Ansible Automation Platform Operator with execution nodes by downloading and installing the install bundle. Prerequisites An automation controller instance. The receptor collection package is installed. AAP Repository ansible-automation-platform-2.4-for-rhel-{RHEL-RELEASE-NUMBER}-x86_64-rpms is enabled. Procedure Log in to Red Hat Ansible Automation Platform. In the navigation panel, select Administration Instances . Click Add . Input the Execution Node domain name or IP in the Host Name field. Optional: Input the port number in the Listener Port field. Click Save . Click the download icon to Install Bundle . This starts a download, take note of where you save the file Untar the gz file. Note To run the install_receptor.yml playbook you need to install the receptor collection from Ansible Galaxy: Ansible-galaxy collection install -r requirements.yml Update the playbook with your user name and SSH private key file. Note that ansible_host pre-populates with the hostname you input earlier. all: hosts: remote-execution: ansible_host: example_host_name # Same with configured in AAP WebUI ansible_user: <username> #user provided Ansible_ssh_private_key_file: ~/.ssh/id_example Open your terminal, and navigate to the directory where you saved the playbook. To install the bundle run: ansible-playbook install_receptor.yml -i inventory.yml When installed you can now upgrade your execution node by downloading and re-running the playbook for the instance you created. Verification To verify receptor service status run the following command: sudo systemctl status receptor.service Make sure the service is in active (running) state To verify if your playbook runs correctly on your new node run the following command: watch podman ps Additional resources For more information about managing instance groups see the Managing Instance Groups section of the Automation Controller User Guide.

Commands:
all: hosts: remote-execution: ansible_host: example_host_name # Same with configured in AAP WebUI ansible_user: <username> #user provided Ansible_ssh_private_key_file: ~/.ssh/id_example
ansible-playbook install_receptor.yml -i inventory.yml
sudo systemctl status receptor.service
watch podman ps
Chapter 11. Improving import performance Very large attribute sizes or a large number of entries can negatively impact server performance during import operations. This section describes how to tune Directory Server settings to improve the import performance. 11.1. Tuning directory server for large database imports and imports with large attribute values Use the import cache autosizing feature for operations like: importing a very large database importing a database with large attributes, such as binary attributes that store certificate chains or images Note Offline imports are faster than online ones. Consider using offline imports where possible. You can configure the import cache autosizing feature with the nsslapd-import-cache-autosize attribute. By default, Directory Server enables the import cache autosizing for the ldif2db operation only, automatically allocating 50% of the free physical memory for the import cache. For further details, see the description of the nsslapd-import-cache-autosize attribute in the Configuration, Command, and File Reference document.

Commands:
3.10. Red Hat High Availability Add-On and SELinux The High Availability Add-On for Red Hat Enterprise Linux 6 supports SELinux in the enforcing state with the SELinux policy type set to targeted . Note When using SELinux with the High Availability Add-On in a VM environment, you should ensure that the SELinux boolean fenced_can_network_connect is persistently set to on . This allows the fence_xvm fencing agent to work properly, enabling the system to fence virtual machines. For more information about SELinux, see Deployment Guide for Red Hat Enterprise Linux 6.

Commands:
Chapter 79. KafkaConnectTemplate schema reference Used in: KafkaConnectSpec , KafkaMirrorMaker2Spec Property Description deployment Template for Kafka Connect Deployment . DeploymentTemplate podSet Template for Kafka Connect StrimziPodSet resource. ResourceTemplate pod Template for Kafka Connect Pods . PodTemplate apiService Template for Kafka Connect API Service . InternalServiceTemplate headlessService Template for Kafka Connect headless Service . InternalServiceTemplate connectContainer Template for the Kafka Connect container. ContainerTemplate initContainer Template for the Kafka init container. ContainerTemplate podDisruptionBudget Template for Kafka Connect PodDisruptionBudget . PodDisruptionBudgetTemplate serviceAccount Template for the Kafka Connect service account. ResourceTemplate clusterRoleBinding Template for the Kafka Connect ClusterRoleBinding. ResourceTemplate buildPod Template for Kafka Connect Build Pods . The build pod is used only on OpenShift. PodTemplate buildContainer Template for the Kafka Connect Build container. The build container is used only on OpenShift. ContainerTemplate buildConfig Template for the Kafka Connect BuildConfig used to build new container images. The BuildConfig is used only on OpenShift. BuildConfigTemplate buildServiceAccount Template for the Kafka Connect Build service account. ResourceTemplate jmxSecret Template for Secret of the Kafka Connect Cluster JMX authentication. ResourceTemplate

Commands:
7.95. iscsi-initiator-utils 7.95.1. RHBA-2013:0438 - iscsi-initiator-utils bug fix and enhancement update Updated iscsi-initiator-utils packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The iscsi-initiator-utils packages provide the server daemon for the Internet Small Computer System Interface (iSCSI) protocol, as well as the utility programs used to manage it. iSCSI is a protocol for distributed disk access using SCSI commands sent over Internet Protocol (IP) networks. Note The iSCSI user-space driver, iscsiuio, has been upgraded to upstream version 0.7.6.1, which provides a number of bug fixes and enhancements over the version. In particular, VLAN and routing support. (BZ#826300) Bug Fixes BZ#826300 The iSCSI user-space driver, iscsiuio, has been upgraded to upstream version 0.7.6.1, which provides a number of bug fixes and enhancements over the version. In particular, VLAN and routing support. BZ# 811428 The "iscsiadm --version" command was missing the main version number, the leading "6.". This update corrects the version number value and "iscsiadm --version" now shows the main version number correctly. BZ# 854776 For some bnx2i cards, the network interface must be active for the iSCSI interface to report a valid MAC address. This sometimes lead to a failure to connect to an iSCSI target and consequently, iSCSI root setups failing to boot. This update changes iscsistart to put the network interface associated with the iSCSI context into an active state. As a result, iSCSI boot with bnx2i cards now works correctly. BZ# 868305 Due to a regression in the iscsiuio 0.7.4.3 update, iSCSI discovery and login failed on certain hardware. This has been corrected as part of the iscsiuio 0.7.6.1 update. As a result, iSCSI is functional again. All users of iscsi-initiator-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
probe::sunrpc.svc.send Name probe::sunrpc.svc.send - Return reply to RPC client Synopsis sunrpc.svc.send Values rq_vers the program version in the request rq_prog the program number in the request rq_prot the IP protocol of the reqeust sv_name the service name rq_xid the transmission id in the request peer_ip the peer address where the request is from rq_proc the procedure number in the request

Commands:
Chapter 41. PodDisruptionBudgetTemplate schema reference Used in: CruiseControlTemplate , KafkaBridgeTemplate , KafkaClusterTemplate , KafkaConnectTemplate , KafkaMirrorMakerTemplate , ZookeeperClusterTemplate Full list of PodDisruptionBudgetTemplate schema properties A PodDisruptionBudget (PDB) is an OpenShift resource that ensures high availability by specifying the minimum number of pods that must be available during planned maintenance or upgrades. Streams for Apache Kafka creates a PDB for every new StrimziPodSet or Deployment . By default, the PDB allows only one pod to be unavailable at any given time. You can increase the number of unavailable pods allowed by changing the default value of the maxUnavailable property. StrimziPodSet custom resources manage pods using a custom controller that cannot use the maxUnavailable value directly. Instead, the maxUnavailable value is automatically converted to a minAvailable value when creating the PDB resource, which effectively serves the same purpose, as illustrated in the following examples: If there are three broker pods and the maxUnavailable property is set to 1 in the Kafka resource, the minAvailable setting is 2 , allowing one pod to be unavailable. If there are three broker pods and the maxUnavailable property is set to 0 (zero), the minAvailable setting is 3 , requiring all three broker pods to be available and allowing zero pods to be unavailable. Example PodDisruptionBudget template configuration # ... template: podDisruptionBudget: metadata: labels: key1: label1 key2: label2 annotations: key1: label1 key2: label2 maxUnavailable: 1 # ... 41.1. PodDisruptionBudgetTemplate schema properties Property Property type Description metadata MetadataTemplate Metadata to apply to the PodDisruptionBudgetTemplate resource. maxUnavailable integer Maximum number of unavailable pods to allow automatic Pod eviction. A Pod eviction is allowed when the maxUnavailable number of pods or fewer are unavailable after the eviction. Setting this value to 0 prevents all voluntary evictions, so the pods must be evicted manually. Defaults to 1.

Commands:
template: podDisruptionBudget: metadata: labels: key1: label1 key2: label2 annotations: key1: label1 key2: label2 maxUnavailable: 1
8.6. Getting the Status of Available Snapshots This command displays the running status of the snapshot. By default the status of all the snapshots in the cluster are displayed. To check the status of all the snapshots that are taken for a particular volume, specify a volume name: where, snapname - This is an optional field. If the snapname is provided then the status about the specified snap is displayed. VOLNAME - This is an optional field. If the VOLNAME is provided the status about all the snaps in the specified volume is displayed. For example: Note This shows the status of an activated snapshot.

Commands:
gluster snapshot status [(< snapname > | volume VOLNAME )]
gluster snapshot status snap3 Snap Name : snap3 Snap UUID : b2a391ce-f511-478f-83b7-1f6ae80612c8 Brick Path : 10.70.42.248:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick1/brick1 Volume Group : snap_lvgrp1 Brick Running : Yes Brick PID : 1640 Data Percentage : 1.54 LV Size : 616.00m Brick Path : 10.70.43.139:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick2/brick3 Volume Group : snap_lvgrp1 Brick Running : Yes Brick PID : 3900 Data Percentage : 1.80 LV Size : 616.00m Brick Path : 10.70.43.34:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick3/brick4 Volume Group : snap_lvgrp1 Brick Running : Yes Brick PID : 3507 Data Percentage : 1.80 LV Size : 616.00m
Chapter 2. 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. 2.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. For information about how to scale up HCI nodes by adding OSDs to a Red Hat Ceph Storage cluster, see Adding an OSD to a Ceph Storage node in Deploying an Overcloud with Containerized Red Hat Ceph . 2.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. 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:
Appendix A. Getting involved in the Migration Toolkit for Applications development A.1. Contributing to the project To help the Migration Toolkit for Applications cover most application constructs and server configurations, including yours, you can help with any of the following items: Send an email to jboss-migration-feedback@redhat.com and let us know what MTA migration rules must cover. Provide example applications to test migration rules. Identify application components and problem areas that might be difficult to migrate: Write a short description of the problem migration areas. Write a brief overview describing how to solve the problem in migration areas. Try Migration Toolkit for Applications on your application. Make sure to report any issues you meet. Contribute to the Migration Toolkit for Applications rules repository: Write a Migration Toolkit for Applications rule to identify or automate a migration process. Create a test for the new rule. For more information, see Rule Development Guide . Contribute to the project source code: Create a core rule. Improve MTA performance or efficiency. Any level of involvement is greatly appreciated! A.2. Reporting issues MTA uses Jira as its issue tracking system. If you encounter an issue executing MTA, submit a Jira issue . A.3. Migration Toolkit for Applications development resources Use the following resources to learn and contribute to the Migration Toolkit for Applications development: MTA forums: https://developer.jboss.org/en/windup Jira issue tracker: https://issues.redhat.com/projects/MTA/issues MTA mailing list: jboss-migration-feedback@redhat.com Revised on 2024-12-31 15:04:06 UTC

Commands:
Chapter 2. Using Active Directory as an Identity Provider for SSSD The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client ) to an external back-end system (a domain ). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm. When used as an identity management service for AD integration, SSSD is an alternative to services such as NIS or Winbind. This chapter describes how SSSD works with AD. For more details on SSSD, see the System-Level Authentication Guide . 2.1. How the AD Provider Handles Trusted Domains This section describes how SSSD handles trusted domains if you set id_provider = ad in the /etc/sssd/sssd.conf file. SSSD only supports domains in a single Active Directory forest. If SSSD requires access to multiple domains from multiple forests, consider using IdM with trusts (preferred) or the winbindd service instead of SSSD. By default, SSSD discovers all domains in the forest and, if a request for an object in a trusted domain arrives, SSSD tries to resolve it. If the trusted domains are not reachable or geographically distant, which makes them slow, you can set the ad_enabled_domains parameter in /etc/sssd/sssd.conf to limit from which trusted domains SSSD resolves objects. By default, you must use fully-qualified user names to resolve users from trusted domains.

Commands: