mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 14. Samba Samba is an open-source implementation of the Server Message Block ( SMB ) and Common Internet File System ( CIFS ) protocols that provides file and print services between clients across various operating systems. [15] In Red Hat Enterprise Linux, the samba package provides the Samba server. Enter the following command to see if the samba package is installed: If it is not installed and you want to use Samba, use the yum utility as the root user to install it: 14.1. Samba and SELinux When SELinux is enabled, the Samba server ( smbd ) runs confined by default. Confined services run in their own domains, and are separated from other confined services. The following example demonstrates the smbd process running in its own domain. This example assumes the samba package is installed: Run the getenforce command to confirm SELinux is running in enforcing mode: The command returns Enforcing when SELinux is running in enforcing mode. Enter the following command as root to start smbd : Confirm that the service is running. The output should include the information below (only the time stamp will differ): To view the smbd processes, execute the following command: The SELinux context associated with the smbd processes is system_u:system_r:smbd_t:s0 . The second last part of the context, smbd_t , is the type. A type defines a domain for processes and a type for files. In this case, the smbd processes are running in the smbd_t domain. Files must be labeled correctly to allow smbd to access and share them. For example, smbd can read and write to files labeled with the samba_share_t type, but by default, cannot access files labeled with the httpd_sys_content_t type, which is intended for use by the Apache HTTP Server. Booleans must be enabled to allow certain behavior, such as allowing home directories and NFS volumes to be exported through Samba, as well as to allow Samba to act as a domain controller. [15] For more information, see the Samba section in the System Administrator's Guide .

Commands:
~]USD rpm -q samba package samba is not installed
~]# yum install samba
~]USD getenforce Enforcing
~]# systemctl start smb.service
~]# systemctl status smb.service smb.service - Samba SMB Daemon Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled) Active: active (running) since Mon 2013-08-05 12:17:26 CEST; 2h 22min ago
~]USD ps -eZ | grep smb system_u:system_r:smbd_t:s0 9653 ? 00:00:00 smbd system_u:system_r:smbd_t:s0 9654 ? 00:00:00 smbd
1.5. Persistence and Firewall Marks In certain situations, it may be desirable for a client to reconnect repeatedly to the same real server, rather than have an LVS load balancing algorithm send that request to the best available server. Examples of such situations include multi-screen web forms, cookies, SSL, and FTP connections. In these cases, a client may not work properly unless the transactions are being handled by the same server to retain context. LVS provides two different features to handle this: persistence and firewall marks . 1.5.1. Persistence When enabled, persistence acts like a timer. When a client connects to a service, LVS remembers the last connection for a specified period of time. If that same client IP address connects again within that period, it is sent to the same server it connected to previously - bypassing the load-balancing mechanisms. When a connection occurs outside the time window, it is handled according to the scheduling rules in place. Persistence also allows the administrator to specify a subnet mask to apply to the client IP address test as a tool for controlling what addresses have a higher level of persistence, thereby grouping connections to that subnet. Grouping connections destined for different ports can be important for protocols which use more than one port to communicate, such as FTP. However, persistence is not the most efficient way to deal with the problem of grouping together connections destined for different ports. For these situations, it is best to use firewall marks .

Commands:
6.2.2.2. Home Directories Another issue facing system administrators is whether or not users should have centrally-stored home directories. The primary advantage of centralizing home directories on a network-attached server is that if a user logs into any machine on the network, they will be able to access the files in their home directory. The disadvantage is that if the network goes down, users across the entire organization will be unable to get to their files. In some situations (such as organizations that make widespread use of laptops), having centralized home directories may not be desirable. But if it makes sense for your organization, deploying centralized home directories can make a system administrator's life much easier.

Commands:
Chapter 15. Managing Guests with the Virtual Machine Manager (virt-manager) This section describes the Virtual Machine Manager ( virt-manager ) windows, dialog boxes, and various GUI controls. virt-manager provides a graphical view of hypervisors and guests on your host system and on remote host systems. virt-manager can perform virtualization management tasks, including: defining and creating guests, assigning memory, assigning virtual CPUs, monitoring operational performance, saving and restoring, pausing and resuming, and shutting down and starting guests, links to the textual and graphical consoles, and live and offline migrations. 15.1. Starting virt-manager To start virt-manager session open the Applications menu, then the System Tools menu and select Virtual Machine Manager ( virt-manager ). The virt-manager main window appears. Figure 15.1. Starting virt-manager Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command: Using ssh to manage virtual machines and hosts is discussed further in Section 5.1, "Remote Management with SSH" .

Commands:
ssh -X host's address virt-manager
9.2. Booting a Guest Using PXE This section demonstrates how to boot a guest virtual machine with PXE. 9.2.1. Using bridged networking Procedure 9.2. Booting a guest using PXE and bridged networking Ensure bridging is enabled such that the PXE boot server is available on the network. Boot a guest virtual machine with PXE booting enabled. You can use the virt-install command to create a new virtual machine with PXE booting enabled, as shown in the following example command: Alternatively, ensure that the guest network is configured to use your bridged network, and that the XML guest configuration file has a <boot order='1'/> element inside the network's <interface> element, as shown in the following example: 9.2.2. Using a Private libvirt Network Procedure 9.3. Using a private libvirt network Configure PXE booting on libvirt as shown in Section 9.1.1, "Setting up a PXE Boot Server on a Private libvirt Network" . Boot a guest virtual machine using libvirt with PXE booting enabled. You can use the virt-install command to create/install a new virtual machine using PXE: Alternatively, ensure that the guest network is configured to use your private libvirt network, and that the XML guest configuration file has a <boot order='1'/> element inside the network's <interface> element. In addition, ensure that the guest virtual machine is connected to the private network:

Commands:
virt-install --pxe --network bridge=breth0 --prompt
<interface type='bridge'> <mac address='52:54:00:5a:ad:cb'/> <source bridge='breth0'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> <boot order='1'/> </interface>
virt-install --pxe --network network=default --prompt
<interface type='network'> <mac address='52:54:00:66:79:14'/> <source network='default'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> <boot order='1'/> </interface>
Chapter 14. Allowing JavaScript-based access to the API server from additional hosts 14.1. Allowing JavaScript-based access to the API server from additional hosts The default OpenShift Container Platform configuration only allows the web console to send requests to the API server. If you need to access the API server or OAuth server from a JavaScript application using a different hostname, you can configure additional hostnames to allow. Prerequisites Access to the cluster as a user with the cluster-admin role. Procedure Edit the APIServer resource: USD oc edit apiserver.config.openshift.io cluster Add the additionalCORSAllowedOrigins field under the spec section and specify one or more additional hostnames: apiVersion: config.openshift.io/v1 kind: APIServer metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-07-11T17:35:37Z" generation: 1 name: cluster resourceVersion: "907" selfLink: /apis/config.openshift.io/v1/apiservers/cluster uid: 4b45a8dd-a402-11e9-91ec-0219944e0696 spec: additionalCORSAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) 1 1 The hostname is specified as a Golang regular expression that matches against CORS headers from HTTP requests against the API server and OAuth server. Note This example uses the following syntax: The (?i) makes it case-insensitive. The // pins to the beginning of the domain and matches the double slash following http: or https: . The \. escapes dots in the domain name. The (:|\z) matches the end of the domain name (\z) or a port separator (:) . Save the file to apply the changes.

Commands:
oc edit apiserver.config.openshift.io cluster
apiVersion: config.openshift.io/v1 kind: APIServer metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-07-11T17:35:37Z" generation: 1 name: cluster resourceVersion: "907" selfLink: /apis/config.openshift.io/v1/apiservers/cluster uid: 4b45a8dd-a402-11e9-91ec-0219944e0696 spec: additionalCORSAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) 1
Chapter 5. Virtualization Tools This chapter provides an introduction to the basic tools available to interact with virtualization on Red Hat Enterprise Linux 6. 5.1. virsh virsh is a command-line interface (CLI) tool for managing the hypervisor and guest virtual machines. virsh is built on the libvirt management API. . The virsh command can be used in read-only mode by unprivileged users, or for full administration by users with root access. In addition, virsh is the main management interface for virsh guest domains and can be used to create, pause, and shut down domains, as well as list current domains. This tool is installed as part of the libvirt-client package. Note Refer to the Red Hat Enterprise Linux 6 Virtualization Administration Guide for more information about managing virtual machines with virsh .

Commands:
Chapter 18. Planning for Installation on System z 18.1. Pre-Installation Red Hat Enterprise Linux 6.9 runs on System z9 or later IBM mainframe systems. The installation process assumes that you are familiar with the IBM System z and can set up logical partitions (LPARs) and z/VM guest virtual machines. For additional information on System z, refer to http://www.ibm.com/systems/z . For installation of Red Hat Enterprise Linux on System z, Red Hat supports DASD and FCP storage devices. Before you install Red Hat Enterprise Linux, you must decide on the following: Decide whether you want to run the operating system on an LPAR or as a z/VM guest operating system. Decide if you need swap space and if so how much. Although it is possible (and recommended) to assign enough memory to z/VM guest virtual machine and let z/VM do the necessary swapping, there are cases where the amount of required RAM is hard to predict. Such instances should be examined on a case-by-case basis. Refer to Section 23.15.5, "Recommended Partitioning Scheme" . Decide on a network configuration. Red Hat Enterprise Linux 6.9 for IBM System z supports the following network devices: Real and virtual Open Systems Adapter (OSA) Real and virtual HiperSockets LAN channel station (LCS) for real OSA You require the following hardware: Disk space. Calculate how much disk space you need and allocate sufficient disk space on DASDs [9] or SCSI [10] disks. You require at least 2 GB for a server installation, and 5 GB if you want to install all packages. You also require disk space for any application data. After the installation, more DASD or SCSI disk partitions may be added or deleted as necessary. The disk space used by the newly installed Red Hat Enterprise Linux system (the Linux instance) must be separate from the disk space used by other operating systems you may have installed on your system. For more information about disks and partition configuration, refer to Section 23.15.5, "Recommended Partitioning Scheme" . RAM. Acquire 1 GB (recommended) for the Linux instance. With some tuning, an instance might run with as little as 512 MB RAM. [9] Direct Access Storage Devices (DASDs) are hard disks that allow a maximum of three partitions per device. For example, dasda can have partitions dasda1 , dasda2 , and dasda3 . [10] Using the SCSI-over-Fibre Channel device driver (zfcp device driver) and a switch, SCSI LUNs can be presented to Linux on System z as if they were locally attached SCSI drives.

Commands:
Chapter 1. Identity service As a cloud administrator, you can manage projects, users, and roles. Projects are organizational units containing a collection of resources. You can assign users to roles within projects. Roles define the actions that those users can perform on the resources within a given project. Users can be assigned roles in multiple projects. Each Red Hat OpenStack (RHOSP) deployment must include at least one user assigned to a role within a project. As a cloud administrator, you can: Add, update, and delete projects and users. Assign users to one or more roles, and change or remove these assignments. Manage projects and users independently from each other. You can also configure user authentication with the Identity service (keystone)to control access to services and endpoints. The Identity service provides token-based authentication and can integrate with LDAP and Active Directory, so you can manage users and identities externally and synchronize the user data with the Identity service.

Commands:
Chapter 29. KafkaJmxOptions schema reference Used in: KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , ZookeeperClusterSpec Full list of KafkaJmxOptions schema properties Configures JMX connection options. Get JMX metrics from Kafka brokers, ZooKeeper nodes, Kafka Connect, and MirrorMaker 2. by connecting to port 9999. Use the jmxOptions property to configure a password-protected or an unprotected JMX port. Using password protection prevents unauthorized pods from accessing the port. You can then obtain metrics about the component. For example, for each Kafka broker you can obtain bytes-per-second usage data from clients, or the request rate of the network of the broker. To enable security for the JMX port, set the type parameter in the authentication field to password . Example password-protected JMX configuration for Kafka brokers and ZooKeeper nodes apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: authentication: type: "password" # ... zookeeper: # ... jmxOptions: authentication: type: "password" #... You can then deploy a pod into a cluster and obtain JMX metrics using the headless service by specifying which broker you want to address. For example, to get JMX metrics from broker 0 you specify: " CLUSTER-NAME -kafka-0. CLUSTER-NAME -kafka-brokers" CLUSTER-NAME -kafka-0 is name of the broker pod, and CLUSTER-NAME -kafka-brokers is the name of the headless service to return the IPs of the broker pods. If the JMX port is secured, you can get the username and password by referencing them from the JMX Secret in the deployment of your pod. For an unprotected JMX port, use an empty object {} to open the JMX port on the headless service. You deploy a pod and obtain metrics in the same way as for the protected port, but in this case any pod can read from the JMX port. Example open port JMX configuration for Kafka brokers and ZooKeeper nodes apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: {} # ... zookeeper: # ... jmxOptions: {} # ... Additional resources For more information on the Kafka component metrics exposed using JMX, see the Apache Kafka documentation . 29.1. KafkaJmxOptions schema properties Property Description authentication Authentication configuration for connecting to the JMX port. The type depends on the value of the authentication.type property within the given object, which must be one of [password]. KafkaJmxAuthenticationPassword

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # jmxOptions: authentication: type: "password" # zookeeper: # jmxOptions: authentication: type: "password" #
" CLUSTER-NAME -kafka-0. CLUSTER-NAME -kafka-brokers"
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # jmxOptions: {} # zookeeper: # jmxOptions: {} #
probe::nfs.fop.mmap Name probe::nfs.fop.mmap - NFS client mmap operation Synopsis nfs.fop.mmap Values attrtimeo how long the cached information is assumed to be valid. We need to revalidate the cached attrs for this inode if jiffies - read_cache_jiffies > attrtimeo. vm_end the first byte after end address within vm_mm dev device identifier buf the address of buf in user space vm_flag vm flags cache_time when we started read-caching this inode file_name file name ino inode number cache_valid cache related bit mask flag parent_name parent dir name vm_start start address within vm_mm

Commands:
4.50. doxygen 4.50.1. RHBA-2011:1174 - doxygen bug fix update Updated doxygen packages that fix one bug are now available for Red Hat Enterprise Linux 6. Doxygen can generate an online class browser in HTML and/or a reference manual in LaTeX from a set of documented source files. The documentation is extracted directly from the sources. Bug Fix BZ# 690076 Prior to this update, Doxygen required invalid BuildRequires on the qt-devel package. With this update, packages with BuildRequires dependencies on the qt-devel package have been fixed. Now, these packages explicitly require qt4-devel. All users of Doxygen are advised to upgrade to these updated packages, which fix this bug.

Commands:
C.8. DeadlockDetectingLockManager org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager This component provides information about the number of deadlocks that were detected. Table C.14. Attributes Name Description Type Writable detectedLocalDeadlocks Number of local transactions that were rolled back due to deadlocks. long No detectedRemoteDeadlocks Number of remote transactions that were rolled back due to deadlocks. long No overlapWithNotDeadlockAwareLockOwners Number of situations when we try to determine a deadlock and the other lock owner is NOT a transaction. In this scenario we cannot run the deadlock detection mechanism. long No totalNumberOfDetectedDeadlocks Total number of local detected deadlocks. long No concurrencyLevel The concurrency level that the MVCC Lock Manager has been configured with. int No numberOfLocksAvailable The number of exclusive locks that are available. int No numberOfLocksHeld The number of exclusive locks that are held. int No Table C.15. Operations Name Description Signature resetStatistics Resets statistics gathered by this component. void resetStatistics() Report a bug

Commands:
Chapter 5. About the multicluster engine for Kubernetes Operator One of the challenges of scaling Kubernetes environments is managing the lifecycle of a growing fleet. To meet that challenge, you can use the multicluster engine Operator. The operator delivers full lifecycle capabilities for managed OpenShift Container Platform clusters and partial lifecycle management for other Kubernetes distributions. It is available in two ways: As a standalone operator that you install as part of your OpenShift Container Platform or OpenShift Kubernetes Engine subscription As part of Red Hat Advanced Cluster Management for Kubernetes 5.1. Cluster management with multicluster engine on OpenShift Container Platform When you enable multicluster engine on OpenShift Container Platform, you gain the following capabilities: Hosted control planes , which is a feature that is based on the HyperShift project. With a centralized hosted control plane, you can operate OpenShift Container Platform clusters in a hyperscale manner. Hive, which provisions self-managed OpenShift Container Platform clusters to the hub and completes the initial configurations for those clusters. klusterlet agent, which registers managed clusters to the hub. Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of OpenShift Container Platform, such as single-node OpenShift on bare metal. The Infrastructure Operator includes GitOps Zero Touch Provisioning (ZTP) , which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes. Open cluster management, which provides resources to manage Kubernetes clusters. The multicluster engine is included with your OpenShift Container Platform support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the OpenShift Container Platform cluster and then install the operator. For more information, see Installing and upgrading multicluster engine operator . 5.2. Cluster management with Red Hat Advanced Cluster Management If you need cluster management capabilities beyond what OpenShift Container Platform with multicluster engine can provide, consider Red Hat Advanced Cluster Management. The multicluster engine is an integral part of Red Hat Advanced Cluster Management and is enabled by default. 5.3. Additional resources For the complete documentation for multicluster engine, see Cluster lifecycle with multicluster engine documentation , which is part of the product documentation for Red Hat Advanced Cluster Management.

Commands:
Chapter 22. Users 22.1. User Elements Users are exposed in a top-level collection and are referenced with the rel="users" link. Individual user elements contain the following: Table 22.1. User elements Element Type Description Properties user_name string The user principal name (UPN). The UPN is used as a more convenient identifier when adding a new user. link rel="tags" relationship A link to the tags sub-collection for user resources. link rel="roles" relationship A link to the roles sub-collection for user resources. name string A free-text name for the user. domain string The containing directory service domain. groups complex A list of directory service groups for this user.

Commands:
Chapter 9. Support policies Supported for certain RHEL releases: RHEL for SAP Solutions follows the general RHEL product lifecycle and related policies . Important SAP defines its own release strategy regarding the support of operating systems and operating system versions. For SAP NetWeaver-based solutions, refer to the SAP Product Availability Matrix . For SAP HANA, see SAP Note 2235581 . For general information, see SAP Note 2369910 . Production environments must comply with Red Hat and SAP support conditions. Additional SAP certifications may apply. Support for RHEL HA clusters, as part of RHEL for SAP Solutions: The RHEL for SAP Solutions subscription includes the Red Hat Enterprise Linux (RHEL) High Availability Add-on. Users of RHEL High Availability clusters should adhere to general Support Policies for RHEL High Availability Clusters in order to be eligible for support. In addition, RHEL for SAP Solutions provides resource agents, scripts and documentation for integration with & support of the following SAP applications and scenarios: Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications .

Commands: