mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 60. Securing passwords with a keystore You can use a keystore to encrypt passwords that are used for communication between Business Central and KIE Server. You should encrypt both controller and KIE Server passwords. If Business Central and KIE Server are deployed to different application servers, then both application servers should use the keystore. Use Java Cryptography Extension KeyStore (JCEKS) for your keystore because it supports symmetric keys. Use KeyTool, which is part of the JDK installation, to create a new JCEKS. Note If KIE Server is not configured with JCEKS, KIE Server passwords are stored in system properties in plain text form. Prerequisites KIE Server is installed in Oracle WebLogic Server. A KIE Server user with the kie-server role has been created, as described in Section 56.1, "Configuring the KIE Server group and users" . Java 8 or higher is installed. Procedure To use KeyTool to create a JCEKS, enter the following command in the Java 8 home directory: USD<JAVA_HOME>/bin/keytool -importpassword -keystore <KEYSTORE_PATH> -keypass <ALIAS_KEY_PASSWORD> -alias <PASSWORD_ALIAS> -storepass <KEYSTORE_PASSWORD> -storetype JCEKS In this example, replace the following variables: <KEYSTORE_PATH> : The path where the keystore will be stored <KEYSTORE_PASSWORD> : The keystore password <ALIAS_KEY_PASSWORD> : The password used to access values stored with the alias <PASSWORD_ALIAS> : The alias of the entry to the process When prompted, enter the password for the KIE Server user that you created. Set the system properties listed in the following table: Table 60.1. System properties used to load a KIE Server JCEKS System property Placeholder Description kie.keystore.keyStoreURL <KEYSTORE_URL> URL for the JCEKS that you want to use, for example file:///home/kie/keystores/keystore.jceks kie.keystore.keyStorePwd <KEYSTORE_PWD> Password for the JCEKS kie.keystore.key.server.alias <KEY_SERVER_ALIAS> Alias of the key for REST services where the password is stored kie.keystore.key.server.pwd <KEY_SERVER_PWD> Password of the alias for REST services with the stored password kie.keystore.key.ctrl.alias <KEY_CONTROL_ALIAS> Alias of the key for default REST Process Automation Controller where the password is stored kie.keystore.key.ctrl.pwd <KEY_CONTROL_PWD> Password of the alias for default REST Process Automation Controller with the stored password Start KIE Server to verify the configuration.

Commands:
USD<JAVA_HOME>/bin/keytool -importpassword -keystore <KEYSTORE_PATH> -keypass <ALIAS_KEY_PASSWORD> -alias <PASSWORD_ALIAS> -storepass <KEYSTORE_PASSWORD> -storetype JCEKS
2.3. Pass-Through Authentication If your client application (web application or web service) is deployed on the same application server instance as JBoss Data Virtualization and your client application uses a security domain to handle authentication, you can configure JBoss Data Virtualization to use that same security domain. This way, the user will not have to re-authenticate in order to use JBoss Data Virtualization. In pass-through mode, Red Hat JBoss Data Virtualization looks for an authenticated subject in the calling thread context and uses it for sessioning and authorization. Procedure 2.1. Configure Pass-Through Authentication Change the Teiid security-domain name in the embedded "transport" section to the same name as your application's security domain name. (You can make this change via the CLI or by editing the standalone.xml file if you are running the product in standalone mode.). Important The security domain must be a JAAS-based LoginModule and your client application must obtain its Teiid connection using a Local Connection with the PassthroughAuthentication connection flag set to true.

Commands:
Chapter 3. Optimizing Virtualization Performance with virt-manager This chapter covers performance tuning options available in virt-manager , a desktop tool for managing guest virtual machines. 3.1. Operating System Details and Devices 3.1.1. Specifying Guest Virtual Machine Details The virt-manager tool provides different profiles depending on what operating system type and version are selected for a new guest virtual machine. When creating a guest, you should provide as many details as possible; this can improve performance by enabling features available for your specific type of guest. See the following example screen capture of the virt-manager tool. When creating a new guest virtual machine, always specify your intended OS type and Version : Figure 3.1. Provide the OS type and Version 3.1.2. Remove Unused Devices Removing unused or unnecessary devices can improve performance. For instance, a guest tasked as a web server is unlikely to require audio features or an attached tablet. See the following example screen capture of the virt-manager tool. Click the Remove button to remove unnecessary devices: Figure 3.2. Remove unused devices

Commands:
7.8. GET and PUT Usage in Distribution Mode In distribution mode, the cache performs a remote GET command before a write command. This occurs because certain methods (for example, Cache.put() ) return the value associated with the specified key according to the java.util.Map contract. When this is performed on an instance that does not own the key and the entry is not found in the L1 cache, the only reliable way to elicit this return value is to perform a remote GET before the PUT . The GET operation that occurs before the PUT operation is always synchronous, whether the cache is synchronous or asynchronous, because Red Hat JBoss Data Grid must wait for the return value. Report a bug 7.8.1. Distributed GET and PUT Operation Resource Usage In distribution mode, the cache may execute a GET operation before executing the desired PUT operation. This operation is very expensive in terms of resources. Despite operating in an synchronous manner, a remote GET operation does not wait for all responses, which would result in wasted resources. The GET process accepts the first valid response received, which allows its performance to be unrelated to cluster size. Use the Flag.SKIP_REMOTE_LOOKUP flag for a per-invocation setting if return values are not required for your implementation. Such actions do not impair cache operations and the accurate functioning of all public methods, but do break the java.util.Map interface contract. The contract breaks because unreliable and inaccurate return values are provided to certain methods. As a result, ensure that these return values are not used for any important purpose on your configuration. Report a bug

Commands:
Chapter 58. JmxTransOutputDefinitionTemplate schema reference Used in: JmxTransSpec Property Description outputType Template for setting the format of the data that will be pushed.For more information see JmxTrans OutputWriters . string host The DNS/hostname of the remote host that the data is pushed to. string port The port of the remote host that the data is pushed to. integer flushDelayInSeconds How many seconds the JmxTrans waits before pushing a new set of data out. integer typeNames Template for filtering data to be included in response to a wildcard query. For more information see JmxTrans queries . string array name Template for setting the name of the output definition. This is used to identify where to send the results of queries should be sent. string

Commands:
Chapter 7. Securing Programs Using Sandbox The sandbox security utility adds a set of SELinux policies that allow a system administrator to run an application within a tightly confined SELinux domain. Restrictions on permission to open new files or access to the network can be defined. This enables testing the processing characteristics of untrusted software securely, without risking damage to the system. 7.1. Running an Application Using Sandbox Before using the sandbox utility, the policycoreutils-sandbox package must be installed: The basic syntax to confine an application is: To run a graphical application in a sandbox , use the -X option. For example: The -X tells sandbox to set up a confined secondary X Server for the application (in this case, evince ), before copying the needed resources and creating a closed virtual environment in the user's home directory or in the /tmp directory. To preserve data from one session to the : Note that sandbox/home is used for /home and sandbox/tmp is used for /tmp . Different applications are placed in different restricted environments. The application runs in full-screen mode and this prevents access to other functions. As mentioned before, you cannot open or create files except those which are labeled as sandbox_x_file_t . Access to the network is also initially impossible inside the sandbox . To allow access, use the sandbox_web_t label. For example, to launch Firefox : Warning The sandbox_net_t label allows unrestricted, bi-directional network access to all network ports. The sandbox_web_t allows connections to ports required for web browsing only. Use of sandbox_net_t should made with caution and only when required. See the sandbox (8) manual page for information, and a full list of available options.

Commands:
~]# yum install policycoreutils-sandbox
~]USD sandbox [options] application_under_test
~]USD sandbox -X evince
~]USD sandbox -H sandbox/home -T sandbox/tmp -X firefox
~]USD sandbox ‐X ‐t sandbox_web_t firefox
6.4.2. Useful Websites http://www.bergen.org/ATC/Course/InfoTech/passwords.html - A good example of a document conveying information about password security to an organization's users. http://www.crypticide.org/users/alecm/ - Homepage of the author of one of the most popular password-cracking programs (Crack). You can download Crack from this page and see how many of your users have weak passwords. http://www.linuxpowered.com/html/editorials/file.html - a good overview of Linux file permissions.

Commands:
Chapter 5. Configuring Ansible Automation Platform Central Authentication Generic OIDC settings and Red Hat SSO/keycloak for Red Hat SSO and Ansible Automation Platform Ansible Automation Platform Central Authentication allows for the setting of generic OIDC settings and Red Hat SSO/keycloak for Red Hat SSO and Ansible Automation Platform. 5.1. Prerequisites You are able to log in as an admin user. 5.2. Configuring Central Authentication Generic OIDC settings Procedure Log in to RH-SSO as admin. Note If you have an existing realm you may go to step 6. Add Realm. Enter Name and click Create . Click the Clients tab. Enter name and click Create . From the navigation panel, select Client Protocol openid-connect . From the navigation panel, select Access Type confidential . In the Root URL field, enter your Ansible Automation Platform server IP or hostname. In the Valid Redirect field, enter your Ansible Automation Platform server IP or hostname. If not in production, set to *. In the Web origins field, enter your Ansible Automation Platform server IP or hostname. If not in production, set to *. Click the Credentials tab. Note Keep track of the Secret to be used later. Log in to Ansible Automation Platform Controller as admin. From the navigation panel, select Settings . Select Generic OIDC settings from the list of Authentication options. Click Edit . In the OIDC Key field, enter the name of your client from step 5. In the OIDC Secret field, enter the secret saved from step 8. In the OIDC Provider URL field, enter your keycloak server URL and port. Click Save . OIDC should appear as an option for login. Click Sign in with OIDC and it will redirect you to the SSO server for login and redirection back to Ansible Automation Platform.

Commands:
Chapter 1. Build controller observability Builds exposes several metrics to help you monitor the performance and functioning of your build resources. The build controller metrics are exposed on the port 8383 . 1.1. Build controller metrics You can check the following build controller metrics for monitoring purposes: Table 1.1. Build controller metrics Name Type Description Labels Status build_builds_registered_total Counter The number of total registered builds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> experimental build_buildruns_completed_total Counter The number of total completed build runs. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental build_buildrun_establish_duration_seconds Histogram The build run establish duration in seconds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental build_buildrun_completion_duration_seconds Histogram The build run completion duration in seconds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental build_buildrun_rampup_duration_seconds Histogram The build run ramp-up duration in seconds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental build_buildrun_taskrun_rampup_duration_seconds Histogram The build run ramp-up duration for a task run in seconds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental build_buildrun_taskrun_pod_rampup_duration_seconds Histogram The build run ramp-up duration for a task run pod in seconds. buildstrategy=<build_buildstrategy_name> namespace=<buildrun_namespace> build=<build_name> buildrun=<buildrun_name> experimental 1.1.1. Histogram metrics To use custom buckets for the build controller, you must set the environment variable for a particular histogram metric. The following table shows the environment variables for all histogram metrics: Table 1.2. Histogram metrics Metric Environment variable Default build_buildrun_establish_duration_seconds PROMETHEUS_BR_EST_DUR_BUCKETS 0,1,2,3,5,7,10,15,20,30 build_buildrun_completion_duration_seconds PROMETHEUS_BR_COMP_DUR_BUCKETS 50,100,150,200,250,300,350,400,450,500 build_buildrun_rampup_duration_seconds PROMETHEUS_BR_RAMPUP_DUR_BUCKETS 0,1,2,3,4,5,6,7,8,9,10 build_buildrun_taskrun_rampup_duration_seconds PROMETHEUS_BR_RAMPUP_DUR_BUCKETS 0,1,2,3,4,5,6,7,8,9,10 build_buildrun_taskrun_pod_rampup_duration_seconds PROMETHEUS_BR_RAMPUP_DUR_BUCKETS 0,1,2,3,4,5,6,7,8,9,10

Commands:
4.8. at 4.8.1. RHBA-2012:0068 - at bug fix update An updated at package that fixes one bug is now available for Red Hat Enterprise Linux 6. The "at" package provides the at and "batch" commands, which are used to read commands from standard input or from a specified file. The "at" command allows you to specify that a command will be run at a particular time. The "batch" command will execute commands when the system load levels drop to a particular level. Both commands use the /bin/sh. Bug Fix BZ# 783190 Due to an error in the time-parsing routine, the "at" command incorrectly calculated the year when a job was scheduled by using days on input. For example: "at now + 10 days". This update fixes erroneous grammar so that "at" now schedules jobs correctly. All users of at are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 3. Red Hat build of OpenJDK features 3.1. New features and enhancements This section describes the new features introduced in this release. It also contains information about changes in the existing features. Note For all the other changes and security fixes, see OpenJDK 11.0.13 Released . 3.1.1. Removed IdenTrust root certificate The following root certificate from IdenTrust has been removed from the cacerts keystore: Alias Name: identrustdstx3 [jdk] Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co. For more information, see JDK-8271434 . 3.1.2. Updated keytool to create AKID from SKID for issuing certificate as specified by RFC 5280 The gencert command of the keytool utility has been updated to create AKID from the SKID for issuing certificate as specified by RFC 5280. For more information, see JDK-8261922 . 3.1.3. Added ChaCha20 and Poly1305 TLS cipher suites The new TLS cipher suites using the ChaCha20-Poly1305 algorithm are added to JSSE. These cipher suites are enabled by default. The TLS_CHACHA20_POLY1305_SHA256 cipher suite is available for TLS 1.3. The following cipher suites are available for TLS 1.2: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 For more information, see JDK-8210799 . 3.1.4. Updated the default enabled cipher suites preference The preference of the default enabled cipher suites are changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and its preference. For more information, see JDK-8219551 .

Commands:
11.5. RAID and Other Disk Devices Important Red Hat Enterprise Linux 6 uses mdraid instead of dmraid for installation onto Intel BIOS RAID sets. These sets are detected automatically, and devices with Intel ISW metadata are recognized as mdraid instead of dmraid. Note that the device node names of any such devices under mdraid are different from their device node names under dmraid . Therefore, special precautions are necessary when you migrate systems with Intel BIOS RAID sets. Local modifications to /etc/fstab , /etc/crypttab or other configuration files which refer to devices by their device node names will not work in Red Hat Enterprise Linux 6. Before migrating these files, you must therefore edit them to replace device node paths with device UUIDs instead. You can find the UUIDs of devices with the blkid command. 11.5.1. Hardware RAID RAID, or Redundant Array of Independent Disks, allows a group, or array, of drives to act as a single device. Configure any RAID functions provided by the mainboard of your computer, or attached controller cards, before you begin the installation process. Each active RAID array appears as one drive within Red Hat Enterprise Linux. On systems with more than one hard drive you may configure Red Hat Enterprise Linux to operate several of the drives as a Linux RAID array without requiring any additional hardware.

Commands:
5.8. Modifying Resource Parameters To modify the parameters of a configured resource, use the following command. The following sequence of commands show the initial values of the configured parameters for resource VirtualIP , the command to change the value of the ip parameter, and the values following the update command.

Commands:
pcs resource update resource_id [ resource_options ]
pcs resource show VirtualIP Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.168.0.120 cidr_netmask=24 Operations: monitor interval=30s pcs resource update VirtualIP ip=192.169.0.120 pcs resource show VirtualIP Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.169.0.120 cidr_netmask=24 Operations: monitor interval=30s
2.6. iostat The iostat tool, provided by the sysstat package, monitors and reports on system input/output device loading to help administrators make decisions about how to balance input/output load between physical disks. The iostat tool reports on processor or device utilization since iostat was last run, or since boot. You can focus the output of these reports on specific devices by using the parameters defined in the iostat (1) manual page. For detailed information on the await value and what can cause its values to be high, see the following Red Hat Knowledgebase article: What exactly is the meaning of value "await" reported by iostat?

Commands:
Chapter 2. Acknowledgments Red Hat Ceph Storage version 4.3 contains many contributions from the Red Hat Ceph Storage team. In addition, the Ceph project is seeing amazing growth in the quality and quantity of contributions from individuals and organizations in the Ceph community. We would like to thank all members of the Red Hat Ceph Storage team, all of the individual contributors in the Ceph community, and additionally, but not limited to, the contributions from organizations such as: Intel(R) Fujitsu (R) UnitedStack Yahoo TM Ubuntu Kylin Mellanox (R) CERN TM Deutsche Telekom Mirantis (R) SanDisk TM SUSE

Commands:
5.2.2. Securing Connectivity to Storage You can connect virtualized systems to networked storage in many different ways. Each approach presents different security benefits and concerns, however the same security principles apply to each: authenticate the remote store pool before use, and protect the confidentiality and integrity of the data while it is being transferred. The data must also remain secure while it is stored. Before storing, Red Hat recommends data be encrypted or digitally signed, or both. Note For more information on networked storage, refer to the Red Hat Enterprise Linux Virtualization Administration Guide .

Commands:
Chapter 7. Networking Troubleshoot networking issues. 7.1. Issue - The default subnet used in Ansible Automation Platform containers conflicts with the internal network The default subnet used in Ansible Automation Platform containers conflicts with the internal network resulting in "No route to host" errors. To resolve this issue, update the default classless inter-domain routing (CIDR) value so it does not conflict with the CIDR used by the default Podman networking plugin. Procedure In all controller and hybrid nodes, run the following commands to create a file called custom.py : # touch /etc/tower/conf.d/custom.py # chmod 640 /etc/tower/conf.d/custom.py # chown root:awx /etc/tower/conf.d/custom.py Add the following to the /etc/tower/conf.d/custom.py file: DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.0.2.0/24'] 192.0.2.0/24 is the value for the new CIDR in this example. Stop and start the automation controller service in all controller and hybrid nodes: # automation-controller-service stop # automation-controller-service start All containers will start on the new CIDR.

Commands:
touch /etc/tower/conf.d/custom.py
chmod 640 /etc/tower/conf.d/custom.py
chown root:awx /etc/tower/conf.d/custom.py
DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.0.2.0/24']
automation-controller-service stop
automation-controller-service start
11.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with rsync . Different types all you to configure flexible access: public_content_t This is a generic type used for the location of files (and the actual files) to be shared via rsync . If a special directory is created to house files to be shared with rsync , the directory and its contents need to have this label applied to them. rsync_exec_t This type is used for the /usr/bin/rsync system binary. rsync_log_t This type is used for the rsync log file, located at /var/log/rsync.log by default. To change the location of the file rsync logs to, use the --log-file=FILE option to the rsync command at run-time. rsync_var_run_t This type is used for the rsyncd lock file, located at /var/run/rsyncd.lock . This lock file is used by the rsync server to manage connection limits. rsync_data_t This type is used for files and directories which you want to use as rsync domains and isolate them from the access scope of other services. Also, the public_content_t is a general SELinux context type, which can be used when a file or a directory interacts with multiple services (for example, FTP and NFS directory as an rsync domain). rsync_etc_t This type is used for rsync -related files in the /etc/ directory.

Commands: