mtpti5iD/redhat-docs_dataset huggingface dataset:
2.11.2. Finding a Subsystem To find out what subsystems are available in your kernel and how they are mounted together into hierarchies, run: In the example output above, the hierarchy column lists IDs of the existing hierarchies on the system. Subsystems with the same hierarchy ID are attached to the same hierarchy. The num_cgroup column lists the number of existing cgroups in the hierarchy that uses a particular subsystem. The enabled column reports the value of 1 if a particular subsystem is enabled, or 0 if it is not. Or, to find the mount points of particular subsystems, run: where subsystems is a list of the subsystems in which you are interested. Note that the lssubsys -m command returns only the top-level mount point per each hierarchy.

Commands:
~]USD cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 2 1 1 ns 0 1 1 cpu 3 1 1 cpuacct 4 1 1 memory 5 1 1 devices 6 1 1 freezer 7 1 1 net_cls 8 1 1 blkio 9 3 1 perf_event 0 1 1 net_prio 0 1 1
~]USD lssubsys -m subsystems
Chapter 9. Working with job templates A job template combines an Ansible playbook from a project and the settings required to launch it. Job templates are useful to run the same job many times. Job templates also encourage the reuse of Ansible playbook content and collaboration between teams. For more information, see Job Templates in the Automation controller User Guide . 9.1. Getting started with job templates As part of the initial setup, a Demo Job Template is created for you. Procedure To review existing templates, select Resources Templates from the navigation panel. Click Demo Job Template to view its details. 9.2. Editing a job template As part of the initial setup, you can leave the default Demo Job Template as it is, but you can edit it later. Procedure Open the template to edit it by using one of these methods: Click Edit in the job template Details page. From the navigation panel, select Resources Templates . Click Edit to the template name and edit the appropriate details. Save your changes. To exit after saving and return to the Templates list view, use the breadcrumb navigation links or click Cancel . Clicking Save does not exit the Details dialog. 9.3. Running a job template A benefit of automation controller is the push-button deployment of Ansible Playbooks. You can configure a template to store all the parameters that you would normally pass to the Ansible Playbook on the command line. In addition to the playbooks, the template passes the inventory, credentials, extra variables, and all options and settings that you can specify on the command line. Procedure From the navigation panel, select Resources Templates and click Launch to the job template. The initial job start generates a status page, which updates automatically by using automation controller's Live Event feature, until the job is complete. For more information about the job results, see Jobs in automation controller in the Automation controller User Guide . Additional resources To learn more about these automation controller features or to learn about administration tasks and the controller API, see the following documentation sets: Automation controller User Guide Red Hat Ansible Automation Platform Installation Guide Automation controller Administration Guide Automation Controller API Guide Automation controller Release Notes Product Documentation for Red Hat Ansible Automation Platform

Commands:
8.203. rrdtool 8.203.1. RHBA-2014:0356 - rrdtool bug fix update Updated rrdtool packages that fix one bug are now available for Red Hat Enterprise Linux 6. The round robin database (RRD) system stores and displays time-series data, such as network bandwidth, machine-room temperature, and server load average. RRDtool is a high performance data logging and graphing utility, which can be easily integrated with shell scripts, or used to create applications using its Perl, Python, Ruby, Lua, Tcl, and PHP bindings. The data is stored in a compact manner that does not expand over time, and RRDtool provides the user with useful graphs by processing the data to enforce a certain data density. Bug Fix BZ# 914688 Prior to this update, the RRDtool utility did not reduce data after the "fetch" operation. Consequently, some data could not be plotted or processed under certain circumstances. With this update, the data is reduced to at least the chart resolution after the "fetch" operation, and all the data is now plotted or processed as expected in the described scenario. Users of rrdtool are advised to upgrade to these updated packages, which fix this bug.

Commands:
8.53. glib2 8.53.1. RHBA-2013:1545 - glib2 bug fix and enhancement update Updated glib2 packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. GLib is a low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. Note The glib2 packages have been upgraded to upstream version 2.26.0, which provides a number of bug fixes and enhancements over the version. (BZ# 883021 ) Users of glib2 are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Appendix D. Additional Eclipse Vert.x resources The Reactive Manifesto Eclipse Vert.x project Vert.x in Action Eclipse Vert.x for Reactive Programming Building Reactive Microservices in Java Eclipse Vert.x Cheat Sheet for Developers Vert.x - From zero to (micro)-hero Red Hat Summit 2017 Talk - Reactive Programming with Eclipse Vert.x Red Hat Summit 2017 Breakout Session - Reactive Systems with Eclipse Vert.x and Red Hat OpenShift Live Coding Reactive Systems with Eclipse Vert.x and OpenShift

Commands:
Chapter 51. JSON Gson Gson is a Data Format which uses the Gson Library . from("activemq:My.Queue"). marshal().json(JsonLibrary.Gson). to("mqseries:Another.Queue"); 51.1. Dependencies When using json-gson with Red Hat build of Camel Spring Boot make sure to use the following Maven dependency to have support for auto configuration: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-gson-starter</artifactId> </dependency> 51.2. Gson Options The JSON Gson dataformat supports 3 options, which are listed below. Name Default Java Type Description prettyPrint Boolean To enable pretty printing output nicely formatted. Is by default false. unmarshalType String Class name of the java type to use when unmarshalling. contentTypeHeader Boolean Whether the data format should set the Content-Type header with the type from the data format. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSON. 51.3. Spring Boot Auto-Configuration The component supports 4 options, which are listed below. Name Description Default Type camel.dataformat.json-gson.content-type-header Whether the data format should set the Content-Type header with the type from the data format. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSON. true Boolean camel.dataformat.json-gson.enabled Whether to enable auto configuration of the json-gson data format. This is enabled by default. Boolean camel.dataformat.json-gson.pretty-print To enable pretty printing output nicely formatted. Is by default false. false Boolean camel.dataformat.json-gson.unmarshal-type Class name of the java type to use when unmarshalling. String

Commands:
from("activemq:My.Queue"). marshal().json(JsonLibrary.Gson). to("mqseries:Another.Queue");
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-gson-starter</artifactId> </dependency>
Chapter 39. Using A JAXBContext Object Abstract The JAXBContext object allows the Apache CXF's runtime to transform data between XML elements and Java object. Application developers need to instantiate a JAXBContext object they want to use JAXB objects in message handlers and when implementing consumers that work with raw XML messages. Overview The JAXBContext object is a low-level object used by the runtime. It allows the runtime to convert between XML elements and their corresponding Java representations. An application developer generally does not need to work with JAXBContext objects. The marshaling and unmarshaling of XML data is typically handled by the transport and binding layers of a JAX-WS application. However, there are instances when an application will need to manipulate the XML message content directly. In two of these instances: Section 41.1, "Using XML in a Consumer" Chapter 43, Writing Handlers You will need instantiate a JAXBContext object using one of the two available JAXBContext.newInstance() methods. Best practices JAXBContext objects are resource intensive to instantiate. It is recommended that an application create as few instances as possible. One way to do this is to create a single JAXBContext object that can manage all of the JAXB objects used by your application and share it among as many parts of your application as possible. JAXBContext objects are thread safe. Getting a JAXBContext object using an object factory The JAXBContext class provides a newInstance() method, shown in Example 39.1, "Getting a JAXB Context Using Classes" , that takes a list of classes that implement JAXB objects. Example 39.1. Getting a JAXB Context Using Classes static JAXBContext newInstance Class... classesToBeBound JAXBException The returned JAXBObject object will be able to marshal and unmarshal data for the JAXB object implemented by the classes passed into the method. It will also be able to work with any classes that are statically referenced from any of the classes passed into the method. While it is possible to pass the name of every JAXB class used by your application to the newInstance() method it is not efficient. A more efficient way to accomplish the same goal is to pass in the object factory, or object factories, generated for your application. The resulting JAXBContext object will be able to manage any JAXB classes the specified object factories can instantiate. Getting a JAXBContext object using package names The JAXBContext class provides a newInstance() method, shown in Example 39.2, "Getting a JAXB Context Using Classes" , that takes a colon ( : ) seperated list of package names. The specified packages should contain JAXB objects derived from XML Schema. Example 39.2. Getting a JAXB Context Using Classes static JAXBContext newInstance String contextPath JAXBException The returned JAXBContext object will be able to marshal and unmarshal data for all of the JAXB objects implemented by the classes in the specified packages.

Commands:
22.16.9. Adding a Multicast Client Address To add a multicast client address, that is to say, to configure a multicast address to be monitored for multicast NTP packets, make use of the multicastclient command in the ntp.conf file. The multicastclient command takes the following form: multicastclient address Enables the receiving of multicast messages. Where address is the address to subscribe to. This should be used together with authentication to prevent service disruption. This command configures a system to act as an NTP client. Systems can be both client and server at the same time.

Commands:
Preface Red Hat Quay offers administrators the ability to secure communication and trusted access to their repositories through the use of Transport Layer Security (TLS), certificate management, and encryption techniques. Properly configuring SSL/TLS and implementing custom certificates can help safeguard data, secure external connections, and maintain trust between Red Hat Quay and the integrated services of your choosing. The following topics are covered: Configuring custom SSL/TLS certificates for standalone Red Hat Quay deployments Configuring custom SSL/TLS certificates for Red Hat Quay on OpenShift Container Platform Adding additional Certificate Authorities to the Red Hat Quay container Adding additional Certificate Authorities to Red Hat Quay on OpenShift Container Platform

Commands:
Chapter 4. Configuring the web console in OpenShift Container Platform You can modify the OpenShift Container Platform web console to set a logout redirect URL or disable the console. 4.1. Prerequisites Deploy an OpenShift Container Platform cluster. 4.2. Configuring the web console You can configure the web console settings by editing the console.config.openshift.io resource. Edit the console.config.openshift.io resource: USD oc edit console.config.openshift.io cluster The following example displays the sample resource definition for the console: apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2 1 Specify the URL of the page to load when a user logs out of the web console. If you do not specify a value, the user returns to the login page for the web console. Specifying a logoutRedirect URL allows your users to perform single logout (SLO) through the identity provider to destroy their single sign-on session. 2 The web console URL. To update this to a custom value, see Customizing the web console URL .

Commands:
oc edit console.config.openshift.io cluster
apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2
4.3.13. Moving a Volume Group to Another System You can move an entire LVM volume group to another system. It is recommended that you use the vgexport and vgimport commands when you do this. The vgexport command makes an inactive volume group inaccessible to the system, which allows you to detach its physical volumes. The vgimport command makes a volume group accessible to a machine again after the vgexport command has made it inactive. To move a volume group form one system to another, perform the following steps: Make sure that no users are accessing files on the active volumes in the volume group, then unmount the logical volumes. Use the -a n argument of the vgchange command to mark the volume group as inactive, which prevents any further activity on the volume group. Use the vgexport command to export the volume group. This prevents it from being accessed by the system from which you are removing it. After you export the volume group, the physical volume will show up as being in an exported volume group when you execute the pvscan command, as in the following example. When the system is shut down, you can unplug the disks that constitute the volume group and connect them to the new system. When the disks are plugged into the new system, use the vgimport command to import the volume group, making it accessible to the new system. Activate the volume group with the -a y argument of the vgchange command. Mount the file system to make it available for use.

Commands:
pvscan PV /dev/sda1 is in exported VG myvg [17.15 GB / 7.15 GB free] PV /dev/sdc1 is in exported VG myvg [17.15 GB / 15.15 GB free] PV /dev/sdd1 is in exported VG myvg [17.15 GB / 15.15 GB free]
1.2. Configuring the iptables Firewall to Allow Cluster Components Table 1.1, "Ports to Enable for High Availability Add-On" shows the ports to enable for the Red Hat High Availability Add-On. Table 1.1. Ports to Enable for High Availability Add-On Port When Required TCP 2224 Required on all nodes (needed by the pcsd daemon) TCP 3121 Required on all nodes if the cluster has any Pacemaker Remote nodes TCP 21064 Required on all nodes if the cluster contains any resources requiring DLM (such as clvm or GFS2 ) UDP 5405 Required on all cluster nodes (needed by corosync ) UDP 5404 Required on cluster nodes if corosync is configured for multicast UDP

Commands:
Chapter 6. Connecting with node.js 6.1. Access Red Hat JBoss Data Virtualization from node.js If you are writing a "node.js" application and would like to access Red Hat JBoss Data Virtualization with it, you can do so by using an NPM package called "pg". Red Hat JBoss Data Virtualization supports the ODBC transport, so you can use this PostgreSQL client for "node.js" to access it. For example, if you have a virtual database called "northwind" deployed on your Red Hat JBoss Data Virtualization server, and it has a table called "customers", your default configuration will look like this: You can then write a short access program like this: If you want to access one row at a time, you can also use the event mechanism by writing a piece of code like this: For more information, please refer to the node-postgres package documentation. You can also find the source code on GitHub.

Commands:
user = 'user' password = 'user' host = 127.0.0.1 port = 35432
var pg = require('pg'); var connectionString = "pg://user:user@localhost:35432/northwind" pg.connect(connectionString, function(err, client) { client.query('SELECT CustomerID, ContactName, ContactTitle FROM Customers', function(err, result) { console.log(result.rows) }); });
var pg = require('pg'); var connectionString = "pg://user:user@localhost:35432/northwind" pg.connect(connectionString, function(err, client) { var query = client.query('SELECT CustomerID, ContactName, ContactTitle FROM Customers'); query.on('row', function(row) { console.log(row); }); query.on('error', function(error) { console.log("failed to query"); }); query.on('end', function(error) { console.log("closing client"); client.end(); }); });
10.2.3. Connecting to a Network Automatically For any connection type you add or configure, you can choose whether you want NetworkManager to try to connect to that network automatically when it is available. Procedure 10.1. Configuring NetworkManager to Connect to a Network Automatically When Detected Right-click on the NetworkManager applet icon in the Notification Area and click Edit Connections . The Network Connections window appears. Click the arrow head if necessary to reveal the list of connections. Select the specific connection that you want to configure and click Edit . Check Connect automatically to cause NetworkManager to auto-connect to the connection whenever NetworkManager detects that it is available. Uncheck the check box if you do not want NetworkManager to connect automatically. If the box is unchecked, you will have to select that connection manually in the NetworkManager applet's left-click menu to cause it to connect.

Commands:
Chapter 8. InfiniBand subnet manager All InfiniBand networks must have a subnet manager running for the network to function. This is true even if two machines are connected directly with no switch involved. It is possible to have more than one subnet manager. In that case, one acts as a master and another subnet manager acts as a slave that will take over in case the master subnet manager fails. Red Hat Enterprise Linux provides OpenSM , an implementation of an InfiniBand subnet manager. However, the features of OpenSM are limited and there is no active upstream development. Typically, embedded subnet managers in InfiniBand switches provide more features and support up-to-date InfiniBand hardware. For further details, see Installing and configuring the OpenSM InfiniBand subnet manager .

Commands:
7.3. Configuring the audit Service The Audit daemon can be configured in the /etc/audit/auditd.conf configuration file. This file consists of configuration parameters that modify the behavior of the Audit daemon. Any empty lines or any text following a hash sign ( # ) is ignored. See the auditd.conf (5) man page for a complete listing of all configuration parameters and their explanation. 7.3.1. Configuring auditd for a CAPP Environment The default auditd configuration should be suitable for most environments. However, if your environment has to meet the criteria set by the Controlled Access Protection Profile (CAPP), which is a part of the Common Criteria certification, the Audit daemon must be configured with the following settings: The directory that holds the Audit log files (usually /var/log/audit/ ) should reside on a separate partition. This prevents other processes from consuming space in this directory, and provides accurate detection of the remaining space for the Audit daemon. The max_log_file parameter, which specifies the maximum size of a single Audit log file, must be set to make full use of the available space on the partition that holds the Audit log files. The max_log_file_action parameter, which decides what action is taken once the limit set in max_log_file is reached, should be set to keep_logs to prevent Audit log files from being overwritten. The space_left parameter, which specifies the amount of free space left on the disk for which an action that is set in the space_left_action parameter is triggered, must be set to a number that gives the administrator enough time to respond and free up disk space. The space_left value depends on the rate at which the Audit log files are generated. It is recommended to set the space_left_action parameter to email or exec with an appropriate notification method. The admin_space_left parameter, which specifies the absolute minimum amount of free space for which an action that is set in the admin_space_left_action parameter is triggered, must be set to a value that leaves enough space to log actions performed by the administrator. The admin_space_left_action parameter must be set to single to put the system into single-user mode and allow the administrator to free up some disk space. The disk_full_action parameter, which specifies an action that is triggered when no free space is available on the partition that holds the Audit log files, must be set to halt or single . This ensures that the system is either shut down or operating in single-user mode when Audit can no longer log events. The disk_error_action , which specifies an action that is triggered in case an error is detected on the partition that holds the Audit log files, must be set to syslog , single , or halt , depending on your local security policies regarding the handling of hardware malfunctions. The flush configuration parameter must be set to sync or data . These parameters assure that all Audit event data is fully synchronized with the log files on the disk. The remaining configuration options should be set according to your local security policy.

Commands:
5.3. SystemTap SystemTap is a useful instrumentation platform for probing running processes and kernel activity on the Linux system. To execute a probe: Write SystemTap scripts that specify which system events (for example, virtual file system reads, packet transmissions) should trigger specified actions (for example, print, parse, or otherwise manipulate data). SystemTap translates the script into a C program, which it compiles into a kernel module. SystemTap loads the kernel module to perform the actual probe. SystemTap scripts are useful for monitoring system operation and diagnosing system issues with minimal intrusion into the normal operation of the system. You can quickly instrument running system test hypotheses without having to recompile and re-install instrumented code. To compile a SystemTap script that probes kernel-space , SystemTap uses information from three different kernel information packages : kernel- variant -devel- version kernel- variant -debuginfo- version kernel-debuginfo-common- arch-version Note The kernel information package in Red Hat Enterprise Linux 6 is now named kernel-debuginfo-common- arch-version . It was originally kernel-debuginfo-common- version in Red Hat Enterprise Linux 5. These kernel information packages must match the kernel to be probed. In addition, to compile SystemTap scripts for multiple kernels, the kernel information packages of each kernel must also be installed. 5.3.1. Additional Information For more detailed information about SystemTap, see the following Red Hat documentation: SystemTap Beginner's Guide SystemTap Tapset Reference

Commands: