mtpti5iD/redhat-docs_dataset huggingface dataset:
20.19. Memory Balloon Device A virtual memory balloon device is added to all Xen and KVM/QEMU guest virtual machines. It will be seen as <memballoon> element. It will be automatically added when appropriate, so there is no need to explicitly add this element in the guest virtual machine XML unless a specific PCI slot needs to be assigned. Note that if the memballoon device needs to be explicitly disabled, model='none' may be used. The following example automatically added device with KVM ... <devices> <memballoon model='virtio'/> </devices> ... Figure 20.67. Memory balloon device Here is an example where the device is added manually with static PCI slot 2 requested ... <devices> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </memballoon> </devices> </domain> Figure 20.68. Memory balloon device added manually The required model attribute specifies what type of balloon device is provided. Valid values are specific to the virtualization platform are: 'virtio' which is the default setting with the KVM hypervisor or 'xen' which is the default setting with the Xen hypervisor.

Commands:
<devices> <memballoon model='virtio'/> </devices>
<devices> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </memballoon> </devices> </domain>
probe::signal.do_action Name probe::signal.do_action - Examining or changing a signal action Synopsis signal.do_action Values sigact_addr The address of the new sigaction struct associated with the signal sig_name A string representation of the signal sa_mask The new mask of the signal sa_handler The new handler of the signal oldsigact_addr The address of the old sigaction struct associated with the signal sig The signal to be examined/changed name Name of the probe point

Commands:
4.6. Dell Drac 5 Table 4.7, "Dell DRAC 5" lists the fence device parameters used by fence_drac5 , the fence agent for Dell DRAC 5. Table 4.7. Dell DRAC 5 luci Field cluster.conf Attribute Description Name name The name assigned to the DRAC. IP Address or Hostname ipaddr The IP address or host name assigned to the DRAC. IP Port (optional) ipport The TCP port to use to connect to the device. Login login The login name used to access the DRAC. Password passwd The password used to authenticate the connection to the DRAC. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Use SSH secure Indicates that the system will use SSH to access the device. When using SSH, you must specify either a password, a password script, or an identity file. SSH Options ssh_options SSH options to use. The default value is -1 -c blowfish . Path to SSH Identity File identity_file The identity file for SSH. Module Name module_name (optional) The module name for the DRAC when you have multiple DRAC modules. Force Command Prompt cmd_prompt The command prompt to use. The default value is '\USD'. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Delay (seconds) delay The number of seconds to wait before fencing is started. The default value is 0. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Figure 4.6, "Dell Drac 5" shows the configuration screen for adding a Dell Drac 5 device Figure 4.6. Dell Drac 5 The following command creates a fence device instance for a Dell Drac 5 device: The following is the cluster.conf entry for the fence_drac5 device:

Commands:
ccs -f cluster.conf --addfencedev delldrac5test1 agent=fence_drac5 ipaddr=192.168.0.1 login=root passwd=password123 module_name=drac1 power_wait=60
<fencedevices> <fencedevice agent="fence_drac5" cmd_prompt="\USD" ipaddr="192.168.0.1" login="root" module_name="drac1" name="delldrac5test1" passwd="password123" power_wait="60"/> </fencedevices>
Chapter 18. Policy: Using Automount Automount is a way of making directories on different servers available, automatically, when requested by a user. This works exceptionally well within an IdM domain since it allows directories on clients within the domain to be shared easily. This is especially important with user home directories ( Section 9.1, "Setting up User Home Directories" ). In IdM, automount works with the internal LDAP directory and, if it is configured, DNS services. 18.1. About Automount and IdM Automount is a way to manage, organize, and access directories across multiple systems. Automount automatically mounts a directory whenever that resource is requested. Automount also provides a coherent structure to the way that these directories are organized. Every single directory, or mount point is called a key . Multiple keys that are grouped together are a map , and maps are associated according to their physical or conceptual location . The base configuration file for automount is the auto.master file in the /etc/ directory. There can be multiple auto.master configuration files in separate server locations, if necessary. When autofs is configured on a server and that server is a client in an IdM domain, then all of the configuration information for automount is stored in the IdM directory. Rather than being stored in separate text files, the autofs configuration - maps, locations, and keys - are stored as LDAP entries. For example, the default map file, auto.master , is stored as: Important Identity Management does not set up or configure autofs. That must be done separately. Identity Management works with an existing autofs deployment. Each new location is added as a container entry under cn=automount,dc=example,dc=com , and each map and each key are stored beneath that location. As with other IdM domain services, automount works with IdM natively. The automount configuration can be managed by IdM tools: Locations , using ipa automountlocation* commands Both direct and indirect maps , using ipa automountmap* commands Keys , using ipa automountkey* commands For automount to work within the IdM domain, the NFS server must be configured as an IdM client. Configuring NFS itself is covered in the Red Hat Enterprise Linux Storage Administration Guide .

Commands:
dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com objectClass: automountMap objectClass: top automountMapName: auto.master
4.2. Attaching an export storage domain Before converting virtual machines to run on Red Hat Enterprise Virtualization, you must attach an export storage domain to the Red Hat Enterprise Virtualization data center being used. An export storage domain can be attached to a data center to enable the import or export of virtual machines from one data center to another. An export storage domain can also be used to backup virtual machines and templates. Note At a given time, an export domain can only be attached to a single data center. Procedure 4.1. Attaching an export storage domain Log in to the Red Hat Enterprise Virtualization Administration Portal. Click the Data Centers tab. Select the data center to which the export storage domain is to be attached. The details pane displays. Select the Storage tab. Click Attach Export to add the storage location where the images are stored. Figure 4.1. Attaching an Export Domain The Attach Export Domain dialog box displays if there are export domains available. Select the export domain from the list. Click the OK button. The new export storage domain displays on the Storage tab of the details pane with a status of Locked , followed by Inactive . Select the new export storage domain on the Storage tab of the details pane, and click the Activate button. The export domain will be activated in a few moments and display an Active status.

Commands:
Chapter 5. Attesting and validating a container image Before Enterprise Contract can validate your signed container image, you must first create SLSA provenance and associate it with your container image. Provenance is the verifiable information about software artifacts, including where, when, and how a given software "link" in a supply chain was produced. For more information about Supply-chain Levels for Software Artifacts (SLSA) provenance, see SLSA Provenance . Prerequisites A signed container image. Access to the OpenShift web console. A working Red Hat Trusted Artifact Signer installation running on OpenShift version 4.13 or later. A workstation with the cosign and oc binary files installed. Procedure Create a SLSA provenance predicate.json file; for example: Sign and attest the predicate.json file you just created; for example: Keycloak opens to automatically authenticate you based on your login when you signed your container image. Verify the signature and attestation with Enterprise Contract, for example: Important Be as specific as possible when you run the ec validate image command so that each signature matches the expected identity . Verification When Enterprise Contract has validated your container image, a detailed report of all Enterprise Contract verifications and signatures opens. Additional resources For more information about Red Hat Trusted Artifact Signer, and especially about how it works with RHTAP and Enterprise Contract, see Red Hat Trusted Artifact Signer Deployment . For more information about SLSA, see slsa.dev . For more information about Keycloak, see keycloak.org .

Commands:
echo '{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://localhost/dummy-type", "invocation": {}, "buildConfig": {}, "metadata": { "buildStartedOn": "2023-09-25T16:26:44Z", "buildFinishedOn": "2023-09-25T16:28:59Z", "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] } ' > predicate.json
cosign attest -y --fulcio-url=USDFULCIO_URL --rekor-url=USDREKOR_URL --oidc-issuer=USDOIDC_ISSUER_URL --predicate predicate.json --type slsaprovenance USDIMAGE
ec validate image --image USDIMAGE --certificate-identity-regexp '.*' --certificate-oidc-issuer-regexp '.*' --output yaml --show-successes
B.79.2. RHSA-2011:0406 - Moderate: quagga security update Updated quagga packages that fix two security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Quagga is a TCP/IP based routing software suite. The Quagga bgpd daemon implements the BGP (Border Gateway Protocol) routing protocol. CVE-2010-1675 A denial of service flaw was found in the way the Quagga bgpd daemon processed certain route metrics information. A BGP message with a specially-crafted path limit attribute would cause the bgpd daemon to reset its session with the peer through which this message was received. CVE-2010-1674 A NULL pointer dereference flaw was found in the way the Quagga bgpd daemon processed malformed route extended communities attributes. A configured BGP peer could crash bgpd on a target system via a specially-crafted BGP message. Users of quagga should upgrade to these updated packages, which contain backported patches to correct these issues. After installing the updated packages, the bgpd daemon must be restarted for the update to take effect.

Commands:
Chapter 19. tags Optional. An operator-defined list of tags placed on each log by the collector or normalizer. The payload can be a string with whitespace-delimited string tokens or a JSON list of string tokens. Data type text file The path to the log file from which the collector reads this log entry. Normally, this is a path in the /var/log file system of a cluster node. Data type text offset The offset value. Can represent bytes to the start of the log line in the file (zero- or one-based), or log line numbers (zero- or one-based), so long as the values are strictly monotonically increasing in the context of a single log file. The values are allowed to wrap, representing a new version of the log file (rotation). Data type long

Commands:
Chapter 1. Overview AMQ Broker is a high-performance messaging implementation based on ActiveMQ Artemis. It uses an asynchronous journal for fast message persistence, and supports multiple languages, protocols, and platforms. 1.1. Key features AMQ Broker provides the following features: Clustering and high availability options Fast, native-IO persistence Supports local transactions Supports XA transactions when using AMQ Core Protocol JMS and AMQ OpenWire JMS clients Written in Java for broad platform support Multiple management interfaces: AMQ Management Console, Management APIs, and JMX 1.2. Supported standards and protocols AMQ Broker supports the following standards and protocols: Wire protocols: Core Protocol AMQP 1.0 MQTT OpenWire (Used by A-MQ 6 clients) STOMP JMS 2.0 Note The details of distributed transactions (XA) within AMQP are not provided in the 1.0 version of the specification. If your environment requires support for distributed transactions, it is recommended that you use the AMQ Core Protocol JMS. 1.3. Supported configurations Refer to the article " Red Hat AMQ 7 Supported Configurations " on the Red Hat Customer Portal for current information regarding AMQ Broker supported configurations. 1.4. Document conventions This document uses the following conventions for the sudo command, file paths, and replaceable values. The sudo command In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo , as any changes can affect the entire system. For more information about using sudo , see Managing sudo access . About the use of file paths in this document In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/... ). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\... ). Replaceable values This document sometimes uses replaceable values that you must replace with values specific to your environment. Replaceable values are lowercase, enclosed by angle brackets ( < > ), and are styled using italics and monospace font. Multiple words are separated by underscores ( _ ) . For example, in the following command, replace <install_dir> with your own directory name. USD <install_dir> /bin/artemis create mybroker

Commands:
<install_dir> /bin/artemis create mybroker
4.4. Tuning Tasks with Tuna To change policy and priority information on threads, use the --priority parameter: The pid_or_cmd_list argument is a list of comma-separated PIDs or command-name patterns. Set the policy to RR for round-robin, FIFO for first in, first out, or OTHER for the default policy. For an overview of the scheduling policies, see Section 6.3.6, "Tuning Scheduling Policy" . Set the rt_priority in the range 1-99. 1 is the lowest priority, and 99 is the highest priority. For example: To verify the changes you set, use the --show_threads parameter both before and after the modifying --priority parameter: This allows you to compare the state of the selected threads before and after your changes.

Commands:
tuna --threads= pid_or_cmd_list --priority=[ policy : ] rt_priority
tuna --threads=7861 --priority=RR:40
tuna --threads=sshd --show_threads --priority=RR:40 --show_threads thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 1034 OTHER 0 0,1,2,3 12 17 sshd thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 1034 RR 40 0,1,2,3 12 17 sshd
Chapter 7. Creating an instance with a VDPA interface Important This feature is available in this release as a Technology Preview , and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details . You can create an instance with a VDPA interface by requesting a port for your instance that has a vNIC type of VDPA. Limitations You cannot suspend, live migrate, shelve, or evacuate an instance that has a VDPA interface. You cannot detach the VDPA interface from an instance and then reattach it to the instance. Procedure Create a network that is mapped to the physical network: Create a subnet for the network: Create a port from a VDPA-enabled NIC: Create an instance, specifying the NIC port to use: An "ACTIVE" status in the output indicates that you have successfully created the instance on a host that can provide the requested VDPA interface.

Commands:
openstack network create vdpa_network --provider-physical-network tenant --provider-network-type vlan --provider-segment 1337
openstack subnet create vdpa_subnet --network vdpa_net1 --subnet-range 192.0.2.0/24 --dhcp
openstack port create vdpa_direct_port --network vdpa_network --vnic-type vdpa \
openstack server create vdpa_instance --flavor cirros256 --image cirros-0.3.5-x86_64-disk --nic port-id=vdpa_direct_port --wait
30.2.2. Configuring PXE Boot for EFI If tftp-server is not yet installed, run yum install tftp-server . In the tftp-server config file at /etc/xinetd.d/tftp , change the disable parameter from yes to no . Create a directory within tftpboot for the EFI boot images, and then copy them from your boot directory. In these examples we will name the subdirectory pxelinux , but any other name could be used. Configure your DHCP server to use the EFI boot images packaged with GRUB. (If you do not have a DHCP server installed, refer to the DHCP Servers chapter in the Red Hat Enterprise Linux Deployment Guide .) A sample configuration in /etc/dhcp/dhcpd.conf might look like: Add a config file to /var/lib/tftpboot/pxelinux . The file should either be named efidefault or named after the IP address, converted into hexadecimal format without delimiters. For example, if your machine's IP address is 10.0.0.1, the filename would be 0A000001 . A sample config file at /var/lib/tftpboot/pxelinux/efidefault might look like: For instructions on how to specify the installation source, refer to Section 7.1.3, "Additional Boot Options" Copy the splash image into your tftp root directory: Copy the boot images into your tftp root directory: Boot the client system, and select the network device as your boot device when prompted.

Commands:
mkdir /var/lib/tftpboot/pxelinux cp /boot/efi/EFI/redhat/grub.efi /var/lib/tftpboot/pxelinux/bootx64.efi
option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; # RFC4578 subnet 10.0.0.0 netmask 255.255.255.0 { option routers 10.0.0.254; range 10.0.0.2 10.0.0.253; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; next-server 10.0.0.1; if option arch = 00:06 { filename "pxelinux/bootia32.efi"; } else if option arch = 00:07 { filename "pxelinux/bootx64.efi"; } else { filename "pxelinux/pxelinux.0"; } } host example-ia32 { hardware ethernet XX:YY:ZZ:11:22:33; fixed-address 10.0.0.2; } }
default=0 timeout=1 splashimage=(nd)/splash.xpm.gz hiddenmenu title RHEL root (nd) kernel /rhel6/vmlinuz initrd /rhel6/initrd.img
cp /boot/grub/splash.xpm.gz /var/lib/tftpboot/pxelinux/splash.xpm.gz
cp / path/to /x86_64/os/images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/pxelinux/rhel6/
Chapter 15. Cron jobs Several repetitive tasks are automatically scheduled and run in Red Hat Update Infrastructure, on the RHUA node in particular. Table 15.1. Cron jobs Job file Purpose Frequency Log file /etc/cron.d/rhui-export-repos export synchronized content every 5 minutes /var/log/rhui/rhui-export-repos.log /etc/cron.d/rhui-purge-upload-dirs clean up temporary directories from uploads to custom repositories every 5 minutes /var/log/rhui/rhui-purge-upload-dirs.log.log /etc/cron.d/rhui-repo-sync synchronize repositories, if they are due every 5 minutes /var/log/cron (see the note below) /etc/cron.d/rhui-update-mappings update the information about available minor versions hourly, at HH:34 /var/log/rhui/rhui-update-mappings.log /etc/cron.hourly/synchronize-rhui-subscriptions check for changes to the entitlement certificate, and import a new one if needed hourly, at HH:01 /var/log/rhui/rhui-subscription-sync.log Note The output is sent to the root user by e-mail instead of the /var/log/cron file if a Mail Transport Agent, such as Postfix, is installed and running on the RHUA. For more information, see Deploying and configuring a Postfix SMTP server .

Commands:
Chapter 9. Deleting files from your bucket To delete files from your bucket from your workbench, use the delete_file() method. Prerequisites You have cloned the odh-doc-examples repository to your workbench. You have opened the s3client_examples.ipynb file in your workbench. You have installed Boto3 and configured an S3 client. You know the key of the file you want to delete and the bucket that the file is located in. Procedure In the notebook, locate the following instructions to delete files from a bucket: Replace <bucket_name> with the name of your bucket and <key> with the key of the file you want to delete, as shown in the example. Run the code cell. The output displays a HTTP response status code of 204 , which indicates that the request was successful. Verification Locate the following instructions to list files in a bucket: Replace <bucket_name> with the name of your bucket, as shown in the example and run the code cell. The deleted file does not appear in the output.

Commands:
#Delete files from bucket s3_client.delete_object(Bucket='<bucket_name>', Key='<object_key>')
#Delete object from bucket s3_client.delete_object(Bucket='aqs971-image-registry', Key='/tmp/series43-image12-086.csv')
#Delete Object Verification bucket_name = '<bucket_name>' for key in s3_client.list_objects_v2(Bucket=bucket_name)['Contents']: print(key['Key'])
#Delete Object Verification bucket_name = 'aqs971-image-registry' for key in s3_client.list_objects_v2(Bucket=bucket_name)['Contents']: print(key['Key'])