mtpti5iD/redhat-docs_dataset huggingface dataset:
7.2. The Boot Menu Once your system has completed loading the boot media, a boot menu is displayed using GRUB2 ( GRand Unified Bootloader , version 2). The boot menu provides several options in addition to launching the installation program. If no key is pressed within 60 seconds, the default boot option (the one highlighted in white) will be run. To choose the default, either wait for the timer to run out or press Enter . Figure 7.1. The Boot Screen To select a different option than the default, use the arrow keys on your keyboard, and press Enter when the correct option is highlighted. To customize the boot options for a particular menu entry: On BIOS-based systems, the preferred way is to press the Tab key and add custom boot options to the command line. You can also access the boot: prompt by pressing the Esc key but no required boot options will be preset in it. In that case, you must always specify the linux option before using any other boot options. On UEFI-based systems, press the e key and add custom boot options to the command line. When ready press Ctrl + X to boot the modified option. See Chapter 23, Boot Options for more information about additional boot options. The boot menu options are: Install Red Hat Enterprise Linux 7.0 Choose this option to install Red Hat Enterprise Linux onto your computer system using the graphical installation program. Test this media & install Red Hat Enterprise Linux 7.0 This option is the default. Prior to starting the installation program, a utility is launched to check the integrity of the installation media. Troubleshooting > This item is a separate menu containing options that help resolve various installation issues. When highlighted, press Enter to display its contents. Figure 7.2. The Troubleshooting Menu Install Red Hat Enterprise Linux 7.0 in basic graphics mode This option allows you to install Red Hat Enterprise Linux in graphical mode even if the installation program is unable to load the correct driver for your video card. If your screen appears distorted or goes blank when using the Install Red Hat Enterprise Linux 7.0 option, restart your computer and try this option instead. Rescue a Red Hat Enterprise Linux system Choose this option to repair a problem with your installed Red Hat Enterprise Linux system that prevents you from booting normally. The rescue environment contains utility programs that allow you fix a wide variety of these problems. Run a memory test This option runs a memory test on your system. For more information, see Section 23.2.1, "Loading the Memory (RAM) Testing Mode" . Boot from local drive This option boots the system from the first installed disk. If you booted this disc accidentally, use this option to boot from the hard disk immediately without starting the installation program.

Commands:
5.7.3. File-Related Issues System administrators often have to deal with file-related issues. The issues include: File Access File Sharing 5.7.3.1. File Access Issues relating to file access typically revolve around one scenario -- a user is not able to access a file they feel they should be able to access. Often this is a case of user #1 wanting to give a copy of a file to user #2. In most organizations, the ability for one user to access another user's files is strictly curtailed, leading to this problem. There are three approaches that could conceivably be taken: User #1 makes the necessary changes to allow user #2 to access the file wherever it currently exists. A file exchange area is created for such purposes; user #1 places a copy of the file there, which can then be copied by user #2. User #1 uses email to give user #2 a copy of the file. There is a problem with the first approach -- depending on how access is granted, user #2 may have full access to all of user #1's files. Worse, it might have been done in such a way as to permit all users in your organization access to user #1's files. Still worse, this change may not be reversed after user #2 no longer requires access, leaving user #1's files permanently accessible by others. Unfortunately, when users are in charge of this type of situation, security is rarely their highest priority. The second approach eliminates the problem of making all of user #1's files accessible to others. However, once the file is in the file exchange area the file is readable (and depending on the permissions, even writable) by all other users. This approach also raises the possibility of the file exchange area becoming filled with files, as users often forget to clean up after themselves. The third approach, while seemingly an awkward solution, may actually be the preferable one in most cases. With the advent of industry-standard email attachment protocols and more intelligent email programs, sending all kinds of files via email is a mostly foolproof operation, requiring no system administrator involvement. Of course, there is the chance that a user will attempt to email a 1GB database file to all 150 people in the finance department, so some amount of user education (and possibly limitations on email attachment size) would be prudent. Still, none of these approaches deal with the situation of two or more users needing ongoing access to a single file. In these cases, other methods are required.

Commands:
16.5. Configuring the Squid Service to Listen on a Specific Port or IP Address By default, the Squid proxy service listens on the 3128 port on all network interfaces. This section describes how to change the port and configuring Squid to listen on a specific IP address. Prerequisites Squid is installed. Procedure Edit the /etc/squid/squid.conf file: To set the port on which the Squid service listens, set the port number in the http_port parameter. For example, to set the port to 8080 , set: To configure on which IP address the Squid service listens, set the IP address and port number in the http_port parameter. For example, to configure that Squid listens only on the 192.0.2.1 IP address on port 3128 , set: Add multiple http_port parameters to the configuration file to configure that Squid listens on multiple ports and IP addresses: If you configured that Squid uses a different port as the default ( 3128 ): Open the port in the firewall: If you run SELinux in enforcing mode, assign the port to the squid_port_t port type definition: If the semanage utility is not available on your system, install the policycoreutils-python-utils package. Restart the squid service:

Commands:
http_port 8080
http_port 192.0.2.1:3128
http_port 192.0.2.1:3128 http_port 192.0.2.1:8080
firewall-cmd --permanent --add-port= port_number /tcp firewall-cmd --reload
semanage port -a -t squid_port_t -p tcp port_number
systemctl restart squid
Chapter 2. Installation This chapter guides you through the steps to install AMQ OpenWire JMS in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ OpenWire JMS, you must install Apache Maven . To use AMQ OpenWire JMS, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.apache.activemq</groupId> <artifactId>activemq-client</artifactId> <version>5.11.0.redhat-630416</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ OpenWire JMS can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Broker 7.7.0 Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.7.0-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" . 2.4. Installing the examples Procedure Use your subscription to download the AMQ Broker 7.7.0 .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.7.0.zip On Windows, right-click the .zip file and select Extract All . When you extract the contents of the .zip file, a directory named amq-broker-7.7.0 is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document.

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.apache.activemq</groupId> <artifactId>activemq-client</artifactId> <version>5.11.0.redhat-630416</version> </dependency>
unzip amq-broker-7.7.0-maven-repository.zip
unzip amq-broker-7.7.0.zip
Chapter 6. Configuration from sample environment file The environment file that you created in Creating the custom back end environment file configures the Block Storage service to use two NetApp back ends. The following snippet displays the relevant settings:

Commands:
enabled_backends = netapp1,netapp2 [netapp1] volume_backend_name=netapp_1 volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver netapp_login=root netapp_storage_protocol=iscsi netapp_password=p@USDUSDw0rd netapp_storage_family=ontap_7mode netapp_server_port=80 netapp_server_hostname=10.35.64.11 [netapp2] volume_backend_name=netapp_2 volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver netapp_login=root netapp_storage_protocol=iscsi netapp_password=p@USDUSDw0rd netapp_storage_family=ontap_7mode netapp_server_port=80 netapp_server_hostname=10.35.64.11
B.2. The lvmconfig Command You can display the current LVM configuration, or save the configuration to a file, with the lvmconfig command. There are a variety of features that the lvmconfig command provides, including the following; You can dump the current lvm configuration merged with any tag configuration files. You can dump all current configuration settings for which the values differ from the defaults. You can dump all new configuration settings introduced in the current LVM version, in a specific LVM version. You can dump all configuration settings that can be customized in a profile, either in their entirety or separately for command and metadata profiles. For information on LVM profiles see Section B.3, "LVM Profiles" . You can dump only the configuration settings for a specific version of LVM. You can validate the current configuration. For a full list of supported features and information on specifying the lvmconfig options, see the lvmconfig man page.

Commands:
3.3. Basic SystemTap Handler Constructs SystemTap supports the use of several basic constructs in handlers. The syntax for most of these handler constructs are mostly based on C and awk syntax. This section describes several of the most useful SystemTap handler constructs, which should provide you with enough information to write simple yet useful SystemTap scripts. 3.3.1. Variables Variables can be used freely throughout a handler; simply choose a name, assign a value from a function or expression to it, and use it in an expression. SystemTap automatically identifies whether a variable should be typed as a string or integer, based on the type of the values assigned to it. For instance, if you use set the variable foo to gettimeofday_s() (as in foo = gettimeofday_s() ), then foo is typed as a number and can be printed in a printf() with the integer format specifier ( %d ). Note, however, that by default variables are only local to the probe they are used in. This means that variables are initialized, used and disposed at each probe handler invocation. To share a variable between probes, declare the variable name using global outside of the probes. Consider the following example: Example 3.8. timer-jiffies.stp Example 3.8, "timer-jiffies.stp" computes the CONFIG_HZ setting of the kernel using timers that count jiffies and milliseconds, then computing accordingly. The global statement allows the script to use the variables count_jiffies and count_ms (set in their own respective probes) to be shared with probe timer.ms(12345) . Note The ++ notation in Example 3.8, "timer-jiffies.stp" (that is count_jiffies ++ and count_ms ++ ) is used to increment the value of a variable by 1. In the following probe, count_jiffies is incremented by 1 every 100 jiffies: In this instance, SystemTap understands that count_jiffies is an integer. Because no initial value was assigned to count_jiffies , its initial value is zero by default.

Commands:
global count_jiffies, count_ms probe timer.jiffies(100) { count_jiffies ++ } probe timer.ms(100) { count_ms ++ } probe timer.ms(12345) { hz=(1000*count_jiffies) / count_ms printf ("jiffies:ms ratio %d:%d => CONFIG_HZ=%d\n", count_jiffies, count_ms, hz) exit () }
probe timer.jiffies(100) { count_jiffies ++ }
5.4. Creating a Fencing Device The following command creates a stonith device. Some fence devices can fence only a single node, while other devices can fence multiple nodes. The parameters you specify when you create a fencing device depend on what your fencing device supports and requires. Some fence devices can automatically determine what nodes they can fence. You can use the pcmk_host_list parameter when creating a fencing device to specify all of the machines that are controlled by that fencing device. Some fence devices require a mapping of host names to the specifications that the fence device understands. You can map host names with the pcmk_host_map parameter when creating a fencing device. For information on the pcmk_host_list and pcmk_host_map parameters, see Table 5.1, "General Properties of Fencing Devices" . After configuring a fence device, it is imperative that you test the device to ensure that it is working correctly. For information on testing fence devices, see Section 5.12, "Testing a Fence Device" .

Commands:
pcs stonith create stonith_id stonith_device_type [ stonith_device_options ]
pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
Chapter 2. Overview of the all-in-one Red Hat OpenStack Platform environment This section contains information about installing, configuring, and deploying a simple, single-node Red Hat OpenStack Platform environment. In this scenario, there is no pre-existing undercloud dependency. Instead, the installer runs an inline heat-all instance to bootstrap the deployment process and convert the selected heat templates into Ansible playbooks that you can execute on a local machine. Use the all-in-one installation for basic testing and development. The all-in-one installation is a good starting point and test environment for Red Hat OpenStack Platform, but if you want to perform complex operations, you must deploy a production-level scaled cloud. Workflow To install, configure, and deploy a simple, single-node Red Hat OpenStack Platform environment, complete the tasks in the following basic workflow: Prepare your environment. Install packages for the all-in-one environment. Configure the all-in-one environment. Deploy the all-in-one environment. Benefits of the all-in-one installation Composable services. Pre-defined roles. Condensed single-node environment. Playbooks that you can use to run the small-footprint installer in a container and generate Ansible playbooks. Configuration If you want to experiment with configuring roles and services, see Chapter 8, Working with custom roles and services and Section 7.1, "Core heat templates" . Composable roles You can create custom composable roles and deploy specific services for each role. Ansible This installation applies Ansible playbooks automatically with the deployment command. You can also direct the deployment command to output Ansible playbooks that you can use on other instances. For example, you can complete testing in the all-in-one installation, and then apply the verified Ansible playbook to other instances.

Commands:
Chapter 4. Downloading and building Red Hat Build of OptaPlanner examples You can download the Red Hat Build of OptaPlanner examples as a part of the Red Hat Build of OptaPlanner sources package available on the Red Hat Customer Portal. Note Red Hat Build of OptaPlanner has no GUI dependencies. It runs just as well on a server or a mobile JVM as it does on the desktop. Procedure Navigate to the Software Downloads page in the Red Hat Customer Portal (login required), and select the product and version from the drop-down options: Product: Red Hat Build of OptaPlanner Version: 8.38 Download Red Hat Build of OptaPlanner 8.38 Source Distribution . Extract the rhbop-8.38.0-optaplanner-sources.zip file. The extracted org.optaplanner.optaplanner-8.38.0.Final-redhat-00004/optaplanner-examples/src/main/java/org/optaplanner/examples directory contains example source code. To build the examples, in the org.optaplanner.optaplanner-8.38.0.Final-redhat-00004 directory enter the following command: Change to the examples directory: To run the examples, enter the following command:

Commands:
mvn clean install -Dquickly
optaplanner-examples
mvn exec java
4.2. Directories in the /etc/sysconfig/ Directory The following directories are normally found in /etc/sysconfig/ . apm-scripts/ - This directory contains the APM suspend/resume script. Do not edit the files directly. If customization is necessary, create a file called /etc/sysconfig/apm-scripts/apmcontinue which is called at the end of the script. It is also possible to control the script by editing /etc/sysconfig/apmd . cbq/ - This directory contains the configuration files needed to do Class Based Queuing for bandwidth management on network interfaces. CBQ divides user traffic into a hierarchy of classes based on any combination of IP addresses, protocols, and application types. networking/ - This directory is used by the Network Administration Tool ( system-config-network ), and its contents should not be edited manually. For more information about configuring network interfaces using the Network Administration Tool , refer to the chapter called Network Configuration in the System Administrators Guide . network-scripts/ - This directory contains the following network-related configuration files: Network configuration files for each configured network interface, such as ifcfg-eth0 for the eth0 Ethernet interface. Scripts used to bring up and down network interfaces, such as ifup and ifdown . Scripts used to bring up and down ISDN interfaces, such as ifup-isdn and ifdown-isdn . Various shared network function scripts which should not be edited directly. For more information on the network-scripts directory, refer to Chapter 8, Network Interfaces . rhn/ - This directory contains the configuration files and GPG keys for Red Hat Network. No files in this directory should be edited by hand. For more information on Red Hat Network, refer to the Red Hat Network website online at https://rhn.redhat.com/ .

Commands:
Appendix B. The LVM Configuration Files LVM supports multiple configuration files. At system startup, the lvm.conf configuration file is loaded from the directory specified by the environment variable LVM_SYSTEM_DIR , which is set to /etc/lvm by default. The lvm.conf file can specify additional configuration files to load. Settings in later files override settings from earlier ones. To display the settings in use after loading all the configuration files, execute the lvmconfig command. For information on loading additional configuration files, see Section D.2, "Host Tags" . B.1. The LVM Configuration Files The following files are used for LVM configuration: /etc/lvm/lvm.conf Central configuration file read by the tools. etc/lvm/lvm_ hosttag .conf For each host tag, an extra configuration file is read if it exists: lvm_ hosttag .conf . If that file defines new tags, then further configuration files will be appended to the list of files to read in. For information on host tags, see Section D.2, "Host Tags" . LVM profiles An LVM profile is a set of selected customizable configuration settings that can be implemented for specific environments. The settings in an LVM profile can be used to override existing configuration. For information on LVM profiles see Section B.3, "LVM Profiles" . In addition to the LVM configuration files, a system running LVM includes the following files that affect LVM system setup: /etc/lvm/cache/.cache Device name filter cache file (configurable). /etc/lvm/backup/ Directory for automatic volume group metadata backups (configurable). /etc/lvm/archive/ Directory for automatic volume group metadata archives (configurable with regard to directory path and archive history depth). /var/lock/lvm/ In single-host configuration, lock files to prevent parallel tool runs from corrupting the metadata; in a cluster, cluster-wide DLM is used.

Commands:
7.110. libsemanage 7.110.1. RHBA-2015:1403 - libsemanage bug fix update Updated libsemanage packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The libsemanage library provides an API for the manipulation of SELinux binary policies. It is used by the checkpolicy compiler and similar tools, as well as by programs such as load_policy, which must perform specific transformations on binary policie, such as customizing policy boolean settings. Bug Fixes BZ# 591451 The libsemanage test suite previously failed when attempting to test the libsemanage library. With this update, an error in the underlying code has been corrected, which allows the libsemanage test suite to work as expected. BZ# 872700 Prior to this update, the semodule command failed with an error message when attempting to enable an already enabled module, or disable an already disabled module. This update adjusts the behavior of the command to succeed and not to produce error messages in the described scenarios. Users of libsemanage are advised to upgrade to these updated packages, which fix these bugs.

Commands:
3.14. Detaching a Virtual Disk This Ruby example detaches a disk from a virtual machine. # Find the virtual machine: vm = vms_service.list(search: 'name=myvm').first # Detach the first disk from the virtual machine: vm_service = vms_service.vm_service(vm.id) attachments_service = vm_service.disk_attachments_service attachment = attachments_service.list.first # Remove the attachment. The default behavior is that the disk is detached # from the virtual machine, but not deleted from the system. If you wish to # delete the disk, change the `detach_only` parameter to `false`. attachment.remove(detach_only: true) For more information, see VmService:disk_attachments_service .

Commands:
Find the virtual machine: vm = vms_service.list(search: 'name=myvm').first Detach the first disk from the virtual machine: vm_service = vms_service.vm_service(vm.id) attachments_service = vm_service.disk_attachments_service attachment = attachments_service.list.first Remove the attachment. The default behavior is that the disk is detached from the virtual machine, but not deleted from the system. If you wish to delete the disk, change the `detach_only` parameter to `false`. attachment.remove(detach_only: true)