repquota.txt

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?

bigfile1

user100_quota.txt

1. Do all the following section logged in as user100 in the user100 home directory:
   1. 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.

   2. 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.

   3. 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.

   4. 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)
   5. 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.
   6. 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

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

smallfile

linkfile1

linkfile

5. Become User 100 again and do the following in the user’s HOME directory:
   1. 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.

   2. 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.

   3. 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).
   4. 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.

   5. 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.
   6. 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.

   7. 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.)

   8. 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

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

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.

pse_rc_2.txt

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

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

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.

ntpd_chkconfig.txt

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

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

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

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

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

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

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.

rsyslog_authpriv.txt

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

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

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.
   1. View this file to be sure it includes both the sshd and sudo log entries you saw in the previous steps.
   2. 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
   3. The ssh_sudo_log.txt file must show logging lines from both ssh and from sudo.

sshd_new.txt

8. Recall the name of the sshd configuration file viewed earlier.
   1. 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.)
   2. 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.
   3. 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

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.

force_grep.txt

quotacheck_grep.txt

1. Let’s verify that the system init script actually does pay attention to the file /forcequotacheck.
   1. 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.

   2. 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

   3. Do a case-insensitive grep for quotacheck in that same script:
      • RTFM for case-insensitive grep
   4. 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.

   5. 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

2. Try out the logger command with no options and a simple message: I made this default log entry
   1. What is the default priority used by logger (RTFM)?
   2. 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.
   3. Use tail on that system log file to see your message.
   4. Save the tail output (10 lines showing your message) as file messages_tail.txt in your sysadmin Base Directory.

secure_tail.txt

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
   1. Where do messages with this facility and level get logged? Hint: You already know this from your work with sshd
   2. Use tail on that system log file to see your message.
   3. Save the tail output (10 lines showing your message) as file secure_tail.txt in your sysadmin Base Directory.

forcequotacheck.sh

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:
   1. Put our standard script header at the top.
   2. 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.)
   3. Write to the system log file using a logger command as follows:
      1. Use user.info as the facility.level pair for all logging messages in this script.
      2. 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!
      3. Log the message: Attempting to force quota check upon next reboot

   4. 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

5. Test your script and save the test results:
   1. Test it with arguments to be sure the error messages work correctly.
   2. 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.
   3. Test your script with sudo so that it succeeds.
      • Check the logs for the messages appropriate for success.
   4. 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.

email.txt

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
   1. Review reading email in Course Linux Server - EMail
   2. Write the logwatch mail message to file email.txt in your sysadmin Base Directory.
   3. Quit the mail program.
   4. Verify that your email.txt file contains the logwatch mail message text.
   5. 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.

psacct_levels.txt

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

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

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

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

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.