mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. DeploymentLog [apps.openshift.io/v1] Description DeploymentLog represents the logs for a deployment Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 11.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds 11.2. API endpoints The following API endpoints are available: /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/log GET : read log of the specified DeploymentConfig 11.2.1. /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/log Table 11.1. Global path parameters Parameter Type Description name string name of the DeploymentLog HTTP method GET Description read log of the specified DeploymentConfig Table 11.2. HTTP responses HTTP code Reponse body 200 - OK DeploymentLog schema 401 - Unauthorized Empty

Commands:
13.2.2. Setting up the sssd.conf File SSSD services and domains are configured in a .conf file. By default, this is /etc/sssd/sssd.conf - although that file must be created and configured manually, since SSSD is not configured after installation. 13.2.2.1. Creating the sssd.conf File There are three parts of the SSSD configuration file: [sssd] , for general SSSD process and operational configuration; this basically lists the configured services, domains, and configuration parameters for each [service_name] , for configuration options for each supported system service, as described in Section 13.2.4, "SSSD and System Services" [domain_type/DOMAIN_NAME] , for configuration options for each configured identity provider Important While services are optional, at least one identity provider domain must be configured before the SSSD service can be started. Example 13.1. Simple sssd.conf File [sssd] domains = LOCAL services = nss config_file_version = 2 [nss] filter_groups = root filter_users = root [domain/LOCAL] id_provider = local auth_provider = local access_provider = permit The [sssd] section has three important parameters: domains lists all of the domains, configured in the sssd.conf , which SSSD uses as identity providers. If a domain is not listed in the domains key, it is not used by SSSD, even if it has a configuration section. services lists all of the system services, configured in the sssd.conf , which use SSSD; when SSSD starts, the corresponding SSSD service is started for each configured system service. If a service is not listed in the services key, it is not used by SSSD, even if it has a configuration section. config_file_version sets the version of the configuration file to set file format expectations. This is version 2, for all recent SSSD versions. Note Even if a service or domain is configured in the sssd.conf file, SSSD does not interact with that service or domain unless it is listed in the services or domains parameters, respectively, in the [sssd] section. Other configuration parameters are listed in the sssd.conf man page. Each service and domain parameter is described in its respective configuration section in this chapter and in their man pages. 13.2.2.2. Using a Custom Configuration File By default, the sssd process assumes that the configuration file is /etc/sssd/sssd.conf . An alternative file can be passed to SSSD by using the -c option with the sssd command:

Commands:
[sssd] domains = LOCAL services = nss config_file_version = 2 [nss] filter_groups = root filter_users = root [domain/LOCAL] id_provider = local auth_provider = local access_provider = permit
~]# sssd -c /etc/sssd/customfile.conf --daemon
10.5.2. Patching the System Patching affected systems is a more dangerous course of action and should be undertaken with great caution. The problem with patching a system instead of reinstalling is determining whether or not a given system is cleansed of trojans, security holes, and corrupted data. Most rootkits (programs or packages that a cracker uses to gain root access to a system), trojan system commands, and shell environments are designed to hide malicious activities from cursory audits. If the patch approach is taken, only trusted binaries should be used (for example, from a mounted, read-only CD-ROM).

Commands:
2.2. A Three-Tier keepalived Load Balancer Configuration Figure 2.2, "A Three-Tier Load Balancer Configuration" shows a typical three-tier Keepalived Load Balancer topology. In this example, the active LVS router routes the requests from the Internet to the pool of real servers. Each of the real servers then accesses a shared data source over the network. Figure 2.2. A Three-Tier Load Balancer Configuration This configuration is ideal for busy FTP servers, where accessible data is stored on a central, highly available server and accessed by each real server by means of an exported NFS directory or Samba share. This topology is also recommended for websites that access a central, highly available database for transactions. Additionally, using an active-active configuration with the Load Balancer, administrators can configure one high-availability cluster to serve both of these roles simultaneously. The third tier in the above example does not have to use the Load Balancer, but failing to use a highly available solution would introduce a critical single point of failure.

Commands:
Chapter 4. Optimizing MTA performance MTA performance depends on a number of factors, including hardware configuration, the number and types of files in the application, the size and number of applications to be evaluated, and whether the application contains source or compiled code. For example, a file that is larger than 10 MB may need a lot of time to process. In general, MTA spends about 40% of the time decompiling classes, 40% of the time executing rules, and the remainder of the time processing other tasks and generating reports. This section describes what you can do to improve the performance of MTA. 4.1. Deploying and running the application Try these suggestions first before upgrading hardware. If possible, run MTA against the source code instead of the archives. This eliminates the need to decompile additional JARs and archives. Increase your ulimit when analyzing large applications. See this Red Hat Knowledgebase article for instructions on how to do this for Red Hat Enterprise Linux. If you have access to a server that has better resources than your laptop or desktop machine, you may want to consider running MTA on that server. 4.2. Upgrading hardware If the application and command-line suggestions above do not improve performance, you may need to upgrade your hardware. If you have access to a server that has better resources than your laptop/desktop, then you may want to consider running MTA on that server. Very large applications that require decompilation have large memory requirements. 8 GB RAM is recommended. This allows 3 - 4 GB RAM for use by the JVM. An upgrade from a single or dual-core to a quad-core CPU processor provides better performance. Disk space and fragmentation can impact performance. A fast disk, especially a solid-state drive (SSD), with greater than 4 GB of defragmented disk space should improve performance.

Commands:
probe::sunrpc.clnt.call_async Name probe::sunrpc.clnt.call_async - Make an asynchronous RPC call Synopsis sunrpc.clnt.call_async Values progname the RPC program name prot the IP protocol number proc the procedure number in this RPC call procname the procedure name in this RPC call vers the RPC program version number flags flags servername the server machine name xid current transmission id port the port number prog the RPC program number dead whether this client is abandoned

Commands:
11.3.2. Removing an LVM2 Logical Volume for Swap The swap logical volume cannot be in use (no system locks or processes on the volume). The easiest way to achieve this it to boot your system in rescue mode. Refer to Chapter 5, Basic System Recovery for instructions on booting into rescue mode. When prompted to mount the file system, select Skip . To remove a swap volume group (assuming /dev/VolGroup00/LogVol02 is the swap volume you want to remove): Disable swapping for the associated logical volume: Remove the LVM2 logical volume of size 512 MB: Remove the following entry from the /etc/fstab file: Test that the logical volume has been extended properly:

Commands:
swapoff -v /dev/VolGroup00/LogVol02
lvm lvremove /dev/VolGroup00/LogVol02
/dev/VolGroup00/LogVol02 swap swap defaults 0 0
cat /proc/swaps # free
Chapter 14. Using TLS certificates for applications accessing RGW Most of the S3 applications require TLS certificate in the forms such as an option included in the Deployment configuration file, passed as a file in the request, or stored in /etc/pki paths. TLS certificates for RADOS Object Gateway (RGW) are stored as Kubernetes secret and you need to fetch the details from the secret. Prerequisites A running OpenShift Data Foundation cluster. Procedure For internal RGW server Get the TLS certificate and key from the kubernetes secret: <secret_name> The default kubernetes secret name is <objectstore_name>-cos-ceph-rgw-tls-cert . Specify the name of the object store. For external RGW server Get the the TLS certificate from the kubernetes secret: <secret_name> The default kubernetes secret name is ceph-rgw-tls-cert and it is an opaque type of secret. The key value for storing the TLS certificates is cert . 14.1. Accessing External RGW server in OpenShift Data Foundation Accessing External RGW server using Object Bucket Claims The S3 credentials such as AccessKey or Secret Key is stored in the secret generated by the Object Bucket Claim (OBC) creation and you can fetch the same by using the following commands: Similarly, you can fetch the endpoint details from the configmap of OBC: Accessing External RGW server using the Ceph Object Store User CR You can fetch the S3 Credentials and endpoint details from the secret generated as part of the Ceph Object Store User CR: Important For both the access mechanisms, you can either request for new certificates from the administrator or reuse the certificates from the Kubernetes secret, ceph-rgw-tls-cert .

Commands:
oc get secrets/<secret_name> -o jsonpath='{.data..tls\.crt}' | base64 -d oc get secrets/<secret_name> -o jsonpath='{.data..tls\.key}' | base64 -d
oc get secrets/<secret_name> -o jsonpath='{.data.cert}' | base64 -d
oc get secret <object bucket claim name> -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 --decode oc get secret <object bucket claim name> -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 --decode
oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_HOST}' oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_PORT}' oc get cm <object bucket claim name> -o jsonpath='{.data.BUCKET_NAME}'
oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.AccessKey}' | base64 --decode oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.SecretKey}' | base64 --decode oc get secret rook-ceph-object-user-<object-store-cr-name>-<object-user-cr-name> -o jsonpath='{.data.Endpoint}' | base64 --decode
Chapter 15. Using the Multicloud Object Gateway's Security Token Service to assume the role of another user Multicloud Object Gateway (MCG) provides support to a security token service (STS) similar to the one provided by Amazon Web Services. To allow other users to assume the role of a certain user, you need to assign a role configuration to the user. You can manage the configuration of roles using the MCG CLI tool. The following example shows role configuration that allows two MCG users ( assumer@mcg.test and assumer2@mcg.test ) to assume a certain user's role: Assign the role configuration by using the MCG CLI tool. Collect the following information before proceeding to assume the role as it is needed for the subsequent steps: The access key ID and secret access key of the assumer (the user who assumes the role) The MCG STS endpoint, which can be retrieved by using the command: The access key ID of the assumed user. The value of the role_name value in your role configuration. A name of your choice for the role session After the configuration role is ready, assign it to the appropriate user (fill with the data described in the step) - Note Adding --no-verify-ssl might be necessary depending on your cluster's configuration. The resulting output contains the access key ID, secret access key, and session token that can be used for executing actions while assuming the other user's role. You can use the credentials generated after the assume role steps as shown in the following example:

Commands:
'{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'
mcg sts assign-role --email <assumed user's username> --role_config '{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'
oc -n openshift-storage get route
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> aws --endpoint-url <mcg-sts-endpoint> sts assume-role --role-arn arn:aws:sts::<assumed-user-access-key-id>:role/<role-name> --role-session-name <role-session-name>
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> AWS_SESSION_TOKEN=<session token> aws --endpoint-url <mcg-s3-endpoint> s3 ls
2.5.6. Samba (SMB or Windows) File Serving over GFS2 As of the Red Hat Enterprise Linux 6.2 release, you can use Samba (SMB or Windows) file serving from a GFS2 file system with CTDB, which allows active/active configurations. For information on Clustered Samba configuration, see the Cluster Administration document. Simultaneous access to the data in the Samba share from outside of Samba is not supported. There is currently no support for GFS2 cluster leases, which slows Samba file serving.

Commands:
Chapter 2. Before you begin 2.1. Run with clean target server installation Because the JBoss Server Migration Tool creates the configuration files based on the configuration of a release, it is intended to be run on a clean and unconfigured target server installation. The JBoss Server Migration Tool creates a backup of the target server's configuration files by appending .beforeMigration to the file names. It then creates totally new configuration files for the target server using the source server's configuration files, and migrates the configuration to run in the target server configuration. Warning When you run the JBoss Server Migration Tool, all changes on the target server made between installation and running the migration tool are lost. Also, be aware that if you run the tool against the target server directory more than once, the subsequent runs will overwrite the original target configuration files that were backed up on the first run of the tool. This is because each run of the tool backs up the configuration files by appending .beforeMigration , resulting in the loss of any existing backed up configuration files. 2.2. Customize the migration The JBoss Server Migration Tool provides the ability to configure logging, reporting, and the execution of migration tasks. By default, when you run the JBoss Server Migration Tool in non-interactive mode, it migrates the entire server configuration. You can configure the JBoss Server Migration Tool to customize logging and reporting output. You can also configure it to skip any part of the configuration that you do not want to migrate. Additional resources For instructions on how to configure properties to control the migration process, see Configuring the JBoss Server Migration Tool .

Commands:
Chapter 16. Suspending applications This guide explains how to disable all keys and access tokens for an application. If an application is misusing your API and affecting other traffic, you may need to quickly suspend its operations before contacting the developer involved to ask them to amend their code or configuration. 16.1. Find the application You can find the application from the Accounts or Applications tabs or by searching as described here . 16.2. Disable the application Once you have located the application and see the application summary page, click on the suspend icon to the State value. This action will immediately disable the application from the API and suspend all keys from working. Calls with these application keys will be rejected by the control system. The application can be unsuspended using the same button once the problematic behavior has been rectified. Note If you use caching in your agents, suspension may not be immediate but require a short timeout. 16.3. Contact the developer How you contact the developer of the application will depend on your workflow and policy. On the same page, you can click on the account name, which will take you to the account view where you can identify the key administrator of the account that owns the application. You can contact them either by email or by clicking on the send message button as shown, which will generate a dashboard message for the user.

Commands:
B.2. How to Set Up Red Hat Virtualization Manager to Use Ethtool You can configure ethtool properties for host network interface cards from the Administration Portal. The ethtool_opts key is not available by default and needs to be added to the Manager using the engine configuration tool. You also need to install the required VDSM hook package on the hosts. Adding the ethtool_opts Key to the Manager On the Manager, run the following command to add the key: # engine-config -s UserDefinedNetworkCustomProperties=ethtool_opts=.* --cver=4.4 Restart the ovirt-engine service: # systemctl restart ovirt-engine.service On the hosts that you want to configure ethtool properties, install the VDSM hook package. The package is available by default on Red Hat Virtualization Host but needs to be installed on Red Hat Enterprise Linux hosts. # dnf install vdsm-hook-ethtool-options The ethtool_opts key is now available in the Administration Portal. See Editing Host Network Interfaces and Assigning Logical Networks to Hosts to apply ethtool properties to logical networks.

Commands:
engine-config -s UserDefinedNetworkCustomProperties=ethtool_opts=.* --cver=4.4
systemctl restart ovirt-engine.service
dnf install vdsm-hook-ethtool-options
Chapter 2. New features and enhancements Red Hat JBoss Web Server 6.0 Service Pack 1 includes the following new features and enhancements. 2.1. Location changes for tomcat-websocket-chat quick start application This release includes the following changes to the location of the example tomcat-websocket-chat quick start application that you can use with JWS for OpenShift: The URL for the quick start has changed from https://github.com/jboss-openshift/openshift-quickstarts to https://github.com/web-servers/tomcat-websocket-chat-quickstart . The git repository for the quick start has changed from https://github.com/jboss-openshift/openshift-quickstarts.git to https://github.com/web-servers/tomcat-websocket-chat-quickstart.git . The directory path for the quick start has changed from openshift-quickstarts/tomcat-websocket-chat to tomcat-websocket-chat-quickstart/tomcat-websocket-chat .

Commands:
9.9. Securing Server Connections After designing the authentication scheme for identified users and the access control scheme for protecting information in the directory, the step is to design a way to protect the integrity of the information as it passes between servers and client applications. For both server to client connections and server to server connections, the Directory Server supports a variety of secure connection types: Transport Layer Security (TLS) . To provide secure communications over the network, the Directory Server can use LDAP over the Transport Layer Security (TLS). TLS can be used in conjunction with encryption algorithms from RSA. The encryption method selected for a particular connection is the result of a negotiation between the client application and Directory Server. Start TLS . Directory Server also supports Start TLS, a method of initiating a Transport Layer Security (TLS) connection over a regular, unencrypted LDAP port. Simple Authentication and Security Layer (SASL) . SASL is a security framework, meaning that it sets up a system that allows different mechanisms to authenticate a user to the server, depending on what mechanism is enabled in both client and server applications. It can also establish an encrypted session between the client and a server. In Directory Server, SASL is used with GSS-API to enable Kerberos logins and can be used for almost all server to server connections, including replication, chaining, and pass-through authentication. (SASL cannot be used with Windows Sync.) Secure connections are recommended for any operations which handle sensitive information, like replication, and are required for some operations, like Windows password synchronization. Directory Server can support TLS connections, SASL, and non-secure connections simultaneously. Both SASL authentication and TLS connections can be configured at the same time. For example, the Directory Server instance can be configured to require TLS connections to the server and also support SASL authentication for replication connections. This means it is not necessary to choose whether to use TLS or SASL in a network environment; you can use both. It is also possible to set a minimum level of security for connections to the server. The security strength factor measures, in key strength, how strong a secure connection is. An ACI can be set that requires certain operations (like password changes) only occur if the connection is of a certain strength or higher. It is also possible to set a minimum SSF, which can essentially disable standard connections and requires TLS, Start TLS, or SASL for every connection. The Directory Server supports TLS and SASL simultaneously, and the server calculates the SSF of all available connection types and selects the strongest. For more information about using TLS, Start TLS, and SASL, check out the Administration Guide .

Commands: