NIS (Network Information Service)

Originally known as Yellow Pages (YP). Thus, the commands still begin with 'yp'. It is an RPC based client-server system used for distributed configuration of data such as 'user' and 'hostname' between computers on a computer network.

A NIS/YP system maintains and distributes central directory of user and group information, hostnames, email aliases and other text based tables of information in a network.

Note:  Portmap has been replaced by rpcbind in distros like RHEL-6, CentOS-6, Fedora8 and theire
         later versions. Portmap service is associated with RPCBind package.
/etc/rc.d/init.d/rpcbind

This setup is done on CentOS-6.6 system

A. NIS Server:

1. start the rpcbind (portmap in earlier versions) service;
# service rpcbind start
Starting rpcbind:                                          [  OK  ]

2. If reqd, do a yum search for 'ypserv'

# yum search ypserv
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
* base: mirrors.tummy.com
* extras: mirrors.psychz.net
* updates: mirror.supremebytes.com
======================================= N/S Matched: ypserv ========================================
ypserv.x86_64 : The NIS (Network Information Service) server

  Name and summary matches only, use "search all" for everything.

3. Install 'ypserv' package;
# yum install ypserv -y

4. Set the NISDOMAIN in /etc/sysconfig/network;
NISDOMAIN=blueangle.srv

5. Start the NIS service (ypserv);
# service ypserv start
Setting NIS domain name blueangle.srv:        [  OK  ]
Starting YP server services:                               [  OK  ]

6. # rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

7. Generate NIS Database:

# /usr/lib64/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers.  host-192-168-1-13 is in the list of NIS server hosts.  Please continue to add
the names for the other hosts, one per line.  When you are done with the
list, type a .
next host to add:  host-192-168-1-13
next host to add:
The current list of NIS servers looks like this:

host-192-168-1-13

Is this correct?  [y/n: y]  y
We need a few minutes to build the databases...
Building /var/yp/blueangle.srv/ypservers...
gethostbyname(): Success
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/blueangle.srv'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/blueangle.srv'

host-192-168-1-13 has been set up as a NIS master server.

Now you can run ypinit -s host-192-168-1-13 on all slave server.

9. After generating the database, you can see a new directory for your domain is created under
        /var/yp as shown below.
# ls -l /var/yp/
total 28
drwxr-xr-x. 2 root root  4096 Mar 18 09:06 blueangle.srv
-rw-r--r--. 1 root root 16675 Oct  7  2013 Makefile
-rw-r--r--. 1 root root    18 Mar 18 09:05 ypservers


B. NIS Client:

1. Install the client packages;
# yum install ypbind -y

2. Start rpcbind service (portmapper in older version)
# service rpcbind start
Starting rpcbind:                                          [  OK  ]

3. Provide the domainname and host info of the NIS server as;
In /etc/yp.conf,
domain blueangle.srv server host-192-168-1-13

4. Resolve the host information in /etc/hosts file on the client as;
192.168.1.13 host-192-168-1-13

5. Test the NIS server using the client tool (this is without starting 'ypbind');
# ypcat passwd
No such map passwd.byname. Reason: Can't bind to server which serves this domain

6. Start the ypbind (client) service and test again;

# service ypbind start
Starting NIS service:                                      [  OK  ]
Binding NIS service: .                                     [  OK  ]

7. # ypcat passwd
bijit:$1$cWrsV2Yk$7Ywe9qJ7x7c3C9ZAPWdBK.:500:500::/home/bijit:/bin/bash
ajith:$1$SWi8yVce$ooPNgNfhEhT9VOCkGkdaR1:501:501::/home/ajith:/bin/bash

These two users do not exist on the client system, they are read from the NIS server the client is
        connected to.

8. Check the NIS server the client is connected to;
# ypwhich
host-192-168-1-13

9. One may add the 'NIS' entry in /etc/nsswitch.conf (Name Service Switch)

passwd:     files nis
shadow:     files nis
group:      files nis


Once done, one may check with 'getent' command (it actually displays entries from the
        databases as supported in /etc/nsswitch.conf)

        [root@host-192-168-1-14 ~]# getent passwd | grep bijit
bijit:$1$cWrsV2Yk$7Ywe9qJ7x7c3C9ZAPWdBK.:500:500::/home/bijit:/bin/bash

10.   Now, try and switch user to 'bijit'

NOTE: To create user's home directory, one need to add the following line in
        /etc/pam.d/system-auth;

# add if you need ( create home directory automatically if it's none )
session     optional      pam_mkhomedir.so skel=/etc/skel umask=077 ## Added

[root@host-192-168-1-14 ~]# su - bijit
Creating directory '/home/bijit'.

Centralised SysLog server on CentOS

A centralised syslog server helps you to keep track of activities that are happening on remote systems. The centralised facility saves time as one does not need to log into each client to check logs and additionaly, it becomes very handy when a remote system crashes or compromised.

A. Server:

I. Installation

By default rsyslog (syslog on older systems) package is installed. If not, one can install it as;
# yum install rsyslog -y


II. Configuration

1. By default rsyslog is not configured to receive logs/messages from remote systems. One needs the enable the remote logging by uncommenting the following in "/etc/rsyslog.conf"

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

2. Once the changes are made, restart rsyslog service as;

# service rsyslog restart
Shutting down system logger:                          [  OK  ]
Starting system logger:                                    [  OK  ]


3. Check if it is listening on correct ports (both tcp and udp)
# netstat -atupn | grep 514
tcp        0      0 0.0.0.0:514          0.0.0.0:*           LISTEN      14374/rsyslogd
tcp        0      0 :::514                    :::*                    LISTEN      14374/rsyslogd
udp        0      0 0.0.0.0:514         0.0.0.0:*                               14374/rsyslogd
udp        0      0 :::514                   :::*                                        14374/rsyslogd



4. Allow the syslog port (port 514) to accept connetion from the clients for both TCP and UDP (an
                example only, IP 192.168.1.11 acts as client);

# iptables -I INPUT 4 -p tcp --dport 514 -s 192.168.1.11/24 -j ACCEPT
# iptables -I INPUT 5 -p udp --dport 514 -s 192.168.1.11/24 -j ACCEPT
# service iptables save
# service iptables restart


B. Client:

1. On the client system (i.e. 192.168.1.11), install the rsyslog package as was in server.

2. Open /etc/rsyslog.conf
Navigate to the bottom of the file and add the type of log you want your remote server to keep                     track of eg. I did the following

*.info;mail.none;authpriv.none;cron.none   @192.168.1.10

3. Restart syslog service

# service rsyslog restart
Shutting down system logger:                          [  OK  ]
Starting system logger:                                    [  OK  ]




Now, on the server we may check /var/log/messages file to see if the activities on the remote client is being logged !


Happy logging ! :)

LVM - Exporting and Importing the Volume Group - the Correct way

There could be a need to move the entire LVM Volume group from one system to another system. Following are the steps to it in the proper way;

1. Check the mount info of the LVM  (Showing only the relevant mount point):
/dev/mapper/vg--1-lv--1 on /bijitLVM type ext4 (rw)

2. Unmount the LV:
# umount /bijitLVM/

3. Deactivate the Volume Group (VG):
# lvs
 LV   VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert
 lv-1 vg-1 -wi-a- 2.00g

# vgchange -an vg-1
 0 logical volume(s) in volume group "vg-1" now active
 The link /dev/vg-1/lv-1 should have been removed by udev but it is still present. Falling back to
   direct link removal.

# lvs
 LV   VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert
 lv-1 vg-1 -wi--- 2.00g

4. Export the Volume Group:
# vgexport -v vg-1
   Using volume group(s) on command line
   Finding volume group "vg-1"
 Volume group vg-1 is exported

5. PVScan to check PV status:
# pvscan
 PV /dev/sda6    is in exported VG vg-1 [3.71 GiB / 1.71 GiB free]
 PV /dev/sda7    is in exported VG vg-1 [3.72 GiB / 3.72 GiB free]
 Total: 2 [7.43 GiB] / in use: 2 [7.43 GiB] / in no VG: 0 [0   ]

Now, one may detach the physical drives associated with the Volume Group from the system (on shutdown). Attach the drives to another system and perform the sequence of steps below;

6. Import the VG:
# vgimport -v vg-1
   Using volume group(s) on command line
   Finding volume group "vg-1"
   Archiving volume group "vg-1" metadata (seqno 4).
   Creating volume group backup "/etc/lvm/backup/vg-1" (seqno 5).
 Volume group "vg-1" successfully imported

7. PVScan to check PV status
# pvscan
 PV /dev/sda6   VG vg-1   lvm2 [3.71 GiB / 1.71 GiB free]
 PV /dev/sda7   VG vg-1   lvm2 [3.72 GiB / 3.72 GiB free]
 Total: 2 [7.43 GiB] / in use: 2 [7.43 GiB] / in no VG: 0 [0   ]

8. Activate the VG
# vgchange -ay vg-1
 1 logical volume(s) in volume group "vg-1" now active
 /dev/mapper/vg--1-lv--1 not set up by udev: Falling back to direct node creation.
 The link /dev/vg-1/lv-1 should had been created by udev but it was not found. Falling back to
   direct link creation.

# lvs
 LV   VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert
 lv-1 vg-1 -wi-a- 2.00g            

Fedora, RHEL or CentOS ?

Fedora

1. Run by Redhat 
2. Community supported.
3. It is the upstream distribution for both CentOS and Red Hat Enterprise  
   Linux. 
4. Acts as a test bed for future versions Red Hat Enterprise Linux (RHEL)
5. Release life cycle is 6 months (approx.), thus it has short 
   development, support life cycle.
6. Focusses more on the newer features rather then stability (since it 
   acts a test bed for future RHEL). Thus, more popular as Desktops 
   rather then production servers, in case of servers stability is 
   expected which is not the case with Fedora due to its short life cycle 
   and support and constant shifting APIs to incorporate newer features. 


Red Hat Enterprise Linux (RHEL)

1. Run by Redhat
2. Fully supported by Redhat but at a cost, thus it is not "free" to use 
   although source code can be used freely and distributed.
3. Red Hat support services, service level agreements, and certification 
   programs are based on RHEL.
4. Long life and support cycles of 7 years (approx) and support extended 
   to 10 years (approx).
5. Due to long life cycle focus is on stability rather then features. 
   Thus, ideal for Servers at the Enterprise level.


CentOS (Community Enterprise Operating System)
1. Community run.
2. Clone of RHEL in fact "binary compatible"
3. Long life and support cycles. The support is purely community based 
   and thus it is free.
4. It is a free drop-in replacement for RHEL.

*  Scientific Linux (SL) is another distribution run by "Fermi National 
   Accelerator Laboratory" . It is free and claims to be a clone of RHEL.

What to choose?
A. If stability and long term support are not the issues but cost is - 
   Fedora
B. If stability and cost are the issues and you want get long term 
   support service for free (community support)  - CentOS
C. But, if you want stability with long term dedicated support and ready 
   to pay  - RHEL

Note:
Who maintains Linux Kernel ?
Linus Torvalds, and he receives patches from different subsystems
Official website:    https://kernel.org/

NFS - Network File System

What is NFS?

Network File System or NFS is a client/server system. It allows users to access files across network and the shared files/directories from remote are treated as if they reside on local system.

Works on both TCP and UDP protocol.

The stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks.

Note (From CentOS official docs):

NFSv4 has no interaction with portmapper, rpc.mountd, rpc.lockd, and rpc.statd, since protocol support has been incorporated into the v4 protocol. NFSv4 listens on the well known TCP port (2049) which eliminates the need for the portmapper interaction. The mounting and locking protocols have been incorpated into the V4 protocol which eliminates the need for interaction with rpc.mountd and rpc.lockd.

Salient features:

* A NFS file system mounted is very similar to a local file system on the machine
* NFS does not disclose the location of a file on the network
* An NFS server can be made of a completely different architecture and operating system
        than the client
* It also never discloses the underlying file system on the remote machine

Versions:
Currently there are three versions available viz. NFSv2, NFSv3 & NFSv4

Setup on CentOS-6.5 systems:
Following are the IP details of the server and the Client for this example setup;

i. Server: 172.16.20.8
ii. Client: 172.16.20.9

A. NFS Server (IP 172.16.20.8):

1. Install the packages;
yum install nfs*

2. Start the NFS service;
# service nfs start
Starting NFS services:      [  OK  ]
Starting NFS mountd:        [  OK  ]
Starting NFS daemon:        [  OK  ]
Starting RPC idmapd:        [  OK  ]

[NOTE:  Although, it is mentioned that rpcbind (earlier Portmapper) services are incorporated into NFS-V4 and there is no need to start the rpcbind service explicitly, I encountered NFS services failed to start without explicitly starting the "rpcbind" service; thus if you encounter the same, start the rpcbind service as; 

# service rpcbind start
Starting rpcbind:                                          [  OK  ]

]

3. Ports it listen to;

111/tcp  open  rpcbind
2049/tcp open  nfs

4. Open the relevant ports in the firewall so that they are accessible;

# iptables -I INPUT 4 -p tcp --dport 111 -j ACCEPT
# iptables -I INPUT 4 -p tcp --dport 2049 -j ACCEPT

Note: Number '4' is the position in the INPUT chain where these records are inserted, could be different in your case. Find that out using "iptables -L INPUT --line-numbers"

5. Create a NFS share;
mkdir /nfsshare

6. Share the directory with NFS client (172.16.20.9):

vi /etc/exports
/nfsshare 172.16.20.9(rw,sync,no_root_squash)


B. On the Client (172.16.20.9):

1. Install the packages
        #yum install nfs*

2. Start NFS service;
        # service nfs start

3. You may check all the rpcservices information on the server using;
         # rpcinfo -p 172.16.20.8

2. Create the mount point to mount the NFS share;
# mkdir /opt/nfs_share

3. Mount the NFS share directory from the NFS server to the client;
# mount -t nfs 172.16.20.8:/nfsshare/ /opt/nfs_share/

4. Check with mount command;
# mount
/dev/vda1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
172.16.20.8:/nfsshare/ on /opt/nfs_share type nfs (rw,vers=4,addr=172.16.20.8,clientaddr=172.16.20.9)

5. On the client, one may also check with 'nfsstat -m' command (displays details about nfs mounts)

# nfsstat -m
/opt/nfs_share from 172.16.20.8:/nfsshare/
Flags:
rw,relatime,vers=4,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.16.20.9,minorversion=0,local_lock=none,addr=172.16.20.8

Now, create files or directories under /opt/nfs/ (on the client) or /nfsshare on the server to see if they are visible/accessible to each other.

C. NFS Options:

1. The following would provide statistics about NFS server and client respectively;
nfsstat -s
nfsstat -c

2. Important configuration files (all man page info);

/etc/sysconfig/nfs
/etc/nfsmount.conf ---->  Configuration  file  for  NFS  mounts  that  allows options to be set
                                             globally, per server or per mount point.
/etc/exports     ---->  Contains  a table of local physical file systems on an NFS server that
                                             are accessible to NFS clients.

3. Any changes to the /etc/exports would only require to have NFS services reloaded to
        make the changes effective. This does not require clients to unmount NFS share or the
        any service restarts on clients and server.

eg.

Thus, an entry like the following in /etc/exports;
/nfsshare 172.16.20.9(rw,sync,no_root_squash)

when changed to ('rw' to 'ro');
/nfsshare 172.16.20.9(ro,sync,no_root_squash)

It only needs 'service nfs restart' on the NFS Server to make the changes effective.


D. NFS share options:

1. ro:    With the help of this option we can provide read only access to the shared files i.e client
                will only be able to read.

2. rw:   This option allows the client server to both read and write access within the shared
                directory.

3. sync:   Sync confirms requests to the shared directory only once the changes have been
                  committed.

4. no_subtree_check:   This option prevents the subtree checking. When a shared directory
                                       is the subdirectory of a larger file system, nfs performs scans of every
                                       directory above it, in order to verify its permissions and details.

                   Disabling the subtree check may increase the reliability of NFS, but reduce security.

5.     no_root_squash:    This phrase allows root to connect to the designated directory.
                                     Thus, remote  "root" user on the client would be treated a                                  
                                     local "root" user on the server.
                                      The opposite is "root_squash".

Issues:
1. # showmount -e
clnt_create: RPC: Unknown host

Solution: Check using;

                # showmount -e localhost
         Export list for localhost:
        /nfsshare 172.16.20.9

         Now, provide a hostname entry with IP in the /etc/hosts as;
         172.16.20.8 ins-1

         Where, ins-1 is the hostname as revealed by;
           # hostname
           ins-1