mtpti5iD/redhat-docs_dataset huggingface dataset:
4.350. xinetd 4.350.1. RHBA-2012:1161 - xinetd bug fix update An updated xinetd package that fixes one bug is now available for Red Hat Enterprise Linux 6 Extended Update Support. Xinetd is a secure replacement for inetd, the Internet services daemon. Xinetd provides access control for all services based on the address of the remote host and/or on time of access, and can prevent denial-of-access attacks. Xinetd provides extensive logging, has no limit on the number of server arguments, and allows users to bind specific services to specific IP addresses on a host machine. Each service has its own specific configuration file for Xinetd; the files are located in the /etc/xinetd.d directory. Bug Fix BZ# 841915 Due to incorrect handling of a file descriptor array in the service.c source file, some of the descriptors remained open when xinetd was under heavy load. Additionally, the system log was filled with a large number of messages that took up a lot of disk space over time. This bug has been fixed in the code, xinetd now handles the file descriptors correctly and no longer fills the system log. All users of xinetd are advised to upgrade to this updated package, which fixes this bug. 4.350.2. RHBA-2011:1713 - xinetd bug fix update An updated xinetd package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The xinetd daemon is a secure replacement for inetd, the Internet services daemon. It provides access control for all services based on the address of the remote host and/or on time of access, and can prevent denial of service (DoS) attacks. Bug Fixes BZ# 706976 Previously, the configuration files of the xinetd utility were readable for all users. This update makes the permissions more restrictive and the configuration files are now readable only by root. BZ# 738662 Previously, the /etc/xinet.d/ directory was owned by both the filesystem and xinetd packages. This bug has been fixed, and the directory is now owned only by the filesystem package. Users of xinetd are advised to upgrade to this updated package which fixes these bugs.

Commands:
Chapter 9. Managing domains Identity Service (keystone) domains are additional namespaces that you can create in keystone. Note Identity Service includes a built-in domain called Default . It is suggested you reserve this domain only for service accounts, and create a separate domain for user accounts. 9.1. Viewing a list of domains You can view a list of domains with the openstack domain list command: Example command Example output 9.2. Creating a new domain You can create a new domain with the openstack domain create command: Example command Example output 9.3. Viewing the details of a domain You can view the details of a domain with the openstack domain show command: Example command Example output 9.4. Disabling a domain You can disable and enable domains according to your requirements. Procedure Disable a domain using the --disable option: Example command Confirm that the domain has been disabled: Example command Example output Use the --enable option to re-enable the domain, if required: Example command

Commands:
openstack domain list
+----------------------------------+------------------+---------+--------------------+ | ID | Name | Enabled | Description | +----------------------------------+------------------+---------+--------------------+ | 3abefa6f32c14db9a9703bf5ce6863e1 | TestDomain | True | | | 69436408fdcb44ab9e111691f8e9216d | corp | True | | | a4f61a8feb8d4253b260054c6aa41adb | federated_domain | True | | | default | Default | True | The default domain | +----------------------------------+------------------+---------+--------------------+
openstack domain create TestDomain
+-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | True | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain show TestDomain
+-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | True | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain set TestDomain --disable
openstack domain show TestDomain
+-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | enabled | False | | id | 3abefa6f32c14db9a9703bf5ce6863e1 | | name | TestDomain | +-------------+----------------------------------+
openstack domain set TestDomain --enable
Chapter 18. Setting Time and Date in Red Hat Enterprise Linux 7 The section contains how to set time and date in Red Hat Enterprise Linux 7: The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. Changing the Current Time Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form. Changing the Current Date Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month. The time change is audited by the operating system. For more information see the Auditing Time Change Events section in the Red Hat Certificate System Planning, Installation, and Deployment Guide .

Commands:
timedatectl set-time HH:MM:SS
timedatectl set-time YYYY-MM-DD
7.174. pcre 7.174.1. RHBA-2012:1240 - pcre bug fix release Updated pcre packages that fix four bugs are now available for Red Hat Enterprise Linux 6. The pcre packages provide the Perl-compatible regular expression (PCRE) library. Bug Fixes BZ# 756105 Prior to this update, matching patterns with repeated forward reference failed to match if the first character was not repeated at the start of the matching text. This update modifies the matching algorithm not to expect the first character again. Now, patterns with repeated forward references match as expected. BZ# 759475 Prior to this update, case-less patterns in UTF-8 mode did not match characters at the end of input text with encoding length that was shorter than the encoding length of character in the pattern, for example "/a/8i".This update modifies the pcre library to count the length of matched characters correctly. Now, case-less patterns match characters with different encoding length correctly even at the end of an input string. BZ# 799003 Prior to this update, manual pages for the pcre library contained misprints. This update modifies the manual pages. BZ#842000 Prior to this update, applications that were compiled with the libpcrecpp library from the pcre version 6 could not been executed against libpcrecpp library from the pcre version 7 because the application binary interface (ABI) was mismatched. This update adds the compat RE::Init() function for the pcre version 6 to the pcre version 7 libpcrecpp library. Applications that were compiled on Red Hat Enterprise Linux 5 and use the RE::Init function can now be executed on Red Hat Enterprise Linux 6. All users of pcre are advised to upgrade to these updated packages, which fix these bugs.

Commands:
API overview OpenShift Container Platform 4.17 Overview content for the OpenShift Container Platform API Red Hat OpenShift Documentation Team

Commands:
oc debug node/<node>
chroot /host
systemctl cat kubelet
/etc/systemd/system/kubelet.service.d/20-logging.conf [Service] Environment="KUBELET_LOG_LEVEL=2"
echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-master-kubelet-loglevel spec: config: ignition: version: 3.2.0 systemd: units: - name: kubelet.service enabled: true dropins: - name: 30-logging.conf contents: | [Service] Environment="KUBELET_LOG_LEVEL=2"
oc adm node-logs --role master -u kubelet
oc adm node-logs --role worker -u kubelet
journalctl -b -f -u kubelet.service
sudo tail -f /var/log/containers/*
- for n in USD(oc get node --no-headers | awk '{print USD1}'); do oc adm node-logs USDn | gzip > USDn.log.gz; done
22.4. JBoss Operations Network Agent The JBoss Operations Network Agent is a standalone Java application. Only one agent is required per machine, regardless of how many resources you require the agent to manage. The JBoss Operations Network Agent does not ship fully configured. Once the agent has been installed and configured it can be run as a Windows service from a console, or run as a daemon or init.d script in a UNIX environment. A JBoss Operations Network Agent must be installed on each of the machines being monitored in order to collect data. The JBoss Operations Network Agent is typically installed on the same machine on which Red Hat JBoss Data Grid is running, however where there are multiple machines an agent must be installed on each machine. Note For more detailed information about configuring JBoss Operations Network agents, see the JBoss Operations Network Installation Guide . Report a bug

Commands:
Part VII. Designing a decision service using guided rule templates As a business analyst or business rules developer, you can define business rule templates using the guided rule templates designer in Business Central. These guided rule templates provide a reusable rule structure for multiple rules that are compiled into Drools Rule Language (DRL) and form the core of the decision service for your project. Note You can also design your decision service using Decision Model and Notation (DMN) models instead of rule-based or table-based assets. For information about DMN support in Red Hat Decision Manager 7.13, see the following resources: Getting started with decision services (step-by-step tutorial with a DMN decision service example) Designing a decision service using DMN models (overview of DMN support and capabilities in Red Hat Decision Manager) Prerequisites The space and project for the guided rule templates have been created in Business Central. Each asset is associated with a project assigned to a space. For details, see Getting started with decision services .

Commands:
2.2. Indexing Modes 2.2.1. Managing Indexes In Red Hat JBoss Data Grid's Query Module there are two options for storing indexes: Each node can maintain an individual copy of the global index. The index can be shared across all nodes. When the indexes are stored locally, by setting indexLocalOnly to true , each write to cache must be forwarded to all other nodes so that they can update their indexes. If the index is shared, by setting indexLocalOnly to false , only the node where the write originates is required to update the shared index. Lucene provides an abstraction of the directory structure called directory provider , which is used to store the index. The index can be stored, for example, as in-memory, on filesystem, or in distributed cache. Report a bug 2.2.2. Managing the Index in Local Mode In local mode, any Lucene Directory implementation may be used. The indexLocalOnly option is meaningless in local mode. Report a bug 2.2.3. Managing the Index in Replicated Mode In replication mode, each node can store its own local copy of the index. To store indexes locally on each node, set indexLocalOnly to false , so that each node will apply the required updates it receives from other nodes in addition to the updates started locally. Any Directory implementation can be used. When a new node is started it must receive an up to date copy of the index. Usually this can be done via resync, however being an external operation, this may result in a slightly out of sync index, particularly where updates are frequent. Alternatively, if a shared storage for indexes is used (see Section 2.3.3, "Infinispan Directory Provider" ), indexLocalOnly must be set to true so that each node will only apply the changes originated locally. While there is no risk of having an out of sync index, this causes contention on the node used for updating the index. The following diagram demonstrates a replicated deployment where each node has a local index. Figure 2.1. Replicated Cache Querying Report a bug 2.2.4. Managing the Index in Distribution Mode In both Distribution modes, the shared index must be used, with the indexLocalOnly set to true . The following diagram shows a deployment with a shared index. Figure 2.2. Querying with a Shared Index Report a bug 2.2.5. Managing the Index in Invalidation Mode Indexing and searching of elements in Invalidation mode is not supported. Report a bug

Commands:
Chapter 108. AclRuleTopicResource schema reference Used in: AclRule The type property is a discriminator that distinguishes use of the AclRuleTopicResource type from AclRuleGroupResource , AclRuleClusterResource , AclRuleTransactionalIdResource . It must have the value topic for the type AclRuleTopicResource . Property Description type Must be topic . string name Name of resource for which given ACL rule applies. Can be combined with patternType field to use prefix pattern. string patternType Describes the pattern used in the resource field. The supported types are literal and prefix . With literal pattern type, the resource field will be used as a definition of a full topic name. With prefix pattern type, the resource name will be used only as a prefix. Default value is literal . string (one of [prefix, literal])

Commands:
3.9. Renaming Client Machines This section explains how to rename an IdM client. The process involves: the section called "Identifying Current Service and Keytab Configuration" . the section called "Removing the Client Machine from the IdM Domain" . the section called "Re-enrolling the Client with a New Host Name" . Warning Renaming a client is a manual procedure. Red Hat does not recommend it unless changing the host name is absolutely required. Identifying Current Service and Keytab Configuration Before uninstalling the current client, make note of certain settings for the client. You will apply this configuration after re-enrolling the machine with a new host name. Identify which services are running on the machine: Use the ipa service-find command, and identify services with certificates in the output: In addition, each host has a default host service which does not appear in the ipa service-find output. The service principal for the host service, also called a host principal , is host/client.example.com . Identify all host groups to which the machine belongs. For all service principals displayed by ipa service-find client.example.com , determine the location of the corresponding keytabs on client.example.com . Each service on the client system has a Kerberos principal in the form service_name/hostname@REALM , such as ldap/client.example.com@EXAMPLE.COM . Removing the Client Machine from the IdM Domain Unenroll the client machine from the IdM domain. See Section 3.7, "Uninstalling a Client" . For each identified keytab other than /etc/krb5.keytab , remove the old principals: See Section 29.4, "Removing Keytabs" . On an IdM server, remove the host entry. This removes all services and revokes all certificates issued for that host: At this point, the host is completely removed from IdM. Re-enrolling the Client with a New Host Name Rename the machine as required. Re-enroll the machine as an IdM client. See Section 3.8, "Re-enrolling a Client into the IdM Domain" . On an IdM server, add a new keytab for every service identified in the section called "Identifying Current Service and Keytab Configuration" . Generate certificates for services that had a certificate assigned in the section called "Identifying Current Service and Keytab Configuration" . You can do this: Using the IdM administration tools. See Chapter 24, Managing Certificates for Users, Hosts, and Services . Using the certmonger utility. See Working with certmonger in the System-Level Authentication Guide or the certmonger (8) man page. Re-add the client to the host groups identified in the section called "Identifying Current Service and Keytab Configuration" . See Section 13.3, "Adding and Removing User or Host Group Members" .

Commands:
ipa service-find client.example.com
ipa hostgroup-find client.example.com
ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
ipa host-del client.example.com
ipa service-add service_name/new_host_name
E.2.11. /proc/iomem This file shows you the current map of the system's memory for each physical device: The first column displays the memory registers used by each of the different types of memory. The second column lists the kind of memory located within those registers and displays which memory registers are used by the kernel within the system RAM or, if the network interface card has multiple Ethernet ports, the memory registers assigned for each port.

Commands:
00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-07ffffff : System RAM 00100000-00291ba8 : Kernel code 00291ba9-002e09cb : Kernel data e0000000-e3ffffff : VIA Technologies, Inc. VT82C597 [Apollo VP3] e4000000-e7ffffff : PCI Bus #01 e4000000-e4003fff : Matrox Graphics, Inc. MGA G200 AGP e5000000-e57fffff : Matrox Graphics, Inc. MGA G200 AGP e8000000-e8ffffff : PCI Bus #01 e8000000-e8ffffff : Matrox Graphics, Inc. MGA G200 AGP ea000000-ea00007f : Digital Equipment Corporation DECchip 21140 [FasterNet] ea000000-ea00007f : tulip ffff0000-ffffffff : reserved
Chapter 10. Adding metadata to instances Warning The content for this feature is available in this release as a Documentation Preview , and therefore is not fully verified by Red Hat. Use it only for testing, and do not use in a production environment. The Compute (nova) service uses metadata to pass configuration information to instances on launch. The instance can access the metadata by using a config drive or the metadata service. Config drive By default, every instance has a config drive. Config drives are special drives that you can attach to an instance when it boots. The config drive is presented to the instance as a read-only drive. The instance can mount this drive and read files from it to get information that is normally available through the metadata service. Metadata service The Compute service provides the metadata service as a REST API, which can be used to retrieve data specific to an instance. Instances access this service at 169.254.169.254 or at fe80::a9fe:a9fe . 10.1. Types of instance metadata Cloud users, cloud administrators, and the Compute service can pass metadata to instances: Cloud user provided data Cloud users can specify additional data to use when they launch an instance, such as a shell script that the instance runs on boot. The cloud user can pass data to instances by using the user data feature, and by passing key-value pairs as required properties when creating or updating an instance. Cloud administrator provided data The Red Hat OpenStack Services on OpenShift (RHOSO) administrator uses the vendordata feature to pass data to instances. The Compute service provides the vendordata modules StaticJSON and DynamicJSON to allow administrators to pass metadata to instances: StaticJSON : (Default) Use for metadata that is the same for all instances. DynamicJSON : Use for metadata that is different for each instance. This module makes a request to an external REST service to determine what metadata to add to an instance. Vendordata configuration is located in one of the following read-only files on the instance: /openstack/{version}/vendor_data.json /openstack/{version}/vendor_data2.json Compute service provided data The Compute service uses its internal implementation of the metadata service to pass information to the instance, such as the requested hostname for the instance, and the availability zone the instance is in. This happens by default and requires no configuration by the cloud user or administrator.

Commands:
Chapter 4. Configuring automatic registration and management You can automatically register your systems with Red Hat by using an activation key for the image. You can add an activation key to the image during the image building process. For that, follow the steps to enabling automatic registration with the Red Hat Remote Host Configuration (rhc) client. Prerequisites You must have a Red Hat Hybrid Cloud Console account. You must have a Remote Host Configuration and Management org ID and activation key for your RHEL subscription. If you have Organization Administrator access for your account, you can set up an activation key at the Activation keys page. You started to create a new OSTree image in the Hybrid Cloud Console. See Building a RHEL image with custom repositories . Procedure In the Activation Keys page, perform the following steps: From the Activation key to use for this image dropdown menu, select one activation key to use for the image from your Organization ID. No activation keys found - If you do not have an activation key from your Organization ID, you can choose the "default activation key", a preset key with the basic configuration, by completing the following step: Click the Create activation key button. The Select activation key dropdown menu enables the "activation-key-default". Manage the activation key by accessing Activation keys . You can edit the System Purpose , the Workload , and also add Additional repositories . Click . Note After you register a RHEL for Edge device, it is not automatically removed after a period of inactivity. If you want to unregister and remove the device from the Red Hat Hybrid Cloud Console , you must unregister your device to remove it. To unregister the device, go to the Red Hat Hybrid Cloud Console and click Red Hat Insights > Inventory > Images , find your system device, select it, and click Delete . Additional resources Creating an activation key

Commands: