mtpti5iD/redhat-docs_dataset huggingface dataset:
4.322. texlive-texmf 4.322.1. RHBA-2011:1677 - texlive-texmf bug fix update Updated texlive-texmf packages that fix one bug are now available for Red Hat Enterprise Linux 6. The texlive-texmf packages contain a texmf distribution based upon TeXLive. TeXLive is an implementation of TeX for Linux or UNIX systems. TeX takes a text file and a set of formatting commands as input and creates a printable file as output. Usually, TeX is used in conjunction with a higher level formatting package like LaTeX or PlainTeX. Bug Fix BZ# 711344 Prior to this update, LaTeX did not build documents if the source file was more than five years old. An error message appeared and requested manual confirmation which stopped the build process. With this update, the error message has been changed to a message stating that the source file is more than five years old. Now, the build process completes successfully. All users of texlive-texmf are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.4. Creating a Fencing Device The following command creates a stonith device. If you use a single fence device for several nodes, using a different port of each node, you do not need to create a device separately for each node. Instead you can use the pcmk_host_map option to define which port goes to which node. For example, the following command creates a single fencing device called myapc-west-13 that uses an APC powerswitch called west-apc and uses port 15 for node west-13 . The following example, however, uses the APC powerswitch named west-apc to fence nodes west-13 using port 15, west-14 using port 17, west-15 using port 18, and west-16 using port 19.

Commands:
pcs stonith create stonith_id stonith_device_type [ stonith_device_options ]
pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s
pcs stonith create myapc-west-13 fence_apc pcmk_host_list="west-13" ipaddr="west-apc" login="apc" passwd="apc" port="15"
pcs stonith create myapc fence_apc pcmk_host_list="west-13,west-14,west-15,west-16" pcmk_host_map="west-13:15;west-14:17;west-15:18;west-16:19" ipaddr="west-apc" login="apc" passwd="apc"
Chapter 1. Preparing to deploy OpenShift Data Foundation When you deploy OpenShift Data Foundation on OpenShift Container Platform using the local storage devices on any platform, you can create internal cluster resources. This approach internally provisions base services so that all the applications can access additional storage classes. You can also deploy OpenShift Data Foundation to use an external Red Hat Ceph Storage cluster and IBM FlashSystem. For instructions, see Deploying OpenShift Data Foundation in external mode . External mode deployment works on clusters that are detected as non-cloud. If your cluster is not detected correctly, open up a bug in Bugzilla . Before you begin the deployment of Red Hat OpenShift Data Foundation using a local storage, ensure that you meet the resource requirements. See Requirements for installing OpenShift Data Foundation using local storage devices . After completing the preparatory steps, perform the following procedures: Install the Local Storage Operator . Install the Red Hat OpenShift Data Foundation Operator . Create the OpenShift Data Foundation cluster on any platform . 1.1. Requirements for installing OpenShift Data Foundation using local storage devices Node requirements The cluster must consist of at least three OpenShift Container Platform worker or infrastructure nodes with locally attached-storage devices on each of them. Each of the three selected nodes must have at least one raw block device available. OpenShift Data Foundation uses the one or more available raw block devices. Note Make sure that the devices have a unique by-id device name for each available raw block device. The devices you use must be empty, the disks must not include Physical Volumes (PVs), Volume Groups (VGs), or Logical Volumes (LVs) remaining on the disk. For more information, see the Resource requirements section in the Planning guide . Disaster recovery requirements Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced subscription. A valid Red Hat Advanced Cluster Management (RHACM) for Kubernetes subscription. To know in detail how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . For detailed disaster recovery solution requirements, see Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads guide, and Requirements and recommendations section of the Install guide in Red Hat Advanced Cluster Management for Kubernetes documentation. Minimum starting node requirements An OpenShift Data Foundation cluster is deployed with a minimum configuration when the resource requirement for a standard deployment is not met. For more information, see the Resource requirements section in the Planning guide .

Commands:
Chapter 17. Setting up Content Synchronization Using the SyncRepl Protocol Using the Content Synchronization plug-in, Directory Server supports the SyncRepl protocol according to RFC 4533 . This protocol enables LDAP servers and clients to use Red Hat Directory Server as a source to synchronize their local database with the changing content of Directory Server. To use the SyncRepl protocol: Enable the Content Synchronization plug-in in Directory Server and optionally create a new user which the client will use to bind to Directory Server. The account must have permissions to read the content in the directory. Configure the client. For example, set the search base for a subtree to synchronize. For further details, see your client's documentation. 17.1. Configuring the Content Synchronization Plug-in Using the Command Line To configure the Content Synchronization plug-in using the command line: The Content Synchronization plug-in requires the Retro Changelog plug-in to log the nsuniqueid attribute: To verify if the retro changelog is already enabled, enter: If the nsslapd-pluginEnabled parameter is set to off , the retro changelog is disabled. To enable, see Section 15.21.1, "Enabling the Retro Changelog Plug-in" . Add the nsuniqueid attribute to retro changelog plug-in configuration: Optionally, apply the following recommendations for improved performance: Set maximum validity for entries in the retro change log. For example, to set 2 days ( 2d ): If you know which back end or subtree clients access to synchronize data, limit the scope of the Retro Changelog plug-in. For example, to exclude the cn=demo,dc=example,dc=com subtree, enter: Enable the Content Synchronization plug-in: Using the defaults, Directory Server creates an access control instruction (ACI) in the oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config entry that enables all users to use the SyncRepl protocol: Optionally, update the ACI to limit using the SyncRepl control. For further details about ACIs, see Section 18.11, "Defining Bind Rules" . Restart Directory Server: Clients are now able to synchronize data with Directory Server using the SyncRepl protocol.

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog show nsslapd-pluginEnabled: off
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog set --attribute nsuniqueid:targetUniqueId
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 2d
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog set --exclude-suffix "cn=demo,dc=example,dc=com"
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin set --enabled on "Content Synchronization"
aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( read, search ) userdn = "ldap:///all";)
dsctl instance_name restart
Chapter 14. High Availability XFS and High Availability Add On Usage of XFS in conjunction with Red Hat Enterprise Linux 6.2 High Availability Add On as a file system resource is now fully supported. HA support for VMWare Applications running inside VMWare based guests can now be configured for high availability. This also includes full support for the use of GFS2 shared storage file system in the environment. A new SOAP-based fence agent has been added that has the ability to fence guests when necessary. Administrative UI enhancements Luci, the web-based administrative UI for configuring clusters has been updated to include the following: Role-based access control (RBAC): enables fine-grained access levels by defining user classes to access specific cluster operations. Improved response times for destructive operations in a cluster. Support for UDP-Unicast IP multicasting has been the only supported option for a cluster transport. IP multicasting is inherently complex to configure and often requires re-configuration of network switches. UDP-unicast in contrast offers a simpler approach to cluster configuration and is an established protocol for cluster communication. UDP-unicast, initially introduced as a Technology Preview, is now fully supported. Watchdog integration with fence_scsi Watchdog is a general timer service available in Linux that can be used to periodically monitor system resources. Fence agents have now been integrated with watchdog such that the watchdog service can reboot a node after it has been fenced using fence_scsi . This eliminates the need for manual intervention to reboot the node after it has been fenced using fence_scsi .

Commands:
4.4.5. Renaming Logical Volumes To rename an existing logical volume, use the lvrename command. Either of the following commands renames logical volume lvold in volume group vg02 to lvnew . For more information on activating logical volumes on individual nodes in a cluster, see Section 4.8, "Activating Logical Volumes on Individual Nodes in a Cluster" .

Commands:
lvrename /dev/vg02/lvold /dev/vg02/lvnew
lvrename vg02 lvold lvnew
14.6. Converting an Existing Image to Another Format The convert option is used to convert one recognized image format to another image format. For a list of accepted formats, see Section 14.12, "Supported qemu-img Formats" . The -p parameter shows the progress of the command (optional and not for every command) and -S flag allows for the creation of a sparse file , which is included within the disk image. Sparse files in all purposes function like a standard file, except that the physical blocks that only contain zeros (that is, nothing). When the Operating System sees this file, it treats it as it exists and takes up actual disk space, even though in reality it does not take any. This is particularly helpful when creating a disk for a guest virtual machine as this gives the appearance that the disk has taken much more disk space than it has. For example, if you set -S to 50Gb on a disk image that is 10Gb, then your 10Gb of disk space will appear to be 60Gb in size even though only 10Gb is actually being used. Convert the disk image filename to disk image output_filename using format output_format . The disk image can be optionally compressed with the -c option, or encrypted with the -o option by setting -o encryption . Note that the options available with the -o parameter differ with the selected format. Only the qcow2 and qcow2 format supports encryption or compression. qcow2 encryption uses the AES format with secure 128-bit keys. qcow2 compression is read-only, so if a compressed sector is converted from qcow2 format, it is written to the new format as uncompressed data. Image conversion is also useful to get a smaller image when using a format which can grow, such as qcow or cow . The empty sectors are detected and suppressed from the destination image.

Commands:
qemu-img convert [-c] [-p] [-f fmt ] [-t cache ] [-O output_fmt ] [-o options ] [-S sparse_size ] filename output_filename
Red Hat Ansible Lightspeed with IBM watsonx Code Assistant User Guide Red Hat Ansible Lightspeed with IBM watsonx Code Assistant 2.x_latest Learn how to use Red Hat Ansible Lightspeed with IBM watsonx Code Assistant. Red Hat Customer Content Services

Commands:
fatal: unable to access 'https://private.repo./mine/ansible-rulebook.git': SSL certificate problem: unable to get local issuer certificate
kubectl create secret generic <resourcename>-custom-certs --from-file=bundle-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE> 1
spec: bundle_cacert_secret: <resourcename>-custom-certs
secretGenerator: - name: <resourcename>-custom-certs files: - bundle-ca.crt=<path+filename> options: disableNameSuffixHash: true
```yaml spec: extra_settings: - setting: LOGOUT_ALLOWED_HOSTS value: "'<lightspeed_route-HostName>'" ```
curl -H "Authorization: Bearer <token>" https://<lightspeed_route>/api/v1/me/
Install postgresql-server & run postgresql-setup command
Create a keypair called lightspeed-keypair & create a vpc & create vpc_id var & create a security group that allows SSH & create subnet with 10.0.1.0/24 cidr & create an internet gateway & create a route table
Install postgresql-server & run postgresql-setup command
Create a keypair called lightspeed-keypair & create a vpc & create vpc_id var & create a security group that allows SSH & create subnet with 10.0.1.0/24 cidr & create an internet gateway & create a route table
ansible-content-parser --version ansible-content-parser 0.0.1 using ansible-lint:6.20.0 ansible-core:2.15.4 ansible-lint --version ansible-lint 6.13.1 using ansible 2.15.4 A new release of ansible-lint is available: 6.13.1 -> 6.20.0
ansible-content-parser --version ansible-content-parser 0.0.1 using ansible-lint:6.20.0 ansible-core:2.15.4 ansible-lint --version ansible-lint 6.20.0 using ansible-core:2.15.4 ansible-compat:4.1.10 ruamel-yaml:0.17.32 ruamel-yaml-clib:0.2.7
ansible-content-parser --profile min --source-license undefined --source-description Samples --repo-name ansible-tower-samples --repo-url 'https://github.com/ansible/ansible-tower-samples' git@github.com:ansible/ansible-tower-samples.git /var/tmp/out_dir
cat out_dir/ftdata.jsonl| jq { "data_source_description": "Samples", "input": "---\n- name: Hello World Sample\n hosts: all\n tasks:\n - name: Hello Message", "license": "undefined", "module": "debug", "output": " debug:\n msg: Hello World!", "path": "hello_world.yml", "repo_name": "ansible-tower-samples", "repo_url": "https://github.com/ansible/ansible-tower-samples" }
output/ |-- ftdata.jsonl # Training dataset 1 |-- report.txt # A human-readable report 2 | |-- repository/ 3 | |-- (files copied from the source repository) | |-- metadata/ 4 |-- (metadata files generated during the execution)
schedule: interval: daily
Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1006)'))
extra_settings: - setting: ANSIBLE_AI_MODEL_MESH_API_VERIFY_SSL value: false
extra_settings: - setting: ANSIBLE_AI_MODEL_MESH_API_VERIFY_SSL value: false
12.5. Suppressing Repetitive Log Messages Repetitive log messages in the Red Hat Gluster Storage Server can be configured by setting a log-flush-timeout period and by defining a log-buf-size buffer size options with the gluster volume set command. Suppressing Repetitive Log Messages with a Timeout Period To set the timeout period on the bricks: Example 12.13. Set a timeout period on the bricks To set the timeout period on the clients: Example 12.14. Set a timeout period on the clients To set the timeout period on glusterd : Example 12.15. Set a timeout period on the glusterd Suppressing Repetitive Log Messages by defining a Buffer Size The maximum number of unique log messages that can be suppressed until the timeout or buffer overflow, whichever occurs first on the bricks. To set the buffer size on the bricks: Example 12.16. Set a buffer size on the bricks To set the buffer size on the clients: Example 12.17. Set a buffer size on the clients To set the log buffer size on glusterd : Example 12.18. Set a log buffer size on the glusterd Note To disable suppression of repetitive log messages, set the log-buf-size to zero. See Also: Section 11.1, "Configuring Volume Options"

Commands:
gluster volume set VOLNAME diagnostics.brick-log-flush-timeout <value in seconds>
gluster volume set testvol diagnostics.brick-log-flush-timeout 200sec volume set: success
gluster volume set VOLNAME diagnostics.client-log-flush-timeout <value in seconds>
gluster volume set testvol diagnostics.client-log-flush-timeout 180sec volume set: success
glusterd --log-flush-timeout= <value in seconds>
glusterd --log-flush-timeout=60sec
gluster volume set VOLNAME diagnostics.brick-log-buf-size <value>
gluster volume set testvol diagnostics.brick-log-buf-size 10 volume set: success
gluster volume set VOLNAME diagnostics.client-log-buf-size <value>
gluster volume set testvol diagnostics.client-log-buf-size 15 volume set: success
glusterd --log-buf-size= <value>
glusterd --log-buf-size=10
Chapter 51. Case management Showcase application The Showcase application is included in the Red Hat Process Automation Manager distribution to demonstrate the capabilities of case management in an application environment. Showcase is intended to be used as a proof of concept that aims to show the interaction between business process management (BPM) and case management. You can use the application to start, close, monitor, and interact with cases. Showcase must be installed in addition to the Business Central application and KIE Server. The Showcase application is required to start new case instances, however the case work is still performed in Business Central. After a case instance is created and is being worked on, you can monitor the case in the Showcase application by clicking the case in the Case List to open the case Overview page. Showcase Support The Showcase application is not an integral part of Red Hat Process Automation Manager and is intended for demonstration purposes for case management. Showcase is provided to encourage customers to adopt and modify it to work for their specific needs. The content of the application itself does not carry product-specific Service Level Agreements (SLAs). We encourage you to report issues, request for enhancements, and any other feedback for consideration in Showcase updates. Red Hat Support will provide guidance on the use of this template on a commercially reasonable basis for its intended use, excluding the provided example UI code provided within. Note Production support is limited to the Red Hat Process Automation Manager distribution.

Commands:
probe::signal.sys_tgkill Name probe::signal.sys_tgkill - Sending kill signal to a thread group Synopsis Values name Name of the probe point sig_name A string representation of the signal sig The specific kill signal sent to the process tgid The thread group ID of the thread receiving the kill signal pid_name The name of the signal recipient sig_pid The PID of the thread receiving the kill signal Description The tgkill call is similar to tkill, except that it also allows the caller to specify the thread group ID of the thread to be signalled. This protects against TID reuse.

Commands:
signal.sys_tgkill
2.3. External Materialization Options If you are trying to load the materialized table "Portfolio.UpdateProduct", for which the materialization table is defined as "mv_view.UpdateProduct", use any JDBC Query tool like SquirreL and make a JDBC connection to the VDB you created and issue following SQL command: INSERT INTO mv_view.mv_UpdateProduct SELECT * FROM Portfolio.UpdateProduct OPTION NOCACHE Here is how you would create an AdminShell script to automatically load the materialized table: Use this command to execute the script: adminshell.sh . load.groovy Note If you want to set up a job to run this script frequently at regular intervals, then on Red Hat Enterprise Linux use "cron tab" or on Microsoft Windows use "Windows Scheduler" to refresh the rows in the materialized table. Every time the script runs it will refresh the contents. This job needs to be run only when user access is restricted. Important There are some situation in which this process of loading the cache will not work. Here are some situations in which it will not work: If it is updating all the rows in the materialized table, and you only need to update only few rows to avoid long refresh time. If it takes an hour for your reload your materialized table, queries executed during that time will fail to povide correct results. Also ensure that you create indexes on your materialization table after the data is loaded, as having indexes during the load process slows down the loading of data, especially when you are dealing with a large number of rows.

Commands:
sql=connect(USD{url}, USD{user}, USD{password}); sql.execute("DELETE FROM mv_view.mv_UpdateProduct"); sql.execute("INSERT INTO mv_view.mv_UpdateProduct SELECT * FROM Portfolio.UpdateProduct OPTION NOCACHE"); sql.close();
D.4. Promoting a Replica to a Master CA Server If your IdM deployment uses an embedded certificate authority (CA), one of the IdM CA servers acts as the master CA: it manages the renewal of CA subsystem certificates and generates certificate revocation lists (CRLs). By default, the master CA is the first server on which the system administrator installed the CA role using the ipa-server-install or ipa-ca-install command. If you plan to take the master CA server offline or decommission it, promote a replica to take the its place as the master CA: Make sure the replica is configured to handle CA subsystem certificate renewal. See Section D.4.1, "Changing Which Server Handles Certificate Renewal" . Configure the replica to generate CRLs. See Section 6.5.2.2, "Changing Which Server Generates CRLs" . D.4.1. Changing Which Server Handles Certificate Renewal To change which server handles certificate renewal, use the following procedure on an IdM server: Determine which server is the current renewal master: On Red Hat Enterprise Linux 7.3 and later: On Red Hat Enterprise Linux 7.2 and earlier: In both examples, server.example.com is the current renewal master. To set a different server to handle certificate renewal: On Red Hat Enterprise Linux 7.4 and later: On Red Hat Enterprise Linux 7.3 and earlier: Note This command sets the server on which you run the command as the new renewal master. These commands also automatically reconfigures the CA from renewal master to clone.

Commands:
ipa config-show | grep "CA renewal master" IPA CA renewal master: server.example.com
ldapsearch -H ldap://USDHOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn CA, server.example.com, masters, ipa, etc, example.com dn: cn=CA,cn= server.example.com ,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
ipa config-mod --ca-renewal-master-server new_server.example.com
ipa-csreplica-manage set-renewal-master