mtpti5iD/redhat-docs_dataset huggingface dataset:
16.2.3. Starting and Stopping the Server Important When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. Use the command touch /var/lib/dhcpd/dhcpd.leases to create the file if it does not exist. If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file. To start the DHCP service, use the command /sbin/service dhcpd start . To stop the DHCP server, use the command /sbin/service dhcpd stop . By default, the DHCP service does not start at boot time. For information on how to configure the daemon to start automatically at boot time, see Chapter 12, Services and Daemons . If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd , add the name of the interface to the list of DHCPDARGS : This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users cannot connect to the daemon through the Internet. Other command-line options that can be specified in /etc/sysconfig/dhcpd include: -p <portnum> - Specifies the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responds to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. See Section 16.2.4, "DHCP Relay Agent" for details. -f - Runs the daemon as a foreground process. This is mostly used for debugging. -d - Logs the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages . -cf <filename> - Specifies the location of the configuration file. The default location is /etc/dhcp/dhcpd.conf . -lf <filename> - Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcpd/dhcpd.leases . -q - Do not print the entire copyright message when starting the daemon.

Commands:
Command line options here DHCPDARGS=eth0
Preface For OpenShift Data Foundation, node replacement can be performed proactively for an operational node and reactively for a failed node for the following deployments: For Amazon Web Services (AWS) User-provisioned infrastructure Installer-provisioned infrastructure For VMware User-provisioned infrastructure Installer-provisioned infrastructure For Microsoft Azure Installer-provisioned infrastructure For local storage devices Bare metal VMware IBM Power For replacing your storage nodes in external mode, see Red Hat Ceph Storage documentation .

Commands:
Chapter 12. Deploying IPv6 on Red Hat Quay on OpenShift Container Platform Note Currently, deploying IPv6 on the Red Hat Quay on OpenShift Container Platform is not supported on IBM Power and IBM Z. Your Red Hat Quay on OpenShift Container Platform deployment can now be served in locations that only support IPv6, such as Telco and Edge environments. For a list of known limitations, see IPv6 limitations 12.1. Enabling the IPv6 protocol family Use the following procedure to enable IPv6 support on your Red Hat Quay deployment. Prerequisites You have updated Red Hat Quay to at least version 3.8. Your host and container software platform (Docker, Podman) must be configured to support IPv6. Procedure In your deployment's config.yaml file, add the FEATURE_LISTEN_IP_VERSION parameter and set it to IPv6 , for example: # ... FEATURE_GOOGLE_LOGIN: false FEATURE_INVITE_ONLY_USER_CREATION: false FEATURE_LISTEN_IP_VERSION: IPv6 FEATURE_MAILING: false FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: false # ... Start, or restart, your Red Hat Quay deployment. Check that your deployment is listening to IPv6 by entering the following command: USD curl <quay_endpoint>/health/instance {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200} After enabling IPv6 in your deployment's config.yaml , all Red Hat Quay features can be used as normal, so long as your environment is configured to use IPv6 and is not hindered by the IPv6 and dual-stack limitations . Warning If your environment is configured to IPv4, but the FEATURE_LISTEN_IP_VERSION configuration field is set to IPv6 , Red Hat Quay will fail to deploy. 12.2. IPv6 limitations Currently, attempting to configure your Red Hat Quay deployment with the common Microsoft Azure Blob Storage configuration will not work on IPv6 single stack environments. Because the endpoint of Microsoft Azure Blob Storage does not support IPv6, there is no workaround in place for this issue. For more information, see PROJQUAY-4433 . Currently, attempting to configure your Red Hat Quay deployment with Amazon S3 CloudFront will not work on IPv6 single stack environments. Because the endpoint of Amazon S3 CloudFront does not support IPv6, there is no workaround in place for this issue. For more information, see PROJQUAY-4470 .

Commands:
FEATURE_GOOGLE_LOGIN: false FEATURE_INVITE_ONLY_USER_CREATION: false FEATURE_LISTEN_IP_VERSION: IPv6 FEATURE_MAILING: false FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: false
curl <quay_endpoint>/health/instance {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200}
9.3. Configuring Publishing to an OCSP The general process to configure publishing involves setting up a publisher to publish the certificates or CRLs to the specific location. There can be a single publisher or multiple publishers, depending on how many locations will be used. The locations can be split by certificates and CRLs or finer definitions, such as certificate type. Rules determine which type to publish and to what location by being associated with the publisher. Publishing to an OCSP Manager is a way to publish CRLs to a specific location for client verification. A publisher must be created and configured for each publishing location; publishers are not automatically created for publishing to the OCSP responder. Create a single publisher to publish everything to s single location, or create a publisher for every location to which CRLs will be published. Each location can contain a different kind of CRL. 9.3.1. Enabling Publishing to an OCSP with Client Authentication Log into the Certificate Manager Console. In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing , and then Publishers . Click Add to open the Select Publisher Plug-in Implementation window, which lists registered publisher modules. Select the OCSPPublisher module, then open the editor window. This is the publisher module that enables the Certificate Manager to publish CRLs to the Online Certificate Status Manager. The publisher ID must be an alphanumeric string with no spaces, like PublishCertsToOCSP . The host can be the fully-qualified domain name, such as ocspResponder.example.com , or an IPv4 or IPv6 address. The default path is the directory to send the CRL to, like /ocsp/agent/ocsp/addCRL . If client authentication is used ( enableClientAuth is checked), then the nickname field gives the nickname of the certificate to use for authentication. This certificate must already exist in the OCSP security database; this will usually be the CA subsystem certificate. Create a user entry for the CA on the OCSP Manager. The user is used to authenticate to the OCSP when sending a new CRL. There are two things required: Name the OCSP user entry after the CA server, like CA- hostname-EEport . Use whatever certificate was specified in the publisher configuration as the user certificate in the OCSP user account. This is usually the CA's subsystem certificate. Setting up subsystem users is covered in Section 15.3.2.1, "Creating Users" . After configuring the publisher, configure the rules for the published certificates and CRLs, as described in Section 9.5, "Creating Rules" . Note pkiconsole is being deprecated.

Commands:
pkiconsole https://server.example.com:8443/ca
Appendix E. Swift response headers The response from the server should include an X-Auth-Token value. The response might also contain a X-Storage-Url that provides the API_VERSION / ACCOUNT prefix that is specified in other requests throughout the API documentation. Table E.1. Response Headers Name Description Type X-Storage-Token The authorization token for the X-Auth-User specified in the request. String X-Storage-Url The URL and API_VERSION / ACCOUNT path for the user. String

Commands:
Chapter 5. Locked-down, secure Firefox in a container This section explains how to deploy a secure container that runs Firefox. This container gives you an instance of Firefox, containerized, with the following features: Completely unprivileged - needs no extra SELinux tweaking Only the list of cgroups is passed into the container from the host No port redirection because the container is available only to the host No X11 clipboard events or X events shared with your real host No shared sound hardware Everything runs with normal, non-elevated user permissions except for systemd (and systemd runs only to reap the other processes) unsynced sound, flash, and interactivity. Running Firefox Securely in a Container Retrieve the base image that we use to build this container: Load the base image you just downloaded into the local Docker registry: Create a directory to hold the Dockerfile that will map out this container: Retrieve the Dockerfile by using this curl command: Build the container and tag it with a tag called isolated_firefox : Run the container: Retrieve the CONTAINER_ID by using the docker ps command: Retrieve the IP address of the container: Open the container in vncviewer: To hear the audio associated with this container, open a browser and go to the following location: Note Do not forget to include the port in the URL. That means that you should not forget to type :8000 after the URL. You can also send the address of the container to VLC to play the content in VLC. Run the following command to launch the VLC instance:

Commands:
curl -o Fedora-Docker-Base-22-20150521.x86_64.tar.xz -L https://download.fedoraproject.org/pub/fedora/linux/releases/22/Docker/x86_64/Fedora-Docker-Base-22-20150521.x86_64.tar.xz
sudo docker load < Fedora-Docker-Base-22-20150521.x86_64.tar.xz
mkdir -p isolated_firefox
curl -o isolated_firefox/Dockerfile -L http://pastebin.com/raw.php?i=cgYXQvJu
sudo docker build -t isolated_firefox isolated_firefox .
sudo docker run -v /sys/fs/cgroup:/sys/fs/cgroup:ro isolated_firefox
sudo docker ps
sudo docker inspect CONTAINER_ID| grep IPAddress\":
vncviewer CONTAINER_IP
http://CONTAINER_IP:8000/firefox.ogg
vlc http://CONTAINER_IP:8000/firefox.ogg
Providing feedback on Red Hat documentation We appreciate and prioritize your feedback regarding our documentation. Provide as much detail as possible, so that your request can be quickly addressed. Prerequisites You are logged in to the Red Hat Customer Portal. Procedure To provide feedback, perform the following steps: Click the following link: Create Issue Describe the issue or enhancement in the Summary text box. Provide details about the issue or requested enhancement in the Description text box. Type your name in the Reporter text box. Click the Create button. This action creates a documentation ticket and routes it to the appropriate documentation team. Thank you for taking the time to provide feedback.

Commands:
Chapter 52. EntityOperatorSpec schema reference Used in: KafkaSpec Property Property type Description topicOperator EntityTopicOperatorSpec Configuration of the Topic Operator. userOperator EntityUserOperatorSpec Configuration of the User Operator. tlsSidecar TlsSidecar The tlsSidecar property has been deprecated. TLS sidecar was removed in Streams for Apache Kafka 2.8. This property is ignored. TLS sidecar configuration. template EntityOperatorTemplate Template for Entity Operator resources. The template allows users to specify how a Deployment and Pod is generated.

Commands:
8.240. xorg-x11-drv-nouveau 8.240.1. RHBA-2013:1664 - xorg-x11-drv-nouveau bug fix update Updated xorg-x11-drv-nouveau packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-nouveau packages provide the X.Org X11 noveau video driver for NVIDIA graphics chipsets. Bug Fix BZ# 876566 Previously, when using a VGA-compatible controller for certain NVIDIA Quadro graphics cards, the rendercheck test suite was not able to perform the complete check due to rendering problems. The xorg-x11-drv-nouveau packages have been fixed, rendering problems no longer occur, and the test suite completes the check as expected. Users of xorg-x11-drv-nouveau are advised to upgrade to these updated packages, which fix this bug.

Commands:
13.3.2. Let the Installer Prompt You for a Driver Update Begin the installation normally for whatever method you have chosen. If the installer cannot load drivers for a piece of hardware that is essential for the installation process (for example, if it cannot detect any network or storage controllers), it prompts you to insert a driver update disk: Figure 13.5. The no driver found dialog Select Use a driver disk and refer to Section 13.4, "Specifying the Location of a Driver Update Image File or a Driver Update Disk" .

Commands:
Backup and restore Red Hat Advanced Cluster Security for Kubernetes 4.5 Backing up and restoring Red Hat Advanced Cluster Security for Kubernetes Red Hat OpenShift Documentation Team

Commands:
export ROX_API_TOKEN=<api_token>
export ROX_ENDPOINT=<address>:<port_number>
roxctl central backup 1
export ROX_ENDPOINT=<address>:<port_number>
roxctl -p <admin_password> central backup 1
oc get central -n _<central-namespace>_ _<central-name>_ -o yaml > central-cr.yaml
oc get secret -n _<central-namespace>_ central-tls -o json | jq 'del(.metadata.ownerReferences)' > central-tls.json
oc get secret -n _<central-namespace>_ central-htpasswd -o json | jq 'del(.metadata.ownerReferences)' > central-htpasswd.json
helm get values --all -n _<central-namespace>_ _<central-helm-release>_ -o yaml > central-values-backup.yaml
export ROX_API_TOKEN=<api_token>
export ROX_ENDPOINT=<address>:<port_number>
roxctl central db restore <backup_file> 1
export ROX_ENDPOINT=<address>:<port_number>
roxctl -p <admin_password> \ 1 central db restore <backup_file> 2
roxctl central generate interactive
Enter path to the backup bundle from which to restore keys and certificates (optional): _<backup-file-path>_
./central-bundle/central/scripts/setup.sh
oc create -R -f central-bundle/central
oc get pod -n stackrox -w
cat central-bundle/password
oc apply -f central-tls.json
oc apply -f central-htpasswd.json
oc apply -f central-cr.yaml
roxctl central generate k8s pvc --backup-bundle _<path-to-backup-file>_ --output-format "helm-values"
helm install -n stackrox --create-namespace stackrox-central-services rhacs/central-services -f central-values-backup.yaml -f central-bundle/values-private.yaml
B.80. rdesktop B.80.1. RHSA-2011:0506 - Moderate: rdesktop security update An updated rdesktop package that fixes one security issue is now available for Red Hat Enterprise Linux 5 and 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. rdesktop is a client for the Remote Desktop Server (previously, Terminal Server) in Microsoft Windows. It uses the Remote Desktop Protocol (RDP) to remotely present a user's desktop. CVE-2011-1595 A directory traversal flaw was found in the way rdesktop shared a local path with a remote server. If a user connects to a malicious server with rdesktop, the server could use this flaw to cause rdesktop to read and write to arbitrary, local files accessible to the user running rdesktop. Red Hat would like to thank Cendio AB for reporting this issue. Cendio AB acknowledges an anonymous contributor working with the SecuriTeam Secure Disclosure program as the original reporter. Users of rdesktop should upgrade to this updated package, which contains a backported patch to resolve this issue.

Commands:
Chapter 1. Overview of HawtIO HawtIO is a diagnostic Console for the Red Hat build of Apache Camel and Red Hat build of AMQ. It is a pluggable Web diagnostic console built with modern Web technologies such as React and PatternFly . HawtIO provides a central interface to examine and manage the details of one or more deployed HawtIO-enabled containers. HawtIO is available when you install HawtIO standalone or use HawtIO on OpenShift. The integrations that you can view and manage in HawtIO depend on the plugins that are running. You can monitor HawtIO and system resources, perform updates, and start or stop services. The pluggable architecture is based on Webpack Module Federation and is highly extensible; you can dynamically extend HawtIO with your plugins or automatically discover plugins inside the JVM. HawtIO has built-in plugins already to make it highly useful out of the box for your JVM application. The plugins include Apache Camel, Connect, JMX, Logs, Runtime, Quartz, and Spring Boot. HawtIO is primarily designed to be used with Camel Quarkus and Camel Spring Boot. It's also a tool for managing microservice applications. HawtIO is cloud-native; it's ready to go over the cloud! You can deploy it to Kubernetes and OpenShift with the HawtIO Operator . Benefits of HawtIO can be listed as follows: Runtime management of JVM via JMX, especially that of Camel applications and AMQ broker, with specialized views Visualization and debugging/tracing of Camel routes Simple managing and monitoring of application metrics

Commands:
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To provide feedback, you can highlight the text in a document and add comments. Follow the steps in the procedure to learn about submitting feedback on Red Hat documentation. Prerequisites Log in to the Red Hat Customer Portal. In the Red Hat Customer Portal, view the document in HTML format. Procedure Click Feedback to see existing reader comments. Note The feedback feature is enabled only in the HTML format. Highlight the section of the document where you want to provide feedback. In the prompt menu that displays near the text you selected, click Add Feedback . A text box opens in the feedback section on the right side of the page. Enter your feedback in the text box and click Submit . You have created a documentation issue. To view the issue, click the issue tracker link in the feedback view.

Commands:
Chapter 1. About Red Hat OpenShift Dev Spaces Red Hat OpenShift Dev Spaces provides web-based development environments on Red Hat OpenShift with an enterprise-level setup: Cloud Development Environments (CDE) server IDEs such as Microsoft Visual Studio Code - Open Source and JetBrains IntelliJ IDEA Community ( Technology Preview ) Containerized environments with popular programming languages, frameworks, and Red Hat technologies Red Hat OpenShift Dev Spaces is well-suited for container-based development. Red Hat OpenShift Dev Spaces 3.16 is based on Eclipse Che 7.90. 1.1. Supported platforms OpenShift Dev Spaces runs on OpenShift 4.12-4.16 on the following CPU architectures: AMD64 and Intel 64 ( x86_64 ) IBM Z ( s390x ) The following CPU architecture requires Openshift 4.13-4.16 to run OpenShift Dev Spaces: IBM Power ( ppc64le ) Additional resources OpenShift Documentation Red Hat OpenShift Dev Spaces administration guide 1.2. Support policy For Red Hat OpenShift Dev Spaces 3.16, Red Hat will provide support for deployment, configuration, and use of the product. Additional resources OpenShift Dev Spaces life-cycle and support policy . 1.3. Differences between Red Hat OpenShift Dev Spaces and Eclipse Che There are some differences between Red Hat OpenShift Dev Spaces and the upstream project on which it is based, Eclipse Che: OpenShift Dev Spaces is supported only on Red Hat OpenShift. OpenShift Dev Spaces is based on Red Hat Enterprise Linux and is regularly updated to include the latest security fixes. OpenShift Dev Spaces provides getting-started samples supported in the air-gap mode with languages and technologies such as Quarkus, Lombok, NodeJS, Python, DotNet, Golang, and C/C++. Community samples are available at the Devfile registry page . OpenShift Dev Spaces uses OpenShift OAuth for user login and management. Red Hat provides licensing and packaging to ensure enterprise-level support for OpenShift Dev Spaces.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ Core Protocol JMS examples require a running message broker with a queue named exampleQueue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named exampleQueue . USD <broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:31 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop