mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction to Control Groups (Cgroups) 1.1. What are Control Groups The control groups , abbreviated as cgroups in this guide, are a Linux kernel feature that allows you to allocate resources - such as CPU time, system memory, network bandwidth, or combinations of these resources - among hierarchically ordered groups of processes running on a system. By using cgroups, system administrators gain fine-grained control over allocating, prioritizing, denying, managing, and monitoring system resources. Hardware resources can be smartly divided up among applications and users, increasing overall efficiency. Control Groups provide a way to hierarchically group and label processes, and to apply resource limits to them. Traditionally, all processes received similar amounts of system resources that the administrator could modulate with the process niceness value. With this approach, applications that involved a large number of processes received more resources than applications with few processes, regardless of the relative importance of these applications. Red Hat Enterprise Linux 7 moves the resource management settings from the process level to the application level by binding the system of cgroup hierarchies with the systemd unit tree. Therefore, you can manage system resources with systemctl commands, or by modifying systemd unit files. See Chapter 2, Using Control Groups for details. In versions of Red Hat Enterprise Linux, system administrators built custom cgroup hierarchies with the use of the cgconfig command from the libcgroup package. This package is now deprecated, and it is not recommended to use it since it can easily create conflicts with the default cgroup hierarchy. However, libcgroup is still available to cover for certain specific cases, where systemd is not yet applicable, most notably for using the net-prio subsystem. See Chapter 3, Using libcgroup Tools . The aforementioned tools provide a high-level interface to interact with cgroup controllers (also known as subsystems) in Linux kernel. The main cgroup controllers for resource management are cpu , memory , and blkio , see Available Controllers in Red Hat Enterprise Linux 7 for the list of controllers enabled by default. For detailed description of resource controllers and their configurable parameters, see Controller-Specific Kernel Documentation .

Commands:
4.183. mod_revocator 4.183.1. RHBA-2011:1769 - mod_revocator bug fix update An updated mod_revocator package that fixes multiple bugs is now available for Red Hat Enterprise Linux 6. The mod_revocator module retrieves and installs remote Certificate Revocation Lists (CRLs) into an Apache web server. Bug Fixes BZ# 748579 Previously, the code for the httpd daemon shutdown was incorrect and the mod_revocator module did not shut down the httpd daemon when CRL (Certificate Revocation List) update failed on IA-32 architectures. With this update, the code has been fixed and httpd is now closed as expected when CRL update fails. BZ# 748577 Previously, the code for httpd shutdown was incorrect and the mod_revocator module did not shut down the httpd daemon when expired CRLs were fetched. With this update, the code has been fixed and httpd is closed as expected in this scenario. BZ# 749696 Due to an incorrect initialization size of a static array, the httpd daemon with mod_revocator failed to start on 64-bit PowerPC architectures. With this update, the size of the array has been modified and the httpd starts as expected under these circumstances. BZ# 746365 The httpd daemon with the mod_revocator module cannot be used as an HTTP client by default because the SELinux policy prevents such behavior. However, to acquire CRLs from a remote host, the httpd daemon needs to behave as an HTTP client to send HTTP messages to the host. If the behavior was not enabled, child processes of the httpd daemon terminated unexpectedly with segmentation faults when attempting to connect to a remote host. With this update, the underlying code has been changed and the segmentation faults no longer occur. Note To change the SELinux policy and enable httpd to request CRLs from a remote host, execute the "setsebool -P httpd_can_network_connect=1" command as root. All users of mod_revocator are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 1. Overview of Red Hat OpenStack Application and VNF policies Use this guide to understand the prerequisites and environmental testing requirements that are necessary to successfully complete and obtain a Red Hat OpenStack Platform (RHOSP) application certification. This includes applications that depend on RHOSP API's, provide additional functionality in RHOSP cloud, such as a Virtual Network Function (VNF), Network Functions Virtualization (NFV), Management and Orchestration (MANO), and those applications which run on top of a RHOSP environment. It includes the applications that do not implement infrastructure software (plug-in or driver) for use with Red Hat OpenStack Platform in a supported customer environment. 1.1. Audience Red Hat OpenStack Application certification policy guide is intended for Partners who want to certify their system using an Openstack application like Virtual Network Function (VNF), Network Functions Virtualization (NFV), Management and Orchestration (MANO) and others. 1.2. Creating value for our customers Red Hat OpenStack application certification creates value for customers as it ensures that the certified application can be used with RHOSP in addition to making sure the underlying architecture is still supportable after installation of application. The certification process, through a series of tests, validates that a certified solution meets the requirements of an enterprise cloud, and is jointly supported by Red Hat and your organization.

Commands:
3.3. Automated Installation If you need to install a Red Hat JBoss product multiple times with the same configuration, you can save time by using an installation script. By using an installation script with predefined settings, you can perform the entire installation by running a single command, instead of working through the installation step by step each time. You can generate an installation script by running the installer (in graphical or text mode), stepping through with your desired configuration, and then choosing to generate the script when prompted towards the end of the process. Prerequisites You must have downloaded the relevant installer JAR file from https://access.redhat.com/jbossnetwork/ . You must have generated the script and saved it as an XML file during a installation. Procedure 3.3. Installing with a Script Note You can also provide variables using the CLI or automatic installation. Use java -jar path/to/installer.jar -variablefile /pathtofile to supply variables using a configuration file or use java -jar path/to/installer.jar -variables EXAMPLE1=example1,EXAMPLE2=example2 to provide a comma-separated list of variables.

Commands:
java -jar jboss- PRODUCT -installer- VERSION .jar SCRIPT .xml
8.35. emacs 8.35.1. RHBA-2013:1088 - emacs bug fix update Updated emacs packages that fix a bug are now available for Red Hat Enterprise Linux 6. GNU Emacs is a powerful, customizable, self-documenting text editor. It provides special code editing features, a scripting language (elisp), and the capability to read email and news. Bug Fix BZ#678225 The Lucida Typewriter and Lucida Console fonts were not usable with Emacs 23.1 in Red Hat Enterprise Linux 6. Consequently, the following error message was displayed in the Messages buffer: "set-face-attribute: Font not available". With this update, no error message is displayed in this scenario and the selected font can be used to display the buffer contents. Users of emacs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Accessing the Fuse Console To access the Fuse Console for Apache Karaf standalone, follow these steps. Prerequisite Install Fuse on the Karaf container. For step-by-step instructions, see Installing on Apache Karaf . Procedure In the command line, navigate to the directory in which you installed Red Hat Fuse and run the following command to start Fuse standalone: The Karaf console starts and shows version information, the default Fuse Console URL, and a list of common commands. In a browser, type the URL to connect to the Fuse Console. For example: http://localhost:8181/hawtio In the login page, type your user name and password and then click Log In . By default, the Fuse Console shows the Home page. The left navigation tabs indicate the running plugins.

Commands:
./bin/fuse
2.5.3. VFS Tuning Options: Research and Experiment Like all Linux file systems, GFS2 sits on top of a layer called the virtual file system (VFS). You can tune the VFS layer to improve underlying GFS2 performance by using the sysctl (8) command. For example, the values for dirty_background_ratio and vfs_cache_pressure may be adjusted depending on your situation. To fetch the current values, use the following commands: The following commands adjust the values: You can permanently change the values of these parameters by editing the /etc/sysctl.conf file. To find the optimal values for your use cases, research the various VFS options and experiment on a test cluster before deploying into full production.

Commands:
sysctl -n vm.dirty_background_ratio sysctl -n vm.vfs_cache_pressure
sysctl -w vm.dirty_background_ratio=20 sysctl -w vm.vfs_cache_pressure=500
4.3.7. Activating and Deactivating Volume Groups When you create a volume group it is, by default, activated. This means that the logical volumes in that group are accessible and subject to change. There are various circumstances for which you you need to make a volume group inactive and thus unknown to the kernel. To deactivate or activate a volume group, use the -a ( --available ) argument of the vgchange command. The following example deactivates the volume group my_volume_group . If clustered locking is enabled, add 'e' to activate or deactivate a volume group exclusively on one node or 'l' to activate or/deactivate a volume group only on the local node. Logical volumes with single-host snapshots are always activated exclusively because they can only be used on one node at once. You can deactivate individual logical volumes with the lvchange command, as described in Section 4.4.4, "Changing the Parameters of a Logical Volume Group" , For information on activating logical volumes on individual nodes in a cluster, see Section 4.8, "Activating Logical Volumes on Individual Nodes in a Cluster" .

Commands:
vgchange -a n my_volume_group
3.2. Grouping API Use Case This feature allows logically related data to be stored on a single node. For example, if the cache contains user information, the information for all users in a single location can be stored on a single node. The benefit of this approach is that when seeking specific (logically related) data, the Distributed Executor task is directed to run only on the relevant node rather than across all nodes in the cluster. Such directed operations result in optimized performance. Example 3.1. Grouping API Example Acme, Inc. is a home appliance company with over one hundred offices worldwide. Some offices house employees from various departments, while certain locations are occupied exclusively by the employees of one or two departments. The Human Resources (HR) department has employees in Bangkok, London, Chicago, Nice and Venice. Acme, Inc. uses Red Hat JBoss Data Grid's Grouping API to ensure that all the employee records for the HR department are moved to a single node (Node AB) in the cache. As a result, when attempting to retrieve a record for a HR employee, the DistributedExecutor only checks node AB and quickly and easily retrieves the required employee records. Storing related entries on a single node as illustrated optimizes the data access and prevents time and resource wastage by seeking information on a single node (or a small subset of nodes) instead of all the nodes in the cluster. Report a bug

Commands:
8.245. xorg-x11-xinit 8.245.1. RHBA-2013:1538 - xorg-x11-xinit bug fix update Updated xorg-x11-xinit packages that fix one bug are now available for Red Hat Enterprise Linux 6. X.Org is an open source implementation of the X Window System providing basic low-level functionality that full-fledged desktop environments such as GNOME and KDE are built on top of. The xorg-x11-xinit packages contain the X.Org X Window System xinit startup scripts. Bug Fix BZ# 811289 Previously, the startx script did not handle the xserverrc file properly. If the xserverrc file existed in the /etc/X11/xinit/ directory, the script failed with the following error message: Fatal server error: Unrecognized option: /etc/X11/xinit/xserverrc With this update, the X session is started using options from the xserverrc file, and the startx script now properly handles the xserverrc file. Users of xorg-x11-xinit are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 9. Error handling Errors in AMQ JavaScript can be handled by intercepting named events corresponding to AMQP protocol or connection errors. 9.1. Handling connection and protocol errors You can handle protocol-level errors by intercepting the following events: connection_error session_error sender_error receiver_error protocol_error error These events are fired whenever there is an error condition with the specific object that is in the event. After calling the error handler, the corresponding <object> _close handler is also called. The event argument has an error attribute for accessing the error object. Example: Handling errors container.on("error", function (event) { console.log("An error!", event.error); }); Note Because the close handlers are called in the event of any error, only the error itself needs to be handled within the error handler. Resource cleanup can be managed by close handlers. If there is no error handling that is specific to a particular object, it is typical to handle the general error event and not have a more specific handler. Note When reconnect is enabled and the remote server closes a connection with the amqp:connection:forced condition, the client does not treat it as an error and thus does not fire the connection_error event. The client instead begins the reconnection process.

Commands:
container.on("error", function (event) { console.log("An error!", event.error); });
7.4. Modifying Cache Entries After the cache entry has been created, the cache entry can be modified programmatically. Report a bug 7.4.1. Cache Entry Modified Listener Configuration In a cache entry modified listener event, The getValue() method's behavior is specific to whether the callback is triggered before or after the actual operation has been performed. For example, if event.isPre() is true, then event.getValue() would return the old value, prior to modification. If event.isPre() is false, then event.getValue() would return new value. If the event is creating and inserting a new entry, the old value would be null. For more information about isPre() , see the Red Hat JBoss Data Grid API Documentation 's listing for the org.infinispan.notifications.cachelistener.event package. Listeners can only be configured programmatically by using the methods exposed by the Listenable and FilteringListenable interfaces (which the Cache object implements). Report a bug 7.4.2. Cache Entry Modified Listener Example The following example defines a listener in Red Hat JBoss Data Grid that prints some information each time a cache entry is modified: Example 7.2. Modified Listener Report a bug

Commands:
@Listener public class PrintWhenModified { @CacheEntryModified public void print(CacheEntryModifiedEvent event) { System.out.println("Cache entry modified. Details = " + event"); } }
10.2.4.5. The mod_auth_dbm and mod_auth_db Modules Apache HTTP Server 1.3 supported two authentication modules, mod_auth_db and mod_auth_dbm , which used Berkeley Databases and DBM databases respectively. These modules have been combined into a single module named mod_auth_dbm in Apache HTTP Server 2.0, which can access several different database formats. To migrate from mod_auth_db , configuration files should be adjusted by replacing AuthDBUserFile and AuthDBGroupFile with the mod_auth_dbm equivalents, AuthDBMUserFile and AuthDBMGroupFile . Also, the directive AuthDBMType DB must be added to indicate the type of database file in use. The following example shows a sample mod_auth_db configuration for Apache HTTP Server 1.3: To migrate this setting to version 2.0 of Apache HTTP Server, use the following structure: Note that the AuthDBMUserFile directive can also be used in .htaccess files. The dbmmanage Perl script, used to manipulate username and password databases, has been replaced by htdbm in Apache HTTP Server 2.0. The htdbm program offers equivalent functionality and, like mod_auth_dbm , can operate a variety of database formats; the -T option can be used on the command line to specify the format to use. Table 10.1, "Migrating from dbmmanage to htdbm " shows how to migrate from a DBM-format database to htdbm format using dbmmanage . Table 10.1. Migrating from dbmmanage to htdbm Action dbmmanage command (1.3) Equivalent htdbm command (2.0) Add user to database (using given password) dbmmanage authdb add username password htdbm -b -TDB authdb username password Add user to database (prompts for password) dbmmanage authdb adduser username htdbm -TDB authdb username Remove user from database dbmmanage authdb delete username htdbm -x -TDB authdb username List users in database dbmmanage authdb view htdbm -l -TDB authdb Verify a password dbmmanage authdb check username htdbm -v -TDB authdb username The -m and -s options work with both dbmmanage and htdbm , enabling the use of the MD5 or SHA1 algorithms for hashing passwords, respectively. When creating a new database with htdbm , the -c option must be used. For more on this topic, refer to the following documentation on the Apache Software Foundation's website: http://httpd.apache.org/docs-2.0/mod/mod_auth_dbm.html

Commands:
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location>
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location>
Chapter 4. Desktop Multiple mount changes no longer cause performance drop for clients of the GUnixMountMonitor object Previously, when the autofs program initiated multiple mount changes in a short period of time, services using the GUnixMountMonitor object caused a high CPU load. This update makes it possible to skip accumulated file change events of the /proc/mounts file that cannot be handled in real-time. As a result, the CPU load for the clients of GUnixMountMonitor is lower. (BZ#1154183) xfreerdp client now works correctly on systems with enabled FIPS mode Previously, when the xfreerdp client was used on systems with enabled FIPS mode, it exited unexpectedly due to usage of FIPS non-compliant encryption algorithms. This update ensures that xfreerdp does not exit unexpectedly when it is used with FIPS mode enabled and that FIPS security encryption method is negotiated. As a result, xfreerdp now works correctly with the RDP and TLS security protocols on systems with enabled FIPS mode. However, an error now occurs if the Network Level Authentication (NLA) protocol is required, because its implementation requires FIPS non-compliant algorithms. (BZ# 1347920 )

Commands:
13.4. Disabling User Private Groups To ensure that IdM does not create a default user private group for a new user, choose one of the following: Section 13.4.1, "Creating a User without a User Private Group" Section 13.4.2, "Disabling User Private Groups Globally for All Users" Even after you disable creating default user private groups, IdM will still require a GID when adding new users. To ensure that adding the user succeeds, see Section 13.4.3, "Adding a User with User Private Groups Disabled" . Note If you want to disable creating default user private groups because of GID conflicts, consider changing the default UID and GID assignment ranges. See Chapter 14, Unique UID and GID Number Assignments . 13.4.1. Creating a User without a User Private Group Add the --noprivate option to the ipa user-add command. Note that for the command to succeed, you must specify a custom private group. See Section 13.4.3, "Adding a User with User Private Groups Disabled" . 13.4.2. Disabling User Private Groups Globally for All Users Log in as the administrator: IdM uses the Directory Server Managed Entries Plug-in to manage user private groups. List the instances of the plug-in: To ensure IdM does not create user private groups, disable the plug-in instance responsible for managing user private groups: Note To re-enable the UPG Definition instance later, use the ipa-managed-entries -e "UPG Definition" enable command. Restart Directory Server to load the new configuration. 13.4.3. Adding a User with User Private Groups Disabled To make sure adding a new user succeeds when creating default user private groups is disabled, choose one of the following: Specify a custom GID when adding a new user. The GID does not have to correspond to an already existing user group. For example, when adding a user from the command line, add the --gid option to the ipa user-add command. Use an automember rule to add the user to an existing group with a GID. See Section 13.6, "Defining Automatic Group Membership for Users and Hosts" .

Commands:
kinit admin
ipa-managed-entries --list
ipa-managed-entries -e "UPG Definition" disable Disabling Plugin
systemctl restart dirsrv.target
Chapter 7. Managing credentials Credentials authenticate the controller user to launch Ansible playbooks. The passwords and SSH keys are used to authenticate against inventory hosts. By using the credentials feature of automation controller, you can require the automation controller user to enter a password or key phrase when a playbook launches. 7.1. Creating new credentials As part of the initial setup, a demonstration credential and a Galaxy credential have been created for your use. Use the Galaxy credential as a template. It can be copied, but not edited. You can add more credentials as necessary. Procedure From the navigation panel, select Resources Credentials . To add a new credential, see Creating a credential in the Automation controller User Guide . Note When you set up additional credentials, the user you assign must have root access or be able to use SSH to connect to the host machine. Click Demo Credential to view its details. 7.2. Editing a credential As part of the initial setup, you can leave the default Demo Credential as it is, and you can edit it later. Procedure Edit the credential by using one of these methods: Go to the credential Details page and click Edit . From the navigation panel, select Resources Credentials . Click Edit to the credential name and edit the appropriate details. Save your changes.

Commands: