samba4 component, BZ#878168
If configured, the Active Directory (AD) DNS server returns IPv4 and IPv6 addresses of an AD server. If the FreeIPA server cannot connect to the AD server with an IPv6 address, running the
ipa trust-add command will fail even if it would be possible to use IPv4. To work around this problem, add the IPv4 address of the AD server to the
/etc/hosts file. In this case, the FreeIPA server will use only the IPv4 address and executing
ipa trust-add will be successful.
Destroying the root port before any NPIV ports can cause unexpected system behavior, including a full system crash. Note that one instance where the root port is destroyed before the NPIV ports is when the system is shut down. To work around this problem, destroy NPIV ports before destroying the root port that the NPIV ports were created on. This means that for each created NPIV port, the user should write to the
sysfs vport_delete interface to delete that NPIV port. This should be done before the root port is destroyed. Users are advised to script the NPIV port deletion and configure the system such that the script is executed before the
fcoe service is stopped, in the shutdown sequence.
A Linux LIO FCoE target causes the
bfa driver to reset all FCoE targets which might lead to data corruption on LUN. To avoid these problems, do not use the
bfa driver with a Linux FCoE target.
NetworkManager component, BZ#896198
GATEWAY setting in the
/etc/sysconfig/network file causes NetworkManager to assign that gateway to all interfaces with static IP addresses, even if their configuration did not specify a gateway or specified a different gateway. Interfaces have the incorrect gateway information and the wrong interface may have the default route. Instead of using
/etc/sysconfig/network to specify which interface receives the default route, set
DEFROUTE=no in each
ifcfg file that should not have the default route. Any interface connected using configuration from an
ifcfg file containing
DEFROUTE=no will never receive the default route.
Typically, on platforms with no Intelligent Platform Management Interface (IPMI) hardware the user can see the following message the on the boot console and in dmesg log:
Could not set up I/O space
This message can be safely ignored, unless the system really does have IPMI hardware. In that case, the message indicates that the IPMI hardware could not be initialized. In order to support Advanced Configuration and Power Interface (ACPI) opregion access to IPMI functionality early in the boot, the IPMI driver has been statically linked with the kernel image. This means that the IPMI driver is "loaded" whether or not there is any hardware. The IPMI driver will try to initialize the IPMI hardware, but if there is no IPMI hardware present on the booting platform, the driver will print error messages on the console and in the dmesg log. Some of these error messages do not identify themselves as having been issued by the IPMI driver, so they can appear to be serious, when they are harmless.
Shutting down the
fcoe-target service while the Fibre Channel over Ethernet (FCoE) can lead to a kernel crash. Please minimize FCoE traffic before stopping or restarting this service.
After an ixgbe Fibre Channel over Ethernet (FCoE) session is created, server reboot can cause some or all of the FCoE sessions to not be created automatically. To work around this problem, follow the following steps (assuming that eth0 is the missing NIC for the FCoE session):
ifconfig eth0 down
ifconfig eth0 up
dcbtool sc eth0 dcb on
dcbtool sc eth0 pfc e:1 a:1 w:1
dcbtool sc eth0 app:fcoe e:1 a:1 w:1
service fcoe restart
targetcli to configure the FCoE Target will fail with the message
Could not create RTSRoot in configFS. To prevent this, ensure that the
fcoe-target service is running by executing
service fcoe-target start.
The InfiniBand UD transport test utility could become unresponsive when the
ibv_ud_pingpong command was used with a packet size of 2048 or greater. UD is limited to no more than the smallest MTU of any point in the path between point A and B, which is between 0 and 4096 given that the largest MTU supported (but not the smallest nor required) is 4096. If the underlying Ethernet is jumbo frame capable, and with a 4096 IB MTU on an RoCE device, the max packet size that can be used with UD is 4012 bytes.
IPA creates a new DNS zone in two separate steps. When the new zone is created, it is invalid for a short period of time.
A/AAAA records for the name server belonging to the new zone are created after this delay. Sometimes, BIND attempts to load this invalid zone and fails. In such a case, reload BIND by running either
rndc reload or
service named restart.
SELinux can prevent the
nmbd service from writing into the
/var/, which breaks NetBIOS name resolution and leads to SELinux AVC denials.
If multiple DHCP6 servers are configured on multiple VLANs, for example two DHCP6 servers on VLAN1 and VLAN3, the bna driver NIC does not set up a VLAN interface but can get the VLAN3 IPv6 address.
The latest version of the sfc NIC driver causes lower UDP and TX performance with large amounts of fragmented UDP packets. This problem can be avoided by setting a constant interrupt moderation period (not adaptive moderation) on both sides, sending and receiving.
When IPv6 is administratively disabled via
disable=1 module parameter, all of the IPv6 protocol handlers are disabled. This includes any offload handlers that support TSO/GSO. The lack of handlers results in the host dropping any TSO/GSO IPv6 packets it may receive from the guest. This can cause problems with retransmission on the guest and throughput. If you want to disable IPV6 support on the host administratively while enabling and providing IPv6 support to the guest without incurring a performance penalty:
Some network interface cards (NICs) may not get an IPv4 address assigned after the system is rebooted. To work around this issue, add the following line to the
NetworkManager component, BZ#758076
If a Certificate Authority (CA) certificate is not selected when configuring an 802.1x or WPA-Enterprise connection, a dialog appears indicating that a missing CA certificate is a security risk. This dialog presents two options: ignore the missing CA certificate and proceed with the insecure connection, or choose a CA certificate. If the user elects to choose a CA certificate, this dialog disappears and the user may select the CA certificate in the original configuration dialog.
Current Samba versions shipped with Red Hat Enterprise Linux 6.4 are not able to fully control the user and group database when using the
back end. This back end was never designed to run a production LDAP and Samba environment for a long period of time. The
back end was created as a tool to ease migration from historical Samba releases (version 2.2.x) to Samba version 3 and greater using the new
back end and the new LDAP schema. The
back end lack various important LDAP attributes and object classes in order to fully provide full user and group management. In particular, it cannot allocate user and group IDs. In the Red Hat Enterprise Linux Reference Guide
, it is pointed out that this back end is likely to be deprecated in future releases. Refer to Samba's documentation
for instructions on how to migrate existing setups to the new LDAP schema.
When you are not able to upgrade to the new LDAP schema (though upgrading is strongly recommended and is the preferred solution), you may work around this issue by keeping a dedicated machine running an older version of Samba (v2.2.x) for the purpose of user account management. Alternatively, you can create user accounts with standard LDIF files. The important part is the assignment of user and group IDs. In that case, the old Samba 2.2 algorithmic mapping from Windows RIDs to Unix IDs is the following: user RID = UID * 2 + 1000, while for groups it is: group RID = GID * 2 + 1001. With these workarounds, users can continue using the
ldapsam_compat back end with their existing LDAP setup even when all the above restrictions apply.
Because Red Hat Enterprise Linux 6.4 defaults to using Strict Reverse Path filtering, packets are dropped by default when the route for outbound traffic differs from the route of incoming traffic. This is in line with current recommended practice in RFC3704. For more information about this issue please refer to