mtpti5iD/redhat-docs_dataset huggingface dataset:
7.4. Fonts Red Hat Enterprise Linux uses two methods to manage and display fonts under X. The newer Fontconfig font subsystem simplifies font management and provides advanced display features, such as anti-aliasing. This system is used automatically for applications programmed using the Qt 3 or GTK+ 2 graphical toolkit. For compatibility, Red Hat Enterprise Linux includes the original font subsystem, called the core X font subsystem. This system, which is over 15 years old, is based around the X Font Server ( xfs ). This section discusses how to configure fonts for X using both systems. 7.4.1. Fontconfig The Fontconfig font subsystem allows applications to directly access fonts on the system and use Xft or other rendering mechanisms to render Fontconfig fonts with advanced anti-aliasing. Graphical applications can use the Xft library with Fontconfig to draw text to the screen. Over time, the Fontconfig/Xft font subsystem replaces the core X font subsystem. Important The Fontconfig font subsystem does not yet work for OpenOffice.org , which uses its own font rendering technology. It is important to note that Fontconfig uses the /etc/fonts/fonts.conf configuration file, and should not be edited by hand. Note Due to the transition to the new font system, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog (accessed by selecting Main Menu Button [on the Panel] => Preferences => Font ). For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine : Replace <font-specification> with a font specification in the style used by traditional X applications, such as -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* . A full list of core fonts can be obtained by running xlsfonts or created interactively using the xfontsel command. 7.4.1.1. Adding Fonts to Fontconfig Adding new fonts to the Fontconfig subsystem is a straightforward process. To add fonts system-wide, copy the new fonts into the /usr/share/fonts/ directory. It is a good idea to create a new subdirectory, such as local/ or similar, to help distinguish between user and default installed fonts. To add fonts for an individual user, copy the new fonts into the .fonts/ directory in the user's home directory. Use the fc-cache command to update the font information cache, as in the following example: In this command, replace <path-to-font-directory> with the directory containing the new fonts (either /usr/share/fonts/local/ or /home/ <user> /.fonts/ ). Note Individual users may also install fonts graphically, by typing fonts:/// into the Nautilus address bar, and dragging the new font files there. Important If the font file name ends with a .gz extension, it is compressed and cannot be used until uncompressed. To do this, use the gunzip command or double-click the file and drag the font to a directory in Nautilus .

Commands:
style "user-font" { fontset = " <font-specification> " } widget_class "*" style "user-font"
fc-cache <path-to-font-directory>
Chapter 6. Uninstalling a cluster on Azure You can remove a cluster that you deployed to Microsoft Azure. 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. Deleting Microsoft Azure resources with the Cloud Credential Operator utility After uninstalling an OpenShift Container Platform cluster that uses short-term credentials managed outside the cluster, you can use the CCO utility ( ccoctl ) to remove the Microsoft Azure (Azure) resources that ccoctl created during installation. Prerequisites Extract and prepare the ccoctl binary. Uninstall an OpenShift Container Platform cluster on Azure that uses short-term credentials. Procedure Delete the Azure resources that ccoctl created by running the following command: USD ccoctl azure delete \ --name=<name> \ 1 --region=<azure_region> \ 2 --subscription-id=<azure_subscription_id> \ 3 --delete-oidc-resource-group 1 <name> matches the name that was originally used to create and tag the cloud resources. 2 <azure_region> is the Azure region in which to delete cloud resources. 3 <azure_subscription_id> is the Azure subscription ID for which to delete cloud resources. Verification To verify that the resources are deleted, query Azure. For more information, refer to Azure documentation.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
ccoctl azure delete --name=<name> \ 1 --region=<azure_region> \ 2 --subscription-id=<azure_subscription_id> \ 3 --delete-oidc-resource-group
3.2. Deprecated Features The following table describes deprecated features to be removed in a future version of Red Hat Virtualization. Table 3.2. Deprecated Features Deprecated Feature Details Version 3 REST API Version 3 of the REST API is no longer supported. Use the version 4 REST API . Version 3 SDKs Version 3 of the SDKs for Java, Python, and Ruby are no longer supported. Use the version 4 SDK for Java , Python , or Ruby . RHEVM Shell Red Hat Virtualization's specialized command line interface is no longer supported. Use the version 4 SDK for Java , Python , or Ruby , or the version 4 REST API . Export Domains Use a data domain. Migrate data domains between data centers and import the virtual machines into the new data center. In Red Hat Virtualization 4.3, some tasks may still require the export domain. ISO domains Use a data domain. Upload images to data domains . In Red Hat Virtualization 4.3, some tasks may still require the ISO domain. Iptables Use the firewalld service . Conroe, Penryn, Opteron G1, Opteron G2, and Opteron G3 CPU types Use newer CPU types . IBRS CPU types Use newer fixes . 3.6 and 4.0 cluster compatibility versions Use a newer cluster compatibility version. Upgrade the compatibility version of existing clusters. ovirt-guest-agent The ovirt-guest-agent project is no longer supported. Use qemu-guest-agent version 2.12.0 or later. cockpit-machines-ovirt The cockpit-machines-ovirt package is not included in Red Hat Enterprise Linux 8 and will not be supported in Red Hat Virtualization Host 4.4. Use the Administration Portal. rhv-guest-tools-iso package The rhv-guest-tools-iso package is deprecated and will be replaced in Red Hat Virtualization 4.4 by virtio-win-guest-tools iso image. For information, see How can I install RHV Windows guest tools in RHEV 4.4? .

Commands:
4.87. ibus 4.87.1. RHBA-2011:1645 - ibus bug fix update Updated ibus packages that resolve an issue are now available for Red Hat Enterprise Linux 6. The Intelligent Input Bus for Linux OS (IBus) is an input framework for Linux OS. Bug Fix BZ# 667031 IBus did not work on a minimal installation of Red Hat Enterprise Linux 6 if no desktop environment, such as KDE or GNOME, was installed. This issue was caused by the missing dbus-x11 package, which IBus is dependent on. The dbus-x11 package is now included as a prerequisite for IBus in the IBus spec file, and IBus now works as expected. All users of ibus are advised to upgrade to these updated packages, which resolve this issue.

Commands:
Chapter 3. Provisioning management with Red Hat Satellite With Red Hat Satellite, you can provision hosts on various compute resources with many provisioning methods from a unified interface. 3.1. Provisioning methods in Red Hat Satellite With Red Hat Satellite, you can provision hosts by using the following methods. Bare-metal hosts Satellite provisions bare-metal hosts primarily by using PXE boot and MAC address identification. When provisioning bare-metal hosts with Satellite, you can do the following: Create host entries and specify the MAC address of the physical host to provision. Boot blank hosts to use the Satellite Discovery service, which creates a pool of hosts that are ready for provisioning. Cloud providers Satellite connects to private and public cloud providers to provision instances of hosts from images stored in the cloud environment. When provisioning from cloud with Satellite, you can do the following: Select which hardware profile to use. Provision cloud instances from specific providers by using their APIs. Virtualization infrastructure Satellite connects to virtualization infrastructure services, such as Red Hat Virtualization and VMware. When provisioning virtual machines with Satellite, you can do the following: Provision virtual machines from virtual image templates. Use the same PXE-based boot methods that you use to provision bare-metal hosts. 3.2. Additional resources For information about how to provision hosts with Satellite, see Provisioning hosts .

Commands:
21.3.3. Useful Websites http://www.nsa.gov/selinux/ - Homepage for the NSA SELinux development team. Many resources are available in HTML and PDF formats. Although many of these links are not Red Hat Enterprise Linux specific, some concepts may apply. http://fedora.redhat.com/docs/ - Homepage for the Fedora documentation project, which contains Fedora Core specific materials that may be more timely, since the release cycle is much shorter. http://selinux.sourceforge.net - Homepage for the SELinux community.

Commands:
27.3. Installing libStorageMgmt To install libStorageMgmt for use of the command line, required run-time libraries and simulator plug-ins, use the following command: To develop C applications that utilize the library, install the libstoragemgmt-devel package with the following command: To install libStorageMgmt for use with hardware arrays, select one or more of the appropriate plug-in packages with the following command: The following plug-ins that are available include: libstoragemgmt-smis-plugin Generic SMI-S array support. libstoragemgmt-netapp-plugin Specific support for NetApp files. libstoragemgmt-nstor-plugin Specific support for NexentaStor. libstoragemgmt-targetd-plugin Specific support for targetd. The daemon is then installed and configured to run at start after the reboot. To use it immediately without rebooting, start the daemon manually. Managing an array requires support through a plug-in. The base install package includes open source plug-ins for a number of different vendors. Additional plug-in packages will be available separately as array support improves. Currently supported hardware is constantly changing and improving. The libStorageMgmt daemon ( lsmd ) behaves like any standard service for the system. To check the status of the libStorageMgmt service: To stop the service: To start the service:

Commands:
yum install libstoragemgmt libstoragemgmt-python
yum install libstoragemgmt-devel
yum install libstoragemgmt- name -plugin
systemctl status libstoragemgmt
systemctl stop libstoragemgmt
systemctl start libstoragemgmt
5.3. Uploading VMDK images to vSphere Image Builder can generate images suitable for uploading to a VMware ESXi or vSphere system. This section describes steps to upload an VMDK image to VMware vSphere. Note Because VMWare deployments typically do not have cloud-init configured to inject user credentials to virtual machines, you have to perform that task yourself on the blueprint. Prerequisites You must have an VMDK image created by Image Builder. Use the vmdk output type in CLI or VMware Virtual Machine Disk (.vmdk) in GUI when creating the image. Procedure 1. Upload the image into vSphere via HTTP. Click on Upload Files in the vCenter: 2. When you create a VM, on the Device Configuration, delete the default New Hard Disk and use the drop-down to select an Existing Hard Disk disk image: Figure 5.3. Virtualization type 3. Make sure you use an IDE device as the Virtual Device Node for the disk you create. The default SCSI value results in an unbootable virtual machine. Figure 5.4. Virtualization type

Commands:
Chapter 13. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.16, you can install a three-node cluster on Google Cloud Platform (GCP). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 13.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 13.2. steps Installing a cluster on GCP with customizations Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 8. Interacting with a running Red Hat build of Kogito microservice After your Red Hat build of Kogito microservice is running, you can send REST API requests to interact with your application and execute your microservices according to how you set up the application. This example tests the /persons REST API endpoint that is automatically generated the decisions in the PersonDecisions.dmn file (or the rules in the PersonRules.drl file if you used a DRL rule unit). For this example, use a REST client, curl utility, or the Swagger UI configured for the application (such as http://localhost:8080/q/swagger-ui or http://localhost:8080/swagger-ui.html ) to send API requests with the following components: URL : http://localhost:8080/persons HTTP headers : For POST requests only: accept : application/json content-type : application/json HTTP methods : GET , POST , or DELETE Example POST request body to add an adult (JSON) { "person": { "name": "John Quark", "age": 20 } } Example curl command to add an adult Example response (JSON) { "id": "3af806dd-8819-4734-a934-728f4c819682", "person": { "name": "John Quark", "age": 20, "adult": false }, "isAdult": true } This example procedure uses curl commands for convenience. Procedure In a command terminal window that is separate from your running application, navigate to the project that contains your Red Hat build of Kogito microservice and use any of the following curl commands with JSON requests to interact with your running microservice: Note On Spring Boot, you might need to modify how your application exposes API endpoints in order for these example requests to function. For more information, see the README file included in the example Spring Boot project that you created for this tutorial. Add an adult person: Example request Example response Add an underage person: Example request Example response Complete the evaluation using the returned UUIDs: Example request

Commands:
{ "person": { "name": "John Quark", "age": 20 } }
curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}'
{ "id": "3af806dd-8819-4734-a934-728f4c819682", "person": { "name": "John Quark", "age": 20, "adult": false }, "isAdult": true }
curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}'
{"id":"3af806dd-8819-4734-a934-728f4c819682","person":{"name":"John Quark","age":20,"adult":false},"isAdult":true}
curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"Jenny Quark", "age": 15}}'
{"id":"8eef502b-012b-4628-acb7-73418a089c08","person":{"name":"Jenny Quark","age":15,"adult":false},"isAdult":false}
curl -X POST http://localhost:8080/persons/8eef502b-012b-4628-acb7-73418a089c08/ChildrenHandling/cdec4241-d676-47de-8c55-4ee4f9598bac -H 'content-type: application/json' -H 'accept: application/json' -d '{}'
Chapter 1. General information Lean about Red Hat Directory Server 12 general information that is independent of the minor versions. 1.1. Directory Server support policy and life cycle For details, see the Red Hat Directory Server Errata Support Policy document. 1.2. Software conflicts You cannot install Directory Server on a system that has a Red Hat Enterprise Linux Identity Management (IdM) server installed. Likewise, no Red Hat Enterprise Linux IdM server can be installed on a system with a Directory Server instance. 1.3. Migrating to Directory Server 12 For a procedure about migrating Directory Server 11 to Directory Server 12, see the Migrating Directory Server 11 to Directory Server 12 chapter. For a procedure about migrating Directory Server 10 to Directory Server 12, see Migrating Directory Server 10 to Directory Server 12 chapter. 1.4. Notes about migrating to Directory Server 12 The Directory Server 12 default password storage scheme is PBKDF2-SHA512 Directory Server 12 uses the PBKDF2-SHA512 scheme as a default password storage scheme, which is more secure than SSHA , SSHA512 , and other schemes. Therefore, if some of your applications, such as freeradius , do not support the PBKDF2-SHA512 scheme, and you must set a weaker password storage scheme back, note that Directory Server updates user passwords not only when an application adds or modifies the user entry, but also during a successful bind operation. However, you can disable an update on bind operations by setting the nsslapd-enable-upgrade-hash parameter in the cn=config entry to off . New command-line utilities starting Directory Server 11 Since version 11, Directory Server provides new command line utilities to manage server instances and users. These utilities replace the Perl scripts used for management tasks in Directory Server 10 and earlier versions. For a list of commands in versions and their replacements in Directory Server 12, see the Command-line utilities replaced in Red Hat Directory Server 11 appendix in the Red Hat Directory Server Installation Guide . Important The Perl scripts used for management tasks in Directory Server 10 and earlier versions are still available in the 389-ds-base-legacy-tools package. However, Red Hat only supports the new dsconf , dsctl , dscreate , and dsidm command-line utilities.

Commands:
4.3.11. Backing Up Volume Group Metadata Metadata backups and archives are automatically created on every volume group and logical volume configuration change unless disabled in the lvm.conf file. By default, the metadata backup is stored in the /etc/lvm/backup file and the metadata archives are stored in the /etc/lvm/archives file. You can manually back up the metadata to the /etc/lvm/backup file with the vgcfgbackup command. The vgcfrestore command restores the metadata of a volume group from the archive to all the physical volumes in the volume groups. For an example of using the vgcfgrestore command to recover physical volume metadata, see Section 6.4, "Recovering Physical Volume Metadata" .

Commands:
4.14. Setting Up Clients to Access Data NFS and SMB clients The NFS and SMB protocols are available for use, but due to limitations in the network configuration these protocols cannot be made highly available with CTDB or Pacemaker as would be normally recommended. Prerequisites You must ensure to register and subscribe your system before installing Native Client. Instructions for registering the system, is available, refer to the Creating Access to Volumes chapter in the Red Hat Gluster Storage Administration Guide . 4.14.1. Installing Native Client Run the following command to install the native client: 4.14.2. Mounting Red Hat Gluster Storage Volumes After installing Native Client, the Red Hat Gluster Storage volumes must be mounted to access data. Mount the myvol Gluster volume to the local directory /rhgs/client/myvol: 4.14.3. Testing Mounted Volumes Test the mounted volume by running the following command:

Commands:
yum -y install glusterfs-fuse attr
mkdir -p /rhgs/client/myvol
sh -c 'echo "rhgs-primary-n01:myvol /rhgs/client/myvol glusterfs defaults 0 0" >> /etc/fstab'
mount /rhgs/client/myvol'
8.4.6.2. OpenSCAP Offline Remediation Offline remediation allows you to postpone fix execution. In first step, the system is only evaluated, and the results are stored in a TestResult element in an XCCDF file. In the second step, oscap executes the fix scripts and verifies the result. It is safe to store the results into the input file, no data will be lost. During offline remediation, OpenSCAP creates a new TestResult element that is based on the input one and inherits all the data. The newly created TestResult differs only in the rule-result elements that have failed. For those, remediation is executed. To perform offline remediation using the scap-security-guide package, run:

Commands:
~]USD oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdf-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
~]USD oscap xccdf remediate --results scan-xccdf-results.xml scan-xccdf-results.xml