mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction to Automation execution environments Using Ansible content that depends on non-default dependencies can be complicated because the packages must be installed on each node, interact with other software installed on the host system, and be kept in sync. Automation execution environments help simplify this process and can easily be created with Ansible Builder. 1.1. About automation execution environments Automation execution environments are container images on which all automation in Red Hat Ansible Automation Platform is run. Automation execution environments create a common language for communicating automation dependencies, and provide a standard way to build and distribute the automation environment. An automation execution environment is expected to contain the following: Ansible 2.9 or Ansible Core 2.11-2.13 Python 3.8-3.10 Ansible Runner Ansible content collections Collection, Python, or system dependencies 1.1.1. Why use automation execution environments? With automation execution environments, Red Hat Ansible Automation Platform has transitioned to a distributed architecture by separating the control plane from the execution plane. Keeping automation execution independent of the control plane results in faster development cycles and improves scalability, reliability, and portability across environments. Red Hat Ansible Automation Platform also includes access to Ansible content tools, making it easy to build and manage automation execution environments. In addition to speed, portability, and flexibility, automation execution environments provide the following benefits: They ensure that automation runs consistently across multiple platforms and make it possible to incorporate system-level dependencies and collection-based content. They give Red Hat Ansible Automation Platform administrators the ability to provide and manage automation environments to meet the needs of different teams. They allow automation to be easily scaled and shared between teams by providing a standard way of building and distributing the automation environment. They enable automation teams to define, build, and update their automation environments themselves. Automation execution environments provide a common language to communicate automation dependencies.

Commands:
3.11. Multicast Addresses The nodes in a cluster communicate among each other using multicast addresses. Therefore, each network switch and associated networking equipment in the Red Hat High Availability Add-On must be configured to enable multicast addresses and support IGMP (Internet Group Management Protocol). Ensure that each network switch and associated networking equipment in the Red Hat High Availability Add-On are capable of supporting multicast addresses and IGMP; if they are, ensure that multicast addressing and IGMP are enabled. Without multicast and IGMP, not all nodes can participate in a cluster, causing the cluster to fail; use UDP unicast in these environments, as described in Section 3.12, "UDP Unicast Traffic" . Note Procedures for configuring network switches and associated networking equipment vary according each product. Refer to the appropriate vendor documentation or other information about configuring network switches and associated networking equipment to enable multicast addresses and IGMP.

Commands:
Appendix A. Troubleshooting DNF modules If DNF modules fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows. List the enabled modules: A.1. Ruby If Ruby module fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows: List the enabled modules: If the Ruby 2.5 module has already been enabled, perform a module reset: A.2. PostgreSQL If PostgreSQL module fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows: List the enabled modules: If the PostgreSQL 10 module has already been enabled, perform a module reset: If you created a PostgreSQL 10 database, perform an upgrade: Enable the DNF modules: Install the PostgreSQL upgrade package: Perform the upgrade:

Commands:
dnf module list --enabled
dnf module list --enabled
dnf module reset ruby
dnf module list --enabled
dnf module reset postgresql
dnf module enable satellite:el8
dnf install postgresql-upgrade
postgresql-setup --upgrade
Appendix A. Component Versions This appendix is a list of components and their versions in the Red Hat Enterprise Linux 7.2 release. Table A.1. Component Versions Component Version Kernel 3.10.0-327 QLogic qla2xxx driver 8.07.00.18.07.2-k QLogic qla4xxx driver 5.04.00.00.07.02-k0 Emulex lpfc driver 0:10.7.0.1 iSCSI initiator utils iscsi-initiator-utils-6.2.0.873-32 DM-Multipath device-mapper-multipath-0.4.9-85 LVM lvm2-2.02.130-5

