Updated: 2014-04-18 00:45 EDT
chkconfig
Do not print this assignment on paper!
- On paper, you will miss updates, corrections, and hints added to the online version.
- On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.
- On paper, scrolling text boxes will be cut off and not print properly.
23h59 (11:59pm) Thursday April 17, 2014 (end of Week 14)
sudo
and sysadmin account)Do not print this assignment on paper! On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.
rsyslog
logging mechanismRemember to READ ALL THE WORDS to work effectively and not waste time.
This is an overview of how you are expected to complete this assignment. Read all the words before you start working.
Do not print this assignment on paper. On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.
You will create filesystem structure in your CLS home directory containing various directories and files. You will also make changes in your own Linux Virtual Machine running CentOS 6.5. You can use the Checking Program to check your work as you do the tasks. You can check your work with the checking program as often as you like before you submit your final mark. Some task sections below require you to finish the whole section before running the checking program; you may not always be able to run the checking program successfully after every single task step.
When you are finished the tasks, leave the files and directories in place on both the CLS and your own Linux Virtual Machine as part of your deliverables. Do not delete any assignment work until after the term is over! Assignments may be re-marked at any time on the CLS; you must have your term work available on the CLS right until term end.
Since we also do manual marking of student assignments, your final mark may not be the same as the mark submitted using the current version of the Checking Program. We do not guarantee that any version of the Checking Program will find all the errors in your work. Complete your assignments according to the specifications, not according to the incomplete set of mistakes detected by the Checking Program.
The previous term’s course notes are always available on the Internet here: CST8207 GNU/Linux Operating Systems I.
All the current and previous terms notes files are also stored on the CLS. You can learn about how to read and search these files using the command line on the CLS under the heading Copies of the CST8207 course notes near the bottom of the page Course Linux Server. The current CST8177 term notes are searchable there, too!
All references to the “Source Directory” below are to the CLS directory ~idallen/cst8177/14w/assignment12/
and that name starts with a tilde character followed by a userid with no intervening slash. The leading tilde indicates to the shell that the pathname starts with the HOME directory of the account idallen
(seven letters).
You do not have permission to list the names of all the files in the Source Directory, but you can access any files whose names you already know.
Review your work from CST8207 GNU/Linux Operating Systems I:
I recommend that once you have booted your CentOS VM, you connect to it and work using a remote login session (e.g. ssh
or PuTTY
) where copy-and-paste works and where you can have multiple simultaneous connections into the VM. The VMware console is not friendly.
If you can’t get an SSH (PuTTY or ssh
) connection working into your Linux VM, see the Network Diagnostics page.
Note that SSH sessions (and whatever you are doing inside them) do not survive across a VMware suspend. Make sure you save your editor files and exit your SSH session before you pause or suspend your virtual machine. (Editor sessions that run inside the VMware console do survive across suspend and resume, since they don’t depend on a network connection.)
Advanced users may look into the various virtual terminal programs such as
tmux
andscreen
that do allow you to suspend and resume your sessions even from a remote login.
Do a Remote Login to the Course Linux Server (CLS) from any existing computer, using the host name appropriate for whether you are on-campus or off-campus.
Create the CLS directory ~/CST8177-14W/Assignments/assignment12
Create the check
symbolic link needed to run the Checking Program, as described in the section Part II - Check and Submit below.
Run Part II - Check and Submit to verify your work so far.
sudoers
group.~/CST8177-14W/Assignments/assignment12
(the same hierarchy as you have already made on the CLS).This CentOS assignment12
directory in your sysadmin account is the base directory for all pathnames in this assignment. Store your CentOS files and answers below in this sysadmin base assignment12
directory.
Run the Fetch and Checking Program to verify your work so far.
You must have
/home
mounted on its own file system with user and group quotas enabled to do this section. You did that in Assignment #10.Refer to Red Hat Quotas
Install the quota
package.
Take your CentOS VM into single user mode. (See CST8207 Booting and GRUB.)
Make sure your /home
file system is mounted with quotas enabled. (You added quota options in Assignment #10.)
Use the quotacheck
command with options appropriate to initialize the group quota file and user quota file for the /home
filesystem.
/home
filesystem.
quota
command as User 100
and ensure you see no quotas.quota: Can't open quotafile /home/aquota.user: Permission denied
then you forgot to turn quotas on.User 100
, set the following (unrealistic) test quota values:
500
)700
)5
6
/home
file system quota report for all users and verify that User 100
has the correct limits.repquota.txt
in your sysadmin base directory.Change the ownership and group of this quota report file to yourself and your group. (Always change files stored in your own account to your own sysadmin userid.)
sudo
and su
with the correct option to do a full login as User 100
.
sudo
gain root privileges and you need su
with the right option and userid to do the full login.user100
in the user100
home directory:
Exceed the soft block limit by creating a 600KB file with this command:
$ whoami
user100
$ pwd
/home/user100
$ dd if=/dev/zero of=bigfile1 bs=1K count=600
Creating this file will generate a quota exceeded message on the system console, because you are now over the soft limit on the number of files you can create. (If you are logged in via a terminal program, not on the VMware console, you may not see the quota exceeded warning message.)
Note that even though you got a quota exceeded
warning message on the console, all 600KB were actually copied into the output file. You only exceeded the soft quota, not the hard quota.
files
). You should see that the number of blocks used exceeds the soft quota but not the hard quota.Run the same quota information command again and redirect the output to a file named user100_quota.txt
in the user100
home directory. This is just the user100
quota information, so it should be only three lines:
$ whoami
user100
$ pwd
/home/user100
$ wc user100_quota.txt
3 24 201 user100_quota.txt
You did read the words above about running all the commands in this section as user100
, right?
user100_quota.txt
files
) increased in the file. Why did the number increase before the quota command ran?Run ls
to display a long listing of all the pathnames in the user100
home directory, including hidden names. The number of pathnames listed as being owned by user100
should be exactly the same as the number of files given in the user100_quota.txt
file you created.
Type exit
to revert from user100
back to your sysadmin account.
As your sysadmin user, use sudo
to generate another overall /home
file system quota report for all users, redirecting the output into the file repquota_grace.txt
in your sysadmin base directory. The file will be owned by you, not by root
.
View repquota_grace.txt
and verify that it is owned by you and is consistent with the numbers in the user100_quota.txt
file.
User 100
again and do the following in the home directory:
Try to create another file, as follows. The command will give a “quota exceeded” message when the hard quota limit is reached:
$ whoami
user100
$ pwd
/home/user100
$ dd if=/dev/zero of=bigfile2 bs=1K count=200
You will see a quota error message from the dd
command part-way through the file creation. Note that this time the output file does not contain the expected 200KB of data. The file is truncated because the hard quota limit was reached. You are not allowed to use any more disk blocks.
5
if there is a .bash_history
file (there should be), and 4
if not.smallfile
and note:
5
).5
files (the soft limit) in it.6
). Programs trying to create new files or directories will fail and return error messages.Type exit
to revert back to your sysadmin self.
repquota_hard.txt
in your sysadmin base directory.
sudo
) so that the owner of the redirection output file is your sysadmin user, so that the updated quota information includes this new file.diff
to put the difference between repquota_{grace,hard}.txt
into repquota_diff.txt
and view the file to verify that the changes in usage look right (eight lines of output):
root
user. No changes.root
user, or no changes for your own userid, you did not create the repquota_hard.txt
file correctly using sudo
from your own sysadmin account. Delete the file and review all the words on the previous step.Copy the user100
file named user100_quota.txt
into your own sysadmin base directory. (Needs privilege; you know what to do.)
Change the ownership and group of all files in your base directory to your own sysadmin account.
Run the Fetch and Checking Program to verify your work so far.
Do the following tasks on the console (in the VMware window) of your VM.
inittab
file to configure your system so that it boots by default into runlevel 2. (This changes one character in the file.) The changed inittab
should have these wc
and sum
numbers:
26 149 884
and 57793 1
26 149 884
and 57789 1
Reboot your system, and after it comes back up, log in and display the runlevel to verify that it is in runlevel 2.
Take a listing of all the processes running on your system using ps -e
and redirect the output to pse_rc_2.txt
in your sysadmin base directory (approximately 77 lines).
Take your system into single user mode (runlevel 1) using the shutdown
command.
As root, take a listing of all the processes running on your system using ps -e
and redirect the output to pse_rc_1.txt
in your sysadmin base directory (approximately 63 lines).
Return back to the default runlevel by exiting the single user mode shell.
Log in as your sysadmin user and put the text difference between the two files pse_rc_{1,2}.txt
into pse_rc_diff.txt
.
Take note of some of the differences, especially lines that include sshd
, ntpd
, and rsyslogd
. Find the symbolic links for these service names in the runlevel 1 and 2 init directories, namely /etc/rc1.d
and /etc/rc2.d
. Is the first character of those link names consistent with what you see in the process lists for those two runlevels?
Your system will continue to boot into runlevel 2 for the rest of this lab. Do not change the runlevel back to its previous value.
Fix the ownership of any root
-owned files in your sysadmin base directory.
Run the Fetch and Checking Program to verify your work so far.
chkconfig
We’ll consider the
ntpd
service and runlevel 3. We’ll look at the contents of therc3.d
directory whilentpd
is seton
for runlevel 3. Then we’ll turnntpd
off
for runlevel 3, and look at the contents of therc3.d
directory again to see how it changed.
View the top of the script /etc/init.d/ntpd
and note the comment lines used for chkconfig
control. Put the line that indicates the chkconfig
default runlevels and start and stop priority numbers into ntpd_chkconfig.txt
in your sysadmin base directory:
$ wc ntpd_chkconfig.txt
1 5 21 ntpd_chkconfig.txt
$ sum ntpd_chkconfig.txt
09004 1
Run the command to display the runlevels for which the ntpd
service is on or off. Redirect the output of this command into ntpd_before.txt
in your sysadmin base directory:
$ wc ntpd_before.txt
1 8 54 ntpd_before.txt
$ sum ntpd_before.txt
42633 1
Take a long ls
listing of /etc/rc.d/rc3.d/
and put this listing into rc3d_before.txt
in your sysadmin base directory (about 25 lines, 266 words).
Think about how you can search for ntpd
but NOT ntpdate
. In this and the following tasks, your grep
for ntpd
should result in the line containing ntpd
, but not the line containing ntpdate
.
Run a grep
command for ntpd
in the rc3d_before.txt
file, and put the output (one line) into rc3d_ntpd_before.txt
in your sysadmin base directory. (Should be one line – the pattern you use must not match the line with ntpdate
.)
$ wc -lw rc3d_ntpd_before.txt
1 11 rc3d_ntpd_before.txt
Verify the priority number contained in the name of the symbolic link for ntpd
in rc3d_ntpd_before.txt
against the start priority number in the line in ntpd_chkconfig.txt
(and confirm that they match).
Use chkconfig
to turn ntpd
off in runlevel 3.
Run the command to display the runlevels for which the ntpd
service is on or off, and check to be sure it’s off in runlevel 3, but the other runlevels are unchanged. Redirect the output of this command into ntpd_after.txt
in your sysadmin base directory:
$ wc ntpd_after.txt
1 8 55 ntpd_after.txt
$ sum ntpd_after.txt
65203 1
Now that you’ve used chkconfig
to turn ntpd
off in runlevel 3, take another long listing of /etc/rc.d/rc3.d
and put the output into rc3d_after.txt
in your sysadmin base directory (about 25 lines, 266 words).
Run a grep
command for ntpd
in the rc3d_after.txt
file, and put the output (one line) into rc3d_ntpd_after.txt
in your sysadmin base directory. (Should be one line – your grep
should not match the line with ntpdate
).
$ wc -lw rc3d_ntpd_after.txt
1 11 rc3d_ntpd_after.txt
Verify the priority number contained in the name of the symbolic link for ntpd
in rc3d_ntpd_after.txt
against the stop priority number in the line in ntpd_chkconfig.txt
(and confirm that they match).
Run the diff
command on rc3d_{before,after}.txt
to see what the chkconfig
command did. You should see that the symbolic link to the ntpd
service has changed from a start symlink at priority 58
to a kill (stop) symlink at priority 74
.
Changing these symlinks is how chkconfig
turns on and off services. You may need to make these same symlink changes manually if chkconfig
is not available on your system.
Turn the ntpd
service on again in runlevel 3 (back to normal).
Run the Fetch and Checking Program to verify your work so far.
We’ll look at the logging of
ssh
activity. Then, we’ll change the file thatssh
logging goes to, and change it back.
View the configuration file for rsyslog
, find the RULES
section, and find the line dealing with the authpriv
facility (the line that starts with the word authpriv
). Put this line into rsyslog_authpriv.txt
in your sysadmin base directory:
$ wc rsyslog_authpriv.txt
1 2 72 rsyslog_authpriv.txt
$ sum rsyslog_authpriv.txt
42327 1
View the configuration file for the SSH service daemon sshd
named /etc/ssh/sshd_config
(note the d
in sshd
) and find the Logging
section. Copy the one active Logging
configuration line (it starts with the word SyslogFacility
) into the file sshd_logging.txt
in your sysadmin base directory:
$ wc sshd_logging.txt
1 2 24 sshd_logging.txt
$ sum sshd_logging.txt
50989 1
Remember the name of this sshd
configuration file and the location of this rsyslog
line. You will need to edit it, below.
Notice the correspondence between the contents of rsyslog_authpriv.txt
and sshd_logging.txt
and determine the file that sshd
log entries are added to. They both use the same logging keyword (though one is using it upper-case, which doesn’t matter).
Start a separate window (console, or PuTTY
, or ssh
) and use the tail -f
command with sudo
to watch the file that sshd
log entries go to. (The -f
option keeps watch on the end of the file, waiting for new lines to appear.)
ssh
or PuTTY
, and observe the output of your tail -f
command in the other window.
sshd
log entries for your login activity.Still in the same ssh
/ PuTTY
window from the last step, use the sudo
command to run head
on the /etc/shadow
file. The use of sudo
will cause log entries for sudo
in the same file on which you’re running the tail -f
command. (Now you know to which log facility, and therefore in which log file, sudo
invocations get logged!)
tail -f
with ^C
and then put the last 20 lines of that log file into ssh_sudo_log.txt
in your sysadmin base directory.
sshd
and sudo
log entries you saw in the previous steps.tail -f
of the log file to ssh_sudo_log.txt
, and repeat the ssh
and sudo
steps to be sure the logging output goes into ssh_sudo_log.txt
ssh_sudo_log.txt
file must show logging lines from both ssh
and from sudo
.sshd
configuration file viewed earlier.
AUTHPRIV
to the AUTH
logging facility by uncommenting one line and commenting out another. (Both lines exist in the file already.)wc
on the file will be the same (138 467 3879
) and the sum
will change from 51338 4
to 57871 4
.57871
) in file sshd_new.txt
in your sysadmin base directory.sshd
service using the appropriate command.
Stopping sshd: [OK]
followed by Starting sshd: [OK]
.View the rsyslog
config file and put the line of the rule that controls the auth
facility into rsyslog_auth.txt
in your sysadmin base directory:
$ wc rsyslog_auth.txt
1 2 74 rsyslog_auth.txt
$ sum rsyslog_auth.txt
06250 1
Hint: There is no line that explicitly matches the auth
facility. Look for a “catch-all” or “log anything” rule instead.
Similarly to how you monitored sshd
activity before, run tail -f
on the log file corresponding to the auth
facility (a different log file now), which is now used for sshd
logging.
Similarly to before, generate some sshd
activity to appear in the log by using ssh
or PuTTY
, and confirm that you see a log entry in the correct log file that you’re monitoring due to the previous step.
Change /etc/ssh/sshd_config
back to use the previous log facility, and restart the sshd
service.
Run the Fetch and Checking Program to verify your work so far.
At Managing Quotas, Red Hat recommends a daily cron job to
touch /forcequotacheck
so thatquotacheck
will be run during the next reboot. We will follow Red Hat’s advice because it exercises many of the concepts we’ve been studying: booting and init scripts, quotas, shell scripting, regularly run sysadmin jobs, and logging.
/forcequotacheck
.
upstartd
system. Find the invocation of this system initialization script in the upstartd
configuration files by doing a grep
for sysinit
in /etc/init/rcS.conf
, which should print one line showing the absolute pathname of the system initialization script.Now, grep
for forcequotacheck
in that script pathname. You should see two lines mentioning the forcequotacheck
file. Run the command again, redirecting the output to force_grep.txt
in your sysadmin base directory:
$ wc force_grep.txt
2 20 147 force_grep.txt
grep
for quotacheck
in that same script:
grep
quotacheck
.Redirect the output of this case-insensitive grep
to file quotacheck_grep.txt
in your sysadmin base directory:
$ wc quotacheck_grep.txt
7 41 334 force_grep.txt
The
logger
command writes into the system logs via thersyslog
service. You can use an option to set the priority to use any syslog facility and any level, so you can write a log message into any log file on the system that is written byrsyslog
.
logger
command with no options and a simple message: I made this default log entry
logger
(RTFM)?tail
output (showing your message) as file messages_tail.txt
in your sysadmin base directory.logger
command again, but use options to set the tag to testing
and the priority to authpriv.info
and the message to An authpriv message
sshd
tail
output (showing your message) as file secure_tail.txt
in your sysadmin base directory.forcequotacheck.sh
(in your sysadmin base directory) that takes no arguments and creates an empty /forcequotacheck
file (note the full pathname), as follows:
logger
command as follows:
user.info
as the facility.level
pair for all logging messages in this script.Attempting to force quota check upon next reboot
Create the empty /forcequotacheck
file using an if
statement with the following structure:
IF the creation of empty file /forcequotacheck is successful
log a message "Successfully forced quota check upon next reboot"
exit the script with a success return value
ELSE
log a message "Failed to force quota check upon next reboot"
exit the script with a failure return value
sudo
sudo
so that it succeeds.
testing.txt
enough lines from the system log file to show the Attempting
messages followed by both the success and failure messages (at least four log lines).cron
to run your script daily by copying your script file into the /etc/cron.daily
directory.Run the Fetch and Checking Program to verify your work so far.
logrotate
configuration file to keep 5 weeks worth of backlogs by default.
/etc
directory, as you would expect.wc
and sum
should be 35 110 662
and 56994 1
.logrotate
configuration file for the yum
package to rotate the yum
logs monthy rather than yearly.
logrotate
-related directory under /etc
and inside that directory look for a yum
-specific file.wc
and sum
should be 7 12 101
and 38265 1
.Run the Fetch and Checking Program to verify your work so far.
Note: Some documentation says that the
logwatch.conf
file is located in/etc/logwatch.conf
but this is not correct. Search for the file name under/etc
and use its actual location.
Install the logwatch
package.
Change the user that receives logwatch
emails from root
to your own sysadmin userid.
Change the detail of logwatch
summaries from Low
to Med
(medium).
Use sudo -i
to simulate a root
login, and run the script /etc/cron.daily/0logwatch
(cron
does this daily, but you can do it too whenever you want).
logwatch
emails, you should have an email from logwatch
mail
command to view your email interactively.mail
program &
prompt character, type h
for a list of mail
commands.1
) to send that message into the more
pagination program (similar to less
).more
prompt character, type h
for a list of pagination commands.more
pagination commands (spacebar to advance a screen, /something
to search for something
, etc) to read the message.sshd
to see mentions of sshd
activity.q
to quit more
viewing a message and return to the &
mail program prompt.logwatch
mail message to file email.txt
in your sysadmin base directory.email.txt
file contains the logwatch
mail message text.
Detail Level of Output
number that results from the Med
option in the config file.Run the Fetch and Checking Program to verify your work so far.
Install the psacct
package, for monitoring process activities.
Use chkconfig
to find out for which runlevels the psacct
service is on. Put the output from the command you used into psacct_levels.txt
in your sysadmin base directory:
$ wc psacct_levels.txt
1 8 58 psacct_levels.txt
$ sum psacct_levels.txt
60721 1
Turn on psacct
for runlevels 2
,3
,4
,and 5
Check the status of the psacct
service, and start it if it’s not enabled.
last
command to view a listing of last logged in users
user100
by using ssh
to login a few times: ssh user100@localhost
date
or who
and then exit
to log out again. Repeat once or twice.Use only the last
command to select and view the last logins of only User 100
, then run the command again, redirecting the output into last_user100.txt
in your sysadmin base directory:
$ tail -2 last_user100.txt | wc
2 7 38
Do not use grep
or any pipeline for this. One command. RTFM.
Use the lastlog
to display a report of the most recent logins of all users
Use only the lastlog
command to select and view a two-line report of the logins for User 100
and then run the command again, redirecting the two lines into lastlog_user100.txt
in your sysadmin base directory:
$ head -1 lastlog_user100.txt | wc
1 4 50
Do not use grep
or any pipeline for this. One command. RTFM.
Run the ac
command with the option to also print the individual totals (time totals) of the hours your users have been logged in. Run the command again, redirecting the output to ac_individuals.txt
in your sysadmin base directory.
Run the lastcomm
command to see all of the commands that have been run on your system since you enabled psacct
and run the command again, redirecting the output to lastcomm.txt
in your sysadmin base directory.
Run the Fetch and Checking Program to verify your work so far.
That is all the tasks you need to do.
Check your work a final time using the Fetch and Checking Program and save the output as described below. Submit your mark following the directions below.
Optional: Keeping your main CentOS Virtual Machine snapshot, remove any intermediate snapshots you no longer require, to free up disk space. - Be careful not to remove your current work!
Summary: Do some tasks, then run the Fetch and checking program to verify your work as you go. You can run the Fetch and checking program as often as you want. When you have the best mark, upload the marks file to Blackboard.
Since I also do manual marking of student assignments, your final mark may not be the same as the mark submitted using the current version of the Checking Program. I do not guarantee that any version of the Checking Program will find all the errors in your work. Complete your assignments according to the specifications, not according to the incomplete set of the mistakes detected by the Checking Program.
The checking program resides on the Course Linux Server, but your work is on your CentOS Virtual Machine. There is a Fetch program that you must download and use on your CentOS Virtual Machine to copy information from your CentOS Virtual Machine to your account on the CLS so that the checking program can check it on the CLS.
Once the Fetch program has fetched these files from your Virtual Machine to the CLS, you can run the checking program on the CLS to check what is saved in the files. When you make changes on your CentOS Virtual Machine, you need to run the Fetch program again on CentOS to update the saved files on the CLS.
Simply running the checking program on the CLS will not update the saved files on the CLS. You must run the Fetch program on your CentOS VM when you make changes on your CentOS Virtual Machine.
Do all the following steps on your CentOS Virtual Machine. Read through the whole list before you start typing anything. An example of what to type is given below the descriptions that follow.
Failure to read all the words will lock your account out of the CLS.
root
account (same userid as Blackboard).CST8177-14W/Assignments/assignment12
(use the same directory hierarchy as you already have in your own account on the CLS). This is your base directory for this assignment.curl
to get a copy of the Fetch program from the given URL into a file named do.sh
. Make sure you have a file named do.sh
in your sysadmin base directory. You only need to download this once per assignment.curl
program.$ whoami ; hostname ; pwd
abcd0001 # your userid, not abcd0001
abcd0001 # your userid, not abcd0001
/home/abcd0001/CST8177-14W/Assignments/assignment12
$ url=http://teaching.idallen.com/cst8177/14w/notes/data/assignment12do.sh
$ curl -A mozilla "$url" >do.sh
[... make sure you scroll right to read the full web URL above ...]
[... various download statistics print here ...]
$ fgrep -i 'error' do.sh # make sure no errors (no output)
$ head -n1 do.sh # make sure it's a shell script
#!/bin/sh -u
You must run the do.sh
script you just downloaded. You must run the script as the root
user with the USER
environment variable set to your own CLS account userid. (Do not use abcd0001
; use your own.) Failure to set the USER=
variable as shown below will cause your account to be locked out of the CLS.
As shown below, use sudo
and sh
to run the do.sh
script you just downloaded to CentOS with the USER
environment variable set to your own CLS account userid (as stored in the USER
variable).
$ echo "$USER" ; pwd
abcd0001 # your userid, not abcd0001
/home/abcd0001/CST8177-14W/Assignments/assignment12
$ sudo USER=$USER sh do.sh
This do.sh
script runs a Fetch program that will connect from your CentOS machine to the CLS using your account name in the USER
variable. It will copy selected files from your CentOS machine to your assignment12
directory on the CLS. It will then run the checking program on the CLS to check your work. You will need to answer one question about your IP address, and then wait and type in your CLS password, as shown below:
---------------------------------------------------------------------------
abcd0001: FETCH version 3. Connecting to CLS as USER='abcd0001' using ssh
---------------------------------------------------------------------------
abcd0001: Use local Algonquin IP cst8177-alg.idallen.ca [y/N/?]? n
abcd0001: Please wait; using ssh to connect to user 'abcd0001' on cst8177.idallen.ca ...
*** COURSE LINUX SERVER ***
abcd0001@cst8177.idallen.ca's password: # enter your CLS password
---------------------------------------------------------------------------
idallen-ubuntu assignment12fetch_server.sh version 8 run by abcd0001.
Please wait; collecting info from abcd0001 Virtual Machine
---------------------------------------------------------------------------
VM files collected into CST8177-14W/Assignments/assignment12/abcd0001.tar.bz on CLS.
Now running checking program for abcd0001 on CLS:
[... checking program output appears here ...]
tar
archive in your account under assignment12
on the CLS and then runs the checking program on the CLS. If you only run the checking program on the CLS, it won’t update the files from your CentOS VM and it will just check the existing files saved under assignment12
on the CLS..bashrc
file or world-writable files on the CLS). These errors are on the CLS, not on your CentOS machine.When you are done with your assignment, you need to run the checking program one last time on the CLS (not from CentOS) and submit the output file, as follows:
Do all this on the Course Linux Server when you are ready to submit:
There is a Checking Program named assignment12check
in the Source Directory on the CLS. Create a Symbolic Link to this program named check
under your new assignment12
directory on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file.
Execute the above “check” program on the CLS using its symbolic link. (Review the Search Path notes if you forget how to run a program by pathname from the command line.) This program will check your fetched CentOS work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.)
Remember: The checking program does not fetch new files to the CLS from your CentOS VM. You must run the Fetch program on your CentOS VM to update the fetched files on the CLS so that the checking program can mark them on the CLS.
You may run the “check” program as many times as you wish, to correct mistakes and get the best mark. Some task sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.
assignment12.txt
under your assignment12
directory on the CLS. Use the exact name assignment12.txt
in your assignment12
directory. Case (upper/lower case letters) matters. Be absolutely accurate, as if your marks depended on it. Do not edit the file.
YOUR MARK for
assignment12.txt
file from the CLS to your local computer and verify that the file still contains all the output from the checking program. Do not edit this file! No empty files, please! Edited or damaged files will not be marked. You may want to refer to your File Transfer notes.
YOUR MARK for
Upload the assignment12.txt
file under the correct Assignment area on Blackboard (with the exact correct name) before the due date. Upload the file via the assignment12 “Upload Assignment” facility in Blackboard: click on the underlined assignment12 link in Blackboard. Use “Attach File” and “Submit” to upload your plain text file.
No word-processor documents. Do not send email. Use only “Attach File”. Do not enter any text into the Submission or Comments boxes on Blackboard; I do not read them. Use only the “Attach File” section followed by the Submit button. If you need to comment on any assignment submission, send me email.
You can upload the file more than once; I only look at the most recent. You must upload the file with the correct name; you cannot correct the name as you upload it to Blackboard.
You will also see the Review Submission History page any time you already have an assignment attempt uploaded and you click on the underlined assignment12 link.
You cannot delete an assignment attempt, but you can always upload a new version. I only mark the latest version.
Your instructor may also mark files in your directory in your CLS account after the due date. Leave everything there on the CLS. Do not delete any assignment work from the CLS until after the term is over!
I do not accept any assignment submissions by email. Use only the Blackboard Attach File. No word processor documents. Plain Text only.
Use the exact file name given above. Upload only one single file of Linux-format plain text, not HTML, not RTF, not MSWord. No fonts, no word-processing. Linux plain text only.
NO EMAIL, WORD PROCESSOR, PDF, RTF, or HTML DOCUMENTS ACCEPTED.
No marks are awarded for submitting under the wrong assignment number or for using the wrong file name. Use the exact 16-character, lower-case name given above.
WARNING: Some inattentive students don’t read all these words. Don’t make that mistake! Be exact.
READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!
Author:
| Todd Kelley and
| Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada
| Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/
| College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/
| Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/
Plain Text - plain text version of this page in Pandoc Markdown format
Author Ian! D. Allen