mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Viewing and managing Quartz Schedules Quartz is a richly featured, open source job scheduling library that you can integrate within most Java applications. You can use Quartz to create simple or complex schedules for executing jobs. A job is defined as a standard Java component that can execute virtually anything that you program it to do. HawtIO shows the Quartz tab if your Camel route deploys the camel-quartz component. Note that you can alternately access Quartz mbeans through the JMX tree view. Procedure : In HawtIO, click the Quartz tab. The Quartz page includes a tree view of the Quartz Schedulers and Scheduler , Triggers , and Jobs tabs. To pause or start a scheduler, click the buttons on the Scheduler tab. Click the Triggers tab to view the triggers that determine when jobs will run. For example, a trigger can specify to start a job at a certain time of day (to the millisecond), on specified days, or repeated a specified number of times or at specific times. To filter the list of triggers select State , Group , Name , or Type from the drop-down list. You can then further filter the list by selecting or typing in the fill-on field. To pause, resume, update, or manually fire a trigger, click the options in the Action column. Click the Jobs tab to view the list of running jobs. You can sort the list by the columns in the table: Group , Name , Durable , Recover , Job ClassName , and Description .

Commands:
Chapter 11. Hardening block storage on Red Hat OpenStack Platform OpenStack Block Storage (cinder) is a service that provides software (services and libraries) to self-service manage persistent block-level storage devices. This creates on-demand access to Block Storage resources for use with Compute (nova) instances. This creates software-defined storage through abstraction by virtualizing pools of block storage to a variety of back-end storage devices which can be either software implementations or traditional hardware storage products. The primary functions of this is to manage the creation, attachment, and detachment of the block devices. The consumer requires no knowledge of the type of back-end storage equipment or where it is located. Compute instances store and retrieve block storage using industry-standard storage protocols such as iSCSI, ATA over Ethernet, or Fibre-Channel. These resources are managed and configured using OpenStack native standard HTTP RESTful API. 11.1. Set the max size for the body of a request If the maximum body size per request is not defined, the attacker can craft an arbitrary OSAPI request of large size, causing the service to crash and finally resulting in a Denial Of Service attack. Assigning t he maximum value ensures that any malicious oversized request gets blocked ensuring continued availability of the service. Review whether max_request_body_size under the [oslo_middleware] section in cinder.conf is set to 114688 . 11.2. Enable volume encryption Unencrypted volume data makes volume-hosting platforms especially high-value targets for attackers, as it allows the attacker to read the data for many different VMs. In addition, the physical storage medium could be stolen, remounted, and accessed from a different machine. Encrypting volume data and volume backups can help mitgate these risks and provides defense-in-depth to volume-hosting platforms. Block Storage (cinder) is able to encrypt volume data before it is written to disk, so consider enabling volume encryption, and using Barbican for private key storage. 11.3. Volume Wiping There are multiple ways to wipe a block storage device. The traditional approach is to set the lvm_type to thin, and then use the volume_clear parameter. Alternatively, if the volume encryption feature is us ed, then volume wiping is not necessary if the volume encryption key is deleted. Note Previously, lvm_type=default was used to signify a wipe. While this method still works, lvm_type=default is not recommended for setting secure delete. The volume_clear parameter can accept either zero or shred as arguments. zero will write a single pass of zeroes to the device. The shred operation will write three passes of predetermined bit patterns.

Commands:
10.2. Configure 802.1Q VLAN tagging Using the Text User Interface, nmtui The text user interface tool nmtui can be used to configure 802.1Q VLANs in a terminal window. Issue the following command to start the tool: The text user interface appears. Any invalid command prints a usage message. To navigate, use the arrow keys or press Tab to step forwards and press Shift + Tab to step back through the options. Press Enter to select an option. The Space bar toggles the status of a check box. From the starting menu, select Edit a connection . Select Add , the New Connection screen opens. Figure 10.1. The NetworkManager Text User Interface Add a VLAN Connection menu Select VLAN , the Edit connection screen opens. Follow the on-screen prompts to complete the configuration. Figure 10.2. The NetworkManager Text User Interface Configuring a VLAN Connection menu See Section 10.5.1.1, "Configuring the VLAN Tab" for definitions of the VLAN terms. See Section 3.2, "Configuring IP Networking with nmtui" for information on installing nmtui .

Commands:
~]USD nmtui
18.9. Language Support To install support for additional locales and language dialects, select Language Support from the Installation Summary screen. Use your mouse to select the language for which you would like to install support. In the left panel, select your language of choice, for example Espanol . Then you can select a locale specific to your region in the right panel, for example Espanol (Costa Rica) . You can select multiple languages and multiple locales. The selected languages are highlighted in bold in the left panel. Figure 18.5. Configuring Language Support Once you have made your selections, click Done to return to the Installation Summary screen. Note To change your language support configuration after you have completed the installation, visit the Region & Language section of the Settings dialog window.

Commands:
4.8. Disabling LDAP Authentication for Token Operations By default, each user who requests a token operation is authenticated against an LDAP directory. If the user has an entry, then the operation is allowed; if the user does not have an entry, then the operation is rejected. For testing or for certain types of users, then it can be simpler or preferable to disable LDAP authentication. This is not configured in the Enterprise Security Client configuration, but in the Token Processing System configuration, and must be done by a TPS administrator. Stop the TPS subsystem. Open the TPS configuration file. Set the authentication parameters to false . The operation_type is the token operation for which LDAP authentication is being disabled, such as enroll , format , or pinreset . Disabling authentication for one operation type does not disable it for any other operation types. The token_type is the token profile. There are default profiles for regular users, security officers, and the users enrolled by security officers. There can also be custom token types for other kinds of users or certificates. For example: Restart the TPS subsystem. Editing the TPS configuration is covered in the Certificate System Administrator's Guide .

Commands:
service pki-tps stop
vim /var/lib/pki-tps/conf/CS.cfg
op. operation_type.token_type .loginRequest.enable=false op. operation_type.token_type .auth.enable=false
op. enroll.userKey. loginRequest.enable=false op. enroll.userKey .pinReset.enable=false
service pki-tps start
2.2. The File System Hierarchy The root directory of Software Collections is normally located in the /opt/ directory to avoid possible conflicts between Software Collections and the base system installation. The use of the /opt/ directory is recommended by the Filesystem Hierarchy Standard (FHS). Below is an example of the file system hierarchy layout with two Software Collections, software_collection_1 and software_collection_2 : Figure 2.1. The Software Collection File System Hierarchy As you can see above, each of the Software Collections directories contains the Software Collection root directory, and one or more Software Collection scriptlets. For more information on the Software Collection scriptlets, refer to Section 2.6, "Software Collection Scriptlets" .

Commands:
4.2.2. Boot Loader Passwords The following are the primary reasons for password protecting a Linux boot loader: Preventing Access to Single User Mode - If attackers can boot the system into single user mode, they are logged in automatically as root without being prompted for the root password. Preventing Access to the GRUB Console - If the machine uses GRUB as its boot loader, an attacker can use the use the GRUB editor interface to change its configuration or to gather information using the cat command. Preventing Access to Non-Secure Operating Systems - If it is a dual-boot system, an attacker can select at boot time an operating system, such as DOS, which ignores access controls and file permissions. The GRUB boot loader ships with Red Hat Enterprise Linux on the x86 platform. For a detailed look at GRUB, consult the chapter titled The GRUB Boot Loader in the Reference Guide . 4.2.2.1. Password Protecting GRUB GRUB can be configured to address the first two issues listed in Section 4.2.2, "Boot Loader Passwords" by adding a password directive to its configuration file. To do this, first decide on a password, then open a shell prompt, log in as root, and type: When prompted, type the GRUB password and press Enter . This returns an MD5 hash of the password. , edit the GRUB configuration file /boot/grub/grub.conf . Open the file and below the timeout line in the main section of the document, add the following line: Replace <password-hash> with the value returned by /sbin/grub-md5-crypt [6] . The time the system boots, the GRUB menu does not allow access to the editor or command interface without first pressing p followed by the GRUB password. Unfortunately, this solution does not prevent an attacker from booting into a non-secure operating system in a dual-boot environment. For this, a different part of the /boot/grub/grub.conf file must be edited. Look for the title line of the non-secure operating system and add a line that says lock directly beneath it. For a DOS system, the stanza should begin similar to the following: Warning A password line must be present in the main section of the /boot/grub/grub.conf file for this method to work properly. Otherwise, an attacker can access the GRUB editor interface and remove the lock line. To create a different password for a particular kernel or operating system, add a lock line to the stanza, followed by a password line. Each stanza protected with a unique password should begin with lines similar to the following example: [6] GRUB also accepts unencrypted passwords, but it is recommended that an md5 hash be used for added security.

Commands:
/sbin/grub-md5-crypt
password --md5 <password-hash>
title DOS lock
title DOS lock password --md5 <password-hash>
Chapter 5. Deleting a model registry You can delete model registries that you no longer require. Important When you delete a model registry, databases connected to the model registry will not be removed. To remove any remaining databases, contact your cluster administrator. Prerequisites You have logged in to OpenShift AI as a user with OpenShift AI administrator privileges. An available model registry exists in your deployment. Procedure From the OpenShift AI dashboard, click Settings Model registry settings . Click the action menu ( ... ) beside the model registry that you want to delete. Click Delete model registry . In the Delete model registry? dialog that appears, enter the name of the model registry in the text field to confirm that you intend to delete it. Click Delete model registry . Verification The model registry no longer appears on the Model Registry Settings page.

Commands:
4.3.5. Removing Physical Volumes from a Volume Group To remove unused physical volumes from a volume group, use the vgreduce command. The vgreduce command shrinks a volume group's capacity by removing one or more empty physical volumes. This frees those physical volumes to be used in different volume groups or to be removed from the system. Before removing a physical volume from a volume group, you can make sure that the physical volume is not used by any logical volumes by using the pvdisplay command. If the physical volume is still being used you will have to migrate the data to another physical volume using the pvmove command. Then use the vgreduce command to remove the physical volume: The following command removes the physical volume /dev/hda1 from the volume group my_volume_group .

Commands:
pvdisplay /dev/hda1 -- Physical volume --- PV Name /dev/hda1 VG Name myvg PV Size 1.95 GB / NOT usable 4 MB [LVM: 122 KB] PV# 1 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 499 Free PE 0 Allocated PE 499 PV UUID Sd44tK-9IRw-SrMC-MOkn-76iP-iftz-OVSen7
vgreduce my_volume_group /dev/hda1
3.6. Example: List CPU Profiles The following request retrieves a representation of the CPU profiles: Example 3.6. List CPU profiles Request: cURL command: Result:

Commands:
GET /ovirt-engine/api/cpuprofiles HTTP/1.1 Accept: application/xml
curl -X GET -H "Accept: application/xml" -u [USER:PASS] --cacert [CERT] https:// [RHEVM Host] :443/ovirt-engine/api/cpuprofiles
HTTP/1.1 200 OK Content-Type: application/xml <cpu_profiles> <cpu_profile href="0000001a-001a-001a-001a-00000000035e" id="0000001a-001a-001a-001a-00000000035e"> <name>Default</name> <link href="/ovirt-engine/api/cpuprofiles/0000001a-001a-001a-001a-00000000035e/permissions" rel="permissions"/> <cluster href= "/ovirt-engine/api/clusters/00000001-0001-0001-0001-00000000021b" id="00000001-0001-0001-0001-00000000021b"/> </cpu_profile> <cpu_profile href="fc4b9188-f87f-44f9-b9c5-c7665e10e0a2" id="fc4b9188-f87f-44f9-b9c5-c7665e10e0a2"> <name>Premium</name> <description>Full service available</description> <link href="/ovirt-engine/api/cpuprofiles/fc4b9188-f87f-44f9-b9c5-c7665e10e0a2/permissions" rel="permissions"/> <qos href= "/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000000f7/qoss/5afe49e3-aac4-4b7b-bb83-11b9aef285e1" id="5afe49e3-aac4-4b7b-bb83-11b9aef285e1"/> <cluster href= "/ovirt-engine/api/clusters/00000001-0001-0001-0001-00000000021b" id="00000001-0001-0001-0001-00000000021b"/> </cpu_profile> <cpu_profile href="48c600f4-6768-49ca-9c16-a877d0e586e5" id="48c600f4-6768-49ca-9c16-a877d0e586e5"> <name>Budget</name> <description>Limited CPU</description> <link href="/ovirt-engine/api/cpuprofiles/48c600f4-6768-49ca-9c16-a877d0e586e5/permissions" rel="permissions"/> <cluster href= "/ovirt-engine/api/clusters/00000001-0001-0001-0001-00000000021b" id="00000001-0001-0001-0001-00000000021b"/> </cpu_profile> <cpu_profile href="48c600f4-6768-49ca-9c16-a877d0e586e5" id="48c600f4-6768-49ca-9c16-a877d0e586e5"> <name>Backup</name> <link href="/ovirt-engine/api/cpuprofiles/d510b042-42f0-4cb2-9d2e-25fcc28d6c5f/permissions" rel="permissions"/> <cluster href= "/ovirt-engine/api/clusters/668cab0c-9185-4eaa-9942-658284eeecdd" id="668cab0c-9185-4eaa-9942-658284eeecdd"/> </cpu_profile> </cpu_profiles>
3.3. Listing Clusters This Ruby example lists the clusters. # Get the reference to the root of the services tree: system_service = connection.system_service # Get the reference to the service that manages the # collection of clusters: cls_service = system_service.clusters_service # Retrieve the list of clusters and for each one # print its name: cls = cls_service.list cls.each do |cl| puts cl.name end In an environment with only the Default cluster, the example outputs: For more information, see ClustersService:list .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Get the reference to the service that manages the collection of clusters: cls_service = system_service.clusters_service Retrieve the list of clusters and for each one print its name: cls = cls_service.list cls.each do |cl| puts cl.name end
Default
18.5. Converting Root Disk to RAID1 after Installation If you need to convert a non-raided root disk to a RAID1 mirror after installing Red Hat Enterprise Linux 7, see the instructions in the following Red Hat Knowledgebase article: How do I convert my root disk to RAID1 after installation of Red Hat Enterprise Linux 7? On the PowerPC (PPC) architecture, take the following additional steps: Copy the contents of the PowerPC Reference Platform (PReP) boot partition from /dev/sda1 to /dev/sdb1 : Update the Prep and boot flag on the first partition on both disks: Note Running the grub2-install /dev/sda command does not work on a PowerPC machine and returns an error, but the system boots as expected.

Commands:
dd if=/dev/sda1 of=/dev/sdb1
parted /dev/sda set 1 prep on USD parted /dev/sda set 1 boot on USD parted /dev/sdb set 1 prep on USD parted /dev/sdb set 1 boot on
1.5. Security Updates As security vulnerabilities are discovered, the affected software must be updated in order to limit any potential security risks. If the software is part of a package within a Red Hat Enterprise Linux distribution that is currently supported, Red Hat is committed to releasing updated packages that fix the vulnerability as soon as is possible. Often, announcements about a given security exploit are accompanied with a patch (or source code that fixes the problem). This patch is then applied to the Red Hat Enterprise Linux package and tested and released as an errata update. However, if an announcement does not include a patch, a developer first works with the maintainer of the software to fix the problem. Once the problem is fixed, the package is tested and released as an errata update. If an errata update is released for software used on your system, it is highly recommended that you update the affected packages as soon as possible to minimize the amount of time the system is potentially vulnerable. 1.5.1. Updating Packages When updating software on a system, it is important to download the update from a trusted source. An attacker can easily rebuild a package with the same version number as the one that is supposed to fix the problem but with a different security exploit and release it on the Internet. If this happens, using security measures such as verifying files against the original RPM does not detect the exploit. Thus, it is very important to only download RPMs from trusted sources, such as from Red Hat and to check the signature of the package to verify its integrity. Note Red Hat Enterprise Linux includes a convenient panel icon that displays visible alerts when there is an update available.

Commands:
Chapter 6. Running a distributed workload 6.1. Distributing training jobs with Ray In sections of this tutorial, you trained the fraud model directly in a notebook and then in a pipeline. In this section, you learn how to train the model by using Ray. Ray is a distributed computing framework that you can use to parallelize Python code across multiple CPUs or GPUs. This section demonstrates how you can use Ray to distribute the training of a machine learning model across multiple CPUs. While distributing training is not necessary for a simple model, applying it to the example fraud model is a good way for you to learn how to use Ray for more complex models that require more compute power, such as multiple GPUs across multiple machines. In your notebook environment, open the 8_distributed_training.ipynb file and follow the instructions directly in the notebook. The instructions guide you through setting authentication, creating Ray clusters, and working with jobs. Optionally, if you want to view the Python code for this section, you can find it in the ray-scripts/train_tf_cpu.py file. For more information about TensorFlow training on Ray, see the Ray TensorFlow guide .

Commands:
Chapter 8. Configuring Red Hat High Availability Manually This chapter describes how to configure Red Hat High Availability Add-On software by directly editing the cluster configuration file ( /etc/cluster/cluster.conf ) and using command-line tools. The chapter provides procedures about building a configuration file one section at a time, starting with a sample file provided in the chapter. As an alternative to starting with a sample file provided here, you could copy a skeleton configuration file from the cluster.conf man page. However, doing so would not necessarily align with information provided in subsequent procedures in this chapter. There are other ways to create and configure a cluster configuration file; this chapter provides procedures about building a configuration file one section at a time. Also, keep in mind that this is just a starting point for developing a configuration file to suit your clustering needs. This chapter consists of the following sections: Section 8.1, "Configuration Tasks" Section 8.2, "Creating a Basic Cluster Configuration File" Section 8.3, "Configuring Fencing" Section 8.4, "Configuring Failover Domains" Section 8.5, "Configuring HA Services" Section 8.7, "Configuring Debug Options" Section 8.6, "Configuring Redundant Ring Protocol" Section 8.9, "Verifying a Configuration" Important Make sure that your deployment of High Availability Add-On meets your needs and can be supported. Consult with an authorized Red Hat representative to verify your configuration prior to deployment. In addition, allow time for a configuration burn-in period to test failure modes. Important This chapter references commonly used cluster.conf elements and attributes. For a comprehensive list and description of cluster.conf elements and attributes, see the cluster schema at /usr/share/cluster/cluster.rng , and the annotated schema at /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (for example /usr/share/doc/cman-3.0.12/cluster_conf.html ). Important Certain procedure in this chapter call for using the cman_tool version -r command to propagate a cluster configuration throughout a cluster. Using that command requires that ricci is running. Using ricci requires a password the first time you interact with ricci from any specific machine. For information on the ricci service, refer to Section 3.13, "Considerations for ricci " . Note Procedures in this chapter may include specific commands for some of the command-line tools listed in Appendix E, Command Line Tools Summary . For more information about all commands and variables, see the man page for each command-line tool. 8.1. Configuration Tasks Configuring Red Hat High Availability Add-On software with command-line tools consists of the following steps: Creating a cluster. Refer to Section 8.2, "Creating a Basic Cluster Configuration File" . Configuring fencing. Refer to Section 8.3, "Configuring Fencing" . Configuring failover domains. Refer to Section 8.4, "Configuring Failover Domains" . Configuring HA services. Refer to Section 8.5, "Configuring HA Services" . Verifying a configuration. Refer to Section 8.9, "Verifying a Configuration" .

Commands:
2.2.2. Securing Portmap The portmap service is a dynamic port assignment daemon for RPC services such as NIS and NFS. It has weak authentication mechanisms and has the ability to assign a wide range of ports for the services it controls. For these reasons, it is difficult to secure. Note Securing portmap only affects NFSv2 and NFSv3 implementations, since NFSv4 no longer requires it. If you plan to implement an NFSv2 or NFSv3 server, then portmap is required, and the following section applies. If running RPC services, follow these basic rules. 2.2.2.1. Protect portmap With TCP Wrappers It is important to use TCP Wrappers to limit which networks or hosts have access to the portmap service since it has no built-in form of authentication. Further, use only IP addresses when limiting access to the service. Avoid using hostnames, as they can be forged by DNS poisoning and other methods.

Commands: