mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Deprecated Functionality virtio-win component, BZ# 1001981 The VirtIO SCSI driver has been removed from the virtio-win package and is no longer supported on Microsoft Windows Server 2003 platform. qemu-kvm component The qemu-guest-agent-win32 package is no longer shipped as part of the qemu-kvm package. The Windows guest agent is now delivered in the Supplementary channel together with other Windows components, for example, virtio-win drivers. fence-agents component Prior to Red Hat Enterprise Linux 6.5 release, the Red Hat Enterprise Linux High Availability Add-On was considered fully supported on certain VMware ESXi/vCenter versions in combination with the fence_scsi fence agent. Due to limitations in these VMware platforms in the area of SCSI-3 persistent reservations, the fence_scsi fencing agent is no longer supported on any version of the Red Hat Enterprise Linux High Availability Add-On in VMware virtual machines, except when using iSCSI-based storage. See the Virtualization Support Matrix for High Availability for full details on supported combinations: https://access.redhat.com/site/articles/29440 Users using fence_scsi on an affected combination can contact Red Hat Global Support Services for assistance in evaluating alternative configurations or for additional information. systemtap component The systemtap-grapher package has been removed from Red Hat Enterprise Linux 6. For more information, see https://access.redhat.com/solutions/757983 . matahari component The Matahari agent framework ( matahari-* ) packages have been removed from Red Hat Enterprise Linux 6. Focus for remote systems management has shifted towards the use of the CIM infrastructure. This infrastructure relies on an already existing standard which provides a greater degree of interoperability for all users. distribution component The following packages have been deprecated and are subjected to removal in a future release of Red Hat Enterprise Linux 6. These packages will not be updated in the Red Hat Enterprise Linux 6 repositories and customers who do not use the MRG-Messaging product are advised to uninstall them from their system. mingw-gcc mingw-boost mingw32-qpid-cpp python-qmf python-qpid qpid-cpp qpid-qmf qpid-tests qpid-tools ruby-qpid saslwrapper Red Hat MRG-Messaging customers will continue to receive updated functionality as part of their regular updates to the product. fence-virt component The libvirt-qpid is no longer part of the fence-virt package. openscap component The openscap-perl subpackage has been removed from openscap .

Commands:
3.2. Volume Groups Physical volumes are combined into volume groups (VGs). This creates a pool of disk space out of which logical volumes can be allocated. Within a volume group, the disk space available for allocation is divided into units of a fixed-size called extents. An extent is the smallest unit of space that can be allocated. Within a physical volume, extents are referred to as physical extents. A logical volume is allocated into logical extents of the same size as the physical extents. The extent size is thus the same for all logical volumes in the volume group. The volume group maps the logical extents to physical extents.

Commands:
Chapter 8. Reviewing monitoring dashboards OpenShift Dedicated provides a set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads. 8.1. Monitoring dashboards in the Administrator perspective Use the Administrator perspective to access dashboards for the core OpenShift Dedicated components, including the following items: API performance etcd Kubernetes compute resources Kubernetes network resources Prometheus USE method dashboards relating to cluster and node performance Node performance metrics Figure 8.1. Example dashboard in the Administrator perspective 8.2. Monitoring dashboards in the Developer perspective In the Developer perspective, you can access only the Kubernetes compute resources dashboards: Figure 8.2. Example dashboard in the Developer perspective 8.3. Reviewing monitoring dashboards as a cluster administrator In the Administrator perspective, you can view dashboards relating to core OpenShift Dedicated cluster components. Prerequisites You have access to the cluster as a user with the dedicated-admin role. Procedure In the Administrator perspective of the OpenShift Dedicated web console, go to Observe Dashboards . Choose a dashboard in the Dashboard list. Some dashboards, such as etcd and Prometheus dashboards, produce additional sub-menus when selected. Optional: Select a time range for the graphs in the Time Range list. Select a pre-defined time period. Set a custom time range by clicking Custom time range in the Time Range list. Input or select the From and To dates and times. Click Save to save the custom time range. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items. 8.4. Reviewing monitoring dashboards as a developer In the Developer perspective, you can view dashboards relating to a selected project. Note In the Developer perspective, you can view dashboards for only one project at a time. Prerequisites You have access to the cluster as a developer or as a user. You have view permissions for the project that you are viewing the dashboard for. Procedure In the Developer perspective in the OpenShift Dedicated web console, click Observe and go to the Dashboards tab. Select a project from the Project: drop-down list. Select a dashboard from the Dashboard drop-down list to see the filtered metrics. Note All dashboards produce additional sub-menus when selected, except Kubernetes / Compute Resources / Namespace (Pods) . Optional: Select a time range for the graphs in the Time Range list. Select a pre-defined time period. Set a custom time range by clicking Custom time range in the Time Range list. Input or select the From and To dates and times. Click Save to save the custom time range. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items.

Commands:
11.5.2. Network/Netmask Directives Format You can also use the network/netmask directives format for route- interface files. The following is a template for the network/netmask format, with instructions following afterwards: ADDRESS0= 10.10.10.0 is the network address of the remote network or host to be reached. NETMASK0= 255.255.255.0 is the netmask for the network address defined with ADDRESS0= 10.10.10.0 . GATEWAY0= 192.168.1.1 is the default gateway, or an IP address that can be used to reach ADDRESS0= 10.10.10.0 The following is an example of a route- interface file using the network/netmask directives format. The default gateway is 192.168.0.1 but a leased line or WAN connection is available at 192.168.0.10 . The two static routes are for reaching the 10.10.10.0/24 and 172.16.1.0/24 networks: Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0 , ADDRESS1 , ADDRESS2 , and so on.

Commands:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.1.1
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.10 ADDRESS1=172.16.1.10 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.10
4.11. Displaying Extended GFS Information and Statistics You can use the gfs_tool command to gather a variety of details about GFS. This section describes typical use of the gfs_tool command for displaying statistics, space usage, and extended status. Usage Displaying Statistics The counters flag displays statistics about a file system. If -c is used, the gfs_tool command continues to run, displaying statistics once per second. Displaying Space Usage The df flag displays a space-usage summary of a given file system. The information is more detailed than a standard df . Displaying Extended Status The stat flag displays extended status information about a file. MountPoint Specifies the file system to which the action applies. File Specifies the file from which to get information. The gfs_tool command provides additional action flags (options) not listed in this section. For more information about other gfs_tool flags, refer to the gfs_tool man page. Examples This example reports extended file system usage about file system /gfs . This example reports extended file status about file /gfs/datafile .

Commands:
gfs_tool counters MountPoint
gfs_tool df MountPoint
gfs_tool stat File
gfs_tool df /gfs
gfs_tool stat /gfs/datafile
Chapter 7. Adding annotation to the pre-existing backingstores Adding the correct annotation to the pre-existing backingstores allows the backingstores backed by object gateways (RGWs) to report its actual and free size. The Multicloud Object Gateway (MCG) can retrieve and use this information. This flow is only relevant if RGW is present and in-use on the cluster. RGW is used by default only in on-premise platforms such as vSphere. Note If you added the annotations to pre-existing backingstores after upgrading to OpenShift Data Foundation version 4.8, then you do not need to add them after upgrading to 4.9. All backingstores created in version 4.8 and above will already have this annotation by default. Procedure Log in to the OpenShift Container Platform Web Console. Click Home Search . Search for BackingStore in Resources and click on it. Beside the S3-compatible BackingStore, click Action Menu (...) Edit annotations . Add rgw for KEY . Click Save .

Commands:
Chapter 3. Integrating with PagerDuty If you are using PagerDuty , you can forward alerts from Red Hat Advanced Cluster Security for Kubernetes to PagerDuty. The following steps represent a high-level workflow for integrating Red Hat Advanced Cluster Security for Kubernetes with PagerDuty: Add a new API service in PagerDuty and get the integration key. Use the integration key to set up notifications in Red Hat Advanced Cluster Security for Kubernetes. Identify the policies you want to send notifications for, and update the notification settings for those policies. 3.1. Configuring PagerDuty Start integrating with PagerDuty by creating a new service and by getting the integration key. Procedure Go to Configuration Services . Select Add Services . Under General Settings , specify a Name and Description . Under Integration Setting , click Use our API Directly with Events v2 API selected for the Integration Type drop-down menu. Under Incident Settings , select an Escalation Policy , and configure notification settings and incident timeouts. Accept default settings for Incident Behavior and Alert Grouping , or configure them as required. Click Add Service . From the Service Details page, make note of the Integration Key . 3.2. Configuring Red Hat Advanced Cluster Security for Kubernetes Create a new integration in Red Hat Advanced Cluster Security for Kubernetes by using the integration key. Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll down to the Notifier Integrations section and select PagerDuty . Click New Integration ( add icon). Enter a name for Integration Name . Enter the integration key in the PagerDuty integration key field. Click Test to validate that the integration with PagerDuty is working. Click Create to create the configuration. 3.3. Configuring policy notifications Enable alert notifications for system policies. Procedure In the RHACS portal, go to Platform Configuration Policy Management . Select one or more policies for which you want to send alerts. Under Bulk actions , select Enable notification . In the Enable notification window, select the PagerDuty notifier. Note If you have not configured any other integrations, the system displays a message that no notifiers are configured. Click Enable . Note Red Hat Advanced Cluster Security for Kubernetes sends notifications on an opt-in basis. To receive notifications, you must first assign a notifier to the policy. Notifications are only sent once for a given alert. If you have assigned a notifier to a policy, you will not receive a notification unless a violation generates a new alert. Red Hat Advanced Cluster Security for Kubernetes creates a new alert for the following scenarios: A policy violation occurs for the first time in a deployment. A runtime-phase policy violation occurs in a deployment after you resolved the runtime alert for a policy in that deployment.

Commands:
5.315. subversion and neon 5.315.1. RHEA-2012:0896 - subversion and neon bug fix and enhancement update Updated subversion and neon packages that fix several bugs and add an enhancement are now available. Subversion (SVN) is a concurrent version control system which enables one or more users to collaborate in developing and maintaining a hierarchy of files and directories while keeping a history of all changes. Neon is an HTTP library and WebDAV client library used by Subversion. Bug Fixes BZ# 749494 The "svn" command unnecessarily required access to the parent directory during certain types of merge operations, which could be denied by the authorization policy on the server. The SVN client has been fixed to not require such access. BZ# 751321 When the "AuthzForceUsernameCase lower" directive was configured in the /etc/httpd/conf.d/subversion.conf file, the "mod_authz_svn" module could crash with a segmentation fault. With this update, segmentation faults no longer occur when using the "AuthzForceUsernameCase" directive. BZ# 798636 Due to a bug in the neon HTTP library, the Server Name Indication (SNI) support was disabled on an SVN client. This update upgrades the neon library, and SNI now works as expected. Enhancement BZ# 711904 , BZ# 720790 This update adds an init script for the "svnserve" daemon. Users are advised to upgrade to these updated subversion and neon packages, which resolve these issues and add this enhancement.

Commands:
Chapter 5. Viewing logs for a resource You can view the logs for various resources, such as builds, deployments, and pods by using the OpenShift CLI (oc) and the web console. Note Resource logs are a default feature that provides limited log viewing capability. To enhance your log retrieving and viewing experience, it is recommended that you install OpenShift Logging . OpenShift Logging aggregates all the logs from your OpenShift Container Platform cluster, such as node system audit logs, application container logs, and infrastructure logs, into a dedicated log store. You can then query, discover, and visualize your log data through the Kibana interface . Resource logs do not access the OpenShift Logging log store. 5.1. Viewing resource logs You can view the log for various resources in the OpenShift CLI (oc) and web console. Logs read from the tail, or end, of the log. Prerequisites Access to the OpenShift CLI (oc). Procedure (UI) In the OpenShift Container Platform console, navigate to Workloads Pods or navigate to the pod through the resource you want to investigate. Note Some resources, such as builds, do not have pods to query directly. In such instances, you can locate the Logs link on the Details page for the resource. Select a project from the drop-down menu. Click the name of the pod you want to investigate. Click Logs . Procedure (CLI) View the log for a specific pod: USD oc logs -f <pod_name> -c <container_name> where: -f Optional: Specifies that the output follows what is being written into the logs. <pod_name> Specifies the name of the pod. <container_name> Optional: Specifies the name of a container. When a pod has more than one container, you must specify the container name. For example: USD oc logs ruby-58cd97df55-mww7r USD oc logs -f ruby-57f7f4855b-znl92 -c ruby The contents of log files are printed out. View the log for a specific resource: USD oc logs <object_type>/<resource_name> 1 1 Specifies the resource type and name. For example: USD oc logs deployment/ruby The contents of log files are printed out.

Commands:
oc logs -f <pod_name> -c <container_name>
oc logs ruby-58cd97df55-mww7r
oc logs -f ruby-57f7f4855b-znl92 -c ruby
oc logs <object_type>/<resource_name> 1
oc logs deployment/ruby
14.7.9. Detaching a Node Device The virsh nodedev-detach detaches the nodedev from the host so it can be safely used by guests via <hostdev> passthrough. This action can be reversed with the nodedev-reattach command but it is done automatically for managed services. This command also accepts nodedev-dettach . Note that different drivers expect the device to be bound to different dummy devices. Using the --driver option allows you to specify the desired back-end driver.

Commands:
13.4. OpenLDAP Configuration Files OpenLDAP configuration files are installed into the /etc/openldap/ directory. The following is a brief list highlighting the most important directories and files: /etc/openldap/ldap.conf - This is the configuration file for all client applications which use the OpenLDAP libraries such as ldapsearch , ldapadd , Sendmail, Evolution , and Gnome Meeting . /etc/openldap/slapd.conf - This is the configuration file for the slapd daemon. Refer to Section 13.6.1, "Editing /etc/openldap/slapd.conf " for more information file. /etc/openldap/schema/ directory - This subdirectory contains the schema used by the slapd daemon. Refer to Section 13.5, "The /etc/openldap/schema/ Directory" for more information. Note If the nss_ldap package is installed, it creates a file named /etc/ldap.conf . This file is used by the PAM and NSS modules supplied by the nss_ldap package. Refer to Section 13.7, "Configuring a System to Authenticate Using OpenLDAP" for more information.

Commands:
probe::ioscheduler.elv_completed_request Name probe::ioscheduler.elv_completed_request - Fires when a request is completed Synopsis ioscheduler.elv_completed_request Values name Name of the probe point rq Address of the request elevator_name The type of I/O elevator currently enabled disk_major Disk major number of the request disk_minor Disk minor number of the request rq_flags Request flags

Commands:
C.2. Desktop Environments and Window Managers Once an X server is running, X client applications can connect to it and create a GUI for the user. A range of GUIs are available with Red Hat Enterprise Linux, from the rudimentary Tab Window Manager (twm) to the highly developed and interactive desktop environment (such as GNOME or KDE ) that most Red Hat Enterprise Linux users are familiar with. To create the latter, more comprehensive GUI, two main classes of X client application must connect to the X server: a window manager and a desktop environment . C.2.1. Maximum number of concurrent GUI sessions Multiple GUI sessions for different users can be run at the same time on the same machine. The maximum number of concurrent GUI sessions is limited by the hardware, especially by the memory size, and by the workload demands of the running applications. For common PCs the maximum possible number of concurrent GUI sessions is not higher than 10 to 15, depending on previously described circumstances. Logging the same user into GNOME more than once on the same machine is not supported, because some applications could terminate unexpectedly.

Commands:
Chapter 4. Test the Configuration Once you have configured Ceph Object Gateway to use LDAP to authenticate users, test the configuration. 4.1. Add an S3 User to the LDAP Server In the administrative console on LDAP server, create at least one S3 user so that an S3 client can use the LDAP user credentials. Make a note of the user name and secret for use when passing the credentials to the S3 client. 4.2. Export an LDAP Token When running Ceph Object Gateway with LDAP, the access token is all that is required. However, the access token is created from the access key and secret. Export the access key and secret key as an LDAP token. Export the access key. Export the secret. Export the token. For LDAP, use ldap as the token type ( ttype ). For Active Directory, use ad as the token type. The result is a base-64 encoded string, which is the access token. Provide this access token to S3 clients in lieu of the access key. The secret is no longer required. (Optional) For added convenience, export the base-64 encoded string to the RGW_ACCESS_KEY_ID environment variable if the S3 client uses the environment variable. 4.3. Test the Configuration with an S3 Client Pick a Ceph Object Gateway client such as Python Boto. Configure it to use the RGW_ACCESS_KEY_ID environment variable. Alternatively, you may copy the base-64 encoded string and specify it as the access key. Then, run the Ceph client. Note The secret is no longer required.

Commands:
export RGW_ACCESS_KEY_ID="<username>"
export RGW_SECRET_ACCESS_KEY="<password>"
radosgw-token --encode --ttype=ldap
radosgw-token --encode --ttype=ad
export RGW_ACCESS_KEY_ID="ewogICAgIlJHV19UT0tFTiI6IHsKICAgICAgICAidmVyc2lvbiI6IDEsCiAgICAgICAgInR5cGUiOiAibGRhcCIsCiAgICAgICAgImlkIjogImNlcGgiLAogICAgICAgICJrZXkiOiAiODAwI0dvcmlsbGEiCiAgICB9Cn0K"
7.14. RHEA-2014:1441 - new packages: libmicrohttpd New libmicrohttpd packages are now available for Red Hat Enterprise Linux 6. GNU libmicrohttpd is a lightweight C library that can be used to easily embed an HTTP server in another application. This enhancement update adds the libmicrohttpd packages to Red Hat Enterprise Linux 6. (BZ# 1087821 ) All users who require libmicrohttpd are advised to install these new packages.

Commands:
2.29. RHEA-2011:0627 - new package: pki-core New pki-core packages are now available for Red Hat Enterprise Linux 6. Red Hat Certificate System is an enterprise software system designed to manage enterprise public key infrastructure (PKI) deployments. PKI Core contains fundamental packages required by Red Hat Certificate System, which comprise the Certificate Authority (CA) subsystem. Note: The Certificate Authority component provided by this errata cannot be used as a standalone server. It is installed and operates as a part of the Red Hat Enterprise Identity (IPA). This enhancement update adds the pki-core packages to Red Hat Enterprise Linux 6. (BZ# 645097 ) All users should install these new packages.

Commands:
7.165. ppc64-diag 7.165.1. RHSA-2015:1320 - Moderate: ppc64-diag security, bug fix and enhancement update Updated ppc64-diag packages that fix two security issues, several bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6. Red Hat Product Security has rated this update as having Moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE links in the References section. The ppc64-diag packages provide diagnostic tools for Linux on the 64-bit PowerPC platforms. The platform diagnostics write events reported by the firmware to the service log, provide automated responses to urgent events, and notify system administrators or connected service frameworks about the reported events. Security Fix CVE-2014-4038 , CVE-2014-4039 Multiple insecure temporary file use flaws were found in the way the ppc64-diag utility created certain temporary files. A local attacker could possibly use either of these flaws to perform a symbolic link attack and overwrite arbitrary files with the privileges of the user running ppc64-diag, or obtain sensitive information from the temporary files. The ppc64-diag packages have been upgraded to upstream version 2.6.7, which provides a number of bug fixes and enhancements over the version. (BZ# 1148142 ) Bug Fixes BZ# 1139655 Previously, the "explain_syslog" and "syslog_to_svclog" commands failed with a "No such file or directory" error message. With this update, the ppc64-diag package specifies the location of the message_catalog directory correctly, which prevents the described error from occurring. BZ# 1131501 Prior to this update, the /var/lock/subsys/rtas_errd file was incorrectly labeled for SELinux as "system_u:object_r:var_lock_t:s0". This update corrects the SELinux label to "system_u:object_r:rtas_errd_var_lock_t:s0". Users of ppc64-diag are advised to upgrade to these updated packages, which correct these issues and add these enhancements.

Commands: