mtpti5iD/redhat-docs_dataset huggingface dataset:
Installing with an RPM package Red Hat build of MicroShift 4.18 Installing MicroShift with RPMs Red Hat OpenShift Documentation Team

Commands:
sudo vgs
VG #PV #LV #SN Attr VSize VFree rhel 1 2 0 wz--n- <127.00g 54.94g
sudo subscription-manager repos --enable rhocp-4.18-for-rhel-9-USD(uname -m)-rpms --enable fast-datapath-for-rhel-9-USD(uname -m)-rpms
sudo subscription-manager repos --enable rhel-9-for-USD(uname -m)-appstream-eus-rpms --enable rhel-9-for-USD(uname -m)-baseos-eus-rpms
sudo subscription-manager release --set=9.4
sudo dnf install -y microshift
sudo cp USDHOME/openshift-pull-secret /etc/crio/openshift-pull-secret
sudo chown root:root /etc/crio/openshift-pull-secret
sudo chmod 600 /etc/crio/openshift-pull-secret
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1
sudo firewall-cmd --reload
sudo systemctl start microshift
sudo systemctl enable microshift
sudo systemctl disable microshift
sudo systemctl stop microshift
sudo crictl ps -a
sudo systemctl stop kubepods.slice
mkdir -p ~/.kube/
sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
chmod go-r ~/.kube/config
oc get all -A
[user@microshift]USD sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
[user@microshift]USD oc get all -A
[user@workstation]USD mkdir -p ~/.kube/
[user@workstation]USD MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
[user@workstation]USD ssh <user>@USDMICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/USDMICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
chmod go-r ~/.kube/config
[user@workstation]USD oc get all -A
14.8.2. Suspending a Guest Virtual Machine Suspend a guest virtual machine with virsh : When a guest virtual machine is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest virtual machine is suspended. This operation is immediate and the guest virtual machine can be restarted with the resume ( Section 14.8.6, "Resuming a Guest Virtual Machine" ) option.

Commands:
virsh suspend {domain-id, domain-name or domain-uuid}
Appendix F. Additional Replication High Availability Configuration Elements The following table lists additional ha-policy configuration elements that are not described in the Configuring replication high availability section. These elements have default settings that are sufficient for most common use cases. Table F.1. Additional Configuration Elements Available when Using Replication High Availability Name Used in Description check-for-live-server Embedded broker coordination Applies only to brokers configured as master brokers. Specifies whether the original master broker checks the cluster for another live broker using its own server ID when starting up. Set to true to fail back to the original master broker and avoid a "split brain" situation in which two brokers become live at the same time. The default value of this property is false . cluster-name Embedded broker and ZooKeeper coordination Name of the cluster configuration to use for replication. This setting is only necessary if you configure multiple cluster connections. If configured, the cluster configuration with this name will be used when connecting to the cluster. If unset, the first cluster connection defined in the configuration is used. initial-replication-sync-timeout Embedded broker and ZooKeeper coordination The amount of time the replicating broker will wait upon completion of the initial replication process for the replica to acknowledge that it has received all the necessary data. The default value of this property is 30,000 milliseconds. NOTE: During this interval, any other journal-related operations are blocked. max-saved-replicated-journals-size Embedded broker and ZooKeeper coordination Applies to backup brokers only. Specifies how many backup journal files the backup broker retains. Once this value has been reached, the broker makes space for each new backup journal file by deleting the oldest journal file. The default value of this property is 2 .

Commands:
19.3.4. Mail Transport Agent (MTA) Configuration A Mail Transport Agent (MTA) is essential for sending email. A Mail User Agent (MUA) such as Evolution , Thunderbird , or Mutt , is used to read and compose email. When a user sends an email from an MUA, the message is handed off to the MTA, which sends the message through a series of MTAs until it reaches its destination. Even if a user does not plan to send email from the system, some automated tasks or system programs might use the /bin/mail command to send email containing log messages to the root user of the local system. Red Hat Enterprise Linux 6 provides two MTAs: Postfix and Sendmail. If both are installed, Postfix is the default MTA.

Commands:
Chapter 11. Reviewing monitoring dashboards OpenShift Container Platform 4.12 provides a comprehensive set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads. Use the Administrator perspective to access dashboards for the core OpenShift Container Platform components, including the following items: API performance etcd Kubernetes compute resources Kubernetes network resources Prometheus USE method dashboards relating to cluster and node performance Figure 11.1. Example dashboard in the Administrator perspective Use the Developer perspective to access Kubernetes compute resources dashboards that provide the following application metrics for a selected project: CPU usage Memory usage Bandwidth information Packet rate information Figure 11.2. Example dashboard in the Developer perspective Note In the Developer perspective, you can view dashboards for only one project at a time. 11.1. Reviewing monitoring dashboards as a cluster administrator In the Administrator perspective, you can view dashboards relating to core OpenShift Container Platform cluster components. Prerequisites You have access to the cluster as a user with the cluster-admin cluster role. Procedure In the Administrator perspective in the OpenShift Container Platform web console, navigate 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 selecting 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. 11.2. Reviewing monitoring dashboards as a developer Use the Developer perspective to view Kubernetes compute resources dashboards of a selected project. 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 Container Platform web console, navigate to Observe Dashboard . 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 selecting 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. Additional resources Monitoring project and application metrics using the Developer perspective

Commands:
33.6. Authentication Figure 33.9. Authentication In the Authentication section, select whether to use shadow passwords and MD5 encryption for user passwords. These options are highly recommended and chosen by default. The Authentication Configuration options allow you to configure the following methods of authentication: NIS LDAP Kerberos 5 Hesiod SMB Name Switch Cache These methods are not enabled by default. To enable one or more of these methods, click the appropriate tab, click the checkbox to Enable , and enter the appropriate information for the authentication method. Refer to the Red Hat Enterprise Linux Deployment Guide for more information about the options.

Commands:
Chapter 7. Annobin The Annobin project consists of the annobin plugin and the annockeck program. The annobin plugin scans the GNU Compiler Collection (GCC) command line, the compilation state, and the compilation process, and generates the ELF notes. The ELF notes record how the binary was built and provide information for the annocheck program to perform security hardening checks. The security hardening checker is part of the annocheck program and is enabled by default. It checks the binary files to determine whether the program was built with necessary security hardening options and compiled correctly. annocheck is able to recursively scan directories, archives, and RPM packages for ELF object files. Note The files must be in ELF format. annocheck does not handle any other binary file types. 7.1. Installing Annobin In Red Hat Developer Toolset, the annobin plugin and the annockeck program are provided by the devtoolset-12-gcc package and are installed as described in Section 1.5.3, "Installing Optional Packages" . 7.2. Using Annobin Plugin To pass options to the annobin plugin with gcc , use: Note that you can execute any command using the scl utility, causing it to be run with the Red Hat Developer Toolset binaries used in preference to the Red Hat Enterprise Linux system equivalent. This allows you to run a shell session with Red Hat Developer Toolset as as default: 7.3. Using Annocheck To scan files, directories or RPM packages with the annocheck program: Note annocheck only looks for the ELF files. Other file types are ignored. Note that you can execute any command using the scl utility, causing it to be run with the Red Hat Developer Toolset binaries used in preference to the Red Hat Enterprise Linux system equivalent. This allows you to run a shell session with Red Hat Developer Toolset as as default: Note To verify the version of annocheck you are using at any point: Red Hat Developer Toolset's annocheck executable path will begin with /opt . Alternatively, you can use the following command to confirm that the version number matches that for Red Hat Developer Toolset annocheck : 7.4. Additional Resources For more information about annocheck , annobin and its features, see the resources listed below. Installed Documentation annocheck (1) - The manual page for the annocheck utility provides detailed information on its usage. To display the manual page for the version included in Red Hat Developer Toolset: annobin (1) - The manual page for the annobin utility provides detailed information on its usage. To display the manual page for the version included in Red Hat Developer Toolset:

Commands:
scl enable devtoolset-12 'gcc -fplugin=annobin -fplugin-arg-annobin- option file-name '
scl enable devtoolset-12 'bash'
scl enable devtoolset-12 'annocheck file-name '
scl enable devtoolset-12 'bash'
which annocheck
annocheck --version
scl enable devtoolset-12 'man annocheck'
scl enable devtoolset-12 'man annobin'
Chapter 3. Adding ActiveDocs to 3scale 3scale offers a framework to create interactive documentation for your API. With OpenAPI Specification (OAS) , you have functional documentation for your API, which will help your developers explore, test, and integrate with your API. 3.1. Setting up ActiveDocs in 3scale You can add ActiveDocs to your API in the 3scale user interface to obtain a framework for creating interactive documentation for your API. Prerequisites An OpenAPI document that defines your API. A 3scale 2.15 instance tenant's credentials ( token or provider_key ). Procedure Navigate to [your_API_name] ActiveDocs in your Admin Portal. 3scale displays the list of your service specifications for your API. This is initially empty. You can add as many service specifications as you want. Typically, each service specification corresponds to one of your APIs. For example, 3scale has specifications for each 3scale API , such as Service Management, Account Management, Analytics, and Billing. Click Create a new spec . When you add a new service specification, provide the following: Name System name This is required to reference the service specification from the Developer Portal. Choose whether you want the specification to be published or not. If you do not publish, the new specification will not be available in the Developer Portal. Note If you create, but do not publish your new specification, it will remain available to you for publication at a later time of your choosing. Add a description that is meant for only your consumption. Add the API JSON specification. Generate the specification of your API according to the specification proposed by OpenAPI Specification (OAS) . In this tutorial we assume that you already have a valid OAS-compliant specification of your API. Working with your first ActiveDoc After you add your first ActiveDoc, you can see it listed in [your_API_name] ActiveDocs . You can edit it as necessary, delete it, or switch it from public to private. You can detach it from your API or attach it to any other API. You can see all your ActiveDocs, whether or not they are attached to an API in Audience Developer Portal ActiveDocs . You can preview what your ActiveDocs looks like by clicking the name you gave the service specification, for example, Pet Store. You can do this even if the specification is not published yet. This is what an ActiveDoc looks like:

Commands:
7.57. fence-virt 7.57.1. RHBA-2013:0419 - fence-virt bug fix and enhancement update Updated fence-virt packages that fix two bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The fence-virt packages provide a fencing agent for virtual machines as well as a host agent, which processes fencing requests. Bug Fixes BZ# 761228 Previously, the fence_virt man page contained incorrect information in the "SERIAL/VMCHANNEL PARAMETERS" section. With this update, the man page has been corrected. BZ# 853927 Previously, the fence_virtd daemon returned an incorrect error code to the fence_virt agent when the virt domain did not exist. Consequently, the fence_node utility occasionally failed to detect fencing. With this update, the error codes have been changed and the described error no longer occurs. Enhancements BZ# 823542 The "delay" (-w) option has been added to the fence_virt and fence_xvm fencing agents. The delay option can be used, for example, as a method of preloading a winner in a fence race in a CMAN cluster. BZ# 843104 With this update, the documentation of the "hash" parameter in the fence_virt.conf file has been improved to notify that hash is the weakest hashing algorithm allowed for client requests. All users of fence-virt are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
2.3. Migration Migration describes the process of moving a guest virtual machine from one host to another. This is possible because the virtual machines are running in a virtualized environment instead of directly on the hardware. There are two ways to migrate a virtual machine: live and offline. Migration Types Offline migration An offline migration suspends the guest virtual machine, and then moves an image of the virtual machine's memory to the destination host. The virtual machine is then resumed on the destination host and the memory used by the virtual machine on the source host is freed. Live migration Live migration is the process of migrating an active virtual machine from one physical host to another. Note that this is not possible between all Red Hat Enterprise Linux releases. Consult the Virtualization Administration Guide for details. 2.3.1. Benefits of Migrating Virtual Machines Migration is useful for: Load balancing When a host machine is overloaded, one or more of its virtual machines could be migrated to other hosts using live migration. Similarly, machines that are not running and tend to overload can be migrated using offline migration. Upgrading or making changes to the host When the need arises to upgrade, add, or remove hardware devices on a host, virtual machines can be safely relocated to other hosts. This means that guests do not experience any downtime due to changes that are made to hosts. Energy saving Virtual machines can be redistributed to other hosts and the unloaded host systems can be powered off to save energy and cut costs in low usage periods. Geographic migration Virtual machines can be moved to other physical locations for lower latency or for other reasons. When the migration process moves a virtual machine's memory, from Red Hat Enterprise Linux 6.3, the disk volume associated with the virtual machine is also migrated. This process is performed using live block migration. Shared, networked storage can be used to store guest images to be migrated. When migrating virtual machines, it is recommended to use libvirt -managed storage pools for shared storage. Note For more information on migration, refer to the Red Hat Enterprise Linux 6 Virtualization Administration Guide .

Commands:
7.236. spice-xpi 7.236.1. RHBA-2013:0459 - spice-xpi bug fix update Updated spice-xpi packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The spice-xpi packages provide the Simple Protocol for Independent Computing Environments (SPICE) extension for Mozilla that allows the SPICE client to be used from a web browser. Bug Fixes BZ# 805602 Previously, spice-xpi did not check port validity. Consequently, if an invalid port number was provided, spice-xpi sent it to the client. With this update, spice-xpi checks validity of provided port numbers, warns about invalid ports, and does not run the client if both ports are invalid. BZ# 810583 Previously, the disconnect() function failed to terminate a SPICE client when invoked. The underlying source code has been modified and disconnect() now works as expected in the described scenario. All users of spice-xpi are advised to upgrade to these updated packages, which fix these bugs.

Commands:
10.5.5. KeepAlive KeepAlive sets whether the server allows more than one request per connection and can be used to prevent any one client from consuming too much of the server's resources. By default Keepalive is set to off . If Keepalive is set to on and the server becomes very busy, the server can quickly spawn the maximum number of child processes. In this situation, the server slows down significantly. If Keepalive is enabled, it is a good idea to set the the KeepAliveTimeout low (refer to Section 10.5.7, " KeepAliveTimeout " for more information about the KeepAliveTimeout directive) and monitor the /var/log/httpd/error_log log file on the server. This log reports when the server is running out of child processes.

Commands:
Chapter 5. Kernel parameters Parameter Description BridgeNfCallArpTables Configures sysctl net.bridge.bridge-nf-call-arptables key. The default value is 1 . BridgeNfCallIp6Tables Configures sysctl net.bridge.bridge-nf-call-ip6tables key. The default value is 1 . BridgeNfCallIpTables Configures sysctl net.bridge.bridge-nf-call-iptables key. The default value is 1 . ExtraKernelModules Hash of extra kernel modules to load. ExtraKernelPackages List of extra kernel related packages to install. ExtraSysctlSettings Hash of extra sysctl settings to apply. InotifyIntancesMax Configures sysctl fs.inotify.max_user_instances key. The default value is 1024 . KernelDisableIPv6 Configures sysctl net.ipv6.{default/all}.disable_ipv6 keys. The default value is 0 . KernelIpForward Configures net.ipv4.ip_forward key. The default value is 1 . KernelIpNonLocalBind Configures net.ipv{4,6}.ip_nonlocal_bind key. The default value is 1 . KernelPidMax Configures sysctl kernel.pid_max key. The default value is 1048576 . NeighbourGcThreshold1 Configures sysctl net.ipv4.neigh.default.gc_thresh1 value. This is the minimum number of entries to keep in the ARP cache. The garbage collector will not run if there are fewer than this number of entries in the cache. The default value is 1024 . NeighbourGcThreshold2 Configures sysctl net.ipv4.neigh.default.gc_thresh2 value. This is the soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed. The default value is 2048 . NeighbourGcThreshold3 Configures sysctl net.ipv4.neigh.default.gc_thresh3 value. This is the hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. The default value is 4096 .

Commands:
Chapter 1. Managing Bricks 1.1. Creating a brick using the Administration Portal This process creates a new thinly provisioned logical volume on a specified storage device, for use as a brick in a Gluster volume. Log in to the Administration Portal. Click Compute Hosts and select the host for the brick. Click Storage Devices . If no storage devices are visible, try synchronizing the volume: Section 2.9, "Synchronizing volume state using the Administration Portal" . Select a storage device and click Create Brick . The Create Brick window appears. Specify the Brick Name . Specify the Mount Point for the brick. (Optional) To create a RAID array, specify the following: No. of physical disks in the RAID array RAID Type (Optional) To assign a logical volume cache for this brick, specify a Device under Cache Device . This is recommended when your main storage device is not a solid state disk. Click OK . 1.2. Resetting a brick using the Administration Portal Resetting a brick lets you reconfigure a brick as though you are adding it to the cluster for the first time, using the same UUID, hostname, and path. See the Red Hat Gluster Storage Administration Guide for more information. Log in to the Administration Portal. Click Storage Volumes . Click the name of the volume that runs on the brick you want to reset. Click Bricks . Click Reset Brick . The Reset Brick window opens. Click OK to confirm the operation. 1.3. Replacing a brick using the Administration Portal Log in to the Administration Portal. Click Storage Volumes . Click the name of the volume that runs on the brick you want to reset. Click Bricks . Click Replace Brick . The Replace Brick window opens. Select the Host of the replacement brick. Select the Brick Directory of the replacement brick. Click OK . 1.4. Deleting a brick using the Administration Portal Log in to the Administration Portal. Click Storage Volumes . Select the volume you want to delete. Click Stop and confirm that the volume should be stopped. Click Bricks . Select the brick to remove. Click Remove and confirm that the brick should be removed.

Commands: