mtpti5iD/redhat-docs_dataset huggingface dataset:
3.2. Autotools GNU Autotools is a suite of command line tools that allow developers to build applications on different systems, regardless of the installed packages or even Linux distribution. These tools aid developers in creating a configure script. This script runs prior to builds and creates the top-level Makefile s required to build the application. The configure script may perform tests on the current system, create additional files, or run other directives as per parameters provided by the builder. The Autotools suite's most commonly-used tools are: autoconf Generates the configure script from an input file ( configure.ac , for example) automake Creates the Makefile for a project on a specific system autoscan Generates a preliminary input file (that is, configure.scan ), which can be edited to create a final configure.ac to be used by autoconf All tools in the Autotools suite are part of the Development Tools group package. You can install this package group to install the entire Autotools suite, or use yum to install any tools in the suite as you wish. 3.2.1. Autotools Plug-in for Eclipse The Autotools suite is also integrated into the Eclipse IDE via the Autotools plug-in. This plug-in provides an Eclipse graphical user interface for Autotools, which is suitable for most C/C++ projects. As of Red Hat Enterprise Linux 6, this plug-in only supports two templates for new C/C++ projects: An empty project A "hello world" application The empty project template is used when importing projects into the C/C++ Development Toolkit that already support Autotools. Future updates to the Autotools plug-in will include additional graphical user interfaces (wizards, for example) for creating shared libraries and other complex scenarios. The Red Hat Enterprise Linux 6 version of the Autotools plug-in also does not integrate git or mercurial into Eclipse. As such, Autotools projects that use git repositories will be required to be checked out outside the Eclipse workspace. Afterwards, you can specify the source location for such projects in Eclipse. Any repository manipulation (commits, or updates for example) are done via the command line.

Commands:
18.7. IPTables and Connection Tracking You can inspect and restrict connections to services based on their connection state. A module within iptables uses a method called connection tracking to store information about incoming connections. You can allow or deny access based on the following connection states: NEW - A packet requesting a new connection, such as an HTTP request. ESTABLISHED - A packet that is part of an existing connection. RELATED - A packet that is requesting a new connection but is part of an existing connection. For example, FTP uses port 21 to establish a connection, but data is transferred on a different port (typically port 20). INVALID - A packet that is not part of any connections in the connection tracking table. You can use the stateful functionality of iptables connection tracking with any network protocol, even if the protocol itself is stateless (such as UDP). The following example shows a rule that uses connection tracking to forward only the packets that are associated with an established connection:

Commands:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Chapter 3. Internal storage services Red Hat OpenShift Data Foundation service is available for consumption internally to the Red Hat OpenShift Container Platform that runs on the following infrastructure: Amazon Web Services (AWS) Bare metal VMware vSphere Microsoft Azure Google Cloud Red Hat OpenStack 13 or higher (installer-provisioned infrastructure) [Technology Preview] IBM Power IBM Z and IBM(R) LinuxONE Creation of an internal cluster resource results in the internal provisioning of the OpenShift Data Foundation base services, and makes additional storage classes available to the applications.

Commands:
9.7. Storing User Settings Over NFS For dconf to work correctly when using Network File System ( NFS ) home directories, the dconf keyfile back end must be used. Note that the glib2-fam package must be installed on the system when using the dconf keyfile back end . Otherwise notifications on configuration changes made on remote machines will not work properly. Procedure 9.1. Setting the dconf Keyfile Back End Verify that the glib2-fam package is installed on the system. The system must be subscribed to the Optional channel. To learn how to subscribe the system to the Optional channel, read this resource: How to access Optional and Supplementary channels, and -devel packages using Red Hat Subscription Management (RHSM)? Install the glib2-fam package by running the following command: Create or edit the /etc/dconf/profile/user file on every client. At the very beginning of this file, add the following line: The dconf keyfile back end will only take effect the time that the user logs in. It polls the keyfile to determine whether updates have been made, so settings may not be updated immediately.

Commands:
yum install glib2-fam
service-db:keyfile/user
Chapter 21. Identifying virtual devices with tags 21.1. Tagging virtual devices In Red Hat OpenStack Platform, if you launch a VM instance with multiple network interfaces or block devices, you can use device tagging to communicate the intended role of each device to the instance operating system. Tags are assigned to devices at instance boot time, and are available to the instance operating system through the metadata API and the configuration drive (if enabled). Procedure To tag virtual devices, use the tag parameters, --block-device and --nic , when creating instances. Example The resulting tags are added to the existing instance metadata and are available through both the metadata API, and on the configuration drive. In this example, the following devices section populates the metadata: Sample contents of the meta_data.json file: The device tag metadata is available using GET /openstack/latest/meta_data.json from the metadata API. If the configuration drive is enabled, and mounted under /configdrive in the instance operating system, the metadata is also present in /configdrive/openstack/latest/meta_data.json .

Commands:
nova boot test-vm --flavor m1.tiny --image cirros --nic net-id=55411ca3-83dd-4036-9158-bf4a6b8fb5ce,tag=nfv1 --block-device id=b8c9bef7-aa1d-4bf4-a14d-17674b370e13,bus=virtio,tag=database-server NFVappServer
{ "devices": [ { "type": "nic", "bus": "pci", "address": "0030:00:02.0", "mac": "aa:00:00:00:01", "tags": ["nfv1"] }, { "type": "disk", "bus": "pci", "address": "0030:00:07.0", "serial": "disk-vol-227", "tags": ["database-server"] } ] }
14.7.8. Creating Devices on Host Nodes The virsh nodedev-create file command allows you to create a device on a host node and then assign it to a guest virtual machine. libvirt normally detects which host nodes are available for use automatically, but this command allows for the registration of host hardware that libvirt did not detect. The file should contain the XML for the top level <device> description of the node device. To stop this device, use the nodedev-destroy device command.

Commands:
Chapter 1. Red Hat Enterprise Linux 6.8 International Languages Red Hat Enterprise Linux 6.8 supports installation of multiple languages and changing of languages based on your requirements. The following languages are supported in Red Hat Enterprise Linux 6.8: East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese European Languages - English, German, Spanish, French, Portuguese Brazilian, and Russian, The table below summarizes the currently supported languages, their locales, default fonts installed and packages required for some of the supported languages Table 1.1. Red Hat Enterprise Linux 6 International Languages Territory Language Locale Fonts Package Names China Simplified Chinese zh_CN.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-pinyin, scim-tables Japan Japanese ja_JP.UTF-8 Sazanami (Gothic and Mincho) fonts-japanese, scim-anthy Korea Hangul ko_KR.UTF-8 Baekmuk (Batang, Dotum, Gulim, Headline) fonts-korean, scim-hangul Taiwan Traditional Chinese zh_TW.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-chewing, scim-tables Brazil Portuguese pt_BR.UTF-8 standard latin fonts France French ft_FR.UTF-8 standard latin fonts Germany German de_DE.UTF-8 standard latin fonts Italy Italy it_IT.UTF-8 standard latin fonts Russia Russian ru_RU.UTF-8 Cyrillic dejavu-lgc-sans-fonts, dejavu-lgc-sans-mono-fonts, dejavu-lgc-serif-fonts, xorg-x11-fonts-cyrillic Spain Spanish es_ES.UTF-8 standard latin fonts

Commands:
probe::socket.writev.return Name probe::socket.writev.return - Conclusion of message sent via socket_writev Synopsis Values success Was send successful? (1 = yes, 0 = no) protocol Protocol value flags Socket flags value name Name of this probe state Socket state value size Size of message sent (in bytes) or error code if success = 0 type Socket type value family Protocol family value Context The message receiver. Description Fires at the conclusion of sending a message on a socket via the sock_writev function

Commands:
socket.writev.return
Chapter 1. Introduction This document provides a workflow to help keep your Red Hat OpenStack Platform 16.0 environment updated with the latest packages and containers. This guide provides an upgrade path through the following versions: Old Overcloud Version New Overcloud Version Red Hat OpenStack Platform 16.0 Red Hat OpenStack Platform 16.0.z 1.1. High level workflow The following table provides an outline of the steps required for the upgrade process: Step Description Updating the undercloud Update the undercloud to the latest OpenStack Platform 16.0.z version. Updating the overcloud Update the overcloud to the latest OpenStack Platform 16.0.z version. Updating the Ceph Storage nodes Upgrade all Ceph Storage services. Finalize the upgrade Run the convergence command to refresh your overcloud stack.

Commands:
Chapter 4. Deprecated functionality This section provides an overview of functionality that has been deprecated in all minor releases up to this release of Red Hat Ceph Storage. Important Deprecated functionality continues to be supported until the end of life of Red Hat Ceph Storage 5. Deprecated functionality will likely not be supported in future major releases of this product and is not recommended for new deployments. For the most recent list of deprecated functionality within a particular major release, refer to the latest version of release documentation. NFS support for CephFS is now deprecated NFS support for CephFS is now deprecated in favor of upcoming NFS availability in OpenShift Data Foundation. Red Hat Ceph Storage support for NFS in OpenStack Manila is not affected. Deprecated functionality will receive only bug fixes for the lifetime of the current release, and may be removed in future releases. Relevant documentation around this technology is identified as "Limited Availability". iSCSi support is now deprecated iSCSi support is now deprecated in favor of future NVMEoF support. Deprecated functionality will receive only bug fixes for the lifetime of the current release, and may be removed in future releases. Relevant documentation around this technology is identified as "Limited Availability". Ceph configuration file is now deprecated The Ceph configuration file ( ceph.conf ) is now deprecated in favor of new centralized configuration stored in Ceph Monitors. For details, see the The Ceph configuration database section in the Red Hat Ceph Storage Configuration Guide . The min_compat_client parameter for Ceph File System (CephFS) is now deprecated The min_compat_client parameter is deprecated for Red Hat Ceph Storage 5.0 and new client features are added for setting-up the Ceph File Systems (CephFS). For details, see the Client features section in the Red Hat Ceph Storage File System Guide . The snapshot of Ceph File System subvolume group is now deprecated The snapshot feature of Ceph File System (CephFS) subvolume group is deprecated for Red Hat Ceph Storage 5.0. The existing snapshots can be listed and deleted, whenever needed. For details, see the Listing snapshots of a file system subvolume group and Removing snapshots of a file system subvolume group sections in the Red Hat Ceph Storage Ceph File System guide . The Cockpit Ceph Installer is now deprecated Installing a Red Hat Ceph Storage cluster 5 using Cockpit Ceph Installer is not supported. Use Cephadm to install a Red Hat Ceph Storage cluster. For details, see the Red Hat Ceph Storage Installation guide .

Commands:
Part I. Deploying Red Hat Insights with Red Hat Cloud Access The following guidance is for users who want to enable Red Hat Insights for Red Hat Enterprise Linux on an existing Red Hat Enterprise Linux (RHEL) system connected to Red Hat Cloud Access. This procedure involves the following tasks: Installing the Insights client on the system Note Starting with Red Hat Enterprise Linux 8 (RHEL8), RHEL ships with Insights for Red Hat Enterprise Linux preinstalled, so the Insights client installation procedure is not required on systems running RHEL8 or later. All RHEL systems, no matter which version, must be registered with the Red Hat Insights service. Registering the system to the Red Hat Insights for Red Hat Enterprise Linux application.

Commands:
Chapter 9. Keeping kernel panic parameters disabled in virtualized environments When configuring a Virtual Machine in RHEL 9, do not enable the softlockup_panic and nmi_watchdog kernel parameters, because the Virtual Machine might suffer from a spurious soft lockup. And that should not require a kernel panic. Find the reasons behind this advice in the following sections. 9.1. What is a soft lockup A soft lockup is a situation usually caused by a bug, when a task is executing in kernel space on a CPU without rescheduling. The task also does not allow any other task to execute on that particular CPU. As a result, a warning is displayed to a user through the system console. This problem is also referred to as the soft lockup firing. Additional resources What is a CPU soft lockup? 9.2. Parameters controlling kernel panic The following kernel parameters can be set to control a system's behavior when a soft lockup is detected. softlockup_panic Controls whether or not the kernel will panic when a soft lockup is detected. Type Value Effect Integer 0 kernel does not panic on soft lockup Integer 1 kernel panics on soft lockup By default, on RHEL 8, this value is 0. The system needs to detect a hard lockup first to be able to panic. The detection is controlled by the nmi_watchdog parameter. nmi_watchdog Controls whether lockup detection mechanisms ( watchdogs ) are active or not. This parameter is of integer type. Value Effect 0 disables lockup detector 1 enables lockup detector The hard lockup detector monitors each CPU for its ability to respond to interrupts. watchdog_thresh Controls frequency of watchdog hrtimer , NMI events, and soft or hard lockup thresholds. Default threshold Soft lockup threshold 10 seconds 2 * watchdog_thresh Setting this parameter to zero disables lockup detection altogether. Additional resources Softlockup detector and hardlockup detector Kernel sysctl 9.3. Spurious soft lockups in virtualized environments The soft lockup firing on physical hosts usually represents a kernel or a hardware bug. The same phenomenon happening on guest operating systems in virtualized environments might represent a false warning. Heavy workload on a host or high contention over some specific resource, such as memory, can cause a spurious soft lockup firing because the host might schedule out the guest CPU for a period longer than 20 seconds. When the guest CPU is again scheduled to run on the host, it experiences a time jump that triggers the due timers. The timers also include the hrtimer watchdog that can report a soft lockup on the guest CPU. Soft lockup in a virtualized environment can be false. You must not enable the kernel parameters that trigger a system panic when a soft lockup reports to a guest CPU. Important To understand soft lockups in guests, it is essential to know that the host schedules the guest as a task, and the guest then schedules its own tasks. Additional resources Virtual machine components and their interaction

Commands:
19.3. Disk Options This section provides information about disk options. Generic Drive -drive <option>[,<option>[,<option>[,...]]] Supported with the following options: readonly [on|off] werror [enospc|report|stop|ignore] rerror [report|stop|ignore] id =<id> Id of the drive has the following limitation for if=none: IDE disk has to have <id> in following format: drive-ide0-<BUS>-<UNIT> Example of correct format: -drive if=none,id=drive-ide0-<BUS>-<UNIT>,... -device ide-drive,drive=drive-ide0-<BUS>-<UNIT>,bus=ide.<BUS>,unit=<UNIT> file =<file> Value of <file> is parsed with the following rules: Passing floppy device as <file> is not supported. Passing cd-rom device as <file> is supported only with cdrom media type (media=cdrom) and only as IDE drive (either if=ide or if=none + -device ide-drive). If <file> is neither block nor character device, it must not contain ':'. if =<interface> The following interfaces are supported: none, ide, virtio, floppy. index =<index> media =<media> cache =<cache> Supported values: none, writeback or writethrough. copy-on-read =[on|off] snapshot =[yes|no] serial =<serial> aio =<aio> format =<format> This option is not required and can be omitted. However, this is not recommended for raw images because it represents security risk. Supported formats are: qcow2 raw Boot Option -boot [order=<drives>][,menu=[on|off]] Snapshot Mode -snapshot

Commands:
6.4.2. Configuring the I/O Scheduler for Red Hat Enterprise Linux 7 For a Red Hat Enterprise Linux 7 guest, changes to the I/O scheduler can be made persistent through boot by adding the following elevator to /etc/grub2.cfg , as in the following example:

Commands:
vi /etc/grub2.cfg linux16 /vmlinuz-kernel-version root=/dev/mapper/vg0-lv0 ro rd.lvm.lv=vg0/lv0 vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rhgb quiet elevator=deadline initrd16 /initramfs-kernel-version.img
Chapter 14. Detecting BitRot BitRot detection is a technique used in Red Hat Gluster Storage to identify when silent corruption of data has occurred. BitRot also helps to identify when a brick's data has been manipulated directly, without using FUSE, NFS or any other access protocols. BitRot detection is particularly useful when using JBOD, since JBOD does not provide other methods of determining when data on a disk has become corrupt. The gluster volume bitrot command scans all the bricks in a volume for BitRot issues in a process known as scrubbing. The process calculates the checksum for each file or object, and compares that checksum against the actual data of the file. When BitRot is detected in a file, that file is marked as corrupted, and the detected errors are logged in the following files: /var/log/glusterfs/bitd.log /var/log/glusterfs/scrub.log 14.1. Enabling and Disabling the BitRot daemon The BitRot daemon is disabled by default. In order to use or configure the daemon, you first need to enable it. gluster volume bitrot VOLNAME enable Enable the BitRot daemon for the specified volume. gluster volume bitrot VOLNAME disable Disable the BitRot daemon for the specified volume.

Commands:
6.2. Setting up a Server Teiid Designer is installed as a component of JBoss Developer Studio hence connection to a JBoss Data Virtualization Server requires the setting up and configuration of its parent JBoss Server. This is achieved using the Server View, see Server View section, displayed as part of the Teiid Designer perspective. If no servers have been previously created then the Server View will display a new server hyperlink. To create a new JBoss Server configuration, click the hyperlink. Figure 6.4. Server View with no created servers Navigate through the wizard, configuring the details of the JBoss Server including its Runtime location, hostname and whether its externally managed. The final property determines whether the server is instantiated within the IDE or whether it is installed and started independently. Should the latter be the case then the Server View merely assumes connection to the independent server. Figure 6.5. New Server Configuration The server has been installed with a JBoss Data Virtualization Server and on clicking the green start button, Teiid Designer is successfully connected to the server, resulting in the display of the JBoss Data Virtualization Server's configuration. Figure 6.6. Server View with a single server JBoss Tools provides an editor for the configuration of the JBoss Data Virtualization Server. In addition, Designer provides an extra tab to this editor that displays the configuration of the JBoss Data Virtualization Server. Only a few options can be modified since most of the configuration is determined by the parent JBoss Server. This editor can be displayed by double-clicking on any node in the JBoss Server tree. Figure 6.7. Editor for Configuring the Teiid Server

Commands:
Chapter 17. Object Storage (swift) Parameters You can modify the swift service with object storage parameters. Parameter Description MemcachedTLS Set to True to enable TLS on Memcached service. Because not all services support Memcached TLS, during the migration period, Memcached will listen on 2 ports - on the port set with MemcachedPort parameter (above) and on 11211, without TLS. The default value is False . SwiftAccountWorkers Number of workers for Swift account service. The default value is 0 . SwiftCeilometerIgnoreProjects Comma-seperated list of project names to ignore. The default value is ['service'] . SwiftCeilometerPipelineEnabled Set to False to disable the object storage proxy ceilometer pipeline. The default value is False . SwiftContainerSharderEnabled Set to True to enable Swift container sharder service. The default value is False . SwiftContainerWorkers Number of workers for Swift account service. The default value is 0 . SwiftCorsAllowedOrigin Indicate whether this resource may be shared with the domain received in the request "origin" header. SwiftEncryptionEnabled Set to True to enable data-at-rest encryption in Swift. The default value is False . SwiftHashSuffix A random string to be used as a salt when hashing to determine mappings in the ring. SwiftMinPartHours The minimum time (in hours) before a partition in a ring can be moved following a rebalance. The default value is 1 . SwiftMountCheck Check if the devices are mounted to prevent accidentally writing to the root device. The default value is False . SwiftObjectWorkers Number of workers for Swift account service. The default value is 0 . SwiftPartPower Partition power to use when building object storage rings. The default value is 10 . SwiftPassword The password for the object storage service account. SwiftProxyNodeTimeout Timeout for requests going from swift-proxy to account, container, and object services. The default value is 60 . SwiftRawDisks Additional raw devices to use for the object storage backend. For example: {sdb: {}} SwiftReplicas Number of replicas to use in the object storage rings. The default value is 3 . SwiftRingBuild Whether to manage object storage rings or not. The default value is True . SwiftRingGetTempurl A temporary Swift URL to download rings from. SwiftRingPutTempurl A temporary Swift URL to upload rings to. SwiftUseLocalDir Use a local directory for object storage services when building rings. The default value is True . SwiftWorkers Number of workers for object storage service. Note that more workers creates a larger number of processes on systems, which results in excess memory consumption. It is recommended to choose a suitable non-default value on systems with high CPU core counts. 0 sets to the OpenStack internal default, which is equal to the number of CPU cores on the node. The default value is 0 .

Commands: