mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 14. Activating and deactivating telemetry Activate the telemetry module to help Ceph developers understand how Ceph is used and what problems users might be experiencing. This helps improve the dashboard experience. Activating the telemetry module sends anonymous data about the cluster back to the Ceph developers. View the telemetry data that is sent to the Ceph developers on the public telemetry dashboard . This allows the community to easily see summary statistics on how many clusters are reporting, their total capacity and OSD count, and version distribution trends. The telemetry report is broken down into several channels, each with a different type of information. Assuming telemetry has been enabled, you can turn on and off the individual channels. If telemetry is off, the per-channel setting has no effect. Basic Provides basic information about the cluster. Crash Provides information about daemon crashes. Device Provides information about device metrics. Ident Provides user-provided identifying information about the cluster. Perf Provides various performance metrics of the cluster. The data reports contain information that help the developers gain a better understanding of the way Ceph is used. The data includes counters and statistics on how the cluster has been deployed, the version of Ceph, the distribution of the hosts, and other parameters. Important The data reports do not contain any sensitive data like pool names, object names, object contents, hostnames, or device serial numbers. Note Telemetry can also be managed by using an API. For more information, see the Telemetry chapter in the Red Hat Ceph Storage Developer Guide . Procedure Activate the telemetry module in one of the following ways: From the banner within the Ceph dashboard. Go to Settings->Telemetry configuration . Select each channel that telemetry should be enabled on. Note For detailed information about each channel type, click More Info to the channels. Complete the Contact Information for the cluster. Enter the contact, Ceph cluster description, and organization. Optional: Complete the Advanced Settings field options. Interval Set the interval by hour. The module compiles and sends a new report per this hour interval. The default interval is 24 hours. Proxy Use this to configure an HTTP or HTTPs proxy server if the cluster cannot directly connect to the configured telemetry endpoint. Add the server in one of the following formats: https://10.0.0.1:8080 or https://ceph:telemetry@10.0.01:8080 The default endpoint is telemetry.ceph.com . Click . This displays the Telemetry report preview before enabling telemetry. Review the Report preview . Note The report can be downloaded and saved locally or copied to the clipboard. Select I agree to my telemetry data being submitted under the Community Data License Agreement . Enable the telemetry module by clicking Update . The following message is displayed, confirming the telemetry activation: 14.1. Deactivating telemetry To deactivate the telemetry module, go to Settings->Telemetry configuration and click Deactivate .

Commands:
The Telemetry module has been configured and activated successfully
3.16. Starting a Virtual Machine with Specific Boot Devices and Boot Order This Ruby example starts a virtual machine specifying the boot devices and boot order. # Find the root of the tree of services: system_service = connection.system_service # Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first # Find the service that manages the virtual machine: vm_service = vms_service.vm_service(vm.id) # Start the virtual machine explicitly indicating the boot devices and order: vm_service.start( vm: { os: { boot: { devices: [ OvirtSDK4::BootDevice::NETWORK, OvirtSDK4::BootDevice::CDROM ] } } } ) # Wait until the virtual machine is up: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end For more information, see BootDevice .

Commands:
Find the root of the tree of services: system_service = connection.system_service Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first Find the service that manages the virtual machine: vm_service = vms_service.vm_service(vm.id) Start the virtual machine explicitly indicating the boot devices and order: vm_service.start( vm: { os: { boot: { devices: [ OvirtSDK4::BootDevice::NETWORK, OvirtSDK4::BootDevice::CDROM ] } } } ) Wait until the virtual machine is up: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end
4.66. freetype 4.66.1. RHSA-2012:0467 - Important: freetype security update Updated freetype packages that fix multiple security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. FreeType is a free, high-quality, portable font engine that can open and manage font files. It also loads, hints, and renders individual glyphs efficiently. Security Fixes CVE-2012-1134 , CVE-2012-1136 , CVE-2012-1142 , CVE-2012-1144 Multiple flaws were found in the way FreeType handled TrueType Font (TTF), Glyph Bitmap Distribution Format (BDF), Windows .fnt and .fon, and PostScript Type 1 fonts. If a specially-crafted font file was loaded by an application linked against FreeType, it could cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. CVE-2012-1126 , CVE-2012-1127 , CVE-2012-1130 , CVE-2012-1131 , CVE-2012-1132 , CVE-2012-1137 , CVE-2012-1139 , CVE-2012-1140 , CVE-2012-1141 , CVE-2012-1143 Multiple flaws were found in the way FreeType handled fonts in various formats. If a specially-crafted font file was loaded by an application linked against FreeType, it could cause the application to crash. Red Hat would like to thank Mateusz Jurczyk of the Google Security Team for reporting these issues. Users are advised to upgrade to these updated packages, which contain a backported patch to correct these issues. The X server must be restarted (log out, then log back in) for this update to take effect.

