mtpti5iD/redhat-docs_dataset huggingface dataset:
5.5.3. Directory Structure Many system administrators give little thought to how the storage they make available to users today is actually going to be used tomorrow. However, a bit of thought spent on this matter before handing over the storage to users can save a great deal of unnecessary effort later on. The main thing that system administrators can do is to use directories and subdirectories to structure the storage available in an understandable way. There are several benefits to this approach: More easily understood More flexibility in the future By enforcing some level of structure on your storage, it can be more easily understood. For example, consider a large mult-user system. Instead of placing all user directories in one large directory, it might make sense to use subdirectories that mirror your organization's structure. In this way, people that work in accounting have their directories under a directory named accounting , people that work in engineering would have their directories under engineering , and so on. The benefits of such an approach are that it would be easier on a day-to-day basis to keep track of the storage needs (and usage) for each part of your organization. Obtaining a listing of the files used by everyone in human resources is straightforward. Backing up all the files used by the legal department is easy. With the appropriate structure, flexibility is increased. To continue using the example, assume for a moment that the engineering department is due to take on several large new projects. Because of this, many new engineers are to be hired in the near future. However, there is currently not enough free storage available to support the expected additions to engineering. However, since every person in engineering has their files stored under the engineering directory, it would be a straightforward process to: Procure the additional storage necessary to support engineering Back up everything under the engineering directory Restore the backup onto the new storage Rename the engineering directory on the original storage to something like engineering-archive (before deleting it entirely after running smoothly with the new configuration for a month) Make the necessary changes so that all engineering personnel can access their files on the new storage Of course, such an approach does have its shortcomings. For example, if people frequently move between departments, you must have a way of being informed of such transfers, and you must modify the directory structure appropriately. Otherwise, the structure no longer reflects reality, which makes more work -- not less -- for you in the long run.

Commands:
8.27. cvs 8.27.1. RHBA-2013:1555 - cvs bug fix and enhancement update Updated cvs packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The Concurrent Versions System (CVS) is a version control system that can record the history of your files. CVS only stores the differences between versions, instead of every version of every file you have ever created. CVS also keeps a log of who, when, and why changes occurred. Bug Fix BZ# 671460 When a CVS client tried to establish a GSSAPI-authenticated connection to a DNS load-balanced cluster node, the authentication failed because each node had a unique host name. With this update, the GSSAPI CVS server has been modified to search for any Kerberos key that matches the "cvs" service and any host name. As a result, the CVS server can now authenticate clients using GSSAPI even if the server's host name does not match the domain name, and thus Kerberos principal host name part, common for all cluster nodes. CVS server administrators are advised to deploy two Kerberos principals to each node: a principal matching the node's host name and a principal matching the cluster's domain name. Enhancement BZ# 684789 Previously, the CVS server did not pass the client address to the Pluggable Authentication Modules (PAM) system. As a consequence, it was not possible to distinguish clients by the network address with the PAM system and the system was not able to utilize the client address for authentication or authorization purposes. With this update, the client network address is passed to the PAM subsystem as a remote host item (PAM_RHOST). Also, the terminal item (PAM_TTY) is set to a dummy value "cvs" because some PAM modules cannot work with an unset value. Users of cvs are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands:
Chapter 143. KafkaRebalanceStatus schema reference Used in: KafkaRebalance Property Description conditions List of status conditions. Condition array observedGeneration The generation of the CRD that was last reconciled by the operator. integer sessionId The session identifier for requests to Cruise Control pertaining to this KafkaRebalance resource. This is used by the Kafka Rebalance operator to track the status of ongoing rebalancing operations. string optimizationResult A JSON object describing the optimization result. map

Commands:
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Streams entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2021-12-14 20:09:07 UTC

Commands:
Chapter 3. Configuration 3.1. Configuring Authorization AMQ Broker has role based access control (RBAC) that is used to restrict access to the attributes and methods of MBeans. For instructions on how this is configured see Configuring AMQ Broker . If the broker is configured to use RBAC then the JON plugin must be configured with the correct username and password so that the plugin can authenticate against the broker. Once authenticated any access to MBeans will be restricted based on the BROKER_INSTANCE_DIR /etc/management.xml configuration file. The JON plugin's default user is 'admin' and default password is 'activemq'. You can configure the plugin to use a different user/password to connect to the broker. When the JON plugin is being initiated, it loads the JMX credentials from a configuration file located at BROKER_INSTANCE_DIR /etc/org.jboss.rh-messaging.amq.jon.cfg This configuration file will look something like this. This configuration file also contains the connectorAddress property which is the JMX address that the plugin will use to connect to the broker. 3.2. Populating the Inventory The Inventory is where all manageable resources and groups are shown. To populate the AMQ Broker resources, perform the following steps: Click Resources > Discovery Queue in the left navigation pane. At least one resource, an AMQ Broker instance, is displayed in the Discovery Queue window. Expand the broker resource entry by clicking the down arrow in the Resource Name column. Sub-entries for at least two servers are displayed, including the AMQ 7 Server and the JMX server. The AMQ 7 Server is the entity for which we need to populate the inventory. In the Resource Name column, click the checkbox to the AMQ 7 Server sub-entry. Note that the Import and Ignore buttons are enabled in the bottom left part of the window. Click Import . A Question dialog opens and asks if you want to discover the platform children. Click Yes . You should see a confirmation message stating that the resources were successfully imported. Verify that the import was successful by clicking Resources > Platform in the left navigation pane. You should see multiple entries running in the Platforms window, such as the AMQ Server and the JON Server.

Commands:
principal = username credentials = password connectorAddress = service:jmx:rmi:///jndi/rmi://localhost:11099/jmxrmi
5.240. php-pecl-apc 5.240.1. RHSA-2012:0811 - Low: php-pecl-apc security, bug fix, and enhancement update Updated php-pecl-apc packages that fix one security issue, several bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low 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. The php-pecl-apc packages contain APC (Alternative PHP Cache), the framework for caching and optimization of intermediate PHP code. Security Fix CVE-2010-3294 A cross-site scripting (XSS) flaw was found in the "apc.php" script, which provides a detailed analysis of the internal workings of APC and is shipped as part of the APC extension documentation. A remote attacker could possibly use this flaw to conduct a cross-site scripting attack. Note The administrative script is not deployed upon package installation. It must manually be copied to the web root (the default is "/var/www/html/", for example). In addition, the php-pecl-apc packages have been upgraded to upstream version 3.1.9, which provides a number of bug fixes and enhancements over the version. (BZ# 662655 ) All users of php-pecl-apc are advised to upgrade to these updated packages, which fix these issues and add these enhancements. If the "apc.php" script was previously deployed in the web root, it must manually be re-deployed to replace the vulnerable version to resolve this issue.

Commands:
Chapter 2. Before You Begin 2.1. Comparison: Red Hat Single Sign-On for OpenShift Image and Red Hat Single Sign-On The Red Hat Single Sign-On for OpenShift image version number 7.4.10.GA is based on Red Hat Single Sign-On 7.4.10.GA. There are some differences in functionality between the Red Hat Single Sign-On for OpenShift image and Red Hat Single Sign-On: The Red Hat Single Sign-On for OpenShift image includes all of the functionality of Red Hat Single Sign-On. In addition, the Red Hat Single Sign-On-enabled JBoss EAP image automatically handles OpenID Connect or SAML client registration and configuration for .war deployments that contain <auth-method>KEYCLOAK</auth-method> or <auth-method>KEYCLOAK-SAML</auth-method> in their respective web.xml files. 2.2. Version Compatibility and Support See the xPaaS part of the OpenShift and Atomic Platform Tested Integrations page for details about OpenShift image version compatibility. 2.3. Deprecated Image Streams and Application Templates for Red Hat Single Sign-On for OpenShift Important The Red Hat Single Sign-On for OpenShift image version number between 7.0 and 7.3 are deprecated and they will no longer receive updates of image and application templates. To deploy new applications, it is recommended to use the version 7.4 or 7.4.10.GA of the Red Hat Single Sign-On for OpenShift image along with the application templates specific to these image versions. 2.4. Initial Setup The Tutorials in this guide follow on from and assume an OpenShift instance similar to that created by performing the installation of the OpenShift Container Platform cluster . Important For information related to updating the existing database when migrating Red Hat Single Sign-On for OpenShift image from versions to version 7.4.10.GA, see the Updating Existing Database when Migrating Red Hat Single Sign-On for OpenShift Image to a new version section.

Commands:
Chapter 4. Installing and configuring the Nexus Repository Manager plugin The Nexus Repository Manager plugin displays the information about your build artifacts in your Developer Hub application. The build artifacts are available in the Nexus Repository Manager. Important The Nexus Repository Manager plugin is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information on Red Hat Technology Preview features, see Technology Preview Features Scope . Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page. 4.1. Installation The Nexus Repository Manager plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows: global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-nexus-repository-manager disabled: false 4.2. Configuration Set the proxy to the desired Nexus Repository Manager server in the app-config.yaml file as follows: proxy: '/nexus-repository-manager': target: 'https://<NEXUS_REPOSITORY_MANAGER_URL>' headers: X-Requested-With: 'XMLHttpRequest' # Uncomment the following line to access a private Nexus Repository Manager using a token # Authorization: 'Bearer <YOUR TOKEN>' changeOrigin: true # Change to "false" in case of using self hosted Nexus Repository Manager instance with a self-signed certificate secure: true Optional: Change the base URL of Nexus Repository Manager proxy as follows: nexusRepositoryManager: # default path is `/nexus-repository-manager` proxyPath: /custom-path Optional: Enable the following experimental annotations: nexusRepositoryManager: experimentalAnnotations: true Annotate your entity using the following annotations: metadata: annotations: # insert the chosen annotations here # example nexus-repository-manager/docker.image-name: `<ORGANIZATION>/<REPOSITORY>`,

Commands:
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-nexus-repository-manager disabled: false
proxy: '/nexus-repository-manager': target: 'https://<NEXUS_REPOSITORY_MANAGER_URL>' headers: X-Requested-With: 'XMLHttpRequest' # Uncomment the following line to access a private Nexus Repository Manager using a token # Authorization: 'Bearer <YOUR TOKEN>' changeOrigin: true # Change to "false" in case of using self hosted Nexus Repository Manager instance with a self-signed certificate secure: true
nexusRepositoryManager: # default path is `/nexus-repository-manager` proxyPath: /custom-path
nexusRepositoryManager: experimentalAnnotations: true
metadata: annotations: # insert the chosen annotations here # example nexus-repository-manager/docker.image-name: `<ORGANIZATION>/<REPOSITORY>`,
9.4. Configuration Now that you have developed a custom handler class, package the implementation in a JAR file, then copy this JAR file into the modules directory and edit the module.xml file in the same directory and add then edit standalone.xml or domain.xml file, locate the "logging" subsystem and add the following entries. Change the above configuration accordingly for AuditHandler, if you are working with Audit Messages.

Commands:
<resource-root path="{your-jar-name}.jar" />
<custom-handler name="COMMAND" class="org.teiid.logging.CommandHandler" module="org.jboss.teiid"> </custom-handler> ..other entries <logger category="org.teiid.COMMAND_LOG"> <level name="DEBUG"/> <handlers> <handler name="COMMAND"/> </handlers> </logger>
Chapter 4. Deploying the central controllers Deploy the central controller cluster in a similar way to a typical overcloud deployment. This cluster does not require any Compute nodes, so you can set the Compute count to 0 to override the default of 1 . The central controller has particular storage and Oslo configuration requirements. Use the following procedure to address these requirements. Procedure Create a file called central/overrides.yaml with settings similar to the following: ComputeCount: 0 is an optional parameter to prevent Compute nodes from being deployed with the central Controller nodes. GlanceBackend: swift uses Object Storage (swift) as the Image Service (glance) back end. Red Hat recommends that the Image service does not use Ceph in this configuration until multi-backend glance support is available. The resulting configuration interacts with the distributed compute nodes (DCNs) in the following ways: The Image service on the DCN creates a cached copy of the image it receives from the central Object Storage back end. The Image service uses HTTP to copy the image from Object Storage to the local disk cache. Each DCN has its own Object Storage volume service. This means that users can schedule Object Storage volumes from the central node into different availability zones, because the Ceph volume service on the DCN uses the local Ceph cluster. Note The central Controller node must be able to connect to the distributed compute node (DCN) site. The central Controller node can use a routed layer 3 connection. Deploy the central Controller node. For example, you can use a deploy.sh file with the following contents:

Commands:
parameter_defaults: NtpServer: - 0.pool.ntp.org - 1.pool.ntp.org ControllerCount: 3 ComputeCount: 0 OvercloudControlFlavor: baremetal OvercloudComputeFlavor: baremetal ControllerSchedulerHints: 'capabilities:node': '0-controller-%index%' GlanceBackend: swift
#!/bin/bash STACK=central source ~/stackrc time openstack overcloud deploy --stack USDSTACK --templates /usr/share/openstack-tripleo-heat-templates/ -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml -e ~/containers-env-file.yaml -e ~/central/overrides.yaml
14.5. Reusing Virtual Databases You can treat your deployed VDB as just another database where the database category is your VDB name and each visible model in your VDB is treated as a schema. This is accomplished via a import-vdb XML element in the vdb.xml definition. By allowing VDB's to referenced other VDBs, users can create reusable database components and reduce the amount of modeling required to create complex transformations. This sample vdb.xml file highlights the import-vdb element and the corresponding import-vdb-reference within the view model's model element: Teiid Designer exposes this capability by allowing users to import metadata from deployed VDBs via the JDBC Import option. Through this import, relational VDB source models are created which structurally represent the Catalog (VDB), Schema (Model) and Tables in Virtual DataBase. When dealing with the these VDB source models there are some limitations or rules, namely: VDB source models are read-only VDB source model name is determined by the deployed model name (schema) from the VDB it was imported from Model names have to be unique within a model project VDB source models have to be imported/created in a project different than the project used to create and deploy the Reuse VDB The JDBC Import Wizard will restrict your options to comply with these rules

Commands:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <vdb version="1" name="PartssupplierViewsVDB"> <property value="false" name="preview"/> <import-vdb import-data-policies="false" version="1" name="PartssupplierSourcesVDB"/> <model visible="true" type="VIRTUAL" name="PartsViewModel" path="/PartssupplierProject/PartsViewModel.xmi"> <property value="1623826484" name="checksum"/> <property value="Relational" name="modelClass"/> <property value="false" name="builtIn"/> <property value="655076658.INDEX" name="indexName"/> <property value="PartssupplierSourcesVDB" name="import-vdb-reference"/> </model> </vdb>
Chapter 4. Configuring Static Routes and the Default Gateway This chapter covers the configuration of static routes and the default gateway. 4.1. Introduction to Understanding Routing and Gateway Routing is a mechanism that allows a system to find the network path to another system. Routing is often handled by devices on the network dedicated to routing (although any device can be configured to perform routing). Therefore, it is often not necessary to configure static routes on Red Hat Enterprise Linux servers or clients. Exceptions include traffic that must pass through an encrypted VPN tunnel or traffic that should take a specific route for reasons of cost or security. A host's routing table will be automatically populated with routes to directly connected networks. The routes examine when the network interfaces are " up " . In order to reach a remote network or host, the system is given the address of a gateway to which traffic should be sent. When a host's interface is configured by DHCP , an address of a gateway that leads to an upstream network or the Internet is usually assigned. This gateway is usually referred to as the default gateway as it is the gateway to use if no better route is known to the system (and present in the routing table). Network administrators often use the first or last host IP address in the network as the gateway address; for example, 192.168.10.1 or 192.168.10.254 . Not to be confused by the address which represents the network itself; in this example, 192.168.10.0 , or the subnet's broadcast address; in this example 192.168.10.255 . The default gateway is traditionally a network router. The default gateway is for any and all traffic which is not destined for the local network and for which no preferred route is specified in the routing table. Note To expand your expertise, you might also be interested in the Red Hat System Administration I (RH124) training course.

Commands:
10.5. Managing Translator Settings Using Management CLI To manage JBoss Data Virtualization translator settings, you can use the same commands as those used for the base JBoss Data Virtualization settings, specifying a particular translator in the command. For example: Available translator names are listed under translator when you run the following command to output current JBoss Data Virtualization settings:

Commands:
/subsystem=teiid/translator= TRANSLATOR_NAME :read-resource
/subsystem=teiid:read-resource
Chapter 3. Deprecated Functionality systemtap component The systemtap-grapher package has been removed from Red Hat Enterprise Linux 6. For more information, see https://access.redhat.com/solutions/757983 . matahari component The Matahari agent framework ( matahari-* ) packages have been removed from Red Hat Enterprise Linux 6. Focus for remote systems management has shifted towards the use of the CIM infrastructure. This infrastructure relies on an already existing standard which provides a greater degree of interoperability for all users. distribution component The following packages have been deprecated and are subjected to removal in a future release of Red Hat Enterprise Linux 6. These packages will not be updated in the Red Hat Enterprise Linux 6 repositories and customers who do not use the MRG-Messaging product are advised to uninstall them from their system. mingw-gcc mingw-boost mingw32-qpid-cpp python-qmf python-qpid qpid-cpp qpid-qmf qpid-tests qpid-tools ruby-qpid saslwrapper Red Hat MRG-Messaging customers will continue to receive updated functionality as part of their regular updates to the product. fence-virt component The libvirt-qpid is no longer part of the fence-virt package. openscap component The openscap-perl subpackage has been removed from openscap .

Commands: