mtpti5iD/redhat-docs_dataset huggingface dataset:
B.64. pam B.64.1. RHSA-2010:0891 - Moderate: pam security update Updated pam packages that fix three security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Pluggable Authentication Modules (PAM) provide a system whereby administrators can set up authentication policies without having to recompile programs that handle authentication. CVE-2010-3853 It was discovered that the pam_namespace module executed the external script namespace.init with an unchanged environment inherited from an application calling PAM. In cases where such an environment was untrusted (for example, when pam_namespace was configured for setuid applications such as su or sudo), a local, unprivileged user could possibly use this flaw to escalate their privileges. CVE-2010-3435 It was discovered that the pam_env and pam_mail modules used root privileges while accessing user's files. A local, unprivileged user could use this flaw to obtain information, from the lines that have the KEY=VALUE format expected by pam_env, from an arbitrary file. Also, in certain configurations, a local, unprivileged user using a service for which the pam_mail module was configured for, could use this flaw to obtain limited information about files or directories that they do not have access to. CVE-2010-3316 Note: As part of the fix for CVE-2010-3435 , this update changes the default value of pam_env's configuration option user_readenv to 0, causing the module to not read user's ~/.pam_environment configuration file by default, as reading it may introduce unexpected changes to the environment of the service using PAM, or PAM modules consulted after pam_env. It was discovered that the pam_xauth module did not verify the return values of the setuid() and setgid() system calls. A local, unprivileged user could use this flaw to execute the xauth command with root privileges and make it read an arbitrary input file. Red Hat would like to thank Sebastian Krahmer of the SuSE Security Team for reporting the CVE-2010-3435 issue. All pam users should upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
2.2. HTTP Authentication Any user with a Red Hat Virtualization account has access to the REST API. An API user submits a mandatory Red Hat Virtualization Manager user name and password with all requests to the API. Each request uses HTTP Basic Authentication [2] to encode these credentials. If a request does not include an appropriate Authorization header, the API sends a 401 Authorization Required as a result: Example 2.1. Access to the REST API without appropriate credentials Request are issued with an Authorization header for the specified realm. An API user encodes an appropriate Red Hat Virtualization Manager domain and user in the supplied credentials with the username@domain:password convention. The following table shows the process for encoding credentials in base64. Table 2.1. Encoding credentials for API access Item Value username rhevmadmin domain domain.example.com password 123456 unencoded credentials rhevmadmin@domain.example.com:123456 base64 encoded credentials cmhldm1hZG1pbkBibGFjay5xdW1yYW5ldC5jb206MTIzNDU2 An API user provides the base64 encoded credentials as shown: Example 2.2. Access to the REST API with appropriate credentials Important Basic authentication involves potentially sensitive information, such as passwords, sent as plain text. REST API requires Hypertext Transfer Protocol Secure (HTTPS) for transport-level encryption of plain-text requests. Important Some base64 libraries break the result into multiple lines and terminate each line with a newline character. This breaks the header and causes a faulty request. The Authorization header requires the encoded credentials on a single line within the header. [2] Basic Authentication is described in RFC 2617 HTTP Authentication: Basic and Digest Access Authentication .

Commands:
HEAD [base] HTTP/1.1 Host: [host] HTTP/1.1 401 Authorization Required
HEAD [base] HTTP/1.1 Host: [host] Authorization: Basic cmhldm1hZG1pbkBibGFjay5xdW1yYW5ldC5jb206MTIzNDU2 HTTP/1.1 200 OK
29.5. Analyzing the Data Periodically, the OProfile daemon, oprofiled , collects the samples and writes them to the /var/lib/oprofile/samples/ directory. Before reading the data, make sure all data has been written to this directory by executing the following command as root: Each sample file name is based on the name of the executable. For example, the samples for the default event on a Pentium III processor for /bin/bash becomes: The following tools are available to profile the sample data once it has been collected: opreport opannotate Use these tools, along with the binaries profiled, to generate reports that can be further analyzed. Warning The executable being profiled must be used with these tools to analyze the data. If it must change after the data is collected, back up the executable used to create the samples as well as the sample files. Please note that the sample file and the binary have to agree. Making a backup is not going to work if they do not match. oparchive can be used to address this problem. Samples for each executable are written to a single sample file. Samples from each dynamically linked library are also written to a single sample file. While OProfile is running, if the executable being monitored changes and a sample file for the executable exists, the existing sample file is automatically deleted. Thus, if the existing sample file is needed, it must be backed up, along with the executable used to create it before replacing the executable with a new version. The OProfile analysis tools use the executable file that created the samples during analysis. If the executable changes the analysis tools will be unable to analyze the associated samples. See Section 29.4, "Saving Data" for details on how to back up the sample file. 29.5.1. Using opreport The opreport tool provides an overview of all the executables being profiled. The following is part of a sample output: Each executable is listed on its own line. The first column is the number of samples recorded for the executable. The second column is the percentage of samples relative to the total number of samples. The third column is the name of the executable. See the opreport man page for a list of available command-line options, such as the -r option used to sort the output from the executable with the smallest number of samples to the one with the largest number of samples.

Commands:
~]# opcontrol --dump
\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000
Profiling through timer interrupt TIMER:0| samples| %| ------------------ 25926 97.5212 no-vmlinux 359 1.3504 pi 65 0.2445 Xorg 62 0.2332 libvte.so.4.4.0 56 0.2106 libc-2.3.4.so 34 0.1279 libglib-2.0.so.0.400.7 19 0.0715 libXft.so.2.1.2 17 0.0639 bash 8 0.0301 ld-2.3.4.so 8 0.0301 libgdk-x11-2.0.so.0.400.13 6 0.0226 libgobject-2.0.so.0.400.7 5 0.0188 oprofiled 4 0.0150 libpthread-2.3.4.so 4 0.0150 libgtk-x11-2.0.so.0.400.13 3 0.0113 libXrender.so.1.2.2 3 0.0113 du 1 0.0038 libcrypto.so.0.9.7a 1 0.0038 libpam.so.0.77 1 0.0038 libtermcap.so.2.0.8 1 0.0038 libX11.so.6.2 1 0.0038 libgthread-2.0.so.0.400.7 1 0.0038 libwnck-1.so.4.9.0
Chapter 2. Getting Started with NetworkManager 2.1. Overview of NetworkManager In Red Hat Enterprise Linux 7, the default networking service is provided by NetworkManager , which is a dynamic network control and configuration daemon to keep network devices and connections up and active when they are available. The traditional ifcfg type configuration files are still supported. See Section 2.6, "Using NetworkManager with Network Scripts" for more information. 2.1.1. Benefits of Using NetworkManager The main benefits of using NetworkManager are: Making Network management easier: NetworkManager ensures that network connectivity works. When it detects that there is no network configuration in a system but there are network devices, NetworkManager creates temporary connections to provide connectivity. Providing easy setup of connection to the user: NetworkManager offers management through different tools - GUI, nmtui, nmcli -. See Section 2.5, "NetworkManager Tools" . Supporting configuration flexibility. For example, configuring a WiFi interface, NetworkManager scans and shows the available wifi networks. You can select an interface, and NetworkManager displays the required credentials providing automatic connection after the reboot process. NetworkManager can configure network aliases, IP addresses, static routes, DNS information, and VPN connections, as well as many connection-specific parameters. You can modify the configuration options to reflect your needs. Offering an API through D-Bus which allows applications to query and control network configuration and state. In this way, applications can check or configure networking through D-BUS. For example, the web console interface, which monitors and configures servers through a web browser, uses the NetworkManager D-BUS interface to configure networking. Maintaining the state of devices after the reboot process and taking over interfaces which are set into managed mode during restart. Handling devices which are not explicitly set unmanaged but controlled manually by the user or another network service.

Commands:
5.4.16.3. Converting an LVM RAID1 Logical Volume to an LVM Linear Logical Volume You can convert an existing RAID1 LVM logical volume to an LVM linear logical volume with the lvconvert command by specifying the -m0 argument. This removes all the RAID data subvolumes and all the RAID metadata subvolumes that make up the RAID array, leaving the top-level RAID1 image as the linear logical volume. The following example displays an existing LVM RAID1 logical volume. The following command converts the LVM RAID1 logical volume my_vg/my_lv to an LVM linear device. When you convert an LVM RAID1 logical volume to an LVM linear volume, you can specify which physical volumes to remove. The following example shows the layout of an LVM RAID1 logical volume made up of two images: /dev/sda1 and /dev/sdb1 . In this example, the lvconvert command specifies that you want to remove /dev/sda1 , leaving /dev/sdb1 as the physical volume that makes up the linear device.

Commands:
lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv 100.00 my_lv_rimage_0(0),my_lv_rimage_1(0) [my_lv_rimage_0] /dev/sde1(1) [my_lv_rimage_1] /dev/sdf1(1) [my_lv_rmeta_0] /dev/sde1(0) [my_lv_rmeta_1] /dev/sdf1(0)
lvconvert -m0 my_vg/my_lv lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv /dev/sde1(1)
lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv 100.00 my_lv_rimage_0(0),my_lv_rimage_1(0) [my_lv_rimage_0] /dev/sda1(1) [my_lv_rimage_1] /dev/sdb1(1) [my_lv_rmeta_0] /dev/sda1(0) [my_lv_rmeta_1] /dev/sdb1(0) lvconvert -m0 my_vg/my_lv /dev/sda1 lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv /dev/sdb1(1)
2.2.3. Comments and Documentation All probes and functions should include comment blocks that describe their purpose, the data they provide, and the context in which they run (e.g. interrupt, process, etc). Use comments in areas where your intent may not be clear from reading the code. Note that specially-formatted comments are automatically extracted from most tapsets and included in this guide. This helps ensure that tapset contributors can write their tapset and document it in the same place. The specified format for documenting tapsets is as follows: For example: To override the automatically-generated Synopsis content, use: For example: It is recommended that you use the <programlisting> tag in this instance, since overriding the Synopsis content of an entry does not automatically form the necessary tags. For the purposes of improving the DocBook XML output of your comments, you can also use the following XML tags in your comments: command emphasis programlisting remark (tagged strings will appear in Publican beta builds of the document)

Commands:
/** * probe tapset.name - Short summary of what the tapset does. * @argument: Explanation of argument. * @argument2: Explanation of argument2. Probes can have multiple arguments. * * Context: * A brief explanation of the tapset context. * Note that the context should only be 1 paragraph short. * * Text that will appear under "Description." * * A new paragraph that will also appear under the heading "Description". * * Header: * A paragraph that will appear under the heading "Header". **/
/** * probe vm.write_shared_copy- Page copy for shared page write. * @address: The address of the shared write. * @zero: Boolean indicating whether it is a zero page * (can do a clear instead of a copy). * * Context: * The process attempting the write. * * Fires when a write to a shared page requires a page copy. This is * always preceded by a vm.shared_write . **/
* Synopsis: * New Synopsis string *
/** * probe signal.handle - Fires when the signal handler is invoked * @sig: The signal number that invoked the signal handler * * Synopsis: * <programlisting>static int handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka, * sigset_t *oldset, struct pt_regs * regs)</programlisting> */
12.7. Additional Resources The following sources of information provide additional resources regarding BIND. 12.7.1. Installed Documentation BIND features a full-range of installed documentation covering many different topics, each placed in its own subject directory: /usr/share/doc/bind- <version-number> / - This directory lists the most recent features. Replace <version-number> with the version of bind installed on the system. /usr/share/doc/bind- <version-number> /arm/ - This directory contains HTML and SGML of the BIND 9 Administrator Reference Manual , which details BIND resource requirements, how to configure different types of nameservers, perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start. Replace <version-number> with the version of bind installed on the system. /usr/share/doc/bind- <version-number> /draft/ - This directory contains assorted technical documents that reviews issues related to DNS service and some methods proposed to address them. Replace <version-number> with the version of bind installed on the system. /usr/share/doc/bind- <version-number> /misc/ - This directory contains documents designed to address specific advanced issues. Users of BIND version 8 should consult the migration document for specific changes they must make when moving to BIND 9. The options file lists all of the options implemented in BIND 9 that are used in /etc/named.conf . Replace <version-number> with the version of bind installed on the system. /usr/share/doc/bind- <version-number> /rfc/ - This directory privides every RFC document related to BIND. Replace <version-number> with the version of bind installed on the system. BIND related man pages - There are a number of man pages for the various applications and configuration files involved with BIND. The following lists some of the more important man pages. Administrative Applications man rndc - Explains the different options available when using the rndc command to control a BIND nameserver. Server Applications man named - Explores assorted arguments that can be used to control the BIND nameserver daemon. man lwresd - Describes the purpose of and options available for the lightweight resolver daemon. Configuration Files man named.conf - A comprehensive list of options available within the named configuration file. man rndc.conf - A comprehensive list of options available within the rndc configuration file.

Commands:
Part VI. Troubleshooting and common questions When you review the subscriptions service data for your account, you might have additional questions about how those calculations are made or whether the calculations are accurate. Answers for some of the most commonly asked questions might help you understand more about the data that appears in the subscriptions service. Other information can help you troubleshoot some common problems that are experienced by subscriptions service users. In some cases, completing the suggested steps in the troubleshooting information can help you improve the accuracy of the reported data in the subscriptions service. Troubleshoot Troubleshooting: Correcting over-reporting of virtualized RHEL Troubleshooting: Correcting problems with filtering Learn more How is the subscription threshold calculated? How is core hour usage data calculated? How do vCPUs and hyperthreading affect the subscriptions service usage data?

Commands:
2.4. Threats to Workstation and Home PC Security Workstations and home PCs may not be as prone to attack as networks or servers, but since they often contain sensitive data, such as credit card information, they are targeted by system crackers. Workstations can also be co-opted without the user's knowledge and used by attackers as "slave" machines in coordinated attacks. For these reasons, knowing the vulnerabilities of a workstation can save users the headache of reinstalling the operating system, or worse, recovering from data theft. 2.4.1. Bad Passwords Bad passwords are one of the easiest ways for an attacker to gain access to a system. For more on how to avoid common pitfalls when creating a password, refer to Section 4.3, "Password Security" .

Commands:
probe::tcpmib.PassiveOpens Name probe::tcpmib.PassiveOpens - Count the passive creation of a socket Synopsis tcpmib.PassiveOpens Values sk pointer to the struct sock being acted on op value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function tcpmib_filter_key . If the packet passes the filter is is counted in the global PassiveOpens (equivalent to SNMP's MIB TCP_MIB_PASSIVEOPENS)

Commands:
Installation overview OpenShift Container Platform 4.16 Overview content for installing OpenShift Container Platform Red Hat OpenShift Documentation Team

Commands:
oc get nodes
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
oc get machines -A
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
capabilities: baselineCapabilitySet: v4.11 1 additionalEnabledCapabilities: 2 - CSISnapshot - Console - Storage
oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator default -o yaml
oc get deployment -n openshift-ingress
oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'
map[cidr:10.128.0.0/14 hostPrefix:23]
oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
{"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"} {"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}' 1
oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
openshift-samples
oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
lastTransitionTime: 2022-07-22T03:14:35Z
message: The following capabilities could not be disabled: openshift-samples
reason: CapabilitiesImplicitlyEnabled
status: True
type: ImplicitlyEnabledCapabilities
oc adm release extract --registry-config "USD{pullsecret_file}" --command=openshift-install-fips --to "USD{extract_dir}" USD{RELEASE_IMAGE}
tar -xvf openshift-install-rhel9-amd64.tar.gz
Chapter 1. Overview of deploying in external mode Red Hat OpenShift Data Foundation can make services from an external Red Hat Ceph Storage cluster available for consumption through OpenShift Container Platform clusters running on any platform. See Planning your deployment for more information. For instructions regarding how to install a RHCS cluster, see the installation guide . Follow these steps to deploy OpenShift Data Foundation in external mode: Deploy OpenShift Data Foundation using Red Hat Ceph Storage . 1.1. Disaster recovery requirements Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced subscription A valid Red Hat Advanced Cluster Management for Kubernetes subscription For more information, see the knowledgebase article on OpenShift Data Foundation subscriptions . For detailed disaster recovery solution requirements, see Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads guide, and Requirements and recommendations section of the Install guide in Red Hat Advanced Cluster Management for Kubernetes documentation. 1.2. Network ports required between OpenShift Container Platform and Ceph when using external mode deployment List of TCP ports, source OpenShift Container Platform and destination RHCS TCP ports To be used for 6789, 3300 Ceph Monitor 6800 - 7300 Ceph OSD, MGR, MDS 9283 Ceph MGR Prometheus Exporter For more information about why these ports are required, see Chapter 2. Ceph network configuration of RHCS Configuration Guide .

Commands:
Chapter 141. KafkaMirrorMaker2MirrorSpec schema reference Used in: KafkaMirrorMaker2Spec Property Property type Description sourceCluster string The alias of the source cluster used by the Kafka MirrorMaker 2 connectors. The alias must match a cluster in the list at spec.clusters . targetCluster string The alias of the target cluster used by the Kafka MirrorMaker 2 connectors. The alias must match a cluster in the list at spec.clusters . sourceConnector KafkaMirrorMaker2ConnectorSpec The specification of the Kafka MirrorMaker 2 source connector. heartbeatConnector KafkaMirrorMaker2ConnectorSpec The specification of the Kafka MirrorMaker 2 heartbeat connector. checkpointConnector KafkaMirrorMaker2ConnectorSpec The specification of the Kafka MirrorMaker 2 checkpoint connector. topicsPattern string A regular expression matching the topics to be mirrored, for example, "topic1|topic2|topic3". Comma-separated lists are also supported. topicsBlacklistPattern string The topicsBlacklistPattern property has been deprecated, and should now be configured using .spec.mirrors.topicsExcludePattern . A regular expression matching the topics to exclude from mirroring. Comma-separated lists are also supported. topicsExcludePattern string A regular expression matching the topics to exclude from mirroring. Comma-separated lists are also supported. groupsPattern string A regular expression matching the consumer groups to be mirrored. Comma-separated lists are also supported. groupsBlacklistPattern string The groupsBlacklistPattern property has been deprecated, and should now be configured using .spec.mirrors.groupsExcludePattern . A regular expression matching the consumer groups to exclude from mirroring. Comma-separated lists are also supported. groupsExcludePattern string A regular expression matching the consumer groups to exclude from mirroring. Comma-separated lists are also supported.

Commands: