mtpti5iD/redhat-docs_dataset huggingface dataset:
12.2. Requesting a Self-signed Certificate with certmonger To request a certificate with certmonger , use the getcert request utility. Certificates and keys are stored locally in plain text files with the .pem extension or in an NSS database, identified by the certificate nickname. When requesting a certificate, then, the request should identify the location where the certificate will be stored and the nickname of the certificate. For example: The /etc/pki/nssdb file is the global NSS database, and Server-Cert is the nickname of this certificate. The certificate nickname must be unique within this database. The options you can provide with the command to generate a certificate vary depending on what kind of certificate you are requesting and the required configuration for the final certificate, as well as other settings: -r automatically renews the certificate when its expiration date is close if the key pair already exists. This option is used by default. -f stores the certificate in the given file. -k either stores the key in the given file or, if the key file already exists, uses the key in the file. -K gives the Kerberos principal name of the service that will be using the certificate; -K is required when requesting a certificate from an IdM server and optional when requesting a self-signed or locally-signed certificate -N gives the subject name. -D requests a DNS domain name to be included in the certificate as a subjectAltName value. -U sets the extended key usage flag. -A requests an IP address to be included in the certificate as a subjectAltName value. -I sets a name for the task. certmonger uses this name to refer to the combination of storage locations and request options, and it is also displayed in the output of the getcert list command. If you do not specify this option, certmonger assigns an automatically-generated name for the task. A real CA, such as the one in IdM, can ignore anything that you specify in the signing request using the -K , -N , -D , -U , and -A options according to the CA's own policies. For example, IdM requires that -K and -N agree with the local host name. Certificates generated using the selfsign-getcert and local-getcert commands, on the other hand, agree with the options that you specify because these commands do not enforce any policy. Example 12.1. Using certmonger for a Service

Commands:
selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
Chapter 30. Using sudo Identity Management provides a mechanism for predictably and consistently applying sudo policies across the IdM domain. Every system in the IdM domain can be configured as a sudo client. 30.1. The sudo Utility in Identity Management The sudo utility gives administrative access to specified users. When trusted users precede an administrative command with sudo , they are prompted for their own password. Then, when they have been authenticated and assuming that the command is permitted, the administrative command is executed as if they were the root user. For more information about sudo , see the System Administrator's Guide . 30.1.1. The Identity Management LDAP Schema for sudo IdM has a specialized LDAP schema for sudo entries. The schema supports: Host groups as well as netgroups. Note that sudo only supports netgroups. sudo command groups, which contain multiple commands. Note Because sudo does not support host groups or command groups, IdM translates the IdM sudo configuration into the native sudo configuration when the sudo rules are created. For example, IdM creates a corresponding shadow netgroup for every host group, which allows the IdM administrator to create sudo rules that reference host groups, while the local sudo command uses the corresponding netgroup. By default, the sudo information is not available anonymously over LDAP. Therefore, IdM defines a default sudo user at uid=sudo,cn=sysaccounts,cn=etc,USDSUFFIX . You can change this user in the LDAP sudo configuration file at /etc/sudo-ldap.conf . 30.1.2. NIS Domain Name Requirements The NIS domain name must be set for netgroups and sudo to work properly. The sudo configuration requires NIS-formatted netgroups and a NIS domain name for netgroups. However, IdM does not require the NIS domain to actually exist. It is also not required to have a NIS server installed. Note The ipa-client-install utility sets a NIS domain name automatically to the IdM domain name by default.

Commands:
Chapter 2. Creating the first administrator After installing Red Hat build of Keycloak, you need an administrator account that can act as a super admin with full permissions to manage Red Hat build of Keycloak. With this account, you can log in to the Red Hat build of Keycloak Admin Console where you create realms and users and register applications that are secured by Red Hat build of Keycloak. 2.1. Creating the account on the local host If your server is accessible from localhost , perform these steps. Procedure In a web browser, go to the http://localhost:8080 URL. Supply a username and password that you can recall. Welcome page 2.2. Creating the account remotely If you cannot access the server from a localhost address or just want to start Red Hat build of Keycloak from the command line, use the KEYCLOAK_ADMIN and KEYCLOAK_ADMIN_PASSWORD environment variables to create an initial admin account. For example: export KEYCLOAK_ADMIN=<username> export KEYCLOAK_ADMIN_PASSWORD=<password> bin/kc.[sh|bat] start

Commands:
export KEYCLOAK_ADMIN=<username> export KEYCLOAK_ADMIN_PASSWORD=<password> bin/kc.[sh|bat] start
7.2. Configure Bonding Using the Text User Interface, nmtui The text user interface tool nmtui can be used to configure bonding in a terminal window. Issue the following command to start the tool: The text user interface appears. Any invalid command prints a usage message. To navigate, use the arrow keys or press Tab to step forwards and press Shift + Tab to step back through the options. Press Enter to select an option. The Space bar toggles the status of a check box. From the starting menu, select Edit a connection . Select Add , the New Connection screen opens. Figure 7.1. The NetworkManager Text User Interface Add a Bond Connection menu Select Bond and then Create ; the Edit connection screen for the bond will open. Figure 7.2. The NetworkManager Text User Interface Configuring a Bond Connection menu At this point port interfaces will need to be added to the bond; to add these select Add , the New Connection screen opens. Once the type of Connection has been chosen select the Create button. Figure 7.3. The NetworkManager Text User Interface Configuring a New Bond Slave Connection menu The port's Edit Connection display appears; enter the required port's device name or MAC address in the Device section. If required, enter a clone MAC address to be used as the bond's MAC address by selecting Show to the right of the Ethernet label. Select the OK button to save the port. Note If the device is specified without a MAC address the Device section will be automatically populated once the Edit Connection window is reloaded, but only if it successfully finds the device. Figure 7.4. The NetworkManager Text User Interface Configuring a Bond Slave Connection menu The name of the bond port appears in the Slaves section. Repeat the above steps to add further port connections. Review and confirm the settings before selecting the OK button. Figure 7.5. The NetworkManager Text User Interface Completed Bond See Section 7.8.1.1, "Configuring the Bond Tab" for definitions of the bond terms. See Section 3.2, "Configuring IP Networking with nmtui" for information on installing nmtui .

Commands:
~]USD nmtui
Chapter 5. Installation and Booting The ARPUPDATE option for ifcfg-* files has been introduced This update introduces the ARPUPDATE option for ifcfg-* files. The default value is `yes`; setting the value to no allows you to disable updating neighboring computers using the Address Resolution Protocol (ARP) information about the current network interface controller. This is especially useful when using Linux Virtual Server (LVS) Load Balancing with direct routing enabled. (BZ#1440888)

Commands:
Chapter 5. Minimum hardware recommendations for containerized Ceph Ceph can run on non-proprietary commodity hardware. Small production clusters and development clusters can run without performance optimization with modest hardware. Process Criteria Minimum Recommended ceph-osd-container Processor 1x AMD64 or Intel 64 CPU CORE per OSD container RAM Minimum of 5 GB of RAM per OSD container OS Disk 1x OS disk per host OSD Storage 1x storage drive per OSD container. Cannot be shared with OS Disk. block.db Optional, but Red Hat recommended, 1x SSD or NVMe or Optane partition or lvm per daemon. Sizing is 4% of block.data for BlueStore for object, file and mixed workloads and 1% of block.data for the BlueStore for Block Device, Openstack cinder, and Openstack cinder workloads. block.wal Optionally, 1x SSD or NVMe or Optane partition or logical volume per daemon. Use a small size, for example 10 GB, and only if it's faster than the block.db device. Network 2x 10 GB Ethernet NICs ceph-mon-container Processor 1x AMD64 or Intel 64 CPU CORE per mon-container RAM 3 GB per mon-container Disk Space 10 GB per mon-container , 50 GB Recommended Monitor Disk Optionally, 1x SSD disk for Monitor rocksdb data Network 2x 1GB Ethernet NICs, 10 GB Recommended ceph-mgr-container Processor 1x AMD64 or Intel 64 CPU CORE per mgr-container RAM 3 GB per mgr-container Network 2x 1GB Ethernet NICs, 10 GB Recommended ceph-radosgw-container Processor 1x AMD64 or Intel 64 CPU CORE per radosgw-container RAM 1 GB per daemon Disk Space 5 GB per daemon Network 1x 1GB Ethernet NICs ceph-mds-container Processor 1x AMD64 or Intel 64 CPU CORE per mds-container RAM 3 GB per mds-container This number is highly dependent on the configurable MDS cache size. The RAM requirement is typically twice as much as the amount set in the mds_cache_memory_limit configuration setting. Note also that this is the memory for your daemon, not the overall system memory. Disk Space 2 GB per mds-container , plus taking into consideration any additional space required for possible debug logging, 20GB is a good start. Network 2x 1GB Ethernet NICs, 10 GB Recommended Note that this is the same network as the OSD containers. If you have a 10 GB network on your OSDs you should use the same on your MDS so that the MDS is not disadvantaged when it comes to latency.

Commands:
Deploying and managing OpenShift Container Storage using Red Hat OpenStack Platform Red Hat OpenShift Container Storage 4.6 How to install and manage Red Hat Storage Documentation Team Abstract Read this document for instructions on installing and managing Red Hat OpenShift Container Storage on Red Hat OpenStack Platform (RHOSP). Important Deploying and managing OpenShift Container Storage on Red Hat OpenStack Platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Commands:
Chapter 1. Introduction to developing applications with Red Hat build of Apache Camel for Quarkus This guide is for developers writing Camel applications on top of Red Hat build of Apache Camel for Quarkus. Camel components which are supported in Red Hat build of Apache Camel for Quarkus have an associated Red Hat build of Apache Camel for Quarkus extension. For more information about the Red Hat build of Apache Camel for Quarkus extensions supported in this distribution, see the Red Hat build of Apache Camel for Quarkus Extensions reference guide.

Commands:
B.17.2.2. Unterminated attribute Symptom The following error occurs: Investigation This snippet of a guest's XML file contains an unterminated element attribute value: In this case, 'kvm' is missing a second quotation mark. Strings of attribute values, such as quotation marks and apostrophes, must be opened and closed, similar to XML start and end tags. Solution Correctly open and close all attribute value strings.

Commands:
error: ( name_of_guest.xml ):2: Unescaped '<' not allowed in attributes values <name> name_of_guest </name> --^
<domain type='kvm> <name> name_of_guest </name>
B.39.5. RHSA-2011:0447 - Moderate: krb5 security update Updated krb5 packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Kerberos is a network authentication system which allows clients and servers to authenticate to each other using symmetric encryption and a trusted third-party, the Key Distribution Center (KDC). CVE-2011-0285 An invalid free flaw was found in the password-changing capability of the MIT Kerberos administration daemon, kadmind. A remote, unauthenticated attacker could use this flaw to cause kadmind to abort via a specially-crafted request. All krb5 users should upgrade to these updated packages, which contain a backported patch to correct this issue. After installing the updated packages, the kadmind daemon will be restarted automatically.

Commands:
Chapter 17. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace that makes it easy to discover and access certified software for container-based environments that run on public clouds and on-premises. 17.1. Red Hat Marketplace features Cluster administrators can use the Red Hat Marketplace to manage software on OpenShift Container Platform, give developers self-service access to deploy application instances, and correlate application usage against a quota. 17.1.1. Connect OpenShift Container Platform clusters to the Marketplace Cluster administrators can install a common set of applications on OpenShift Container Platform clusters that connect to the Marketplace. They can also use the Marketplace to track cluster usage against subscriptions or quotas. Users that they add by using the Marketplace have their product usage tracked and billed to their organization. During the cluster connection process , a Marketplace Operator is installed that updates the image registry secret, manages the catalog, and reports application usage. 17.1.2. Install applications Cluster administrators can install Marketplace applications from within OperatorHub in OpenShift Container Platform, or from the Marketplace web application . You can access installed applications from the web console by clicking Operators > Installed Operators . 17.1.3. Deploy applications from different perspectives You can deploy Marketplace applications from the web console's Administrator and Developer perspectives. The Developer perspective Developers can access newly installed capabilities by using the Developer perspective. For example, after a database Operator is installed, a developer can create an instance from the catalog within their project. Database usage is aggregated and reported to the cluster administrator. This perspective does not include Operator installation and application usage tracking. The Administrator perspective Cluster administrators can access Operator installation and application usage information from the Administrator perspective. They can also launch application instances by browsing custom resource definitions (CRDs) in the Installed Operators list.

Commands:
Chapter 33. InlineLogging schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the InlineLogging type from ExternalLogging . It must have the value inline for the type InlineLogging . Property Property type Description type string Must be inline . loggers map A Map from logger name to logger level.

Commands:
1.2. SELinux The High Availability Add-On for Red Hat Enterprise Linux 6 supports SELinux in the enforcing state with the SELinux policy type set to targeted . Note When using SELinux with the High Availability Add-On in a VM environment, you should ensure that the SELinux boolean fenced_can_network_connect is persistently set to on . This allows the fence_xvm fencing agent to work properly, enabling the system to fence virtual machines. For more information about SELinux, see Deployment Guide for Red Hat Enterprise Linux 6.

Commands:
24.2. Configuring DHCP for Diskless Clients Prerequisites Install the necessary packages. See Chapter 24, Setting up a Remote Diskless System Configure the tftp service. See Section 24.1, "Configuring a tftp Service for Diskless Clients" . Procedure After configuring a tftp server, you need to set up a DHCP service on the same host machine. For instructions on setting up a DHCP server, see the Configuring a DHCP Server . Enable PXE booting on the DHCP server by adding the following configuration to /etc/dhcp/dhcpd.conf : Replace server-ip with the IP address of the host machine on which the tftp and DHCP services reside. Note When libvirt virtual machines are used as the diskless client, libvirt provides the DHCP service and the stand alone DHCP server is not used. In this situation, network booting must be enabled with the bootp file=' filename ' option in the libvirt network configuration, virsh net-edit . Steps Now that tftp and DHCP are configured, configure NFS and the exported file system. For instructions, see the Section 24.3, "Configuring an Exported File System for Diskless Clients" .

Commands:
allow booting; allow bootp; class "pxeclients" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; next-server server-ip ; filename "pxelinux.0"; }
Chapter 2. Nagios Core installation and configuration As a storage administrator, you can install Nagios Core by downloading the Nagios Core source code; then, configuring, making and installing it on the node that will run Nagios Core instance. 2.1. Installing and configuring the Nagios Core server from source There is not a Red Hat Enterprise Linux package for the Nagios Core software, so the Nagios Core software must be compiled from source. Prerequisites Access to OpenSSL. Internet access. Procedure Install the prerequisites: Open port 80 for httpd : Create a user and group for Nagios Core: Download the latest version of Nagios Core and Plug-ins: Run ./configure : Compile the Nagios Core source code: Install Nagios source code: Copy the event handlers and change their ownership: Run the pre-flight check: Make and install the Nagios Core plug-ins: Create a user for the Nagios Core user interface: Important If adding a user other than nagiosadmin , ensure the /usr/local/nagios/etc/cgi.cfg file gets updated with the username too. Also modify the /usr/local/nagios/etc/objects/contacts.cfg file with the user name, full name and email address as needed. 2.2. Starting the Nagios Core service Start the Nagios Core service to monitor the Red Hat Ceph Storage cluster health. Prerequisites Root-level access to the Nagios Core service. Procedure Add Nagios Core as a service and enable it: Start the Nagios Core daemon and Apache: 2.3. Logging into the Nagios Core server Log in to the Nagios Core server to view the health status of the Red Hat Ceph Storage cluster. Prerequisites User name and password for the Nagios web interface. Procedure With Nagios up and running, log in to the web user interface: Nagios Core will prompt for a user name and password. Input the login and password of the default Nagios Core user.

Commands:
yum install -y httpd php php-cli gcc glibc glibc-common gd gd-devel net-snmp openssl openssl-devel wget unzip
firewall-cmd --zone=public --add-port=80/tcp firewall-cmd --zone=public --add-port=80/tcp --permanent
useradd nagios passwd nagios groupadd nagcmd usermod -a -G nagcmd nagios usermod -a -G nagcmd apache
wget --inet4-only https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.3.1.tar.gz wget --inet4-only http://www.nagios-plugins.org/download/nagios-plugins-2.2.1.tar.gz tar zxf nagios-4.3.1.tar.gz tar zxf nagios-plugins-2.2.1.tar.gz cd nagios-4.3.1
./configure --with-command-group=nagcmd
make all
make install make install-init make install-config make install-commandmode make install-webconf
cp -R contrib/eventhandlers/ /usr/local/nagios/libexec/ chown -R nagios:nagios /usr/local/nagios/libexec/eventhandlers
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
cd ../nagios-plugins-2.2.1 ./configure --with-nagios-user=nagios --with-nagios-group=nagios make make install
[user@nagios]USD sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
chkconfig --add nagios chkconfig --level 35 nagios on
systemctl start nagios systemctl enable httpd systemctl start httpd
http:// IP_ADDRESS /nagios
Chapter 72. Running a test scenario locally In Red Hat Decision Manager, you can either run the test scenarios directly in Business Central or locally using the command line. Procedure In Business Central, go to Menu Design Projects and click the project name. On the Project's home page, select the Settings tab. Select git URL and click the Clipboard to copy the git url. Open a command terminal and navigate to the directory where you want to clone the git project. Run the following command: Replace your_git_project_url with relevant data like git://localhost:9418/MySpace/ProjectTestScenarios . Once the project is successfully cloned, navigate to the git project directory and execute the following command: Your project's build information and the test results (such as, the number of tests run and whether the test run was a success or not) are displayed in the command terminal. In case of failures, make the necessary changes in Business Central, pull the changes and run the command again.

Commands:
git clone your_git_project_url
mvn clean test