CTS 2301C (Unix/Linux Administration I) Project #9
User Administration (also Package Installation)


Due: by the start of class on the date shown on the syllabus


In this project you will install user accounts, change login defaults, manage user accounts (including email configuration), set disk quotas, setup security, and examine log files.  Since many of these tasks are complicated, the directions below instruct you to install and then use the GUI tool webmin to perform some of the tasks such as enabling and setting quotas.  Make sure you keep an accurate system journal of any and all changes you make to your system!  You will need to turn this in, along with the answers to the questions asked below.

This is a lengthy project, so do not wait until the last minute to start!  When in doubt remember to use the man pages, including for file descriptions, and use the keyword search feature if in doubt as to the name of some command.  Do not hesitate to communicate with your instructor if you wish any help.


User Accounts

Generally UIDs and GIDs below 100 are reserved system and pseudo-system accounts.  On some systems (such as Solaris) UIDs above 60000 can't be used or will have limited functionality.  The command line and GUI tools know about these limits and should only create accounts within the correct range.

You can change most account information with the usermod command.  The passwd command allows you to lock/unlock accounts1 (so does usermod on Linux), view account status and information, and view and update password aging and other information.  chage and chfn on Linux do this too.  Solaris also has the command logins -axl username to view details for username, and an expanded set of options to the passwd command to view and modify most account and password information for a user account.  In addition Linux systems contain a gpasswd utility that is handy for adding a user to a group.  (For some reason this is difficult to do with usermod.)

The default contents of a new user's home directory are copied from /etc/skel.  The /etc/login.defs file controls the location of a user's system mailbox (inbox), what range of UIDs and GIDs to use, and password aging information.  The file /etc/default/useradd contains defaults used with the command line utility useradd.  (Solaris has similar default files to Linux's /etc/login.defs and /etc/default/* but the names of the files depend on the exact version of Unix you have.)

Disk Quotas

Disk quotas limit how much hard disk space can be consumed per user (and optionally per group), per filesystem.  Unix and Linux filesystems support quotas but not all filesystem types do.  Quotas have soft limits, hard limits, and a grace period.  A user may exceed the soft limit but never the hard limit.  As soon as a user has exceed the soft limit, a count-down timer is set to the grace period and starts counting down.  When the user reaches the end of the grace period the excess over the soft limit may be deleted, or the account disabled, or the limit may be frozen, or some combination of these.  Quotas can be used to limit how much disk space a user can consume per partition, how many files they can create per partition, or both.

Quotas can be enabled by mounting a partition with the usrquota (and optionally the grpquota) mount option(s).  (Note that this varies by filesystem and how old your system is; many filesystems just use quota as a mount option.  You will need to check the mount man page for your filesystem type, for the correct option to use.)  Normally this is done by editing /etc/fstab and adding usrquota to the mount options part of the entry for some filesystem.  Then the quota database files on each partition can be initialized with the quotacheck command, which should should also run monthly or possibly weekly from cron.  Use the commands edquota or setquota to edit the quota limits for individual users per partition (and the grace period too).  Use repquota to generate a quota report for all users.  You can use quotaon and quotaoff to manually turn on or off quota checking, although this is usually done automatically by the boot up rc scripts.


On most systems today the users get email from POP or IMAP, so these services must be configured.  Usually there is one or more aliases associated with user accounts.  One reason for aliases is to not allow hackers gain access to security information such as your users' account names or real names.  Aliases reflect the job(s) the users have, such as “sales” or “postmaster” or “webmaster” or “customer-rep”.  A number of email aliases should always be setup, including “abuse”, “admin” or “administrator”, and others that people can use to report problems or contact the correct person.

To send email and be able to run some of the commands below, you need to have an email server (MTA) installed and running.  On Fedora, you can check to see if you have sendmail installed with the command “rpm -q sendmail”.  If not, go ahead and install it with dnf, then start it with systemctl.


The sudo permissions database is in the file /etc/sudoers, see the man page for details and examples.  When setting up user accounts it may be necessary to update the /etc/sudoers file with the visudo command, to provide extra access to some users.


Answer the following questions and perform the following tasks:

  1. In this first part you will install the GUI admin tool webmin.  The GUI administration tool works for nearly every Unix or Linux system.  webmin is a web server that “listens” in on port 10000 rather than the default web server port of 80.  (For security reasons webmin usually requires access from the localhost only, so remote administration would require extra setup.)

    Note the directions on this assignment for using webmin reflect the version of webmin current at the time the assignment was created.  Every so often the user interface of webmin changes a bit, and then the directions below may not match exactly what you see on the screen.  Do your best, try to use the help provided, and let your instructor know if any of the directions here need to be updated.

    Download the RPM package for your version of Linux (Fedora) from www.webmin.com and install according to the directions on their web page.  (In practice installing from RPMs is very easy.)  Make sure that webmin is running (hint: webmin is a legacy SysV init daemon, so you cannot start or enable it with systemctl), then begin using webmin by pointing your web browser to the correct URL of http://localhost:10000/ or https://localhost:10000/ (for SSL security).  Documentation is installed when you installed webmin, or you can view it from the webmin web site.  You should log in as the root user.

    What version number of webmin did you install?

  2. There are usually a number of module updates available when you first install webmin.  Go ahead and update your modules before you try any of the steps below.  What do you do to update webmin, and all webmin modules?
  3. Using webmin, create a new user account auser with the real name Anne User.  Use defaults for all other values.
    1. What was the default group used?
    2. What was the default shell used?
    3. Was the account created enabled or disabled?
    4. What was the password used?
    5. When (if ever) does the password expire?
    6. When (if ever) does the account expire?
    7. What files were modified on your system as a result of the user account creation?  (Hint: use the find command to locate recently modified files.  Note not all files modified at that time are related to user account creation, only report those files that are related to the creation of the user account.)

    Change the initial password for that user to something else (that you can remember; I like “secret”).  Note that an account with a missing password is considered locked by default.

  4. For this part you will change many of the defaults used for creating new user accounts, and then create another user account using command line utilities.  Many of the defaults can be viewed or set using the useradd command with the -D option.  (These and other default settings could also be set by editing files in /etc/login.defs and /etc/default/useradd.)
    1. Set new accounts default shell to /bin/bash.
    2. Set new accounts to expire on December 15 (of this year).
    3. Set new account passwords to expire after 3 months.
    4. Set new accounts to be disabled one week after the password has expired.  (That is, after one week of inactivity after the password has expired.)

    What were the options used for each command?

  5. Using useradd command, create a new user account buser with real name Bob User.  Make sure the account is initially disabled (locked).  Be sure to set a password (that you will remember).
    1. What is actually different in the configuration file(s) for locked/disabled accounted versus unlocked/enabled accounts?
    2. Temporarily turn off the firewall (iptables), comment out the “ALL: ALL” line in /etc/hosts.deny, and start up the vsftpd service.  From the command line you should now be able to run sucessfully “ftp localhost” (and login as anonymous).  After starting the sshd service you should also be able to run “sftp auser@localhost”.  What happens when you try this with a locked account (such as buser)?  (Don't try to login as root, it won't work.)
    3. Unlock/enable the buser account now using any non-GUI method.  What two commands on Linux can be used to enable (unlock) an account?  Verify you can use both ftp and sftp with the buser account now.
    4. Change the login shell of buser to “/sbin/nologin”.  Try ftp and sftp for that user again.  What happened?
      As root, try the following commands: “su -c 'id' buser” and “su buser”.  Did either command work?
    5. Change the login shell of buser to “/bin/false”.  Try both ftp and sftp for that user again.  What happened this time?  Can you explain these results?  (HINT:  Examine /etc/shells for a list of valid shells on your system.)
    6. Restore the login shell of buser to “/bin/bash”.  As root, try the following commands: “su buser” and “su -c 'id' buser”.  Did either command work this time?
    7. Force user buser to change the password immediately at the next login.  (On Linux use the chage command.  On Solaris, use the passwd command.)  What was the exact command used?
  6. What command will remove a user account?  What command will allow you to modify a user account's settings?  Use the man command to find out.  Be sure to examine both man pages, and note the options available.
  7. Next you will setup a disk quota on your /home partition for auser.  Then cause that user to exceed the limits and observe the results.  Although this can be done from webmin, we will use the command line for some of the tasks in the directions below.

    If you have ever logged in as auser from the GUI, the desktop environment used (kde or gnome) will create a large number of additional files (big ones) and directories in the user's home directory.  If you have never done this, you most likely have about 40k of files and you can use quota limits of 100k (soft) and 200k (hard) limits, with a grace period of 2 (two) minutes or less.

    However if you've ever used the GUI as auser, you most likely have used about 5.5MiB of disk space, so don't use those small quota limits.  Instead use the du -h command to determine how much space is actually used and set the quotas to that value plus 100k (soft) and that value plus 200k (hard), with a grace period of 1 (one) hour or less.  If you used the smaller values, don't ever log into auser or buser from the GUI (or the attempt to create 530k of files will fail, causing the GUI system to be corrupted for that user).  How can you set the system to use text based logins, or if GUI logins are the default how can you use a non-GUI login for some user?  (Hint: see init for the default run level (or systemd for the default target), and remember about how to switch between virtual consoles.)

    On production systems, few users have login permission.  For the servers that do, quotas are set based on the expected need of users.  Software developers need little, multi-media developers may need a lot.  (Managers often need the least but this may be a political issue!)

    1. Login to webmin.  Click the “System” button.
    2. Now click on Disk and Network Filesystems.  Click the /home link.  Change the drop-down list for “Use Quotas?” to either “User only” or “User and Group”.  Save your changes and go back to the main Webmin page.

      Note:  If /home is in use you can't remount it to activate the new mount option(s).  Instead you can save the changes to /etc/fstab (i.e., the permanent mount list).  Then remount /home and build the initial quota database file(s) before proceeding.  Note you can't do this if /home is busy!  So if you logged in as your non-root user, you will need to log out and then enable quotas as root.  This is best done from the command line:

      1. logout as your non-root account.  (You can't remount /home if it is busy.)
      2. Login as root.  (This is easiest by switching to a non-GUI console window.)
      3. At the command line, as root, run the command:
        mount -o remount /home

        Which simply remounts /home with the usrquota flags you set using webmin.

      4. Now build the initial quota database files by running the command:
        quotacheck -cuvvM /home
        restorecon /home/aquota*

        The “restorecon” command fixes an SE Linux issue in some versions of Fedora.  You will need to do this for all newly created quota files, if you are running SE Linux in enforcing mode.

      5. Finally, enable quotas:
        quotaon -a
      6. Now login as yourself and return to webmin.
    3. In webmin, click on Disk Quotas.  You should see a line now for /home.  Make sure Quotas are enabled for this storage volume (they are if you see Disable Quotas at the end of the line.)  If not, go back to the previous steps and enable them.  (Remember you may have to log out and log in as root before you can remount /home.)  Click the /home link.

      Note that the quota database files, “/home/aquota.*” are created with permissions determined by umask.  This normally means the files will only be readable by the owner (root).  If you wish to allow normal users to check their quota using the quota command, these files must be readable by everyone (but writable only by root).  Use “chmod 644 /home/aquota.*” to fix this.  Note you won't be allowed to touch this file while quota checking is on, so turn off quota checking first (“quotaoff -a; chmod a+r /home/aquota.*; quotaon -a”).

    4. Next you can edit the grace periods.  This is not a per-user setting but rather a per-filesystem setting (for most systems anyway).  Note if you change some user's quota limits and they go over their quota, the current grace period will be used.  Changing the grace period afterward won't affect that user until they go under and back over their quota limits.
    5. Now enter the username auser (or select auser from the list of users that shows, or from the popup list you get by clicking on the “...” button).  Enter your quotas and limits for this user.  Note when entering in a number in the form you must also click the radio button or the quota limits will remain set to “unlimited”!  When done click the update button.

      Setting Quotas and Grace Times from the Command Line

      If you have problems using webmin you can use these steps instead:

      setquota -ta 604800 604800  # 7*24*60*60 = 1 week grace
      setquota auser soft-blk hard-blk soft-files hard-files /home
      repquota -a  # display quota report
    6. Test out quotas by logging in as auser.  (Don't login from the GUI unless you set the quota limits appropriately!)

      To log in as “auser” you can either switch to some virtual console or use:

         TERM=dumb ssh auser@localhost

      The “TERM=dumb” prevents ssh from clearing the screen when you close the connection, giving you a chance to see any messages.  Note that sshd daemon must be running before you can login in via ssh.

      Now go over your soft limit.  You can copy files (from /usr/share/doc), create large files by using the dd command, or by saving large man pages as files by running the command:

      man bash > bash.txt

      Use the du command and verify you are over your soft limit.  What message (if any) was displayed?  Check this user's email.  Was any email sent as a result of going over the quota?  Use the quota command to see the current quota status.  (Remember, this won't work if you login as a non-root user, unless you made the quota database file(s) readable by everyone.)  What was the output of this command?  Run the command:

      ( ls -als; quota; ) | lpr -T "your-name: before"

      Suppose you remain over your soft limit for more than the grace period (set earlier).  What do you think will happen?

    7. Now wait for the grace period to expire (do not log out!) and verify what actually did happen by performing these steps:  Run the command:
      ( ls -alsR; quota; ) | lpr -T "your-name: after"
      What is different between the “after” and the “before” output?

      Try to create a small file using vi (staying under the hard limit).  Did this work?  What happens if you try to create more large files in the user's home directory, that would cause the user to go over the hard limit.  Did this work?  What happened when you attempted to go over the hard limit?

      Now log out and attempt to login again as auser.  Was this allowed?  If so, was any email sent?

      Finally, remove the large files from /home/auser.  (You may have to do this step as root if you can't login as this user.)  Now attempt to login as auser.  Was this allowed?  If so, was any email sent?  Run the quota command now.  What is the “grace” period now?
  8. Next create some email aliases for user buser (“Bob User”).  Email aliases are created by editing the file /etc/aliases, and then running the command newaliases to update the aliases database file that sendmail actually uses.
    1. Create an alias sales for buser.
    2. Create an alias abuse for buser.
    3. Create an alias postmaster for buser.
    4. Create an alias sysadmins for users buser and root (i.e., a simple mailing list).
    5. Create a redirection alias anne@xyz.com.REDIRECT for auser.
    6. Have root's email forwarded to your personal account.
    7. Save your changes and update the aliases by running the newaliases command.

    Using any MUA of your choosing (such as pine) try to send email messages in turn to each of auser, buser, root, and sysadmins.  What happened in each case?

(There is really too much to do already for this project.  But if you have the time and desire, see if you can figure out how to setup a new user account cuser (“Chen User”) that cannot be used with telnet or ssh (that is, no login permitted), but can be used as a POP email account only.  Hint: see the man page for /sbin/nologin and determine what would happen if this was used instead of /bin/bash as the shell for this user.)

To be turned in:

The answers to the questions above and the portion of your system journal describing the changes you made to the disk. 

You can submit your project as email to .  Please see your syllabus for more information about submitting projects.



  1. Linux locks accounts by adding one or two '!' characters to the front of the password in /etc/shadow.  By removing the '!' characters you can unlock the account, which is exactly what the GUI and command line tools do.  So locking then unlocking an account leaves the password intact.

    On Solaris when you lock an account, the password is changed to "*LK*", so the only way to unlock an account is to set a new password for that account.  Back