mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Ports required for communication between IdM and AD To enable communication between your Active Directory (AD) and Identity Management (IdM) environments, open the following ports on the firewalls of your AD Domain Controllers and IdM servers. Table 6.1. Ports required for an AD trust Service Port Protocol Endpoint resolution portmapper 135 TCP NetBIOS-DGM 138 TCP and UDP NetBIOS-SSN 139 TCP and UDP Microsoft-DS 445 TCP and UDP Dynamic RPC 49152-65535 TCP AD Global Catalog 3268 TCP LDAP 389 TCP and UDP Note The TCP port 389 is not required to be open on IdM servers for trust, but it is necessary for clients communicating with the IdM server. The TCP port 135 is required for the DCE RPC end-point mapper to work and is used during the IdM-AD trust creation. To open ports, you can use the following methods: firewalld service - you can enable the particular ports or enable the following services which includes the ports: FreeIPA trust setup FreeIPA with LDAP Kerberos DNS For details, see the firewall-cmd man page on your system. The RHEL web console, which is a UI with firewall settings based on the firewalld service. For details about firewall configuration through the web console, see Enabling services on the firewall using the web console Table 6.2. Ports required by IdM servers in a trust Service Port Protocol Kerberos 88, 464 TCP and UDP LDAP 389 TCP DNS 53 TCP and UDP Table 6.3. Ports required by IdM clients in an AD trust Service Port Protocol Kerberos 88 UDP and TCP Note The libkrb5 library uses UDP and falls back to the TCP protocol if the data sent from the Key Distribution Center (KDC) is too large. Active Directory attaches a Privilege Attribute Certificate (PAC) to the Kerberos ticket, which increases the size and requires to use the TCP protocol. To avoid the fall-back and resending the request, SSSD uses TCP for user authentication by default. If you want to configure the size before libkrb5 uses TCP, set the udp_preference_limit in the /etc/krb5.conf file. For details, see the krb5.conf(5) man page on your system. The following diagram shows communication sent by IdM clients, and received and responded to by IdM servers and AD Domain Controllers. To set the incoming and outgoing ports and protocols on your firewall, use the firewalld service, which already has definitions for FreeIPA services. Additional resources The default dynamic port range for TCP/IP has changed since Windows Vista and in Windows Server 2008

Commands:
2.4. Battery Life Tool Kit Red Hat Enterprise Linux 6 introduces the Battery Life Tool Kit ( BLTK ), a test suite that simulates and analyzes battery life and performance. BLTK achieves this by performing sets of tasks that simulate specific user groups and reporting on the results. Although developed specifically to test notebook performance, BLTK can also report on the performance of desktop computers when started with the -a option. BLTK allows you to generate very reproducible workloads that are comparable to real use of a machine. For example, the office workload writes a text, corrects things in it, and does the same for a spreadsheet. Running BLTK combined with PowerTOP or any of the other auditing or analysis tool allows you to test if the optimizations you performed have an effect when the machine is actively in use instead of only idling. Because you can run the exact same workload multiple times for different settings, you can compare results for different settings. Install BLTK with the command: The bltk command is run with various workloads to simulate different types of laptop usage, and one of the options. See the format of the command: The workload options available by default are: -I , --idle system is idle, to use as a baseline for comparison with other workloads -R , --reader simulates reading documents (by default, with Firefox ) -P , --player simulates watching multimedia files from a CD or DVD drive (by default, with mplayer ) -O , --office simulates editing documents with the OpenOffice.org suite Other options allow you to specify: -a , --ac-ignore ignore whether AC power is available (necessary for desktop use) -T number_of_seconds , --time number_of_seconds the time (in seconds) over which to run the test; use this option with the idle workload -F filename , --file filename specifies a file to be used by a particular workload, for example, a file for the player workload to play instead of accessing the CD or DVD drive -W application , --prog application specifies an application to be used by a particular workload, for example, a browser other than Firefox for the reader workload Example 2.2. Measuring Battery Life and Performance under Idle Workload To run the idle workload for 120 seconds, run: BLTK supports a large number of more specialized options. For details, refer to the bltk(1) man page. BLTK saves the results it generates in a directory specified in the /etc/bltk.conf configuration file - by default, ~/.bltk/ workload .results. number / . For example, the ~/.bltk/reader.results.002/ directory holds the results of the third test with the reader workload (the first test is not numbered). The results are spread across several text files. To condense these results into a format that is easy to read, run: The results now appear in a text file named Report in the results directory. To view the results in a terminal emulator instead, use the -o option:

Commands:
install bltk
bltk workload options
bltk -I -T 120
bltk_report path_to_results_directory
bltk_report -o path_to_results_directory
7.169. pyOpenSSL 7.169.1. RHBA-2015:1337 - pyOpenSSL bug fix and enhancement update Updated pyOpenSSL packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The pyOpenSSL packages provide a high-level wrapper around a subset of the OpenSSL library for the Python programming language. Note The pyOpenSSL packages have been upgraded to upstream version 0.13.1, which provides a number of bug fixes and enhancements over the version. (BZ# 1036853 ) Users of pyOpenSSL are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 2. Configuring the Compute service (nova) As a cloud administrator, you use environment files to customize the Compute (nova) service. Puppet generates and stores this configuration in the /var/lib/config-data/puppet-generated/<nova_container>/etc/nova/nova.conf file. Use the following configuration methods to customize the Compute service configuration, in the following order of precedence: Heat parameters - as detailed in the Compute (nova) Parameters section in the Overcloud parameters guide. The following example uses heat parameters to set the default scheduler filters, and configure an NFS backend for the Compute service: Puppet parameters - as defined in /etc/puppet/modules/nova/manifests/* : Note Only use this method if an equivalent heat parameter does not exist. Manual hieradata overrides - for customizing parameters when no heat or Puppet parameter exists. For example, the following sets the timeout_nbd in the [DEFAULT] section on the Compute role: Warning If a heat parameter exists, use it instead of the Puppet parameter. If a Puppet parameter exists, but not a heat parameter, use the Puppet parameter instead of the manual override method. Use the manual override method only if there is no equivalent heat or Puppet parameter. Tip Follow the guidance in Identifying parameters that you want to modify to determine if a heat or Puppet parameter is available for customizing a particular configuration. For more information about how to configure overcloud services, see Heat parameters in the Customizing your Red Hat OpenStack Platform deployment guide.

Commands:
parameter_defaults: NovaNfsEnabled: true NovaNfsOptions: "context=system_u:object_r:nfs_t:s0" NovaNfsShare: "192.0.2.254:/export/nova" NovaNfsVersion: "4.2" NovaSchedulerEnabledFilters: - AggregateInstanceExtraSpecsFilter - ComputeFilter - ComputeCapabilitiesFilter - ImagePropertiesFilter
parameter_defaults: ComputeExtraConfig: nova::compute::force_raw_images: True
parameter_defaults: ComputeExtraConfig: nova::config::nova_config: DEFAULT/timeout_nbd: value: '20'
Chapter 4. Tools and components Learn more about the Red Hat Ansible Automation Platform tools and components you will use in creating automation execution environments. 4.1. About Ansible Builder Ansible Builder is a command line tool that automates the process of building automation execution environments by using the metadata defined in various Ansible Collections or by the user. Before Ansible Builder was developed, Red Hat Ansible Automation Platform users could run into dependency issues and errors when creating custom virtual environments or containers that included all of the required dependencies installed. Now, with Ansible Builder, you can easily create a customizable automation execution environments definition file that specifies the content you want to be included in your automation execution environments such as collections, third-party Python requirements, and system-level packages. This allows you to fulfill all of the necessary requirements and dependencies to get jobs running. Note Red Hat currently does not support users who choose to provide their own container images when building automation automation execution environments. 4.2. Uses for automation content navigator Automation content navigator is a command line, content-creator-focused tool with a text-based user interface. You can use automation content navigator to: Launch and watch jobs and playbooks. Share stored, completed playbook and job run artifacts in JSON format. Browse and introspect automation execution environments. Browse your file-based inventory. Render Ansible module documentation and extract examples you can use in your playbooks. View a detailed command output on the user interface. 4.3. About automation hub Automation hub provides a place for Red Hat subscribers to quickly find and use content that is supported by Red Hat and our technology partners to deliver additional reassurance for the most demanding environments. At a high level, automation hub provides an overview of all partners participating and providing certified, supported content. From a central view, users can dive deeper into each partner and check out the collections. Additionally, a searchable overview of all available collections is available. 4.4. About the Ansible command line interface Using Ansible on the command line is a useful way to run tasks that you do not repeat very often. The recommended way to handle repeated tasks is to write a playbook. An ad hoc command for Ansible on the command line follows this structure: USD ansible [pattern] -m [module] -a "[module options]" 4.5. Additional resources For more information on how to use Ansible as a command line tool, refer to Working with command line tools in the Ansible User Guide . To upload content to automation hub, see Uploading content to automation hub in the Ansible Automation Platform product documentation.

Commands:
ansible [pattern] -m [module] -a "[module options]"
Chapter 16. Desktop 16.1. GNOME 3 Red Hat Enterprise Linux 7 features the major version of the GNOME Desktop, GNOME 3. The user experience of GNOME 3 is largely defined by GNOME Shell, which replaces the GNOME 2 desktop shell. Apart from window management, GNOME Shell provides the top bar on the screen, which hosts the "system status" area in the top right, a clock, and a hot corner that switches to Activities Overview , which provides easy access to applications and windows. The default GNOME Shell interface in Red Hat Enterprise Linux 7 is GNOME Classic which features a window list at the bottom of the screen and traditional Applications and Places menus. For more information about GNOME 3, consult GNOME help. To access it, press the Super ( Windows ) key to enter the Activities Overview , type help , and then press Enter . For more information about GNOME 3 Desktop deployment, configuration and administration, see the Desktop Migration and Administration Guide . GTK+ 3 GNOME 3 uses the GTK+ 3 library which can be installed in parallel with GTK+ 2. Both GTK+ and GTK+ 3 are available in Red Hat Enterprise Linux 7. Existing GTK+ 2 applications will continue to work in GNOME 3. GNOME Boxes Red Hat Enterprise Linux 7 introduces a lightweight graphical desktop virtualization tool used to view and access virtual machines and remote systems. GNOME Boxes provides a way to test different operating systems and applications from the desktop with minimal configuration.

Commands:
Chapter 11. Understanding How Endpoints are Defined in WSDL Abstract Endpoints represent an instantiated service. They are defined by combining a binding and the networking details used to expose the endpoint. Overview An endpoint can be thought of as a physical manifestation of a service. It combines a binding, which specifies the physical representation of the logical data used by a service, and a set of networking details that define the physical connection details used to make the service contactable by other endpoints. Note CXF providers are servers for CXF consumers, which correspond to clients. If you are using the CXF ( camel-cxf ) component as the starting endpoint in a route, then the endpoint is both a Camel consumer and a CXF provider. If you are using the Camel CXF component, as an ending endpoint in a route, then the endpoint is both a Camel producer and a CXF consumer. Endpoints and services In the same way a binding can only map a single interface, an endpoint can only map to a single service. However, a service can be manifested by any number of endpoints. For example, you could define a ticket selling service that was manifested by four different endpoints. However, you could not have a single endpoint that manifested both a ticket selling service and a widget selling service. The WSDL elements Endpoints are defined in a contract using a combination of the WSDL service element and the WSDL port element. The service element is a collection of related port elements. The port elements define the actual endpoints. The WSDL service element has a single attribute, name , that specifies a unique name. The service element is used as the parent element of a collection of related port elements. WSDL makes no specification about how the port elements are related. You can associate the port elements in any manner you see fit. The WSDL port element has a has a binding attribute, that specifies the binding used by the endpoint and is a reference to the wsdl:binding element. It also includes the name attribute, which is a mandatory attribute that provides a unique name among all ports. The port element is the parent element of the elements that specify the actual transport details used by the endpoint. The elements used to specify the transport details are discussed in the following sections. Adding endpoints to a contract Apache CXF provides command line tools that can generated endpoints for predefined service interface and binding combinations. The tools will add the proper elements to your contract for you. However, we recommended that you have some knowledge of how the different transports used in defining an endpoint work. You can also add an endpoint to a contract using any text editor. When you hand edit a contract, you are responsible for ensuring that the contract is valid. Supported transports Endpoint definitions are built using extensions defined for each of the transports Apache CXF supports. This includes the following transports: HTTP CORBA Java Messaging Service

Commands:
25.9. Managing Log Files in a Graphical Environment As an alternative to the aforementioned command-line utilities, Red Hat Enterprise Linux 6 provides an accessible GUI for managing log messages. 25.9.1. Viewing Log Files Most log files are stored in plain text format. You can view them with any text editor such as Vi or Emacs . Some log files are readable by all users on the system; however, root privileges are required to read most log files. To view system log files in an interactive, real-time application, use the Log File Viewer . Note In order to use the Log File Viewer , first ensure the gnome-system-log package is installed on your system by running, as root : The gnome-system-log package is provided by the Optional subscription channel that must be enabled before installation. See Section 8.4.8, "Adding the Optional and Supplementary Repositories" for more information on Red Hat additional channels. For more information on installing packages with Yum, see Section 8.2.4, "Installing Packages" . After you have installed the gnome-system-log package, open the Log File Viewer by clicking Applications System Tools Log File Viewer , or type the following command at a shell prompt: The application only displays log files that exist; thus, the list might differ from the one shown in Figure 25.2, "Log File Viewer" . Figure 25.2. Log File Viewer The Log File Viewer application lets you filter any existing log file. Click on Filters from the menu and select Manage Filters to define or edit the desired filter. Figure 25.3. Log File Viewer - Filters Adding or editing a filter lets you define its parameters as is shown in Figure 25.4, "Log File Viewer - defining a filter" . Figure 25.4. Log File Viewer - defining a filter When defining a filter, the following parameters can be edited: Name - Specifies the name of the filter. Regular Expression - Specifies the regular expression that will be applied to the log file and will attempt to match any possible strings of text in it. Effect Highlight - If checked, the found results will be highlighted with the selected color. You may select whether to highlight the background or the foreground of the text. Hide - If checked, the found results will be hidden from the log file you are viewing. When you have at least one filter defined, it can be selected from the Filters menu and it will automatically search for the strings you have defined in the filter and highlight or hide every successful match in the log file you are currently viewing. Figure 25.5. Log File Viewer - enabling a filter When you select the Show matches only option, only the matched strings will be shown in the log file you are currently viewing.

Commands:
~]# yum install gnome-system-log
~]USD gnome-system-log
7.206. sudo 7.206.1. RHSA-2015:1409 - Moderate: sudo security, bug fix, and enhancement update Updated sudo packages that fix one security issue, three bugs, and add one enhancement are now available for Red Hat Enterprise Linux 6. Red Hat Product Security has rated this update as having Moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link in the References section. The sudo packages contain the sudo utility which allows system administrators to provide certain users with the permission to execute privileged commands, which are used for system management purposes, without having to log in as root. Security Fix CVE-2014-9680 It was discovered that sudo did not perform any checks of the TZ environment variable value. If sudo was configured to preserve the TZ environment variable, a local user with privileges to execute commands via sudo could possibly use this flaw to achieve system state changes not permitted by the configured commands. Note: The default sudoers configuration in Red Hat Enterprise Linux removes the TZ variable from the environment in which commands run by sudo are executed. Bug Fixes BZ# 1094548 Previously, the sudo utility child processes could sometimes become unresponsive because they ignored the SIGPIPE signal. With this update, SIGPIPE handler is properly restored in the function that reads passwords from the user, and the child processes no longer ignore SIGPIPE. As a result, sudo child processes do not hang in this situation. BZ# 1138581 Prior to this update, the order in which sudo rules were processed did not honor the user-defined sudoOrder attribute. Consequently, sudo rules were processed in an undefined order even when the user defined the order in sudoOrder. The implementation of SSSD support in sudo has been modified to sort the rules according to the sudoOrder value, and sudo rules are now sorted in the order defined by the user in sudoOrder. BZ# 1147498 Previously, sudo became unresponsive after the user issued a command when a sudoers source was mentioned multiple times in the /etc/nsswitch.conf file. The problem occurred when nsswitch.conf contained, for example, the "sudoers: files sss sss" entry. The sudoers source processing code has been fixed to correctly handle multiple instances of the same sudoers source. As a result, sudo no longer hangs when a sudoers source is mentioned multiple times in /etc/nsswitch.conf. Enhancement BZ# 1106433 The sudo utility now supports I/O logs compressed using the zlib library. With this update, sudo can generate zlib compressed I/O logs and also process zlib compressed I/O logs generated by other versions of sudo with zlib support. All sudo users are advised to upgrade to these updated packages, which contain backported patches to correct these issues and add this enhancement.

Commands:
Chapter 9. Overview of the test environment 9.1. Preparing the test environment for installer-provisioned infrastructure (IPI) The environment for the certification comprises the following components: The bare-metal server on which the IPI cluster that needs certification is installed is referred to as the host under test (HUT). Achieve a successful installer-provisioned installation on the bare-metal system. See Deploying IPI clusters on bare metal . 9.2. Preparing the test environment for assisted installer Important If you prefer using Cockpit instead of the command line for Assisted Installer certification testing, you must set up the Cockpit first. See Configuring the systems and running tests by using Cockpit for instructions. The environment for the certification comprises the following components: A bare-metal server that acts as the Host Under Test (HUT). This is the server that you are certifying. The server must have an Internet connection. The tests verify single-node clusters only . If you want to certify several bare-metal servers, you must install each of them as a single-node cluster. The bare-metal server must comply with the hardware requirements of a control plane node and the network requirements as stated in the assisted installer for OpenShift Container Platform documentation . A Red Hat account that can log in to the Red Hat Hybrid Cloud Console to install the HUT by using the assisted installer. You can use the UI or the API to perform the installation. After installing the single-node cluster using the assisted installer, you can utilize a RHEL 8 or RHEL 9 client that has access to the single-node cluster to proceed with running the assisted_installer test.

Commands: