mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Network Booting with libvirt Guest virtual machines can be booted with PXE enabled. PXE allows guest virtual machines to boot and load their configuration off the network itself. This section demonstrates some basic configuration steps to configure PXE guests with libvirt. This section does not cover the creation of boot images or PXE servers. It is used to explain how to configure libvirt, in a private or bridged network, to boot a guest virtual machine with PXE booting enabled. Warning These procedures are provided only as an example. Ensure that you have sufficient backups before proceeding. 9.1. Preparing the Boot Server To perform the steps in this chapter you will need: A PXE Server (DHCP and TFTP) - This can be a libvirt internal server, manually-configured dhcpd and tftpd, dnsmasq, a server configured by Cobbler, or some other server. Boot images - for example, PXELINUX configured manually or by Cobbler. 9.1.1. Setting up a PXE Boot Server on a Private libvirt Network This example uses the default network. Perform the following steps: Procedure 9.1. Configuring the PXE boot server Place the PXE boot images and configuration in /var/lib/tftpboot . enter the following commands: Edit the <ip> element in the configuration file for the default network to include the appropriate address, network mask, DHCP address range, and boot file, where BOOT_FILENAME represents the file name you are using to boot the guest virtual machine. Run: Boot the guest using PXE (refer to Section 9.2, "Booting a Guest Using PXE" ).

Commands:
virsh net-destroy default virsh net-edit default
<ip address='192.168.122.1' netmask='255.255.255.0'> <tftp root='/var/lib/tftpboot' /> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> <bootp file=' BOOT_FILENAME ' /> </dhcp> </ip>
virsh net-start default
Chapter 4. sVirt 4.1. Introduction Since virtual machines under KVM are implemented as Linux processes, KVM uses the standard Linux security model to provide isolation and resource controls. The Linux kernel includes Security-Enhanced Linux (SELinux) to add mandatory access control (MAC), multi-level security (MLS) and multi-category security (MCS) through a flexible and customizable security policy. SELinux provides strict resource isolation and confinement for processes running on top of the Linux kernel, including virtual machine processes. The sVirt project builds upon SELinux to further enable virtual machine isolation and controlled sharing. For example, fine-grained permissions could be applied to group virtual machines together to share resources. From a security point of view, the hypervisor is a likely target for attackers, as a compromised hypervisor can lead to the all virtual machines running on the host system. Integrating SELinux into virtualization technologies helps improve hypervisor security against malicious virtual machines trying to gain access to the host system or other virtual machines. The following image represents SELinux isolating guests, which limits the ability for a compromised hypervisor (or guest) to launch further attacks, or to extend to another instance: Figure 4.1. Attack path isolated by SELinux Note For more information on SELinux, refer to the Red Hat Enterprise Linux SELinux Users and Administrators Guide .

Commands:
Appendix A. Revision History Revision History Revision 6.6.1-3 Sun 11 Sep 2016 Christian Huffman Included section on patching server. Revision 6.6.1-2 Fri 9 Sep 2016 Christian Huffman Updated list of resolved issues. Revision 6.6.1-1 Wed 7 Sep 2016 Christian Huffman Included set of known and resolved issues. Revision 6.6.1-0 Wed 7 Sep 2016 Christian Huffman Initial Draft for 6.6.1.

Commands:
Chapter 11. Configuring instance security Warning The content for this feature is available in this release as a Documentation Preview , and therefore is not fully verified by Red Hat. Use it only for testing, and do not use in a production environment. As a cloud administrator, you can configure the following security features for the instances that run on your cloud: UEFI Secure boot : You can create a UEFI Secure Boot flavor with the property key os:secure_boot enabled. Cloud users can use this flavor to create instances that are protected with UEFI Secure Boot. Emulated virtual Trusted Platform Module (vTPM) : You can provide cloud users the ability to create instances that have emulated vTPM devices. SEV : Use to enable your cloud users to create instances that use memory encryption.

Commands:
Chapter 7. Cleaning Tempest Resources After running tempest , there are files, users and projects created in the testing process that must be deleted. Being able to self-clean is one of the design principles of tempest . 7.1. Performing a Clean Up First, you must initialize the saved state. This creates the file saved_state.json , which prevents the cleanup from deleting objects that need to be kept. Typically you would run cleanup with --init-saved-state prior to a tempest run. If this is not the case, saved_state.json must be edited to remove objects that you want cleanup to delete. Run the cleanup: The tempest cleanup command deletes tempest resources but does not delete projects or the tempest administrator account. 7.2. Performing a Dry Run It is recommended to perform a dry run before executing the real cleanup. A dry run lists the files that would be deleted by a cleanup, but does not delete any files. The files are listed in the dry_run.json file. Check the dry_run.json file to ensure that the cleanup does not delete any files that you require for your environment. 7.3. Deleting Tempest Objects Run the following command to delete all tempest resources, including projects, but not the tempest administrator account:

Commands:
tempest cleanup --init-saved-state
tempest cleanup
tempest cleanup --dry-run
tempest cleanup --delete-tempest-conf-objects
5.194. mkbootdisk 5.194.1. RHBA-2012:0403 - mkbootdisk bug fix update An updated mkbootdisk package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The mkbootdisk program creates a standalone boot floppy disk for booting the running system. Bug Fixes BZ# 761590 Previously, the "mkbootdisk --iso" command could fail with a "Volume ID string too long" error. This was because the length of the volume ID is limited to 32 characters but the limit was not verified. With this update, the string length is verified and if it is longer than 32 characters, the fixed string "Red Hat Linux" is used for volume ID. BZ# 790039 Previously, the mkbootdisk package was missing a dependency on the genisoimage package that was required for functionality of the "--iso" option. This update adds the missing dependency. All users of mkbootdisk are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 1. Automation of JBoss Web Server deployments by using an Ansible collection Ansible is an information technology (IT) automation engine that you can use to automate and simplify cloud provisioning, configuration management, application deployment, intraservice orchestration, and other tasks across your IT enterprise. An Ansible collection is a standardized distribution format for reusable Ansible content such as playbooks, roles, modules, and plug-ins. Red Hat provides a series of prepackaged Red Hat Ansible Certified Content Collections. You can use these Red Hat Ansible Certified Content Collections to enable the automated deployment of various Red Hat Runtimes products such as Red Hat JBoss Web Server in your system. 1.1. Ansible concepts and benefits Ansible includes various elements such as playbooks, roles, content collections, and automation execution environments. Using Ansible to automate IT processes, workflows, and infrastructure lifecycles provides multiple benefits to your enterprise. If you are unfamiliar with Ansible architecture or you want more information about the benefits of using Ansible, refer to the following Additional resources links. Additional resources How Ansible works Understanding Ansible concepts Learning Ansible basics Red Hat Ansible Automation Platform product page 1.2. JBoss Web Server collection For general information about the JBoss Web Server collection, refer to the Ansible Collection - redhat.jws page in Ansible automation hub . The Ansible Collection - redhat.jws page includes information about the roles that the collection contains. You can click the name of a role to view details about the purpose of this role, any requirements or dependencies, and the list of variables and default settings that the role uses to complete automation tasks. Additional resources Ansible Content Collections

Commands:
Chapter 2. System Requirements This chapter describes the system requirements for Red Hat GFS with Red Hat Enterprise Linux 5 and consists of the following sections: Section 2.1, "Platform Requirements" Section 2.2, "Red Hat Cluster Suite" Section 2.3, "Fencing" Section 2.4, "Fibre Channel Storage Network" Section 2.5, "Fibre Channel Storage Devices" Section 2.6, "Network Power Switches" Section 2.7, "Console Access" 2.1. Platform Requirements Table 2.1, "Platform Requirements" shows the platform requirements for GFS. Table 2.1. Platform Requirements Operating System Hardware Architecture RAM Red Hat Enterprise Linux AS, ES, or WS, Version 4 or later ia64, x86-64, x86 SMP supported 256 MB, minimum

Commands:
Chapter 4. Technology previews This section describes the technology preview features introduced in Red Hat OpenShift Data Foundation 4.13 under Technology Preview support limitations. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. Technology Preview features are provided with a limited support scope, as detailed on the Customer Portal: Technology Preview Features Support Scope . 4.1. Regional disaster recovery for RADOS block device Regional-DR solution provides automated protection for block volumes, asynchronous replication, and protects business functionalities when a disaster strikes at a geographical location. In the public cloud this is similar to protecting from a regional failure. For more information, see Regional-DR section in the Planning guide and Regional-DR solution for OpenShift Data Foundation .

Commands:
Chapter 1. Introduction This document describes how to configure OpenStack to use one or more Dell Storage Center back ends. The following sections assume that: You intend to use only Dell Storage Center devices and drivers for Block Storage back ends The OpenStack Overcloud has already been deployed through Director, with a properly-functional Block Storage service The Dell storage device has already been deployed and configured as a storage repository You have the necessary credentials for connecting to the Enterprise Manager and Dell Storage Center Group You have the username and password of an account with elevated privileges. You can use the same account that was created to deploy the Overcloud; in Creating a Director Installation User , we create and use the stack user for this purpose. When RHEL OpenStack Platform is deployed through the Director, all major Overcloud settings (in particular, the Block Storage service back end) must be defined and orchestrated through the Director as well. This ensures that the settings will persist through any further Overcloud updates. For more information about deploying OpenStack through the Director, see Director Installation and Usage . The purpose of this document is to explain how to orchestrate your desired Dell Storage Center back end configuration to the Overcloud's Block Storage service. This document will not discuss the different deployment configurations possible with the back end. Rather, to learn more about the different available deployment configurations, see your device's product documentation. Once you are familiar with the resulting back end configuration you want to deploy (and its corresponding settings), refer to this document for instructions on how to orchestrate it through the Director. Note At present, the Director only has the integrated components to deploy a single instance of a Dell Storage Center back end. As such, this document only describes the deployment of a single back end. Deploying multiple instances of a Dell Storage Center back end requires a custom back end configuration . See the Custom Block Storage Back End Deployment Guide for instructions.

Commands:
2.38. RHEA-2011:0671 - new package: scons New scons packages as well as new mingw32-* packages, which provide dependencies for building the Matahari agents for Windows guests, are now available for Red Hat Enterprise Linux 6. Matahari is a set of APIs for operating system management that are exposed for remote access over the Qpid Management Framework (QMF). This enhancement update adds new scons and mingw32 dependency packages to Red Hat Enterprise Linux 6 as a Technology Preview. These packages provide the mingw32 compiler dependencies needed to cross-compile Matahari agents for Windows. (BZ# 658833 ) More information about Red Hat Technology Previews is available here: https://access.redhat.com/support/offerings/techpreview/ The complete list of packages provided by this update is as follows: * scons * mingw32-binutils * mingw32-boost * mingw32-bzip2 * mingw32-dlfcn * mingw32-expat * mingw32-filesystem * mingw32-gcc * mingw32-gettext * mingw32-glib2 * mingw32-gnutls * mingw32-iconv * mingw32-libgcrypt * mingw32-libgpg-error * mingw32-libxml2 * mingw32-libxslt * mingw32-nsis * mingw32-pcre * mingw32-pthreads * mingw32-qpid-cpp * mingw32-readline * mingw32-runtime * mingw32-sigar * mingw32-srvany * mingw32-termcap * mingw32-w32api * mingw32-zlib All users who need to cross-compile Matahari agents for Windows should install these packages, which provide this enhancement.

Commands:
2.2.2. Network Time Protocol Setup As opposed to the manual setup described above, you can also synchronize the system clock with a remote server over the Network Time Protocol ( NTP ). For the one-time synchronization only, use the ntpdate command: Firstly, check whether the selected NTP server is accessible: For example: When you find a satisfactory server, run the ntpdate command followed by one or more server addresses: For instance: Unless an error message is displayed, the system time should now be set. You can check the current by setting typing date without any additional arguments as shown in Section 2.2.1, "Date and Time Setup" . In most cases, these steps are sufficient. Only if you really need one or more system services to always use the correct time, enable running the ntpdate at boot time: For more information about system services and their setup, see Chapter 12, Services and Daemons . Note If the synchronization with the time server at boot time keeps failing, i.e., you find a relevant error message in the /var/log/boot.log system log, try to add the following line to /etc/sysconfig/network : However, the more convenient way is to set the ntpd daemon to synchronize the time at boot time automatically: Open the NTP configuration file /etc/ntp.conf in a text editor such as vi or nano , or create a new one if it does not already exist: Now add or edit the list of public NTP servers. If you are using Red Hat Enterprise Linux 6, the file should already contain the following lines, but feel free to change or expand these according to your needs: The iburst directive at the end of each line is to speed up the initial synchronization. As of Red Hat Enterprise Linux 6.5 it is added by default. If upgrading from a minor release, and your /etc/ntp.conf file has been modified, then the upgrade to Red Hat Enterprise Linux 6.5 will create a new file /etc/ntp.conf.rpmnew and will not alter the existing /etc/ntp.conf file. Once you have the list of servers complete, in the same file, set the proper permissions, giving the unrestricted access to localhost only: Save all changes, exit the editor, and restart the NTP daemon: Make sure that ntpd is started at boot time:

Commands:
~]# ntpdate -q server_address
~]# ntpdate -q 0.rhel.pool.ntp.org
~]# ntpdate server_address
~]# ntpdate 0.rhel.pool.ntp.org 1.rhel.pool.ntp.org
~]# chkconfig ntpdate on
NETWORKWAIT=1
~]# nano /etc/ntp.conf
server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst server 3.rhel.pool.ntp.org iburst
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
~]# service ntpd restart
~]# chkconfig ntpd on
2.4. Security A virtual machine uses SELinux and sVirt to improve security in virtualization. This section includes an overview of the security options available. 2.4.1. Virtualization Security Features SELinux Security-Enhanced Linux, or SELinux, provides Mandatory Access Control (MAC) for all Linux system, and thus benefits also Linux guests. Under the control of SELinux, all processes and files are given a type , and their access on the system is limited by fine-grained controls of various types. SELinux limits the abilities of an attacker and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. SELinux strengthens the security model of Red Hat Enterprise Linux hosts and virtualized Red Hat Enterprise Linux guests. SELinux is configured and tested to work, by default, with all virtualization tools shipped with Red Hat Enterprise Linux 6. sVirt sVirt is a technology included in Red Hat Enterprise Linux 6 that integrates SELinux and virtualization. It applies Mandatory Access Control (MAC) to improve security when using virtual machines, and improves security and hardens the system against hypervisor bugs that might be used to attack the host or another virtual machine. Note For more information on security for virtualization, refer to the Red Hat Enterprise Linux 6 Virtualization Security Guide .

Commands:
Chapter 8. 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. 8.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. 8.2. Expanding the node port range You can expand the node port range for the 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>" } }' 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"] 8.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>" } }'
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"]
13.2. Using and Caching Credentials with SSSD The System Security Services Daemon (SSSD) provides access to different identity and authentication providers. 13.2.1. About SSSD Most system authentication is configured locally, which means that services must check with a local user store to determine users and credentials. What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers - an LDAP directory, an Identity Management domain, Active Directory, possibly even a Kerberos realm. SSSD also caches those users and credentials, so if the local system or the identity provider go offline, the user credentials are still available to services to verify. SSSD is an intermediary between local clients and any configured data store. This relationship brings a number of benefits for administrators: Reducing the load on identification/authentication servers. Rather than having every client service attempt to contact the identification server directly, all of the local clients can contact SSSD which can connect to the identification server or check its cache. Permitting offline authentication. SSSD can optionally keep a cache of user identities and credentials that it retrieves from remote services. This allows users to authenticate to resources successfully, even if the remote identification server is offline or the local machine is offline. Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources by authenticating to their local machine and then SSSD maintains their network credentials. Additional Resources While this chapter covers the basics of configuring services and domains in SSSD, this is not a comprehensive resource. Many other configuration options are available for each functional area in SSSD; check out the man page for the specific functional area to get a complete list of options. Some of the common man pages are listed in Table 13.1, "A Sampling of SSSD Man Pages" . There is also a complete list of SSSD man pages in the "See Also" section of the sssd(8) man page. Table 13.1. A Sampling of SSSD Man Pages Functional Area Man Page General Configuration sssd.conf(8) sudo Services sssd-sudo LDAP Domains sssd-ldap Active Directory Domains sssd-ad sssd-ldap Identity Management (IdM or IPA) Domains sssd-ipa sssd-ldap Kerberos Authentication for Domains sssd-krb5 OpenSSH Keys sss_ssh_authorizedkeys sss_ssh_knownhostsproxy Cache Maintenance sss_cache (cleanup) sss_useradd, sss_usermod, sss_userdel, sss_seed (user cache entry management)

Commands: