Tuesday, 14 July 2026

Kubernetes cluster setup on Ubuntu 26.04 using Kubeadm

Step1: Disable swap memory: Kubernetes requires swap to be disabled for the kubelet to function correctly

# swapoff -a

# sudo sed -i '/ swap / s/^/#/' /etc/fstab


This disables swap immediately and make this change permanent


Step2: Load required kernel modules: Enable the overlay and br_netfilter modules needed for container networking

# cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf

overlay

br_netfilter

EOF


Run the following commands to load the modules

# modprobe overlay

# modprobe br_netfilter


These modules enable overlay networking and bridge netfilter functionality required by Kubernetes networking.


Step3: Configure sysctl parameters: Set kernel parameters for Kubernetes networking


# cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-iptables  = 1

net.bridge.bridge-nf-call-ip6tables = 1

net.ipv4.ip_forward                 = 1

EOF

# sysctl --system

These settings enable iptables to process bridged traffic and allow IP forwarding between network interfaces.


Step4: Verify prerequisites: Confirm all settings are correctly applied

# free -h | grep -i swap && lsmod | grep -E "overlay|br_netfilter" && sysctl net.ipv4.ip_forward

Swap should show 0B, both kernel modules should be listed, and ip_forward should equal 1.


Step5: Install Container Runtime

Kubernetes requires a container runtime to run containers. Ubuntu 26.04 includes containerd in its default repositories, which is the recommended runtime for Kubernetes deployments.


Install containerd: Install the container runtime from Ubuntu repositories

# apt update && apt install containerd -y


Generate default configuration: Create the containerd configuration directory and generate a default config file

# mkdir -p /etc/containerd

# containerd config default | sudo tee /etc/containerd/config.toml


Step6: Enable SystemdCgroup: Configure containerd to use systemd as the cgroup driver, which is required for Kubernetes

# sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

This ensures containerd and kubelet use the same cgroup driver, preventing resource management conflicts.


Restart containerd: Apply the configuration changes

# systemctl restart containerd

# systemctl enable containerd


Step7: Install Kubernetes Components on Ubuntu 26.04

With the container runtime configured, you can now install the core Kubernetes components. The installation requires adding the official Kubernetes package repository to your system.


Install required packages: Install dependencies needed to add the Kubernetes repository

# apt install apt-transport-https ca-certificates curl gnupg conntrack -y


Add Kubernetes GPG key: Download and install the repository signing key

# curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key | sudo gpg --dearmor --yes -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

This key verifies the authenticity of packages downloaded from the Kubernetes repository.


Add Kubernetes repository: Add the official Kubernetes apt repository

# echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list


Install Kubernetes packages: Update package lists and install kubeadm, kubelet, and kubectl

# apt update && apt install kubelet kubeadm kubectl -y


Hold packages: Prevent automatic upgrades that could break your cluster

# apt-mark hold kubelet kubeadm kubectl

Holding these packages ensures version consistency across your cluster and prevents unintended upgrades during system updates.



Step8: Initialize the Kubernetes Cluster

Now you can initialize your Kubernetes cluster using kubeadm. This process creates the control plane components and configures the cluster for operation.


Initialize the cluster: Run kubeadm init with the pod network CIDR

# kubeadm init --pod-network-cidr=10.244.0.0/16

The --pod-network-cidr flag specifies the IP address range for pod networking. The value 10.244.0.0/16 is compatible with Flannel, which we will install in the next section.


Sample output after the "kubeadm init"

-----------------

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube

  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.

Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:

  https://kubernetes.io/docs/concepts/cluster-administration/addons/


Then you can join any number of worker nodes by running the following on each as root:


kubeadm join 192.168.192.134:6443 --token gh7gno.yworbsfmf69g12g2 \

        --discovery-token-ca-cert-hash sha256:1bd571d1a1993841478caf85a7f150100daa5062ddb00f05b8f4c8d3f67c7ace

-----------------


Configure kubectl for your user: Set up kubectl access for the regular user. Run the following command as the regular user

$ mkdir -p $HOME/.kube

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

$ sudo chown $(id -u):$(id -g) $HOME/.kube/config


These commands copy the cluster admin configuration to your home directory and set proper ownership, allowing you to run kubectl commands without sudo.


Remove control plane taint (single-node only): Allow scheduling pods on the control plane node

$ kubectl taint nodes --all node-role.kubernetes.io/control-plane-


By default, Kubernetes prevents workloads from running on control plane nodes. For a single-node development cluster, removing this taint allows pods to be scheduled on the only available node.


Step9: Install Network Plugin

A pod network plugin is required for pods to communicate with each other across the cluster. Flannel is a simple and reliable choice that works well for most deployments.


$ kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml


This command downloads and applies the Flannel configuration, creating the necessary DaemonSet and ConfigMap resources


Verify network plugin deployment: Check that Flannel pods are running

$ kubectl get pods -n kube-flannel

Wait until all Flannel pods show a Running status before proceeding.


Verify Kubernetes Installation on Ubuntu 26.04

Check node status: Verify the node is ready

$ kubectl get nodes


Output should show your node with STATUS “Ready”. If the status shows “NotReady”, wait a few moments for the network plugin to initialize.


Check system pods: Verify all Kubernetes system components are running

$ kubectl get pods -n kube-system


All pods should show Running or Completed status.


Step10: Deploy a test application: Create a test pod to verify the cluster accepts workloads

$ kubectl run nginx --image=nginx --port=80

$ kubectl get pods


The nginx pod should transition to Running status within a minute, confirming that your cluster can pull images and schedule pods.



Accessing the nginx webserver outside the cluster for a local development setup

If you are running on-premises or using a local setup like Minikube/Kind where cloud load balancers aren't available, NodePort service is your go-to.


How it works:

Kubernetes opens a specific port (by default, in the high range of 30000–32767) on every single node (machine) in your cluster. Any traffic hitting that port on any node's IP address will be forwarded to your Nginx web server.


Label nginx pod so that it can be selected in service manifest for the pod discovery

$ kubectl label pod nginx app=nginx-webserver


vi nginx-nodeport.yaml

apiVersion: v1

kind: Service

metadata:

  name: nginx-nodeport

spec:

  type: NodePort

  selector:

    app: nginx-webserver

  ports:

    - protocol: TCP

      port: 80

      targetPort: 80

      nodePort: 32080 # Optional: Specify a port in the 30000-32767 range


$ kubectl apply -f nginx-nodeport.yaml

$ kubectl get service 

NAME             TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE

nginx-nodeport   NodePort   10.101.244.247   <none>        80:32080/TCP   18m


Find the nodes IP address and access over the browser as http://NODE_IP_ADDRESS:32080

Sample output:







Sunday, 10 October 2021

NFS traffic encryption using SSL / stunnel

Recently I got a requirement to implement encryption for NFS traffic.

NFS communication is clear text based communication. Transfer of confidential data should be encrypted  between the client and NFS server. Let me jump into the step by step implementation of this configuration.

I have used CentOS7 for the POC environment. Same steps would work with RHEL7 as well.

A pictorial representation of stunnel communication has given under Appendix3. Readers who wish to understand the communication flow might jump there.


LAB environment: 2 X  Virtualbox vm: 1 vCPU/1GB RAM 

  1. NFS server name: nfsserver.lab.com 

          IP address: 192.168.0.112

     2. NFS client name: nfsclient.lab.com

        IP address: 192.168.0.114


Steps to be executed on NFS server

  • Set hostname on NFS server. 

        # hostnamectl set-hostname nfsserver.lab.com

  • Set SELINUX to permissive.

            # setenforce 0  

  •  Stop firewalld

            # systemctl stop firewalld   

Note: These steps were executed temporarily. Once I manage to get this work with SELINUX and Firewall I would be updating this document.

  • Append the following entries in /etc/hosts.

             192.168.0.112 nfsserver nfsserver.lab.com

            192.168.0.114 nfsclient nfsclient.lab.com

  • Install NFS server and required packages.

           # yum -y install nfs-utils

  • Enable and start services related to NFS server.

          # for i in rpcbind nfs-server nfs-idmap nfs-lock nfs-idmap

            do 

                systemctl enable $i; systemctl start $i

            done

  • Create a path to be shared over NFS

          # mkdir /home/share

        

  • Configure and export the shares as mentioned below.  

         # cat /etc/exports

            /home/share 127.0.0.1(fsid=0,ro,insecure)

Note: Loopback entry looks little weird I know but this is required for this setup. insecure option is also required to accept connections from unprivileged ports.

        # exportfs -av


Let us setup Stunnel now.

Install stunnel package.

            # yum -y install stunnel

  • Next, create a user and directories to run the software - on this platform the RPM package does not create the user or directories:

            # useradd -r -m -d /var/run/stunnel -s /bin/false stunnel


  •  The tmpfiles.d configuration to recreate the directory on reboot:

            # echo "d /var/run/stunnel 0770 stunnel stunnel -" > /etc/tmpfiles.d/stunnel.conf


  • Create the systemd unit file to run stunnel as a service:

 [root@nfsclient ~]# cat << EOF > /etc/systemd/system/stunnel.service

[Unit]

Description=SSL tunnel for network daemons

After=syslog.target

[Service]

ExecStart=/usr/bin/stunnel

Type=forking

[Install]

WantedBy=multi-user.target

EOF


            # openssl req -new -newkey rsa:2048 -days 3650 \

                -nodes -x509 -sha256 \

                -subj '/CN=127.0.0.1/O=localhost/C=US' \

                -keyout /etc/stunnel/stunnel.pem \

                -out /etc/stunnel/stunnel.pem

          # chmod 400 /etc/stunnel/stunnel.pem


Next, create the stunnel server oriented config file; in our example we're using NFS service so we'll choose the ports accordingly to have stunnel accept the connection on the IP port 2363, then pass the connection to the localhost port 2049:

      [root@nfsclient ~]# cat << EOF > /etc/stunnel/stunnel.conf

chroot = /var/run/stunnel

setuid = stunnel

setgid = stunnel

pid    = /stunnel.pid

fips   = no


[nfs_server]

client     = no

accept     = nfsserver.lab.com:2363

connect    = 127.0.0.1:2049

cert       = /etc/stunnel/stunnel.pem

key        = /etc/stunnel/stunnel.pem

# stunnel 4.53 (Ubuntu 14) only supports TSLv1 not TLSv1.2

# stunnel 4.56 (CentOS 7) supports both TLSv1 and TSLv1.2

sslVersion = TLSv1

EOF

  • Start & enable stunnel service

        # systemctl start stunnel

        # systemctl enable stunnel


Steps specific to NFS Client

  • Set hostname on NFS Client. 

            # hostnamectl set-hostname nfsclient.lab.com

  • Ensure host entries are updated in /etc/hosts file.

  • Set SELINUX to permissive.

            # setenforce 0  

  •  Stop firewalld

            # systemctl stop firewalld   

Note: These steps were executed temporarily. Once I manage to get this work with SELINUX and Firewall I would be updating this document.

  • Append the following entries in /etc/hosts.

             192.168.0.112 nfsserver nfsserver.lab.com

            192.168.0.114 nfsclient nfsclient.lab.com


Stunnel setup on client end

        # yum -y install stunnel

Next, create a user and directories to run the software - on this platform the RPM package does not create the user or directories:

        # useradd -r -m -d /var/run/stunnel -s /bin/false stunnel

  • The tmpfiles.d configuration to recreate the directory on reboot:

        # echo "d /var/run/stunnel 0770 stunnel stunnel -" > /etc/tmpfiles.d/stunnel.conf


  • Create the systemd unit file to run stunnel as a service:

      # cat << EOF > /etc/systemd/system/stunnel.service

[Unit]

Description=SSL tunnel for network daemons

After=syslog.target


[Service]

ExecStart=/usr/bin/stunnel

Type=forking


[Install]

WantedBy=multi-user.target

EOF

The client does not require a SSL certificate; create the client oriented config file that accepts a connection on local port 2323 and talks to the remote stunnel on 2363:

# cat << EOF > /etc/stunnel/stunnel.conf

chroot = /var/run/stunnel

setuid = stunnel

setgid = stunnel

pid    = /stunnel.pid


[nfs_client]

client     = yes

accept     = 127.0.0.1:2323

connect    = nfsserver.lab.com:2363

# stunnel 4.53 (Ubuntu 14) only supports TSLv1 not TLSv1.2

# stunnel 4.56 (CentOS 7) supports both TLSv1 and TSLv1.2

sslVersion = TLSv1

EOF


        # systemctl start stunnel

        # systemctl enable stunnel


  • Update /etc/fstab with the following entry.

        [root@nfsclient ~]# grep share /etc/fstab

        localhost:/ /home/sslmount nfs noauto,vers=4.2,proto=tcp,port=2323 0 0


  • Create the mount point & mount the share. This will be mounted using stunnel. And the traffic would be encrypted between the client and NFS server.

        # mkdir /home/sslmount

        # mount /home/sslmount


Testing

Let us see the difference between an NFS mount with encryption and without encryption.

We have our NFS share mounted under /home/sslmount with encryption support. Let us mount the same share under /mnt without encryption for testing purpose.

Mount the share under /mnt ( without stunnel)
We need to update the share export configuration on the server to achieve this.
  •  Update /etc/exports on nfsserver.lab.com with the following entry.
    • /home/share nfsclient.lab.com(ro)
    • Re-export the shares with the new configuration.
      • # exportfs -rv

Mount the share on nfsclient.lab.com as mentioned below.

        # mount -t nfs nfsserver.lab.com:/home/share /mnt

  • Capture the traffic on NFS client on one terminal.

        # tcpdump -A -c 200 port 2049

  • Create a file under /home/share on NFS server with some content. Then we can read this file from the client end and generate some traffic. Sample Traffic is attached under Appendix1.

        # cat /mnt/file1


Let us capture the traffic and see how the traffic look like under the stunnel configured share.

  • Capture the traffic on NFS client on one terminal.

        # tcpdump -A -c 200 port 2363

  • Read file1 using the SSL supported mount path /home/sslmount/file1

        # cat /home/sslmount/file1

Sample Traffic is attached as Appendix2.


Following documents had helped me to setup this POC. You may go through them if interested.

Reference:

  1. http://kb.ictbanking.net/article.php?id=388&oid=2
  2. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_stunnel
  3. https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls


Appendices:


Appendix1:

09:30:10.254725 IP nfsclient.864 > nfsserver.nfs: Flags [P.], seq 4081390743:4081390847, ack 3818043196, win 259, options [nop,nop,TS val 5098426 ecr 5073639], length 104: NFS request xid 3398054478 100 access fh Un/0100010000000000 NFS_ACCESS_READ|NFS_ACCESS_LOOKUP|NFS_ACCESS_MODIFY|NFS_ACCESS_EXTEND|NFS_ACCESS_DELETE

E....l@.@......r...p.`...E.....<...........

.M...Mj....d..2N...........................,.A.!....nfsclient.lab.com...........................................

09:30:10.255466 IP nfsserver.nfs > nfsclient.864: Flags [P.], seq 1:125, ack 104, win 227, options [nop,nop,TS val 5097632 ecr 5098426], length 124: NFS reply xid 3398054478 reply ok 120 access c 001f

E....b@.@......p...r...`...<.E.............

.M...M.....x..2N....................................................... ...............................raa.]..hIaa.5....aa.!.o......

09:30:10.255481 IP nfsclient.864 > nfsserver.nfs: Flags [.], ack 125, win 259, options [nop,nop,TS val 5098426 ecr 5097632], length 0

E..4.m@.@..$...r...p.`...E...........Y.....

.M...M..

09:30:10.257665 IP nfsclient.864 > nfsserver.nfs: Flags [P.], seq 104:216, ack 125, win 259, options [nop,nop,TS val 5098428 ecr 5097632], length 112: NFS request xid 3414831694 108 getattr fh Unkno/01000181000000007500000000000000005AE099

E....n@.@......r...p.`...E.................

.M...M.....l..2N...........................,.A.!....nfsclient.lab.com.......................................u........Z..

09:30:10.258219 IP nfsserver.nfs > nfsclient.864: Flags [P.], seq 125:241, ack 216, win 227, options [nop,nop,TS val 5097635 ecr 5098428], length 116: NFS reply xid 3414831694 reply ok 112 getattr REG 644 ids 65534/65534 sz 27

E....c@.@......p...r...`.....E.o....24.....

.M...M.....p..2N...................................................................................uaa...mc.aa.|..L.aa.|..L.

09:30:10.259079 IP nfsclient.864 > nfsserver.nfs: Flags [P.], seq 216:332, ack 241, win 259, options [nop,nop,TS val 5098430 ecr 5097635], length 116: NFS request xid 3431608910 112 access fh Unkno/01000181000000007500000000000000005AE099 NFS_ACCESS_READ|NFS_ACCESS_MODIFY|NFS_ACCESS_EXTEND|NFS_ACCESS_EXECUTE

E....o@.@......r...p.`...E.o...,...........

.M...M.....p..2N...........................,.A.!....nfsclient.lab.com.......................................u........Z.....-

09:30:10.260372 IP nfsserver.nfs > nfsclient.864: Flags [P.], seq 241:365, ack 332, win 227, options [nop,nop,TS val 5097637 ecr 5098430], length 124: NFS reply xid 3431608910 reply ok 120 access c 0001

E....d@.@......p...r...`...,.E......06.....

.M...M.....x..2N.......................................................................................uaa...mc.aa.|..L.aa.|..L.....

09:30:10.300091 IP nfsclient.864 > nfsserver.nfs: Flags [.], ack 365, win 259, options [nop,nop,TS val 5098471 ecr 5097637], length 0

E..4.p@.@..!...r...p.`...E...........Y.....

.M...M..



Appendix2:

09:29:25.173066 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [P.], seq 3181805598:3181805848, ack 4011792125, win 529, options [nop,nop,TS val 5053344 ecr 5040935], length 250

E.....@.@......r...p.b  ;.............S.....

.M...L.'.... ..r.._.2...O&.|..)..g..U.....f..........1....7..|.c/       =A..%.

.O..CX.....n.a.....(n...YA....../.(''.?....A&i...$.....x;./..i.U,......YB8*L..^/C..U.?)j..>.B.;..I.$....0iO9....&...K...2L..E0...&...;..b...v.*E..,?..._N..X.q=X..B/q&.s..0...I.zjTf,c6=.

09:29:25.173695 IP nfsserver.mediacntrlnfsd > nfsclient.57186: Flags [P.], seq 1:251, ack 250, win 361, options [nop,nop,TS val 5052550 ecr 5053344], length 250

E...i.@.@.M....p...r    ;.b...........i.......

.M...M...... 1...e....[b.4f0o.K.K. {.2....7..........p...-....z.k{..<.j..&......4....).MT)[.i..I..F.Yny.+...[..#.NL\..,.d..?..b.NBRQq......O...j...Q.?... .E?..)d..J-.lQ...^..................W..A7e.bmht/.oA..2x..<*....F`pDr.#g..e.....['.sN)-.Ke......."..)..rk

09:29:25.173712 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [.], ack 251, win 548, options [nop,nop,TS val 5053345 ecr 5052550], length 0

E..4..@.@......r...p.b  ;...........$.Y.....

.M...M..

09:29:25.174855 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [P.], seq 250:580, ack 251, win 548, options [nop,nop,TS val 5053346 ecr 5052550], length 330

E..~..@.@..{...r...p.b  ;...........$.......

.M...M...... .m..N...&....Y.....V......C..i...... ..5+...&_s..+..

..%MEs..^..3.2....3.....U.c%.....].....

+..f.k+3..X....)S.~U...)...>....59...#..r.Y8..>(3...0-.Ub^=..4...S..n.<.!P.8.K.q...~gO.;..k.....e..%...i.Q@...  y37..F,*.H.'...\........e.....!...=...*?..=xH.&XK...p.1..b....}.2.........Qxq.4.pk..53..8M....T=....Qju..7I......=fi8r..j

09:29:25.175575 IP nfsserver.mediacntrlnfsd > nfsclient.57186: Flags [P.], seq 251:725, ack 580, win 369, options [nop,nop,TS val 5052552 ecr 5053346], length 474

E...i.@.@.L....p...r    ;.b.......b...q"......

.M...M...... .s.a...C.: 5...y.L.U..I..:A.5..r.......,y%...3o....5....P...Gw).0B....-.S.!w.IR..B.m..V.....C.M.I......r.C.H.|...Q.$p8"=.v..8R...0..`....x0..I..,.q9.34.     {.@*..p.n.z....).......JG|.1[.O.l.r.K{....?..#-....v.3A..PbC.o.B.x..........X...Q.<a&..'..iKY/.........C?.      ....s..+.....v.b/..*.h.Qr|..........M..>....R.....z.!^.../......92.^.....F!.f..e..Mr1...,...i.......@.E..P}S1v@^.L.?B..KV.....x...NB)#6..qx..n.i.A+.BJ]......V...B.Y.5....i.......FD2..J....{=..y.e..~r.R..=..)."

09:29:25.176932 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [P.], seq 580:846, ack 725, win 568, options [nop,nop,TS val 5053348 ecr 5052552], length 266

E..>..@.@......r...p.b  ;...b.......8.c.....

.M...M...... V.-5....Zi..K...../....f.......b...............j..r.]..X.F..+94...g.8.6..}..q....j.Y$.-..,.A..P...i...k._...~.....,.]U.#.#.ea<zB..i?..D..  ....f.

.......&W.......t..S...gv._b...W.L.a..]..O5=.z.N!..YT;e.RJ......e........,.."5!U1j..[.3.I-..[.......'*M;.......B@LI.

09:29:25.177580 IP nfsserver.mediacntrlnfsd > nfsclient.57186: Flags [P.], seq 725:927, ack 846, win 377, options [nop,nop,TS val 5052554 ecr 5053348], length 202

E...i.@.@.M....p...r    ;.b.......l...y.......

.M...M...... q.B.U.{,..9.#K.u.bg..N..mWs..){U.................y...#.A...Aw..o....r.....4......y|........}.._.'(.9hv.&v.......*....^]Xc....yI....~5........9.x.$No..3...K..9^.&z?...9i.......J... .Us.{...z.}7..[A}

09:29:25.179154 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [P.], seq 846:1112, ack 927, win 588, options [nop,nop,TS val 5053350 ecr 5052554], length 266

E..>..@.@......r...p.b  ;...l.......L.c.....

.M...M...... ..iL.w}..Rrs;.|.8..1..9x.n..aoru..........@..#!Pk...All..u@/~m.hsb.W....P.X....m...(.@.e...(h..=g*.*..-..6......x.....{.j.g.jE......._).........I.&...RIo.Q..

.v...(....JU..\...X..a.T..=......Y..O.y....x.^G.x.sw..wZ...=tGO..q..U1eLD..YA~<Uc...p..}...(.^*..G..".]

09:29:25.179745 IP nfsserver.mediacntrlnfsd > nfsclient.57186: Flags [P.], seq 927:1113, ack 1112, win 386, options [nop,nop,TS val 5052556 ecr 5053350], length 186

E...i.@.@.N....p...r    ;.b.......v...........

.M...M...... .B.P.t..Mi....[P.c3,.7P.:..$..4......7^....6...0.ty...U....E.M.%y.3.....%t........./.......b5(..5l..x..u3).Z...9F..Y9*.._y.)Ww...V.=...c.-....J.....X..G..

..      .DU....;E:....Va.......

09:29:25.219519 IP nfsclient.57186 > nfsserver.mediacntrlnfsd: Flags [.], ack 1113, win 608, options [nop,nop,TS val 5053391 ecr 5052556], length 0

E..4..@.@......r...p.b  ;...v...U...`.Y.....

.M...M..



Appendix3:

Here I am trying to provide a pictorial representation of this setup. 

An NFS request initiated by the NFS client would hit 2323 (accept entry under stunnel configuration on the client) port listening on loopback interface which is our stunnel service on the client. Stunnel would redirect this request on to the connect entry which is pointing at NFS server and its Stunnel port number,2363 (accept entry on NFS server side stunnel configuration. Stunnel service on NFS server would redirect this communication onto 2049 which is the connect entry on NFS server end Stunnel configuration.

Port 2049 is our NFS server port. Finally the request has reached NFS server.


Sunday, 20 September 2020

NTP client configuration on Linux - RHEL 6.


1. First you got to install the NTP package. I suggest you try using YUM for this task:
# yum install ntp
2. Then you want to have the NTP service started at boot time:
# chkconfig --levels 235 ntpd on
3. Specify the NTP server you’ll be synchronizing with. I suggest you use the NTP server pool from ntp.org:
if the system is connected to internet. Otherwise use your ntp server in the company network.
# ntpdate 0.pool.ntp.org
4. Start the NTP service:
# service ntpd start
********************************************************

Configure ntp client in a machine.

vi /etc/ntp.conf

#server 127.x.x.1
#fudge
server 10.1.0.34

wq!

ntpdate 10.1.0.34
service ntpd start
chkconfig ntpd on
chkconfig --list ntpd

To view the status of time synching with the ntp server. 
ntpq -pn
ntpstat








Wednesday, 9 April 2014

SFTP jailing in RHEL

SFTP jailing in RHEL


Requirement: Users need only sftp access  and they should be limited to their home directory.
Solution : Chrooted SFTP environment  with disallowing ftp access.

I used RHEL 6.2 Operating System  for  testing
Let the user be suresh .
Create a group; let it be sftponly.

èAdd the group
# groupadd  sftponly

èAdd the users with sftponly group membership.
# useradd -g sftponly -M -d /homedir -s /bin/false suesh  
-M option will help to not create the directory while adding the user. Non-existent shell prevent from interactive logins(SSH/telnet/rsh/rlogin etc)
# passwd suresh

èNow edit SSH server configuration file and comment the default Subsystem entry for sftp and add  “Subsystem                sftp        internal-sftp”  . Append Match block also.

# vi /etc/ssh/sshd_config
#Subsystem       sftp        /usr/libexec/openssh/sftp-server
Subsystem          sftp        internal-sftp

Match Group sftponly                                         
ChrootDirectory /chroots/%u          
AllowTcpForwarding no
ForceCommand       internal-sftp             
X11Forwarding no                                          

Match block matches the group sftponly and applies  below settings to  its members alone.
%u  stands for user_name  ; chrooted directory becomes /chroots/suresh   for  user suresh.


èCreate the directories and set sufficient permissions. 
# mkdir -p /chroots/suresh;chmod 755 /chroots/suresh
# mkdir /chroots/suresh/homedir
# chown suresh:sftponly /chroots/suresh/homedir

To secure from other users reading /chroots/suresh/homedir  contents.
# chmod 750 /chroots/suresh/homedir          


èNow restart SSH service.
# service sshd restart

To block ftp access …add the user name to /etc/vsftpd/ftpusers.
Now suresh has only sftp access (no ssh/telnet/rlogin/rsh/scp/ftp……) and his visibility is limited to /homedir only. For suresh   “/chroots/suresh” becomes the root directory ,ie; “/”. So this kind of setup is pretty secure.

Thursday, 3 April 2014

Xlib: PuTTY X11 proxy: wrong authentication protocol attempted

GUI installer fails to launch when executed with sudo


Problem:
 Application GUI installer fails to launch by throwing X related error messages when executed with sudo.
Scenario:
Application team has to install application with root privilleges but security policy does n't allow sharing root password.Here we provided necessary privilleges to the application user via sudo.But when the application user tried to start the install script which invokes a gui
got the following error messages:
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: wrong authentication protocol attempted
Error: Can't open display: localhost:10.0
Reason:
To get remote display exported to our local machine we need to have proper DISPLAY variable and X authentication for our X server(xming in our case).When the user logs in via ssh client,putty...DISPLAY variable will be set according to the putty X11forwarding configuration,and proper X authentication will be set up by adding entry to ~user/.Xauthority file.When we use sudo to get root privilleges X authentication will be expected from root user's configuration file(/.Xauthority).As the X authentication is updated to ~user/.Xauthority file while logging in to the OS directly via ssh; root user's Xauthority file will not have this information.This is why we get "Xlib: connection to "localhost:10.0" refused by server" message.

Work around:
I just created a softlink from ~user/.Xauthority to ~root/Xauthority.
eg:
# ln -s ~user/.Xauthority  /.Xauthority
This enabled root user to have proper X authentication to connect to xserver(xming) on the local machine.

Note:
When we switch to root user we have to set DISPLAY variable additionally by looking into the DISPLAY variable of the first login.
Eg:
$ echo $DISPLAY
localhost:10.0

$su -

# export DISPLAY=localhost:10.0

Monday, 17 March 2014

System time is one hour ahead of ntp server :AIX

Problem : System time is one hour ahead even ntp sync is proper.

Observation: I stoped the ntp client and set the time manually using date command .The moment i do an ntpdate to the time server system time jumps to one hour ahead.All other ntp clients were fine and were showing proper time.So this should be a problem with this particular client.

Client OS details: AIX 7.1

From the problematic client:
-------------------------------------
bash-4.2# date
Mon Mar 17 19:51:33 IST 2014           =>Time showing 19:51 which was 1 hour ahead that of  ntp server.

bash-4.2# date 031718512014             =>Set time manually.
Mon Mar 17 18:51:33 IST 2014          

bash-4.2# ntpdate  192.168.1.100             where 192.168.1.100 is my ntp server.
17 Mar 19:51:34 ntpdate[12386500]: adjust time server 192.168.1.100 offset  3600.479108

Please notice time is getting set to one hour ahead.

bash-4.2#date
Mon Mar 17 19:51:35 IST 2014

IST  word at the date command output gave an impression that Time zone is IST(GMT+5:30). But it was not true when checked the time zone.
bash-4.2# echo $TZ
IST-5:30IST

So changed the time zone to Asia/Kolkata(GMT+5:30) using smitty and restarted the system to effect the new Time zone.

smitty-->System Environments-->Change / Show Date and Time-->Change Time Zone Using System Defined Values-->Select Asia/Kolkata from the list-->Enter-->Enter -->Exit (F10)
Then took a reboot.
bash-4.2# shutdown -Fr

Once the system is back everything will be fine.

Thursday, 13 March 2014

An event was unable to invoke any of the subscribers:virtual router

Problem: Error message while starting Virtual Router "An event was unable to invoke any of the subscribers"

Reason: The problem happens when the Virtual Router isn't closed properly (ie when your connection disconnects or your computer locks up and needs to be restarted). The shared internet connection still has a lock on the share Virtual Router created, and so it can't create a new one.

In my case i have two  internet connections earlier i was using a data card which was shared and virtual router was using it .once the laptop woke up from hiberation i tried to connect via lan connection ,as the lock from data card was still there i ot into this issue.

Solution:
In Windows 7

Go to your Network and Sharing center -->Change adapter settings. Select the Internet adapter whose Internet connection you share with other devices.

Go to Internet Sharing. Break the lock on the old share by setting the adapter to share its connection with something else (whatever you have handy; network adapter, wireless, anything). You'll get a warning about the old share still being in effect. Break the old share, click OK until the settings for your adapter closes.

Open up your adapter's settings again, and remove the shared connection you just created. Keep clicking OK to close the adapter's settings.

Start up Virtual router again, and enjoy.

This isn't a problem specific to Virtual router, any similar app you try won't be able to create a share until you break the old one that Virtual router had.

Kubernetes cluster setup on Ubuntu 26.04 using Kubeadm

Step1: Disable swap memory: Kubernetes requires swap to be disabled for the kubelet to function correctly # swapoff -a # sudo sed -i '/...