mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 30. Red Hat Enterprise Linux Atomic Host 7.3.6 30.1. Atomic Host OStree update : New Tree Version: 7.3.6 (hash: e073a47baa605a99632904e4e05692064302afd8769a15290d8ebe8dbfd3c81b) Changes since Tree Version 7.3.5-1 (hash: c04cab425084ce81d66d1717f464e292bc5a908a86802faf0da7dd22d74d3727) Updated packages : atomic-devmode-0.3.7-1.el7 cockpit-ostree-141-1.el7 librhsm-0.0.1-2.el7 30.2. Extras Updated packages : atomic-1.17.2-9.git2760e30.el7 cockpit-141-1.el7 container-selinux-2.19-2.1.el7 docker-1.12.6-32.git88a4867.el7 docker-latest-1.13.1-13.gitb303bf6.el7 etcd-3.1.9-1.el7 flannel-0.7.1-1.el7 kubernetes-1.5.2-0.7.git269f928.el7 * oci-systemd-hook-0.1.7-4.gite533efa.el7 ostree-2017.5-3.el7 skopeo-0.1.20-2.el7 The asterisk (*) marks packages which are available for Red Hat Enterprise Linux only. 30.2.1. Container Images Updated : 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 Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Kubernetes apiserver Container Image (rhel7/kubernetes-apiserver) Red Hat Enterprise Linux Atomic Kubernetes controller-manager Container (rhel7/kubernetes-controller-mgr) Red Hat Enterprise Linux Atomic Kubernetes scheduler Container Image (rhel7/kubernetes-scheduler) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic openscap Container Image (rhel7/openscap) Red Hat Enterprise Linux 7.3 Container Image (rhel7.3, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) 30.3. New Features Red Hat Enterprise Linux 6 Init Container Image is now available The new Red Hat Enterprise Linux 6 Init Image allows creating containerized services based on RHEL6 init scripts. This container image enables running one or more services in a RHEL6 user space using init scripts. For details on using rhev6-init , see Using the Atomic RHEL6 Init Container Image in the Managing Containers Guide.

Commands:
Chapter 7. Internationalization 7.1. Red Hat Enterprise Linux 8 International Languages Red Hat Enterprise Linux 8 supports the installation of multiple languages and the changing of languages based on your requirements. East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese. European Languages - English, German, Spanish, French, Italian, Portuguese, and Russian. The following table lists the fonts and input methods provided for various major languages. Language Default Font (Font Package) Input Methods English dejavu-sans-fonts French dejavu-sans-fonts German dejavu-sans-fonts Italian dejavu-sans-fonts Russian dejavu-sans-fonts Spanish dejavu-sans-fonts Portuguese dejavu-sans-fonts Simplified Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libpinyin, libpinyin Traditional Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libzhuyin, libzhuyin Japanese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-kkc, libkkc Korean google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-hangul, libhangu 7.2. Notable changes to internationalization in RHEL 8 RHEL 8 introduces the following changes to internationalization compared to RHEL 7: Support for the Unicode 11 computing industry standard has been added. Internationalization is distributed in multiple packages, which allows for smaller footprint installations. For more information, see glibc localization for RHEL is distributed in multiple packages . The glibc package updates for multiple locales are now synchronized with the Common Locale Data Repository (CLDR).

Commands:
Chapter 53. module This chapter describes the commands under the module command. 53.1. module list List module versions Usage: Table 53.1. Optional Arguments Value Summary -h, --help Show this help message and exit --all Show all modules that have version information Table 53.2. Output Formatters Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 53.3. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 53.4. Shell Formatter Value Summary --prefix PREFIX Add a prefix to all variable names Table 53.5. Table Formatter Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack module list [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--all]
14.2.2. Starting and Stopping Samba To start a Samba server, type the following command in a shell prompt while logged in as root: Important To set up a domain member server, you must first join the domain or Active Directory using the net join command before starting the smb service. To stop the server, type the following command in a shell prompt while logged in as root: The restart option is a quick way of stopping and then starting Samba. This is the most reliable way to make configuration changes take effect after editing the configuration file for Samba. Note that the restart option starts the daemon even if it was not running originally. To restart the server, type the following command in a shell prompt while logged in as root: The condrestart ( conditional restart ) option only starts smb on the condition that it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running. Note When the smb.conf file is changed, Samba automatically reloads it after a few minutes. Issuing a manual restart or reload is just as affective. To conditionally restart the server, type the following command as root: A manual reload of the smb.conf file can be useful in case of a failed automatic reload by the smb service. To ensure that the Samba server configuration file is reloaded without restarting the service, type the following command as root: By default, the smb service does not start automatically at boot time. To configure Samba to start at boot time, use an initscript utility, such as /sbin/chkconfig , /usr/sbin/ntsysv , or the Services Configuration Tool program. Refer to the chapter titled Controlling Access to Services in the System Administrators Guide for more information regarding these tools.

Commands:
service smb start
service smb stop
service smb restart
service smb condrestart
service smb reload
5.4. Load Balancing Policy: Evenly_Distributed Figure 5.1. Evenly Distributed Scheduling Policy An evenly distributed load balancing policy selects the host for a new virtual machine according to lowest CPU load or highest available memory. The maximum CPU load and minimum available memory that is allowed for hosts in a cluster for a set amount of time are defined by the evenly distributed scheduling policy's parameters. Beyond these limits the environment's performance will degrade. The evenly distributed policy allows an administrator to set these levels for running virtual machines. If a host has reached the defined maximum CPU load or minimum available memory and the host stays there for more than the set time, virtual machines on that host are migrated one by one to the host in the cluster that has the lowest CPU or highest available memory depending on which parameter is being utilized. Host resources are checked once per minute, and one virtual machine is migrated at a time until the host CPU load is below the defined limit or the host available memory is above the defined limit.

Commands:
Chapter 20. Access Control Lists Files and directories have permission sets for the owner of the file, the group associated with the file, and all other users for the system. However, these permission sets have limitations. For example, different permissions cannot be configured for different users. Thus, Access Control Lists (ACLs) were implemented. The Red Hat Enterprise Linux kernel provides ACL support for the ext3 file system and NFS-exported file systems. ACLs are also recognized on ext3 file systems accessed via Samba. Along with support in the kernel, the acl package is required to implement ACLs. It contains the utilities used to add, modify, remove, and retrieve ACL information. The cp and mv commands copy or move any ACLs associated with files and directories. 20.1. Mounting File Systems Before using ACLs for a file or directory, the partition for the file or directory must be mounted with ACL support. If it is a local ext3 file system, it can mounted with the following command: mount -t ext3 -o acl device-name partition For example: mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work Alternatively, if the partition is listed in the /etc/fstab file, the entry for the partition can include the acl option: If an ext3 file system is accessed via Samba and ACLs have been enabled for it, the ACLs are recognized because Samba has been compiled with the --with-acl-support option. No special flags are required when accessing or mounting a Samba share. 20.1.1. NFS By default, if the file system being exported by an NFS server supports ACLs and the NFS client can read ACLs, then ACLs are utilized by the client system. To disable ACLs on NFS share when mounting it on a client, mount it with the noacl option with the command line.

Commands:
LABEL=/work /work ext3 acl 1 2
Chapter 4. Configuring IntelliJ to use Dependency Analytics You can gain access to Red Hat's Trusted Profile Analyzer service by using the Dependency Analytics plugin for Jet Brains' IntelliJ IDEA application. With this plugin you get access to the latest open source vulnerability information, and insights about your application's dependent packages. The Red Hat Dependency Analytics plugin uses the following data sources for the most up-to-date vulnerability information available: The ONGuard service, integrates the Open Source Vulnerability (OSV) and the National Vulnerability Database (NVD) data sources. When given a set of packages to the ONGuard service, a query to OSV retrieves the associated vulnerability information, and then a query to NVD for public Common Vulnerability and Exposures (CVE) information. Dependency Analytics supports the following programming languages: Maven Node Python Go Note The Dependency Analytics extension is an online service maintained by Red Hat. Dependency Analytics only accesses your manifest files to analyze your application dependencies before displaying the results. Prerequisites Install IntelliJ IDEA on your workstation. For Maven projects, analyzing a pom.xml file, you must have the mvn binary in your system's PATH environment. For Node projects, analyzing a package.json file, you must have the npm binary in your system's PATH environment. For Go projects, analyzing a go.mod file, you must have the go binary in your system's PATH environment. For Python projects, analyzing a requirements.txt file, you must have the python3/pip3 or python/pip binaries in your system's PATH environment. Procedure Open the IntelliJ application. From the file menu, click Settings , and click Plugins . Search the Marketplace for Red Hat Dependency Analytics . Click the INSTALL button to install the plug-in. To start scanning your application for security vulnerabilities, and view the vulnerability report, you can do one of the following: Open a manifest file, hover over a dependency marked by the inline Component Analysis, indicated by the wavy-red line under a dependency, and click Detailed Vulnerability Report . Right click on a manifest file in the Project window, and click Dependency Analytics Report . Additional resources Red Hat's Dependency Analytics Jet Brains marketplace page . The GitHub project .

Commands:
Chapter 15. Managing Certificate System Users and Groups This chapter explains how to set up authorization for access to the administrative, agent services, and end-entities pages. 15.1. About Authorization Authorization is the process of allowing access to certain tasks associated with the Certificate System. Access can be limited to allow certain tasks to certain areas of the subsystem for certain users or groups and different tasks to different users and groups. Users are specific to the subsystem in which they are created. Each subsystem has its own set of users independent of any other subsystem installed. The users are placed in groups, which can be predefined or user-created. Privileges are assigned to a group through access control lists (ACLs). There are ACLs associated with areas in the administrative console, agent services interface, and end-entities page that perform an authorization check before allowing an operation to proceed. Access control instructions (ACIs) in each of the ACLs are created that specifically allow or deny possible operations for that ACL to specified users, groups, or IP addresses. The ACLs contain a default set of ACIs for the default groups that are created. These ACIs can be modified to change the privileges of predefined groups or to assign privileges to newly-created groups. Authorization goes through the following process: The users authenticate to the interface using either the Certificate System user ID and password or a certificate. The server authenticates the user either by matching the user ID and password with the one stored in the database or by checking the certificate against one stored in the database. With certificate-based authentication, the server also checks that the certificate is valid and finds the group membership of the user by associating the DN of the certificate with a user and checking the user entry. With password-based authentication, the server checks the password against the user ID and then finds the group membership of the user by associating that user ID with the user ID contained in the group. When the user tries to perform an operation, the authorization mechanism compares the user ID of the user, the group in which the user belongs, or the IP address of the user to the ACLs set for that user, group, or IP address. If an ACL exists that allows that operation, then the operation proceeds.

Commands:
5.9.2. Moving Files and Directories Files and directories keep their current SELinux context when they are moved. In many cases, this is incorrect for the location they are being moved to. The following example demonstrates moving a file from a user's home directory to /var/www/html/ , which is used by the Apache HTTP Server. Since the file is moved, it does not inherit the correct SELinux context: Run the cd command without any arguments to change into your home directory. Once in your home directory, run the touch file1 command to create a file. This file is labeled with the user_home_t type: Run the ls -dZ /var/www/html/ command to view the SELinux context of the /var/www/html/ directory: By default, the /var/www/html/ directory is labeled with the httpd_sys_content_t type. Files and directories created under the /var/www/html/ directory inherit this type, and as such, they are labeled with this type. As the Linux root user, run the mv file1 /var/www/html/ command to move file1 to the /var/www/html/ directory. Since this file is moved, it keeps its current user_home_t type: By default, the Apache HTTP Server cannot read files that are labeled with the user_home_t type. If all files comprising a web page are labeled with the user_home_t type, or another type that the Apache HTTP Server cannot read, permission is denied when attempting to access them via web browsers, such as Firefox. Important Moving files and directories with the mv command may result in the incorrect SELinux context, preventing processes, such as the Apache HTTP Server and Samba, from accessing such files and directories.

Commands:
~]USD ls -Z file1 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
~]USD ls -dZ /var/www/html/ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/
~]# mv file1 /var/www/html/ ~]# ls -Z /var/www/html/file1 -rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 /var/www/html/file1
7.63. glusterfs 7.63.1. RHBA-2015:0683 - glusterfs bug fix update Updated glusterfs packages that fix one bug are now available for Red Hat Enterprise Linux 6. GlusterFS is a key building block of Red Hat Storage. It is based on a stackable user-space design and can deliver exceptional performance for diverse workloads. GlusterFS aggregates various storage servers over network interconnections into one large, parallel network file system. Bug Fix BZ# 1204589 Previously, the qemu-kvm utility could terminate unexpectedly with a segmentation fault after the user attempted to create an image on GlusterFS using the "qemu-img create" command. The glusterfs packages source code has been modified to fix this bug, and qemu-kvm no longer crashes in the described situation. Users of glusterfs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Appendix A. Consistent Network Device Naming Red Hat Enterprise Linux 6 provides consistent network device naming for network interfaces. This feature changes the name of network interfaces on a system in order to make locating and differentiating the interfaces easier. Traditionally, network interfaces in Linux are enumerated as eth[0123...] , but these names do not necessarily correspond to actual labels on the chassis. Modern server platforms with multiple network adapters can encounter non-deterministic and counter-intuitive naming of these interfaces. This affects both network adapters embedded on the motherboard ( Lan-on-Motherboard , or LOM ) and add-in (single and multiport) adapters. The new naming convention assigns names to network interfaces based on their physical location, whether embedded or in PCI slots. By converting to this naming convention, system administrators will no longer have to guess at the physical location of a network port, or modify each system to rename them into some consistent order. This feature, implemented via the biosdevname program, will change the name of all embedded network interfaces, PCI card network interfaces, and virtual function network interfaces from the existing eth[0123...] to the new naming convention as shown in Table A.1, "The new naming convention" . Table A.1. The new naming convention Device Old Name New Name Embedded network interface (LOM) eth[0123...] em[1234...] [a] PCI card network interface eth[0123...] p< slot >p< ethernet port > [b] Virtual function eth[0123...] p< slot >p< ethernet port >_< virtual interface > [c] [a] New enumeration starts at 1 . [b] For example: p3p4 [c] For example: p3p4_1 System administrators may continue to write rules in /etc/udev/rules.d/70-persistent-net.rules to change the device names to anything desired; those will take precedence over this physical location naming convention. A.1. Affected Systems Consistent network device naming is enabled by default for a set of Dell PowerEdge , C Series , and Precision Workstation systems. For more details regarding the impact on Dell systems, visit https://access.redhat.com/kb/docs/DOC-47318 . For all other systems, it will be disabled by default; see Section A.2, "System Requirements" and Section A.3, "Enabling and Disabling the Feature" for more details. Regardless of the type of system, Red Hat Enterprise Linux 6 guests running under Red Hat Enterprise Linux 5 hosts will not have devices renamed, since the virtual machine BIOS does not provide SMBIOS information. Upgrades from Red Hat Enterprise Linux 6.0 to Red Hat Enterprise Linux 6.1 are unaffected, and the old eth[0123...] naming convention will continue to be used.

Commands:
25.3.5. Log Rotation The following is a sample /etc/logrotate.conf configuration file: All of the lines in the sample configuration file define global options that apply to every log file. In our example, log files are rotated weekly, rotated log files are kept for four weeks, and all rotated log files are compressed by gzip into the .gz format. Any lines that begin with a hash sign (#) are comments and are not processed. You may define configuration options for a specific log file and place it under the global options. However, it is advisable to create a separate configuration file for any specific log file in the /etc/logrotate.d/ directory and define any configuration options there. The following is an example of a configuration file placed in the /etc/logrotate.d/ directory: The configuration options in this file are specific for the /var/log/messages log file only. The settings specified here override the global settings where possible. Thus the rotated /var/log/messages log file will be kept for five weeks instead of four weeks as was defined in the global options. The following is a list of some of the directives you can specify in your logrotate configuration file: weekly - Specifies the rotation of log files to be done weekly. Similar directives include: daily monthly yearly compress - Enables compression of rotated log files. Similar directives include: nocompress compresscmd - Specifies the command to be used for compressing. uncompresscmd compressext - Specifies what extension is to be used for compressing. compressoptions - Specifies any options to be passed to the compression program used. delaycompress - Postpones the compression of log files to the rotation of log files. rotate INTEGER - Specifies the number of rotations a log file undergoes before it is removed or mailed to a specific address. If the value 0 is specified, old log files are removed instead of rotated. mail ADDRESS - This option enables mailing of log files that have been rotated as many times as is defined by the rotate directive to the specified address. Similar directives include: nomail mailfirst - Specifies that the just-rotated log files are to be mailed, instead of the about-to-expire log files. maillast - Specifies that the about-to-expire log files are to be mailed, instead of the just-rotated log files. This is the default option when mail is enabled. For the full list of directives and various configuration options, see the logrotate(5) manual page.

Commands:
rotate log files weekly weekly keep 4 weeks worth of backlogs rotate 4 uncomment this if you want your log files compressed compress
/var/log/messages { rotate 5 weekly postrotate /usr/bin/killall -HUP syslogd endscript }