mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 13. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.18, 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. Deprecated features This section describes the deprecated features introduced in Red Hat OpenShift Data foundation 4.14. 8.1. Red Hat Virtualization Platform Starting Red Hat OpenShift Data Foundation 4.14, OpenShift Data Foundation deployed on Installer-provisioned infrastructure (IPI) deployment of OpenShift on Red Hat Virtualization Platform (RHV) is no longer supported. For more information, see OpenShift Container Platform 4.14 release notes .

Commands:
Chapter 38. Red Hat Enterprise Linux Atomic Host dracut component, BZ#1160691 Red Hat Enterprise Linux Atomic Host 7.1.0 allows configuring encrypted root installation in the Anaconda installer, but the system will not boot afterwards. Choosing this option in the installer is not recommended. dracut component, BZ# 1189407 Red Hat Enterprise Linux Atomic Host 7.1.0 offers iSCSI support during Anaconda installation, but the current content set does not include iSCSI support, so the system will not be able to access the storage. Choosing this option in the installer is not recommended. kexec-tools component, BZ#1180703 Due to some parsing problems in the code, the kdump utility currently saves the kernel crash drumps in the /sysroot/crash/ directory instead of in /var/crash/ . rhel-server-atomic component, BZ# 1186923 Red Hat Enterprise Linux Atomic Host 7.1.0 does not currently support systemtap, unless the host-kernel-matching packages which contain kernel-devel and other packages are installed into the rheltools container image. rhel-server-atomic component, BZ#1193704 Red Hat Enterprise Linux Atomic Host allocates 3GB of storage to the root partition, which includes the docker volumes. In order to support more volume space, more physical storage must be added to the system, or the root Logical Volume must be extended. The Managing Storage with Red Hat Enterprise Linux Atomic Host section from the Getting Started with Red Hat Enterprise Linux Atomic Host article describes the workaround methods for this issue. rhel-server-atomic component, BZ# 1186922 If the ltrace command is executed inside a Super-Privileged Container (SPC) to trace a process that is running on Red Hat Enterprise Linux Atomic Host, the ltrace command is unable to locate the binary images of the shared libraries that are attached to the process to be traced. As a consequence, ltrace displays a series of error messages, similar to the following example: rhel-server-atomic component, BZ#1187119 Red Hat Enterprise Linux Atomic Host does not include a mechanism to customize or override the content of the host itself, for example it does not include a tool to use a custom kernel for debugging. rhel-server-atomic component, BZ#1187119 Red Hat Enterprise Linux Atomic Host does not include a mechanism to customize or override the content of the host itself, for example it does not include a tool to use a custom kernel for debugging.

Commands:
Can't open /lib64/libwrap.so.0: No such file or directory Couldn't determine base address of /lib64/libwrap.so.0 ltrace: ltrace-elf.c:426: ltelf_destroy: Assertion `(&lte->plt_relocs)->elt_size == sizeof(GElf_Rela)' failed.
Monitoring and logging Red Hat Developer Hub 1.4 Tracking performance and capturing insights with monitoring and logging tools in Red Hat Developer Hub Red Hat Customer Content Services

Commands:
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: <developer_hub_service_monitor_name> 1 namespace: <rhdh_namespace_name> 2 labels: app.kubernetes.io/instance: <rhdh_cr_name> 3 app.kubernetes.io/name: Backstage spec: namespaceSelector: matchNames: - <rhdh_namespace_name> 4 selector: matchLabels: app.kubernetes.io/instance: <deployment_name> 5 app.kubernetes.io/name: <rhdh_cr_type> 6 endpoints: - port: http-metrics path: '/metrics'
apply -f <filename>
upstream: metrics: serviceMonitor: enabled: true path: /metrics port: http-metrics
upstream: backstage: # --- TRUNCATED --- podAnnotations: prometheus.io/scrape: 'true' prometheus.io/path: '/metrics' prometheus.io/port: '9464' prometheus.io/scheme: 'http'
Update OPERATOR_NS accordingly OPERATOR_NS=rhdh-operator edit configmap backstage-default-config -n "USD{OPERATOR_NS}"
deployment.yaml: |- apiVersion: apps/v1 kind: Deployment # --- truncated --- spec: template: # --- truncated --- metadata: labels: rhdh.redhat.com/app: # placeholder for 'backstage-<cr-name>' # --- truncated --- annotations: prometheus.io/scrape: 'true' prometheus.io/path: '/metrics' prometheus.io/port: '9464' prometheus.io/scheme: 'http' # --- truncated ---
--namespace=prometheus port-forward deploy/prometheus-server 9090
upstream: backstage: # --- Truncated --- extraEnvVars: - name: LOG_LEVEL value: debug
spec: # Other fields omitted application: extraEnvs: envs: - name: LOG_LEVEL value: debug
fields @timestamp, @message, kubernetes.container_name | filter kubernetes.container_name in ["install-dynamic-plugins", "backstage-backend"]
az aks create/update --resource-group <your-ResourceGroup> --name <your-Cluster> --enable-azure-monitor-metrics
upstream: backstage: # --- TRUNCATED --- podAnnotations: prometheus.io/scrape: 'true' prometheus.io/path: '/metrics' prometheus.io/port: '9464' prometheus.io/scheme: 'http'
Update OPERATOR_NS accordingly OPERATOR_NS=rhdh-operator edit configmap backstage-default-config -n "USD{OPERATOR_NS}"
deployment.yaml: |- apiVersion: apps/v1 kind: Deployment # --- truncated --- spec: template: # --- truncated --- metadata: labels: rhdh.redhat.com/app: # placeholder for 'backstage-<cr-name>' # --- truncated --- annotations: prometheus.io/scrape: 'true' prometheus.io/path: '/metrics' prometheus.io/port: '9464' prometheus.io/scheme: 'http' # --- truncated ---
Appendix D. Configuration Recommendations D.1. Timeout Values Table D.1. Timeout Value Recommendations for JBoss Data Grid Timeout Value Parent Element Default Value Recommended Value distributedSyncTimeout transport 240,000 (4 minutes) Same as default lockAcquisitionTimeout locking 10,000 (10 seconds) Same as default cacheStopTimeout transaction 30,000 (30 seconds) Same as default completedTxTimeout transaction 60,000 (60 seconds) Same as default replTimeout sync 15,000 (15 seconds) Same as default timeout stateTransfer 240,000 (4 minutes) Same as default timeout backup 10,000 (10 seconds) Same as default flushLockTimeout async 1 (1 millisecond) Same as default. Note that this value applies to asynchronous cache stores, but not asynchronous caches. shutdownTimeout async 25,000 (25 seconds) Same as default. Note that this value applies to asynchronous cache stores, but not asynchronous caches. pushStateTimeout singletonStore 10,000 (10 seconds) Same as default. backup replicationTimeout 10,000 (10 seconds) remoteCallTimeout clusterLoader 0 For most requirements, same as default. This value is usually set to the same as the sync.replTimeout value. Report a bug

Commands:
14.3.3. Domain Controller A domain controller in Windows NT is functionally similar to a Network Information Service (NIS) server in a Linux environment. Domain controllers and NIS servers both host user/group information databases as well as related services. Domain controllers are mainly used for security, including the authentication of users accessing domain resources. The service that maintains the user/group database integrity is called the Security Account Manager (SAM). The SAM database is stored differently between Windows and Linux Samba-based systems, therefore SAM replication cannot be achieved and platforms cannot be mixed in a PDC/BDC environment. In a Samba environment, there can be only one PDC and zero or more BDCs. Important Samba cannot exist in a mixed Samba/Windows domain controller environment (Samba cannot be a BDC of a Windows PDC or vice versa). Alternatively, Samba PDCs and BDCs can coexist. 14.3.3.1. Primary Domain Controller (PDC) using tdbsam The simplest and most common implementation of a Samba PDC uses the tdbsam password database backend. Planned to replace the aging smbpasswd backend, tdbsam has numerous improvements that are explained in more detail in Section 14.5, " Samba Account Information Databases " . The passdb backend directive controls which backend is to be used for the PDC. Note If you need more than one domain controller or have more than 250 users, do not use a tdbsam authentication backend. LDAP is recommended in these cases.

Commands:
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = tdbsam security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines %u The following specifies the default logon script Per user logon scripts can be specified in the user account using pdbedit logon script = logon.bat This sets the default profile path. Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes idmap uid = 15000-20000 idmap gid = 15000-20000 [homes] comment = Home Directories valid users = %S read only = No browseable = No writable = Yes [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon/scripts admin users = ed, john, sam guest ok = No browseable = No writable = No For profiles to work, create a user directory under the path shown. mkdir -p /var/lib/samba/profiles/john [Profiles] comment = Roaming Profile Share path = /var/lib/samba/profiles read only = No browseable = No guest ok = Yes profile acls = Yes Other resource shares
Chapter 11. Compiler and Tools OpenJDK8 Red Hat Enterprise Linux 6.6 features the java-1.8.0-openjdk packages, which contain the latest version of the Open Java Development Kit, OpenJDK8, that is now fully supported. These packages provide a fully compliant implementation of Java SE 8 and may be used in parallel with the existing java-1.7.0-openjdk packages, which remain available in Red Hat Enterprise Linux 6.6. Java 8 brings numerous new improvements, such as Lambda expressions, default methods, a new Stream API for collections, JDBC 4.2, hardware AES support, and much more. In addition to these, OpenJDK8 contains numerous other performance updates and bug fixes.

Commands:
Chapter 6. View OpenShift Data Foundation Topology The topology shows the mapped visualization of the OpenShift Data Foundation storage cluster at various abstraction levels and also lets you to interact with these layers. The view also shows how the various elements compose the Storage cluster altogether. Procedure On the OpenShift Web Console, navigate to Storage Data Foundation Topology . The view shows the storage cluster and the zones inside it. You can see the nodes depicted by circular entities within the zones, which are indicated by dotted lines. The label of each item or resource contains basic information such as status and health or indication for alerts. Choose a node to view node details on the right-hand panel. You can also access resources or deployments within a node by clicking on the search/preview decorator icon. To view deployment details Click the preview decorator on a node. A modal window appears above the node that displays all of the deployments associated with that node along with their statuses. Click the Back to main view button in the model's upper left corner to close and return to the view. Select a specific deployment to see more information about it. All relevant data is shown in the side panel. Click the Resources tab to view the pods information. This tab provides a deeper understanding of the problems and offers granularity that aids in better troubleshooting. Click the pod links to view the pod information page on OpenShift Container Platform. The link opens in a new window.

Commands:
probe::signal.wakeup Name probe::signal.wakeup - Sleeping process being wakened for signal Synopsis Values resume Indicates whether to wake up a task in a STOPPED or TRACED state state_mask A string representation indicating the mask of task states to wake. Possible values are TASK_INTERRUPTIBLE, TASK_STOPPED, TASK_TRACED, and TASK_INTERRUPTIBLE. pid_name Name of the process to wake sig_pid The PID of the process to wake

Commands:
signal.wakeup
Chapter 1. Support policy for Eclipse Temurin Red Hat will support select major versions of Eclipse Temurin in its products. For consistency, these are the same versions that Oracle designates as long-term support (LTS) for the Oracle JDK. A major version of Eclipse Temurin will be supported for a minimum of six years from the time that version is first introduced. For more information, see the Eclipse Temurin Life Cycle and Support Policy . Note RHEL 6 reached the end of life in November 2020. Because of this, Eclipse Temurin does not support RHEL 6 as a supported configuration.

Commands:
Chapter 1. About Red Hat Insights Red Hat Insights is a Software-as-a-Service (SaaS) application included with almost every subscription to Red Hat Enterprise Linux, Red Hat OpenShift, and Red Hat Ansible Automation Platform. Powered by predictive analytics, Red Hat Insights gets smarter with every additional piece of intelligence and data. It can automatically discover relevant insights, recommend tailored, proactive, actions, and even automate tasks. Using Red Hat Insights, customers can benefit from the experience and technical knowledge of Red Hat Certified Engineers, making it easier to identify, prioritize and resolve issues before business operations are affected. As a SaaS offering, located at Red Hat Hybrid Cloud Console , Red Hat Insights is regularly updated. Regular updates expand the Insights knowledge archive in real time to reflect new IT challenges that can impact the stability of mission-critical systems.

Commands:
Chapter 11. Logging 11.1. Enabling protocol logging The client can log AMQP protocol frames to the console. This data is often critical when diagnosing problems. To enable protocol logging, set the PN_TRACE_FRM environment variable to 1 : Example: Enabling protocol logging USD export PN_TRACE_FRM=1 USD <your-client-program> To disable protocol logging, unset the PN_TRACE_FRM environment variable.

Commands:
export PN_TRACE_FRM=1 <your-client-program>
22.2. IBM Redbooks Publications for IBM Z Current versions of IBM Redbooks publications can be found at http://www.redbooks.ibm.com/ . They include: Introductory publications Introduction to the New Mainframe: z/VM Basics . IBM Redbooks . 2007. SG24-7316. Practical Migration to Linux on System z . IBM Redbooks . 2009. SG24-7727. Performance and high availability Linux on IBM System z: Performance Measurement and Tuning . IBM Redbooks . 2011. SG24-6926. Achieving High Availability on Linux for System z with Linux-HA Release 2 . IBM Redbooks . 2009. SG24-7711. Security Security for Linux on System z . IBM Redbooks . 2013. SG24-7728. Networking IBM System z Connectivity Handbook . IBM Redbooks . 2013. SG24-5444. OSA Express Implementation Guide . IBM Redbooks . 2009. SG24-5948. HiperSockets Implementation Guide . IBM Redbooks . 2007. SG24-6816. Fibre Channel Protocol for Linux and z/VM on IBM System z . IBM Redbooks . 2007. SG24-7266.

Commands:
23.4. CPU allocation <domain> ... <vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu> ... </domain> Figure 23.6. CPU Allocation The <vcpu> element defines the maximum number of virtual CPUs allocated for the guest virtual machine operating system, which must be between 1 and the maximum number supported by the hypervisor. This element can contain an optional cpuset attribute, which is a comma-separated list of physical CPU numbers that the domain process and virtual CPUs can be pinned to by default. Note that the pinning policy of the domain process and virtual CPUs can be specified separately by using the cputune attribute. If the emulatorpin attribute is specified in <cputune> , cpuset specified by <vcpu> will be ignored. Similarly, virtual CPUs that have set a value for vcpupin cause cpuset settings to be ignored. For virtual CPUs where vcpupin is not specified, it will be pinned to the physical CPUs specified by cpuset . Each element in the cpuset list is either a single CPU number, a range of CPU numbers, or a caret (^) followed by a CPU number to be excluded from a range. The attribute current can be used to specify whether fewer than the maximum number of virtual CPUs should be enabled. The placement optional attribute can be used to indicate the CPU placement mode for domain processes. The value of placement can be set as one of the following: static - pins the vCPU to the physical CPUs defined by the cpuset attribute. If cpuset is not defined, the domain processes will be pinned to all the available physical CPUs. auto - indicates the domain process will be pinned to the advisory nodeset from the querying numad, and the value of attribute cpuset will be ignored if it is specified. Note If the cpuset attribute is used along with placement , the value of placement defaults to the value of the <numatune> element (if it is used), or to static .

Commands:
<domain> <vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu> </domain>
Chapter 1. Node APIs 1.1. Node [v1] Description Node is a worker node in Kubernetes. Each node will have a unique identifier in the cache (i.e. in etcd). Type object 1.2. PerformanceProfile [performance.openshift.io/v2] Description PerformanceProfile is the Schema for the performanceprofiles API Type object 1.3. Profile [tuned.openshift.io/v1] Description Profile is a specification for a Profile resource. Type object 1.4. RuntimeClass [node.k8s.io/v1] Description RuntimeClass defines a class of container runtime supported in the cluster. The RuntimeClass is used to determine which container runtime is used to run all containers in a pod. RuntimeClasses are manually defined by a user or cluster provisioner, and referenced in the PodSpec. The Kubelet is responsible for resolving the RuntimeClassName reference before running the pod. For more details, see https://kubernetes.io/docs/concepts/containers/runtime-class/ Type object 1.5. Tuned [tuned.openshift.io/v1] Description Tuned is a collection of rules that allows cluster-wide deployment of node-level sysctls and more flexibility to add custom tuning specified by user needs. These rules are translated and passed to all containerized Tuned daemons running in the cluster in the format that the daemons understand. The responsibility for applying the node-level tuning then lies with the containerized Tuned daemons. More info: https://github.com/openshift/cluster-node-tuning-operator Type object

Commands:
Chapter 1. Introducing Software Collections This chapter introduces you to the concept and usage of Software Collections or SCLs for short. 1.1. Why Package Software with RPM? The RPM Package Manager (RPM) is a package management system that runs on Red Hat Enterprise Linux. RPM makes it easier for you to distribute, manage, and update software that you create for Red Hat Enterprise Linux. Many software vendors distribute their software via a conventional archive file (such as a tarball). However, there are several advantages in packaging software into RPM packages. These advantages are outlined below. With RPM, you can: Install, reinstall, remove, upgrade and verify packages. Users can use standard package management tools (for example Yum or PackageKit ) to install, reinstall, remove, upgrade and verify your RPM packages. Use a database of installed packages to query and verify packages. Because RPM maintains a database of installed packages and their files, users can easily query and verify packages on their system. Use metadata to describe packages, their installation instructions, and so on. Each RPM package includes metadata that describes the package's components, version, release, size, project URL, installation instructions, and so on. Package pristine software sources into source and binary packages. RPM allows you to take pristine software sources and package them into source and binary packages for your users. In source packages, you have the pristine sources along with any patches that were used, plus complete build instructions. This design eases the maintenance of the packages as new versions of your software are released. Add packages to Yum repositories. You can add your package to a Yum repository that enables clients to easily find and deploy your software. Digitally sign your packages. Using a GPG signing key, you can digitally sign your package so that users are able to verify the authenticity of the package. For in-depth information on what is RPM and how to use it, see the Red Hat Enterprise Linux 7 System Administrator's Guide , or the Red Hat Enterprise Linux 6 Deployment Guide .

Commands: