mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Backup and recovery of Red Hat Ansible Automation Platform To safeguard against unexpected data loss and application errors, it is critical that you perform periodic backups of your Red Hat Ansible Automation Platform deployment. In addition to data loss prevention, backups allow you to fall back to a different deployment state. 1.1. About backup and recovery Red Hat recommends backing up deployments of Red Hat Ansible Automation Platform in your Red Hat OpenShift Container Platform environment to prevent data loss. A backup resource of your Red Hat Ansible Automation Platform deployment includes the following: Custom deployment of specific values in the spec section of the Ansible Automation Platform custom resource object Back up of the postgresql database secret_key , admin_password , and broadcast_websocket secrets Database configuration Note Be sure to secure your backup resources because they can include sensitive information. 1.1.1. Backup recommendations Recovering from data loss requires that you plan for and create backup resources of your Red Hat Ansible Automation Platform deployments on a regular basis. At a minimum, Red Hat recommends backing up deployments of Red Hat Ansible Automation Platform under the following circumstances: Before upgrading your Red Hat Ansible Automation Platform deployments Before upgrading your Openshift cluster Once per week. This is particularly important if your environment is configured for automatic upgrades.

Commands:
1.7. Temporary Data You can encrypt the temporary data stored on the file system as configured by the BufferManager. Set the buffer-service-encrypt-files property to true on the Teiid subsystem to use 128-bit AES to encrypt any files written by the BufferManager. A new symmetric key will be generated for each start of the Teiid system on each server. A performance hit will be seen for processing that is memory intensive such that data typically spills to disk. This setting does not affect how VDBs (either the artifact or an exploded form) or log files are written to disk.

Commands:
8.5. Clustering JCache instances JBoss Data Grid implementation goes beyond the specification in order to provide the possibility to cluster caches using the standard API. Given a configuration file to replicate caches such as: It is possible to create a cluster of caches using this code: Report a bug

Commands:
<namedCache name="namedCache"> <clustering mode="replication"/> </namedCache>
import javax.cache.*; import java.net.URI; // For multiple cache managers to be constructed with the standard JCache API // and live in the same JVM, either their names, or their classloaders, must // be different. // This example shows how to force their classloaders to be different. // An alternative method would have been to duplicate the XML file and give // it a different name, but this results in unnecessary file duplication. ClassLoader tccl = Thread.currentThread().getContextClassLoader(); CacheManager cacheManager1 = Caching.getCachingProvider().getCacheManager( URI.create("infinispan-jcache-cluster.xml"), new TestClassLoader(tccl)); CacheManager cacheManager2 = Caching.getCachingProvider().getCacheManager( URI.create("infinispan-jcache-cluster.xml"), new TestClassLoader(tccl)); Cache<String, String> cache1 = cacheManager1.getCache("namedCache"); Cache<String, String> cache2 = cacheManager2.getCache("namedCache"); cache1.put("hello", "world"); String value = cache2.get("hello"); // Returns "world" if clustering is working // -- public static class TestClassLoader extends ClassLoader { public TestClassLoader(ClassLoader parent) { super(parent); } }
3.4. Configuring a Kerberos 5 Client All that is required to set up a Kerberos 5 client is to install the client packages and provide each client with a valid krb5.conf configuration file. While ssh and slogin are the preferred methods of remotely logging in to client systems, Kerberized versions of rsh and rlogin are still available, with additional configuration changes. Be sure that time synchronization is in place between the Kerberos client and the KDC and that DNS is working properly on the Kerberos client. Install the krb5-libs and krb5-workstation packages on all of the client machines. Supply a valid /etc/krb5.conf file for each client (usually this can be the same krb5.conf file used by the KDC). To use kerberized rsh and rlogin services, install the rsh package. Before a workstation can use Kerberos to authenticate users who connect using ssh , rsh , or rlogin , it must have its own host principal in the Kerberos database. The sshd , kshd , and klogind server programs all need access to the keys for the host service's principal. Using kadmin , add a host principal for the workstation on the KDC. The instance in this case is the hostname of the workstation. Use the -randkey option for the kadmin 's addprinc command to create the principal and assign it a random key: The keys can be extracted for the workstation by running kadmin on the workstation itself and using the ktadd command. To use other kerberized network services, install the krb5-server package and start the services. The kerberized services are listed in Table 3.3, "Common Kerberized Services" . Table 3.3. Common Kerberized Services Service Name Usage Information ssh OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have GSSAPIAuthentication enabled. If the client also has GSSAPIDelegateCredentials enabled, the user's credentials are made available on the remote system. rsh and rlogin Enable klogin , eklogin , and kshell . Telnet Enable krb5-telnet . FTP Create and extract a key for the principal with a root of ftp . Be certain to set the instance to the fully qualified hostname of the FTP server, then enable gssftp . IMAP The cyrus-imap package uses Kerberos 5 if it also has the cyrus-sasl-gssapi package installed. The cyrus-sasl-gssapi package contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP functions properly with Kerberos as long as the cyrus user is able to find the proper key in /etc/krb5.keytab , and the root for the principal is set to imap (created with kadmin ). An alternative to cyrus-imap can be found in the dovecot package, which is also included in Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support GSS-API and Kerberos. CVS gserver uses a principal with a root of cvs and is otherwise identical to the CVS pserver .

Commands:
addprinc -randkey host/server.example.com
ktadd -k /etc/krb5.keytab host/server.example.com
6.2. Securing the System Using SELinux Security-Enhanced Linux (SELinux) is an implementation of a mandatory access control mechanism in the Linux kernel, checking for allowed operations after standard discretionary access controls are checked. SELinux can enforce rules on files and processes in a Linux system, and on their actions, based on defined policies. In most cases, no actions are required to run Certificate System with SELinux in enforcing mode. If a procedure in the Certificate System documentation requires to manually set SELinux-related settings, such as when using a Hardware Security Module (HSM), it is mentioned in the corresponding section. For further details about SELinux, see the Using SELinux Guide . 6.2.1. Verifying if SELinux is Running in Enforcing Mode By default, after installing Red Hat Enterprise Linux, SELinux is enabled and running in enforcing mode and no further actions are required. To display the current SELinux mode, enter:

Commands:
getenforce
10.4. Starting and Stopping httpd The httpd RPM installs the /etc/init.d/httpd script, which can be accessed using the /sbin/service command. To start the server, as root type: To stop the server, as root type: The restart option is a shorthand way of stopping and then starting the Apache HTTP Server. To restart the server, as root type: Note If running the Apache HTTP Server as a secure server, it may be necessary to type the server password whenever using the start or restart options. After editing the httpd.conf file, however, it is not necessary to explicitly stop and start the server. Instead, use the reload option. To reload the server configuration file, as root type: Note If running the Apache HTTP Server as a secure server, the server password is not required when using the reload option. By default, the httpd service does not start automatically at boot time. To configure the httpd service to start up at boot time, use an initscript utility, such as /sbin/chkconfig , /usr/sbin/ntsysv , or the Services Configuration Tool program. Refer to the chapter titled Controlling Access to Services in System Administrators Guide for more information regarding these tools. Note If running the Apache HTTP Server as a secure server, the secure server's password is required after the machine boots when using an encrypted private SSL key. For information about setting up an Apache HTTP Secure Server, refer to the chapter titled Apache HTTP Secure Server Configuration in the System Administrators Guide .

Commands:
service httpd start
service httpd stop
service httpd restart
service httpd reload
16.11. Set the Root Password Setting up a root account and password is one of the most important steps during your installation. The root account is used to install packages, upgrade RPMs, and perform most system maintenance. Logging in as root gives you complete control over your system. Note The root user (also known as the superuser) has complete access to the entire system; for this reason, logging in as the root user is best done only to perform system maintenance or administration. Figure 16.32. Root Password Use the root account only for system administration. Create a non-root account for your general use and use the su command to change to root only when you need to perform tasks that require superuser authorization. These basic rules minimize the chances of a typo or an incorrect command doing damage to your system. Note To become root, type su - at the shell prompt in a terminal window and then press Enter . Then, enter the root password and press Enter . The installation program prompts you to set a root password [7] for your system. . You cannot proceed to the stage of the installation process without entering a root password. The root password must be at least six characters long; the password you type is not echoed to the screen. You must enter the password twice; if the two passwords do not match, the installation program asks you to enter them again. You should make the root password something you can remember, but not something that is easy for someone else to guess. Your name, your phone number, qwerty , password, root , 123456 , and anteater are all examples of bad passwords. Good passwords mix numerals with upper and lower case letters and do not contain dictionary words: Aard387vark or 420BMttNT , for example. Remember that the password is case-sensitive. If you write down your password, keep it in a secure place. However, it is recommended that you do not write down this or any password you create. Warning Do not use one of the example passwords offered in this manual. Using one of these passwords could be considered a security risk. To change your root password after you have completed the installation, run the passwd command as root . If you forget the root password, see Resolving Problems in System Recovery Modes in the Red Hat Enterprise Linux 6 Deployment Guide for instructions on how to set a new one. [7] A root password is the administrative password for your Red Hat Enterprise Linux system. You should only log in as root when needed for system maintenance. The root account does not operate within the restrictions placed on normal user accounts, so changes made as root can have implications for your entire system.

Commands:
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2023:4166 RHSA-2023:4167 RHSA-2023:4168 RHSA-2023:4172 RHSA-2023:4173 RHSA-2023:4174 RHSA-2023:4176 RHSA-2023:4178 RHSA-2023:4209 RHSA-2023:4212 Revised on 2024-05-10 09:06:19 UTC

Commands:
11.10. Function Options You can use the following options when creating functions. See "create procedure" in Section A.7, "Productions" . Any others properties defined will be considered as extension metadata. Property Data Type or Allowed Values Description UUID string unique Identifier NAMEINSOURCE If this is source function/procedure the name in the physical source, if different from the logical name given above ANNOTATION string Description of the function/procedure CATEGORY string Function Category DETERMINISM NONDETERMINISTIC COMMAND_DETERMINISTIC SESSION_DETERMINISTIC USER_DETERMINISTIC VDB_DETERMINISTIC DETERMINISTIC NULL-ON-NULL 'TRUE'|'FALSE' JAVA_CLASS string Java Class that defines the method in case of UDF JAVA_METHOD string The Java method name on the above defined java class for the UDF implementation VARARGS 'TRUE'|'FALSE' Indicates that the last argument of the function can be repeated 0 to any number of times. default false. It is more proper to use a VARIADIC parameter. AGGREGATE 'TRUE'|'FALSE' Indicates the function is a user defined aggregate function. Properties specific to aggregates are listed below: Note that NULL-ON-NULL, VARARGS, and all of the AGGREGATE properties are also valid relational extension metadata properties that can be used on source procedures marked as functions. You can also create FOREIGN functions that are supported by a source. See the section on user defined functions in Red Hat JBoss Data Virtualization Development Guide: Server Development for more information about source supported functions.

Commands:
Chapter 151. StrimziPodSet schema reference Full list of StrimziPodSet schema properties Important StrimziPodSet is an internal Streams for Apache Kafka resource. Information is provided for reference only. Do not create, modify or delete StrimziPodSet resources as this might cause errors. 151.1. StrimziPodSet schema properties Property Property type Description spec StrimziPodSetSpec The specification of the StrimziPodSet. status StrimziPodSetStatus The status of the StrimziPodSet.

Commands:
Chapter 10. Protecting GRUB with a password You can protect GRUB with a password in two ways: Password is required for modifying menu entries but not for booting existing menu entries. Password is required for modifying menu entries and for booting existing menu entries. 10.1. Setting password protection only for modifying menu entries You can configure GRUB to support password authentication for modifying GRUB menu entries. This procedure creates a /boot/grub2/user.cfg file that provides the password in the hash format. Important Setting a password using the grub2-setpassword command prevents menu entries from unauthorized modification but not from unauthorized booting. Procedure Issue the grub2-setpassword command as root: Enter the password for the user and press the Enter key to confirm the password: Note The root user is defined in the /boot/grub2/grub.cfg file with the password changes. Therefore, modifying a boot entry during booting requires the name and password of the root user. 10.2. Setting password protection for modifying and booting menu entries You can configure GRUB to prevent menu entries from unauthorized modification and booting. Warning If you forget the GRUB password, you will not be able to boot the entries you have reconfigured. Procedure Open the Boot Loader Specification ( BLS ) file for boot entry you want to modify from the /boot/loader/entries/ directory. Find the line beginning with grub_users . This parameter passes extra arguments to menuentry . Set the grub_users attribute to the user name that is allowed to boot the entry besides the superusers, by default this user is root . Here is a sample configuration file: + Save and close the BLS file: Note If you want to protect all the menu entries from booting, you can directly set the grub_users attribute. For example, if root is the user:

Commands:
grub2-setpassword
Enter password: Confirm the password:
title Red Hat Enterprise Linux (4.18.0-221.el8.x86_64) 8.3 (Ootpa) version 4.18.0-221.el8.x86_64 linux /vmlinuz-4.18.0-221.el8.x86_64 initrd /initramfs-4.18.0-221.el8.x86_64.img USDtuned_initrd options USDkernelopts USDtuned_params id rhel-20200625210904-4.18.0-221.el8.x86_64 grub_users root grub_arg --unrestricted grub_class kernel
grub2-editenv - set grub_users="root"
Chapter 20. Groups 20.1. Imported Group Elements The groups collection contains imported groups from directory services. A group resource contains a set of elements. Table 20.1. Imported group elements Element Type Description link rel="tags" relationship A link to the tags sub-collection for tags attached to this group. link rel="permissions" relationship A link to the permissions sub-collection for permissions attached to this group. link rel="roles" relationship A link to the roles sub-collection for roles attached to this group.

Commands:
Chapter 1. Use Case Considerations Because Amazon Web Services is an image-only service, there are common Satellite use cases that do not work, or require extra configuration in an Amazon Web Service environment. If you plan to use Satellite on AWS, ensure that the use case scenarios that you want to use are available in an AWS environment. 1.1. Use Cases Known to Work You can perform the following Red Hat Satellite use cases on AWS: Managing Red Hat Subscriptions Importing Content Managing Errata Registering a Host Manually Red Hat Insights Realm Integration via IdM OpenSCAP Remote Execution Subscriptions Not all Red Hat subscriptions are eligible to run in public cloud environments. For more information about subscription eligibility, see the Red Hat Cloud Access Page . You can create additional organizations and then import additional manifests to the organizations. For more information, see Creating an Organization in Administering Red Hat Satellite . Multi-homed Satellite and Capsule Multi-homed Satellite is not supported. Multi-homed Capsule is supported, to implement this, you can configure Capsules with a load balancer. For more information, see Configuring Capsules with a Load Balancer . You must do this when Satellite Server or Capsule Server has different internal and external DNS host names and there is no site-to-site VPN connection between the locations where you deploy Satellite Server and Capsule Server. On demand content sources You can use the On demand download policy to reduce the storage footprint of the server that runs Satellite. When you set the download policy to On Demand , content syncs to Satellite Server or Capsule Server when a content host requests it. For more information, see Importing Content in Managing content . 1.2. Use Cases that Do Not Work In AWS, you cannot manage the DHCP. Because of this, most of Satellite Server's Kickstart and PXE provisioning models are unusable. This includes: PXE Provisioning Discovery and Discovery Rules ISO Provisioning methods. PXE-Less Discovery (iPXE) Per-host ISO Generic ISO Full-host ISO

Commands:
Chapter 11. The REST Interface Red Hat JBoss Data Grid provides a REST interface. The primary benefit of the REST API is that it allows for loose coupling between the client and server. The need for specific versions of client libraries and bindings is also eliminated. The REST API introduces an overhead, and requires a REST client or custom code to understand and create REST calls. To interact with JBoss Data Grid's REST API only requires a HTTP client library. For Java, the Apache HTTP Commons Client is recommended. Alternatively, the java.net API can be used. Important The following examples assume that REST security is disabled on the REST connector. To disable REST security remove the security-domain and auth-method parameters from the connector. Report a bug 11.1. Ruby Client Code The following code is an example of interacting with Red Hat JBoss Data Grid REST API using ruby. The provided code does not require any special libraries and standard net/HTTP libraries are sufficient. Example 11.1. Using the REST API with Ruby Report a bug

Commands:
require 'net/http' http = Net::HTTP.new('localhost', 8080) #An example of how to create a new entry http.post('/rest/MyData/MyKey', 'DATA_HERE', {"Content-Type" => "text/plain"}) #An example of using a GET operation to retrieve the key puts http.get('/rest/MyData/MyKey').body #An Example of using a PUT operation to overwrite the key http.put('/rest/MyData/MyKey', 'MORE DATA', {"Content-Type" => "text/plain"}) #An example of Removing the remote copy of the key http.delete('/rest/MyData/MyKey') #An example of creating binary data http.put('/rest/MyImages/Image.png', File.read('/Users/michaelneale/logo.png'), {"Content-Type" => "image/png"})
4.2. Programmatically Configure the Persistence SPI The following is a sample programmatic configuration for a Single File Store using the Persistence SPI: Example 4.1. Configure the Single File Store via the Persistence SPI Note Programmatic configurations can only be used with Red Hat JBoss Data Grid's Library mode. Report a bug

Commands:
ConfigurationBuilder builder = new ConfigurationBuilder(); builder.persistence() .passivation(false) .addSingleFileStore() .preload(true) .shared(false) .fetchPersistentState(true) .ignoreModifications(false) .purgeOnStartup(false) .location(System.getProperty("java.io.tmpdir")) .async() .enabled(true) .threadPoolSize(5) .singleton() .enabled(true) .pushStateWhenCoordinator(true) .pushStateTimeout(20000);
7.66. gpxe 7.66.1. RHEA-2015:1368 - gpxe enhancement update Updated gpxe packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The gpxe package provides gPXE, an open source Pre-boot Execution Environment (PXE) implementation and boot loader. Enhancement BZ# 968474 This update corrects the timeout values used by gPXE to conform to RFC 2131 and the PXE specification. Users of gpxe are advised to upgrade to these updated packages, which add this enhancement.

Commands:
B.67. pidgin B.67.1. RHSA-2010:0890 - Moderate: pidgin security update Updated pidgin packages that fix multiple security issues 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. Pidgin is an instant messaging program which can log in to multiple accounts on multiple instant messaging networks simultaneously. CVE-2010-3711 Multiple NULL pointer dereference flaws were found in the way Pidgin handled Base64 decoding. A remote attacker could use these flaws to crash Pidgin if the target Pidgin user was using the Yahoo! Messenger Protocol, MSN, MySpace, or Extensible Messaging and Presence Protocol (XMPP) protocol plug-ins, or using the Microsoft NT LAN Manager (NTLM) protocol for authentication. Red Hat would like to thank the Pidgin project for reporting these issues. Upstream acknowledges Daniel Atallah as the original reporter. All Pidgin users should upgrade to these updated packages, which contain a backported patch to resolve these issues. Pidgin must be restarted for this update to take effect.

Commands:
Appendix A. Revision History Revision History Revision 3.5-3 Wed Dec 20 2023 Lenka Spackova Fixed broken links and anchors. Revision 3.5-2 Fri Nov 12 2021 Lenka Spackova Updated Section 4.5, "Database Connectors" . Revision 3.5-1 Tue May 26 2020 Lenka Spackova Release of Red Hat Software Collections 3.5 Release Notes. Revision 3.5-0 Tue Apr 21 2020 Lenka Spackova Release of Red Hat Software Collections 3.5 Beta Release Notes.

Commands: