% CST8177 Assignment 09 – CentOS: Quotas, SysVinit, chkconfig, Logging, Logrotate, Logwatch, psacct % Ian! D. Allen – – [www.idallen.com] % Winter 2015 - January to Apil 2015 - Updated Sun Apr 12 04:40:19 EDT 2015 Due Date and Deliverables ========================= > **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. - **Due Date**: `23h59 (11:59pm) Friday April 17, 2015 (end of Week 14)` - You have more than one week to do this assignment, but your next assignment will be available in one week and will overlap this assignment. Start work on this now! Don’t delay! - Late assignments or wrong file names may not be marked. Please be accurate and punctual. - **Available online** - Version 1 – 18:15 April 2, 2015 - Version 2 – 16:10 April 4, 2015 – extended due date, above - **Prerequisites** - [CST8207 GNU/Linux Operating Systems I] - All Class Notes since the beginning of term. - All your previous [Assignments]. - Completed [CentOS Install and Configure] virtual machine installation (done in a previous assignment). - Completed previous assignment moving `/home` to a quota-enabled file system. - An ability to **READ ALL THE WORDS** to work effectively. - **Deliverables** 1. Modifications to your [CentOS Install and Configure] as given in this assignment. - **Do not delete any assignment work from your CentOS VM until after the term is over!** 2. One plain text file uploaded to Blackboard according to the steps in the **Checking Program** section below. 3. Directory structure and files created and left for marking on the [Course Linux Server] (**CLS**) and your CentOS Virtual Machine. **Do not delete any assignment work from the CLS or your Linux Virtual Machine until after the term is over!** Purpose of this Assignment ========================== > **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. 1. Practise working with Quota mechanism 2. Practise working with System Services 3. Explore SysVinit system of system initialization 4. Practise working with `rsyslog` logging mechanism 5. Explore other forms of logging and log rotation Remember to **READ ALL THE WORDS** to work effectively and not waste time. Introduction and Overview ========================= 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. 1. Complete the readings in your weekly Class Notes. 2. Complete the **Tasks** listed below, in order. 3. Verify your own work before running the **Checking Program**. 4. Run the **Checking Program** to help you find errors. 5. Submit the output of the **Checking Program** to Blackboard before the due date. 6. **READ ALL THE WORDS** to work effectively and not waste time. Save your work -------------- 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. Searching the course notes on the CLS ------------------------------------- The previous term’s course notes are available on the Internet here: [CST8207 GNU/Linux Operating Systems I]. All the notes files are also searchable on the CLS. You can recall 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]. Backup and Recovery on CentOS ----------------------------- 1. Take a snapshot of your virtual machine before you begin each section of this lab so that you can recover back to the snapshot if needed. - You can delete the unused snapshots if everything works well. - CentOS snapshots are very small and fast compared to your Windows snapshots; you can save lots of them. 2. *Are you keeping an external backup copy of all your coursework (including your virtual machines) somewhere? You should be!* Use a remote login, not the VMware console ------------------------------------------ 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 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 > `tmux` and `screen` that do allow you to suspend and resume your sessions > even from a remote login. CentOS No `root` files in non-root accounts ------------------------------------------- Files 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 ; pwd ; echo "$USER" ; find . ! -user "$USER" -ls /home/abcd0001 # your HOME directory not abcd0001 abcd0001 # your own userid not abcd0001 [... any non-abcd0001 owner files are listed here ...] [abcd0001@abcd0001 ~]$ cd ; pwd ; echo "$USER" ; find . ! -group "$USER" -ls /home/abcd0001 # your HOME directory not abcd0001 abcd0001 # your own userid not abcd0001 [... any non-abcd0001 group files are listed here ...] **Note** that the above commands were run when logged in as **your sysadmin account**, not when logged in as `root` – make sure the `$USER` variable contains your own userid not the `root` userid. You want to find files not owned by or in the group of your *own* userid. If you find any files that are not owned by or in the group of your own sysadmin userid, you should change the owner and group of these files to be your own userid and group. (The command that does this has a *recursive* option that lets you change everything under a directory.) **Hints:** You need to know which account has permissions to change the ownership and group of a file. You need to know how to make the change. See the examples in [Users and Groups]. > Advanced users can modify the above `find` to send pathnames into `sudo` > running `xargs` with `chown`. See [Find and Xargs]. Tasks ===== - Do the following tasks in order, from top to bottom. - Pay attention as to which tasks must be done in your own CentOS VM and which must be done in your account on the [Course Linux Server]. **Put the escape for your current machine name into your SHELL prompt so you know which machine you are working on!** - Tasks done on your own Centos VM require you to run a marking program in that Virtual machine. That marking program will transfer marking data from the VM to the CLS for marking. - Your instructor will mark on the due date the work transferred to account on the CLS. Leave all your work on the CLS and do not modify it. - **Do not delete any assignment work from the CLS until after the course is over.** - **READ ALL THE WORDS!** and do not skip steps. CentOS Snapshot --------------- 1. Complete your [CentOS Install and Configure]. 2. Complete the previous assignment that included **Migrate the /home directory to its own filesystem** with quotas enabled. 3. Before you begin this assignment, create a snapshot of your CentOS Virtual Machine. - Enter a comment explaining where and when you took this snapshot. - You can restore back to this snapshot if anything goes wrong. Set Up – On The CLS ------------------- 1. 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. 2. Make the CLS directory `~/CST8177-15W/Assignments/assignment09` CentOS Set Up – The Base Directory on CentOS -------------------------------------------- 1. In your own sysadmin account in your CentOS Virtual Machine, also make the CentOS directory `~/CST8177-15W/Assignments/assignment09` (the same hierarchy as you have already made on the CLS). **This CentOS `assignment09` 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 Directory].** Run the **Fetch** and [Checking Program] to verify your work so far. Managing user quotas -------------------- 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, do it now, or skip this section.** > For further information on quotas, refer to [Red Hat Quotas] 1. Install the `quota` package. 2. Take your CentOS VM into single user mode. (See [CST8207 Booting and GRUB]. Remember that SSH sessions don’t work in single-user mode.) 3. 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.) 4. 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. 5. In single-user mode, enable quotas (turn quotas on) for the `/home` filesystem. 6. Make sure you can log in to the `User 100` account (e.g. using `su`). - Run the `quota` command as `User 100` and ensure you see no quotas. - If you see the error `quota: Can't open quotafile /home/aquota.user: Permission denied` then you forgot to turn quotas on. 7. Confirm (from the output of the `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. - The HOME directory of `User 100` counts as one “file”. - `User 100` should have a non-empty bash history file. 8. For `User 100`, set the following (unrealistic) test quota values: - **soft block limit**: 500KB worth of 1K blocks (`500`) - **hard block limit**: 700KB worth of 1K blocks (`700`) - **soft inode limit**: `5` - **hard inode limit**: `6` - **Hint:** Only the super-user can set quotas. ### `repquota.txt` {#repquota.txt .floatright .unnumbered} 9. Generate an overall `/home` file system quota report for all users and verify that `User 100` has the correct limits: - This is a full quota report, so it should have over 100 lines. - Make sure `User 100` has these exact numbers: `user100 1 500 700 1 5 6` - Double-check that the `used` column number for `User 100` is exactly 1 (one inode in use – the user’s HOME directory). - Generate the full report again, redirecting the output to file `repquota.txt` in your sysadmin [Base Directory]. The file will also be over 100 lines long. 10. 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. - Do not leave root-owned files in your sysadmin account. - Review the earlier section on [No Root Files], above. 11. Take your CentOS VM back to **runlevel 3** and log in as your sysadmin account. - Verify you are in runlevel 3 with the appropriate command. 12. From your sysadmin account, use both `sudo` and `su` with the correct option to do a full login as `User 100`. - You need `sudo` gain root privileges and you need `su` with the right option and userid to do the full login. - You can also use the correct two options to `sudo` to simulate a login as a particular user name, without using `su`. 13. Exit the `User 100` shell and check the quota of the `User 100` account: - Verify that the account quota for `User 100` is now using *two* inodes (sometimes called “files”, but one is really a directory). - (If you don’t see a quota increase, perhaps you didn’t [Enable Shell History] when you installed CentOS? Fix this and try again.) 14. Do a full login again to `User 100`. - Verify that the account quota is still using exactly *two* inodes (files). - One inode (“file”) is the HOME directory. - **Exam question:** What is the name of the second inode that was created in the `User 100` account? Why does quota show two inodes in use and not just one? ### Quota work in the `User 100` HOME directory ### `bigfile1` {#bigfile1 .floatright .unnumbered} ### `user100_quota.txt` {#user100_quota.txt .floatright .unnumbered} 1. **Do *all* the following section logged in as `user100` in the `user100` home directory**: a. Ensure that the `User 100` quota shows only two files in use. Remove any extra files from the account (and perhaps elsewhere in the file system) if this is not true. The quota must show exactly two files in use. b. Exceed the soft block limit by creating a 600KB file with this command: $ whoami ; pwd user100 /home/user100 $ dd if=/dev/zero of=bigfile1 bs=1K count=600 sdb1: warning, user block quota exceeded. 600+0 records in 600+0 records out $ ls -s total 600 600 bigfile1 $ quota Disk quotas for user user100 (uid 599): Filesystem blocks quota limit grace files quota limit grace /dev/sdb1 602* 500 700 6days 3 5 6 Creating this file may generate a quota exceeded message on your screen and on the system console, because you are now over the soft limit on the number of disk blocks you can use. If you are logged in via a terminal program, not on the VMware console, you may not see the quota exceeded warning message. Even though you may see a `quota exceeded` warning message, 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. 1. The HOME directory is one “file” inode. 2. The file from the previous step is the second inode. 3. The `bigfile1` is the third file inode. In the `quota` output, note the number of blocks used and the number of inodes (`files`) in use. You should see that the number of blocks used exceeds the soft quota but not the hard quota. The `grace` period column should say something like `6days`. The account should now have three “files” in it. c. 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 and 24 words: $ whoami ; pwd user100 /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? The account should now have four “files” in it. d. View the contents of the new `user100_quota.txt` file: - Note how the number of inodes (`files`) listed in the file increased to four. Know why the number increased *before* the quota command ran. (Review *[Redirection]*) - Note how the number of blocks did *not* increase in the file. - Display the quota again (without redirection) and note that the number of blocks has now gone up to account for the new file. - Know why the increased number of blocks did not go into the redirection output file, but did show up after. (Review *[Redirection]*) e. Run `ls` to display a long listing of all the pathnames in the `user100` HOME directory, including options to show the hidden names and the sizes in blocks. - The number of inodes 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. - The disk blocks in use by `User 100` should total to the same number as given in the `quota` command output. - Start over if this is not true. f. Run a summary [Disk Usage] of the current (HOME) directory. - The summary should show the same number as the quota blocks. 2. Type `exit` to revert from `user100` back to your sysadmin account. ### `repquota_grace.txt` {#repquota_grace.txt .floatright .unnumbered} 3. 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]. - Because you use `sudo` and redirection, the file will be owned by you, not by `root`. *(Review [Sudo Redirection])* 4. View `repquota_grace.txt` and verify that it is owned by you and is consistent with the numbers in the `user100_quota.txt` file. - Compare the two repquota files and note the appearance of the new value `6days` in the `grace` column of the `Block limit` section for `User 100`. ### `bigfile2` {#bigfile2 .floatright .unnumbered} ### `smallfile` {#smallfile .floatright .unnumbered} ### `linkfile1` {#linkfile1 .floatright .unnumbered} ### `linkfile` {#linkfile .floatright .unnumbered} 5. Become `User 100` again and do the following in the user’s HOME directory: a. Ensure that the `User 100` quota shows only four inodes (“files”) in use. Remove any extra files from the account (and perhaps elsewhere in the file system) if this is not true. The quota must show exactly four files in use and about 603 disk blocks in use. b. 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 ; pwd user100 /home/user100 $ dd if=/dev/zero of=bigfile2 bs=1K count=200 sdb1: write failed, user block limit reached. dd: writing 'bigfile2': Disk quota exceeded 98+0 records in 97+0 records out $ ls -s bigfile2 97 bigfile2 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. (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. c. Display the quota information for the account: - The hard block limit of `700` has been reached. - The number of files should be listed as `5` (the soft limit). d. Create an empty sixth file named `smallfile` and note: - Creating even an empty file will generate a quota exceeded message , because you are now over the soft limit on the number of files you can create (only `5`). The system let you create the sixth file, but warned you that you are over your soft file limit quota. - If you are logged in via a terminal program, not on the VMware console, you may not see the file limit quota warning message. - You will see the quota exceeded message when the account has more than `5` files (the soft limit) in it. e. Try (and fail) to create a seventh empty file (any name): $ quota Disk quotas for user user100 (uid 599): Filesystem blocks quota limit grace files quota limit grace /dev/sdb1 700* 500 700 6days 6* 5 6 6days $ touch foo sdb1: write failed, user file limit reached. touch: cannot touch 'foo': Disk quota exceeded You will find that you get error messages and can’t create any more files, because you hit the hard limit on the number of files you can create (max `6`). Programs trying to create new files or directories will fail and return error messages. f. Create a hard link from `bigfile1` to `linkfile1` - Note that you *can* create **hard links** to existing files, since hard links only create new names, not new disk space. - There are now seven names in this account, but only six inodes. g. Try (and fail) to create a symbolic link with target `smallfile` named `linkfile` $ ln -s smallfile linkfile ln: creating symbolic link 'linkfile': Disk quota exceeded - You *cannot* create symbolic links, since symbolic links require disk space to store the link pathname. - You cannot create directories either, since a directory is considered a *file* for the purpose of quotas. (Anything that requires a new inode is considered a *file* here.) h. Display the quota information and verify that both the block and files quotas have hit their hard limits for this user. 6. Type `exit` to revert back to your sysadmin self. ### `repquota_hard.txt` {#repquota_hard.txt .floatright .unnumbered} 7. As your sysadmin user, generate another quota report, redirecting the output into your file `repquota_hard.txt` in your sysadmin [Base Directory]. - Make sure you do this as your sysadmin user (using `sudo`) so that the owner of the redirection output file is your sysadmin user, so that the updated quota information includes this new file. 8. Use `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 (exactly eight lines of output): - Exactly two users’ usage should have changed. If you do not see exactly two users, review all the words on the previous step. - Nothing should be shown for the `root` user. No changes. - If you see any changes for the `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_quota.txt` {#user100_quota.txt-1 .floatright .unnumbered} 9. Copy the `user100` file named `user100_quota.txt` into your own sysadmin [Base Directory]. (Needs privilege; you know what to do.) - Because you always use the `-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. 10. Change the ownership and group of all files in your sysadmin [Base Directory] to your own sysadmin account. - Review the earlier section on [No Root Files], above. - Verify that the current quota use for `User 100` is no longer above either of the hard limits. The user should be exactly at both the block quota limit and file quota limit. Run the **Fetch** and [Checking Program] to verify your work so far. Exploring SysVinit ------------------ 1. Do the following tasks on the console (in the VMware window) of your VM. 2. Back up and then edit your `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: - Before: `26 149 884` and `57793 1` - After: `26 149 884` and `57789 1` 3. Reboot your system, and after it comes back up, log in and display the runlevel to verify that it is in runlevel 2. ### `pse_rc_2.txt` {#pse_rc_2.txt .floatright .unnumbered} 4. 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). 5. Take your system into single user mode (runlevel 1) using the appropriate arguments to the `shutdown` command. - Remember that SSH sessions don’t work in single-user mode. - You should probably disconnect your terminal sessions first. ### `pse_rc_1.txt` {#pse_rc_1.txt .floatright .unnumbered} 6. 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). 7. Return back to the default runlevel by exiting the single user mode shell. ### `pse_rc_diff.txt` {#pse_rc_diff.txt .floatright .unnumbered} 8. Log in as your sysadmin user and put the text difference between the two files `pse_rc_{1,2}.txt` into a `pse_rc_diff.txt` file. 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. 9. Fix the ownership of any `root`-owned files in your sysadmin account. - Review the earlier section on [No Root Files], above. Run the **Fetch** and [Checking Program] to verify your work so far. Exploring `chkconfig` --------------------- > We’ll consider the `ntpd` service and runlevel 3. We’ll look at the > contents of the `rc3.d` directory while `ntpd` is set `on` for runlevel 3. > Then we’ll turn `ntpd` `off` for runlevel 3, and look at the contents of > the `rc3.d` directory again to see how it changed. ### `ntpd_chkconfig.txt` {#ntpd_chkconfig.txt .floatright .unnumbered} 1. 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 ### `ntpd_before.txt` {#ntpd_before.txt .floatright .unnumbered} 2. 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 ### `rc3d_before.txt` {#rc3d_before.txt .floatright .unnumbered} 3. 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 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`. ### `rc3d_ntpd_before.txt` {#rc3d_ntpd_before.txt .floatright .unnumbered} 4. 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 5. 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). 6. Use `chkconfig` to turn `ntpd` off in runlevel 3. ### `ntpd_after.txt` {#ntpd_after.txt .floatright .unnumbered} 7. 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 ### `rc3d_after.txt` {#rc3d_after.txt .floatright .unnumbered} 7. 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] (also 26 lines, 277 words). ### `rc3d_ntpd_after.txt` {#rc3d_ntpd_after.txt .floatright .unnumbered} 8. 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. 9. Turn the `ntpd` service on again in runlevel 3 (back to normal). Run the **Fetch** and [Checking Program] to verify your work so far. Logging ------- > We’ll look at the logging of `ssh` activity. Then, we’ll change the file > that `ssh` logging goes to, and change it back. ### `rsyslog_authpriv.txt` {#rsyslog_authpriv.txt .floatright .unnumbered} 1. 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 ### `sshd_logging.txt` {#sshd_logging.txt .floatright .unnumbered} 2. 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. 3. 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). 4. 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. - The last line of the file should show a log entry for the `sudo` command you just used. 5. In another window, log in again to your CentOS VM with `ssh` or `PuTTY`, and observe the output of your `tail -f` command in the other window. - You should see `sshd` log entries for your login activity. 6. 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!) ### `ssh_sudo_log.txt` {#ssh_sudo_log.txt .floatright .unnumbered} 7. Interrupt the `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]. a. View this file to be sure it includes both the `sshd` and `sudo` log entries you saw in the previous steps. b. If the file doesn’t contain those log entries, then redirect a `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` c. The `ssh_sudo_log.txt` file must show logging lines from both `ssh` and from `sudo`. ### `sshd_new.txt` {#sshd_new.txt .floatright .unnumbered} 8. Recall the name of the `sshd` configuration file viewed earlier. a. Back up and edit that file to make the SSH service daemon switch from using the `AUTHPRIV` to the `AUTH` logging facility by uncommenting one line and commenting out another. (Both lines exist in the file already.) b. When you’re done, the `wc` on the file should be the same. Run a `diff` between the old and new files to confirm your change. c. Save a copy of the edited file in file `sshd_new.txt` in your sysadmin [Base Directory]. 9. Restart the `sshd` service using the appropriate command. - You should see `Stopping sshd: [OK]` followed by `Starting sshd: [OK]`. ### `rsyslog_auth.txt` {#rsyslog_auth.txt .floatright .unnumbered} 10. 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 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. 11. 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. Writing to the logs from a script --------------------------------- > At [Managing Quotas], Red Hat recommends a daily cron job to > `touch /forcequotacheck` so that `quotacheck` 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. ### `force_grep.txt` {#force_grep.txt .floatright .unnumbered} ### `quotacheck_grep.txt` {#quotacheck_grep.txt .floatright .unnumbered} 1. Let’s verify that the system init script actually does pay attention to the file `/forcequotacheck`. a. The sysVinit system initialization script is still used by CentOS 6, even though CentOS 6 uses the `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. b. 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 c. Do a case-insensitive `grep` for `quotacheck` in that same script: - RTFM for case-insensitive `grep` d. It will print out enough lines so that with your knowledge of scripting, you can see the gist of what the script does with `quotacheck`. e. 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 the `rsyslog` 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 by `rsyslog`. ### `messages_tail.txt` {#messages_tail.txt .floatright .unnumbered} 2. Try out the `logger` command with no options and a simple message: `I made this default log entry` a. What is the default **priority** used by `logger` (RTFM)? b. Where do messages with this facility and level get logged? **Hint:** it’s the same “catch-all” log file you noted earlier. It is where the default log messages go. c. Use `tail` on that system log file to see your message. d. Save the `tail` output (10 lines showing your message) as file `messages_tail.txt` in your sysadmin [Base Directory]. ### `secure_tail.txt` {#secure_tail.txt .floatright .unnumbered} 3. Try out the `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` a. Where do messages with this facility and level get logged? **Hint:** You already know this from your work with `sshd` b. Use `tail` on that system log file to see your message. c. Save the `tail` output (10 lines showing your message) as file `secure_tail.txt` in your sysadmin [Base Directory]. ### `forcequotacheck.sh` {#forcequotacheck.sh .floatright .unnumbered} 4. Write a script named `forcequotacheck.sh` (in your sysadmin [Base Directory]) that takes no arguments and creates an empty `/forcequotacheck` file (note the full pathname), as follows: a. Put our standard script header at the top. b. Add argument checking. Print the standard error and usage messages and exit with a non-zero status if any arguments are supplied to the script. - You have already written exactly this code in earlier assignments on the CLS. You could try to remember which scripts in which assignments checked for zero arguments, or you could be lazy and clever and use `grep` to search all assignment directories and all scripts to find one that has the code you need. You choose. (p.s. Choose lazy.) c. Write to the system log file using a `logger` command as follows: i. Use `user.info` as the `facility.level` pair for all logging messages in this script. ii. Use the current script name as the tag for all logging messages in this script. - What variable should you use to get the script’s current name? - Do not hard-wire the script name inside the script! iii. Log the message: `Attempting to force quota check upon next reboot` d. 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 ### `testing.txt` {#testing.txt .floatright .unnumbered} 5. Test your script and save the test results: a. Test it with arguments to be sure the error messages work correctly. b. Test your script by running it as your sysadmin user without `sudo` - It should fail and log a message. (You should know why.) - Check the logs for the messages appropriate for this failure. c. Test your script with `sudo` so that it succeeds. - Check the logs for the messages appropriate for success. d. Save into file `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). 6. Allow the system `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 operations -------------------- 1. Change your `logrotate` configuration file to keep 5 weeks worth of backlogs by default. - The file has an obvious name and is directly under the `/etc` directory, as you would expect. - You will change exactly one character on each of two lines. - Your `wc` and `sum` should be `35 110 662` and `56994 1`. 2. Change your `logrotate` configuration file for the `yum` package to rotate the `yum` logs monthy rather than yearly. - Look for a `logrotate`-related directory under `/etc` and inside that directory look for a `yum`-specific file. - Your `wc` and `sum` should be `6 10 88` and `42386 1`. Run the **Fetch** and [Checking Program] to verify your work so far. Logwatch and Mail ----------------- 1. Install the `logwatch` package. > 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` (use a command to do this, don’t do it the hard way) and use > its actual location. 2. Change the user that receives `logwatch` emails from `root` to your own sysadmin userid. 3. Change the detail of `logwatch` summaries from `Low` to `Med` (medium). 4. 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). ### `email.txt` {#email.txt .floatright .unnumbered} 5. Revert back to your sysadmin user, and if you successfully changed the user that receives `logwatch` emails, you should have an email from `logwatch` a. Review reading email in [Course Linux Server - EMail] b. Write the `logwatch` mail message to file `email.txt` in your sysadmin [Base Directory]. c. Quit the mail program. d. Verify that your `email.txt` file contains the `logwatch` mail message text. e. The message must contain a non-zero `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. Process Accounting and Login History ------------------------------------ 1. Install the `psacct` package, for monitoring process activities. ### `psacct_levels.txt` {#psacct_levels.txt .floatright .unnumbered} 2. 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 3. Turn on `psacct` for runlevels `2`,`3`,`4`,and `5` 4. Check the status of the `psacct` service, and start it if it’s not enabled. 5. Use the `last` command to view a listing of last logged in users - Create a `user100` account unless you already have one created from a previous assignment. Give it a simple password. - Create some login records for `user100` by using `ssh` to login a few times: `ssh user100@localhost` - Once logged in as `user100`, type a few commands such as `date` or `who` and then `exit` to log out again. Repeat once or twice. ### `last_user100.txt` {#last_user100.txt .floatright .unnumbered} 6. 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 **Hint**: Do not use `grep` or any pipeline for this. Use one command with one argument. RTFM. 7. Use the `lastlog` to display a report of the most recent logins of all users ### `lastlog_user100.txt` {#lastlog_user100.txt .floatright .unnumbered} 8. 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 to create this file. One command. RTFM. ### `ac_individuals.txt` {#ac_individuals.txt .floatright .unnumbered} 9. 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]. ### `lastcomm.txt` {#lastcomm.txt .floatright .unnumbered} 10. 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]. 11. Change the ownership and group to you of any remaining `root` owner or group files anywhere in your CentOS system admin account. (If you’ve done your work carefully, there should be nothing owned by `root`.) - Review the earlier section on [No Root Files], above. - System administrators often scan HOME directories, looking for `root`-owned files as an indication that someone has broken into the system. Don’t leave `root`-owned files in your own CentOS sysadmin account. - **NOTE**: The [Checking Program] does create `root` files in your CLS assignment directories. This is intentional: don’t delete these files from the CLS! Run the **Fetch** and [Checking Program] to verify your work so far. When you are done ----------------- 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. Read your CLS Linux EMail and remove any messages that may be waiting. See [Reading eMail][Course Linux Server - EMail] for help. > 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! Checking, Marking, and Submitting your Work =========================================== See [CentOS Remote Checking, Marking, and Submitting your Work]. -- | 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 [www.idallen.com]: http://www.idallen.com/ [hyperlink URLs]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [CST8207 GNU/Linux Operating Systems I]: ../../../cst8207/14f [Assignments]: indexcgi.cgi#Assignments [CentOS Install and Configure]: ../../../cst8207/15w/notes/000_centos_install.html [Course Linux Server]: ../../../cst8207/15w/notes/070_course_linux_server.html [Network Diagnostics]: ../../../cst8207/15w/notes/000_network_diagnostics.html [Users and Groups]: ../../../cst8207/15w/notes/700_users_and_groups.html [Find and Xargs]: ../../../cst8207/15w/notes/185_find_and_xargs.html [Remote Login]: ../../../cst8207/15w/notes/110_remote_login.html [Base Directory]: #centos-set-up-the-base-directory-on-centos [Checking Program]: #checking-marking-and-submitting-your-work [Red Hat Quotas]: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-disk-quotas.html [CST8207 Booting and GRUB]: ../../../cst8207/15w/notes/750_booting_and_grub.html [No Root Files]: #centos-no-root-files-in-non-root-accounts [Enable Shell History]: ../../../cst8207/15w/notes/000_centos_install.html#enable-shell-history [Redirection]: ../../../cst8207/15w/notes/200_redirection.html [Disk Usage]: ../../../cst8207/15w/notes/457_disk_usage.html [Sudo Redirection]: ../../../cst8207/15w/notes/700_users_and_groups.html#sudo-doesnt-affect-shell-redirection [Managing Quotas]: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/disk-quotas-keep-accurate.html [Course Linux Server - EMail]: ../../../cst8207/15w/notes/070_course_linux_server.html#email-on-the-cls [CentOS Remote Checking, Marking, and Submitting your Work]: ../../../cst8207/15w/notes/000_centos_marking.html [Plain Text]: assignment09.txt [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/