Author Ian! D. Allen
Updated: 2015-09-06 00:38 EDT
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) Friday December 5, 2014 (end of Week 14)
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.
For full marks, follow these directions exactly.
You will create some minimal file system structure in your HOME directory on the CLS.
Most work will involve changes in your own Linux Virtual Machine running Centos 6.6. You can use the Checking Program to check your work as you go. You can check your work with the Checking Program as often as you like before you submit your final mark.
When you are finished, leave the files and directories in place on both the CLS and your own CentOS 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.
The previous term’s course notes are available on the Internet here: CST8207 GNU/Linux Operating Systems I. All the notes files are also 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.
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.
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 inside the VMware console do survive across suspend and resume.) (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
tmuxandscreenthat do allow you to suspend and resume your sessions even from a remote login.
root files in non-root accountsFiles saved anywhere under your sysadmin HOME directory in CentOS should be owned by you and in one of your groups, not owned by root or in the root group. (The presence of root files in non-root accounts is often a sign that your machine has been cracked!)
Do not leave root-owner or root-group files in your account. You should change the owner and group to you of anything you create as root in your account. To find files not owned by you or not in your own group in your account:
[abcd0001@abcd0001 ~]$ cd
[abcd0001@abcd0001 ~]$ echo "$USER"
abcd0001 # your own userid not abcd0001
[abcd0001@abcd0001 ~]$ find . ! -user "$USER" -ls
[... any non-abcd0001 owner files are listed here ...]
[abcd0001@abcd0001 ~]$ find . ! -group "$USER" -ls
[... any non-abcd0001 group files are listed here ...]If you find any files, you should use the chown command to fix these files to be your own userid and group. (The command has a recursive option that lets you change everything under a directory.)
Advanced users can modify the above
findto send pathnames intosudorunningxargswithchown. See Find and Xargs.
You must have successfully completed the CentOS Install and Configure to do this assignment.
Create the CLS directory ~/CST8177-14F/Assignments/assignment11 on the Course Linux Server.
Create the same directory in your sysadmin account on your CentOS VM. This CentOS directory will be the base directory for this assignment.
This CentOS assignment11 directory is the base directory for all pathnames in this assignment. Store your files and answers in this CentOS base assignment11 directory.
Pay careful attention to whether you are working on the CLS or CentOS, and which account you are using! Watch the userid and hostname values in your
PS1prompt string! All answer files in this assignment get stored in the CentOS base directory, not on the CLS.
You must have /home mounted on its own file system with user and group quotas enabled to do this section. You did that in a previous assignment:
$ mount | grep /home
/dev/sdb1 on /home type ext4 (rw,usrquota,grpquota)If you didn’t do that previous assignment, skip this section on user quotas.
For further information on quotas, refer to Red Hat Quotas
Install the quota package.
Take your CentOS VM into single user mode. (See CST8207 Booting and GRUB. Remember that SSH sessions don’t work in single-user mode.)
In single-user mode, make sure your /home file system is mounted with quotas enabled. (You added quota options to the fstab in an earlier assignment.)
In single-user mode, use the quotacheck command with options appropriate to initialize the group quota file and user quota file for the /home filesystem.
In single-user mode, enable quotas (turn quotas on) for the /home filesystem.
User 100 account (e.g. using su).
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.quota command) that the User 100 account has only two files in it and is using only two or three blocks. Clean out any extra files; there must be only one file.
User 100 counts as one “file”.User 100 should have a non-empty bash history file.User 100, set the following (unrealistic) test quota values:
500)700)56/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.sudo to simulate a login as a particular user name, without using su.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=600Creating 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. The account should now have three “files” in it.
files). You should see that the number of blocks used exceeds the soft quota but not the hard quota. The grace period column should say 6days. The account should now have three “files” in it.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.txtYou did read the words above about running all the commands in this section as user100, right? The account should now have four “files” in it.
user100_quota.txt file:
files) increased in the file increased to four. Know why the number increased before the quota command ran. (Review Redirection)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 4 – exactly the same as the number of files given in the user100_quota.txt file you created. Start over if this is not true.
Type exit to revert from user100 back to your sysadmin account.
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.
sudo and redirection, the file will be owned by you, not by root. (Review Sudo Redirection)repquota_grace.txt and verify that it is owned by you and is consistent with the numbers in the user100_quota.txt file.
6days in the grace column of the Block limit section for User 100.User 100 again and do the following in the user’s HOME directory:
Try to create a fifth file, as shown below. 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=200You 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. (It should contain about 97K.) The file is truncated because the hard quota limit was reached. You are not allowed to use any more disk blocks once you hit the hard quota. The account should now have five “files” in it.
5.smallfile and note:
5). The system let you create the sixth file, but warned you that you are over your soft limit.5 files (the soft limit) in it.6). Programs trying to create new files or directories will fail and return error messages.bigfile1 to linkfile1
smallfile named linkfile
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.user100 file named user100_quota.txt into your own sysadmin base directory. (Needs privilege; you know what to do.)
-p option to cp, the file copy will also be owned by User 100 and User 100 will now be using one more block and one more file than allowed by the hard quota limit. The super-user can always create files regardless of the user quota limits.User 100 is no longer above either of the hard limits.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 126 149 884 and 57789 1Reboot 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 78 lines).
Take your system into single user mode (runlevel 1) using the shutdown command. (Remember that SSH sessions don’t work in single-user mode.)
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. The first character of those link names will be 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.
chkconfigWe’ll consider the
ntpdservice and runlevel 3. We’ll look at the contents of therc3.ddirectory whilentpdis setonfor runlevel 3. Then we’ll turnntpdofffor runlevel 3, and look at the contents of therc3.ddirectory 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 1Run 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 1Take a long ls listing of /etc/rc.d/rc3.d/ and put this listing into rc3d_before.txt in your sysadmin base directory (about 26 lines, 277 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.txtVerify 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 1Now 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 (also 26 lines, 277 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.txtVerify 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
sshactivity. Then, we’ll change the file thatsshlogging 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 1View 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 1Remember 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).
PuTTY, or ssh) and use the tail -f command with sudo to watch the file that sshd log entries go to.
-f option keeps watch on the end of the file, waiting for new lines to appear.sudo command you just used.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.txtssh_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 should be the same. Run a diff between the old and new files to confirm your change.sshd_new.txt in your sysadmin base directory.sshd service using the appropriate command.
Stopping sshd: [OK] followed by Starting sshd: [OK].Read the Hints below. 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 1Hint: 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 /forcequotacheckso thatquotacheckwill 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.txtgrep for quotacheck in that same script:
grepquotacheck.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.txtThe
loggercommand writes into the system logs via thersyslogservice. 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 on that system log file to see your message.tail output (10 lines 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
sshdtail on that system log file to see your message.tail output (10 lines 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:
grep to search all assignment directories and all scripts to find one that has the code you need. You choose. (p.s. Choose lazy.)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 rebootCreate 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 valuesudo
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 6 10 88 and 42386 1.Run the Fetch and Checking Program to verify your work so far.
logwatch package.Note: Some documentation says that the
logwatch.conffile is located in/etc/logwatch.confbut this is not correct. Search for the file name under/etc(use a command to do this, don’t do it the hard way) and use its actual location.
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
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 1Turn 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 account unless you already have one created from a previous assignment. Give it a simple password.user100 by using ssh to login a few times: ssh user100@localhostuser100, type a few commands such as 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 38Hint: Do not use grep or any pipeline for this. Use one command with one argument. 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 50Do not use grep or any pipeline to create this file. 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.
Log in to the CLS and submit your mark from the CLS following the Checking Program instructions below.
Optional: Keeping your main configuration snapshots, remove any intermediate snapshots you no longer require, to free up disk space. - Be careful not to remove your current work!
See CentOS: Remote Checking, Marking, and Submitting your Work.
Author Ian! D. Allen