mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Red Hat build of OpenJDK MSI installer components (Optional) Set the following Red Hat build of OpenJDK 11 for Microsoft Windows MSI-based installer components: jdk Java Development Kit (JDK) files. jdk-registry-standard Registry keys: jdk_env_path Appends <INSTALLDIR>\bin to the system %PATH% environment variable. jdk_env_java_home Sets <INSTALLDIR> to the system %JAVA_HOME% environment variable. jdk_env_vendor_java_home Sets <INSTALLDIR> to the system %REDHAT_JAVA_HOME% environment variable. jdk_registry_jar Association for JAR files. Launch JAR files with the Red Hat build of OpenJDK context menu. jmc JDK Mission Control files, installed into <INSTALLDIR>\missioncontrol . jmc_env Appends <INSTALLDIR>\missioncontrol to the system %PATH% environment variable.

Commands:
HKLM\Software\JavaSoft\JDK\<version>, entries: JavaHome: <INSTALLDIR> RuntimeLib: <INSTALLDIR>\bin\server\jvm.dll HKLM\Software\JavaSoft\JDK, entries: CurrentVersion: <version>
Chapter 18. Installing Using Anaconda This chapter provides step-by-step instructions for installing Red Hat Enterprise Linux using the Anaconda installer. The bulk of this chapter describes installation using the graphical user interface; on IBM Z, the graphical interface is accessed over the VNC protocol from another system. A text mode is also available for systems with no graphical display, but this mode is limited in certain aspects (for example, custom partitioning is not possible in text mode). If you cannot use VNC mode with a graphical interface, consider using Kickstart to automate the installation. See Chapter 27, Kickstart Installations for information about Kickstart. 18.1. Introduction to Anaconda The Red Hat Enterprise Linux installer, Anaconda , is different from most other operating system installation programs due to its parallel nature. Most installers follow a fixed path: you must choose your language first, then you configure network, then installation type, then partitioning, and so on. There is usually only one way to proceed at any given time. In Anaconda you are only required to select your language and locale first, and then you are presented with a central screen, where you can configure most aspects of the installation in any order you like. This does not apply to all parts of the installation process, however - for example, when installing from a network location, you must configure the network before you can select which packages to install. Some screens will be automatically configured depending on your hardware and the type of media you used to start the installation. You can still change the detected settings in any screen. Screens which have not been automatically configured, and therefore require your attention before you begin the installation, are marked by an exclamation mark. You cannot start the actual installation process before you finish configuring these settings. Additional differences appear in certain screens; notably the custom partitioning process is very different from other Linux distributions. These differences are described in each screen's subsection.

Commands:
21.3.8. Selecting the Printer Model and Finishing Once you have properly selected a printer connection type, the system attempts to acquire a driver. If the process fails, you can locate or search for the driver resources manually. Follow this procedure to provide the printer driver and finish the installation: In the window displayed after the automatic driver detection has failed, select one of the following options: Select a Printer from database - the system chooses a driver based on the selected make of your printer from the list of Makes . If your printer model is not listed, choose Generic . Provide PPD file - the system uses the provided PostScript Printer Description (PPD) file for installation. A PPD file may also be delivered with your printer as being normally provided by the manufacturer. If the PPD file is available, you can choose this option and use the browser bar below the option description to select the PPD file. Search for a printer driver to download - enter the make and model of your printer into the Make and model field to search on OpenPrinting.org for the appropriate packages. Figure 21.9. Selecting a printer brand Depending on your choice provide details in the area displayed below: Printer brand for the Select printer from database option. PPD file location for the Provide PPD file option. Printer make and model for the Search for a printer driver to download option. Click Forward to continue. If applicable for your option, window shown in Figure 21.10, "Selecting a printer model" appears. Choose the corresponding model in the Models column on the left. Note On the right, the recommended printer driver is automatically selected; however, you can select another available driver. The print driver processes the data that you want to print into a format the printer can understand. Since a local printer is attached directly to your computer, you need a printer driver to process the data that is sent to the printer. Figure 21.10. Selecting a printer model Click Forward . Under the Describe Printer enter a unique name for the printer in the Printer Name field. The printer name can contain letters, numbers, dashes (-), and underscores (_); it must not contain any spaces. You can also use the Description and Location fields to add further printer information. Both fields are optional, and may contain spaces. Figure 21.11. Printer setup Click Apply to confirm your printer configuration and add the print queue if the settings are correct. Click Back to modify the printer configuration. After the changes are applied, a dialog box appears allowing you to print a test page. Click Yes to print a test page now. Alternatively, you can print a test page later as described in Section 21.3.9, "Printing a Test Page" .

Commands:
4.84. guile 4.84.1. RHBA-2011:0855 - guile bug fix update An updated guile package that fixes one bug is now available for Red Hat Enterprise Linux 6. GUILE (GNU's Ubiquitous Intelligent Language for Extension) is a library implementation of the Scheme programming language, written in C. GUILE provides a machine-independent execution platform that can be linked in as a library during the building of extensible programs. Bug Fix BZ# 659674 Due to a problem in the build test suite, the guile package failed to build. The problem has been resolved in this update so that the guile package now builds properly. All users of guile are advised to upgrade to this updated package, which fixes this bug.

Commands:
2.7. Firewall Configuration The Firewall Configuration window is similar to the screen in the installation program and the Security Level Configuration Tool . Figure 2.10. Firewall Configuration If Disable firewall is selected, the system allows complete access to any active services and ports. No connections to the system are refused or denied. Selecting Enable firewall configures the system to reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is required, you can choose to allow specific services through the firewall. Only devices configured in the Network Configuration section are listed as available Trusted devices . Connections from any devices selected in the list are accepted by the system. For example, if eth1 only receives connections from internal system, you might want to allow connections from it. If a service is selected in the Trusted services list, connections for the service are accepted and processed by the system. In the Other ports text field, list any additional ports that should be opened for remote access. Use the following format: port:protocol . For example, to allow IMAP access through the firewall, specify imap:tcp . Specify numeric ports can also be specified; to allow UDP packets on port 1234 through the firewall, enter 1234:udp . To specify multiple ports, separate them with commas. 2.7.1. SELinux Configuration Although configuration for SELinux is not specified in the Kickstart Configurator , kickstart enables SELinux in enforcing mode by default if the selinux parameter is omitted from the kickstart file.

Commands:
Chapter 2. Quay.io support Technical support is a crucial aspect of the Quay.io container registry service, providing assistance not only in managing container images but also ensuring the functionality and availability of the hosted platform. To help users with functionality-related issues, Red Hat offers Quay.io customers access to several resources. The Red Hat Knowledgebase contains valuable content to maximize the potential of Red Hat's products and technologies. Users can find articles, product documentation, and videos that outline best practices for installing, configuring, and utilizing Red Hat products. It also serves as a hub for solutions to known issues, providing concise root cause descriptions and remedial steps. Additionally, Quay.io customers can count on the technical support team to address questions, troubleshoot problems, and provide solutions for an optimized experience with the platform. Whether it involves understanding specific features, customizing configurations, or resolving container image build issues, the support team is dedicated to guiding users through each step with clarity and expertise. For incidents related to service disruptions or performance issues not listed on the Quay.io status page , which includes availability and functionality concerns, paying customers can raise a technical support ticket using the Red Hat Customer Portal . A service incident is defined as an unplanned interruption of service or reduction in service quality, affecting multiple users of the platform. With this comprehensive technical support system in place, Quay.io ensures that users can confidently manage their container images, optimize their platform experience, and overcome any challenges that might arise. Additional resources Current Red Hat Quay and Quay.io users can find more information about troubleshooting and support in the Red Hat Quay Troubleshooting guide .

Commands:
Chapter 1. Debezium Overview Debezium for Red Hat Integration is a distributed platform that captures database operations, creates data change event records for row-level operations, and streams change event records to Apache Kafka topics. Debezium is built on Apache Kafka and is deployed and integrated with AMQ Streams. Debezium captures row-level changes to a database table and passes corresponding change events to AMQ Streams. Applications can read these change event streams and access the change events in the order in which they occurred. Debezium is the upstream community project for Debezium for Red Hat Integration. Debezium has multiple uses, including: Data replication Updating caches and search indexes Simplifying monolithic applications Data integration Enabling streaming queries Debezium provides Apache Kafka Connect connectors for the following common databases: Db2 MySQL MongoDB Oracle PostgreSQL SQL Server

Commands:
Chapter 2. Preparing a RHEL 6 system for an upgrade to RHEL 7 To prepare your RHEL 6 system for an in-place upgrade to RHEL 7, perform the following steps: Back up the RHEL 6 system, and ensure that the backup is recoverable. For details about creating backups in your environment, see the documentation of your backup software. The following list provides additional resources about backup and recovery: What is Relax and Recover(ReaR) and how can I use it for disaster recovery? (Red Hat Knowledgebase) If the system to upgrade runs in a VM, consider VM snapshots. For details about VM snapshots, see the documentation of your virtualizor. For details about LVM snapshots, see Snapshot logical volumes Relax-and-Recover (ReaR) Update the RHEL 6 system to RHEL 6.10, and reboot the host: Enable the RHEL 6 Extras repository, and install the utilities required for the in-place upgrade to RHEL 7. For details, see the Preparing a RHEL 6 system for the upgrade section in the Upgrading from RHEL 6 to RHEL 7 documentation.

Commands:
yum update reboot
Chapter 6. Networking bind now contains new root zone KSK Because of the DNS Security Extensions (DNSSEC) Key Signing Key (KSK) rollover in October 2017, a new key tag has been added to the bind package with an updated root server and a trust anchor. Having an up-to-date KSK is essential for ensuring that validating DNS resolvers continue to function correctly following the rollover. (BZ#1452639) The iptables-services package now support /etc/sysctl.d With this update, the init scripts of the iptables or ip6tables services now recognize the configuration files in the /etc/sysctl.d directory as well as the /etc/sysctl.conf file itself. As a result, the user-provided sysctl settings stored in /etc/sysctl.d/ are now correctly taken into account when the iptables service is restarted. (BZ# 1459673 )

Commands:
3.2. Data in Motion Data in motion is data that is being transmitted over a network. The biggest threats to data in motion are interception and alteration. Your user name and password should never be transmitted over a network without protection as it could be intercepted and used by someone else to impersonate you or gain access to sensitive information. Encrypting the network session ensures a higher security level for data in motion. Data in motion is particularly vulnerable to attackers because the attacker does not have to be near the computer in which the data is being stored rather they only have to be somewhere along the path. Encryption tunnels can protect data along the path of communications. 3.2.1. Virtual Private Networks Virtual Private Networks (VPN) provide encrypted tunnels between computers or networks of computers across all ports. With a VPN in place, all network traffic from the client is forwarded to the server through the encrypted tunnel. This means that the client is logically on the same network as the server it is connected to via the VPN. VPNs are very common and are simple to use and setup.

Commands:
Chapter 1. Overview Red Hat OpenShift Data Foundation is software-defined storage that is optimized for container environments. It runs as an operator on OpenShift Container Platform to provide highly integrated and simplified persistent storage management for containers. Red Hat OpenShift Data Foundation is integrated into the latest Red Hat OpenShift Container Platform to address platform services, application portability, and persistence challenges.It provides a highly scalable backend for the generation of cloud-native applications, built on a technology stack that includes Red Hat Ceph Storage, the Rook.io Operator, and NooBaa's Multicloud Object Gateway technology. Red Hat OpenShift Data Foundation is designed for FIPS. When running on RHEL or RHEL CoreOS booted in FIPS mode, OpenShift Container Platform core components use the RHEL cryptographic libraries submitted to NIST for FIPS Validation on only the x86_64, ppc64le, and s390X architectures. For more information about the NIST validation program, see Cryptographic Module Validation Program . For the latest NIST status for the individual versions of the RHEL cryptographic libraries submitted for validation, see Compliance Activities and Government Standards . Red Hat OpenShift Data Foundation provides a trusted, enterprise-grade application development environment that simplifies and enhances the user experience across the application lifecycle in a number of ways: Provides block storage for databases. Shared file storage for continuous integration, messaging, and data aggregation. Object storage for cloud-first development, archival, backup, and media storage. Scale applications and data exponentially. Attach and detach persistent data volumes at an accelerated rate. Stretch clusters across multiple data-centers or availability zones. Establish a comprehensive application container registry. Support the generation of OpenShift workloads such as Data Analytics, Artificial Intelligence, Machine Learning, Deep Learning, and Internet of Things (IoT). Dynamically provision not only application containers, but data service volumes and containers, as well as additional OpenShift Container Platform nodes, Elastic Block Store (EBS) volumes and other infrastructure services. 1.1. About this release Red Hat OpenShift Data Foundation 4.15 ( RHSA-2024:1383 ) is now available. New enhancements, features, and known issues that pertain to OpenShift Data Foundation 4.15 are included in this topic. Red Hat OpenShift Data Foundation 4.15 is supported on the Red Hat OpenShift Container Platform version 4.15. For more information, see Red Hat OpenShift Data Foundation Supportability and Interoperability Checker . For Red Hat OpenShift Data Foundation life cycle information, refer to the layered and dependent products life cycle section in Red Hat OpenShift Container Platform Life Cycle Policy .

Commands:
Preface Welcome to the Red Hat JBoss Core Services version 2.4.57 Service Pack 3 release. Red Hat JBoss Core Services Apache HTTP Server is an open source web server developed by the Apache Software Foundation . The Apache HTTP Server includes the following features: Implements the current HTTP standards, including HTTP/1.1 and HTTP/2 Supports Transport Layer Security (TLS) encryption through OpenSSL , which provides secure connections between the web server and web clients Supports extensible functionality through the use of modules, some of which are included with the Red Hat JBoss Core Services Apache HTTP Server

Commands:
Chapter 13. In-place upgrades Starting with Red Hat OpenStack Platform (RHOSP) 16.1.1, the Framework for Upgrades (FFU) is utilized in a new In-place Upgrades test. This test is available during RHOSP plugin certification. It verifies the functionality of plugins to perform as expected during and after automated upgrades between long life releases of RHOSP. Successfully completing this test will add the corresponding feature to the Ecosystem Catalog entry for the certification. Example The "In-place upgrades from RHOSP 13 (Queens)" feature would appear as a line item in a RHOSP 16.1.x (Train) certification. The in_place_upgrades test is available for all plugin types for which certification is available. It will appear on the certification test plan, and is only planned and executed on the Controller node. This feature and thus the test requires that your plugin be installed, managed, and upgradable via the RHOSP Director toolset. It is run after the upgrade is performed on the controller node and will introspect various log files in the upgraded environment to verify the upgrade conducted and was successful. The In-place upgrades test includes the following subtests: in_place_upgrades This test validates that a RHOSP cloud has been upgraded from one RHOSP long life release to the RHOSP long life release using the RHOSP Framework for Upgrades mechanism. And then prompts you to confirm the same. Success criteria PASS: If the system is upgraded successfully and then you certify the same. FAIL: If the system was not upgraded or you do not certify the same. Director Plugin Verification A self declaration prompt is added for you to declare if your plugin installation has been done with the director. Success criteria PASS: If you certify that the plugin installation is done with the director. FAIL: If you certify that the plugin installation is not done with the director. Success criteria The status of the In-place Upgrades test depends as follows: PASS: If both the subtests, in_place_upgrades and Director Plugin Verification pass. FAIL: If both or either subtest, in_place_upgrades and Director Plugin Verification fails.

Commands:
14.3.2.2. Windows NT4-based Domain Member Server The following smb.conf file shows a sample configuration needed to implement a Windows NT4-based domain member server. Becoming a member server of an NT4-based domain is similar to connecting to an Active Directory. The main difference is NT4-based domains do not use Kerberos in their authentication method, making the smb.conf file simpler. In this instance, the Samba member server serves as a pass through to the NT4-based domain server. Having Samba as a domain member server can be useful in many situations. There are times where the Samba server can have other uses besides file and printer sharing. It may be beneficial to make Samba a domain member server in instances where Linux-only applications are required for use in the domain environment. Administrators appreciate keeping track of all machines in the domain, even if not Windows-based. In the event the Windows-based server hardware is deprecated, it is quite easy to modify the smb.conf file to convert the server to a Samba-based PDC. If Windows NT-based servers are upgraded to Windows 2000/2003, the smb.conf file is easily modifiable to incorporate the infrastructure change to Active Directory if needed. Important After configuring the smb.conf file, join the domain before starting Samba by typing the following command as root: Note that the -S option, which specifies the domain server hostname, does not need to be stated in the net rpc join command. Samba uses the hostname specified by the workgroup directive in the smb.conf file instead of it being stated explicitly.

Commands:
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes
net rpc join -U administrator%password
Chapter 42. KIE Server KIE Server is the server where the rules and other artifacts for Red Hat Process Automation Manager are stored and run. KIE Server is a standalone built-in component that can be used to instantiate and execute rules through interfaces available for REST, Java Message Service (JMS), or Java client-side applications, and Red Hat build of OptaPlanner functionality through solvers. Created as a web deployable WAR file, KIE Server can be deployed on any web container. The current version of KIE Server is included with default extensions for both Red Hat Decision Manager and Red Hat Process Automation Manager. KIE Server has a low footprint with minimal memory consumption and therefore can be deployed easily on a cloud instance. Each instance of this server can open and instantiate multiple containers, which enables you to execute multiple rule services in parallel. KIE Server can be integrated with other application servers, such as Oracle WebLogic Server or IBM WebSphere Application Server, to streamline Red Hat Process Automation Manager application management.

Commands: