Linux Assignment Help

Question 1

An important service provided by any system is the ability to run a process on a

predetermined schedule without human intervention. The “automation” of tasks can

reduce the workload of the system management significantly. Unfortunately Linux

currently offers not one service but potentially three—cron, anacron, and systemd timer

units.

In about a page compare and contrast all three systems. Illustrate your discussion by

using the system files /etc/anacron and /etc/crontab and by constructing equivalent

systemd service and timer files.

Solution:

Linux has three main timer units

namely Cron, Anacron and System. There is a distinct set of features that all of these time

schedulers in Linux are built with. However, it is a fact that all of these three are merely

timers and the application of their usage is quite different from each other.

Cron is a time based task scheduler program in Linux. Cron is specifically used in the

environment where the system has to be scheduled to very specific times, generally

precisely to the minutes and seconds. Tasks can run on particular dates, or repeat at

periods as little as consistently. Cron likewise permits clients in extensive national

systems to assign the time zone under which their tasks fall, to guarantee fitting execution

utilizing local times.

Anacron can be considered as ‘Cron’ for laptops and desktops, as it processes in the same

way as the Cron. However the main difference between the cron and anacron is that, cron

is used for servers which are up for almost all their lifetime. Any task scheduled at any

specific time will thereby be executed by the cron; in case of laptops and desktops which

are not up for all the time. In such a case anacron is used, which executes the scheduled

task is the system is up, and let the process pasby if the system is off for that period.

System on the contrary is a session and system manager for Linux. Basically it consist of

two types of files that is, timers and services. Timers here can be an alternative Cron and

Anacron, as they do exactly the same processes that these two timers too; secondly are

the services which corresponds to the timers. Files ending with ‘.timer’ are timers, while

those ending with ‘.service’ are to control files and events.

Reading Crontab file:

Crontab file located at ‘/etc/crontab’ consist of following lines of code:

SHELL=/BIN/SH

PATH=/USR/LOCAL/SBIN:/USR/LOCAL/BIN:/SBIN:/BIN:/USR/SBIN:/USR/BIN

# M H DOM MON DOW USER COMMAND

17 *

* * * ROOT CD / && RUN-PARTS --REPORT /ETC/CRON.HOURLY

25 6

* * * ROOT

TEST -X /USR/SBIN/ANACRON || (CD / && RUN-PARTS --REPORT /ETC/CRON.DAILY )

47 6

* * 7 ROOT

TEST -X /USR/SBIN/ANACRON || ( CD / && RUN-PARTS --REPORT /ETC/CRON.WEEKLY )

52 6

1 * * ROOT

TEST -X /USR/SBIN/ANACRON || ( CD / && RUN-PARTS --REPORT /ETC/CRON.MONTHLY )

From the code snippet above, “17 * ***” is the timing syntax. On a deep insight the

whole structure can be classified in minutes, seconds, hours, days, weeks and months by

following conventions:

 

M = Minute (0-59)

H = Hours (0-23)

DOM = Days of Month (1-31)

MON = Month (1-12)

DOW = Days of week (1-7)

Considering first line of code as an example to understand the syntax, “17 * ***”. This

code implies to a hourly cron job, but will start at 17th minute of every hour, that is

00:17, 01:17, 02:17…

Second sequence is “25 6 ***”; here it is a daily cron job that will start at 6:25 daily.

Third sequence is “47 6 **7”, this code reflect that the code is on a weekly schedule and

will run on last day of the week on 6:47.

Fourth sequence “52 6 1**”. Here the job is scheduled monthly. The event will be

trigerred on 1 day of every month at time 6:52.

There are two other parameters left in the command, that is USER and COMMAND.

User will be the current user who is authenticated, while command will contain all the

command that would run on the command line.

Implementing on terminal:

himanshu@ubuntu:~$ env editor=nano crontab-e crontab: installing new crontab

himanshu@ubuntu:~$ crontab -l

#Edit this file to introduce tasks to be run by cron.

#Each task to run has to be defined through a single line

#indicating with different fields when the task will be run

#and what command to run for the task

#

#To define the time you can provide concrete values for

#minute (m), hour (h), day of month (dom), month (mon),

#and day of week (dow) or use '*' in these fields (for 'any').#

#Notice that tasks will be started based on the cron's   information system

#daemon's notion of time and timezones.

#

#Output of the crontab jobs (including errors) is sent through

#email to the user the crontab file belongs to (unless redirected).

#For example, you can run a backup of all your user accounts

#at 5 a.m every week with:

#0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

#

#For more information see the manual pages of crontab(5) and cron(8)

#m h dom mon dow command

17 * * * * himanshu CD/&&RUN-PARTS--REPORT/ETC/CRON.HOURLY

 

Reading Anacrontab File:

#/etc/anacrontab: configuration file for anacron

#See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

#These replace cron's entries

1 5 cron.daily   nice run-parts --report /etc/cron.daily

7 10 cron.weekly nice run-parts --report /etc/cron.weekly

@monthly 15 cron.monthly nice run -parts --report /etc/cron.monthly

It can be clearly seen from the crontab file contents that it contains fewer timing fields as

compared to the crontab file contents.

The first column corresponds the frequency of the execution of the tasks in days. Second

column is a delay time for the command execution, this is generally done so as to make

sure that the processes do not run explicitly at the same time.

Third field denotes the name, that the task has been called for; this is done to know

specific task. Fourth colum consist of the code, which will be executed in the command

line.

Considering “1 5 cron.daily nice run-parts --report /etc/cron.daily”. Here the task

will run on a daily basis with a time delay of 5 minutes, prior to the launch of anacron.

Considering “7 10 cron.weekly nice run-parts --report /etc/cron.weekly”. Here the

task will run on a weekly basis with 10 minutes delay time.

 

Systemd Service and Timing, Respective to Above Illustrations:

According to the systemd functioning, two files will be required i.e. timing file and

service file.

Read more about Website Development

1. Service File:

Considering the daily task of cron job located at /etc/cron/daily_cron. Creating a service

file naming daily_cron.service, saved at either at “/etc/systemd/system/” or

“/usr/lib/systemd/system”. File has following contents:

[Unit] Description=daily_cron [Service]

Type=simple

ExecStart=/etc/cron/daily_cron

Here type can be altered to oneshot if the task is to be executed only once.

2. Timer file:

Creating a timer file with name “daily_cron.timer” and saving the same directory where

“daily_cron.service” was stored. The file contained following codes:

[Unit]

Description=Runs daily_cron every day [Timer]

#Time to wait after booting before we run first time OnBootSec=10min

#Time between running each consecutive time OnUnitActiveSec=1d

Unit=daily_cron.service [Install]

WantedBy=multi-user.target

Similalrly, the hourly, weekly, monthly and even yearly task can be configured using the

above commands to run at a specific time.

Implementing Commands:

systemctl enable daily_cron.timer #starting the commands systemctl start

daily_cron.timer #checking if timer is enabled

systemctl is-enableddaily_cron.timer #checking if timer is running systemctl is-

activedaily_cron.timer #running script at any time

systemctl start daily_cron

Get help for Business Assignment

 

Question 2

The web administrator of your organisation needs to login remotely to the machine that is

running the organisation’s public web site. You tell her that the only way to login is via

The Secure Shell—which she knows nothing about! Assuming she is logging in via a

Linux boxwrite a help document for her containing the following—

a. (6 marks) A short introduction to SSH, explaining why it is the preferred way of

logging into a remote machine—this explanation will need to discuss symmetric and

asymmetric key encryption.

Answer:

(a)Secure Shell is a project to log into another PC over a network, to execute commands

in a remote machine, and to transfer files from one computer to another. It gives solid

verification and secure interchanges over insecure channels. SSH permits a client to run

commands on a machine's command prompt without them being in person present close

to the machine. Common applications of SSH incorporate remote command line login

and remote order execution, yet any network administration can be secured with SSH.

Now as this process is all about logging into remote device, remaining secure while

sending and reciving data through network is of utmost importance. So the data sent

needs to be encrypted. These encryptions are carried out by namely two encryption

techniques:

(i)Symmetric Key Encryption: This is the best known encryption technique which uses

simple concept of applying manipulations to data to be encrypted in a particular manner

so that the whole original data is modified. This can be shifted of letters and numbers in

the data or exchange of letters or a complex string multiplication. But the problem lies in

disclosure of this key used. As if someone undesired gets this key then he/she can decrypt

the data and hence anybody can easily sniff through the data.

(ii)Asymmetric Key encryption: The problem faced by symmetric key encryption can

be removed by using asymmetric key encryption. Asymmetric key encryption provides

two different keys in place of one common key. First key is the Public key which is made

public and second key is the private key, which is kept private. Data encrypted using

Public Key can only be decrypted by the use of Private Key. So know there is no need of

worries for key to be made public as they are already public.

SSH is preferred way of logging into remote machine as it uses the asymmetric key

encryption technique which protects data from sniffing attacks and is much more secure

than other programs like telnet which uses symmetric key encryption or no encryptions.

(b) The ~./ssh/known_hosts file contains keys for the known hosts or the hosts which

already connected in the past. Whenever a connection is made the key stored is matched

with the key from remote server and if they matches connection is made else error

message is shown. Further new keys can be added for new remote connection manually

or automatically by the SSH.

Contents of ~./ssh/known_hosts file:

,...,192.0.2.53 1024 37 159 ...93

,192.0.2.10 ssh-rsa AAAA1234..... =

|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa

AAAA1234.....

Population of ~./ssh/known_hosts: For adding keys or new hosts to known_hosts file

various methods can be used. For example:

 

The command: “ ssh -o StrictHostKeyChecking=no username@hostname.com” adds new

host without stricktly checking.

Or else the following command easily adds hosts with ip addresses:

ssh-keygen -R [hostname]ssh-keygen -R [ip_address]

ssh-keygen -R [hostname],[ip_address]

ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hostsssh-keyscan -H

[ip_address] >> ~/.ssh/known_hosts ssh-keyscan-H [hostname] >> ~/.ssh/known_hosts

Usage of keys by SSH: as already stated whenever a SSH connection is attempted, the

key sent from remote server is matched against all of the keys present in this

known_hosts file and if there is a match then the host is the matching host entry which

the key belongs to.

Get Help for Business plan Assignment

Man in the Middle attack: The name Man in the middle speaks for itself. I this attack a person sits in between the information exchange of two users or machines. So whenever an unencrypted data is sent he/she can easily access the personal data between the two. For encrypted data requiring public keys, the person can easily get public keys of both users when they exchange the public keys and can manipulate the sent data.

The hostnames in the file are hashed due to security reasons, as if someone somehow

comes to know the user account details or have access to the machine, then he can open

this known_hosts file and will easily find out which all hosts are connected to that

particular machine if the hostnames are not hashed.

Removing any old host name from the file known_hosts is very easy task and can be

done with a simple command line ssh-keygen command:

ssh-keygen -R hostname

We have to just specify the hostname and it would be removed from the known_hosts

file.

(c) Configuring access so that no password is needed:

For this process first asymmetric keys are needed to be setup which will be done by

following command:

ssh-keygen -t rsa

This commands creates a pair of private and public key for the usage. As the name syntax

suggests it’s a kind of key generator.

After this there will be series of steps:

Enter file in which to save the key (/home/user/.ssh/id_rsa):

The text in command output is self-explanatory. We need to specify the file in which we

need to save the generated key.

The next step is making your key passphrase protected.

Enter passphrase (empty for no passphrase):

Passphrasing enables enhanced security to the key. If someone hacked into your key

he/she will still be unable to use it as it is passphrase protected. I.e. it will ask for

passphrase each time and unable to do so will result in no access.

 

Output for key Generation process: ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/user/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/user/.ssh/id_rsa.

Your public key has been saved in /home/user/.ssh/id_rsa.pub.

The key fingerprint is:

4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 user@a

The key's randomart image is:

+--[ RSA 2048]----+

| .oo. |

| . o.E |

| + . o |

| . = = . |

| = S = . |

     

| o + = + |

| . o + o . |

| . o |

| |

 

+ ----------------- +

 

Next step is to copy this generated public key to ~./ssh/authorized_keys

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >>

~/.ssh/authorized_keys"

The authorized key file contains the list of public keys which are used each time process

is carried out.

Read more about Maths Assignment

Example of authorized_keys file:

ssh-rsa AAAAB3Nza...Link== user@example.com from="*.user2.example.com,!

pc.user2.example.com" ssh-rsaAAAAB2...19Q== user3@example.com

command="dump /home",no-pty,no-port-forwarding ssh-dssAAAAC3...51R==

example.com permitopen="192.0.2.1:80",permitopen="192.0.2.2:25"ssh-dss

AAAAB5...21S==

tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== user4@example.com

ssh-agent: Holds the private key from the generated private and public key pair. For

every session login private key from this ssh-agent is used to decrypt the data encrypted

by the public key.

ssh-add: Adds RSA identities to the authentications agent. If passphrase is required it will

ask for the passphrase and will add files accordingly.

 

Question 3

A user comes to you requesting that you create and implement a backup policy for his

desktop machine. What he wants, is to be able to place a blank DVD in his Single-

SidedDVD-burner at the end of the working day on a Friday and have all the files he has

been working on for the week backed up automatically that evening to the DVD!

Solution:

Comprehensively, we can recognize two sorts of backup; the system backup, which is a

backup of the working system and applications (the things just the sysadmin can change),

and the user backup, which is a backup of the users' documents (I don't know whether

any other individual uses these terms, yet they'll accomplish for the reasons of this

article). As we should see, system backups and user backups ought to be dealt with in an

unexpected way.

System Backups:

The purpose behind making system backups is to minimize the exertion presupposed,

after an accident, to get the system up and running as it was before fiasco struck.

Notwithstanding, you would prefer not to spend a large portion of your life moving down

your circle; nobody said it was enjoyable! The way to going down adequately is to go

down just that which is completely important to empower rapid recuperation when

calamity strikes.

User Backups:

User backups are unique in relation to system backups, in that a user's records are at risk

to change much of the time. It will probably be incomprehensible for you to have up-to-

the-moment backups of a given user's document space, and you shouldn't even attempt.

In moving up user records, you are putting forth your users a virtual wellbeing net—

sensiblylate duplicates of their documents they can fall back on the off chance that they

do something senseless (like rm * bak rather than rm *.bak—it does happen!), or if the

hard circle falls.

Implementation:

The implementation involves following steps:

Firstly, the files and the directories which needs to be backuped are identified and the

whole tree is taken for backup.

Now, the directory or the files to be backedup are archived in TAR format and stored

locally before writing onto the optical disk.

As per the given condition the backup needs to be active enough and needs to trace out

the alterations made by the user, prior to the backup. For this specific scripts/commands

needs to be inherited.

Final step concludes of using ‘systemd’ timer for automatically backing up the archives

to the optical drives.

Suppose a lot of software have been installed in the directory ‘usr/local’, now the backup

of the whole tree needs to be done. Command for this would be:

$ tar –cWMF /dev/fd0 /usr/local

 

Here c means create an archive, W to verify the archive, M for managing the disks and F

for specifiying the directory for backup. In this case it is a DVD drive. Thus after creating

the backup the archives will be needed to be burned onto the optical disk.

An alternative approach can also be followed as:

$ find /home -cnewer /etc/last_backup \

-type f i-print > back_these_up

$ tar -cf /dev/ftape -T back_these_up

$ touch /etc/last_backup

The above command will automatically backup files everytime any file is altered. Here

the location of the backup can be changed, although it is for now a temporary location as

the files needs to be written on to optical disk.

Now as per the given condition, all the backups needs to be made on a weekly basis on

every Friday. Here we can make use system times and service files configuration.

Service File:

Creating a service file naming weeklyBackup.service, saved at either at

“/etc/systemd/system/” or “/usr/lib/systemd/system”. File has following contents:

[Unit]

Description=weeklyBackup

[Service]

Type=simple

ExecStart= /usr/bin/sh -c 'for i in $(grep btrfs /proc/mounts | cut -f2 -d" "); do echo

scrubbing $i; btrfs scrub start -Bd $i; done'

IOSchedulingClass=idle

CPUSchedulingPolicy=idle

Timer File:

Creating a timer file with name “weeklyBackup.timer” and saving the same directory

where “weeklyBackup.service” was stored. The file contained following codes

[Unit]

Description=Runs weeklyBackup every week on friday [Timer]

#Time to wait after booting before we run first time OnBootSec=10min

#for running the backup at every Friday on 00:01 OnCalendar=Fri, 00:01

Unit=daily_cron.service [Install]

WantedBy=multi-user.target

Enabling and Starting the service:

 

systemctl enable weeklyBackup.timer #starting the commands

systemctl start weeklyBackup.timer #checking if timer is enabled

systemctl is-enabledweeklyBackup.timer #checking if timer is running

systemctl is-activeweeklyBackup.timer #running script at any time

systemctl start weeklyBackup

References:

Http://www.digitaliocean.com/community/tutorials/how-to-set-up-ssh-keys--2

Http://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-

and- connection-process

https://wiki.archlinux.org/index.php/System_maintenance https://www.digitalocean.com/

community/tutorials/how-to-set-up-ssh-keys--2 http://jason.the-graham.com/2013/03/06/

how-to-use-systemd-timers/ http://linuxconfig.org/linux-cron-guide http://

code.tutsplus.com/tutorials/scheduling-tasks-with-cron-jobs--net-8800 http://

www.thesitewizard.com/general/set-cron-job.shtml http://www.logikdev.com/

2010/05/25/using-the-date-command-in-your-crontab/ http://www.computerhope.com/

unix/udate.htm https://wiki.ubuntu.com/systemd