Differences

This shows you the differences between two versions of the page.

--- services:labtest:start [2024/02/09 12:18] – jas
+++ services:labtest:start [2025/04/02 13:53] (current) – jas
@@ Line 1: / Line 1: @@
 ====== Labtest Mode ======
-Labtest mode provides a secure computing environment for in-lab testing.  In labtest mode, students have access to the software on our systems, a course directory, and a course labtest web site, but lose access to all of the files in their home directory, sending and receiving e-mail, printing, the external web, USB key/cdrom/floppy access, existing temporary files stored on the machine, and all access to the Internet including access to other EECS machines and other York services like eClass. Students are able to submit their work.
+The purpose of this document is to provide an explanation of what labtest mode is, how to request it for your course, how to set it up, and how to check that it is setup correctly.  If you have any questions about labtest, or if this documentation is unclear to you, please contact tech.  Your feedback allows us to improve our documentation and make it easier for everyone to understand.
-The purpose of this document is to provide an explanation of what labtest mode is, how to request it for your course, how to set it up, and how to check that it is setup correctly.  If you have any questions, or if this documentation is unclear, please contact tech.  Your feedback allows us to improve our documentation and make it easier for everyone to understand.
+====== Introduction ======
+Labtest mode provides a secure computing environment for in-lab testing.  In labtest mode, students have access to either all or a limited of software on EECS systems and a course specific labtest web site.  They lose access to all the files in their regular network-shared home directory, sending and receiving e-mail, printing, the external web (except as required), USB key/cdrom/floppy access, existing temporary files stored on the machine, and all access to the Internet including access to other EECS machines (except as required for services such as DNS, DHCP, etc.) and other York services like eClass (except where requested).
+Faculty schedule labtests with the EECS tech team.  A labtest reservation sometimes spans multiple computer labs depending on the number of students that will write the labtest at once.  Faculty can schedule certain machines with extra time to accommodate students with alt exam requirements.
+Prior to labtest time, faculty create a web page for their labtest.  The page is only accessible to students on machines in labtest mode for that specific course.   Faculty can use this site to post their questions (often a PDF or HTML), or to host files that the students need for their labtest  (eg. data set).  Faculty can update this page any time before or during the labtest.  Using SecureQ, faculty can provide a different labtest based on the machine name to ensure students sitting side by side write a different test.
+Several minutes prior to labtest, students using the lab machines will receive a warning message on their display that the machine will be going into labtest mode and that they need to save their files. After the grace period (default of 5 minutes), the machines will all be rebooted into labtest mode.
+Once a machine boots into labtest mode, the login screen displays a banner that indicates that the machine is in labtest mode.  If required, faculty can restrict which user can login to each host.
+When students login, they are placed in the default desktop environment. A temporary home directory that is used for their work during labtest mode will be created. A web browser will automatically open and start at the default labtest home page.  A description of labtest mode is displayed, and a disclaimer about remote monitoring.   Students click the “Start Lab Test” button, and are taken to the labtest start page for the given booking.
+Faculty can customize what happens when a student logs in to a machine.  For example, they can copy in starter code into the student directory.  A database could be initialized and pre-populated with data.  A certain application can be started automatically.
+If there is a power failure during labtest, then after power is restored, students can log back in and continue working on their labtest  (if the labtest is not over).
+If there is a hardware failure during labtest, then the student can move to another machine, and when they login, the TA will be prompted to authenticate, and the student data can be restored from anywhere they were previously working.
+During labtest, student home directory data is synchronized to a repository every 15 minutes.  Faculty can access the repository at any time and data is maintained for many months.  If students fail to submit, faculty can restore the student work from the repository.
+Students will continue to work on their labtest for the duration of the test. Students use either command line submit, web submit, or in some cases eClass to submit their completed work.
+During labtest, faculty can use remote monitoring software to monitor student screens in the lab.  They can take complete control of the student lab computer, or lock their screen. They can capture a screenshot.  They can do this all from in the lab, or from home via the web.
+A few minutes before the end of the labtest, students will receive a warning message on their display that the labtest is about to end. At the end of the labtest, all the machines are automatically rebooted and placed back into their original mode (Linux or Windows). When a machine is switched back to the standard operating mode, the temporary labtest home directories will be removed, but the final copy of the student data will be synced to the repository.
+Faculty can configure a custom list of websites that labtest machines can access during their test with complete URL control.  They can permit or reject whole websites, or even parts of a website using labtests secure proxy.
+When Faculty are using eClass quizzes in labtest, access to messaging, "private files", and other course pages are automatically blocked.  For all labtests, certain general URLs are permitted such as the ones for PassportYork or DUO Authentication.
+During a labtest, faculty can access a web interface to extend the test duration.  For example, if there is no lab booking following the labtest, but a faculty member needs to give the students 15 minutes extra due to a power failure, they can do that without involving tech.
+Faculty can test their labtest via the web using labtest cloud (ltcloud) service.  They can access ltcloud from home, or from York.  This crucial service allows faculty to develop and test their labtest in stages, as a student (ltstu).  Before ltcloud came along, labtests would frequently have problems with inaccessible files, or user errors, but now that faculty can test their test as a student, the success rate of labtest is near perfect!
+====== Labtest Setup with Labtest Assistant ======
+Setting up a labtest requires creating many files and directories on our system.  Labtest Assistant is a tool which will help you setup and manage your labtest with ease.
+===== Usage =====
+In order to setup your labtest, login to an EECS system via [[https://remotelab.eecs.yorku.ca|remotelab]], then follow these instructions:
+Open a Terminal, then start Labtest Assistant (labtest command) and pass in the concatenation of your course number and section (eg. 7777A for EECS7777A) followed by a space and then a test version name (eg. labtest1).  For example, for course EECS7777A if you're having a test that you want to call labtest1:
+<code>
+% labtest 7777a labtest1
+</code>
+NOTE: The test version name can be whatever you choose.  In this case, we chose "labtest1".  Other names might be: labtest1-lab1, labtest1-lab2, midterm, final, or whatever other name you feel describes the purpose of the test.
+After you hit enter, this is what you will see:
+<code>
+There is no directory setup for this course. Create one ([y]/n) ?y
+Creating /eecs/dept/www/course/7777A
+Creating /eecs/dept/www/course/7777A/labtest
+Creating /eecs/dept/www/course/7777A/labtest/labtest1
+Creating /eecs/dept/www/course/7777A/labtest/labtest1/index.html
+Creating /eecs/dept/www/course/7777A/labtest/labtest1/ltinit
+Creating /eecs/dept/www/course/7777A/labtest/labtest1/labtest.allow
+Would you like a submit directory to be set up for labtest1 ([y]/n) ?y
+Creating /eecs/course/7777A/submit/labtest1
+Welcome to Labtest Assistant. Type "help" for options.
+Labtest (7777A) [labtest1] >
+</code>
+Labtest Assistant recognized that no labtest had been previously setup for this course.  It created all the required labtest directories, a default labtest start page (index.html), and a directory for labtest submission.
+Now, let's edit the start page for your labtest using the gedit command:
+<code>
+Labtest (7777A) [labtest1] > gedit
+</code>
+By default, the default start page for your labtest is called "index.html".   It will be opened in a GUI HTML editor.  This makes it easy for you to edit the start page whether or not you know HTML.  If you prefer to use the "vi" text editor, use the "edit" command instead of "gedit":
+<code>
+Labtest (7777A) [labtest1] > edit
+</code>
+Modify the default page, and add your own information such as your rules for the test, and links to other content.  Change the index.html file, and customize it for your test.  By default, index.html includes a link to the file "labtest.pdf".  This file is intended to contain your labtest questions in PDF format.  If you don't want to use this filename, you can change the name to whatever you like.
+NOTE: If you're creating a labtest which points to an eClass quiz, you'll want to include a link to your quiz directly on this page.  It will look like this: https://eclass.yorku.ca/mod/quiz/view.php?id=12345 (you'll need to find the ID for your quiz)
+After you finish editing index.html, save the file.
+Now, let's upload your labtest questions (eg. "labtest.pdf") to your labtest directory.  If you have the file on your PC, you can either sftp the file to indigo.eecs.yorku.ca, or, just drag the PDF from your desktop to your remotelab window.  The file will be placed into your home directory.
+Once labtest.pdf is in your EECS home directory, use Labtest Assistant to upload it to your course labtest directory using the "put" command:
+<code>
+Labtest (7777A) [labtest1] > put labtest.pdf
+Put success.
+</code>
+Labtest Assistant will ensure that file permissions are setup correctly.
+Students will be able to submit their work to your labtest with [[https://wiki.eecs.yorku.ca/dept/tdb/services:submit:cli-submit|command line submit]] or [[https://wiki.eecs.yorku.ca/dept/tdb/services:submit:websubmit|web submit]].
+When you create a new labtest, Labtest Assistant automatically asks you if you want it to set up a submission directory for your test:
+<code>
+Would you like a submit directory to be set up for labtest1 ([y]/n) ?y
+</code>
+If you choose "y", the submission directory will be created, and enabled.  It will have the same name as your test version name (eg. "labtest1").  When students are writing a test labtest1, they will only be able to submit to a submission directory called "labtest1".
+If you are doing an eClass based labtest, you might not need students to submit anything, so you'll answer the question with "n".
+If you make a mistake, it's easy to fix:
+<code>
+Labtest (7777A) [labtest1]  > submit add
+Submit directory added.  It is enabled by default.
+Labtest (7777A) [labtest1]  > submit del
+Submit directory deleted.
+</code>
+The default labtest start page already includes a link to web submit: https://webapp.eecs.yorku.ca/submit
+Congratulations!! Your labtest is now setup!
+Once you submit your [[https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#requesting_labtest_mode|labtest booking request]] to the tech team, they will give you a custom URL which you can use to test your test in [[https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#labtest_cloud_ltcloud|Labtest Cloud]].
+===== Available Commands =====
+Labtest Assistant provides assistance in many areas of labtest setup.  Use the "help" command for more information:
+<code>
+Labtest (7777A) [labtest1] > help
+status                                       Display labtest status
+list                                         List labtest files/directories
+get <labtest-file> [<local-file>]            Download labtest file
+put <local-file> [<labtest-file>]            Upload local file to labtest
+rename <labtest-file> <labtest-file>         Rename labtest file
+delete <labtest-file>                        Delete labtest file
+edit [<labtest-file>]                        Edit labtest file (Default: index.html)
+gedit [<labtest-file>]                       Edit labtest file in GUI editor (Default: index.html)
+import <version>                             Import labtest version from current session
+import <session> <term> <course> [<version>] Import labtest from another session/term (Default version: default)
+files                                        Open labtest directory in file manager
+ltcloud                                      Open Labtest Cloud web page
+fix                                          Fix file permissions
+restore <user>                               Restore files from <user>
+clear                                        Clear the screen
+quit                                         Quit
+lock help                                    Display lock help options
+ltinit help                                  Display ltinit help options
+restrict help                                Display URL restriction help options
+submit help                                  Display submit help options
+help/?                                       Display this help text
+</code>
+A few notes:
+  * You'll see that you can not only "put" files into your labtest, but you can get them out as well with the "get" command.
+  * You can rename and delete files.
+  * If you've taught the course before, and taken the time to setup a labtest, you can use the import command to copy the entire labtest from a different course directory, even if it's from a different session or term.  If you'd like to import a test from another test you've already created this term, you can use the import command with just a version.
+  * You can use the "files" command to open up the file manager in the GUI so you can manipulate the labtest files easily.
+  * You can use the "ltcloud" command to open up a web browser and go to the Labtest Cloud page.
+  * You can use the "fix" command to check and fix all file and directory permissions in your labtest.  This is automatically run every time you exit the "labtest" command, so you don't have to run it manually.
+  * You can use the "restore" command to restore student files should they forget to submit.
+There are also a few subcommands in Labtest Assistant - lock, ltinit, restrict, and submit which will be described below.
+===== Labtest Lock =====
+<code>
+Labtest (7777A) [labtest1] > lock help
+Labtest Lock Mode Help:
+In labtest lock mode, the student is placed in a limited environment
+with no access to a terminal.  By default, the only application available
+is Firefox web browser.  Additional applications can be made available.
+lock enable                                 Enable lock mode
+lock disable                                Disable lock mode
+lock list                                   List apps in lock mode
+lock add <app> [<opts>] [<display-name>]    Add app to lock mode
+lock delete <app>                           Delete app from lock mode
+lock help                                   Display this help text
+NOTE: As there is no access to a terminal, apps must bring up a GUI.
+Example:
+Enable lock mode (by default includes Web browser access only):
+> lock enable
+Want to make Eclipse available in lock mode?
+> lock add eclipse
+Add Matlab to lock mode (requires the option -desktop):
+> lock add matlab -desktop
+DISCLAIMER: Not all applications are suitable for lock mode.  For example, VSCode
+            requires access to the terminal for compiling and debugging code.
+</code>
+===== Labtest Init =====
+<code>
+Labtest (7777A) [labtest1] > ltinit help
+Labtest Ltinit Help:
+ltinit list                                 List files in ltinit
+ltinit get <ltinit-file>                    Download file from ltinit
+ltinit put <local-file> [<ltinit-file>]     Upload file to ltinit
+ltinit rename <ltinit-file> <ltinit-file>   Rename file in ltinit
+ltinit delete <ltinit-file>                 Delete file from ltinit
+ltinit edit <ltinit-file>                   Edit file from ltinit
+ltinit help                                 Display this help text
+</code>
+Using the "ltinit" subcommand, you can get, put, rename, delete, or edit files in your labtest ltinit directory.  The files in the ltinit directory are copied to each students ltinit folder when they login.  For more information on ltinit, see [[https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#custom_file_copy_on_user_login_optional|here]].  Use of ltinit in labtest is entirely optional.
+===== Labtest Restrict =====
+<code>
+Labtest (7777A) [labtest1] > restrict help
+Labtest URL Restriction Help:
+restrict list                                List labtest URL restrictions (including line numbers)
+restrict add <restriction> [<line number>]   Add labtest URL restriction <restriction>
+restrict eclass                              Allow access to eClass (*)
+restrict delete <line-number>                Delete restriction <restriction>
+restrict edit                                Edit labtest restrictions
+restrict help                                Display this help text
+To allow access to www.w3schools.com, and validator.w3.org:
+labtest> restrict add www.w3schools.com
+labtest> restrict add validator.w3.org
+To reject one page on www.w3schools.com:
+labtest> restrict add -www.w3schools.com/html/html_editors.asp
+(*) To allow access to eClass Quiz/VPL, please read the following web page:
+https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#accessing_external_hosts_in_labtest_eclass_example
+*** Don't forget - ALWAYS test your eClass quiz using ltcloud! https://webapp.eecs.yorku.ca/ltcloud ***
+</code>
+By default, labtest doesn't permit students to access external websites.  Using the "restrict" subcommand, you can allow access to other web sites if your labtest requires it.  For more information on the restriction format, please refer to this page:
+  * https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#accessing_external_hosts_in_labtest_optional
+For eClass specific restrictions, please refer to this page:
+  * https://wiki.eecs.yorku.ca/dept/tdb/services:labtest:start#accessing_external_hosts_in_labtest_eclass_example
+Labtest restrictions are entirely optional.
+===== Labtest Submit =====
+<code>
+Labtest (7777A) [labtest1] > submit help
+Labtest Submit Directory Help:
+submit status        Display submit directory status
+submit add           Add labtest submit directory
+submit delete        Delete empty submit directory
+submit enable        Enable submission
+submit disable       Disable submission
+submit files         Open submit directory in file manager
+submit help          Display this help text
+</code>
 ====== Requesting Labtest Mode ======
@@ Line 16: / Line 305: @@
   * EECS TA user IDs (they will be able to help students move between machines in a labtest) (eg. johns, alicez, aigha) (*)
-(*) Please make sure that you **only send us EECS user IDs** - not full names, gmail, or other alternate email.  While EECS usernames should be the same as a users Passport York username, some TAs don't apply for an EECS account, and may not have one yet!  In this case, they won't be able to help your students move between machines during your test.  You can search for a users name [[https://webapp.eecs.yorku.ca/directory|here]].  If you find that your TA doesn't have an EECS account, then please recommend to them that they should e-mail tech and inquire about getting one. In this case, you can report their PPY username.
+(*) Please make sure that you **only send us EECS user IDs** - not full names, not gmail, or other alternate email.  While EECS usernames should be the same as a users Passport York username, some TAs don't apply for an EECS account, and may not have one yet!  In this case, they won't be able to help your students move between machines during your test.  You can search for a users name [[https://webapp.eecs.yorku.ca/directory|here]] or by using the "finduser" command on our system (eg. finduser abc).  If you find that your TA doesn't have an EECS account, then please insist that they e-mail tech to request an account.  In this case, you can report their PPY username so that when their account is created, it will have access as an admin to your test.
 For **subsequent** labtest bookings in your course, please always include in your booking:
@@ Line 23: / Line 312: @@
   * Course Section (eg. A)
-You do not need to include EECS faculty admin user IDs or EECS TA user IDs because these are only configured the first time.
+You do not need to include EECS faculty admin user IDs or EECS TA user IDs with subsequent bookings, **unless they change**.
-Please provide the details of your labtest booking **in this format** only, every time you book:
+Please provide the details of your labtest booking **in this format only**, every time you book:
 <code>
 # <optional description>
-MM/DD/YYYY  HH:MM M labtest <HOSTSPEC>
+#version: <optional labtest version name>
-MM/DD/YYYY  HH:MM M default <HOSTSPEC>
+MM/DD/YYYY  HH:MM M labtest HOSTSPEC
+MM/DD/YYYY  HH:MM M default HOSTSPEC
 </code>
 ... where:
-  * <optional description> is just a description of your test (eg. labtest1-LAB1)
+  * <optional description> is just a description of your test (eg. labtest1-LAB1) - it's entirely optional, and you don't need to provide it.
+  * If you have setup multiple versions of your labtest, you'll need to let us know the version name for this test.  (eg: #version: labtest1-lab1) -- if you configured your labtest to use a version name (eg labtest1-lab1), and you don't include the version name in your booking, then labtest will not display the right start page! Remember - if you don't specify a version name, a version name of "default" is automatically assumed.
   * MM/DD/YYYY - month, day, and year for your labtest (eg. 06/20/2023)
   * HH:MM - hour:minute hour of your test (note that this is impacted by the next field)
   * M - number of minutes of warnings to send to students before system will reboot (usually 5) - NOTE: If M=5, machines will REBOOT at HH:MM + 5 MIN, NOT at HH:MM
-  * <HOSTSPEC> - lets us know which hosts you want to book. <HOSTSPEC> can contain:
+  * HOSTSPEC - lets us know which hosts you want to book. <HOSTSPEC> can contain:
     * individual machines separated by commas: ea01,ea02,ea03
-    * groups of machines: ea 01-78,ptl 01-10 (all the machines between ea01-ea78, and ptl01-ptl10)
+    * groups of machines:
-    * You can even exclude machines using a -:  ea 01-78,-ea10,-ea11
+      * To specify machines ea01-ea78 use: ea 01-78
+      * To specify machines ptl01-ptl10p use: ptl 01-10
+    * You can even exclude machines using a minus (-):
+      * To include machines ea01-ea78, but exclude ea10 and ea11: ea 01-78,-ea10,-ea11
 Here's information on the machines typically booked for labtest:
@@ Line 54: / Line 348: @@
 |[[https://wiki.eecs.yorku.ca/dept/tdb/_media/services:wsclab.pdf|WSC108]]|wsc108-01 - wsc108-49|49|wsc108- 01-49|
 **NOTE:** Click on the room name to see the room layout.
+**NOTE:** The "Hosts" column refers to hosts you want to book.  The "HOSTSPEC" column tells you how to specify those hosts in your booking request.
-Please make sure that you only book a labtest in times scheduled for your lab.  You must not exceed your lab scheduled hours without consultation with tech.  If you have any question about the timing, please inquire with tech before submitting your labtest booking.
+Please only submit your labtest booking request including times **reserved for your course**.  That is, if you have reserved LAS1006 for 9:00 AM to 10:00 AM, please do not submit a labtest booking requesting 9:00 AM - 12:00 PM unless you first confirm with tech that the space can be reserved for you for the additional time that you require.
 Here's an example labtest booking to get you started:
@@ Line 62: / Line 358: @@
 <code>
 # labtest1-LAB1
+# version: labtest1-lab1
 /20/2023   09:54 5 labtest ea 01-78
 /20/2023   11:45 5 default ea 01-78
@@ Line 73: / Line 370: @@
   * At 11:50 PM, machines will reboot from Labest mode back to Linux mode.
-**Please ensure that your labtest schedule ends 10 minutes before your lab booking.**  For example, if your lab time is 10:00 AM - 11:30 AM, then your booking should end no later than 11:20 AM.   If your lab time is 10:00 AM - 12:00 PM, then your booking should end at 11:50 PM.
+**Please ensure that your labtest ends 10 minutes prior to the end of your lab booking time.**  For example, if your lab time is 10:00 AM - 11:30 AM, then the students should receive their 5 minute warning at 11:45 AM, then the machines will reboot at 11:50 AM.
-If you have students with different accommodations for extra time, please submit a separate booking time for each accommodation type.  Here's the same booking request above with 5 machines getting an extra hour, 2 machines getting 30 minutes extra, and 1 machine getting 10 minutes extra.  **Accommodations cannot exceed your lab booking time.  In order to book machines past your lab booking time, please consult with tech.**
+If you used a labtest version name of labtest1-lab1 for this booking, you would add the additional version line to the booking request:
+<code>
+# labtest1-LAB1
+# version: labtest1-lab1
+/20/2023   09:54 5 labtest ea 01-78
+/20/2023   11:45 5 default ea 01-78
+</code>
+If you have students with different accommodations for extra time, please submit a **separate** block for each accommodation type.  Here's the same booking request above with 5 machines getting an extra hour, 2 machines getting 30 minutes extra, and 1 machine getting 20 minutes extra.  **Accommodations cannot exceed your lab booking time.  In order to book machines past your lab booking time, please consult with tech.**
 <code>
 # labtest1-LAB1 MAIN
+# version: labtest1-lab1
 /20/2023   09:54 5 labtest ea 01-70
 /20/2023   11:45 5 default ea 01-70
 # labtest1-LAB1 ACCOMMODATION - 5 machines getting extra hour
+# version: labtest1-lab1
 /20/2023   09:54 5 labtest ea 71-75
 /20/2023   12:45 5 default ea 71-75
 # labtest1-LAB1 ACCOMMODATION - 2 students getting extra 30 minutes
+# version: labtest1-lab1
 /20/2023   09:54 5 labtest ea 76-77
 /20/2023   12:15 5 default ea 76-77
 # labtest1-LAB1 ACCOMMODATION - 1 student getting extra 20 minutes
+# version: labtest1-lab1
 /20/2023   09:54 5 labtest ea78
 /20/2023   12:05 5 default ea78
 </code>
-**Remember - you labtest booking must end 10 minutes before your lab booking.**
+**Remember - your labtest booking must end 10 minutes before your lab booking.**
-If you are booking back to back labtest sessions (eg. 9:00 AM - 11:00 AM, then 11:00 AM - 1:00 PM), it doesn't make sense to bring the machines back to Linux mode between sessions.  In this case, you have to choose whether you want to just create one labtest booking for the duration of both tests or two separate labtests.  Booking one labtest is easier, but requires you to clear the lab manually between sessions (an automatic logout will not occur).  If you book two sessions, you have to be careful that the end time of the first session, and the beginning time of the next session cannot be the same.
+Notice that the start and end blocks must be grouped together.  Please do not group all the start blocks, then all the end blocks separately.
-Two labtests in one booking (9 AM - 1 PM) - you have to clear the lab between sessions yourself:
+If you are booking back to back labtest sessions (eg. 9:00 AM - 11:00 AM, then 11:00 AM - 1:00 PM), you have two choices:  You can reboot machines between sessions (this is why we end the first session 10 minutes before the end of the lab time):
 <code>
-# labtest1-LAB1 and LAB2
-/20/2023   08:55 5 labtest ea 01-78
-/20/2023   12:55 5 default ea 01-78
-</code>
-Two labtests in two separate back to back sessions.  A log out will occur at the end of the first session.  Note that the booking is really 9:00 AM - 10:59 PM, then 11:00 PM - 1:00 PM):
-<code>
 # labtest1-LAB1
+# version: labtest1-lab1
 /20/2023   08:55 5 labtest ea 01-78
-/20/2023   10:54 5 default ea 01-78
+/20/2023   10:45 5 default ea 01-78
 # labtest1-LAB2
+# version: labtest1-lab2
 /20/2023   11:00 0 labtest ea 01-78
-/20/2023   12:55 5 default ea 01-78
+/20/2023   12:50 5 default ea 01-78
 </code>
-After you have submitted your labtest booking, someone from tech will get back to you to confirm your booking.  If you don't get back a confirmation email from tech, then your session has not been booked.  You can check the latbest booking schedule [[http://www.eecs.yorku.ca/schedule/pcmode/|here]] at any time.
+...  or you can create one long session 9:00 AM - 1:00 PM, but you will have to clear the lab manually between sessions yourself:
-If you have any questions about labtest booking, please mail the technical team.
+<code>
+# labtest1-LAB1 and LAB2
+# version: labtest1
+/20/2023   08:55 5 labtest ea 01-78
+/20/2023   12:45 5 default ea 01-78
+</code>
-====== On the Day of Your Labtest ======
+After you have submitted your labtest booking, someone from tech will get back to you to confirm your booking.  If you don't get back a confirmation email from tech, then your session has **not** been booked.  You can check the labtest booking schedule [[http://www.eecs.yorku.ca/schedule/pcmode/|here]] at any time.
-Several minutes prior to your labtest, students using the lab machines will receive a warning message on their display that the machine will be going into labtest mode and that they need to save their files.  After the grace period, the machines will all be rebooted into labtest mode.
+If you have any questions about labtest booking, please e-mail the technical team.
-Once a machine boots into labtest mode, the login screen displays a banner that indicates that the machine is in labtest mode. It's a good idea for you or your TAs to have a quick visual check in the lab to ensure that all the machines are in labtest mode.
-When students login, they are placed in the default desktop environment - GNOME.  A temporary home directory that is used for their work in labtest mode will be created. A Firefox web browser will automatically open up and start at the default labtest home page. Once they read the general labtest disclaimer, they click on the "Start Lab Test" link and are taken to your labtest start page.
-Students will continue to work on their labtest for the duration of the test.  Students using their own personal accounts can use either command line submit or web submit to submit their work.  First year students using the generic "user" account can submit using only the web submit facility.
-A few minutes before the end of the labtest, students will receive a warning message on their display that the labtest is about to end.  At the end of the lab test, all the machines are automatically rebooted and placed back into their original mode (Linux or Windows). When a machine is switched back to the standard operating mode, the temporary labtest home directories will be removed. In the event of a power failure, students using their own personal accounts will be able to log back in and continue working if the power returns before the labtest session is over.  Students using the generic "user" account will lose their work in the event of a power failure.
 ====== Basic Labtest Setup ======
+Now that we've seen how to setup a labtest using Labtest Assistant, we'll look at how to setup a labtest manually.  Of course if you're using Labtest Assistant, you **do not** have to complete these steps!!
 In order to setup a basic labtest, you must complete the following 4 basic steps:
@@ Line 141: / Line 444: @@
 ===== 1.  Create Directories =====
-First, if you haven't done so yet, create a course directory for your course.  For example, if your course was "EECS9999", you would:
+First, if you haven't done so yet, create a course directory for your course.  For example, if your course was "EECS9999A", you would:
-  mkdir /eecs/dept/www/course/9999
+  mkdir /eecs/dept/www/course/9999A
 Now create a subdirectory in the course web directory called "labtest":
-  mkdir /eecs/dept/www/course/9999/labtest
+  mkdir /eecs/dept/www/course/9999A/labtest
+Inside the labtest directory, create a directory for each version of the test that you will have.  If you will only have one test version (which is the most common scenario), this directory is called "default":
+  mkdir /eecs/dept/www/course/9999A/labtest/default
+If you have a course with multiple labs at different times throughout the week, you may choose to have different test versions.  You can create a directory for each version (instead of creating the "default" directory):
+  mkdir /eecs/dept/www/course/9999A/labtest/test1
+  mkdir /eecs/dept/www/course/9999A/labtest/test2
+  mkdir /eecs/dept/www/course/9999A/labtest/test3
+NOTE: For the purposes of simplicity, this documentation will frequently refer to /eecs/dept/www/course which is a shortcut that refers to the course web directories for the current session and term. If you would like to refer to a course directory by its full path, you may use instead: /eecs/dept/www/course_archive/SESSION/TERM/COURSE.  For example, /eecs/dept/www/course_archive/2018-19/F/9999A.
+===== 2.  Create a Labtest Start Page =====
+Students will see the labtest start page when they begin your labtest.  Create an HTML start page in your "labtest" directory, and call it "index.html".
+If you have only one test version, the full path to the file might be: /eecs/dept/www/course/9999A/labtest/default/index.html
+If you have three test versions, you would have: /eecs/dept/www/course/9999A/labtest/test1/index.html, /eecs/dept/www/course/9999A/labtest/test2/index.html, /eecs/dept/www/course/9999A/labtest/test2/index.html
+==== Basic Start Page ====
-The "labtest" directory is the only "mandatory" directory.  How you choose to arrange the directory hierarchy under the "labtest" directory is totally up to you.  For example, you could create a different directory for each test:
+Here's a basic example of a labtest start page:
 <code>
-mkdir /eecs/dept/www/course/9999/labtest/test1
+<!DOCTYPE html>
-mkdir /eecs/dept/www/course/9999/labtest/test2
+<html>
+<body>
+<h1>EECS1234</h1>
+<p>Welcome to the labtest for EECS1234</p>
+<p>You could write a lot of introductory stuff here, or even write your question using HTML on this page.</p>
+<p>Click <a href="test.pdf">here</a> for your labtest question.</p>
+<p>You could include links to other resources on this page that could be available in labtest.</p>
+</body>
+</html>
 </code>
-NOTE: For the purposes of simplicity, this documentation will frequently refer to /eecs/dept/www/course which is a shortcut that refers to the course web directories for the current session and term. If you would like to refer to a course directory by its full path, you may use instead: /eecs/dept/www/course_archive/SESSION/TERM/COURSE.  For example, /eecs/dept/www/course_archive/2018-19/F/9999.
+On your start page, you can include information about the test, your rules and policies, the labtest questions (or a link to a PDF with the questions), and links to additional useful resources (such as PDFs) which you can include in your labtest directory.
+For your convenience, you may choose to provide a link to "/common" on your index page.  This link contains the Java API, and other documentation that is useful across labtests.  In non-labtest mode, the information appears [[http://www.eecs.yorku.ca/teaching/docs|here]].
+Note: You cannot include links to content outside your labtest web directory.  Your regular course directory, or other Departmental web links will not be available during labtest.
-===== 2.  Create a Start Page =====
+==== eClass Quiz Start Page ====
-Create a start page in your "labtest" directory, and call it "index.html".  Students will see this page when their test begins.  For the most minimal labtest setup, this is the only page you need!
+If you are hosting your labtest as an eClass quiz, then your start page can redirect the student to the eClass quiz page like this:
-For your convenience, you may choose to provide a link to "/common" on your index page.  This link contains the Java API, and other documentation that is useful across labtests.  In non-labtest mode, the information appears [[http://www.eecs.yorku.ca/teaching/docs|here]].
+<code>
+<!DOCTYPE html>
-Note: If you decide to have different directories in your labtest directory for each labtest, you still need to have a common index.html file.
+<html>
+<head>
+<meta http-equiv="refresh" content="5; URL= https://eclass.yorku.ca/mod/quiz/view.php?id=12345" />
+</head>
+<body>
-Note: You cannot include links to content outside your labtest web directory.  Your regular course directory, or other Departmental web links will not be available during labtest.
+<p>Redirecting you to eClass. If you are not redirected in 5 seconds, <a https://eclass.yorku.ca/mod/quiz/view.php?id=12345">click here</a>.</p>
+</body>
+</html>
+</code>
+NOTE: Replace "12345" with the quiz ID of your eClass quiz.
 ===== 3.  Create and/or Install Additional Content =====
@@ Line 181: / Line 533: @@
 Make sure that your course directory is accessible to the labtest user:
-  chmod 755 /eecs/dept/www/course/9999
+  chmod 755 /eecs/dept/www/course/9999A
-Make sure that your labtest directory is group labtest:
+Make sure that your labtest directory and all subdirectories and files are group labtest:
-  chgrp -R labtest /eecs/dept/www/course/9999/labtest
+  chgrp -R labtest /eecs/dept/www/course/9999A/labtest
-Make sure that your labtest directory is ONLY accessible to you and group labtest:
+Make sure that your labtest directory is accessible to everyone:
-  chmod 750 /eecs/dept/www/course/9999/labtest
+  chmod 755 /eecs/dept/www/course/9999A/labtest
-Ensure that your index.html is readable by group labtest.  For example:
+Make sure that each of your labtest version directories are accessible to only you and group labtest:
-  chmod 640 /eecs/dept/www/course/9999/labtest/index.html
+  chmod 750 /eecs/dept/www/course/9999A/labtest/*
-You will also want to make sure the other files and directories inside your labtest folder are only readable by group labtest.
+Make sure that your index.html is readable by group labtest.  For example:
-Be very careful with your labtest directory permission, or students may be able to access content that you do not wish to share.  If you have any doubt about your labtest directory and file permissions, please consult with tech.
+  chmod 640 /eecs/dept/www/course/9999A/labtest/default/index.html
-====== Enable or Disable your Labtest ======
+You will also want to make sure the other files and directories inside your labtest folder are also readable by group labtest.
-Two simple commands have been created that assist you with enabling or disabling your labtest web page.
+Be very careful with your labtest directory permission!  Failure to set the permission correctly could allow students to access content unintentionally.
-===== ltenable =====
+An automatic system process which runs every hour will check and fix your top-level labtest directory permission if set incorrectly.
-Run the //ltenable// command on your labtest directory in order to make all the files and directories group labtest, and readable and writable by group labtest.
+If you have any doubt about your labtest directory and file permissions, please consult with tech.
-For example, to fix permissions on the labtest directory /eecs/dept/www/course/9999/labtest:
+You can fix all labtest directory permission for your course with the "ltfix" command:
-  ltenable /eecs/dept/www/course/9999/labtest
+  ltfix /eecs/dept/www/course/9999A
-All files and directories will be group labtest, and mode 770.
+... it will ensure that the outer labtest directory is mode 755.  It will check that the internal labtest version directories are mode 750.  It will ensure that file and directory permissions specified for "user" and duplicated to group and other.
-===== ltdisable =====
-To disable a labtest so that it is not available while in labtest mode, use the //ltdisable// command.   Disabling a labtest is simply a matter of removing all but the user permissions from the labtest directory.
-For example:
-  ltdisable /eecs/dept/www/course/9999/labtest
-** NOTE: ltenable/ltdisable are for enabling or disabling the labtest web page for your course.  These commands do not modify the permission on your submit directory.  Do not run //ltenable// on your upper level course directory. **
 ====== Submit ======
@@ Line 230: / Line 572: @@
   * [[services:submit:websubmit|Web Submit]]
-NOTE: Users who are logged in using the generic "user" account can submit using only web submit.
+If they use web submit, they will be automatically logged in.
 ===== Submit Directory Setup =====
-Whether your students will be submitting via command line submit, or web submit, you must follow this procedure to setup a directory in your course directory to accept lab submissions:
+Whether your students will be submitting via command line submit, or web submit, you must follow this procedure to setup a submit directory to accept lab submissions:
 .  Create and set permissions on a "submit" directory in your course directory:
+  mkdir /eecs/course/9999
   mkdir /eecs/course/9999/submit
+  chmod 755 /eecs/course/9999
   chmod 755 /eecs/course/9999/submit
@@ Line 261: / Line 605: @@
 When your labtest is setup, it will be connected to a specific session, term, and course.  The submit command will only allow submission to the submit directory in that one session, term, and course. If you are holding a deferred test, and you need students to submit their work to the submit directory in a course directory from a previous session and term, be sure to let tech know this at the time of your booking, or submission will fail.  Read more information on command line submit [[services:submit:cli-submit|here]].
-Students can also submit using [[https://webapp.eecs.yorku.ca/submit|web submit]]. They login with their account details, select the proper assignment directory, and submit their files.  Like command line submit, the session, term, and course directory will not be switchable by the student, and must be configured at the time of your labtest booking.  Read more information on Web Submit [[services:submit:websubmit|here]].
+Students can also submit using [[https://webapp.eecs.yorku.ca/submit|web submit]].  They will be automatically logged in.  If your link to web submit includes the actual submit folder name, that submit folder will be automatically selected.  For example: https://webapp.eecs.yorku.ca/submit?assignment=labtest1
+Like command line submit, the session, term, and course directory will not be switchable by the student, and must be configured at the time of your labtest booking.  Read more information on Web Submit [[services:submit:websubmit|here]].
+===== Returning Labtest Submissions to Students Following Labtest =====
+Sometimes, following a labtest, faculty want students to be able to retrieve their labtest submission.
+In order to make this possible, complete the following steps:
+Copy the files from the labtest submit directory to a different directory - for example:
+  cd /eecs/course/9999A/submit
+  cp -pr labtest1 labtest1-return
+Make all the files in the new submit directory readable by group "submit":
+  chgrp -R submit labtest1-return
+Finally, ensure that students can only retrieve their submission, and not re-submit:
+  chmod 750 labtest1-return
+Now, when students login to web submit outside of labtest, and choose their course, they will see an assignment "labtest1-return", and will be able to retrieve their submitted files. Since the directory is not writable, the students will not be able to modify and re-upload their submission.
 ====== Unsubmit (optional) ======
@@ Line 485: / Line 852: @@
 ====== Custom File Copy on User Login (optional) ======
-If you want to be able to initialize a students labtest home directory with certain files  or directories when he logs in, simply create a directory called "ltinit" in your labtest directory (/eecs/dept/www/course/<COURSE>/labtest/ltinit).  The directory should be group labtest. ALL the files and directories in this directory readable by group labtest will be automatically copied to the ltinit directory in the student account when they login.  The files and directories will all be user readable, writable, and executable (mode 700).  Student files will never be overwritten, so if a student modifies files in the ltinit directory, and they log back in, the file will not be recopied from the server.
+If you want to be able to initialize a students labtest home directory with certain files  or directories when he logs in, simply create a directory called "ltinit" in your labtest directory (/eecs/dept/www/course/<COURSE>/labtest/ltinit).  The directory should be group labtest. ALL the files and directories in this directory readable by group labtest will be automatically copied to the ltinit directory in the student account when they login.  Student files will never be overwritten, so if a student modifies files in the ltinit directory, and they log back in, the file will not be recopied from the server.
 For example:
@@ Line 500: / Line 867: @@
 When the student logs in, he will have a directory in his home directory called "ltinit".  It will contain a directory "a1". That will contain "a1.java".
-If you are experimenting with this functionality for your course, please consult with tech. We can place a machine into labtest mode to check that your files will be copied in the way you expect.
+If you are experimenting with this functionality for your course, please consult with tech.
 ====== Custom Shell Script Execution on User Login (optional) ======
@@ Line 506: / Line 873: @@
 Labtest can run a custom shell script on login in order to initialize a student home directory.  You can use this functionality to customize the student account.  The shell script must be called "labtest.sh" and must be located in the ltinit subdirectory of your labtest web directory (/eecs/dept/www/course/<COURSE>/labtest/ltinit/labtest.sh).
-Let's assume a course of EECS9999.  Let's say you have a folder called "a1" in /eecs/dept/www/course/9999/labtest/ltinit/a1.  You want this folder to be copied directly to the users home directory (not in the ltinit subdirectory).  You would create /eecs/dept/www/course/9999/labtest/ltinit/labtest.sh containing:
+Let's assume a course of EECS9999.  Let's say you have a folder called "a1" in /eecs/dept/www/course/9999/labtest/<version>/ltinit/a1.  You want this folder to be copied directly to the users home directory (not in the ltinit subdirectory).  You would create /eecs/dept/www/course/9999/labtest/<version>/ltinit/labtest.sh containing:
 <code>
@@ Line 529: / Line 896: @@
 chgrp labtest /eecs/dept/www/course/9999/labtest/ltinit/labtest.sh
 chmod g=rx /eecs/dept/www/course/9999/labtest/ltinit/labtest.sh
+</code>
+If you are using commands from /eecs/local/bin in ltinit, please ensure that you set the PATH variable accordingly in your labtest.sh script. For example, if you were installing a custom extension for vscode, and you want to use the "code" command in your script, ensure that /eecs/local/bin is in the PATH:
+<code>
+#/bin/sh
+PATH=/eecs/local/bin:$PATH; export PATH
+code --install-extension ~/ltinit/myextension.vsix
 </code>
 If you are experimenting with this functionality for your course, please consult with tech. We can review your script with you before your test, and place a machine into labtest mode to check that it works the way you expect.
+====== Labtest Lock Mode (optional) ======
+By default, users in labtest can still use any software on our systems.  If you enable locked mode, you'll be able to restrict students to using only particular software, or even just a web browser! Use of locked mode is entirely optional.
+To enable locked mode with just a web browser only, touch the file "lock" in your labtest directory.  For example:
+  % touch /eecs/dept/www/course/9999/labtest/default/lock
+  % chmod 644 /eecs/dept/www/course/9999/labtest/default/lock
+Now if you test your labtest in ltcloud, the user will only be able to access the Firefox web browser.
+If you want additional software to be accessible in labtest, it must use a GUI.  You add to the lock file lines of the following format:
+  <app name>,<OPTIONAL app arguments>,<OPTIONAL app display name>
+For example, if you want Eclipse to be available in lock mode, you would add to the lock file:
+  eclipse
+By default, there are no optional arguments, and if no alternate display name is mentioned, then it will appear in the menu with the same name as the command name, but with the first letter capitalized ("Eclipse").
+If you want to add Matlab:
+  matlab,-desktop
+In order to run "Matlab", we have to pass "-desktop".  It would appear in the menu as "Matlab".
+On the other hand, if you wanted to include Visual Studio Code, you would add:
+  code,,Visual Studio Code
+Now, "Visual Studio Code" will be displayed in the menu, but it will execute the command "code".
+In labtest lock mode, the window environment is a little different in order to support the locked down nature of the environment.
+When labtest mode is started, a web browser will appear with the labtest start page.  Additional software will be available by right clicking the desktop, or by clicking on the "Apps & Logout" menu in the bottom left corner of the desktop.
+Please ensure that you're careful when allowing access to software in lock mode.  Giving access to additional software may have unintended side effects.  For example, if you allow access to Eclipse, then students can compile and run code which can give access to system resources that would otherwise not be available.  Access to a terminal is still blocked.
 ====== Accessing External Hosts In Labtest (optional) ======
-Your labtest may require students to access resources on external hosts.  For example, if you're teaching a course on web development, you may want your students to be able to access www.w3schools.com.  You may also want your students to complete a quiz on eclass.yorku.ca.
+Your labtest may require students to access external websites.  For example, if you're teaching a course on web development, you may want your students to be able to access https://www.w3schools.com during your labtest. You can restrict access to a complete website, or even a part of a website!  In the next section we'll even cover restricting access to an eClass quiz.
-Labtest provides two methods for you to allow access to external hosts:
+With host level access control, you can give your labtest access to specific websites such as https://www.w3schools.com.  Students will be able to access any URL on the given sites.
-  * Host Level Access Control
+Let's say you're teaching a course EECS9999, and you want students in your labtest to be able to access "https://www.w3schools.com" and "https://validator.w3.org" web sites during your test:
-  * Host and URL Level Access Control
-===== Host Level Access Control =====
+**Setup With Labtest Assistant**
-With host level access control, you can give your labtest access to specific hosts such as www.w3schools.com.  Students will be able to access any URL on the given sites.
+From within Labtest Assistant, use the "restrict" command:
-Create a file called "labtest.allow" in your labtest web directory (/eecs/dept/www/course/<COURSE>/labtest/labtest.allow).  Include in this file complete hostnames or IP addresses that you want students to be able to access during your test, one per line.  You can follow each hostname or IP address with a port number if required, otherwise web ports (both 80 and 443) will be assumed.
+<code>
+Labtest (9999) [labtest1]  > restrict add www.w3schools.com
+Restriction www.w3schools.com inserted.
+Labtest (9999) [labtest1]  > restrict add validator.w3.org
+Restriction validator.w3.org inserted.
+</code>
+You can use "restrict edit" to edit the restriction list in a text editor, or "restrict list" to list restrictions.  Use "restrict help" for more information on the options that are available.
+**Setup Manually**
-For example, if you're teaching a course EECS9999, and you want students in your labtest to be able to access the complete "www.w3schools.com" and "validator.w3.org" web sites during your test in addition to being able to access www.testing.com:8080, then create /eecs/dept/www/course/9999/labtest/labtest.allow containing:
+If you are setting your labtest up manually, create a file called "labtest.allow" in your labtest web directory (/eecs/dept/www/course/<COURSE>/labtest/labtest.allow).  Include in this file complete website names that you want students to be able to access during your test, one per line.  For example:
 <code>
 www.w3schools.com
 validator.w3.org
-www.testing.com 8080
 </code>
@@ Line 563: / Line 988: @@
 </code>
-Please note that if the web site you are trying to access redirects access to another site, then you will need to allow access to both sites.
+**Please note that if the web site you are trying to access includes links to other sites that you want to work, or includes files from other sites (eg. css style file or font file), then you may need to add additional entries to your labtest.allow file.  Contact tech for assistance.**
-Please also note that if a web site name resolves to multiple IP addresses, then access will be automatically provided to all IPs.  However, if, for any reason the IPs change during the duration of the test, access will be denied.
+Labtest also makes it possible to implement partial access to a website.  For example, if you wanted your students to only be able to access https://www.w3schools.com/html during your test (and not the main page https://www.w3schools.com, or https://www.w3schools.com/css, https://www.w3schools.com/jss, etc), then you set it up like this:
-If you are experimenting with this functionality for your course, please consult with tech. We can review your labtest.allow file with you and explain how you can test it in ltcloud.
+**Setup with Labtest Assistant**
-** CAUTION * CAUTION * CAUTION * CAUTION **
+From within Labtest Assistant, use the "restrict" command again:
-Please be mindful of side effects that may be introduced by the use of this labtest functionality.  For example, by allowing external access to https://eclass.yorku.ca, you will circumvent the security of labtest because students can use Eclass to communicate with other students, access their own uploaded files, and access other course materials and other courses!    When using Eclass, consider using "Host and URL Level Access Control" instead.
+<code>
+Labtest (9999) [labtest1]  > restrict add www.w3schools.com/html
-** CAUTION * CAUTION * CAUTION * CAUTION **
+Restriction www.w3schools.com/html inserted.
-Note: You do not need to specify hosts required for PassportYork authentication or Duo MFA as these are automatically added.
+Labtest (9999) [labtest1]  > restrict list
-===== Host and URL Level Access Control =====
+	www.w3schools.com/html
+</code>
-With host and URL level access control, you not only control what web sites your students can access, but which specific URLs on those web sites they can access.
+**Setup Manually**
-You will still create a labtest.allow file which tells the labtest environment which hosts the students can access.  In addition, you will also specify in labtest.allow the details on which URL fragments will be accepted, and which will be rejected.  Accepted URL fragments start with a "+" while rejected URL fragments start with a "-". If the user enters a URL that matches one of the accepted URL fragments, then the access will be successful.  On the other hand, if the user enters a URL that matches one of the rejected URL fragments, or if the URL does not match any accepted URL fragments, the access will be denied with the following error: "Access to this URL is blocked.".
+Add "www.w3schools.com/html" to your labtest.allow file instead of "www.w3schools.com" alone.
-It is best to demonstrate host and URL level access control with an example.  If you wanted your students to only be able to access www.w3schools.com/html during your test (and not the main page www.w3schools.com, or www.w3schools.com/css, www.w3schools.com/jss, etc), then, as before, your labtest.allow file will start off looking like this:
+Now, during your labtest, if you try to visit anything but "https://www.w3schools.com/html", you will receive an error: "Access to this URL is blocked.".
-  www.w3schools.com
+However, you will also notice that the page doesn't display properly.  If you look at the page source you will realize that this is because the page is trying to access fonts from "https://www.w3schools.com/lib", and CSS from "https://www.w3schools.com/plus".  You can easily add these additional entries:
-Now you need to specify the URL fragments to accept:
+**Setup with Labtest Assistant**
-  +www.w3schools.com/html
+Once again, use the restrict command:
-Remember that a line starting with a "+" denotes an accepted URL fragment.  Here, we are accepting any URL that includes www.w3schools.com/html.  That includes, for example, https://www.w3schools.com/html.  You could also specify "+/html", and that would work as well, and is much shorter in length, but if there were other pages under www.w3schools.com containing "/html" in them (eg. www.w3schools.com/php/html/mypage.html) then they would be accepted as well.  In addition, if you had multiple hosts in labtest.allow (say, www.w3schools.com and www.validator.org), then the user would be able to access /html URLs on *either* site.  By adding www.w3schools.com to the URL fragment, we ensure that the fragment applies to just the one site.  It's always best to ensure that your accept and reject URL fragments are as detailed as possible.
+<code>
+Labtest (9999) [labtest1]  > restrict add www.w3schools.com/lib
-Now, our labtest.allow file only contains these two lines:
+Restriction www.w3schools.com/lib inserted.
-  www.w3schools.com
+Labtest (9999) [labtest1]  > restrict add www.w3schools.com/plus
-  +www.w3schools.com/html
-If you tried to visit this site in labtest mode, you would find that it doesn't look right.  This is because the HTML page refers to various image files (png,svg), fonts, javascript, css, and even a /site.webmanifest" file.  Without these files, the page simply doesn't look the way it's intended.  The labtest.allow file could be extended, and the final file would be:
+Restriction www.w3schools.com/plus inserted.
-  www.w3schools.com
+Labtest (9999) [labtest1]  > restrict list
-  +www.w3schools.com/html
-  +.png
-  +.svg
-  +/fonts/
-  +.js
-  +.css
-  +/site.webmanifest
-Visit "https://www.w3schools.com" with this labtest.allow active, and you will get an error message: "Access to this URL is blocked.".  The top level page is not permitted!  However, access https://www.w3schools.com/html and the page will show up just fine.  Click on additional buttons on the page to view the lessons under /html, and they will all work.  However, try to click on the pages outside of /html, and they will all be blocked.  Sometimes, you may need to view the source of a web page to help determine which URL fragments you may need to add to labtest.allow.
+	www.w3schools.com/html
+	www.w3schools.com/lib
+	www.w3schools.com/plus
+</code>
-Now, let's say there's a particular URL under /html that you don't want the student to be able to access.  You could add this reject rule to the labtest.allow file:
+**Setup Manually**
+Add "www.w3schools.com/lib" and "www.w3schools.com/plus" to labtest.allow.  It will now look like this:
 <code>
--www.w3schools.com/html/html_editors.asp
+www.w3schools.com/html
+www.w3schools.com/lib
+www.w3schools.com/plus
 </code>
+Now, let's say there's a particular URL under https://www.w3schools.com/html that you don't want the student to be able to access (eg. https://www.w3schools.com/html/html_editors.asp).  This can easily be handled as well:
+**Setup with Labtest Assistant**
+Again, use the restrict command:
+<code>
+Labtest (9999) [labtest1]  > restrict add -www.w3schools.com/html_editor.asp
+Restriction -www.w3schools.com/html_editor.asp inserted.
+Labtest (9999) [labtest1]  > restrict list
+	www.w3schools.com/html
+	www.w3schools.com/lib
+	www.w3schools.com/plus
+	-www.w3schools.com/html_editor.asp
+</code>
+**Setup Manually**
+Add the following rule to labtest.allow:
+  -www.w3schools.com/html/html_editors.asp
 NOTE: Rejected URL fragments are processed before accepted URL fragments.  Add this rule to the bottom or top of your labtest.allow file, and it will have the same effect.
@@ Line 621: / Line 1072: @@
 A few important notes:
-) For every host that you wish to provide any level of access to, you must include an entry in labtest.allow with the full hostname.
+) For every website that students needs to be able to access during labtest, you must either use "restrict add <site>" in Labtest Assistant to add the restriction, or manually add the restriction to the labtest.allow file.  You may include just the website name (in which case all URLs on that site will work), or you may include the URLs on that website that you want to be accessible.
-) For host and URL based access control, you must also specify accept (+) and reject (-) URL fragments.  Without this, no access to the pages will be permitted. (All pages are rejected by default).
+) All external pages are rejected by default.
 ) Reject fragments are processed before accept fragments.  The moment a match is found, processing stops.
@@ Line 631: / Line 1082: @@
 ) Always test your labtest in ltcloud every single time!  Just because your labtest.allow rules work for one test doesn't mean that the resources that you're trying to allow access to haven't changed between tests.  Testing your labtest in ltcloud ensures the smoothest experience for you and your students.
-Now that you've seen how to protect access to URLs on one web site, let's look at one additional example.  Many faculty use eclass from within labtest.  The following labtest.allow file contains the rules to limit eclass use to a quiz only.  **Your labtest page must provide a link to a specific quiz on your page which looks something like: https://eclass.yorku.ca/mod/quiz/view.php?id=XXXX**
+====== Accessing External Hosts In Labtest (eClass Example) ======
+eClass is the name of the Moodle-based Learning Management System (LMS) used at York University.  Many faculty use eClass quizzes from within labtest.  This poses a few challenging problems:
+  * Students can upload files to eClass under "Private Files" before a quiz, then access those files during the quiz.
+  * During a quiz, students have access to all course materials posted to any eClass course page where the student is registered.  The faculty member will not know what materials students can access.
+  * Students have access to eClass course forums.
+  * Students have access to eClass communication and can chat with other students.
+In this section, we will configure labtest to provide secure access to an eClass quiz.
+===== 1.  Allow Lab Machines Limited Access To eClass In Labtest Mode =====
+First, you need to allow the lab machines limited access to eClass in labtest mode.
+If you're using Labtest Assistant, use the "restrict eclass" command:
+<code>
+labtest> restrict eclass
+</code>
+If you're not using Labtest Assistant, you need to create a labtest.allow file in your labtest directory which includes the allowed URL parts for eClass:
+<code>
+eclass.yorku.ca/login
+eclass.yorku.ca/auth
+eclass.yorku.ca/pluginfile.php
+eclass.yorku.ca/theme
+eclass.yorku.ca/lib
+eclass.yorku.ca/local
+eclass.yorku.ca/repository
+eclass.yorku.ca/course/switchrole.php
+dm7crvy4e45rz.cloudfront.net
+eclass.yorku.ca/mod/quiz/startattempt.php
+eclass.yorku.ca/mod/quiz/attempt.php
+eclass.yorku.ca/mod/quiz/processattempt.php
+eclass.yorku.ca/mod/quiz/summary.php
+eclass.yorku.ca/mod/quiz/review.php
+eclass.yorku.ca/mod/quiz/autosave
+</code>
+===== 2. Determine Your eClass Quiz URL =====
+Visit your eClass quiz from your machine that is **not** in labtest mode. Grab the quiz URL from the URL bar in your web browser.  The URL will look something like this: https://eclass.yorku.ca/mod/quiz/view.php?id=12345
+You can also get this link in eClass if you go to: Activities >> Quizzes then hover your mouse over your quiz.
+===== 3. Allow Access To Your eClass Quiz ID In Labtest Mode =====
+If you're using Labtest Assistant, use the following command to allow access your eClass quiz in labtest:
+<code>
+labtest> restrict add eclass.yorku.ca/mod/quiz/view.php?id=ID
+</code>
+Replace ID with your eClass Quiz ID.
+If you're not using Labtest Assistant, add the following line to the end of your labtest.allow file in your labtest directory:
+<code>
+eclass.yorku.ca/mod/quiz/view.php?id=ID
+</code>
+Replace ID with your eClass Quiz ID.
+Ensure that the labtest.allow file is readable: <code>chmod 644 /eecs/dept/www/course/COURSE/labtest/labtest.allow</code>
+===== 4. Provide a Link to Your eClass Quiz in Your Labtest Start Page =====
+Your labtest start page (eg. /eecs/dept/www/course/<COURSE>/labtest/index.html) (or a PDF that your start page refers to) **must** include a direct link to your specific eclass quiz. You found this URL in step 2.
+If you're using Labtest Assistant, open your labtest start page using the "gedit" (GUI editor) or "edit" (text editor) commands and add a link to your eClass quiz on the page.  For example:
+<code>
+Click <a href="https://eclass.yorku.ca/mod/quiz/view.php?id=12345">here</a> to take the quiz.
+</code>
+If you're not using Labtest Assistant, open the index.html file in your labtest directory, and add the link manually.
+**IMPORTANT** If students try to access "https://eclass.yorku.ca" in their web browser during your labtest, **they will be blocked**.  Students can **only** visit your quiz by clicking on the link to the quiz from your labtest start page.
+===== 5. Restrict IP Addresses Which Can Access Your eClass Quiz From Within eClass =====
+Login to eClass.  Restrict access to your eClass quiz to the IP addresses of the lab machines where the students will be writing the quiz.  If you don't do this, even though your in-lab students will be limited in the proper way, students who are outside of the lab would also be able to write your quiz.  Go to: Activities >> Quizzes >> Settings >> Extra restriction on attempts >> Show more... >> Require network address.  Please copy and paste the specific address list below:
+^Lab Location^IP Restriction^
+|LAS1002|130.63.96.168/29,130.63.96.176/28,130.63.96.192/29|
+|LAS1002B|130.63.96.203/32,130.63.96.204/30,130.63.96.208/28,130.63.96.224/30|
+|LAS1004|130.63.96.131/32, 130.63.96.132/30,130.63.96.136/29,130.63.96.144/28,130.63.96.160/31,130.63.96.162/32|
+|LAS1006|130.63.96.48/28,130.63.96.64/27,130.63.96.96/28,130.63.96.112/29,130.63.96.120/30,130.63.96.124/31|
+|LAS2007|130.63.96.230/31,130.63.96.232/29,130.63.96.240/31|
+|WSC105|130.63.131.34/31,130.63.131.36/30,130.63.131.40/29,130.63.131.48/28,130.63.131.64/28,130.63.131.80/31,130.63.131.19|
+|WSC106|130.63.131.84/30,130.63.131.88/29,130.63.131.96/27,130.63.131.128/30,130.63.131.132/32,130.63.131.19|
+|WSC108|130.63.131.135/32,130.63.131.136/29,130.63.131.144/28,130.63.131.160/28,130.63.131.176/29|
+|LTCLOUD|130.63.94.193/32,130.63.94.194/31|
+NOTES:
+  * If you are using all 3 of WSC105, WSC106, AND WSC108, use instead: 130.63.131.0/24
+  * If you are testing in ltcloud, please ensure that you include both the IP range for the required lab followed by a comma followed by the ltcloud range.
+  * If your test is being conducted in several labs, you can join two IP ranges with a comma in between them.  Note though that if the number of IP ranges separated by commas exceeds 18, the IP restrictions will not function correctly due to an eClass bug.  Please consult with tech to test your IP range prior to your test.
-  eclass.yorku.ca
+===== 6. Limit the Start and End Time of Your Quiz in eClass =====
-  +eclass.yorku.ca/login
-  +eclass.yorku.ca/auth
-  +eclass.yorku.ca/pluginfile.php
-  +eclass.yorku.ca/quiz
-  +eclass.yorku.ca/mod/quiz
-  +eclass.yorku.ca/theme
-  +eclass.yorku.ca/lib
-  +eclass.yorku.ca/local
-  +eclass.yorku.ca/repository
-  cdn.jsdelivr.net
-  +cdn.jsdelivr.net
-  www.googletagmanager.com
-  +www.googletagmanager.com
-  fonts.googleapis.com
-  +fonts.googleapis.com
-Students won't be able to access just "eclass.yorku.ca", but they will be able to access your specific quiz.
+You will need to limit the start and end time of your quiz in eClass.  If you don't do this, then students on the lab machines will be able to access your quiz **before** your labtest!  Go to: Activities >> Quizzes >> Settings >> Timing and configure the "Open the quiz" and "Close the quiz" times.  Note that if students try to access the quiz before the open time, they will be denied because eclass will try to redirect them back to the course eclass page which has been blocked.  They should try again at the start time of your test.
-**IMPORTANT NOTES:**
+Final Notes:
-  * eclass permits students with access to various repositories such as "Private Files".  In labtest mode, repositories other than "Upload a File" will result in an "Invalid Repository ID" error.
+  * Some faculty would like to use eClass "assignment" in labtest. Note that eClass assignments do not permit IP address restriction.  A quiz with 1 question can replace an "assignment".
-  * Controlling allowed URLs is only one way to protect the integrity of your eclass quiz.    It is recommended that you protect the quiz based on start and end time, and IP addresses as well.
+  * If you're using VPL, you'll need to allow access to the following URL fragments with either "restrict add" in Labtest Assistant, or manually in your labtest.allow file:
-  * Since all of our lab PCs use different IP addresses, consult with tech if you want to block access to your eclass based on IP address.
+    * eclass.yorku.ca/mod/vpl/view.php?id=ID
-  * If you protect your eclass quiz based on start time, please note that if you have the lab machines booting into labtest mode minutes before the time of your test, then if students login early, and click on the quiz link in your index.html file, eclass will try to redirect them back to the course eclass page.  In labtest mode, eclass.yorku.ca/course is blocked, and hence the student will receive an error that the URL they are trying to access has been blocked.  Let students know that they should click on the quiz link after the quiz has been opened.
+    * vpl1.eecs.yorku.ca
+  * **Always test your eClass quiz using ltcloud!  Don't assume that just because it works fine from your unrestricted PC that it will work fine in labtest. Ensuring that your quiz works in ltcloud will guarantee an improved experience in your test session. **
 ====== SecureQ Setup (optional) ======
@@ Line 773: / Line 1309: @@
 \\
 WARNING: Before you can re-use the same secureq directory for another test, at a minimum, you must move any existing “secureq/map” directory out of the way. This directory contains files which track which question each of your students received on the test, and on what machine. This will limit which question they can receive on your new test, and on what machine they can work
+====== Labtest and Containers ======
+It may be helpful to some courses to use containers from within labtest.  This section will provide an example of downloading the latest Ubuntu image, modifying the image, and pushing the image to labtest.
+Download an Ubuntu image:
+<code>
+% podman pull ubuntu:latest
+</code>
+**NOTE:** Your EECS home directory has limited storage space and is on network storage.  **This is not ideal for working with containers.**  Faculty who have their own research servers or personal workstations can use this equipment to generate images, the result of which can be used in labtest.  Failing this, faculty can use /tmp space for **temporary** container development.  For more information, consult with tech.  For information on using containers in EECS click [[services:podman|here]].
+Start up the container from the ubuntu:latest image, and call it my-ubuntu:
+<code>
+% podman run -it --name my-ubuntu ubuntu:latest bash
+</code>
+Make changes -- in this case, we'll just add an empty file named "file", but you could install additional packages, add users or groups, and configure the system in any way you like:
+<code>
+# cd
+# touch file
+# exit
+</code>
+Now let's stop the container:
+<code>
+% podman stop my-ubuntu
+</code>
+Commit the changes in my-ubuntu container to my-new-ubuntu image:
+<code>
+% podman commit my-ubuntu my-new-ubuntu
+</code>
+Save the image to a tar file:
+<code>
+% podman save -o my-new-ubuntu.tar my-new-ubuntu
+</code>
+Place my-new-ubuntu.tar into ltinit directory in the course labtest web directory:
+In ltinit/labtest.sh we can load the image, start the container, and open up a Terminal window connected to the container:
+<code>
+podman load -i $HOME/ltinit/my-new-ubuntu.tar
+podman run -dit --name labtest my-new-ubuntu
+gnome-terminal -- podman exec -it labtest bash
+</code>
+Now, when the user logs in, the image is unpacked and loaded. Podman run starts the container.  Note the following options:
+  * -d runs it in the background (detached).
+  * -i keeps stdin open.
+  * -t allocates a pseudo-tty.
+  * --name labtest names the container labtest.
+  * my-new-ubuntu is the image used to create the container
+**NOTE:** Large container downloads with large multi lab labtests could result in performance issues since all users will be downloading the container on login.  In this case, discuss with tech how we could instead add the container to the course labtest web directory, then include an alias in the users .cshrc file which will download the image with curl or wget, load the image, and start the container.  As users will be doing this manually, and will be doing this at different times, the chance of performance issue is much less.
 ====== Labtest File Synchronization (ltsave) ======
@@ Line 1046: / Line 1646: @@
 Access the Labtest Cloud URL here:
-  * https://webapp.eecs.yorku.ca/ltcloud?id=<your labtest ID>
+  * https://webapp.eecs.yorku.ca/ltcloud
+The best way to access ltcloud is directly from a web browser when you are connected to [[https://remotelab.eecs.yorku.ca|EECS Remotelab]].
+If you want to access LTCloud directly from your home PC, you can use [[https://www.yorku.ca/uit/faculty-and-staff-services/internet-access/#vpn|York VPN]].
-Note that if you are accessing this URL from a non-EECS IP address (such as from home), you must be connected to [[https://staff.computing.yorku.ca/internet-access/secure-remote-access/|York VPN]] in order to to use the service.
 After connecting to the Labtest Cloud URL, you will be required to authenticate with your EECS username and password.  After you successfully authenticate, the system will take about 10 seconds to setup your Labtest Cloud instance.  Click on the "Connect to Labtest Cloud" button, and, right from your web browser, you'll be connected to a virtual system running labtest!  You will be logged in as "ltstu" (labtest student) which is a ugrad account.  Testing as a student is the best way to test your labtest.