Commands:
8.8. bind-dyndb-ldap 8.8.1. RHBA-2013:1636 - bind-dyndb-ldap bug fix update Updated bind-dyndb-ldap packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The dynamic LDAP back-end is a plug-in for BIND that provides back-end capabilities to LDAP databases. It features support for dynamic updates and internal caching that helps to reduce the load on LDAP servers. Bug Fixes BZ# 908780 Previously, the bind-dyndb-ldap plug-in did not handle DNS zones without the "idnsUpdatePolicy" attribute properly, which led to a harmless, but misleading error message: zone serial ([zone serial]) unchanged. zone may fail to transfer to slaves. This message was logged after each zone reload or potentially after each change in the affected DNS zone. The bind-dyndb-ldap plug-in has been fixed, so that it no longer prints any error message if the "idnsUpdatePolicy" attribute is not defined in the DNS zone. BZ# 921167 Previously, the bind-dyndb-ldap plug-in processed update policies with the "zonesub" match-type incorrectly, which led to the BIND daemon terminating unexpectedly during the processing of the update-policy parameter. The bind-dyndb-ldap plug-in has been fixed to process update-policy with the "zonesub" match-type correctly, and so it no longer crashes in this scenario. BZ# 923113 The bind-dyndb-ldap plug-in processed settings too early, which led to the BIND daemon terminating unexpectedly with an assertion failure during startup or reload. The bind-dyndb-ldap plug-in has been fixed to process its options later, and so no longer crashes during startup or reload. BZ# 1010396 Prior to this update, the bind-dyndb-ldap plug-in with the default configuration did not establish enough connections to LDAP server for the pointer record (PTR) synchronization feature and, consequently, the PTR record synchronization failed. With this update, the default number of connections has been raised to four, and the PTR record synchronization now works as expected. Users of bind-dyndb-ldap are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Security Guide Red Hat Enterprise Linux 6 A Guide to Securing Red Hat Enterprise Linux Mirek Jahoda Red Hat Customer Content Services mjahoda@redhat.com Robert Kratky Red Hat Customer Content Services Martin Prpic Red Hat Customer Content Services Tomas Capek Red Hat Customer Content Services Stephen Wadeley Red Hat Customer Content Services Yoana Ruseva Red Hat Customer Content Services Miroslav Svoboda Red Hat Customer Content Services

Commands:
Chapter 5. Creating sample applications with .NET 9.0 5.1. Creating the MVC sample application s2i-dotnetcore-ex is the default Model, View, Controller (MVC) template application for .NET. This application is used as the example application by the .NET S2I image and can be created directly from the OpenShift UI using the Try Example link. The application can also be created with the OpenShift client binary ( oc ). Procedure To create the sample application using oc : Add the .NET application: Make the application accessible externally: Obtain the sharable URL: Additional resources s2i-dotnetcore-ex application repository on GitHub 5.2. Creating the CRUD sample application s2i-dotnetcore-persistent-ex is a simple Create, Read, Update, Delete (CRUD) .NET web application that stores data in a PostgreSQL database. Procedure To create the sample application using oc : Add the database: Add the .NET application: Add environment variables from the postgresql secret and database service name environment variable: Make the application accessible externally: Obtain the sharable URL: Additional resources s2i-dotnetcore-ex application repository on GitHub

Commands:
oc new-app dotnet:9.0-ubi8~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnet-9.0 --context-dir=app
oc expose service s2i-dotnetcore-ex
oc get route s2i-dotnetcore-ex
oc new-app postgresql-ephemeral
oc new-app dotnet:9.0-ubi8~https://github.com/redhat-developer/s2i-dotnetcore-persistent-ex#dotnet-9.0 --context-dir app
oc set env dc/s2i-dotnetcore-persistent-ex --from=secret/postgresql -e database-service=postgresql
oc expose service s2i-dotnetcore-persistent-ex
oc get route s2i-dotnetcore-persistent-ex
28.4.5. Configuring ABRT to Detect a Kernel Panic With Red Hat Enterprise Linux 6.3, ABRT can detect a kernel panic using the abrt-vmcore service, which is provided by the abrt-addon-vmcore package. The service starts automatically on system boot and searches for a core dump file in the /var/crash/ directory. If a core dump file is found, abrt-vmcore creates the problem data directory in the /var/spool/abrt/ directory and moves the core dump file to the newly created problem data directory. After the /var/crash/ directory is searched through, the service is stopped until the system boot. To configure ABRT to detect a kernel panic, perform the following steps: Ensure that the kdump service is enabled on the system. Especially, the amount of memory that is reserved for the kdump kernel has to be set correctly. You can set it by using the system-config-kdump graphical tool, or by specifying the crashkernel parameter in the list of kernel options in the /etc/grub.conf configuration file. See Chapter 32, The kdump Crash Recovery Service for details on how to enable and configure kdump . Install the abrt-addon-vmcore package using the Yum package installer: This installs the abrt-vmcore service with respective support and configuration files. Please note that the abrt-addon-vmcore package is provided by the Optional subscription channel. See Section 8.4.8, "Adding the Optional and Supplementary Repositories" for more information on Red Hat additional channels. Reboot the system for the changes to take effect. Unless ABRT is configured differently, problem data for any detected kernel panic is now stored in the /var/spool/abrt/ directory and can be further processed by ABRT just as any other detected kernel oops.

Commands:
~]# yum install abrt-addon-vmcore
Chapter 16. Deleting applications You can delete applications created in your project. 16.1. Deleting applications using the Developer perspective You can delete an application and all of its associated components using the Topology view in the Developer perspective: Click the application you want to delete to see the side panel with the resource details of the application. Click the Actions drop-down menu displayed on the upper right of the panel, and select Delete Application to see a confirmation dialog box. Enter the name of the application and click Delete to delete it. You can also right-click the application you want to delete and click Delete Application to delete it.

Commands:
Chapter 6. Configuring Cluster Resources This chapter provides information on configuring resources in a cluster. 6.1. Resource Creation Use the following command to create a cluster resource. When you specify the --group option, the resource is added to the resource group named. If the group does not exist, this creates the group and adds this resource to the group. For information on resource groups, see Section 6.5, "Resource Groups" . The --before and --after options specify the position of the added resource relative to a resource that already exists in a resource group. Specifying the --disabled option indicates that the resource is not started automatically. The following command creates a resource with the name VirtualIP of standard ocf , provider heartbeat , and type IPaddr2 . The floating address of this resource is 192.168.0.120, the system will check whether the resource is running every 30 seconds. Alternately, you can omit the standard and provider fields and use the following command. This will default to a standard of ocf and a provider of heartbeat . Use the following command to delete a configured resource. For example, the following command deletes an existing resource with a resource ID of VirtualIP For information on the resource_id , standard , provider , and type fields of the pcs resource create command, see Section 6.2, "Resource Properties" . For information on defining resource parameters for individual resources, see Section 6.3, "Resource-Specific Parameters" . For information on defining resource meta options, which are used by the cluster to decide how a resource should behave, see Section 6.4, "Resource Meta Options" . For information on defining the operations to perform on a resource, see Section 6.6, "Resource Operations" . Specifying the clone option creates a clone resource. Specifying the master option creates a master/slave resource. For information on resource clones and resources with multiple modes, see Chapter 9, Advanced Configuration .

Commands:
pcs resource create resource_id [ standard :[ provider :]] type [ resource_options ] [op operation_action operation_options [ operation_action operation options ]...] [meta meta_options ...] [clone [ clone_options ] | master [ master_options ] | --group group_name [--before resource_id | --after resource_id ] | [bundle bundle_id ] [--disabled] [--wait[= n ]]
pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs resource create VirtualIP IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs resource delete resource_id
pcs resource delete VirtualIP
Chapter 2. The value of registering your RHEL system to Red Hat Registration establishes an authorized connection between your system and Red Hat. Red Hat issues the registered system, whether a physical or virtual machine, a certificate that identifies and authenticates the system so that it can receive protected content, software updates, security patches, support, and managed services from Red Hat. With a valid subscription, you can register a Red Hat Enterprise Linux (RHEL) system in the following ways: During the installation process, using an installer graphical user interface (GUI) or text user interface (TUI) After installation, using the command line (CLI) Automatically, during or after installation, using a kickstart script or an activation key. The specific steps to register your system depend on the version of RHEL that you are using and the registration method that you choose. Registering your system to Red Hat enables features and capabilities that you can use to manage your system and report data. For example, a registered system is authorized to access protected content repositories for subscribed products through the Red Hat Content Delivery Network (CDN) or a Red Hat Satellite Server. These content repositories contain Red Hat software packages and updates that are available only to customers with an active subscription. These packages and updates include security patches, bug fixes, and new features for RHEL and other Red Hat products. Important The entitlement-based subscription model is deprecated and will be retired in the future. Simple content access is now the default subscription model. It provides an improved subscription experience that eliminates the need to attach a subscription to a system before you can access Red Hat subscription content on that system. If your Red Hat account uses the entitlement-based subscription model, contact your Red hat account team, for example, a technical account manager (TAM) or solution architect (SA) to prepare for migration to simple content access. For more information, see Transition of subscription services to the hybrid cloud .

Commands:
6.2. Resource Properties The properties that you define for a resource tell the cluster which script to use for the resource, where to find that script and what standards it conforms to. Table 6.1, "Resource Properties" describes these properties. Table 6.1. Resource Properties Field Description resource_id Your name for the resource standard The standard the script conforms to. Allowed values: ocf , service , upstart , systemd , lsb , stonith type The name of the Resource Agent you wish to use, for example IPaddr or Filesystem provider The OCF spec allows multiple vendors to supply the same resource agent. Most of the agents shipped by Red Hat use heartbeat as the provider. Table 6.2, "Commands to Display Resource Properties" . summarizes the commands that display the available resource properties. Table 6.2. Commands to Display Resource Properties pcs Display Command Output pcs resource list Displays a list of all available resources. pcs resource standards Displays a list of available resources agent standards. pcs resource providers Displays a list of available resources agent providers. pcs resource list string Displays a list of available resources filtered by the specified string. You can use this command to display resources filtered by the name of a standard, a provider, or a type.

Commands:
6.7. RHEA-2013:0349 - new packages: linuxptp New linuxptp packages are now available as a Technology Preview for Red Hat Enterprise Linux 6. The Linux PTP project is a software implementation of the Precision Time Protocol (PTP) according to IEEE standard 1588 for Linux. These packages provide a robust implementation of the standard and use the most relevant and modern Application Programming Interfaces (API) offered by the Linux kernel. Supporting legacy APIs and other platforms is not a goal. This enhancement update adds the linuxptp packages to Red Hat Enterprise Linux 6 as a Technology preview. (BZ#848856) More information about Red Hat Technology Previews is available here: https://access.redhat.com/support/offerings/techpreview/ All users who want to use the linuxptp Technology Preview should install these newly-released packages, which add this enhancement.

Commands:
Chapter 6. Installation and Booting GRE network interfaces now start correctly A change introduced in the release of Red Hat Enterprise Linux 6 introduced a bug which in some cases caused initscripts to fail to correctly start Generic Routing Encapsulation (GRE) network interfaces. This update provides a fix to initscripts that ensures GRE interfaces start as expected. (BZ# 1436061 ) KSH no longer fails to process /etc/init.d/functions The Korn Shell (*KSH*) is unable to process code where the word local appears on the same line as an array definition. This previously caused KSH to fail to source the /etc/init.d/functions file. This update provides a workaround to the KSH limitation, and the function file is now being sourced as expected. Note that KSH may still be unable use some of the functions in /etc/init.d/functions file. This update only allows KSH to not fail during the sourcing of /etc/init.d/functions . (BZ# 1518429 )

Commands:
1.5.3. Economy and Performance Figure 1.14, "GFS and GNBD with Directly Connected Storage" shows how Linux client applications can take advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data files and file systems can be shared with GFS on each client. Application failover can be fully automated with Red Hat Cluster Suite. Figure 1.14. GFS and GNBD with Directly Connected Storage

Commands:
Chapter 7. Migration from versions of .NET 7.1. Migration from versions of .NET Microsoft provides instructions for migrating from most versions of .NET Core. If you are using a version of .NET that is no longer supported or want to migrate to a newer .NET version to expand functionality, see the following articles: Migrate from ASP.NET Core 5.0 to 6.0 Migrate from ASP.NET Core 3.1 to 5.0 Migrate from ASP.NET Core 3.0 to 3.1 Migrate from ASP.NET Core 2.2 to 3.0 Migrate from ASP.NET Core 2.1 to 2.2 Migrate from .NET Core 2.0 to 2.1 Migrate from ASP.NET to ASP.NET Core Migrating .NET Core projects from project.json Migrate from project.json to .csproj format Note If migrating from .NET Core 1.x to 2.0, see the first few related sections in Migrate from ASP.NET Core 1.x to 2.0 . These sections provide guidance that is appropriate for a .NET Core 1.x to 2.0 migration path. 7.2. Porting from .NET Framework Refer to the following Microsoft articles when migrating from .NET Framework: For general guidelines, see Porting to .NET Core from .NET Framework . For porting libraries, see Porting to .NET Core - Libraries . For migrating to ASP.NET Core, see Migrating to ASP.NET Core . Several technologies and APIs present in the .NET Framework are not available in .NET Core and .NET. If your application or library requires these APIs, consider finding alternatives or continue using the .NET Framework. .NET Core and .NET do not support the following technologies and APIs: Desktop applications, for example, Windows Forms and Windows Presentation Foundation (WPF) Windows Communication Foundation (WCF) servers (WCF clients are supported) .NET remoting Additionally, several .NET APIs can only be used in Microsoft Windows environments. The following list shows examples of these Windows-specific APIs: Microsoft.Win32.Registry System.AppDomains System.Drawing System.Security.Principal.Windows Important Several APIs that are not supported in the default version of .NET may be available from the Microsoft.Windows.Compatibility NuGet package. Be careful when using this NuGet package. Some of the APIs provided (such as Microsoft.Win32.Registry ) only work on Windows, making your application incompatible with Red Hat Enterprise Linux.

Commands:
Virtualization Getting Started Guide Red Hat Enterprise Linux 7 Introduction to virtualization technologies available with RHEL Jiri Herrmann Red Hat Customer Content Services jherrman@redhat.com Yehuda Zimmerman Red Hat Customer Content Services yzimmerm@redhat.com Dayle Parker Red Hat Customer Content Services Laura Novich Red Hat Customer Content Services Jacquelynn East Red Hat Customer Content Services Scott Radvan Red Hat Customer Content Services

Commands:
Chapter 4. Downloading Red Hat build of OpenJDK 11.0.26 Red Hat provides extended lifecycle support phase 1 (ELS‐1) support for Red Hat build of OpenJDK 11.0.26. For more information, see Red Hat build of OpenJDK 11 - Extended Lifecycle Support Phase 1 . Access to ELS requires an OpenJDK ELS subscription. For information about downloading Windows or Portable Linux distributions of Red Hat build of OpenJDK 11.0.26, see https://access.redhat.com/downloads/content/975/ .

Commands: