Importance of configuring ifcfg-ethX properly to resolve DNS

I have an interesting problem today. I have configured my compute nodes to access the public network via the head node as the gateway. A good tutorial can be found from
Using iptables to allow compute nodes to access public network from Linux Cluster Blog.


Occasionally, 1 or 2 nodes will not be able to resolve even though /etc/resolv.conf is configured correctly. It seems that only after putting in the localised DNS at /etc/sysconfig/network-script/ifcfg-ethX at the compute node, it was able to resolve.

DEVICE=eth0
BOOTPROTO=static
HWADDR=E4:1F:13:CC:51:54
ONBOOT=yes
HOTPLUG=no
IPADDR=192.168.5.17
NETMASK=255.255.255.0
GATEWAY=192.168.5.1
DNS1=155.1.1.2
DNS2=155.1.1.3
PEERDNS=yes

I suspect it could be due to the multiple NIC with multiple network segment issues and localised DNS resolution at network level.

Take a look at  Redhat Document 8.2 Interface Configuration Files

Programmable Data Centre

This is an interesting article on programmable data centre titled "The Rise of the Programmable Data Center". To quote the aricle

In order to address these issues, there’s a movement afoot to create the “programmable data center,” where an IT administrator can more holistically manage servers, storage, and networking components. While still in its relative infancy, a number of vendors have expressed interest in the movement’s underlying concepts, all but ensuring its growth in coming years

Do read up.

libimf.so: cannot open shared object file: No such file or directory

If you are encounter a problem

mpicc: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory.

 The solution can be easily solved by the following:

# touch /etc/ld.so.conf.d/intel.conf

# vim /etc/ld.so.conf.d/intel.conf  

Inside /etc/ld.so.conf.d/intel.conf

/opt/intel/lib/intel64

Tunable TCP/IP kernel options

Linux has placed each of the tunable kernel variable into the /proc virtual filesystem. The networking variables are in /proc/sys/net/ipv4. Here are some of the trimmed list.

# cd /proc/sys/net/ipv4

# ls -F

......... 

tcp_abc                           tcp_keepalive_time    tcp_sack
tcp_abort_on_overflow             tcp_low_latency       tcp_slow_start_after_idle
tcp_adv_win_scale                 tcp_max_orphans       tcp_stdurg
tcp_allowed_congestion_control    tcp_max_ssthresh      tcp_synack_retries
tcp_app_win                       tcp_max_syn_backlog   tcp_syncookies
tcp_available_congestion_control  tcp_max_tw_buckets    tcp_syn_retries
tcp_base_mss                      tcp_mem               tcp_thin_dupack
tcp_congestion_control            tcp_moderate_rcvbuf   tcp_thin_linear_timeouts
tcp_dma_copybreak                 tcp_mtu_probing       tcp_timestamps
tcp_dsack                         tcp_no_metrics_save   tcp_tso_win_divisor
tcp_ecn                           tcp_orphan_retries    tcp_tw_recycle
tcp_fack                          tcp_reordering        tcp_tw_reuse
tcp_fin_timeout                   tcp_retrans_collapse  tcp_window_scaling
tcp_frto                          tcp_retries1          tcp_wmem
tcp_frto_response                 tcp_retries2          tcp_workaround_signed_windows
tcp_keepalive_intvl               tcp_rfc1337
tcp_keepalive_probes              tcp_rmem

.....................

To make changes on the fly, you can just simply echo the value and pipe it to the options. For example,

# echo 1 > /proc/sys/net/ipv4/ip_forward

Modifying users group on the fly

This is a simple entry but sometimes tend to forget until I do a man page. Adding a users to a group cannot be easier on Linux

If you are adding a user to a secondary group, use the flag -G

# useradd -d /home/users -g users -G g09 user1

If you are modifying a user from a secondary group, use the flag -G

# usermod -G g09 user1