By William Sescu
This is a follow up to the Blog were I explained how to disable IPv6 on Oracle Linux 7.
If you have done all the steps which I have explained here http://blog.dbi-services.com/oel-7-how-to-disable-ipv6-on-oracle-linux-7/ then you have already IPv6 successfully disabled. However, some tools require some special attention afterwards if you want to avoid some ugly warning or error messages. There are so many tools that can use IPv4 and IPv6, but it is impossible to mention all of them. I will just dig a little deeper into the following 4.
Let’s start with Postfix. This might be one of the first warning messages you see, in case you have disabled IPv6 on your system. If you receive the following warning message when you try to send an email, then you need to adjust your /etc/postfix/main.cf file.
$ mailx -s "Test" [email protected] Test . EOT $ send-mail: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol send-mail: warning: inet_protocols: configuring for IPv4 support only postdrop: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol postdrop: warning: inet_protocols: configuring for IPv4 support only
The solution is to configure your /etc/postfix/main.cf file to allow only the ipv4 protocol.
[[email protected] sbin]# /usr/sbin/postconf | grep inet_protocols inet_protocols = all /usr/sbin/postconf: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol /usr/sbin/postconf: warning: inet_protocols: configuring for IPv4 support only [[email protected] sbin]# cd /etc/postfix/ [[email protected] postfix]# cp main.cf main.cf.20170203a [[email protected] postfix]# vi main.cf
Change “inet_protocols = all” to “inet_protocols = ipv4” and then restart PostFix.
[[email protected] postfix]# /etc/init.d/postfix restart Shutting down postfix: [ OK ] Starting postfix: [ OK ] [[email protected] postfix]# /usr/sbin/postconf | grep inet_protocols inet_protocols = ipv4
That’s it. Now the ugly Postfix warning messages disappear.
The next candidate is the Oracle Listener. In some situations, you might see the following error message in your listener.log file when working with Cloud Control 12c.
TNS-01189: The listener could not authenticate the user
This is related to an Oracle bug, to be more precise, it is “BUG 16054202 – TNLIN EXTRACTS WRONG SUBNETMASK FOR IPV6 ADDRESSES”. The bug can be fixed by configuring the Oracle Listener to work with IPv4 only. This is done via the listener.ora IP parameter, which knows the following options.
Listen on the first IP address returned by the DNS resolution of the host name.
If the user wants the listener to listen on the first IP to which the specified host name resolves,
then the address must be qualified with (IP=first).
Listen only on IPv4 addresses.
Listen only on IPv6 addresses.
Simply put the (IP=V4_ONLY) after your PORT setting, and then restart the listener like shown in the following example.
-- listener.ora LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dbidg03)(PORT = 1521)(IP=V4_ONLY)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) ) -- restart $ lsnrctl stop LISTENER; lsnrctl start LISTENER
Now the messages “TNS-01189: The listener could not authenticate the user” in the listener.log should disappear.
Under normal circumstances, no changes should be required for NFS unless you had proto=tcp6 configured for your mount options. If so, then your mount will not work anymore.
[[email protected] etc]# mount /u99 mount.nfs: an incorrect mount option was specified
And you will see the following error in the /var/log/messages file.
Feb 14 10:26:48 dbidg02 kernel: NFS: server address does not match proto= option
Now you could either remove the proto option or change it to proto=tcp.
For NFS version 4 you have the following options:
proto=netid The netid determines the transport that is used to communicate with the NFS server. Supported options are tcp, tcp6, and rdma. tcp6 use IPv6 addresses and is only available if support for TI-RPC is built in. Both others use IPv4 addresses.
In my case, I have added the proto=tcp option to my NFS mount table in the /etc/fstab
#-- NFS mounts dbidg03:/u99 /u99 nfs vers=4.1,proto=tcp,rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,timeo=600 -- And now the mount works perfectly again. [[email protected] etc]# mount /u99 [[email protected] etc]# [[email protected] etc]# mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) nfsd on /proc/fs/nfsd type nfsd (rw,relatime) dbidg03:/u99 on /u99 type nfs4 (rw,relatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.202,local_lock=none,addr=192.168.56.203)
Now the NFS mount works again.
Almost the same applies to the rsyslogd. In case you have not specified “-6” in your syslogd options, you are fine. If not, you need to either remove the option or replace it with “-4”
[email protected]:/etc/sysconfig/ [oms13c] rpm -qa | grep rsyslog rsyslog-7.4.7-16.0.1.el7.x86_64 -- from the doc -4 Causes rsyslogd to listen to IPv4 addresses only. If neither -4 nor -6 is given, rsyslogd listens to all configured addresses of the system.
[[email protected] sysconfig]# cat rsyslog # Options for rsyslogd # Syslogd options are deprecated since rsyslog v3. # If you want to use them, switch to compatibility mode 2 by "-c 2" # See rsyslogd(8) for more details SYSLOGD_OPTIONS="-4" [[email protected] sysconfig]# systemctl restart rsyslog [[email protected] sysconfig]#
There might be some tools on your system that requires special attention after you have disable IPv6 on your system.