mtpti5iD/redhat-docs_dataset huggingface dataset:
3.3. Kernel Address Space Randomization Red Hat Enterprise Linux 7.5 and later include the Kernel Address Space Randomization (KASLR) feature for KVM guest virtual machines. KASLR enables randomizing the physical and virtual address at which the kernel image is decompressed, and thus prevents guest security exploits based on the location of kernel objects. KASLR is activated by default, but can be deactivated on a specific guest by adding the nokaslr string to the guest's kernel command line. To edit the guest boot options, use the following command, where guestname is the name of your guest: Afterwards, modify the GRUB_CMDLINE_LINUX line, for example: Important Guest dump files created from guests that have with KASLR activated are not readable by the crash utility. To fix this, add the <vmcoreinfo/> element to the <features> section of the XML configuration files of your guests. Note, however, that migrating guests with <vmcoreinfo/> fails if the destination host is using an OS that does not support <vmcoreinfo/> . These include Red Hat Enterprise Linux 7.4 and earlier, as well as Red Hat Enterprise Linux 6.9 and earlier.

Commands:
virt-edit -d guestname /etc/default/grub
GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet nokaslr"
Chapter 12. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 12.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 12.2. Expanding the node port range You can expand the node port range for the cluster. Important You can expand the node port range into the protected port range, which is between 0 and 32767. However, after expansion, you cannot change the range. Attempting to change the range returns the following error: The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the range 0-32767 . Before making changes, ensure that the new range you set is appropriate for your cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 12.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]
Chapter 10. Connecting to an instance You can access an instance from a location external to the cloud by using a remote shell such as SSH or WinRM, when you have allowed the protocol in the instance security group rules. You can also connect directly to the console of an instance, so that you can debug even if the network connection fails. Note If you did not provide a key pair to the instance, or allocate a security group to the instance, you can access the instance only from inside the cloud by using VNC. You cannot ping the instance. 10.1. Accessing an instance console You can connect directly to the VNC console for an instance by entering the VNC console URL in a browser. Procedure To display the VNC console URL for an instance, enter the following command: To connect directly to the VNC console, enter the displayed URL in a browser. 10.2. Logging in to an instance You can log in to public instances remotely. Prerequisites You have the key pair certificate for the instance. The certificate is downloaded when the key pair is created. If you did not create the key pair yourself, ask your administrator. The instance is configured as a public instance. For more information on the requirements of a public instance, see Providing public access to an instance . You have a cloud user account. Procedure Retrieve the floating IP address of the instance you want to log in to: Replace <instance> with the name or ID of the instance that you want to connect to. Use the automatically created cloud-user account to log in to your instance: Replace <keypair> with the name of the key pair. Replace <floating_ip> with the floating IP address of the instance. Tip You can use the following command to log in to an instance without the floating IP address: Replace <keypair> with the name of the key pair. Replace <instance> with the name or ID of the instance that you want to connect to.

Commands:
openstack console url show <vm_name> +-------+------------------------------------------------------+ | Field | Value | +-------+------------------------------------------------------+ | type | novnc | | url | http://172.25.250.50:6080/vnc_auto.html?token= | | | 962dfd71-f047-43d3-89a5-13cb88261eb9 | +-------+-------------------------------------------------------+
openstack server show <instance>
ssh -i ~/.ssh/<keypair>.pem cloud-user@<floatingIP> [cloud-user@demo-server1 ~]USD
openstack server ssh --login cloud-user --identity ~/.ssh/<keypair>.pem --private <instance>
Chapter 3. Deploying Kafka components using the AMQ Streams operator When installed on Openshift, the AMQ Streams operator makes Kafka components available for installation from the user interface. The following Kafka components are available for installation: Kafka Kafka Connect Kafka MirrorMaker Kafka MirrorMaker 2 Kafka Topic Kafka User Kafka Bridge Kafka Connector Kafka Rebalance You select the component and create an instance. As a minimum, you create a Kafka instance. This procedure describes how to create a Kafka instance using the default settings. You can configure the default installation specification before you perform the installation. The process is the same for creating instances of other Kafka components. Prerequisites The AMQ Streams operator is installed on the OpenShift cluster . Procedure Navigate in the web console to the Operators > Installed Operators page and click AMQ Streams to display the operator details. From Provided APIs , you can create instances of Kafka components. Click Create instance under Kafka to create a Kafka instance. By default, you'll create a Kafka cluster called my-cluster with three Kafka broker nodes and three ZooKeeper nodes. The cluster uses ephemeral storage. Click Create to start the installation of Kafka. Wait until the status changes to Ready .

Commands:
3.3. Defining Key Defaults in Profiles When creating certificate profiles, the Key Default must be added before the Subject Key Identifier Default . Certificate System processes the key constraints in the Key Default before creating or applying the Subject Key Identifier Default, so if the key has not been processed yet, setting the key in the subject name fails. For example, an object-signing profile may define both defaults: In the policyset list, then, the Key Default ( p11 ) must be listed before the Subject Key Identifier Default ( p3 ).

Commands:
policyset.set1.p3.constraint.class_id=noConstraintImpl policyset.set1.p3.constraint.name=No Constraint policyset.set1.p3.default.class_id=subjectKeyIdentifierExtDefaultImpl policyset.set1.p3.default.name=Subject Key Identifier Default policyset.set1.p11.constraint.class_id=keyConstraintImpl policyset.set1.p11.constraint.name=Key Constraint policyset.set1.p11.constraint.params.keyType=RSA policyset.set1.p11.constraint.params.keyParameters=1024,2048,3072,4096 policyset.set1.p11.default.class_id=userKeyDefaultImpl policyset.set1.p11.default.name=Key Default
policyset.set1.list=p1,p2, p11,p3 ,p4,p5,p6,p7,p8,p9,p10
2.9. Additional Resources This chapter is only intended as an introduction to GRUB. Consult the following resources to discover more about how GRUB works. 2.9.1. Installed Documentation /usr/share/doc/grub- <version-number> / - This directory contains good information about using and configuring GRUB, where <version-number> corresponds to the version of the GRUB package installed. info grub - The GRUB info page contains a tutorial, a user reference manual, a programmer reference manual, and a FAQ document about GRUB and its usage.

Commands:
14.6. The (Non-Transactional) CarMart Quickstart in Remote Client-Server Mode (JBoss Enterprise Web Server) The Carmart (non-transactional) quickstart is supported for JBoss Data Grid's Remote Client-Server Mode with the JBoss Enterprise Web Server container. Report a bug 14.6.1. Build and Deploy the CarMart Quickstart in Remote Client-Server Mode This quickstart accesses Red Hat JBoss Data Grid via Hot Rod. This feature is not available for the Transactional CarMart quickstart. Important This quickstart deploys to JBoss Enterprise Web Server or Tomcat. The application cannot be deployed to JBoss Data Grid because it does not support application deployment. Prerequisites Prerequisites for this procedure are as follows: Obtain the most recent supported JBoss Data Grid Remote Client-Server Mode distribution files from Red Hat . Ensure that the JBoss Data Grid and JBoss Enterprise Application Platform Maven repositories are installed and configured. For details, see Chapter 3, Install and Use the Maven Repositories Add a server element to the Maven settings.xml file. In the id elements within server , add the appropriate tomcat credentials. Procedure 14.10. Build and Deploy the CarMart Quickstart in Remote Client-Server Mode Configure the Standalone File Add the following configuration to the standalone.xml file located in the USDJDG_HOME/standalone/configuration/ directory. Add the following configuration within the infinispan subsystem tags: Note If the carcache element already exists in your configuration, replace it with the provided configuration. Start the Container Start the JBoss server instance where your application will deploy. For Linux: For Windows: Build the Application Use the following command to build your application in the relevant directory: Deploy the Application Use the following command to deploy the application in the relevant directory: Report a bug 14.6.2. View the CarMart Quickstart in Remote Client-Server Mode The following procedure outlines how to view the CarMart quickstart in Red Hat JBoss Data Grid's Remote Client-Server Mode: Prerequisite The CarMart quickstart must be built and deployed be viewed. Procedure 14.11. View the CarMart Quickstart in Remote Client-Server Mode Visit the following link in a browser window to view the application: Report a bug 14.6.3. Remove the CarMart Quickstart in Remote Client-Server Mode The following procedure provides directions to remove an already deployed application in Red Hat JBoss Data Grid's Remote Client-Server mode. Procedure 14.12. Remove an Application in Remote Client-Server Mode To remove an application, use the following command from the root directory of this quickstart: Report a bug

Commands:
<server> <id>tomcat</id> <username>admin</username> <password>admin</password> </server>
<local-cache name="carcache" start="EAGER" batching="false" statistics="true"> <eviction strategy="LIRS" max-entries="4"/> </local-cache>
USDJBOSS_EWS_HOME/tomcat7/bin/catalina.sh run
USDJBOSS_EWS_HOME\tomcat7\bin\catalina.bat run
mvn clean package -Premote-tomcat
mvn tomcat:deploy -Premote-tomcat
http://localhost:8080/jboss-carmart
mvn tomcat:undeploy -Premote-tomcat
2.2.6. Securing FTP The File Transfer Protocol ( FTP ) is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured. Red Hat Enterprise Linux provides three FTP servers. gssftpd - A Kerberos-aware xinetd -based FTP daemon that does not transmit authentication information over the network. Red Hat Content Accelerator ( tux ) - A kernel-space Web server with FTP capabilities. vsftpd - A standalone, security oriented implementation of the FTP service. The following security guidelines are for setting up the vsftpd FTP service. 2.2.6.1. FTP Greeting Banner Before submitting a user name and password, all users are presented with a greeting banner. By default, this banner includes version information useful to attackers trying to identify weaknesses in a system. To change the greeting banner for vsftpd , add the following directive to the /etc/vsftpd/vsftpd.conf file: Replace <insert_greeting_here> in the above directive with the text of the greeting message. For mutli-line banners, it is best to use a banner file. To simplify management of multiple banners, place all banners in a new directory called /etc/banners/ . The banner file for FTP connections in this example is /etc/banners/ftp.msg . Below is an example of what such a file may look like: Note It is not necessary to begin each line of the file with 220 as specified in Section 2.2.1.1.1, "TCP Wrappers and Connection Banners" . To reference this greeting banner file for vsftpd , add the following directive to the /etc/vsftpd/vsftpd.conf file: It also is possible to send additional banners to incoming connections using TCP Wrappers as described in Section 2.2.1.1.1, "TCP Wrappers and Connection Banners" .

Commands:
ftpd_banner= <insert_greeting_here>
######### Hello, all activity on ftp.example.com is logged. #########
banner_file=/etc/banners/ftp.msg
4.68. gcc 4.68.1. RHBA-2011:1644 - gcc bug fix and enhancement update Updated gcc packages that fix various bugs and add three enhancements are now available for Red Hat Enterprise Linux 6. The gcc packages include C, C++, Java, Fortran, Objective C, Objective C++, and Ada 95 GNU compilers, along with related support libraries. Bug Fixes BZ# 696352 The version of GCC incorrectly assumed that processors based on the AMD's multi-core architecture code named Bulldozer support the 3DNow! instruction set. This update adapts the underlying source code to make sure that GCC no longer uses the 3DNow! instructions on these processors. BZ# 705764 On the PowerPC architecture, GCC previously passed the V2DImode vector parameters using the stack and returned them in integer registers, which does not comply with the Application Binary Interface (ABI). This update corrects this error so that GCC now passes these parameters using the AltiVec parameter registers and returns them via the AltiVec return value register. BZ# 721376 Previously, GCC did not flush all pending register saves in a Frame Description Entry (FDE) before inline assembly instructions. This may have led to various problems when the inline assembly code modified those registers. With this update, GCC has been adapted to flush pending register saves in FDE before inline assembly instructions, resolving this issue. BZ# 732802 Prior to this update, the gcov test coverage utility sometimes incorrectly counted even opening brackets, which caused it to produce inaccurate statistics. This update applies a patch that corrects this error so that gcov ignores such brackets, as expected. BZ# 732807 When processing source code that extensively used overloading (that is, with hundreds or more overloads of the same function or method), the version of the C++ front end consumed a large amount of memory. This negatively affected the overall compile time and the amount of used system resources. With this update, the C++ front end has been optimized to use less resources in this scenario. Enhancements BZ# 696145 This update adds support for new "-mfsgsbase", "-mf16c", and "-mrdrnd" command line options, as well as corresponding intrinsics to the immintrin.h header file. This allows for reading FS and GS base registers, retrieving random data from the random data generator, and converting between floating point and half-precision floating-point types. BZ# 696370 GCC now supports AMD's generation processors. These processors can now be specified on the command line via the "-march=" and "-mtune=" command line options. BZ# 696495 GCC now supports Intel's generation processor instrinsics and instructions for reading the hardware random number generator. All users of gcc are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
4.332. udisks 4.332.1. RHBA-2011:1764 - udisks bug fix update An updated udisks package that fixes one bug is now available for Red Hat Enterprise Linux 6. The udisks daemon provides interfaces to obtain information and perform operations on storage devices. Bug Fix BZ# 738479 Prior to this update, the redundant udev watch rule interfered with the Logical Volume Manager (LVM) which could cause problems under certain workloads. This update removes this udev rule and udisks no longer interferes with LVM. All users of udisks are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 1. Support policy for Eclipse Temurin Red Hat will support select major versions of Eclipse Temurin in its products. For consistency, these versions remain similar to Oracle JDK versions that Oracle designates as long-term support (LTS). A major version of Eclipse Temurin will be supported for a minimum of six years from the time that version is first introduced. For more information, see the Eclipse Temurin Life Cycle and Support Policy . Note RHEL 6 reached the end of life in November 2020. Because of this, Eclipse Temurin does not support RHEL 6 as a supported configuration.

Commands:
2.3.4. Inherently Insecure Services Even the most vigilant organization can fall victim to vulnerabilities if the network services they choose are inherently insecure. For instance, there are many services developed under the assumption that they are used over trusted networks; however, this assumption fails as soon as the service becomes available over the Internet - which is itself inherently untrusted. One category of insecure network services are those that require unencrypted usernames and passwords for authentication. Telnet and FTP are two such services. If packet sniffing software is monitoring traffic between the remote user and such a service usernames and passwords can be easily intercepted. Inherently, such services can also more easily fall prey to what the security industry terms the man-in-the-middle attack. In this type of attack, a cracker redirects network traffic by tricking a cracked name server on the network to point to his machine instead of the intended server. Once someone opens a remote session to the server, the attacker's machine acts as an invisible conduit, sitting quietly between the remote service and the unsuspecting user capturing information. In this way a cracker can gather administrative passwords and raw data without the server or the user realizing it. Another category of insecure services include network file systems and information services such as NFS or NIS, which are developed explicitly for LAN usage but are, unfortunately, extended to include WANs (for remote users). NFS does not, by default, have any authentication or security mechanisms configured to prevent a cracker from mounting the NFS share and accessing anything contained therein. NIS, as well, has vital information that must be known by every computer on a network, including passwords and file permissions, within a plain text ACSII or DBM (ASCII-derived) database. A cracker who gains access to this database can then access every user account on a network, including the administrator's account. By default, Red Hat Enterprise Linux is released with all such services turned off. However, since administrators often find themselves forced to use these services, careful configuration is critical. Refer to Chapter 5, Server Security for more information about setting up services in a safe manner.

Commands:
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Do let us know how we can make it better. To give feedback, create a Jira ticket: Log in to the Jira . Click Create in the top navigation bar Enter a descriptive title in the Summary field. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation. Select Documentation in the Components field. Click Create at the bottom of the dialogue.

Commands:
Chapter 1. Introduction Past versions of Red Hat OpenStack Platform used services managed with Systemd. However, more recent version of OpenStack Platform now use containers to run services. Some administrators might not have a good understanding of how containerized OpenStack Platform services operate, and so this guide aims to help you understand OpenStack Platform container images and containerized services. This includes: How to obtain and modify container images How to manage containerized services in the overcloud Understanding how containers differ from Systemd services The main goal is to help you gain enough knowledge of containerized OpenStack Platform services to transition from a Systemd-based environment to a container-based environment. 1.1. Containerized services and Kolla Each of the main Red Hat OpenStack Platform (RHOSP) services run in containers. This provides a method to keep each service within its own isolated namespace separated from the host. This has the following effects: During deployment, RHOSP pulls and runs container images from the Red Hat Customer Portal. The podman command operates management functions, like starting and stopping services. To upgrade containers, you must pull new container images and replace the existing containers with newer versions. Red Hat OpenStack Platform uses a set of containers built and managed with the Kolla toolset.

Commands:
1.3. Cluster Infrastructure The High Availability Add-On cluster infrastructure provides the basic functions for a group of computers (called nodes or members ) to work together as a cluster. Once a cluster is formed using the cluster infrastructure, you can use other components to suit your clustering needs (for example, setting up a cluster for sharing files on a GFS2 file system or setting up service failover). The cluster infrastructure performs the following functions: Cluster management Lock management Fencing Cluster configuration management

Commands: