EECS Technical Database

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== User Restriction Setup (optional) =====

By default, when you reserve the lab for Linux or Labtest mode, your booking will have no user restrictions.  That is, any student can login to any lab machine including students who are not part of your course.  Ultimately, this is the simplest setup as once you enable user restrictions, there is always the potential to inadvertently restrict students from logging in who should otherwise be able to login!  As a result, if you wish to have the ability to restrict access to the lab machines to specific students, you must make this part of your booking request.  

Once tech has enabled "user restrictions" on your lab booking, the next step is for you to configure it.   To do this, place a file called //users.allow// in your course directory - /eecs/course/<COURSE>.  This file contains one user who is allowed to login per line.  For example, if only cse1234 and cse5678 are allowed to login during your booking for EECS9999, then /eecs/course/9999/users.allow would contain:

  cse1234
  cse5678

**IMPORTANT NOTE:**  The //users.allow// file **must** be readable by the system, or it will be ignored and your restrictions will not be followed.  To make the //users.allow// file for EECS9999 readable by the system: chmod o+r /eecs/course/9999/users.allow

When the machines boot into Linux or Labtest mode, a "RESERVED" message will appear on the bottom of the login screen.  If a student who is not in the allow list tries to login, he will see a message as follows:

  The computer that you are trying to use has been reserved and 
  is not available for your use at this time.  Sorry for any
  inconvenience.

The users.allow file may also contain an optional "#include" directive.  For example:

  #include /eecs/course/9999/users.contest
  #include /eecs/course/9999/otherusers

NOTE: There **used** to be a "#includedist" directive which would allow you specify a distribution list.  Distribution lists are no longer available in labtest mode, and hence this does not work.  An alternate solution is provided below.

If your lab booking includes multiple machines, and you wish to restrict different users logging into different machines, this functionality is available as well.  Simply append ".<HOSTNAME>" to the //users.allow// file in your course directory to restrict users to a specific host.  For example, assume that you are teaching EECS9999, and have booked machines ea01 through ea10.  You want to restrict "cse1234" to logging into host "ea01", "cse5678" to logging into "ea02", but your other students "cse91011" and "cse91112" can login to any other ea host.  To do this, create ///eecs/course/9999/users.allow.ea01// and put in it:

  cse1234

Create ///eecs/course/9999/users.allow.ea02// and put in it:

  cse5678

Create ///eecs/course/9999/users.allow// and put in it:

  cse91011
  cse91112

If you want to allow access to your test to only users who are enrolled in your course, then you can extract this information from the distribution list prior to your test.  For example:

<code>
% awk '{ print $1 }' /eecs/dept/dist/EECS9999 | grep -v "<NO-CS-ACCT>" > /eecs/course/9999/users.allow
% chmod 644 /eecs/course/9999/users.allow
</code>

If you wish to test whether a user will be able to login during your lab booking, you can use the //pcmode-allow// command.  This is the identical command used by the system during login to verify whether a user should be able to access a given machine. For example, assume that your booking has ID 6 (as per the pcmode schedule), and you want to check whether a user "cse1234" will be able to login to "ea01" during your test.  Execute the //pcmode-allow// command as follows:

  % /xsys/pkg/pcmode/bin/pcmode-allow cse1234 6 ea01

Proper responses will be one of:

  * user cse1234 does not meet pcmode access restrictions in /eecs/course/9999/users.allow for host ea01 id 6 and cannot login.
  * user cse1234 does not meet pcmode access restrictions in /eecs/course/9999/users.allow.ea01 for host ea01 id 6 and cannot login. 
  * user cse1234 meets pcmode access restrictions in /eecs/course/9999/users.allow for host ea01 id 6 and can login. 
  * user cse1234 meets pcmode access restrictions in /eecs/course/9999/users.allow.ea01 for host ea01 id 6 and can login.
  * warning: found no system readable restriction file for id 6 - everyone will be allowed access
  * [if cse1234 was in either group tech/faculty/submit]: user cse1234 is a member of a system group exempt from pcmode access restrictions for host ea01 id 6 and can login.
  
NOTE:

  * Users who are in the tech, faculty, and submit system groups are automatically exempt from login restrictions.  These users do not need to be included in your //users.allow// file.
  * If you have an empty //users.allow// file, then nobody can login (except as indicated above).
  * If your users.allow file is missing, this has the same effect as no restriction at all - anyone can login.
  * //users.allow// and //users.allow.<HOSTNAME>// files are totally independent.  If a //users.allow.<HOSTNAME>// file exists for a host, it will always be used instead of //users.allow//.
  * If a student was forgotten from //users.allow// or a guest student showed up, you may edit //users.allow// during the booking to correct the issue.
  * The permission of the //users.allow// file is **very** important.  It **must** be readable by the system.  For example: chmod 644 //users.allow//. If you make the //users.allow// file writable by submit group, then your TA (who would normally be in the submit group) should be able to fix any last minute mistakes during the lab session.
  * At this time, users restrictions are available for Labtest or Linux modes, but not Windows.
  * Please note that if you enable user restrictions on your booking, you need to be **extra careful** to ensure proper syntax in //users.allow//, and that your //users.allow// file includes ALL users who need to login.  TAs need to be aware of user restrictions so that they do not panic if a student is unable to login.