Commands:
5.9. Smart Card Authentication Smart cards are an external hardware security feature, most commonly seen in credit cards, but also used by many businesses as authentication tokens. Smart cards can be used to protect Red Hat Virtualization virtual machines. Enabling Smart Cards Ensure that the smart card hardware is plugged into the client machine and is installed according to manufacturer's directions. Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Console tab and select the Smartcard enabled check box. Click OK . Connect to the running virtual machine by clicking the Console button. Smart card authentication is now passed from the client hardware to the virtual machine. Important Important If the Smart card hardware is not correctly installed, enabling the Smart card feature will result in the virtual machine failing to load properly. Disabling Smart Cards Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Console tab, and clear the Smartcard enabled check box. Click OK . Configuring Client Systems for Smart Card Sharing Smart cards may require certain libraries in order to access their certificates. These libraries must be visible to the NSS library, which spice-gtk uses to provide the smart card to the guest. NSS expects the libraries to provide the PKCS #11 interface. Make sure that the module architecture matches `spice-gtk/remote-viewer's architecture. For instance, if you have only the 32b PKCS #11 library available, you must install the 32b build of virt-viewer in order for smart cards to work. Configuring RHEL Clients with CoolKey Smart Card Middleware CoolKey Smart Card middleware is a part of Red Hat Enterprise Linux. Install the Smart card support group. If the Smart Card Support group is installed on a Red Hat Enterprise Linux system, smart cards are redirected to the guest when Smart Cards are enabled. The following command installs the Smart card support group: Configuring RHEL Clients with Other Smart Card Middleware Register the library in the system's NSS database. Run the following command as root: Configuring Windows Clients Red Hat does not provide PKCS #11 support to Windows clients. Libraries that provide PKCS #11 support must be obtained from third parties. When such libraries are obtained, register them by running the following command as a user with elevated privileges:

Commands:
yum groupinstall "Smart card support"
modutil -dbdir /etc/pki/nssdb -add " module name " -libfile /path/to/library .so
modutil -dbdir %PROGRAMDATA%\pki\nssdb -add " module name " -libfile C:_\Path\to\module_.dll
2.4. RHEA-2011:0589 - new package: compat-openldap A new compat-openldap package is now available for Red Hat Enterprise Linux 6. OpenLDAP is an open source suite of LDAP (Lightweight Directory Access Protocol) applications and development tools. The compat-openldap package provides compatibility libraries for the OpenLDAP suite. Previously, the compat-openldap package was released as a subpackage of openldap. This enhancement update adds compat-openldap to Red Hat Enterprise Linux 6 as a separate package. (BZ# 652309 ) All users who require compat-openldap should install this new package.

Commands:
Chapter 6. Uninstalling a cluster on RHV You can remove an OpenShift Container Platform cluster from Red Hat Virtualization (RHV). 6.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program. 6.2. Removing a cluster that uses user-provisioned infrastructure When you are finished using the cluster, you can remove a cluster that uses user-provisioned infrastructure from your cloud. Prerequisites Have the original playbook files, assets directory and files, and USDASSETS_DIR environment variable that you used to you install the cluster. Typically, you can achieve this by using the same computer you used when you installed the cluster. Procedure To remove the cluster, enter: USD ansible-playbook -i inventory.yml \ retire-bootstrap.yml \ retire-masters.yml \ retire-workers.yml Remove any configurations you added to DNS, load balancers, and any other infrastructure for this cluster.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
ansible-playbook -i inventory.yml retire-bootstrap.yml retire-masters.yml retire-workers.yml
Chapter 8. Network Interfaces Under Red Hat Enterprise Linux, all network communications occur between configured software interfaces and physical networking devices connected to the system. The configuration files for network interfaces, and the scripts used to activate and deactivate them, are located in the /etc/sysconfig/network-scripts/ directory. Although the number and type of interface files can differ from system to system, there are three categories of files that exist in this directory: Interface configuration files Interface control scripts Network function files The files in each of these categories work together to enable various network devices. This chapter explores the relationship between these files and how they are used. 8.1. Network Configuration Files Before delving into the interface configuration files, let us first itemize the primary configuration files used in network configuration. Understanding the role these files play in setting up the network stack can be helpful when customizing a Red Hat Enterprise Linux system. The primary network configuration files are as follows: /etc/hosts - The main purpose of this file is to resolve hostnames that cannot be resolved any other way. It can also be used to resolve hostnames on small networks with no DNS server. Regardless of the type of network the computer is on, this file should contain a line specifying the IP address of the loopback device ( 127.0.0.1 ) as localhost.localdomain . For more information, refer to the hosts man page. /etc/resolv.conf - This file specifies the IP addresses of DNS servers and the search domain. Unless configured to do otherwise, the network initialization scripts populate this file. For more information about this file, refer to the resolv.conf man page. /etc/sysconfig/network - Specifies routing and host information for all network interfaces. For more information about this file and the directives it accepts, refer to Section 4.1.25, " /etc/sysconfig/network " . /etc/sysconfig/network-scripts/ifcfg- <interface-name> - For each network interface, there is a corresponding interface configuration script. Each of these files provide information specific to a particular network interface. Refer to Section 8.2, "Interface Configuration Files" for more information on this type of file and the directives it accepts. Warning The /etc/sysconfig/networking/ directory is used by the Network Administration Tool ( system-config-network ) and its contents should not be edited manually. In addition, any use of the Network Administration Tool , even launching the application, will override any directives previously set in /etc/sysconfig/network-scripts . Using only one method for network configuration is strongly encouraged, due to the risk of configuration deletion. For more information about configuring network interfaces using the Network Administration Tool , refer to the chapter titled Network Configuration in the System Administrators Guide .

Commands:
7.284. xorg-x11-drv-synaptics 7.284.1. RHBA-2013:0298 - xorg-x11-drv-synaptics bug fix and enhancement update Updated xorg-x11-drv-synaptics packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-synaptics packages contain the X.Org X11 input drivers for Synaptics touchpads. Note The xorg-x11-drv-synaptics packages have been upgraded to upstream version 1.6.2, which provides a number of bug fixes and enhancements over the version. (BZ#835257) Users of xorg-x11-drv-synaptics are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Audit logs in Red Hat Developer Hub Audit logs are a chronological set of records documenting the user activities, system events, and data changes that affect your Red Hat Developer Hub users, administrators, or components. Administrators can view Developer Hub audit logs in the OpenShift Container Platform web console to monitor scaffolder events, changes to the RBAC system, and changes to the Catalog database. Audit logs include the following information: Name of the audited event Actor that triggered the audited event, for example, terminal, port, IP address, or hostname Event metadata, for example, date, time Event status, for example, success , failure Severity levels, for example, info , debug , warn , error You can use the information in the audit log to achieve the following goals: Enhance security Trace activities, including those initiated by automated systems and software templates, back to their source. Know when software templates are executed, as well as the details of application and component installations, updates, configuration changes, and removals. Automate compliance Use streamlined processes to view log data for specified points in time for auditing purposes or continuous compliance maintenance. Debug issues Use access records and activity details to fix issues with software templates or plugins. Note Audit logs are not forwarded to the internal log store by default because this does not provide secure storage. You are responsible for ensuring that the system to which you forward audit logs is compliant with your organizational and governmental regulations, and is properly secured. Additional resources For more information about logging in OpenShift Container Platform, see About Logging For a complete list of fields that a Developer Hub audit log can include, see Section 3.1, "Audit log fields" For a list of scaffolder events that a Developer Hub audit log can include, see Section 3.2, "Scaffolder events"

Commands:
Chapter 95. OtherArtifact schema reference Used in: Plugin Property Property type Description url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. fileName string Name under which the artifact will be stored. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure. type string Must be other .

Commands:
7.8. Templates and Permissions 7.8.1. Managing System Permissions for a Template As the SuperUser , the system administrator manages all aspects of the Administration Portal. More specific administrative roles can be assigned to other users. These restricted administrator roles are useful for granting a user administrative privileges that limit them to a specific resource. For example, a DataCenterAdmin role has administrator privileges only for the assigned data center with the exception of the storage for that data center, and a ClusterAdmin has administrator privileges only for the assigned cluster. A template administrator is a system administration role for templates in a data center. This role can be applied to specific virtual machines, to a data center, or to the whole virtualized environment; this is useful to allow different users to manage certain virtual resources. The template administrator role permits the following actions: Create, edit, export, and remove associated templates. Import and export templates. Note You can only assign roles and permissions to existing users. 7.8.2. Template Administrator Roles Explained The table below describes the administrator roles and privileges applicable to template administration. Table 7.1. Red Hat Virtualization System Administrator Roles Role Privileges Notes TemplateAdmin Can perform all operations on templates. Has privileges to create, delete and configure a template's storage domain and network details, and to move templates between domains. NetworkAdmin Network Administrator Can configure and manage networks attached to templates. 7.8.3. Assigning an Administrator or User Role to a Resource Assign administrator or user roles to resources to allow users to access or manage that resource. Procedure Use the resource tabs, tree mode, or the search function to find and select the resource in the results list. Click the resource's name to go to the details view. Click the Permissions tab to list the assigned users, the user's role, and the inherited permissions for the selected resource. Click Add . Enter the name or user name of an existing user into the Search text box and click Go . Select a user from the resulting list of possible matches. Select a role from the Role to Assign: drop-down list. Click OK . You have assigned a role to a user; the user now has the inherited permissions of that role enabled for that resource. 7.8.4. Removing an Administrator or User Role from a Resource Remove an administrator or user role from a resource; the user loses the inherited permissions associated with the role for that resource. Removing a Role from a Resource Use the resource tabs, tree mode, or the search function to find and select the resource in the results list. Click the resource's name to go to the details view. Click the Permissions tab to list the assigned users, the user's role, and the inherited permissions for the selected resource. Select the user to remove from the resource. Click Remove . The Remove Permission window opens to confirm permissions removal. Click OK . You have removed the user's role, and the associated permissions, from the resource.

Commands:
Chapter 25. Virtualization Performance monitoring in KVM guests As a Technology Preview, KVM can virtualize a performance monitoring unit (vPMU) to allow virtual machines to use performance monitoring. Additionally it supports Intel's "architectural PMU" which can be live-migrated across different host CPU versions, using the -cpu host option. The virtual performance monitoring feature allows virtual machine users to identify sources of performance problems in their guests, using their preferred pre-existing profiling tools that work on the host as well as the guest. Note that this is an addition to the existing ability to profile a KVM guest from the host. Package: kernel-2.6.32-642 System monitoring using SNMP As a Technology Preview, Red Hat Enterprise Linux 6 allows Simple Network Management Protocol (SNMP) to be used for system monitoring. This allows KVM hosts to send SNMP traps on events so that hypervisor events can be communicated to the user via standard SNMP protocol. In addition, SNMP is capable of performing basic virtual networking operations, such as starting and stopping the virtual domain. Package: libvirt-snmp-0.0.2-5 Zero-copy compatibility for macvtap-vhost The macvtap-vhost zero-copy capability is available on Red Hat Enterprise Linux 6 as a Technology Preview. This feature allows running networking work loads in very high wire speeds but with low CPU resource consumption, and it does not limit other features such as memory overcommit and guest migration, which is not the case when using PCI device assignment to achieve the wire speed. Note that this feature is disabled by default. Package: qemu-kvm-0.12.1.2-2.491 vCPU hot unplug Although hot-plugging a virtual CPU (vCPU) is a supported operation, hot-unplugging a vCPU remains a Technology Preview in Red Hat Enterprise Linux 6, and is strongly recommended not to be used in high-value deployments. Package: libvirt-0.10.2-60

Commands: