mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. alarming This chapter describes the commands under the alarming command. 8.1. alarming capabilities list List capabilities of alarming service Usage: Table 8.1. Optional Arguments Value Summary -h, --help Show this help message and exit Table 8.2. Output Formatters Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 8.3. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 8.4. Shell Formatter Value Summary --prefix PREFIX Add a prefix to all variable names Table 8.5. Table Formatter Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack alarming capabilities list [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty]
E.3.12. /proc/PID/ Out of Memory (OOM) refers to a computing state where all available memory, including swap space, has been allocated. When this situation occurs, it will cause the system to panic and stop functioning as expected. There is a switch that controls OOM behavior in /proc/sys/vm/panic_on_oom . When set to 1 the kernel will panic on OOM. A setting of 0 instructs the kernel to call a function named oom_killer on an OOM. Usually, oom_killer can kill rogue processes and the system will survive. The easiest way to change this is to echo the new value to /proc/sys/vm/panic_on_oom . It is also possible to prioritize which processes get killed by adjusting the oom_killer score. In /proc/ PID / there are two tools labeled oom_adj and oom_score . Valid scores for oom_adj are in the range -16 to +15. To see the current oom_killer score, view the oom_score for the process. oom_killer will kill processes with the highest scores first. This example adjusts the oom_score of a process with a PID of 12465 to make it less likely that oom_killer will kill it. There is also a special value of -17, which disables oom_killer for that process. In the example below, oom_score returns a value of 0, indicating that this process would not be killed. A function called badness() is used to determine the actual score for each process. This is done by adding up 'points' for each examined process. The process scoring is done in the following way: The basis of each process's score is its memory size. The memory size of any of the process's children (not including a kernel thread) is also added to the score The process's score is increased for 'niced' processes and decreased for long running processes. Processes with the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities have their scores reduced. The final score is then bitshifted by the value saved in the oom_adj file. Thus, a process with the highest oom_score value will most probably be a non-privileged, recently started process that, along with its children, uses a large amount of memory, has been 'niced', and handles no raw I/O.

Commands:
cat /proc/sys/vm/panic_on_oom 1 echo 0 > /proc/sys/vm/panic_on_oom cat /proc/sys/vm/panic_on_oom 0
cat /proc/12465/oom_score 79872 echo -5 > /proc/12465/oom_adj cat /proc/12465/oom_score 78
cat /proc/12465/oom_score 78 echo -17 > /proc/12465/oom_adj cat /proc/12465/oom_score 0
4.159. lohit-gujarati-fonts 4.159.1. RHEA-2011:1134 - lohit-gujarati-fonts enhancement update An updated lohit-gujarati-fonts package which adds one enhancement is now available for Red Hat Enterprise Linux 6. The lohit-gujarati-fonts package provides a free Gujarati TrueType/OpenType font. Enhancement BZ# 691287 Unicode 6.0, the most recent major version of the Unicode standard, introduces the Indian Rupee Sign (U+20B9), the new official Indian currency symbol. With this update, the lohit-gujarati-fonts package now includes a glyph for this new character. All users requiring the Indian rupee sign should install this updated package, which adds this enhancement.

Commands:
Chapter 18. Additional resources Installing and configuring Red Hat Decision Manager on Red Hat JBoss EAP 7.4 Planning a Red Hat Decision Manager installation Installing and configuring Red Hat Decision Manager on Red Hat JBoss EAP 7.4 Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 4 using Operators Deploying an Red Hat Decision Manager environment on Red Hat OpenShift Container Platform 3 using templates

Commands:
Chapter 11. Lifecyle bucket configuration in Multicloud Object Gateway Multicloud Object Gateway (MCG) lifecycle provides a way to reduce storage costs due to accumulated data objects. Deletion of expired objects is a simplified way that enables handling of unused data. Data expiration is a part of Amazon Web Services (AWS) lifecycle management and sets an expiration date for automatic deletion. The minimal time resolution of the lifecycle expiration is one day. For more information, see Expiring objects . AWS S3 API is used to configure lifecyle bucket in MCG. For information about the data bucket APIs and their support level, see Support of Multicloud Object Gateway data bucket APIs . There are a few limitations with the expiratation rule API for MCG in comaparison with AWS: ExpiredObjectDeleteMarker is accepted but it is not processed. No option to define specific non-current version's expiration conditions

Commands:
Preface The Red Hat Quay application programming interface (API) provides a comprehensive, RESTful interface for managing and automating tasks within Red Hat Quay. Designed around the OAuth 2.0 protocol , this API enables secure, fine-grained access to Red Hat Quay resources, and allows administrators and users to perform such actions as creating repositories, managing images, setting permissions, and more. Red Hat Quay follows Semantic Versioning (SemVer) principles, ensuring predictable API stability across releases, such as: Major releases : Introduce new capabilities. Might include breaking changes to API compatibility. For example, the API of Red Hat Quay 2.0 differs from Red Hat Quay 3.0 . Minor releases : Add new functionality in a backward-compatible manner. For example, a 3.y release adds functionality to the version 3. release. Patch releases : Deliver bug fixes and improvements while preserving backward compatibility with minor releases, such as 3.y.z . The following guide describes the Red Hat Quay API in more detail, and provides details on the following topics: OAuth 2 access tokens and how they compare to traditional API tokens and Red Hat Quay's robot tokens Generating an OAuth 2 access token Best practices for token management OAuth 2 access token capabilities Using the Red Hat Quay API Red Hat Quay API configuration examples

Commands:
14.3.3.2. Primary Domain Controller (PDC) using LDAP The most powerful and versatile implementation of a Samba PDC is its ability to have an LDAP password backend. LDAP is highly scalable. LDAP database servers can be used for redundancy and fail-over by replicating to a Samba BDC. Groups of LDAP PDCs and BDCs with load balancing are ideal for an enterprise environment. On the other hand, LDAP configurations are inherently complex to setup and maintain. If SSL is to be incorporated with LDAP, the complexity instantly multiplies. Even so, with careful and precise planning, LDAP is an ideal solution for enterprise environments. Note the passdb backend directive as well as specific LDAP suffix specifications. Although the Samba configuration for LDAP is straightforward, the installation of OpenLDAP is not trivial. LDAP should be installed and configured before any Samba configuration. Also notice that Samba and LDAP do not need to be on the same server to function. It is highly recommended to separate the two in an enterprise environment. Note Implementing LDAP in this smb.conf file assumes that a working LDAP server has been successfully installed on ldap.example.com .

Commands:
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines %u The following specifies the default logon script Per user logon scripts can be specified in the user account using pdbedit logon script = scripts\logon.bat This sets the default profile path. Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 Other resource shares
Appendix A. Sample environment file: creating a Ceph Storage cluster The following custom environment file uses many of the options described throughout Chapter 2, Preparing overcloud nodes . This sample does not include any commented-out options. For an overview on environment files, see Environment Files (from the Advanced Overcloud Customization guide). /home/stack/templates/storage-config.yaml 1 The parameter_defaults section modifies the default values for parameters in all templates. Most of the entries listed here are described in Chapter 4, Customizing the Storage service . 2 If you are deploying the Ceph Object Gateway, you can use Ceph Object Storage ( ceph-rgw ) as a backup target. To configure this, set CinderBackupBackend to swift . See Section 4.2, "Enabling the Ceph Object Gateway" for details. 3 The CephAnsibleDisksConfig section defines a custom disk layout for deployments using BlueStore. 4 For each role, the *Count parameters assign a number of nodes while the Overcloud*Flavor parameters assign a flavor. For example, ControllerCount: 3 assigns 3 nodes to the Controller role, and OvercloudControlFlavor: control sets each of those roles to use the control flavor. See Section 7.1, "Assigning nodes and flavors to roles" for details. Note The CephMonCount , CephMdsCount , OvercloudCephMonFlavor , and OvercloudCephMdsFlavor parameters (along with the ceph-mon and ceph-mds flavors) will only be valid if you created a custom CephMON and CephMds role, as described in Chapter 3, Deploying Ceph services on dedicated nodes . 5 NeutronNetworkType: sets the network type that the neutron service should use (in this case, vxlan ).

Commands:
parameter_defaults: 1 CinderBackupBackend: ceph 2 CephAnsibleDisksConfig: 3 osd_scenario: lvm osd_objectstore: bluestore dmcrypt: true devices: - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:10:0 - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:11:0 - /dev/nvme0n1 ControllerCount: 3 4 OvercloudControlFlavor: control ComputeCount: 3 OvercloudComputeFlavor: compute CephStorageCount: 3 OvercloudCephStorageFlavor: ceph-storage CephMonCount: 3 OvercloudCephMonFlavor: ceph-mon CephMdsCount: 3 OvercloudCephMdsFlavor: ceph-mds NeutronNetworkType: vxlan 5
10.5. Updating the TLS Certificates Used for Attribute Encryption Attribute encryption is based on the TLS certificate. To prevent that attribute encryption fails after renewing or replacing the TLS certificate: Export the database with decrypted attributes. See Section 10.4.1, "Exporting an Encrypted Database" . Create a new Certificate Signing Request (CSR). See Section 9.3.1, "Creating a Certificate Signing Request" . Install the new certificate. See Section 9.3.4, "Installing a Server Certificate" . Stop the Directory Server instance: Edit the /etc/dirsrv/slapd- instance_name /dse.ldif file and remove the following entries including their attributes: cn=AES,cn=encrypted attribute keys,cn= database_name ,cn=ldbm database,cn=plugins,cn=config cn=3DES,cn=encrypted attribute keys,cn= database_name ,cn=ldbm database,cn=plugins,cn=config Important Remove the entries for all databases. If any entry that contains the nsSymmetricKey attribute is left in the /etc/dirsrv/slapd- instance_name /dse.ldif file, Directory Server will fail to start. Import the database. See Section 10.4.2, "Importing an LDIF File into an Encrypted Database" . Start the instance:

Commands:
dsctl instance_name stop
dsctl instance_name start
Chapter 2. Choosing a backend Secrets (such as certificates, API keys, and passwords) can either be stored as an encrypted blob in the barbican database, or directly in a secure storage system. To store the secrets as an encrypted blob in the barbican database, the following options are available. Simple crypto plugin - The simple crypto plugin is enabled by default and uses a single symmetric key to encrypt the blob of secrets. This key is stored in plain text in the barbican.conf file. PKCS#11 crypto plugin - The PKCS#11 crypto plugin encrypts secrets with project-specific key encryption keys (KEK), which are stored in the barbican database. These project-specific KEKs are encrypted by a master KEK, which is stored in a hardware security module (HSM). All encryption and decryption operations take place in the HSM, rather than in-process memory. The PKCS#11 plugin communicates with the HSM through the PKCS#11 protocol. Because the encryption is done in secure hardware, and a different KEK is used per project, this option is more secure than the simple crypto plugin. Alternatively, you can store the secrets directly in a secure storage system: KMIP plugin - The Key Management Interoperability Protocol (KMIP) plugin works with devices that have KIMP enabled, such as an HSM. Secrets are stored directly on the device instead of the barbican database. The plugin can authenticate to the device either with a username and password or a client certificate stored in the barbican.conf file. Red Hat Certificate System (dogtag) - Red Hat Certificate System is a Common Criteria and FIPS certified security framework for managing various aspects of Public Key Infrastructure (PKI). The key recovery authority (KRA) subsystem stores secrets as encrypted blobs in its database. The master encryption keys are stored in either a software-based Network Security Services (NSS) database or an HSM. For more information about Red Hat Certificate System, see Product Documentation for Red Hat Certificate System . Note Regarding high availability (HA) options: The barbican service runs within Apache and is configured by director to use HAProxy for high availability. HA options for the back end layer will depend on the back end being used. For example, for simple crypto, all the barbican instances have the same encryption key in the config file, resulting in a simple HA configuration. 2.1. Migrating between backends Barbican allows you to define a different backend for a project. If no mapping exists for a project, then secrets are stored in the global default backend. This means that multiple backends can be configured, but there must be at least one global backend defined. The heat templates supplied for the different backends contain the parameters that set each backend as the default. If you do store secrets in a certain backend and then decide to migrate to a new backend, you can keep the old backend available while enabling the new backend as the global default (or as a project-specific backend). As a result, the old secrets remain available through the old backend.

Commands:
4.4. Booting the Hosts Consult the documentation for your PXE card to configure the host to boot via PXE. When the diskless client boots, it mounts the remote root/ directory in the diskless directory as read-only. It also mounts its individual snapshot directory as read/write. Then it mounts all the files and directories in the files and files.custom files using the mount -o bind over the read-only diskless directory to allow applications to write to the root directory of the diskless environment if they need to.

Commands:
7.40. dovecot 7.40.1. RHBA-2015:1348 - dovecot bug fix and enhancement update Updated dovecot packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. Dovecot is an IMAP server for Linux and other UNIX-like systems, primarily written with security in mind. It also contains a small POP3 server, and supports e-mail in either the maildir or mbox format. The SQL drivers and authentication plug-ins are provided as subpackages. Bug Fixes BZ# 723228 The ports used by dovecot were in some cases unavailable during the boot process by other services, which caused dovecot to fail to start and display an "Address already in use" error. This update configures the portreserve service to ensure that dovecot's ports stay available during the boot process, which prevents the described failure from occurring. BZ# 771336 Previously, the dovecot utility used too small a login input buffer for Kerberos authentication. As a consequence, users who attempted to use Kerberos authentication were not able to log in. This updated version of dovecot uses a bigger input buffer, and users can now authenticate to their email accounts using a Kerberos ticket. BZ# 813957 Prior to this update, dovecot logged a redundant "unable to get certificate" error message when no certification revocation list (CRL) was available. With this update, dovecot no longer treats missing CRL as an error, and no longer logs an error in the mentioned scenario. BZ# 961466 When the LIST-STATUS extension was used with certain hierarchy separator symbols, dovecot in some cases terminated unexpectedly. Consequently, the user was unable to list the contents of their e-mail folder. This update fixes the code for traversing folders, and using LIST-STATUS no longer causes dovecot to crash. BZ# 1131749 Previously, after executing the "uid copy" command against a non-existent mailbox, the dovecot server became unresponsive. As a consequence, the user could not download e-mails unless recovered manually. A patch has been provided to fix this bug, and dovecot no longer hangs in the aforementioned scenario. Enhancement BZ# 1153041 With this update, it is possible to configure which Secure Sockets Layer (SSL) protocols dovecot allows. Among other things, this allows users to disable SSLv3 connections and thus mitigate the impact of the POODLE vulnerability. Due to security concerns, SSLv2 and SSLv3 are now also disabled by default, and the user has to be allow them manually if required. Users of dovecot are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 6. References This chapter enumerates other references for more information about SystemTap. It is advisable that you see these sources in the course of writing advanced probes and tapsets. SystemTap Wiki The SystemTap Wiki is a collection of links and articles related to the deployment, usage, and development of SystemTap. You can find it at http://sourceware.org/systemtap/wiki/HomePage . SystemTap Tutorial Much of the content in this book comes from the SystemTap Tutorial . The SystemTap Tutorial is a more appropriate reference for users with intermediate to advanced knowledge of C++ and kernel development, and can be found at http://sourceware.org/systemtap/tutorial/ . man stapprobes The stapprobes man page enumerates a variety of probe points supported by SystemTap, along with additional aliases defined by the SystemTap tapset library. The bottom of the man page includes a list of other man pages enumerating similar probe points for specific system components, such as stapprobes.scsi , stapprobes.kprocess , stapprobes.signal , etc. man stapfuncs The stapfuncs man page enumerates numerous functions supported by the SystemTap tapset library, along with the prescribed syntax for each one. Note, however, that this is not a complete list of all supported functions; there are more undocumented functions available. SystemTap Language Reference This document is a comprehensive reference of SystemTap's language constructs and syntax. It is recommended for users with a rudimentary to intermediate knowledge of C++ and other similar programming languages. The SystemTap Language Reference is available to all users at http://sourceware.org/systemtap/langref/ Tapset Developers Guide Once you have sufficient proficiency in writing SystemTap scripts, you can then try your hand out on writing your own tapsets. The Tapset Developers Guide describes how to add functions to your tapset library. Test Suite The systemtap-testsuite package allows you to test the entire SystemTap toolchain without having to build from source. In addition, it also contains numerous examples of SystemTap scripts you can study and test; some of these scripts are also documented in Chapter 4, Useful SystemTap Scripts . By default, the example scripts included in systemtap-testsuite are located in /usr/share/systemtap/testsuite/systemtap.examples .

Commands:
Chapter 8. Recertification requests 8.1. Recertifying Cloud Instance Type Procedure Log in to Red Hat Certification and click the New Certification button. Select the Red Hat product, version, and platform for certification and click . State the Vendor, Make, Model (Name and Size), and Architecture of the product to be certified . Provide URL of Cloud Instance Type to be certified and click . After the request is created, monitor the request for questions from the review team. 8.2. Certifying Cloud Instance Type Pass-Through An Instance Type Pass-Through certification essentially creates a copy of a certified Cloud Instance Type, and lists it in a different vendor name, a different make, or a different model. Pass-through is used when a vendor sells their Instance Type to a partner who then rebrands it, or if a vendor sells two or more Instance Type Products where one Instance Type Product is a super set of the others. In such situations, the vendor should have tested in the existing Cloud Instance Type Product certification as that covers all the Instances Sizes in the new Pass-Through certification. After the Cloud Instance Type Product is certified, the Cloud Instance Type Size Pass-Through certification is performed. Each Cloud Instance Type Size individually undergoes Pass-Through certification and is published to catalog. Procedure Log in to the Red Hat Certification Portal . Click the existing cloud instance certification and select Related Certification . Click Add Related Certification , and select Pass-through . Select the appropriate product: If the product already exists in the list, then select it. If the product is not in the list, then create a new product. Click New Certification to create the new pass-through certification. The Red Hat certification team certifies and publishes the newly created Cloud Instance Type Certification. After the certificate is published, it becomes public for other partners to refer as a pass-through Cloud Instance Type. 8.3. Completing certification A certification is complete once all the items on the official test plan have been reviewed and found to have passing results. At this point the certification can be closed and published. After a successful certification, the certified product is listed on Red Hat Certified Cloud Instance Type Page .

Commands: