mtpti5iD/redhat-docs_dataset huggingface dataset:
1.4. Setting the Wireless Regulatory Domain In Red Hat Enterprise Linux, the crda package contains the Central Regulatory Domain Agent that provides the kernel with the wireless regulatory rules for a given jurisdiction. It is used by certain udev scripts and should not be run manually unless debugging udev scripts. The kernel runs crda by sending a udev event upon a new regulatory domain change. Regulatory domain changes are triggered by the Linux wireless subsystem (IEEE-802.11). This subsystem uses the regulatory.bin file to keep its regulatory database information. The setregdomain utility sets the regulatory domain for your system. Setregdomain takes no arguments and is usually called through system script such as udev rather than manually by the administrator. If a country code look-up fails, the system administrator can define the COUNTRY environment variable in the /etc/sysconfig/regdomain file. See the following man pages for more information about the regulatory domain: setregdomain(1) man page - Sets regulatory domain based on country code. crda(8) man page - Sends to the kernel a wireless regulatory domain for a given ISO or IEC 3166 alpha2. regulatory.bin(5) man page - Shows the Linux wireless regulatory database. iw(8) man page - Shows or manipulates wireless devices and their configuration.

Commands:
Chapter 4. Unsupported and deprecated features Cryostat 2.3 removes some features because of their high maintenance costs, low community interest, and better alternative solutions. Removed static Kubernetes environment variable-based target discovery In Cryostat 2.3, the io.cryostat.platform.internal.KubeEnvPlatformStrategy value is removed as an option for the CRYOSTAT_PLATFORM environment variable.

Commands:
13.2. Setting the NIS Port for Identity Management The IdM server binds to its NIS services over a random port that is selected when the server starts. It sends that port assignment to the portmapper so that NIS clients know what port to use to contact the IdM server. Administrators may need to open a firewall for NIS clients or may have other services that need to know the port number in advance and need that port number to remain the same. In that case, an administrator can specify the port to use. Note Any available port number below 1024 can be used for the NIS Plug-in setting. The NIS configuration is in the NIS Plug-in in Identity Management's internal Directory Server instance. To specify the port: Enable the NIS listener and compatibility plug-ins: Edit the plug-in configuration and add the port number as an argument. For example, to set the port to 514: Restart the Directory Server to load the new plug-in configuration.

Commands:
ipa-nis-manage enable ipa-compat-manage enable
ldapmodify -x -D 'cn=directory manager' -w secret dn: cn=NIS Server,cn=plugins,cn=config changetype: modify add: nsslapd-pluginarg0 nsslapd-pluginarg0: 514 modifying entry "cn=NIS Server,cn=plugins,cn=config"
service dirsrv restart
Chapter 22. Red Hat Enterprise Linux Atomic Host 7.5.1 22.1. Atomic Host OStree update : New Tree Version: 7.5.1 (hash: c0211e0b703930dd0f0df8b9f5e731901fce8e15e00b3bc76d3cf00df44eb6e8) Changes since Tree Version 7.5.0 (hash: 5df677dcfef08a87dd0ace55790e184a35716cf11260239216bfeba2eb7c60b0) Updated packages : cockpit-ostree-165-3.el7 22.2. Extras Updated packages : docker-1.13.1-63.git94f4240.el7 buildah-0.16.0-2.git6f7d05b.el7 skopeo-0.1.29-3.dev.git7add6fc.el7 atomic-1.22.1-3.git2fd0860.el7 docker-distribution-2.6.2-2.git48294d9.el7 cockpit-165-3.el7 etcd-3.2.18-1.el7 runc-1.0.0-27.rc5.dev.git4bb1fe4.el7 The asterisk (*) marks packages which are available for Red Hat Enterprise Linux only. New packages : podman-0.4.1-4.gitb51d327.el7 22.2.1. Container Images Updated : Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux 7.5 Container Image (rhel7.5, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic OpenSCAP Container Image (rhel7/openscap) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc)

Commands:
Part II. Designing a decision service using PMML models As a business rules developer, you can use Predictive Model Markup Language (PMML) to define statistical or data-mining models that you can integrate with your decision services in Red Hat Decision Manager. Red Hat Decision Manager includes consumer conformance support of PMML 4.2.1 for Regression, Scorecard, Tree, and Mining models. Red Hat Decision Manager does not include a built-in PMML model editor, but you can use an XML or PMML-specific authoring tool to create PMML models and then integrate them with your Red Hat Decision Manager projects. For more information about PMML, see the DMG PMML specification . Note You can also design your decision service using Decision Model and Notation (DMN) models and include your PMML models as part of your DMN service. For information about DMN support in Red Hat Decision Manager 7.13, see the following resources: Getting started with decision services (step-by-step tutorial with a DMN decision service example) Designing a decision service using DMN models (overview of DMN support and capabilities in Red Hat Decision Manager)

Commands:
E.2.16. /proc/locks This file displays the files currently locked by the kernel. The contents of this file contain internal kernel debugging data and can vary tremendously, depending on the use of the system. A sample /proc/locks file for a lightly loaded system looks similar to the following: Each lock has its own line which starts with a unique number. The second column refers to the class of lock used, with FLOCK signifying the older-style UNIX file locks from a flock system call and POSIX representing the newer POSIX locks from the lockf system call. The third column can have two values: ADVISORY or MANDATORY . ADVISORY means that the lock does not prevent other people from accessing the data; it only prevents other attempts to lock it. MANDATORY means that no other access to the data is permitted while the lock is held. The fourth column reveals whether the lock is allowing the holder READ or WRITE access to the file. The fifth column shows the ID of the process holding the lock. The sixth column shows the ID of the file being locked, in the format of MAJOR-DEVICE : MINOR-DEVICE : INODE-NUMBER . The seventh and eighth column shows the start and end of the file's locked region.

Commands:
1: POSIX ADVISORY WRITE 3568 fd:00:2531452 0 EOF 2: FLOCK ADVISORY WRITE 3517 fd:00:2531448 0 EOF 3: POSIX ADVISORY WRITE 3452 fd:00:2531442 0 EOF 4: POSIX ADVISORY WRITE 3443 fd:00:2531440 0 EOF 5: POSIX ADVISORY WRITE 3326 fd:00:2531430 0 EOF 6: POSIX ADVISORY WRITE 3175 fd:00:2531425 0 EOF 7: POSIX ADVISORY WRITE 3056 fd:00:2548663 0 EOF
Chapter 18. Running Red Hat Process Automation Manager Use this procedure to run Red Hat Process Automation Manager on Red Hat JBoss EAP in standalone mode. Prerequisites Red Hat Process Automation Manager is installed and configured. Note If you changed the default host ( localhost ) or the default port ( 9990 ), then before you run Red Hat Process Automation Manager, you must edit the business-central.war/WEB-INF/classes/datasource-management.properties and business-central.war/WEB-INF/classes/security-management.properties files as described in Solution 3519551 . Procedure In a terminal application, navigate to EAP_HOME /bin . Run the standalone configuration: On Linux or UNIX-based systems: USD ./standalone.sh -c standalone-full.xml On Windows: standalone.bat -c standalone-full.xml Note If you deployed Business Central without KIE Server, you can start Business Central with the standalone.sh script without specifying the standalone-full.xml file. In this case, ensure that you make any configuration changes to the standalone.xml file before starting Business Central. On Linux or UNIX-based systems: On Windows: standalone.bat In a web browser, open the URL localhost:8080/business-central . If you configured Red Hat Process Automation Manager to run from a domain name, replace localhost with the domain name, for example: http://www.example.com:8080/business-central Log in using the credentials of the user that you created for Business Central in Section 14.3, "Creating users" .

Commands:
./standalone.sh -c standalone-full.xml
standalone.bat -c standalone-full.xml
./standalone.sh
standalone.bat
8.81. kde-settings 8.81.1. RHBA-2013:1053 - kde-settings bug fix update Updated kde-settings packages that fix one bug are now available. The kde-settings packages provide a rich set of administration panels to configure system and desktop settings in the Konqueror Desktop Environment (KDE). Bug Fix BZ# 886237 The Konqueror browser enabled Java support by default. Because Java is one of the common targets for browser-based malware attacks, Java is now disabled by default in Konqueror. To enable Java in Konqueror, navigate to Settings -> Configure Konqueror -> Java & JavaScript (which sets the path to Java), and select the "Enable Java globally" check box. Users of kde-settings are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 49. TlsSidecar schema reference Used in: CruiseControlSpec , EntityOperatorSpec Full list of TlsSidecar schema properties Configures a TLS sidecar, which is a container that runs in a pod, but serves a supporting purpose. In AMQ Streams, the TLS sidecar uses TLS to encrypt and decrypt communication between components and ZooKeeper. The TLS sidecar is used in the Entity Operator. The TLS sidecar is configured using the tlsSidecar property in Kafka.spec.entityOperator . The TLS sidecar supports the following additional options: image resources logLevel readinessProbe livenessProbe The resources property specifies the memory and CPU resources allocated for the TLS sidecar. The image property configures the container image which will be used. The readinessProbe and livenessProbe properties configure healthcheck probes for the TLS sidecar. The logLevel property specifies the logging level. The following logging levels are supported: emerg alert crit err warning notice info debug The default value is notice . Example TLS sidecar configuration apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... entityOperator: # ... tlsSidecar: resources: requests: cpu: 200m memory: 64Mi limits: cpu: 500m memory: 128Mi # ... 49.1. TlsSidecar schema properties Property Description image The docker image for the container. string livenessProbe Pod liveness checking. Probe logLevel The log level for the TLS sidecar. Default value is notice . string (one of [emerg, debug, crit, err, alert, warning, notice, info]) readinessProbe Pod readiness checking. Probe resources CPU and memory resources to reserve. For more information, see the external documentation for core/v1 resourcerequirements . ResourceRequirements

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # entityOperator: # tlsSidecar: resources: requests: cpu: 200m memory: 64Mi limits: cpu: 500m memory: 128Mi #
1.4. Changing the Data Warehouse Sampling Scale Data Warehouse is required in Red Hat Virtualization. It can be installed and configured on the same machine as the Manager, or on a separate machine with access to the Manager. The default data retention settings may not be required for all setups, so engine-setup offers two data sampling scales: Basic and Full . Full uses the default values for the data retention settings listed in Section 2.4, "Application Settings for the Data Warehouse service in ovirt-engine-dwhd.conf" (recommended when Data Warehouse is installed on a remote host). Basic reduces the values of DWH_TABLES_KEEP_HOURLY to 720 and DWH_TABLES_KEEP_DAILY to 0 , easing the load on the Manager machine. Use Basic when the Manager and Data Warehouse are installed on the same machine. The sampling scale is configured by engine-setup during installation: You can change the sampling scale later by running engine-setup again with the --reconfigure-dwh-scale option. Changing the Data Warehouse Sampling Scale You can also adjust individual data retention settings if necessary, as documented in Section 2.4, "Application Settings for the Data Warehouse service in ovirt-engine-dwhd.conf" .

Commands:
--== MISC CONFIGURATION ==-- Please choose Data Warehouse sampling scale: (1) Basic (2) Full (1, 2)[1]:
engine-setup --reconfigure-dwh-scale [...] Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: [...] Perform full vacuum on the oVirt engine history database ovirt_engine_history@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/9.0/static/sql-vacuum.html (Yes, No) [No]: [...] Setup can backup the existing database. The time and space required for the database backup depend on its size. This process takes time, and in some cases (for instance, when the size is few GBs) may take several hours to complete. If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost. Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: [...] Please choose Data Warehouse sampling scale: (1) Basic (2) Full (1, 2)[1]: 2 [...] During execution engine service will be stopped (OK, Cancel) [OK]: [...] Please confirm installation settings (OK, Cancel) [OK]:
End-user Guide Red Hat CodeReady Workspaces 2.1 Using Red Hat CodeReady Workspaces 2.1 Supriya Takkhi Robert Kratky rkratky@redhat.com Michal Maler mmaler@redhat.com Fabrice Flore-Thebault ffloreth@redhat.com Yana Hontyk yhontyk@redhat.com Red Hat Developer Group Documentation Team devtools-docs@redhat.com

Commands:
5.4. GFS2 File System Does Not Mount on Newly-Added Cluster Node If you add a new node to a cluster and you find that you cannot mount your GFS2 file system on that node, you may have fewer journals on the GFS2 file system than you have nodes attempting to access the GFS2 file system. You must have one journal per GFS2 host you intend to mount the file system on (with the exception of GFS2 file systems mounted with the spectator mount option set, since these do not require a journal). You can add journals to a GFS2 file system with the gfs2_jadd command, as described in Section 4.7, "Adding Journals to a File System" .

Commands:
A.4. Host Problems A.4.1. Certificate Not Found/Serial Number Not Found Errors The IdM information is stored in a separate LDAP directory than the certificate information, and these two LDAP databases are replicated separately. It is possible for a replication agreement to be broken for one directory and working for another, which can cause problems with managing clients. Specifically, if the replication agreement between the two CA databases is broken, then a server may not be able to find certificate information about a valid IdM client, causing certificate errors: For example, an IdM server and replica have a function replication agreement between their IdM databases, but the replication agreement between their CA databases is broken. If a host is created on the server, the host entry is replicated over to the replica - but the certificate for that host is not replicated. The replica is aware of the client, but any management operations for that client will fail because the replica doesn't have a copy of its certificate. A.4.2. Debugging Client Connection Problems Client connection problems are apparent immediately. This can mean that users cannot log into a machine or attempts to access user and group information fail (for example, getent passwd admin ). Authentication in IdM is managed with the SSSD daemon, which is described in the Red Hat Enterprise Linux Deployment Guide . If there are problems with client authentication, then check the SSSD information. First, check the SSSD logs in /var/log/sssd/ . There is a specific log file for the DNS domain, such as sssd_example.com.log . If there is not enough information in the logs at the default logging level, then increase the log level. To increase the log level: Open the sssd.conf file. In the [domain/ example.com ] section, set debug_level . Restart the sssd daemon. Check the /var/log/sssd/sssd_example.com.log file for the debug messages.

Commands:
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)
vim /etc/sssd/sssd.conf
debug_level = 9
service sssd restart
25.6. Configuring an FCoE Interface to Automatically Mount at Boot Note The instructions in this section are available in /usr/share/doc/fcoe-utils- version /README as of Red Hat Enterprise Linux 6.1. Refer to that document for any possible changes throughout minor releases. You can mount newly discovered disks via udev rules, autofs , and other similar methods. Sometimes, however, a specific service might require the FCoE disk to be mounted at boot-time. In such cases, the FCoE disk should be mounted as soon as the fcoe service runs and before the initiation of any service that requires the FCoE disk. To configure an FCoE disk to automatically mount at boot, add proper FCoE mounting code to the startup script for the fcoe service. The fcoe startup script is /lib/systemd/system/fcoe.service . The FCoE mounting code is different per system configuration, whether you are using a simple formatted FCoE disk, LVM, or multipathed device node. Example 25.2. FCoE Mounting Code The following is a sample FCoE mounting code for mounting file systems specified via wild cards in /etc/fstab : The mount_fcoe_disks_from_fstab function should be invoked after the fcoe service script starts the fcoemon daemon. This will mount FCoE disks specified by the following paths in /etc/fstab : Entries with fc- and _netdev sub-strings enable the mount_fcoe_disks_from_fstab function to identify FCoE disk mount entries. For more information on /etc/fstab entries, refer to man 5 fstab . Note The fcoe service does not implement a timeout for FCoE disk discovery. As such, the FCoE mounting code should implement its own timeout period.

Commands:
mount_fcoe_disks_from_fstab() { local timeout=20 local done=1 local fcoe_disks=(USD(egrep 'by-path\/fc-.*_netdev' /etc/fstab | cut -d ' ' -f1)) test -z USDfcoe_disks && return 0 echo -n "Waiting for fcoe disks . " while [ USDtimeout -gt 0 ]; do for disk in USD{fcoe_disks[*]}; do if ! test -b USDdisk; then done=0 break fi done test USDdone -eq 1 && break; sleep 1 echo -n ". " done=1 let timeout-- done if test USDtimeout -eq 0; then echo "timeout!" else echo "done!" fi # mount any newly discovered disk mount -a 2>/dev/null }
/dev/disk/by-path/fc-0xXX:0xXX /mnt/fcoe-disk1 ext3 defaults,_netdev 0 0 /dev/disk/by-path/fc-0xYY:0xYY /mnt/fcoe-disk2 ext3 defaults,_netdev 0 0
25.2. Creating an iSCSI Initiator In Red Hat Enterprise Linux 7, the iSCSI service is lazily started by default: the service starts after running the iscsiadm command. Procedure 25.7. Creating an iSCSI Initiator Install iscsi-initiator-utils : If the ACL was given a custom name in Section 25.1.6, "Configuring ACLs" , modify the /etc/iscsi/initiatorname.iscsi file accordingly. For example: Discover the target: Log in to the target with the target IQN you discovered in step 3: This procedure can be followed for any number of initators connected to the same LUN so long as their specific initiator names are added to the ACL as described in Section 25.1.6, "Configuring ACLs" . Find the iSCSI disk name and create a file system on this iSCSI disk: Replace disk_name with the iSCSI disk name displayed in /var/log/messages . Mount the file system: Replace /mount/point with the mount point of the partition. Edit the /etc/fstab to mount the file system automatically when the system boots: Replace disk_name with the iSCSI disk name. Log off from the target:

Commands:
yum install iscsi-initiator-utils -y
cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2006-04.com.example.node1 # vi /etc/iscsi/initiatorname.iscsi
iscsiadm -m discovery -t st -p target-ip-address 10.64.24.179:3260,1 iqn.2006-04.com.example:3260
iscsiadm -m node -T iqn.2006-04.com.example:3260 -l Logging in to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] (multiple) Login to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] successful.
grep "Attached SCSI" /var/log/messages # mkfs.ext4 /dev/ disk_name
mkdir /mount/point # mount /dev/ disk_name /mount/point
vim /etc/fstab /dev/ disk_name /mount/point ext4 _netdev 0 0
iscsiadm -m node -T iqn.2006-04.com.example:3260 -u
7.10. bacula 7.10.1. RHBA-2012:1469 - bacula bug fix update Updated bacula packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. The bacula packages provide a tool set that allows you to manage the backup, recovery, and verification of computer data across a network of different computers. Bug Fixes BZ# 728693 Prior to this update, the logwatch tool did not check the "/var/log/bacula*" file. As a consequence, the logwatch report was incomplete. This update adds all log files to the logwatch configuration file. Now, the logwatch report is complete. BZ# 728697 Prior to this update, the bacula tool itself created the "/var/spool/bacula/log" file. As a consequence, this log file used an incorrect SELinux context. This update modifies the underlying code to create the /var/spool/bacula/log file in the bacula package. Now, this log file has the correct SELinux context. BZ# 729008 Prior to this update, the bacula packages were built without the CFLAGS variable "USDRPM_OPT_FLAGS". As a consequence, the debug information was not generated. This update modifies the underlying code to build the packages with CFLAGS="USDRPM_OPT_FLAGS. Now, the debug information is generated as expected. BZ# 756803 Prior to this update, the perl script which generates the my.conf file contained a misprint. As a consequence, the port variable was not set correctly. This update corrects the misprint. Now, the port variable is set as expected. BZ#802158 Prior to this update, values for the "show pool" command was obtained from the "res->res_client" item. As a consequence, the output displayed incorrect job and file retention values. This update uses the "res->res_pool" item to obtain the correct values. BZ# 862240 Prior to this update, bacula-storage-common utility wrongly removed alternatives for the bcopy function during the update. As a consequence, the Link to bcop.{mysql,sqlite,postgresql} disappeared after updating. This update modifies the underlying code to remove these links directly in storage-{mysql,sqlite,postgresql} and not in bacula-storage-common. All users of bacula are advised to upgrade to these updated packages, which fix these bugs.

Commands: