Lab 3 – Due: Week 8 (17 July 2020, by midnight)

Do this lab with your FAST private cloud remote VMs.

1. Put your answers in this document.
2. When you are done, hi-light your answers in YELLOW and submit this document to SLATE.
3. Keep all the results of your work on your Linux VM. You may be asked to demo them later, to complete the marking of
this exercise.
4. Answer those questions which are hi-lighted in green.
5. Caution: sometimes copy/paste from this doc to an SSH or ‘nomachine’ client results in incorrect characters (ex.:
hyphens ‘-‘ and double-quotes “”). If you do copy, these characters may need to be fixed.

Lesson 5 Exercises
Part 5.1 – Networking (Assigning static and dynamic IP Addresses) (documentation:
https://ubuntu.com/server/docs/network-configuration & https://ubuntu.com/server/docs/network-dhcp)

IMPORTANT: most likely Linux will name your network interface card using the “ens##” naming
convention (where ## is a number). You can verify the names by running the ‘ip’ command. (An older
naming convention used “eth#” for NICs). This example shows two interfaces named ‘ens33’ and
‘ens37’ with their IP addresses.

Start the Desktop and Server01 VMs. These VMs are already on the same subnet. Do all your work at the
Command Line. View the ‘man’ page for the ‘ping’ command. At the Desktop, ping Server01 (this command
runs non-stop – press ‘Ctrl-C’ to stop it). Then ping Desktop from Server01.

5.1 a) Do these VMs have network connectivity? [yes/no]

YES
b) Put here the screenshot of the ping from Desktop.

c) View the ‘man’ page for the ‘ip’ command. Check the IP information on both VMs. A short form of the
above “ip address show” command is “ip a”. Put a screenshot of your result at the Desktop:
d) Identify the interface used by Desktop:
ens160

Deleting/Adding Static IP Addresses

There are two ways to set the IP address:
1) With the ‘netplan’ configuration. This method is easy and persistent (meaning, after a reboot, the
static address will be retained). It uses YAML files (‘Yet Another Markup Language’ – we won’t learn this
language in this course, we’ll just use provided files).

2) With the ‘ip’ command. This method is temporary – the address is not retained in a reboot, but
reverts back to the address specified by netplan.

Note: Due to settings in the FAST private cloud, if we change the Desktop’s IP address, we can no longer
access it with an SSH Client or the ‘nomachine’ client. So the ‘vcenter’ site with a browser must be used.

1) STEPS using netplan

5.1.1 On Desktop, go to /etc/netplan.
5.1.2 List the files there. You likely have two: 01-network-manager-all.yaml and 99-netcfg-vmware.yaml
The ’01…’ file is not used now – we’ll ignore it. The ’99…’ file is setting the address now.
5.1.3 Make a backup copy of the ’99…’ file – name it
‘99-netcfg-vmware.yaml.bak’. View the file. It should be like the one
shown here. The red marks show: the interface name, DHCP is not
used and the address is statically set to ‘…13’.

5.1.4 Edit this file and set the address to 192.168.10.100

5.1.5 Reboot to make the VM recognize the new address:

sudo init 6 (recall runlevel 6 is for reboot – the reboot
command also works)

5.1.6 After the VM reboots, use ‘ip’ to verify it has the new address.
Put a screenshot here showing its output:
5.1.7 Verify Desktop can ping Server01 and vice-versa.

2) STEPS using ‘ip’ Command

5.1.8 At Desktop, first we delete the …100 address: sudo ip a del 192.168.10.100/24 dev ens160
(if your interface has a name other than ens160, insert your interface name)
5.1.9 Add a different address (use 101): sudo ip a add 192.168.10.101/24 dev ens160
5.1.10 Verify you have the new address, then verify Desktop can ping Server01 and vice-versa. Show the ping
from Server01:

STEPS for Using DHCP to Set IP Addresses

It may help for you to review your Networking course notes on how DHCP works, before you do this section.

5.1.11 First we must install DHCP Server on the Server01 VM (Server02 VM could also be used – for these
steps, we’ll stick with Server01). Start Server01 and run: sudo apt-get install isc-dhcp-server -y - to do
the install.

5.1.12 Configure the DHCP Server: go to /etc/dhcp

5.1.12.1 First back up the config file: sudo cp dhcpd.conf dhcpd.conf.bak
5.1.12.2 Next, edit the file: sudo vim /etc/dhcp/dhcpd.conf
5.1.12.3 Find the line with option domain-name and set it to option domain-name “localdomain";
(check /etc/hosts or the ‘dnsdomainname’ command to get the domain name)
5.1.12.4 Set the nameserver's hostname or IP address by finding and changing this line to:

option domain-name-servers 142.55.100.25, 142.55.44.25;

(We find these IP addresses by checking the ‘nameservers: ‘ field in

/etc/netplan/99-netcfg-vmware.yaml)

5.1.12.5 Find and change the lease times to 8 minutes (480s) – (this is just for testing – more common
times are 2 hrs, 1 day or 1 week)

default-lease-time 480;
max-lease-time 480;

5.1.12.6 Find the #authoritative; line and uncomment it by removing the #

5.1.12.7 Specify the network address and subnet-mask: Go to the end of the file and add these lines:
(use these addresses and masks)

subnet 192.168.10.0 netmask 255.255.255.0 {

# Specify the default gateway address
option routers 192.168.10.1;
 # Specify the subnet-mask
option subnet-mask 255.255.255.0;
# Specify the range of leased IP addresses
range 192.168.10.105 192.168.10.115;
}

5.1.12.8 Save and quit the editor.

5.1.13 Restart the DHCP server: sudo systemctl restart isc-dhcp-server.service

5.1.14 The Desktop VM still has a statically set IP address. We must switch it to use DHCP. Start the VM from
a browser at ‘vcenter…’ (if you use SSH Client or ‘nomachine’ client now to connect, you will lose the
connection once DHCP switches the IP address away from the 192.168.10.13 address).

5.1.15 Edit the 99-netcfg-vmware.yaml file so that you have: dhcp4: yes (you can leave the
dhcp6: no line). Delete all the following lines.

5.1.16 Get the VM to accept the change: sudo netplan apply

5.1.17 Verify its IP address is now in the range chosen: 192.168.10.105 – 115 - Put a screenshot showing
this new address:
5.1.18 Run: netplan ip leases ens160 (substitute your interface name). Put a screenshot of its output:

5.1.19 Verify you can ping Server01.

5.1.20 From Server01, ping the Desktop. Put a screenshot of the ping:
5.1.21 Also from Server01, run: dhcp-lease-list - put a screenshot of its output:

5.1.22 View the dhcpd.leases file in /var/lib/dhcp - after 20 minutes, how many leases are in this file? Put
a screenshot of one of the leases here:

We are done reviewing DHCP. Now we must statically set Desktop’s IP address back to the original and
disable the DHCP Server.

5.1.23 On Server01, run: sudo systemctl disable isc-dhcp-server.service - to disable it at bootup

5.1.24 Stop it now: sudo systemctl stop isc-dhcp-server.service

5.1.25 On Desktop, back up the YAML file for future reference:

sudo mv 99-netcfg-vmware.yaml 99-netcfg-vmware.yaml.dhcp-bak

5.1.26 You previously created the backup file 99-netcfg-vmware.yaml.bak, now rename it back to the original
name so netplan will use it: sudo mv 99-netcfg-vmware.yaml.bak 99-netcfg-vmware.yaml

5.1.27 Apply the change: sudo netplan apply

5.1.28 Verify the IP address is changed back to 192.168.10.13. This is an IMPORTANT step to ensure
continued access to Desktop.

Part 5.2 Installing and configuring NFS (complete documentation:

https://help.ubuntu.com/community/SettingUpNFSHowTo & https://ubuntu.com/server/docs/service-nfs)

This part is like the Samba tool in that it involves an NFS Server (server01) making NFS shares available to
NFS Clients (our test will use only ‘Desktop’).

STEPS
5.2.1 On your SERVER01 (the NFS server): Login with your default user (for ex: vmadmin), create the ‘nfs-
test’ and
‘nfs-test/data’ directories below your home directory and add a file myfile.txt (with text) to the data directory.

5.2.2 Install nfs-server: sudo apt-get install nfs-kernel-server

5.2.3 Edit the NFS configurations file: sudo vim /etc/exports

Add entries:
/home/USERNAME/nfs-test ClientIP(rw,fsid=0,insecure,no_subtree_check,async)
/home/USERNAME/nfs-test/data ClientIP(rw,nohide,insecure,no_subtree_check,async)

(replace USERNAME and ClientIP with your values – for ClientIP, use the IP address of your client
[DESKTOP] – note the SPACE(s) before ClientIP).
Note the ‘rw’. We are giving clients read/write access to these folders. Put a screenshot of the lines of this file:

Save and close it.

5.2.4 Start rpc.idmapd service: sudo rpc.idmapd

5.2.5 On your NFS Client machine (DESKTOP), install nfs-client: sudo apt-get install nfs-common

5.2.6 Modify /etc/default/nfs-common file (at the client) and set:

NEED_IDMAPD=yes
NEED_GSSD=no

5.2.7 Load the nfs module (at the client): sudo modprobe nfs

5.2.8 At the NFS Server, restart nfs server: sudo systemctl restart nfs-kernel-server …or
sudo /etc/init.d/nfs-kernel-server restart

5.2.9 At the client, create the directory /media/nfs-share for mounting the nfs share (you may choose any
name or location – ‘/media’ is often used), then issue the following command to mount SERVER01’s nfs share
– run this from DESKTOP: sudo mount -t nfs ServerIP:/data /media/nfs-share (replace ServerIP
with your SERVER01’s IP address – ‘data’ is the directory you entered in ‘exports’ file)

5.2.10 Run df -h and mount commands to verify DESKTOP has accessed the share. Put a screenshot of
these commands:
.

5.2.11 Go to /media/nfs-share directory at the client and verify that you can see the file that you created in
/home/USERNAME/nfs-test/data folder. Verify you can create a file in SERVER01 and it is readable in
DESKTOP, then, you can create a file in DESKTOP and it is readable in SERVER01. Put screenshots
showing:
- the files in both VMs (‘nfs-share’ and ‘data’)
- you created a file in nfs-share and it is readable in data
- you created a file in data and it is readable in nfs-share

5.2.12 When done, from DESKTOP, leave the directory and unmount this filesystem:
sudo umount /media/nfs-share

5.2.13 Stop the NFS service on the server: sudo systemctl stop nfs-kernel-server …or
sudo /etc/init.d/nfs-kernel-server stop
Insert here the history of your Linux session on both VMs for this Part 5.2 (NFS Share) ONLY (not your entire
history file!).
 cl
e
Lesson 7 Exercises

The Secure Shell (SSH) protocol is the Application Layer protocol that enables clients to remotely login to an SSH Server
to access services. An example is employees logging into a company server to do work from home.

Part 7.1: Configuring SSH

In many Linux servers, the SSH daemon will be installed and started at bootup. If you are able to login to
Server01 using ‘Putty’ or another SSH Client, that means the SSH Server is running on Server01.

7.1.1 Launch your SERVER01 (it will be the SSH Server), log in to your regular user account and verify SSH
Server daemon is running: sudo systemctl status sshd

If the first 4 lines look like this:

- notice the “active (running)”, then it is running.

If it is not, check if you have the SSH package: dpkg -l | grep ssh
ii libssh-4:amd64 0.9.3-2ubuntu2 amd64
tiny C SSH library (OpenSSL flavor)
ii openssh-client 1:8.2p1-4 amd64
secure shell (SSH) client, for secure access to remote machines
ii openssh-server 1:8.2p1-4 amd64
secure shell (SSH) server, for secure access from remote machines
ii openssh-sftp-server 1:8.2p1-4 amd64
secure shell (SSH) sftp server module, for SFTP access from remote machines
ii ssh-import-id 5.10-0ubuntu1 all
securely retrieve an SSH public key and install it locally

If you don’t see these packages, install them: sudo apt-get install openssh-server openssh-client

and start the sshd service: sudo systemctl start sshd

7.1.2 At your Desktop VM (the SSH Client), attempt to connect to the SSH Server:
ssh [email protected] (‘your-userid’ is a user account on the server, substitute Server01’s
IP address)

Note that the first time you log in, you may see a message like this:
vmadmin@Desktop:~$ ssh [email protected]
The authenticity of host '192.168.10.11 (192.168.10.11)' can't be established.
ECDSA key fingerprint is SHA256:fa87xR4a4y2uhOAN+/6QSpx0Z68uhuaODjlqdAc63kQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If so, just enter ‘yes’.

Put a screenshot of the result:

7.1.3 Try the ‘who’ and ‘hostname’ commands to get an idea of your connection details. Then enter ‘exit’ to
log-out of your ssh session (leave Server01).

7.1.4 At the server, view the contents of the SSH configuration file: /etc/ssh/sshd_config
There is a section for permitting login as root (PermitRootLogin). Why do you think it would be important to not
allow root to be permitted remote login? ANSWER: because root can do a lot more damage on the
machine than a standard user so root is prohibited.
Part 7.2: Using SSH Utilities (ssh, scp, sftp)

We will use ssh to remotely run commands and transfer files between your Desktop VM and your Atlas
account. Atlas is a Sheridan College-wide Linux server.

7.2.1 Enter the following on Desktop: ssh [email protected] ls

(Substitute your SLATE userid). Put a screenshot of the result:

7.2.2 Now issue the command:
ssh [email protected] “echo Hi ATLAS Server > message.txt”

Where do you think the file was saved? ANSWER: In bhanvada directory

How can you prove this? ANSWER:

7.2.3 Next, you will transfer files between hosts using the scp command (Secure Copy). This is an efficient
command for quickly transferring files and directories between servers. On your Desktop VM, use your regular
user account to create a folder called ~/transfer and a file called test.txt (containing your full name, Sheridan
account (Slate UserID) and student number) in your new directory.

7.2.4 Transfer the test.txt file to the Atlas server:

scp ~/transfer/test.txt [email protected]:test.txt

Did the command work? ANSWER: YES

What command can you issue to confirm that this command worked?
COMMAND: ssh [email protected] ls

7.2.5 Add two more small files to ‘transfer’ directory. Write the scp command using the option –r to copy that
transfer directory to your atlas account (make certain to include the colon (:) at the end of the atlas domain
name).

COMMAND:

Try issuing the command above. Did the command work? ANSWER: Yes

What command can you issue to confirm that this command worked?
COMMAND: ssh [email protected] ls

7.2.6 Another way we can transfer files is using the sftp command (Secure File Transfer Protocol). You
probably noticed scp requires to enter the password each time when you issue the command.This sftp
method opens a shell where the user issues commands to perform various file transfer operations without
requiring the password every time.

On your Desktop VM, put your professor’s name in sample.txt, and move the file to ~/transfer. Run the sftp
command shell: sftp [email protected]

Some common sftp commands:

Local Machine (eg. Desktop VM) Remote Server (eg. Atlas Server)

!ls (or lls) – list files on local machine ls – list files on remote server

lcd – change directory (local machine) cd – change directory (remote server)

!pwd (or lpwd) – display current location (local machine) pwd – display current location (remote server)

get filename – download from remote server to local machine

put filename – upload from local machine to remote server

Within sftp shell, go to ~/transfer, remove test.txt file from local directory, transfer your sample.txt file to
your atlas account, then copy/restore the test.txt file back to transfer directory on Desktop VM.
Put screenshots of all steps:

How can you prove it worked?

As sample.txt file is transfer to remote server it is visible in atlas remote server. And test.txt is visible
in local machine.

When you are done, enter: quit to terminate the session.

*** END OF WEEK 7 EXERCISE ***

You are done, hi-light your answers in YELLOW and submit this to SLATE.