mtpti5iD/redhat-docs_dataset huggingface dataset:
4.309. sudo 4.309.1. RHBA-2011:1175 - sudo bug fix and enhancement update An updated sudo package that fixes one bug and introduces one feature enhancement is now available for Red Hat Enterprise Linux 6. The sudo utility allows system administrators to give certain users the ability to run commands as root with logging. Bug Fix BZ# 709235 Prior to this update, sudo incorrectly searched for the Lightweight Directory Access Protocol (LDAP) configuration in the /etc/nss_ldap.conf file. This bug has been fixed in this update so that sudo now searches the /etc/nslcd.conf file. Enhancement BZ# 709859 Because the sudo utility needs to be run with elevated privileges, the sudo package is now built with RELRO linker flags. All users of sudo are advised to upgrade to this updated package, which fixes this bug and adds this enhancement. 4.309.2. RHBA-2012:0565 - sudo bug fix update Updated sudo packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The sudo (superuser do) utility allows system administrators to give certain users the ability to run commands as root. Bug Fixes BZ# 802440 A race condition in the signal handling code caused the sudo process to become unresponsive after receiving the SIGCHLD signal. This update modifies the signal handling to prevent the race condition, which ensures that the sudo process no longer hangs under these circumstances. BZ# 811879 The "-l" option is used to list allowed and forbidden commands for the invoking user or for the user specified by the "-U" option. However, previously, the getgrouplist() function incorrectly checked the invoker's group membership instead of the membership of the specified user. Consequently, using the "sudo" command with both the "-l" and "-U" options listed privileges granted to any group the invoker was a member of. The getgrouplist() function has been fixed to properly check the group membership of the intended user rather than checking the invoker's membership. This ensures that the required output is listed when using the "-l" and "-U options. All users of sudo are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 21. KafkaAuthorizationSimple schema reference Used in: KafkaClusterSpec Full list of KafkaAuthorizationSimple schema properties Configures the Kafka custom resource to use simple authorization and define Access Control Lists (ACLs). ACLs allow you to define which users have access to which resources at a granular level. Streams for Apache Kafka uses Kafka's built-in authorization plugins as follows: StandardAuthorizer for Kafka in KRaft mode AclAuthorizer for ZooKeeper-based Kafka Set the type property in the authorization section to the value simple , and configure a list of super users. Super users are always allowed without querying ACL rules. Access rules are configured for the KafkaUser , as described in the ACLRule schema reference . Example simple authorization configuration apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: simple superUsers: - CN=user-1 - user-2 - CN=user-3 # ... Note The super.user configuration option in the config property in Kafka.spec.kafka is ignored. Designate super users in the authorization property instead. 21.1. KafkaAuthorizationSimple schema properties The type property is a discriminator that distinguishes use of the KafkaAuthorizationSimple type from KafkaAuthorizationOpa , KafkaAuthorizationKeycloak , KafkaAuthorizationCustom . It must have the value simple for the type KafkaAuthorizationSimple . Property Property type Description type string Must be simple . superUsers string array List of super users. Should contain list of user principals which should get unlimited access rights.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # authorization: type: simple superUsers: - CN=user-1 - user-2 - CN=user-3 #
probe::signal.handle Name probe::signal.handle - Signal handler being invoked Synopsis signal.handle Values name Name of the probe point sig The signal number that invoked the signal handler sinfo The address of the siginfo table ka_addr The address of the k_sigaction table associated with the signal sig_mode Indicates whether the signal was a user-mode or kernel-mode signal sig_code The si_code value of the siginfo signal regs The address of the kernel-mode stack area (deprecated in SystemTap 2.1) oldset_addr The address of the bitmask array of blocked signals (deprecated in SystemTap 2.1) sig_name A string representation of the signal

Commands:
Chapter 3. Technology Preview and Deprecated Features 3.1. Technology Preview Features Important Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and 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. For more information see Red Hat Technology Preview Features Support Scope . The following table describes features available as Technology Previews in Red Hat Virtualization. Table 3.1. Technology Preview Features Technology Preview Feature Details NoVNC console option Option for opening a virtual machine console in the browser using HTML5. Websocket proxy Allows users to connect to virtual machines through a noVNC console. VDSM hook for nested virtualization Allows a virtual machine to serve as a host. Import Debian and Ubuntu virtual machines from VMware and RHEL 5 Xen Allows virt-v2v to convert Debian and Ubuntu virtual machines from VMware or RHEL 5 Xen to KVM. Known Issues: virt-v2v cannot change the default kernel in the GRUB2 configuration. The kernel configured on the guest operating system is not changed during the conversion, even if a more optimal version is available. After converting a Debian or Ubuntu virtual machine from VMware to KVM, the name of the virtual machine's network interface may change, and will need to be configured manually Open vSwitch cluster type support Adds Open vSwitch networking capabilities. moVirt Mobile Android app for Red Hat Virtualization. Shared and local storage in the same data center Allows the creation of single-brick Gluster volumes to enable local storage to be used as a storage domain in shared data centers. Cinderlib Integration Leverage CinderLib library to use Cinder-supported storage drivers in Red Hat Virtualization without a Full Cinder-OpenStack deployment. Adds support for Ceph storage along with Fibre Channel and iSCSI storage. The Cinder volume has multipath support on the Red Hat Virtualization Host. Intel Q35 Chipset Adds support for the Q35 machine type. Q35 is PCIe-enabled and can use UEFI (OVMF) BIOS and legacy BIOS (SeaBIOS). SSO with OpenID Connect Adds support for external OpenID Connect authentication using Keycloak in both the user interface and with the REST API. oVirt Engine Backup Adds support to back up and restore Red Hat Virtualization Manager with the Ansible ovirt-engine-backup role.

Commands:
Chapter 1. Understanding zone failure For the purpose of this section, zone failure is considered as a failure where all OpenShift Container Platform, master and worker nodes in a zone are no longer communicating with the resources in the second data zone (for example, powered down nodes). If communication between the data zones is still partially working (intermittently up or down), the cluster, storage, and network admins should disconnect the communication path between the data zones for recovery to succeed.

Commands:
Chapter 5. Provisioning Environments Table 5.1. Provisioning Environments Subcommand Description and tasks domain Create a domain: subnet org loc Add a subnet: compute-resource org loc Create a compute resource: medium Add an installation medium: partition-table Add a partition table: template Add a provisioning template: os Add an operating system:

Commands:
hammer domain create --name domain_name
hammer subnet create --name subnet_name --organization-ids org_ID1,... --location-ids loc_ID1,... --domain-ids dom_ID1,... --boot-mode boot_mode --network network_address --mask netmask --ipam ipam
hammer compute-resource create --name cr_name --organization-ids org_ID1,... --location-ids loc_ID1,... --provider provider_name
hammer medium create --name med_name --path path_to_medium
hammer partition-table create --name tab_name --path path_to_file --os-family os_family
hammer template create --name tmp_name --file path_to_template
hammer os create --name os_name --version version_num
Chapter 11. Installation and Booting A new network-scripts option: IFDOWN_ON_SHUTDOWN This update adds the IFDOWN_ON_SHUTDOWN option for network-scripts . Setting this option to yes , true , or leaving it empty has no effect. If you set this option to no , or false , it causes the ifdown calls to not be issued when stopping or restarting the network service. This can be useful in situations where NFS (or other network file system) mounts are in a stale state, because the network was shut down before the mount was cleanly unmounted. (BZ# 1583677 ) Improved content of error messages in network-scripts The network-scripts now display more verbose error messages when the installation of bonding drivers fails. (BZ#1542514) Booting from an iSCSI device that is not configured using iBFT is now supported This update provides a new installer boot option inst.nonibftiscsiboot that supports the installation of boot loader on an iSCSI device that has not been configured in the iSCSI Boot Firmware Table (iBFT). This update helps when the iBFT is not used for booting the installed system from an iSCSI device, for example, an iPXE boot from SAN features is used instead. The new installer boot option allows you to install the boot loader on an iSCSI device that is not automatically added as part of the iBFT configuration but is manually added using the iscsi Kickstart command or the installer GUI. (BZ# 1562301 ) Installing and booting from NVDIMM devices is now supported Prior to this update, Nonvolatile Dual Inline Memory Module (NVDIMM) devices in any mode were ignored by the installer. With this update, kernel improvements to support NVDIMM devices provide improved system performance capabilities and enhanced file system access for write-intensive applications like database or analytic workloads, as well as reduced CPU overhead. This update introduces support for: The use of NVDIMM devices for installation using the nvdimm Kickstart command and the GUI, making it possible to install and boot from NVDIMM devices in sector mode and reconfigure NVDIMM devices into sector mode during installation. The extension of Kickstart scripts for Anaconda with commands for handling NVDIMM devices. The ability of grub2 , efibootmgr , and efivar system components to handle and boot from NVDIMM devices. (BZ# 1612965 , BZ#1280500, BZ#1590319, BZ#1558942) The --noghost option has been added to the rpm -V command This update adds the --noghost option to the rpm -V command. If used with this option, rpm -V verifies only the non-ghost files that were altered, which helps diagnose system problems. (BZ# 1395818 )

Commands:
23.8. Enforcing a Specific Authentication Indicator When Obtaining a Ticket from the KDC To enforce a specific authentication indicator on: A host object, execute: A Kerberos service, execute: To set multiple authentication indicators, specify the --auth-ind parameter multiple times. Warning Setting an authentication indicator to the HTTP/ IdM_master service causes the IdM master to fail. Additionally, the utilities provided by IdM do not enable you to restore the master. Example 23.2. Enforcing the pkinit Indicator on a Specific Host The following command configures that only the users authenticated through a smart card can obtain a service ticket for the host.idm.example.com host: The setting above ensures that the ticket-granting ticket (TGT) of a user requesting a Kerberos ticket, contains the pkinit authentication indicator.

Commands:
ipa host-mod host_name --auth-ind= indicator
ipa service-mod service / host_name --auth-ind= indicator
ipa host-mod host.idm.example.com --auth-ind=pkinit
Chapter 4. Installing a cluster on vSphere using the Assisted Installer You can install OpenShift Container Platform on on-premise hardware or on-premise VMs by using the Assisted Installer. Installing OpenShift Container Platform by using the Assisted Installer supports x86_64 , AArch64 , ppc64le , and s390x CPU architectures. The Assisted Installer is a user-friendly installation solution offered on the Red Hat Hybrid Cloud Console. The Assisted Installer supports the various deployment platforms with a focus on the following infrastructures: Bare metal Nutanix vSphere 4.1. Additional resources Installing OpenShift Container Platform with the Assisted Installer

Commands:
1.2. KVM Performance Architecture Overview The following points provide a brief overview of KVM as it pertains to system performance, as well as process and thread management: When using KVM, guests run as a Linux processes on the host. Virtual CPUs (vCPUs) are implemented as normal threads, handled by the Linux scheduler. Guests do not automatically inherit features such as NUMA and huge pages from the kernel. Disk and network I/O settings in the host have a significant performance impact. Network traffic typically travels through a software-based bridge. Depending on the devices and their models, there might be significant overhead due to emulation of that particular hardware.

Commands:
probe::vm.pagefault.return Name probe::vm.pagefault.return - Indicates what type of fault occurred Synopsis vm.pagefault.return Values name name of the probe point fault_type returns either 0 (VM_FAULT_OOM) for out of memory faults, 2 (VM_FAULT_MINOR) for minor faults, 3 (VM_FAULT_MAJOR) for major faults, or 1 (VM_FAULT_SIGBUS) if the fault was neither OOM, minor fault, nor major fault.

Commands:
function::ctime Name function::ctime - Convert seconds since epoch into human readable date/time string Synopsis Arguments epochsecs Number of seconds since epoch (as returned by gettimeofday_s ) Description Takes an argument of seconds since the epoch as returned by gettimeofday_s . Returns a string of the form " Wed Jun 30 21:49:08 1993 " The string will always be exactly 24 characters. If the time would be unreasonable far in the past (before what can be represented with a 32 bit offset in seconds from the epoch) an error will occur (which can be avoided with try/catch). If the time would be unreasonable far in the future, an error will also occur. Note that the epoch (zero) corresponds to " Thu Jan 1 00:00:00 1970 " The earliest full date given by ctime, corresponding to epochsecs -2147483648 is " Fri Dec 13 20:45:52 1901 " . The latest full date given by ctime, corresponding to epochsecs 2147483647 is " Tue Jan 19 03:14:07 2038 " . The abbreviations for the days of the week are 'Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', and 'Sat'. The abbreviations for the months are 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', and 'Dec'. Note that the real C library ctime function puts a newline ('\n') character at the end of the string that this function does not. Also note that since the kernel has no concept of timezones, the returned time is always in GMT.

Commands:
ctime:string(epochsecs:long)
2.3.2. Disabling ACPI Soft-Off with the BIOS The preferred method of disabling ACPI Soft-Off is with chkconfig management ( Section 2.3.1, "Disabling ACPI Soft-Off with chkconfig Management" ). However, if the preferred method is not effective for your cluster, follow the procedure in this section. Note Disabling ACPI Soft-Off with the BIOS may not be possible with some computers. You can disable ACPI Soft-Off by configuring the BIOS of each cluster node as follows: Reboot the node and start the BIOS CMOS Setup Utility program. Navigate to the Power menu (or equivalent power management menu). At the Power menu, set the Soft-Off by PWR-BTTN function (or equivalent) to Instant-Off (or the equivalent setting that turns off the node via the power button without delay). Example 2.11, " BIOS CMOS Setup Utility : Soft-Off by PWR-BTTN set to Instant-Off " shows a Power menu with ACPI Function set to Enabled and Soft-Off by PWR-BTTN set to Instant-Off . Note The equivalents to ACPI Function , Soft-Off by PWR-BTTN , and Instant-Off may vary among computers. However, the objective of this procedure is to configure the BIOS so that the computer is turned off via the power button without delay. Exit the BIOS CMOS Setup Utility program, saving the BIOS configuration. When the cluster is configured and running, verify that the node turns off immediately when fenced. Note You can fence the node with the fence_node command or Conga . Example 2.11. BIOS CMOS Setup Utility : Soft-Off by PWR-BTTN set to Instant-Off This example shows ACPI Function set to Enabled , and Soft-Off by PWR-BTTN set to Instant-Off .

Commands:
+-------------------------------------------------|------------------------+ | ACPI Function [Enabled] | Item Help | | ACPI Suspend Type [S1(POS)] |------------------------| | x Run VGABIOS if S3 Resume Auto | Menu Level * | | Suspend Mode [Disabled] | | | HDD Power Down [Disabled] | | | Soft-Off by PWR-BTTN [Instant-Off] | | | CPU THRM-Throttling [50.0%] | | | Wake-Up by PCI card [Enabled] | | | Power On by Ring [Enabled] | | | Wake Up On LAN [Enabled] | | | x USB KB Wake-Up From S3 Disabled | | | Resume by Alarm [Disabled] | | | x Date(of Month) Alarm 0 | | | x Time(hh:mm:ss) Alarm 0 : 0 : 0 | | | POWER ON Function [BUTTON ONLY] | | | x KB Power ON Password Enter | | | x Hot Key Power ON Ctrl-F1 | | | | | | | | +-------------------------------------------------|------------------------+
Chapter 14. Accessing the CUPS documentation CUPS provides browser-based access to the service's documentation that is installed on the CUPS server. This documentation includes: Administration documentation, such as for command-line printer administration and accounting Man pages Programming documentation, such as the administration API References Specifications Prerequisites CUPS is installed and running . The IP address of the client you want to use has permissions to access the web interface. Procedure Use a browser, and access http:// <hostname_or_ip_address> :631/help/ : Expand the entries in Online Help Documents , and select the documentation you want to read.

Commands:
Chapter 3. SCAP content in Satellite SCAP content is a SCAP data-stream file that contains implementation of compliance, configuration, or security baselines. A single data stream usually includes multiple XCCDF profiles. An XCCDF profile defines an industry standard or custom security standard against which you can evaluate compliance of host configuration in Satellite, such as Protection Profile for General Purpose Operating Systems (OSPP), Health Insurance Portability and Accountability Act (HIPAA), and PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 9. You can adapt existing XCCDF profiles according to your requirements using tailoring files . In Satellite, you use an XCCDF profile from SCAP content and, eventually, a tailoring file, to define a compliance policy . Satellite includes default SCAP contents from SCAP Security Guide provided by the OpenSCAP project . For more information on how to download, deploy, modify, and create your own content, see: Red Hat Enterprise Linux 9 Security hardening Red Hat Enterprise Linux 8 Security hardening Red Hat Enterprise Linux 7 Security Guide Red Hat Enterprise Linux 6 Security Guide 3.1. Supported SCAP versions Satellite supports content of SCAP versions 1.2 and 1.3.

Commands:
Chapter 28. Defining Password Policies This chapter describes what password policies in Identity Management (IdM) are and how to manage them. 28.1. What Are Password Policies and Why Are They Useful A password policy is a set of rules that passwords must meet. For example, a password policy can define minimum password length and maximum password lifetime. All users affected by such a policy are required to set a sufficiently long password and change it frequently enough. Password policies help reduce the risk of someone discovering and misusing a user's password.

Commands:
Chapter 1. Overview of Red Hat Ansible Automation Platform Red Hat Ansible Automation Platform simplifies the development and operation of automation workloads for managing enterprise application infrastructure lifecycles. Ansible Automation Platform works across multiple IT domains, including operations, networking, security, and development, as well as across diverse hybrid environments. Simple to adopt, use, and understand, Ansible Automation Platform provides the tools needed to rapidly implement enterprise-wide automation, no matter where you are in your automation journey. 1.1. What is included in the Ansible Automation Platform Ansible Automation Platform Automation controller Automation hub Event-Driven Ansible controller Insights for Ansible Automation Platform Platform gateway (Unified UI) 2.5 4.6.0 4.10.0 hosted service 1.1.0 hosted service 1.1 1.2. Red Hat Ansible Automation Platform life cycle Red Hat provides different levels of maintenance for each Ansible Automation Platform release. For more information, see Red Hat Ansible Automation Platform Life Cycle .

Commands: