mtpti5iD/redhat-docs_dataset huggingface dataset:
5.349. virt-manager 5.349.1. RHBA-2012:0785 - virt-manager bug fix and enhancement update Updated virt-manager packages that fix multiple bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The Virtual Machine Manager (virt-manager) is a graphical tool for administering Kernel-based Virtual Machines (KVM) using libvirt. Bug Fixes BZ# 741937 , BZ# 769192 Prior to this update, the virt-manager tool did not change all required XML elements when changing the disk bus of a guest from IDE to virtio, or vice versa. As a consequence, virt-manager could create invalid XML elements that libvirt accepted but then the guest failed to boot. This update modifies the underlying code to change all required XML elements and guests start now as expected. BZ# 742055 Prior to this update, the virt-manager tool could, under certain circumstances, receive an error from libvirt if virt-manager tried to read a domain's information while that domain was shutting down. As a consequence, the libvirt connection in the user interface (UI) was incorrectly closed. This update modifies the underlying code to expect errors in this case and not close the libvirt connection. BZ# 747490 Prior to this update, the glib integration did not work correctly. As a consequence, serial consoles of virtual machines could stall when transferring large amounts of data. This update modifies the underlying code to allow the transfer of larger amounts of data without stalling. BZ# 750225 Prior to this update, graphical scaling did not work for SPICE graphics in the virt-manager tool. This update modifies the underlying code to connect the UI scaling selection element to the spice back end. BZ# 803600 Prior to this update, the virt-manager tool could close with a segmentation fault if the user deleted several storage volumes in quick succession due to data locking when deleting the storage volume. This update modifies the virt-manager threads to allow deleting of storage volumes in quick succession. BZ# 811316 Prior to this update, the virt-manager tool could, did not correctly clean up certain internal state. As a consequence, closing and reopening a graphical window of a guest did not reopen the graphical console. This update modifies the underlying code to ensure that the graphical console connection is correctly reopened. BZ# 816279 Prior to this update, the virt-manager tool did not correctly using the graphics listen address attribute in the configuration of the virtual machine, and would always try to connect to the guest with an SSH tunnel. This could break graphical console connections if "listen=" was set to an explicit interface address. This update modifies the underlying code to ensure that virt-manager now correctly connects to these addresses. Enhancement BZ# 716673 Prior to this update, the default disk image format for disk images used for newly created virtual machines was "raw" and could not be changed. This update adds the new "qcow2" option. All users of virt-manager are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 4. Certification testing The certification testing briefs about the prerequisites for testing, understanding the certification process, and its requirements. 4.1. Prerequistes for certification testing Bare-metal certification The corresponding RHEL server certification is successfully completed and posted. The corresponding Red Hat OpenStack Platform Compute Node certification is successfully completed and posted. The corresponding bare-metal driver is on the supported Drivers List for the corresponding Red Hat OpenStack Platform release. 4.2. Certification workflow The Red Hat Bare Metal Hardware certification process includes the following requirements and steps: Figure 4.1. Red Hat OpenStack Platform Bare Metal Hardware Certification Process 4.3. Certification requirements Ensure you follow the Red Hat OpenStack bare metal hardware guide . Additional details for the certification requirements include: The Host Under Test (HUT) must already be RHEL certified. Additionally, the tests must run on a previously certified server, and all the tests prescribed in the test plan must be executed in a single run. If you have a failed test, take the corrective action and execute all the tests in a single run . Open a support case if necessary for guidance.

Commands:
Chapter 6. Troubleshooting upgrade error messages The following table shows some cephadm upgrade error messages. If the cephadm upgrade fails for any reason, an error message appears in the storage cluster health status. Error Message Description UPGRADE_NO_STANDBY_MGR Ceph requires both active and standby manager daemons to proceed, but there is currently no standby. UPGRADE_FAILED_PULL Ceph was unable to pull the container image for the target version. This can happen if you specify a version or container image that does not exist (e.g., 1.2.3), or if the container registry is not reachable from one or more hosts in the cluster.

Commands:
Chapter 2. Enable Basic authentication Enable Basic authentication for your Quarkus project and allow users to authenticate with a username and password. 2.1. Prerequisites You have installed at least one extension that provides an IdentityProvider based on username and password. For example: Quarkus Security Jakarta Persistence extension ( quarkus-security-jpa ) Elytron security properties file extension (quarkus-elytron-security-properties-file) Elytron security JDBC extension (quarkus-elytron-security-jdbc) The following procedure outlines how you can enable Basic authentication for your application by using the elytron-security-properties-file extension. 2.2. Procedure In the application.properties file, set the quarkus.http.auth.basic property to true . quarkus.http.auth.basic=true Optional: In a non-production environment only and purely for testing Quarkus Security in your applications: To enable authentication for the embedded realm, set the quarkus.security.users.embedded.enabled property to true . security.users.embedded.enabled=true You can also configure the required user credentials, user name, secret, and roles. For example: quarkus.http.auth.basic=true quarkus.security.users.embedded.enabled=true quarkus.security.users.embedded.plain-text=true quarkus.security.users.embedded.users.alice=alice 1 quarkus.security.users.embedded.users.bob=bob 2 quarkus.security.users.embedded.roles.alice=admin 3 quarkus.security.users.embedded.roles.bob=user 4 1 3 The user, alice , has alice as their password and admin as their role. 2 4 The user, bob , has bob as their password and user as their role. For information about other methods that you can use to configure the required user credentials, see the Configuring User Information section of the Quarkus "Security Testing" guide. Important Configuring user names, secrets, and roles in the application.properties file is appropriate only for testing scenarios. For securing a production application, it is crucial to use a database to store this information. 2.3. steps For a more detailed walk-through that shows you how to configure Basic authentication together with Jakarta Persistence for storing user credentials in a database, see the Getting started with Security by using Basic authentication and Jakarta Persistence guide. 2.4. References Quarkus Security overview Identity Providers Configuring User Information in application.properties Basic authentication

Commands:
quarkus.http.auth.basic=true
security.users.embedded.enabled=true
quarkus.http.auth.basic=true quarkus.security.users.embedded.enabled=true quarkus.security.users.embedded.plain-text=true quarkus.security.users.embedded.users.alice=alice 1 quarkus.security.users.embedded.users.bob=bob 2 quarkus.security.users.embedded.roles.alice=admin 3 quarkus.security.users.embedded.roles.bob=user 4
3.9. Relatime Drive Access Optimization The POSIX standard requires that operating systems maintain file system metadata that records when each file was last accessed. This timestamp is called atime , and maintaining it requires a constant series of write operations to storage. These writes keep storage devices and their links busy and powered up. Since few applications make use of the atime data, this storage device activity wastes power. Significantly, the write to storage would occur even if the file was not read from storage, but from cache. For some time, the Linux kernel has supported a noatime option for mount and would not write atime data to file systems mounted with this option. However, simply turning off this feature is problematic because some applications rely on atime data and will fail if it is not available. The kernel used in Red Hat Enterprise Linux 7 supports another alternative - relatime . Relatime maintains atime data, but not for each time that a file is accessed. With this option enabled, atime data is written to the disk only if the file has been modified since the atime data was last updated ( mtime ), or if the file was last accessed more than a certain length of time ago (by default, one day). By default, all filesystems are now mounted with relatime enabled. You can suppress it for any particular file system by mounting that file system with the option norelatime .

Commands:
Chapter 4. Extending the JDBC Translator 4.1. Extensions New custom Translators can be created by extending the JDBC Translator. This is one of the most common use-cases for custom Translator development and is often done to add support for JDBC drivers and database versions. To design a JDBC Translator for any relational database management system (RDBMS) that is not already supported by Red Hat JBoss Data Virtualization, extend the org.teiid.translator.jdbc.JDBCExecutionFactory class in the translator-jdbc module. There are three types of methods that you can override from the base class to define the behavior of the Translator. Table 4.1. Extensions Extension Purpose Capabilities Specify the SQL syntax and functions the source supports. SQL Translation Customize what SQL syntax is used, how source-specific functions are supported, how procedures are executed. Results Translation Customize how results are retrieved from JDBC and translated.

Commands:
Chapter 3. Managing roles on dashboard As a storage administrator, you can create, view, edit, and delete roles on the dashboard. You can give permissions to the roles and you can assign specific roles for users. 3.1. Creating roles on dashboard The dashboard allows you to create roles on the dashboard which can be assigned to the users. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : On Roles tab, click the Create button: In the CreateRole window, set the Name and select the Permissions for this role, and then click the CreateRole button: A notification towards the top right corner of the page indicates the role was created successfully. 3.2. Viewing roles on dashboard The dashboard allows you to view the details of the roles on the dashboard. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the dashboard. Roles are created on the dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : To view the details of the role, click the row: You can see the details of the permissions provided for the roles. Additional Resources See the Creating roles on the dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details. 3.3. Editing roles on dashboard The dashboard allows you to edit roles on the dashboard. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. A role is created on the dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : To edit the role, click the row: On the Roles tab, select Edit from the Edit dropdown menu: In the EditRole window, edit parameters including, and then click the EditRole button: A notification towards the top right corner of the page indicates the role was updated successfully. Additional Resources See the Creating roles on the dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details. 3.4. Deleting roles on dashboard The dashboard allows you to delete roles on the dashboard. Note You can only delete the roles that you have created. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. Admin level of access to the Dashboard. A role is created on the dashboard. Procedure Log in to the Dashboard. On the upper right side of the Dashboard, click the gear icon and select User management : To delete the role, click the row: On Roles tab, select Delete from the Edit dropdown menu: In the Delete Role dialog window, Click the Yes, I am sure box and then Click Delete Role to save the settings: Additional Resources See the Creating roles on the dashboard section in the Red Hat Ceph Storage Dashboard Guide for more details.

Commands:
Chapter 1. Provisioning APIs 1.1. BMCEventSubscription [metal3.io/v1alpha1] Description BMCEventSubscription is the Schema for the fast eventing API Type object 1.2. BareMetalHost [metal3.io/v1alpha1] Description BareMetalHost is the Schema for the baremetalhosts API Type object 1.3. FirmwareSchema [metal3.io/v1alpha1] Description FirmwareSchema is the Schema for the firmwareschemas API Type object 1.4. HardwareData [metal3.io/v1alpha1] Description HardwareData is the Schema for the hardwaredata API Type object 1.5. HostFirmwareSettings [metal3.io/v1alpha1] Description HostFirmwareSettings is the Schema for the hostfirmwaresettings API Type object 1.6. Metal3Remediation [infrastructure.cluster.x-k8s.io/v1beta1] Description Metal3Remediation is the Schema for the metal3remediations API. Type object 1.7. Metal3RemediationTemplate [infrastructure.cluster.x-k8s.io/v1beta1] Description Metal3RemediationTemplate is the Schema for the metal3remediationtemplates API. Type object 1.8. PreprovisioningImage [metal3.io/v1alpha1] Description PreprovisioningImage is the Schema for the preprovisioningimages API Type object 1.9. Provisioning [metal3.io/v1alpha1] Description Provisioning contains configuration used by the Provisioning service (Ironic) to provision baremetal hosts. Provisioning is created by the OpenShift installer using admin or user provided information about the provisioning network and the NIC on the server that can be used to PXE boot it. This CR is a singleton, created by the installer and currently only consumed by the cluster-baremetal-operator to bring up and update containers in a metal3 cluster. Type object

Commands:
4.9. Configuring atime Updates Each file inode and directory inode has three time stamps associated with it: ctime - The last time the inode status was changed mtime - The last time the file (or directory) data was modified atime - The last time the file (or directory) data was accessed If atime updates are enabled as they are by default on GFS2 and other Linux file systems then every time a file is read, its inode needs to be updated. Because few applications use the information provided by atime , those updates can require a significant amount of unnecessary write traffic and file locking traffic. That traffic can degrade performance; therefore, it may be preferable to turn off or reduce the frequency of atime updates. Two methods of reducing the effects of atime updating are available: Mount with relatime (relative atime), which updates the atime if the atime update is older than the mtime or ctime update. Mount with noatime , which disables atime updates on that file system. 4.9.1. Mount with relatime The relatime (relative atime) Linux mount option can be specified when the file system is mounted. This specifies that the atime is updated if the atime update is older than the mtime or ctime update. Usage BlockDevice Specifies the block device where the GFS2 file system resides. MountPoint Specifies the directory where the GFS2 file system should be mounted. Example In this example, the GFS2 file system resides on the /dev/vg01/lvol0 and is mounted on directory /mygfs2 . The atime updates take place only if the atime update is older than the mtime or ctime update.

Commands:
mount BlockDevice MountPoint -o relatime
mount /dev/vg01/lvol0 /mygfs2 -o relatime
Chapter 5. Installing a cluster on vSphere using the Agent-based Installer The Agent-based installation method provides the flexibility to boot your on-premises servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments. Agent-based installation is a subcommand of the OpenShift Container Platform installer. It generates a bootable ISO image containing all of the information required to deploy an OpenShift Container Platform cluster with an available release image. 5.1. Additional resources Preparing to install with the Agent-based Installer

Commands:
Chapter 5. Upgrade OpenShift sandboxed containers You can upgrade the components of OpenShift sandboxed containers by upgrading OpenShift sandboxed containers Operator and OpenShift sandboxed containers artifacts. 5.1. Upgrade OpenShift sandboxed containers Operator You can use Operator Lifecycle Manager (OLM) to manually or automatically upgrade the OpenShift sandboxed containers Operator. You can select manual or automatic upgrade during the initial deployment. In the context of manual upgrades, the web console shows the available updates that can be installed by the cluster administrator. Additional resources Upgrading installed Operators 5.2. Upgrade the OpenShift sandboxed containers artifacts The OpenShift sandboxed containers artifacts are deployed onto the cluster using Red Hat Enterprise Linux CoreOS (RHCOS) extensions. The RHCOS extension sandboxed containers contains the required components to run Kata Containers such as the Kata containers runtime, the hypervisor QEMU, and other dependencies. The extension is upgraded when upgrading the cluster to a new release of OpenShift Container Platform.

Commands:
32.2. Configuring SELinux User Map Order and Defaults An SELinux user map is the association between an SELinux user on a client and an IdM user. The available SELinux user map order is part of the IdM server configuration. The SELinux user map order is a list of the SELinux users, in an order from the most to the least confined. The SELinux user entry itself has this format: The individual user entries are separated with a dollar sign (USD). Since there is no requirement on user entries to have an SELinux map, many entries might be unmapped. The IdM server configuration sets a default SELinux user, one of the users from the total SELinux map list, to use for unmapped IdM user entries. This way, even unmapped IdM users have a functional SELinux context. The default SELinux user for unmapped IdM user entries is unconfined_u , the default SELinux user for system users on Red Hat Enterprise Linux. This configuration defines the map order of available system SELinux users. This does not define any IdM user SELinux policies. The IdM user - SELinux user map must be defined and then users are added to the map. For details, see Section 32.3, "Mapping SELinux Users and IdM Users" . 32.2.1. In the Web UI In the top menu, click the IPA Server main tab and the Configuration subtab. Scroll to the bottom of the list of server configuration areas, to SELINUX OPTIONS . Edit the SELinux user configuration, the SELinux user map order , the Default SELinux user , or both. Click the Update link at the top of the page to save the changes. 32.2.2. In the CLI To view the list of SELinux users, set in the IdM server configuration, which are available to be mapped: To edit the SELinux user settings, use the config-mod command: Example 32.1. List of SELinux Users To edit the list of SELinux users to be available for mapping, use the --ipaselinuxusermaporder option. The list orders the SELinux users from the most to the least confined, for example: Note The default SELinux user, used for unmapped entries, must be included in the user map list or the edit operation fails. Likewise, if the default is edited, it must be changed to a user in the SELinux map list or the map list must be updated first. Example 32.2. Default SELinux User IdM users are not required to have a specific SELinux user mapped to their account. However, the local system still checks the IdM entry for an SELinux user to use for the IdM user account. To modify the default SELinux user, use the --ipaselinuxusermapdefault option. For example:

Commands:
SELinux_user:MLS[:MCS]
[user1]@server ~]USD ipa config-show SELinux user map order: guest_u:s0USDxguest_u:s0USDuser_u:s0USDstaff_u:s0-s0:c0.c1023USDunconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023
[user1@server ~]USD ipa config-mod --ipaselinuxusermaporder="unconfined_u:s0-s0:c0.c1023USDguest_u:s0USDxguest_u:s0USDuser_u:s0-s0:c0.c1023USDstaff_u:s0-s0:c0.c1023"
[user1@server ~]USD ipa config-mod --ipaselinuxusermapdefault="guest_u:s0"
4.2. Service Initialization 4.2.1. xinetd Xinetd is a daemon used to start network services on demand. The changes in xinetd are related to the allowed limit of open file descriptors: The listening mechanism has changed from select() to poll() . With this change, the limit of open file descriptors used by xinetd can be changed. File descriptor limit can also now be changed on a per-service basis. This can be done in the configuration file for the service using the rlimit_files directive. The value can be a positive integer or UNLIMITED.

Commands:
Chapter 14. Post-installation security hardening RHEL is designed with robust security features enabled by default. However, you can enhance its security further through additional hardening measures. For more information about: Installing security updates and displaying additional details about the updates to keep your RHEL systems secured against newly discovered threats and vulnerabilities, see Managing and monitoring security updates . Processes and practices for securing RHEL servers and workstations against local and remote intrusion, exploitation, and malicious activity, see Security hardening . Control how users and processes interact with the files on the system or control which users can perform which actions by mapping them to specific SELinux confined users, see Using SELinux . Tools and techniques to improve the security of your networks and lower the risks of data breaches and intrusions, see Securing networks . Packet filters, such as firewalls, that use rules to control incoming, outgoing, and forwarded network traffic, see Using and configuring firewalld and Getting started with nftables .

Commands:
Chapter 10. Creating a diagnostic log for support If you need help from the Red Hat support team, you can create and share diagnostic log files. These log files can help the support team to troubleshoot issues with insights-client . 10.1. Creating a diagnostic log You can create a diagnostic log to share with the support team. Prerequisites Root-level access to your system. Procedure Enter the insights-client command with the --support option. The command displays informational messages while creating the support file. Navigate to the collection directory as shown in the Support information collected in message. Unpack the compressed tar.gz file. Unzipping the tar.gz file produces a new directory containing the log files. You can share the tar.gz file with the support team if requested.

Commands:
insights-client --support
Collecting logs Insights version: insights-core-3.0.121-1 Registration check: status: True unreachable: False . . . . Copying Insights logs to archive Support information collected in /var/tmp/H_Y43a/insights-client-logs-20190927144011.tar.gz
cd /var/tmp/H_Y43a
tar -xzf insights-client-logs-20190927144011.tar.gz