mtpti5iD/redhat-docs_dataset huggingface dataset:
9.2. Restoring a Backup If you have a directory with a backup created using ipa-backup , you can restore your IdM server or the LDAP content to the state in which they were when the backup was performed. You cannot restore a backup on a host different from the host on which the backup was originally created. Note Uninstalling an IdM server does not automatically remove the backup of this server. 9.2.1. Restoring from the Full-Server or Data-Only Backup Important It is recommended that you uninstall a server before performing a full-server restore on it. Both full-server and data-only backups are restored using the ipa-restore utility which must always be run as root. Pass the backup to the command: Pass only the name of the directory with the backup if it is located in the default /var/lib/ipa/backup/ directory. Pass the full path to the backup if the directory containing the backup is not located in the default directory. For example: The ipa-restore utility automatically detects what type of backup the backup directory contains and by default performs the same type of restore. You can add the following options to ipa-restore : --data performs a data-only restore from a full-server backup, that is, restores only the LDAP data component from a backup directory containing the full-server backup --online restores the LDAP data in a data-only restore online --instance specifies which 389 DS instance is restored. IdM in Red Hat Enterprise Linux 7 only uses the IPA-REALM instance, but it might be possible, for example, to create a backup on a system with separate instances; in such cases, --instance allows you to restore only IPA-REALM . For example: You can use this option only when performing a data-only restore. --backend specifies which back end is restored; without this option, ipa-restore restores all back ends it discovers. The arguments defining the possible back ends are userRoot , which restores the IPA data back end, and ipaca , which restores the CA back end. You can use this option only when performing a data-only restore. --no-logs restores the backup without restoring the log files To avoid authentication problems on an IdM master, clear the SSSD cache after a restore: Stop the SSSD service: Remove all cached content from SSSD: Start the SSSD service: Note It is recommended that you reboot your system after restoring from backup. For further information on using ipa-restore , see the ipa-restore (1) man page. 9.2.2. Restoring with Multiple Master Servers For details about restoring IdM in a multi-master replication environment, see " Backup and Restore in IdM ". 9.2.3. Restoring from an Encrypted Backup If you want to restore from a backup encrypted with GPG, provide the full path to the private and public keys using the --gpg-keyring option. For example:

Commands:
ipa-restore /path/to/backup
ipa-restore --instance=IPA-REALM /path/to/backup
systemctl stop sssd
find /var/lib/sss/ ! -type d | xargs rm -f
systemctl start sssd
ipa-restore --gpg-keyring=/root/backup /path/to/backup
9.4. Additional Resources For more information about PackageKit, see the resources listed below. Installed Documentation gpk-application(1) - The manual page containing information about the gpk-application command. gpk-backend-status(1) - The manual page containing information about the gpk-backend-status command. gpk-install-local-file(1) - The manual page containing information about the gpk-install-local-file command. gpk-install-mime-type(1) - The manual page containing information about the gpk-install-mime-type command. gpk-install-package-name(1) - The manual page containing information about the qpk-install-package-name command. gpk-install-package-name(1) - The manual page containing information about the gpk-install-package-name command. gpk-prefs(1) - The manual page containing information about the gpk-prefs command. gpk-repo(1) - The manual page containing information about the gpk-repo command. gpk-update-icon(1) - The manual page containing information about the gpk-update-icon command. gpk-update-viewer(1) - The manual page containing information about the gpk-update-viewer command. pkcon(1) and pkmon(1) - The manual pages containing information about the PackageKit console client. pkgenpack(1) - The manual page containing information about the PackageKit Pack Generator. Online Documentation PackageKit home page - The PackageKit home page listing detailed information about the PackageKit software suite. PackageKit FAQ - An informative list of Frequently Asked Questions for the PackageKit software suite. See Also Chapter 8, Yum documents Yum, the Red Hat package manager.

Commands:
7.2. Installing from a Different Source You can install Red Hat Enterprise Linux from the ISO images stored on hard disk, or from a network using NFS, FTP, HTTP, or HTTPS methods. Experienced users frequently use one of these methods because it is often faster to read data from a hard disk or network server than from a DVD. The following table summarizes the different boot methods and recommended installation methods to use with each: Table 7.1. Boot methods and installation sources Boot method Installation source Installation DVD DVD, network, or hard disk Installation USB flash drive Installation DVD, network, or hard disk Minimal boot CD or USB, rescue CD Network or hard disk Refer to Section 3.7, "Selecting an Installation Method" for information about installing from locations other than the media with which you booted the system.

Commands:
Chapter 15. Preparing network functions virtualization (NFV) If you use network functions virtualization (NFV), you must complete some preparation for the overcloud upgrade. 15.1. Network functions virtualization (NFV) environment files In a typical NFV-based environment, you can enable services such as the following: Single-root input/output virtualization (SR-IOV) Data Plane Development Kit (DPDK) You do not require any specific reconfiguration to these services to accommodate the upgrade to Red Hat OpenStack Platform 16.2. However, ensure that the environment files that enable your NFV functionality meet the following requirements: The default environment files to enable NFV features are located in the environments/services directory of the Red Hat OpenStack Platform 16.2 openstack-tripleo-heat-templates collection. If you include the default NFV environment files from openstack-tripleo-heat-templates with your Red Hat OpenStack Platform 13 deployment, verify the correct environment file location for the respective feature in Red Hat OpenStack Platform 16.2: Open vSwitch (OVS) networking and SR-IOV: /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml Open vSwitch (OVS) networking and DPDK: /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml To maintain OVS compatibility during the upgrade from Red Hat OpenStack Platform 13 to Red Hat OpenStack Platform 16.2, you must include the /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml environment file. When running deployment and upgrade commands that involve environment files, you must include any NFV-related environment files after the neutron-ovs.yaml file. For example, when running openstack overcloud upgrade prepare with OVS and NFV environment files, include the files in the following order: The OVS environment file The SR-IOV environment file The DPDK environment file Note During an upgrade, you can migrate instances between RHOSP 13 and RHOSP 16.2 Compute nodes only when the RHOSP 13 Compute nodes are in the hybrid state. For more information, see Migration constraints in the Configuring the Compute Service for Instance Creation guide. There is an additional migration constraint for NFV workloads: you cannot live migrate instances from OVS-DPDK Compute nodes during an upgrade. Alternatively, you can cold migrate instances from OVS-DPDK Compute nodes during an upgrade.

Commands:
openstack overcloud upgrade prepare -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml
Chapter 5. Enabling notifications and integrations You can enable the notifications service on Red Hat Hybrid Cloud Console to send notifications whenever the advisor service detects an issue and generates a recommendation. Using the notifications service frees you from having to continually check the Red Hat Insights for RHEL dashboard for recommendations. For example, you can configure the notifications service to automatically send an email message whenever the advisor service generates a recommendation. 5.1. Requirements for enabling notifications Enabling the notifications service requires three main steps: First, an Organization Administrator creates a User access group with the Notifications administrator role, and then adds account members to the group. , a Notifications administrator sets up behavior groups for events in the notifications service. Behavior groups specify the delivery method for each notification. For example, a behavior group can specify whether email notifications are sent to all users, or just to Organization administrators. Finally, users who receive email notifications from events must set their user preferences so that they receive individual emails for each event. In addition to sending email messages, you can configure the notifications service to send event data in other ways: Using an authenticated client to query Red Hat Insights APIs for event data Using webhooks to send events to third-party applications that accept inbound requests Integrating notifications with applications such as Splunk to route advisor recommendations to the application dashboard Additional resources For more information about how to set up notifications for Advisor recommendations, see Configuring notifications on the Red Hat Hybrid Cloud Console with FedRAMP and Integrating the Red Hat Hybrid Cloud Console with third-party applications .

Commands:
Chapter 6. Installing RHTAP in your cluster Once you have created a GitHub application and a private values.yaml file, you are ready to install RHTAP. The actual installation process is quite simple. Prerequisites ClusterAdmin access to OCP cluster via CLI A private-values.yaml file (generated during the procedure) Procedure In your CLI, access your OCP cluster as ClusterAdmin. Add the installer Helm repository to your local system. If you already added this Helm repository earlier, update your Helm repositories. In the directory where you ran bin/make.sh , run the install command. Installation may take ten minutes or longer to complete. Note After --namespace you can specify any namespace you want; you do not have to use rhtap . Once installation is complete, the installer provides output. Label and save the PipelineRun file that the installer generates in ~/install_values.txt . Copy and paste the entire PipelineRun, from cat << EOF | kubectl create to EOF , into your command line. Press enter to execute this PipelineRun. Once the PipelineRun completes, it provides output which includes a link. If you are not already logged into the OpenShift web console, login first. Then open the link from the PipelineRun output. Troubleshooting If Helm is unable to successfully install RHTAP for any reason, try deleting the rhatp project in your cluster, and running the install command again.

Commands:
oc login [cluster address] -u kubeadmin -p [password]
helm repo add openshift-helm-charts https://charts.openshift.io/
helm repo update
helm upgrade installer openshift-helm-charts/redhat-trusted-application-pipeline --install --create-namespace --namespace rhtap --timeout 20m --values private-values.yaml
E.5.3. The Root File System and GRUB The use of the term root file system has a different meaning in regard to GRUB. It is important to remember that GRUB's root file system has nothing to do with the Linux root file system. The GRUB root file system is the top level of the specified device. For example, the image file (hd0,0)/grub/splash.xpm.gz is located within the /grub/ directory at the top-level (or root) of the (hd0,0) partition (which is actually the /boot/ partition for the system). , the kernel command is executed with the location of the kernel file as an option. Once the Linux kernel boots, it sets up the root file system that Linux users are familiar with. The original GRUB root file system and its mounts are forgotten; they only existed to boot the kernel file. Refer to the root and kernel commands in Section E.7, "GRUB Commands" for more information.

Commands:
Chapter 16. Configuring GNOME to store user settings on home directories hosted on an NFS share If you use GNOME on a system with home directories hosted on an NFS server, you must change the keyfile backend of the dconf database. Otherwise, dconf might not work correctly. This change affects all users on the host because it changes how dconf manages user settings and configurations stored in the home directories. Procedure Add the following line to the beginning of the /etc/dconf/profile/user file. If the file does not exist, create it. With this setting, dconf polls the keyfile back end to determine whether updates have been made, so settings might not be updated immediately. The changes take effect when the users logs out and in.

Commands:
service-db:keyfile/user
8.116. microcode_ctl 8.116.1. RHBA-2013:1668 - microcode_ctl bug fix and enhancement update Updated microcode_ctl packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The microcode_ctl packages provide utility code and microcode data to assist the kernel in updating the CPU microcode at system boot time. This microcode supports all current x86-based, Intel 64-based, and AMD64-based CPU models. It takes advantage of the mechanism built-in to Linux that allows microcode to be updated after system boot. When loaded, the updated microcode corrects the behavior of various processors, as described in processor specification updates issued by Intel and AMD for those processors. Bug Fix BZ# 1000317 Previously, the microcode_ctl utility did not detect if it was running in a virtual machine and attempted to install the CPU microcode updates. This behavior caused several errors to be returned in the kernel ring buffer. The underlying source code has been modified and microcode_ctl no longer tries to update the CPU microcode in the described scenario. Enhancement BZ# 915957 , BZ# 1005606 The Intel CPU microcode file has been updated to version 20130906. All users of microcode_ctl are advised to upgrade to these updated packages, which fix this bug and add this enhancement. Note: a system reboot is necessary for this update to take effect.

Commands:
Chapter 13. Setting terms and conditions When you allow developers to sign up for your API, you will probably want to get them to agree to your Terms and Conditions to make some of your policies clear before you grant them access. There may be different versions of your Terms and Conditions you want developers to abide by. These are easy to set up at different points throughout the registration process. For example: Signup Terms and Conditions. Application Terms and Conditions. Service/subscription Terms and Conditions. Only available when you have multiple services. Additionally, if you are charging for use of your API, you may want to make your credit card policies explicit. 3scale provides an easy way to set up the following kinds of credit card policy URLs: Legal Terms Privacy Refunds 13.1. Terms and conditions This part of the workflow is easy to set up in the Admin Portal by following the steps below. Go to Audience > Developer Portal > Signup , where you will be presented with a blank page to populate with your signup legal terms. You can use any combination of HTML, JavaScript, and CSS. There is also some toggling code provided by clicking Insert toggling code. The content you write in this box will appear just above the Sign Up button on the Signup page of your Developer Portal. Once you have filled out your Terms and Conditions, save them by clicking Update. If you have used the toggling code, it will display "By signing up you agree to the following Legal Terms and Conditions" followed by a link that toggles between showing and hiding the Terms and Conditions you specified. This is placed on the Signup page by default, but it is a partial (signup_licence) that can be included anywhere on your Developer Portal. To remove this from the Signup page, simply remove the {% include 'signup_licence' %} line from the page. Similarly, if you want to include it somewhere else, you can use the same partial by means of the snippet, which can be placed anywhere on your Developer Portal. You might also want your users to accept another set of Terms and Conditions when they create a new application ( new_application_licence partial) and/or when they subscribe to a new service ( service_subscription_licence partial). To set these up, you can follow the same procedure outlined above. 13.2. Credit card policies You can also define other URLs where different policies reside. Set them up by going to Audience > Billing > Credit Card Policies and setting the path where your policy pages will be located. In order for these links to work, you will then need to create new pages in the Developer Portal. Once that is done, you can reference them using the URL's liquid drop. For example: <a href="{{ urls.credit_card_terms }}">Legal Terms</a> <a href="{{ urls.credit_card_privacy }}">Privacy</a> <a href="{{ urls.credit_card_refunds }}">Refunds</a>

Commands:
<a href="{{ urls.credit_card_terms }}">Legal Terms</a> <a href="{{ urls.credit_card_privacy }}">Privacy</a> <a href="{{ urls.credit_card_refunds }}">Refunds</a>
Chapter 208. Kubernetes Secrets Component Available as of Camel version 2.17 The Kubernetes Secrets component is one of Kubernetes Components which provides a producer to execute kubernetes secret operations. 208.1. Component Options The Kubernetes Secrets component has no options. 208.2. Endpoint Options The Kubernetes Secrets endpoint is configured using URI syntax: with the following path and query parameters: 208.2.1. Path Parameters (1 parameters): Name Description Default Type masterUrl Required Kubernetes API server URL String 208.2.2. Query Parameters (20 parameters): Name Description Default Type apiVersion (producer) The Kubernetes API Version to use String dnsDomain (producer) The dns domain, used for ServiceCall EIP String kubernetesClient (producer) Default KubernetesClient to use if provided KubernetesClient operation (producer) Producer operation to do on Kubernetes String portName (producer) The port name, used for ServiceCall EIP String portProtocol (producer) The port protocol, used for ServiceCall EIP tcp String connectionTimeout (advanced) Connection timeout in milliseconds to use when making requests to the Kubernetes API server. Integer synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean caCertData (security) The CA Cert Data String caCertFile (security) The CA Cert File String clientCertData (security) The Client Cert Data String clientCertFile (security) The Client Cert File String clientKeyAlgo (security) The Key Algorithm used by the client String clientKeyData (security) The Client Key data String clientKeyFile (security) The Client Key file String clientKeyPassphrase (security) The Client Key Passphrase String oauthToken (security) The Auth Token String password (security) Password to connect to Kubernetes String trustCerts (security) Define if the certs we used are trusted anyway or not Boolean username (security) Username to connect to Kubernetes String 208.3. Spring Boot Auto-Configuration The component supports 2 options, which are listed below. Name Description Default Type camel.component.kubernetes-secrets.enabled Whether to enable auto configuration of the kubernetes-secrets component. This is enabled by default. Boolean camel.component.kubernetes-secrets.resolve-property-placeholders Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true Boolean

Commands:
kubernetes-secrets:masterUrl
4.2.3. Preventing Allocation on a Physical Volume You can prevent allocation of physical extents on the free space of one or more physical volumes with the pvchange command. This may be necessary if there are disk errors, or if you will be removing the physical volume. The following command disallows the allocation of physical extents on /dev/sdk1 . You can also use the -xy arguments of the pvchange command to allow allocation where it had previously been disallowed.

Commands:
pvchange -x n /dev/sdk1
Chapter 4. Red Hat Process Automation Manager supported repositories You can use Git repositories and Apache Maven with Red Hat Process Automation Manager. 4.1. Git repositories Git repositories are used internally within Business Central to store all processes, rules, and other artifacts that are created in the authoring environment. Git is a distributed version control system. It implements revisions as commit objects. When you commit your changes into a repository, a new commit object in the Git repository is created. When you create a project in Business Central, it is added to the Git repository that is connected to Business Central. If you have projects in other Git repositories, you can import them into Business Central spaces. You can use Git hooks to synchronize the internal Git repositories with external repositories. 4.2. Apache Maven Apache Maven is a distributed build automation tool used in Java application development to build and manage software projects. You can use Maven to build, publish, and deploy your Red Hat Process Automation Manager projects. Maven provides the following benefits: The build process is easy and a uniform build system is implemented across projects. All of the required JAR files for a project are made available at compile time. A proper project structure is configured. Dependencies and versions are well managed. There is no need for additional build processing because Maven builds output into a number of predefined types, such as JAR and WAR. Maven uses repositories to store Java libraries, plug-ins, and other build artifacts. These repositories can be local or remote. Red Hat Process Automation Manager maintains local and remote maven repositories that you can add to your project for accessing the rules, processes, events, and other project dependencies. When building projects and archetypes, Maven dynamically retrieves Java libraries and Maven plug-ins from local or remote repositories. Doing this promotes sharing and reuse of dependencies across projects.

Commands: