mtpti5iD/redhat-docs_dataset huggingface dataset:
16.3. SSM Resources For more information on SSM, see the following resources: The man ssm page provides good descriptions and examples, as well as details on all of the commands and options too specific to be documented here. Local documentation for SSM is stored in the doc/ directory. The SSM wiki can be accessed at http://storagemanager.sourceforge.net/index.html . The mailing list can be subscribed from https://lists.sourceforge.net/lists/listinfo/storagemanager-devel and mailing list archives from http://sourceforge.net/mailarchive/forum.php?forum_name=storagemanager-devel . The mailing list is where developers communicate. There is currently no user mailing list so feel free to post questions there as well.

Commands:
Chapter 9. Additional Use Cases Once the cluster is up and running, there are additional use cases to consider. Expanding the Cluster with Multi-Site Migrating Data with NFS-Ganesha Configuring the Cluster for Static Webhosting Configuring the Cluster with LDAP/AD Configuring the Cluster to use Keystone 9.1. Expanding the Cluster with Multisite When developing storage strategies, the procedure for Creating a Realm ensured that the cluster is already configured to use multi-site with its own realm, master zone group and master zone. A typical production cluster will have a secondary zone with its own Ceph Storage Cluster in a separate physical location to act as a backup in the event of a disaster. To set up a secondary zone, repeat the procedures in this guide. Generally, the secondary zone should have the same hardware configuration and sizing as the master zone. See Configuring a Secondary Zone for additional details. Adding a secondary zone adds Failover and Disaster Recovery capabilities to the cluster. 9.2. Migrating Data with NFS Ganesha If the Ceph Object Gateway and Ceph Storage Cluster replaces a file system-based storage solution, consider using Ceph's NFS-Ganesha solution to migrate data from the file system into Ceph Object Gateway. See Exporting the Namespace to NFS-Ganesha chapter in the Ceph Object Gateway Configuration and Administration Guide. 9.3. Configuring the Cluster for Static Webhosting Traditional web hosting sometimes involves setting up a web server for each website, which can use resources inefficiently when content does not change dynamically. Ceph Object Gateway can host static web sites in S3 buckets- that is, sites that do not use server-side services like PHP, servlets, databases, nodejs and the like. This approach is substantially more economical than setting up VMs with web servers for each site. See Configuring Gateways for Static Web Hosting for additional details. 9.4. Configuring the Cluster for LDAP/AD Organizations deploying Ceph Object Gateway for their users and applications may choose to use Light-weight Directory Access Protocol (LDAP) or Microsoft Active Directory (AD) to authenticate with the Ceph Object Gateway in lieu of creating Ceph Object Gateway users. Using LDAP/AD means that Ceph Object Gateway can integrate with an organizations LDAP/AD single sign-on initiatives. For details, see the Ceph Object Gateway with LDAP/AD Guide for Red Hat Ceph Storage 4. 9.5. Configuring the Cluster to use OpenStack Keystone When deploying the Ceph Object Gateway in lieu of OpenStack Swift, it is possible to configure the gateway to use OpenStack Keystone to authenticate users in lieu of creating Ceph Object Gateway users. For details, see the Using Keystone to Authenticate Ceph Object Gateway Users guide for Red Hat Ceph Storage 4.

Commands:
4.111. jwhois 4.111.1. RHBA-2011:0921 - jwhois bug fix and enhancement update An updated jwhois package that fixes one bug and adds one enhancement is now available for Red Hat Enterprise Linux 6. The jwhois package provides a whois client, which is used to obtain information about domain names and IP addresses from whois servers. Bug Fix BZ# 682832 Previously, when querying a domain with the name length near the allowed limit of 63 characters, and emitting command options to a whois server, the "whois" command failed because both the domain name and command options were given to a function responsible for translating Internationalized Domain Names (IDN) to ASCII. The length of such command was greater than the allowed limit. This update fixes this bug so that only the domain name is now translated after executing the command. Enhancement BZ# 664449 Previously, jwhois did not contain the whois server details for the dotEmarat extension. As a result, whois queries for these extensions were incorrectly directed to whois.internic.net. With this update, the configuration file correctly directs queries for the dotEmarat domains to whois.aeda.net.ae. All users of whois clients are advised to upgrade to this updated package, which fixes this bug and adds this enhancement.

Commands:
8.10. Assessing Configuration Compliance of a Container or a Container Image with a Specific Baseline Follow the steps to assess compliance of your container or a container image with a specific security baseline, such as Operating System Protection Profile (OSPP) or Payment Card Industry Data Security Standard (PCI-DSS). Prerequisites The openscap-utils and scap-security-guide packages are installed. Procedure Find the ID of a container or a container image, for example: Evaluate the compliance of the container image with the OSPP profile and save scan results in the report.html HTML file. Replace 096cae65a207 with the ID of your container image and the ospp value with pci-dss if you assess configuration compliance with the PCI-DSS baseline. Verification Check the results in a browser of your choice, for example: Note The rules marked as notapplicable are rules that do not apply to containerized systems. These rules apply only to bare-metal or virtualized systems. Additional Resources For more information, see the oscap-docker(8) and scap-security-guide(8) man pages. The SCAP Security Guide documentation installed in the file:///usr/share/doc/scap-security-guide-doc-0.1.46/ directory.

Commands:
~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi7/ubi latest 096cae65a207 7 weeks ago 239 MB
~]USD sudo oscap-docker 096cae65a207 xccdf eval --report report.html --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
~]USD firefox report.html &
probe::tcp.setsockopt Name probe::tcp.setsockopt - Call to setsockopt Synopsis tcp.setsockopt Values optstr Resolves optname to a human-readable format name Name of this probe family IP address family level The level at which the socket options will be manipulated optname TCP socket options (e.g. TCP_NODELAY, TCP_MAXSEG, etc) sock Network socket optlen Used to access values for setsockopt Context The process which calls setsockopt

Commands:
17.2. Trouble Beginning the Installation 17.2.1. Problems with Booting into the Graphical Installation There are some video cards that have trouble booting into the graphical installation program. If the installation program does not run using its default settings, it tries to run in a lower resolution mode. If that still fails, the installation program attempts to run in text mode. One possible solution is to try using the resolution= boot option. Refer to Chapter 28, Boot Options for more information. Note To disable frame buffer support and allow the installation program to run in text mode, try using the nofb boot option. This command may be necessary for accessibility with some screen reading hardware.

Commands:
14.10. Re-sizing the Disk Image Change the disk image filename as if it had been created with size size . Only images in raw format can be resized in both directions, whereas qcow2 images can be grown but cannot be shrunk. Use the following to set the size of the disk image filename to size bytes: You can also resize relative to the current size of the disk image. To give a size relative to the current size, prefix the number of bytes with + to grow, or - to reduce the size of the disk image by that number of bytes. Adding a unit suffix allows you to set the image size in kilobytes (K), megabytes (M), gigabytes (G) or terabytes (T). Warning Before using this command to shrink a disk image, you must use file system and partitioning tools inside the VM itself to reduce allocated file systems and partition sizes accordingly. Failure to do so will result in data loss. After using this command to grow a disk image, you must use file system and partitioning tools inside the VM to actually begin using the new space on the device.

Commands:
qemu-img resize filename size
qemu-img resize filename [+|-] size [K|M|G|T]
Install builds for Red Hat OpenShift 1.3 Installing Builds Red Hat OpenShift Documentation Team

Commands:
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-builds-operator namespace: openshift-builds spec: channel: <channel-name> 1 name: openshift-builds-operator 2 source: redhat-operators 3 sourceNamespace: openshift-marketplace 4
oc apply -f sub.yml
oc get openshiftbuilds
oc get shipwrightbuilds
oc get pods -n openshift-builds
oc get pods -n openshift-builds NAME READY STATUS RESTARTS AGE openshift-builds-operator-6f5c48c6b5-cvp2w 2/2 Running 0 13d openshift-pipelines-operator-64d8c4969c-952cc 2/2 Running 0 3d13h shared-resource-csi-driver-node-gbkqs 2/2 Running 0 13d shared-resource-csi-driver-node-kcqxc 2/2 Running 0 13d shared-resource-csi-driver-node-sbsvg 2/2 Running 0 13d shared-resource-csi-driver-webhook-9d9bd48f4-d5ln6 1/1 Running 0 13d shipwright-build-controller-5454475b85-mmm6w 1/1 Running 0 13d shipwright-build-webhook-7fbd49c6bb-2n77s 1/1 Running 0 13d tekton-operator-webhook-756f5dfdc7-c99mc 1/1 Running 0 3d13h
oc patch openshiftbuild cluster --type=merge -p '{"spec":{"shipwright":{"build":{"state":"Disabled"}}}}'
7.198. python-rtslib 7.198.1. RHBA-2013:0466 - python-rtslib bug fix update An updated python-rtslib package that fixes one bug is now available for Red Hat Enterprise Linux 6. The python-rtslib package provides a Python library to configure the kernel target subsystem, using the configfs file system. Bug Fix BZ# 838759 Previously, it was possible to create more than one "fileio" backstore with the same backing file. This behavior could lead to data loss. This update prevents "fileio" backstores from using the same backing store. All users of python-rtslib are advised to upgrade to this updated package, which fixes this bug.

Commands:
2.2.9. Verifying Which Ports Are Listening Unnecessary open ports should be avoided because it increases the attack surface of your system. If after the system has been in service you find unexpected open ports in listening state, that might be signs of intrusion and it should be investigated. Issue the following command, as root, from the console to determine which ports are listening for connections from the network: Review the output of the command with the services needed on the system, turn off what is not specifically required or authorized, repeat the check. Proceed then to make external checks using nmap from another system connected via the network to the first system. This can be used verify the rules in iptables . Make a scan for every IP address shown in the netstat output (except for localhost 127.0.0.0 or ::1 range) from an external system. Use the -6 option for scanning an IPv6 address. See man nmap(1) for more information. The following is an example of the command to be issued from the console of another system to determine which ports are listening for TCP connections from the network: See the netstat (8) , nmap (1) , and services (5) manual pages for more information.

Commands:
~]# netstat -tanp | grep LISTEN tcp 0 0 0.0.0.0:45876 0.0.0.0:* LISTEN 1193/rpc.statd tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1241/dnsmasq tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1783/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 7696/sendmail tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1167/rpcbind tcp 0 0 127.0.0.1:30003 0.0.0.0:* LISTEN 1118/tcsd tcp 0 0 :::631 :::* LISTEN 1/init tcp 0 0 :::35018 :::* LISTEN 1193/rpc.statd tcp 0 0 :::111 :::* LISTEN 1167/rpcbind
~]# nmap -sT -O 192.168.122.1
A.15. Guest Virtual Machine Fails to Shutdown Traditionally, executing a virsh shutdown command causes a power button ACPI event to be sent, thus copying the same action as when someone presses a power button on a physical machine. Within every physical machine, it is up to the OS to handle this event. In the past operating systems would just silently shutdown. Today, the most usual action is to show a dialog asking what should be done. Some operating systems even ignore this event completely, especially when no users are logged in. When such operating systems are installed on a guest virtual machine, running virsh shutdown just does not work (it is either ignored or a dialog is shown on a virtual display). However, if a qemu-guest-agent channel is added to a guest virtual machine and this agent is running inside the guest virtual machine's OS, the virsh shutdown command will ask the agent to shut down the guest OS instead of sending the ACPI event. The agent will call for a shutdown from inside the guest virtual machine OS and everything works as expected. Procedure A.7. Configuring the guest agent channel in a guest virtual machine Stop the guest virtual machine. Open the Domain XML for the guest virtual machine and add the following snippet: <channel type='unix'> <source mode='bind'/> <target type='virtio' name='org.qemu.guest_agent.0'/> </channel> Figure A.2. Configuring the guest agent channel Start the guest virtual machine, by running virsh start [domain] . Install qemu-guest-agent on the guest virtual machine ( yum install qemu-guest-agent ) and make it run automatically at every boot as a service (qemu-guest-agent.service).

Commands:
<channel type='unix'> <source mode='bind'/> <target type='virtio' name='org.qemu.guest_agent.0'/> </channel>
Chapter 4. Advisories related to this release The following advisories have been issued to bugfixes and CVE fixes included in this release. RHEA-2021:2761-04 RHEA-2021:2762-03 RHEA-2021:2753-02 RHSA-2021:2784-02 RHSA-2021:2783-02 RHSA-2021:2782-02 RHSA-2021:2781-02 RHSA-2021:2780-01 RHSA-2021:2779-01 Revised on 2024-05-09 16:46:34 UTC

Commands:
Chapter 4. Adding user preferences You can change the default preferences for your profile to meet your requirements. You can set your default project, topology view (graph or list), editing medium (form or YAML), language preferences, and resource type. The changes made to the user preferences are automatically saved. 4.1. Setting user preferences You can set the default user preferences for your cluster. Procedure Log in to the Red Hat OpenShift Service on AWS web console using your login credentials. Use the masthead to access the user preferences under the user profile. In the General section: In the Theme field, you can set the theme that you want to work in. The console defaults to the selected theme each time you log in. In the Perspective field, you can set the default perspective you want to be logged in to. You can select the Administrator or the Developer perspective as required. If a perspective is not selected, you are logged into the perspective you last visited. In the Project field, select a project you want to work in. The console defaults to the project every time you log in. In the Topology field, you can set the topology view to default to the graph or list view. If not selected, the console defaults to the last view you used. In the Create/Edit resource method field, you can set a preference for creating or editing a resource. If both the form and YAML options are available, the console defaults to your selection. In the Language section, select Default browser language to use the default browser language settings. Otherwise, select the language that you want to use for the console. In the Notifications section, you can toggle display notifications created by users for specific projects on the Overview page or notification drawer. In the Applications section: You can view the default Resource type . The default resource type is Deployment . You can select another resource type to be the default resource type from the Resource Type field.

Commands:
Chapter 3. Enabling Linux control group version 1 (cgroup v1) As of OpenShift Container Platform 4.14, OpenShift Container Platform uses Linux control group version 2 (cgroup v2) in your cluster. If you are using cgroup v1 on OpenShift Container Platform 4.13 or earlier, migrating to OpenShift Container Platform 4.15 will not automatically update your cgroup configuration to version 2. A fresh installation of OpenShift Container Platform 4.14 or later will use cgroup v2 by default. However, you can enable Linux control group version 1 (cgroup v1) upon installation. Enabling cgroup v1 in OpenShift Container Platform disables all cgroup v2 controllers and hierarchies in your cluster. cgroup v2 is the current version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as Pressure Stall Information , and enhanced resource management and isolation. However, cgroup v2 has different CPU, memory, and I/O management characteristics than cgroup v1. Therefore, some workloads might experience slight differences in memory or CPU usage on clusters that run cgroup v2. You can switch between cgroup v1 and cgroup v2, as needed, by editing the node.config object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section. 3.1. Enabling Linux cgroup v1 during installation You can enable Linux control group version 1 (cgroup v1) when you install a cluster by creating installation manifests. Procedure Create or edit the node.config object to specify the v1 cgroup: apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2" Proceed with the installation as usual. Additional resources OpenShift Container Platform installation overview Configuring the Linux cgroup on your nodes

Commands:
apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2"
1.3. Supported Methods to Configure Directory Server You can configure Directory Server using: the command-line utilities provided by Directory Server the web console Important The web console does not automatically display the latest settings if a user changes the configuration outside of the console's window. For example, if you change the configuration using the command line while the web console is open, the new settings are not automatically updated in the web console. This applies also if you change the configuration using the web console on a different computer. To work around the problem, manually refresh the web console in the browser if the configuration has been changed outside the console's window.

Commands:
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Tell us how we can make it better. Using the Direct Documentation Feedback (DDF) function Use the Add Feedback DDF function for direct comments on specific sentences, paragraphs, or code blocks. View the documentation in the HTML format. Ensure that you see the Feedback button in the upper right corner of the document. Highlight the part of text that you want to comment on. Click Add Feedback . Complete the Add Feedback field with your comments. Optional: Add your email address so that the documentation team can contact you for clarification on your issue. Click Submit .

Commands:
24.2. XML Representation of a Tag Resource Example 24.1. An XML representation of a tag resource

Commands:
<tag id="f436ebfc-67f2-41bd-8ec6-902b6f7dcb5e" href="/ovirt-engine/api/tags/f436ebfc-67f2-41bd-8ec6-902b6f7dcb5e"> <name>Finance</name> <description>Resources for the Finance department</description> <parent> <tag id="-1" href="/ovirt-engine/api/tags/-1"/> </parent> </tag>
Chapter 1. Introduction SystemTap is a tracing and probing tool that allows users to study and monitor the activities of the operating system (particularly, the kernel) in fine detail. It provides information similar to the output of tools like netstat , ps , top , and iostat ; however, SystemTap is designed to provide more filtering and analysis options for collected information. 1.1. Documentation Goals SystemTap provides the infrastructure to monitor the running Linux system for detailed analysis. This can assist administrators and developers in identifying the underlying cause of a bug or performance problem. Without SystemTap, monitoring the activity of a running kernel would require a tedious instrument, recompile, install, and reboot sequence. SystemTap is designed to eliminate this, allowing users to gather the same information by simply running user-written SystemTap scripts. However, SystemTap was initially designed for users with intermediate to advanced knowledge of the kernel. This makes SystemTap less useful to administrators or developers with limited knowledge of and experience with the Linux kernel. Moreover, much of the existing SystemTap documentation is similarly aimed at knowledgeable and experienced users. This makes learning the tool similarly difficult. To lower these barriers the SystemTap Beginners Guide was written with the following goals: To introduce users to SystemTap, familiarize them with its architecture, and provide setup instructions for all kernel types. To provide pre-written SystemTap scripts for monitoring detailed activity in different components of the system, along with instructions on how to run them and analyze their output.

Commands:
Chapter 53. module This chapter describes the commands under the module command. 53.1. module list List module versions Usage: Table 53.1. Command arguments Value Summary -h, --help Show this help message and exit --all Show all modules that have version information Table 53.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 53.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 53.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 53.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack module list [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--all]
21.12. Workaround for Creating External Snapshots with libvirt There are two classes of snapshots for QEMU guests. Internal snapshots are contained completely within a qcow2 file, and fully supported by libvirt , allowing for creating, deleting, and reverting of snapshots. This is the default setting used by libvirt when creating a snapshot, especially when no option is specified. Although this file type takes a bit longer than others in creating the snapshot, it is required by libvirt to use qcow2 disks. Another drawback to this file type is that qcow2 disks are not subject to receive improvements from QEMU. External snapshots, on the other hand work with any type of original disk image, can be taken with no guest downtime, and are able to receive active improvements from QEMU. In libvirt , they are created when using the --disk-only option to snapshot-create-as (or when specifying an explicit XML file to snapshot-create that does the same). At the moment external snapshots are a one-way operation as libvirt can create them but cannot do anything further with them.

Commands: