mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 14. ca This chapter describes the commands under the ca command. 14.1. ca get Retrieve a CA by providing its URI. Usage: Table 14.1. Positional Arguments Value Summary URI The uri reference for the ca. Table 14.2. Optional Arguments Value Summary -h, --help Show this help message and exit Table 14.3. Output Formatters 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 Table 14.4. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 14.5. Shell Formatter Value Summary --prefix PREFIX Add a prefix to all variable names Table 14.6. Table Formatter 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. 14.2. ca list List CAs. Usage: Table 14.7. Optional Arguments Value Summary -h, --help Show this help message and exit --limit LIMIT, -l LIMIT Specify the limit to the number of items to list per page (default: 10; maximum: 100) --offset OFFSET, -o OFFSET Specify the page offset (default: 0) --name NAME, -n NAME Specify the ca name (default: none) Table 14.8. Output Formatters Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated Table 14.9. CSV Formatter Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 14.10. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 14.11. Table Formatter 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 ca get [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] URI
openstack ca list [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN] [--limit LIMIT] [--offset OFFSET] [--name NAME]
11.4. Naming Scheme for Network Devices Available for Linux on System z Use the bus-ID to create predictable device names for network interfaces in Linux on System z instances. The bus-ID identifies a device in the s390 channel subsystem. A bus ID identifies the device within the scope of a Linux instance. For a CCW device, the bus ID is the device's device number with a leading 0.n , where n is the subchannel set ID. For example, 0.1.0ab1 . Network interfaces of device type Ethernet are named as follows: enccw 0 . 0 . 1234 CTC network devices of device type SLIP are named as follows: slccw 0 . 0 . 1234 Use the znetconf -c command or the lscss -a command to display available network devices and their bus-IDs. Table 11.1. Device Name Types for Linux on System z Format Description enccw bus-ID device type Ethernet slccw bus-ID CTC network devices of device type SLIP

Commands:
21.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: selinuxuser_postgresql_connect_enabled Having this Boolean enabled allows any user domain (as defined by PostgreSQL) to make connections to the database server. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
Chapter 94. KafkaConnectStatus schema reference Used in: KafkaConnect Property Description conditions List of status conditions. Condition array observedGeneration The generation of the CRD that was last reconciled by the operator. integer url The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors. string connectorPlugins The list of connector plugins available in this Kafka Connect deployment. ConnectorPlugin array labelSelector Label selector for pods providing this resource. string replicas The current number of pods being used to provide this resource. integer

Commands:
12.3. The Memcached Interface Connector The following enables a Memcached server using the memcached socket binding, and exposes the memcachedCache cache declared in the local container, using defaults for all other settings. Due to the limitations in the Memcached protocol, only one cache can be exposed by a connector. To expose more than one cache, declare additional memcached-connectors on different socket-bindings. See Section 12.3.1, "Configure Memcached Connectors" . Report a bug 12.3.1. Configure Memcached Connectors The following procedure describes the attributes used to configure the memcached connector within the connectors element in Red Hat JBoss Data Grid's Remote Client-Server Mode. Procedure 12.1. Configuring the Memcached Connector in Remote Client-Server Mode The memcached-connector element defines the configuration elements for use with memcached. The socket-binding parameter specifies the socket binding port used by the memcached connector. This is a mandatory parameter. The cache-container parameter names the cache container used by the memcached connector. This is a mandatory parameter. The worker-threads parameter specifies the number of worker threads available for the memcached connector. The default value for this parameter is 160. This is an optional parameter. The idle-timeout parameter specifies the time (in milliseconds) the connector can remain idle before the connection times out. The default value for this parameter is -1 , which means that no timeout period is set. This is an optional parameter. The tcp-nodelay parameter specifies whether TCP packets will be delayed and sent out in batches. Valid values for this parameter are true and false . The default value for this parameter is true . This is an optional parameter. The send-buffer-size parameter indicates the size of the send buffer for the memcached connector. The default value for this parameter is the size of the TCP stack buffer. This is an optional parameter. The receive-buffer-size parameter indicates the size of the receive buffer for the memcached connector. The default value for this parameter is the size of the TCP stack buffer. This is an optional parameter. Report a bug

Commands:
<memcached-connector socket-binding="memcached" cache-container="local"/>
<subsystem xmlns="urn:infinispan:server:endpoint:6.1"> <memcached-connector socket-binding="memcached" cache-container="local" worker-threads="USD{VALUE}" idle-timeout="{VALUE}" tcp-nodelay="{TRUE/FALSE}" send-buffer-size="{VALUE}" receive-buffer-size="USD{VALUE}" /> </subsystem>
Chapter 3. Understanding How SystemTap Works SystemTap allows users to write and reuse simple scripts to deeply examine the activities of a running Linux system. These scripts can be designed to extract data, filter it, and summarize it quickly (and safely), enabling the diagnosis of complex performance (or even functional) problems. The essential idea behind a SystemTap script is to name events , and to give them handlers . When SystemTap runs the script, SystemTap monitors for the event; once the event occurs, the Linux kernel then runs the handler as a quick sub-routine, then resumes. There are several kind of events; entering/exiting a function, timer expiration, session termination and so on. A handler is a series of script language statements that specify the work to be done whenever the event occurs. This work normally includes extracting data from the event context, storing them into internal variables, and printing results. 3.1. Architecture A SystemTap session begins when you run a SystemTap script. This session occurs in the following fashion: Procedure 3.1. SystemTap Session First, SystemTap checks the script against the existing tapset library (normally in /usr/share/systemtap/tapset/ for any tapsets used. SystemTap will then substitute any located tapsets with their corresponding definitions in the tapset library. SystemTap then translates the script to C, running the system C compiler to create a kernel module from it. The tools that perform this step are contained in the systemtap package (refer to Section 2.1.1, "Installing SystemTap" for more information). SystemTap loads the module, then enables all the probes (events and handlers) in the script. The staprun in the systemtap-runtime package (refer to Section 2.1.1, "Installing SystemTap" for more information) provides this functionality. As the events occur, their corresponding handlers are executed. Once the SystemTap session is terminated, the probes are disabled, and the kernel module is unloaded. This sequence is driven from a single command-line program: stap . This program is SystemTap's main front-end tool. For more information about stap , refer to man stap (once SystemTap is properly installed on your machine).

Commands:
Preface Learn how to use both the OpenShift command-line interface and web console to install Red Hat OpenShift AI Self-Managed on your OpenShift cluster in a disconnected environment. To uninstall the product, learn how to use the recommended command-line interface (CLI) method. Note Red Hat does not support installing more than one instance of OpenShift AI on your cluster. Red Hat does not support installing the Red Hat OpenShift AI Operator on the same cluster as the Red Hat OpenShift AI Add-on.

Commands:
Chapter 122. KafkaMirrorMakerTemplate schema reference Used in: KafkaMirrorMakerSpec Property Property type Description deployment DeploymentTemplate Template for Kafka MirrorMaker Deployment . pod PodTemplate Template for Kafka MirrorMaker Pods . podDisruptionBudget PodDisruptionBudgetTemplate Template for Kafka MirrorMaker PodDisruptionBudget . mirrorMakerContainer ContainerTemplate Template for Kafka MirrorMaker container. serviceAccount ResourceTemplate Template for the Kafka MirrorMaker service account.

Commands:
Chapter 3. The Grouping API The Grouping API can relocate groups of entries to a specified node or to a node selected using the hash of the group. 23155%2C+Developer+Guide-6.630-06-2017+15%3A00%3A55JBoss+Data+Grid+6Documentation6.6.1 Report a bug 3.1. Grouping API Operations Normally, Red Hat JBoss Data Grid uses the hash of a specific key to determine an entry's destination node. However, when the Grouping API is used, a hash of the group associated with the key is used instead of the hash of the key to determine the destination node. Each node can use an algorithm to determine the owner of each key. This removes the need to pass metadata (and metadata updates) about the location of entries between nodes. This approach is beneficial because: Every node can determine which node owns a particular key without expensive metadata updates across nodes. Redundancy is improved because ownership information does not need to be replicated if a node fails. When using the Grouping API, each node must be able to calculate the owner of an entry. As a result, the group cannot be specified manually and must be either: Intrinsic to the entry, which means it was generated by the key class. Extrinsic to the entry, which means it was generated by an external function. Report a bug

Commands:
17.10. Resolving Hostnames in the IdM Domain It is possible to check the DNS entries for IdM domain members using the dns-resolve command. If the record exists and is properly formatted in the DNS configuration, then the command returns the DNS record. If not, the command returns an error, that the hostname is not recognized within the DNS service. This can be helpful with troubleshooting connection problems between servers, clients, and services.

Commands:
USDipa dns-resolve server1.example.com
Chapter 7. Checking IdM replication using Healthcheck You can test Identity Management (IdM) replication using the Healthcheck tool. Prerequisites You are using RHEL version 8.1 or newer. 7.1. Replication healthcheck tests The Healthcheck tool tests the Identity Management (IdM) topology configuration and searches for replication conflict issues. To list all tests, run the ipa-healthcheck with the --list-sources option: The topology tests are placed under the ipahealthcheck.ipa.topology and ipahealthcheck.ds.replication sources: IPATopologyDomainCheck This test verifies: That no single server is disconnected from the topology. That servers do not have more than the recommended number of replication agreements. If the test succeeds, the test returns the configured domains. Otherwise, specific connection errors are reported. Note The test runs the ipa topologysuffix-verify command for the domain suffix. It also runs the command for the ca suffix if the IdM Certificate Authority server role is configured on this server. ReplicationConflictCheck The test searches for entries in LDAP matching (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) . Note Run these tests on all IdM servers when trying to check for issues. Additional resources Solving common replication problems 7.2. Screening replication using Healthcheck Follow this procedure to run a standalone manual test of an Identity Management (IdM) replication topology and configuration using the Healthcheck tool. The Healthcheck tool includes many tests. Therefore, you can shorten the results with: Replication conflict test: --source=ipahealthcheck.ds.replication Correct topology test: --source=ipahealthcheck.ipa.topology Prerequisites You are logged in as the root user. Procedure To run Healthcheck replication conflict and topology checks, enter: Four different results are possible: SUCCESS - the test passed successfully. WARNING - the test passed but there might be a problem. ERROR - the test failed. CRITICAL - the test failed and it affects the IdM server functionality. Additional resources man ipa-healthcheck 7.3. Additional resources Healthcheck in IdM

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology
{ "source": "ipahealthcheck.ipa.topology", "check": "IPATopologyDomainCheck", "result": "SUCCESS", "kw": { "suffix": "domain" } }
{ "source": "ipahealthcheck.ipa.topology", "check": "IPATopologyDomainCheck", "result": "ERROR", "uuid": d6ce3332-92da-423d-9818-e79f49ed321f "when": 20191007115449Z "duration": 0.005943 "kw": { "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)" } }
Chapter 5. Process Management This section on process management covers two different situations: the single-process container, which houses the files that the container needs to do its job the managed-multiprocess container, which consists of several heterogeneous processes running at the same time Apache is an example of a single-process container. Apache does all of its own logging, which means that it does not require an external container to do its logging. This means that using systemd in this case does not offer any benefits. GNOME 3 is an example of a managed-multiprocess container. Attempting to manage this kind of container manually (for instance, trying to get upower and DBUS and logging working together) is more onerous than simply getting systemd to work. 5.1. Running systemd in a Container In the case of the managed-multiprocess container, implement systemd to manage the several processes running within the container. To run systemd in a container, run a command similar to the following command: Note The above command ( -it ) launches an interactive-tty container running systemd . For more historical context on running systemd in a container, see Dan Walsh's May 2014 blog post on the matter: Running systemd within a Docker Container . 5.1.1. journald and systemd in a container Disable journal auditing in containers. Permit only the docker host to run journald . Journal auditing is a kernel feature, and only one instance of journald can use it at a time. (It is fine if the docker host is still running journald.) 5.1.2. Services and containers Services work out of the box in containers. Services "just work" in containers. No special configuration is necessary for services to work in containers. 5.1.3. Managing Hardware that is Outside the Container It is possible to create a container that uses systemd to manage outside hardware, but so configuring a container makes it non-portable because the container expects the specific hardware setup against which it is configured to be available for management. 5.1.4. systemd and Zombies systemd solves the zombie problem. When processes die and become zombies, init 1 reaps them. This is just as true inside a container as it is outside a container. Expect systemd inside a container to reap zombies in exactly the way you have come to expect it to reap zombies outside a container. If you start a container without systemd (or, for instance, sysv ), processes that die in that container will never be reaped.

Commands:
sudo docker run -it IMAGE /bin/bash
7.133. ncurses 7.133.1. RHBA-2015:0687 - ncurses bug fix update Updated ncurses packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ncurses (new curses) library routines are a terminal-independent method of updating character screens with reasonable optimization. The ncurses packages contain support utilities including a terminfo compiler tic, a decompiler infocmp, clear, tput, tset, and a termcap conversion tool captoinfo. Bug Fix BZ# 1025744 Prior to this update, compilation of applications that use pkg-config and static linking could fail, as the ncurses.pc files did not include the "-ltinfo" option for static linking with ncurses. To fix this bug, the "-ltinfo" option has been included in the pkg-config files and applications now compile successfully. Users of ncurses are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 3. Checking disk space using IdM Healthcheck You can monitor the Identity Management server's free disk space using the Healthcheck tool. For details, see Healthcheck in IdM . 3.1. Disk space healthcheck test The Healthcheck tool includes a test for checking available disk space. Insufficient free disk space can cause issues with: Logging Execution Backups The test checks the following paths: Table 3.1. Tested paths Paths checked by the test Minimal disk space in MB /var/lib/dirsrv/ 1024 /var/lib/ipa/backup/ 512 /var/log/ 1024 var/log/audit/ 512 /var/tmp/ 512 /tmp/ 512 To list all tests, run the ipa-healthcheck with the --list-sources option: You can find the file system space check test under the ipahealthcheck.system.filesystemspace source: FileSystemSpaceCheck This test checks available disk space in the following ways: The minimum raw free bytes needed. The percentage - the minimum free disk space is hardcoded to 20%. 3.2. Screening disk space using the healthcheck tool Follow this procedure to run a standalone manual test of available disk space on an Identity Management (IdM) server using the Healthcheck tool. Since Healthcheck includes many tests, you can narrow the results by: Excluding all successful test: --failures-only Including only space check tests: --source=ipahealthcheck.system.filesystemspace Procedure To run Healthcheck with warnings, errors and critical issues regarding available disk space, enter: A successful test displays empty brackets: As an example, a failed test can display: The failed test informs you that the /var/lib/dirsrv directory has run out of space. Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only
{ "source": "ipahealthcheck.system.filesystemspace", "check": "FileSystemSpaceCheck", "result": "ERROR", "kw": { "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB", "store": "/var/lib/dirsrv", "free_space": 0, "threshold": 1024 } }
Chapter 1. Machine APIs 1.1. ContainerRuntimeConfig [machineconfiguration.openshift.io/v1] Description ContainerRuntimeConfig describes a customized Container Runtime configuration. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. ControllerConfig [machineconfiguration.openshift.io/v1] Description ControllerConfig describes configuration for MachineConfigController. This is currently only used to drive the MachineConfig objects generated by the TemplateController. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.3. ControlPlaneMachineSet [machine.openshift.io/v1] Description ControlPlaneMachineSet ensures that a specified number of control plane machine replicas are running at any given time. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. KubeletConfig [machineconfiguration.openshift.io/v1] Description KubeletConfig describes a customized Kubelet configuration. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. MachineConfig [machineconfiguration.openshift.io/v1] Description MachineConfig defines the configuration for a machine Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.6. MachineConfigNode [machineconfiguration.openshift.io/v1alpha1] Description MachineConfigNode describes the health of the Machines on the system Compatibility level 4: No compatibility is provided, the API can change at any point for any reason. These capabilities should not be used by applications needing long term support. Type object 1.7. MachineConfigPool [machineconfiguration.openshift.io/v1] Description MachineConfigPool describes a pool of MachineConfigs. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.8. MachineHealthCheck [machine.openshift.io/v1beta1] Description MachineHealthCheck is the Schema for the machinehealthchecks API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.9. Machine [machine.openshift.io/v1beta1] Description Machine is the Schema for the machines API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.10. MachineSet [machine.openshift.io/v1beta1] Description MachineSet ensures that a specified number of machines replicas are running at any given time. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object

Commands: