mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Pulling images from a container repository Pull images from the automation hub container registry to make a copy to your local machine. Automation hub provides the podman pull command for each latest image in the container repository. You can copy and paste this command into your terminal, or use podman pull to copy an image based on an image tag. 7.1. Pulling an image You can pull images from the automation hub container registry to make a copy to your local machine. Prerequisites You must have permission to view and pull from a private container repository. Procedure If you are pulling container images from a password or token-protected registry, create a credential in automation controller before pulling the image. From the navigation panel, select Execution Environments Execution Environments . Select your container repository. In the Pull this image entry, click Copy to clipboard . Paste and run the command in your terminal. Verification Run podman images to view images on your local machine. 7.2. Syncing images from a container repository You can pull images from the automation hub container registry to sync an image to your local machine. To sync an image from a remote container registry, you must first configure a remote registry. Prerequisites You must have permission to view and pull from a private container repository. Procedure From the navigation panel, select Execution Environments Execution Environments . Add https://registry.redhat.io to the registry. Add any required credentials to authenticate. Note Some container registries are aggressive with rate limiting. Set a rate limit under Advanced Options . From the navigation panel, select Execution Environments Execution Environments . Click Add execution environment in the page header. Select the registry you want to pull from. The Name field displays the name of the image displayed on your local registry. Note The Upstream name field is the name of the image on the remote server. For example, if the upstream name is set to "alpine" and the Name field is "local/alpine", the alpine image is downloaded from the remote and renamed to "local/alpine". Set a list of tags to include or exclude. Syncing images with a large number of tags is time consuming and uses a lot of disk space. Additional resources See Red Hat Container Registry Authentication for a list of registries. See the What is Podman? documentation for options to use when pulling images.

Commands:
20.3.4.2. Generating a DSA Key Pair for Version 2 Use the following steps to generate a DSA key pair for version 2 of the SSH Protocol. To generate a DSA key pair to work with version 2 of the protocol, type the following command at a shell prompt: Accept the default file location of ~/.ssh/id_dsa . Enter a passphrase different from your account password and confirm it by entering it again. Note A passphrase is a string of words and characters used to authenticate a user. Passphrases differ from passwords in that you can use spaces or tabs in the passphrase. Passphrases are generally longer than passwords because they are usually phrases instead of a single word. The public key is written to ~/.ssh/id_dsa.pub . The private key is written to ~/.ssh/id_dsa . It is important never to give anyone the private key. Change the permissions of the .ssh directory with the following command: Copy the contents of ~/.ssh/id_dsa.pub into the file ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys exist, append the contents of the file ~/.ssh/id_dsa.pub to the file ~/.ssh/authorized_keys on the other machine. Change the permissions of the authorized_keys file using the following command: If you are running GNOME, skip to Section 20.3.4.4, "Configuring ssh-agent with GNOME" . If you are not running the X Window System, skip to Section 20.3.4.5, "Configuring ssh-agent " .

Commands:
ssh-keygen -t dsa
chmod 755 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
Chapter 33. Managing DNS An Identity Management server can be installed without integrated DNS services so that it uses an external DNS service or with DNS configured. See Section 2.3, "Installing an IdM Server: Introduction" and Section 2.3.1, "Determining Whether to Use Integrated DNS" for details. If the DNS service is configured within the domain, IdM offers the administrator a significant amount of flexibility and control over DNS settings. For example, DNS entries for the domain, such as host entries, locations, or records, can be managed using native IdM tools, and clients can update their own DNS records dynamically. Most documentation material and tutorials available for BIND version 9.9 are also applicable to IdM DNS, because majority of configuration options work in the same way in BIND and IdM. This chapter mostly focuses on notable differences between BIND and IdM. 33.1. BIND in Identity Management IdM integrates BIND DNS server version 9.9 with an LDAP database used for data replication and with Kerberos for DNS update signing using the GSS-TSIG protocol [3] . This enables convenient DNS management using IdM tools and at the same time increases resiliency because IdM-integrated DNS servers support multi-master operations, allowing all IdM-integrated DNS servers to accept DNS updates from clients without having a single point of failure. The default IdM DNS configuration is suitable for internal networks that are not accessible from the public Internet. If the IdM DNS server is accessible from the public Internet, Red Hat recommends applying the usual hardening applicable to the BIND service, described in the Red Hat Enterprise Linux Networking Guide . Note It is not possible to run BIND integrated with IdM inside a chroot environment. The BIND (Berkeley Internet Name Domain) implementation of the DNS (Domain Name System) protocols in Red Hat Enterprise Linux includes the named DNS server. named-pkcs11 is a version of the BIND DNS server built with native support for the PKCS#11 cryptographic standard. BIND integrated with IdM communicates with the Directory Server using the bind-dyndb-ldap plug-in. IdM creates a dynamic-db configuration section in the /etc/named.conf file for the BIND service, which configures the bind-dyndb-ldap plug-in for the BIND named-pkcs11 service. The most notable difference between standard BIND and IdM DNS is that IdM stores all DNS information as LDAP entries. Every domain name is represented as an LDAP entry, and every resource record is stored as an LDAP attribute of the LDAP entry. For example, the following client1.example.com. domain name contains three A records and one AAAA record: Important To edit DNS data or BIND configuration, always use the IdM tools described in this chapter. [3] For more information about GSS-TSIG, see RFC 3545 .

Commands:
dn: idnsname=client1,idnsname=example.com.,cn=dns,dc=idm,dc=example,dc=com objectclass: top objectclass: idnsrecord idnsname: client1 Arecord: 192.0.2.1 Arecord: 192.0.2.2 Arecord: 192.0.2.3 AAAArecord: 2001:DB8::ABCD
18.12.5. Automatic IP Address Detection and DHCP Snooping This section provides information about automatic IP address detection and DHCP snooping. 18.12.5.1. Introduction The detection of IP addresses used on a virtual machine's interface is automatically activated if the variable IP is referenced but no value has been assigned to it. The variable CTRL_IP_LEARNING can be used to specify the IP address learning method to use. Valid values include: any , dhcp , or none . The value any instructs libvirt to use any packet to determine the address in use by a virtual machine, which is the default setting if the variable TRL_IP_LEARNING is not set. This method will only detect a single IP address per interface. Once a guest virtual machine's IP address has been detected, its IP network traffic will be locked to that address, if for example, IP address spoofing is prevented by one of its filters. In that case, the user of the VM will not be able to change the IP address on the interface inside the guest virtual machine, which would be considered IP address spoofing. When a guest virtual machine is migrated to another host physical machine or resumed after a suspend operation, the first packet sent by the guest virtual machine will again determine the IP address that the guest virtual machine can use on a particular interface. The value of dhcp instructs libvirt to only honor DHCP server-assigned addresses with valid leases. This method supports the detection and usage of multiple IP address per interface. When a guest virtual machine resumes after a suspend operation, any valid IP address leases are applied to its filters. Otherwise the guest virtual machine is expected to use DHCP to obtain a new IP addresses. When a guest virtual machine migrates to another physical host physical machine, the guest virtual machine is required to re-run the DHCP protocol. If CTRL_IP_LEARNING is set to none , libvirt does not do IP address learning and referencing IP without assigning it an explicit value is an error.

Commands:
Part I. Firewall Rules for Red Hat OpenStack Platform This document includes a link to the Red Hat OpenStack Platform (RHOSP) network flow matrix. Use this information to help you define firewall rules. The matrix lists RHOSP core services and their dependencies and describes the ports and protocols they use and the associated traffic flows. It includes the following columns: Service The OpenStack service. Protocol Transmission protocol. Dest. Port Destination port. Source Object Source of data. Dest. Object Destination of data. Source/Dest Pairs Valid source and destination pairs. Dest. Network Destination network. ServiceNetMap Parent Determines the network type used for each service. Traffic Description Notes about the traffic flow. 1. Using the Red Hat OpenStack Network Flow Matrix The network flow matrix is a comma separated values (CSV) file that describes flows to and from Red Hat OpenStack Platform (RHOSP) services. Note The network flow matrix describes common traffic flows. It does not describe every possible service and flow. Some flows that are not described in this matrix might be critical to operation. For example, if you block all traffic and then selectively open only the flows described here, you might unintentionally block a necessary flow. That could cause issues that are difficult to troubleshoot. Procedure Use the following link to download the matrix: Red Hat OpenStack Network Flows . For example, right click the link and choose Save link as . Ensure that the downloaded file has the .csv filename extension. For example, if it is .txt , change it to .csv . Use the information in the file to help you formulate firewall rules. You can open it in a spreadsheet application that accepts .csv files, or access it with your own program.

Commands:
Chapter 5. Creating a Puppet config group A Puppet config group is a named list of Puppet classes that allows you to combine their capabilities and assign them to hosts at a click. This is equivalent to the concept of profiles in pure Puppet. Procedure In the Satellite web UI, navigate to Configure > Puppet ENC > Config Groups . Click Create Config Group . Select the classes you want to add to the config group. Choose a meaningful Name for the Puppet config group. Add selected Puppet classes to the Included Classes field. Click Submit to save the changes.

Commands:
5.3. Transport Security Authentication Modes The following authentication modes are available: anonymous No certificates are exchanged. Settings are not needed for the keystore and truststore properties. The client must have org.teiid.ssl.allowAnon set to true (the default) to connect to an anonymous server. Communications are encrypted using the TLS_DH_anon_WITH_AES_128_CBC_SHA SSL cipher suite. This is suitable for most secure intranets. Important Anonymous SSL fails to work if you are using IBM's JDK. 1-way Athenticates the server to the client. The server presents a certificate which is signed by the private key stored in the server's keystore. The server's corresponding public key must be in the client's truststore. 2-way Mutual client and server authentication. The server presents a certificate which is signed by the private key stored in the server's keystore. The server's corresponding public key must be in the client's truststore. Additionally, the client presents a certificate signed by its private key stored in the client's keystore. The client's corresponsing public key must be in the server's truststore. Note You can use keytool to generate encryption keys; however, you should first consider your local requirements for managing public key cryptography. See Also: Section 7.1, "Keytool"

Commands:
5.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. By default, mounted NFS volumes on the client side are labeled with a default context defined by policy for NFS. In common policies, this default context uses the nfs_t type. The following types are used with NFS. Different types allow you to configure flexible access: var_lib_nfs_t This type is used for existing and new files copied to or created in the /var/lib/nfs/ directory. This type should not need to be changed in normal operation. To restore changes to the default settings, run the restorecon -R -v /var/lib/nfs command as the root user. nfsd_exec_t The /usr/sbin/rpc.nfsd file is labeled with the nfsd_exec_t , as are other system executables and libraries related to NFS. Users should not label any files with this type. nfsd_exec_t will transition to nfsd_t .

Commands:
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the AMQ Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2022-04-13 17:49:00 UTC

Commands:
Chapter 2. Installation This chapter guides you through the steps to install AMQ Core Protocol JMS in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ Core Protocol JMS, you must install Apache Maven . To use AMQ Core Protocol JMS, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.apache.activemq</groupId> <artifactId>artemis-jms-client</artifactId> <version>2.11.0.redhat-00005</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ Core Protocol JMS can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Broker 7.7.0 Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.7.0-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" . 2.4. Installing the examples Procedure Use your subscription to download the AMQ Broker 7.7.0 .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.7.0.zip On Windows, right-click the .zip file and select Extract All . When you extract the contents of the .zip file, a directory named amq-broker-7.7.0 is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document.

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.apache.activemq</groupId> <artifactId>artemis-jms-client</artifactId> <version>2.11.0.redhat-00005</version> </dependency>
unzip amq-broker-7.7.0-maven-repository.zip
unzip amq-broker-7.7.0.zip
8.31. dovecot 8.31.1. RHBA-2013:1736 - dovecot bug fix update Updated dovecot packages that fix one bug are now available for Red Hat Enterprise Linux 6. Dovecot is an IMAP server for Linux and other UNIX-like systems, primarily written with security in mind. It also contains a small POP3 server. It supports e-mail in either the maildir or mbox format. The SQL drivers and authentication plug-ins are provided as sub-packages. Bug Fix BZ# 1010279 Because of a bug in dovecot's SSL parameters generator, installation of Red Hat Enterprise Linux 6 with FIPS mode enabled could become unresponsive when installing the dovecot package. This problem has been fixed and the installation now completes successfully in the described scenario. Users of dovecot are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.13. Fujitsu-Siemens RemoteView Service Board (RSB) Table 4.14, "Fujitsu Siemens Remoteview Service Board (RSB)" lists the fence device parameters used by fence_rsb , the fence agent for Fujitsu-Siemens RemoteView Service Board (RSB). Table 4.14. Fujitsu Siemens Remoteview Service Board (RSB) luci Field cluster.conf Attribute Description Name name A name for the RSB to use as a fence device. IP Address or Hostname ipaddr The host name assigned to the device. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. TCP Port ipport The port number on which the telnet service listens. The default value is 3172. Force Command Prompt cmd_prompt The command prompt to use. The default value is '\USD'. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Delay (seconds) delay The number of seconds to wait before fencing is started. The default value is 0. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Figure 4.10, "Fujitsu-Siemens RSB" shows the configuration screen for adding an Fujitsu-Siemens RSB fence device. Figure 4.10. Fujitsu-Siemens RSB The following command creates a fence device instance for a Fujiitsu-Siemens RSB device: The following is the cluster.conf entry for the fence_rsb device:

Commands:
ccs -f cluster.conf --addfencedev fsrbtest1 agent=fence_rsb ipaddr=192.168.0.1 login=root passwd=password123 telnet_port=3172
<fencedevices> <fencedevice agent="fence_rsb" ipaddr="192.168.0.1" login="root" name="fsrsbtest1" passwd="password123" telnet_port="3172"/> </fencedevices>
Chapter 1. About Serverless 1.1. {ServerlessProductName} overview OpenShift Serverless provides Kubernetes native building blocks that enable developers to create and deploy serverless, event-driven applications on OpenShift Container Platform. OpenShift Serverless is based on the open source Knative project , which provides portability and consistency for hybrid and multi-cloud environments by enabling an enterprise-grade serverless platform. Note Because OpenShift Serverless releases on a different cadence from OpenShift Container Platform, the OpenShift Serverless documentation is now available as separate documentation sets for each minor version of the product. The OpenShift Serverless documentation is available at https://docs.openshift.com/serverless/ . Documentation for specific versions is available using the version selector drop-down list, or directly by adding the version to the URL, for example, https://docs.openshift.com/serverless/1.28 . In addition, the OpenShift Serverless documentation is also available on the Red Hat Customer Portal at https://access.redhat.com/documentation/en-us/red_hat_openshift_serverless/ . For additional information about the OpenShift Serverless life cycle and supported platforms, refer to the Platform Life Cycle Policy . 1.1.1. Additional resources Extending the Kubernetes API with custom resource definitions Managing resources from custom resource definitions What is serverless?

Commands:
Appendix A. Revision History Revision History Revision 7.1-1 Wed Aug 7 2019 Steven Levine Document version for 7.7 GA publication. Revision 6.1-1 Thu Oct 4 2018 Steven Levine Document version for 7.6 GA publication. Revision 5.1-1 Thu Mar 15 2018 Steven Levine Document version for 7.5 GA publication. Revision 5.1-0 Wed Dec 13 2017 Steven Levine Document version for 7.5 Beta publication. Revision 4.0-6 Wed Jul 19 2017 Steven Levine Document version for 7.4 GA publication. Revision 4.0-3 Wed May 10 2017 Steven Levine Preparing document for 7.4 Beta publication Revision 0.4-5 Wed Nov 16 2016 Steven Levine Small update to 7.3 version Revision 0.4-3 Mon Oct 24 2016 Steven Levine Version for 7.3 GA publication Revision 0.4-1 Mon Aug 15 2016 Steven Levine Preparing document for 7.3 Beta publication Revision 0.3-6 Mon Nov 9 2015 Steven Levine Preparing document for 7.2 GA publication Revision 0.3-3 Wed Aug 19 2015 Steven Levine Preparing document for 7.2 Beta publication. Revision 0.2-7 Mon Feb 16 2015 Steven Levine Version for 7.1 GA release Revision 0.2-6 Thu Dec 11 2014 Steven Levine Version for 7.1 Beta release Revision 0.1-22 Mon Jun 2 2014 Steven Levine Version for 7.0 GA release Revision 0.1-10 Wed Apr 9 2014 Steven Levine 7.0 Beta update Revision 0.1-3 Tue Nov 26 2013 Steven Levine Version for 7.0 pre-Beta Revision 0.1-1 Wed Jan 16 2013 Steven Levine Branched from the Red Hat Enterprise Linux 6 version of the document

Commands: