#
MM/DD/YYYY HH:MM M labtest
MM/DD/YYYY HH:MM M default
... where:
*
# labtest1-LAB1
06/20/2023 09:54 5 labtest ea 01-78
06/20/2023 11:45 5 default ea 01-78
Description:
* On June 20, 2023 at 9:54 AM, machines ea01-ea78 in las1006 will display (to logged in users) a warning that the machines will reboot in 5 minutes into labtest mode. The machines will remind students once per minute until the 5 minutes have elapsed.
* The machines will reboot into labtest mode at 9:59 AM, so they should be ready by 10:00 AM.
* On June 20, 2023 at 11:45 AM, machines ea01-ea78 in las1006 will display (to logged in users) a warning that the machines will reboot back to Linux mode in 5 minutes. The machines will remind students once per minute until the 5 minutes have elapsed.
* 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.
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.**
# labtest1-LAB1 MAIN
06/20/2023 09:54 5 labtest ea 01-70
06/20/2023 11:45 5 default ea 01-70
# labtest1-LAB1 ACCOMMODATION - 5 machines getting extra hour
06/20/2023 09:54 5 labtest ea 71-75
06/20/2023 12:45 5 default ea 71-75
# labtest1-LAB1 ACCOMMODATION - 2 students getting extra 30 minutes
06/20/2023 09:54 5 labtest ea 76-77
06/20/2023 12:15 5 default ea 76-77
# labtest1-LAB1 ACCOMMODATION - 1 student getting extra 20 minutes
06/20/2023 09:54 5 labtest ea78
06/20/2023 12:05 5 default ea78
**Remember - you 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.
Two labtests in one booking (9 AM - 1 PM) - you have to clear the lab between sessions yourself:
# labtest1-LAB1 and LAB2
06/20/2023 08:55 5 labtest ea 01-78
06/20/2023 12:55 5 default ea 01-78
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):
# labtest1-LAB1
06/20/2023 08:55 5 labtest ea 01-78
06/20/2023 10:54 5 default ea 01-78
# labtest1-LAB2
06/20/2023 11:00 0 labtest ea 01-78
06/20/2023 12:55 5 default ea 01-78
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.
If you have any questions about labtest booking, please mail the technical team.
====== On the Day of Your Labtest ======
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.
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 ======
In order to setup a basic labtest, you must complete the following 4 basic steps:
===== 1. Create Directories =====
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/9999A
Now create a subdirectory in the course web directory called "labtest":
mkdir /eecs/dept/www/course/9999A/labtest
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:
mkdir /eecs/dept/www/course/9999A/labtest/test1
mkdir /eecs/dept/www/course/9999A/labtest/test2
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".
==== Basic Start Page ====
Here's a very basic example of a labtest start page:
EECS1234
Welcome to the labtest for EECS1234
You could write a lot of introductory stuff here, or even write your question using HTML on this page.
Click here for your labtest question.
You could include links to other resources on this page that could be available in labtest.
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.
==== eClass Quiz Start Page ====
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:
Redirecting you to eClass. If you are not redirected in 5 seconds, click here.
NOTE: Replace "12345" with the quiz ID of your eClass quiz.
===== 3. Create and/or Install Additional Content =====
Create additional HTML pages to be part of your labtest, copy in images, PDFs, etc.
Note: "/" in a link refers to your labtest web directory. Links that do not start with a "/" refer to files/directories in the current directory. Links may never start with "http:" as external web links will not be accessible in labtest mode.
===== 4. Fix File and Directory Permissions =====
The web server serving your files is running as user labtest and group labtest. All faculty are in group labtest. Ensure that files and directories are accessible by group labtest so that the web server can serve them.
Make sure that your course directory is accessible to the labtest user:
chmod 755 /eecs/dept/www/course/9999
Make sure that your labtest directory is group labtest:
chgrp -R labtest /eecs/dept/www/course/9999/labtest
Make sure that your labtest directory is ONLY accessible to you and group labtest:
chmod 750 /eecs/dept/www/course/9999/labtest
Ensure that your index.html is readable by group labtest. For example:
chmod 640 /eecs/dept/www/course/9999/labtest/index.html
You will also want to make sure the other files and directories inside your labtest folder are only readable by group labtest.
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.
====== Enable or Disable your Labtest ======
Two simple commands have been created that assist you with enabling or disabling your labtest web page.
===== ltenable =====
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.
For example, to fix permissions on the labtest directory /eecs/dept/www/course/9999/labtest:
ltenable /eecs/dept/www/course/9999/labtest
All files and directories will be group labtest, and mode 770.
===== 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 ======
During labtest, your students will submit their work using one of two methods:
* [[services:submit:cli-submit|Command line submit]]
* [[services:submit:websubmit|Web Submit]]
NOTE: Users who are logged in using the generic "user" account can submit using only web submit.
===== 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:
1. Create and set permissions on a "submit" directory in your course directory:
mkdir /eecs/course/9999/submit
chmod 755 /eecs/course/9999/submit
2. Create a lab submission directory inside the "submit" directory and set permissions accordingly:
mkdir /eecs/course/9999/submit/lab1
chmod 770 /eecs/course/9999/submit/lab1
chgrp labtest /eecs/course/9999/submit/lab1
**IMPORTANT** Students will **only** be able to submit in labtest mode to lab submission directories that are group labtest.
NOTE: If you get an error when trying to change group ownership of the lab submission submit directory to group "labtest", please contact tech.
===== Submission =====
In labtest mode, students can submit their work via the command line like this:
submit
% awk '{ print $1 }' /eecs/dept/dist/EECS9999 | grep -v "" > /eecs/course/9999/users.allow
% chmod 644 /eecs/course/9999/users.allow
===== Restriction Type: Allow Multiple Users to Custom Hosts =====
With this restriction type, you provide a list of usernames allowed to login to particular hosts.
Place a file called //users.allow.
ea01,bob
ea02,sally
When ea01 boots, in addition to the "RESERVED" banner on the login screen, a message will appear on the screen:
Reserved For: Bob Smith
User bob's full name is read from the system.
When ea02 boots, in addition to the "RESERVED" banner on the login screen, a message will appear on the screen:
Reserved For: Sally Mojo
User sally's full name is read from the system.
User "bob" can only login to ea01. User "sally" can only login to ea02.
The //users.allow.byhost// file may also contain an optional "#include" directive. For example:
#include /eecs/course/9999/users.contest
#include /eecs/course/9999/otherusers
A few important notes:
* If you have a //users.allow.byhost// file, any //users.allow// or //users.allow.
cd /eecs/dept/www/course/9999/labtest/ltinit
mkdir -p a1
chmod 750 a1
cp ~/a1/a1.java a1
chmod 640 a1/a1.java
chgrp -R labtest ltinit
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.
====== Custom Shell Script Execution on User Login (optional) ======
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/
#!/bin/sh
cp -r ~/ltinit/a1 ~
Now let's assume you have a zip file called "project.zip" in /eecs/dept/www/course/9999/labtest/ltinit. You want to create a directory called "project" in the users home directory, and unzip project.zip into this directory. You would create /eecs/dept/www/course/EECS9999/labtest/ltinit/labtest.sh containing:
#!/bin/sh
mkdir ~/project
cd ~/project
unzip ~/ltinit/project.zip
In order to ensure that labtest.sh is executed when the user logs in, you must set the correct file group and permission. The file must be group labtest, and readable and executable:
chgrp labtest /eecs/dept/www/course/9999/labtest/ltinit/labtest.sh
chmod g=rx /eecs/dept/www/course/9999/labtest/ltinit/labtest.sh
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:
#/bin/sh
PATH=/eecs/local/bin:$PATH; export PATH
code --install-extension ~/ltinit/myextension.vsix
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.
====== 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.
Labtest provides two methods for you to allow access to external hosts:
* Host Level Access Control
* Host and URL Level Access Control
===== Host Level Access Control =====
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.
Create a file called "labtest.allow" in your labtest web directory (/eecs/dept/www/course/
www.w3schools.com
validator.w3.org
www.testing.com 8080
Ensure that the labtest.allow file is readable by group labtest:
chgrp labtest /eecs/dept/www/course/9999/labtest/labtest.allow
chmod g=r /eecs/dept/www/course/9999/labtest/labtest.allow
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 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.
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.
** CAUTION * CAUTION * CAUTION * CAUTION **
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.
** CAUTION * CAUTION * CAUTION * CAUTION **
Note: You do not need to specify hosts required for PassportYork authentication or Duo MFA as these are automatically added.
===== Host and URL Level Access Control =====
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.
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.".
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 https://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:
www.w3schools.com
Now you need to specify the URL fragments to accept:
+www.w3schools.com/html
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.
Now, our labtest.allow file only contains these two lines:
www.w3schools.com
+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:
www.w3schools.com
+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.
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:
-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.
A few important notes:
1) 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.
2) 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).
3) Reject fragments are processed before accept fragments. The moment a match is found, processing stops.
4) You need to accept not only the pages that the student will view, but the pages required to display the web page properly.
5) 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.
==== eClass Quiz ====
Now that you've seen a basic example of how to restrict access to specific URLs in labtest, let's look at one additional example - eClass. eClass is the name of the Moodle-based Learning Management System (LMS) used at York University. Many faculty want to use eClass quizzes from within labtest. This poses a few problems. First, students can upload files to the platform before a quiz, and access those files during the quiz. During a quiz, students have access to all materials posted on their course eclass site which may include materials that a faculty member would not want the students to access during a quiz. In addition, students have access to materials from other courses they are taking as well. As each student would be taking different courses, the faculty member may not be aware of which materials the student has access to during their quiz. Finally, students have access to eclass forums, and messaging during a quiz. Using labtest Host and URL Level Access Control, we can alleviate some of these issues with eClass quiz.
1. Place the following labtest.allow file in your course labtest web directory (/eecs/dept/www/course/labtest/labtest.allow):
eclass.yorku.ca
+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
dm7crvy4e45rz.cloudfront.net
+dm7crvy4e45rz.cloudfront.net
cdn.jsdelivr.net
+cdn.jsdelivr.net
www.googletagmanager.com
+www.googletagmanager.com
fonts.googleapis.com
+fonts.googleapis.com
Ensure that the file is readable: chmod 644 /eecs/dept/www/course/COURSE/labtest/labtest.allow
2. Your labtest start page (eg. /eecs/dept/www/course/
Tue Feb 21 15:31:24 EST 2006 user: bob, host: ea05, question: 2.html
Tue Feb 21 15:34:14 EST 2006 user: bob, host: ea06, error: user assigned question 2.html, but machine question is 1.html
The first log entry here says that user "bob" was assigned question 2.html on ea05. The user bob then tried to login a few minutes later to ea06 to see if he could get a different question set! The second log entry shows that bob tried to view the question set assigned to ea06, but was denied. In the event that bob's machine malfunctions, logging into another machine will give bob a message that tells him which other machines are assigned his identical question.
The "map" directory (which will also be initially blank) will contain one file per user with the name of the user who has successfully been assigned a question set by SecureQ. The file will only contain the filename of the question set that the user has been assigned. For example, in the case above, "map/bob" exists and contains:
2.html
This means that bob was assigned question set "2.html". Again, if bob tries to login to any other machine that has not been assigned to 2.html, he will not be able to see the questions there.
NOTE: If, during the test, you need to have the user assigned a different question set, you can modify the students map file "map/bob" manually, and adjust it to point to another question, but be careful because if you make a typo, bob won't be able to get any question! Alternatively, you can delete the map/bob file altogether, and now bob can login to any machine and will be assigned the question set assigned to that machine.
All files and permissions are automatically generated by the mksecureq utility. Furthermore, a .htaccess file is placed in the secureq directory which denies web access to the files and directories. An .htaccess file is also placed in the root of your labtest site which limits access to your labtest based on your access specifications.
If you happen to delete a file from the SecureQ tree, you can simply re-run mksecureq. It will only create files or directories that do not exist.
**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.
===== SecureQ Security =====
SecureQ will only work from EECS department machines. If you try to use SecureQ from outside of the department, you will get a message as follows:
secureq is not available from this host.
The secureq directory must retain its 770 mode, and group labtest ownership, or SecureQ will not run.
A secureq.cgi wrapper file is copied to your top-level labtest directory. It must not be deleted, or SecureQ will not run. It exists mostly so that when you are testing your site in your own personal web area, the web server can run SecureQ as you. The script must be owned by you, and your primary unix group (eg. faculty). The script file must be mode 755, and the directory that the script file is in must not be writable by group/other.
Inside the secureq directory, the internal directories log, map, and questions should retain their 770 mode, and group labtest. The files in the "log", and "map" directories will always be generated with mode 660, and group labtest. The question files and question configuration files in the questions directory will be mode 640, and group labtest.
**IMPORTANT TO CLEAR LOGS/MAPS BEFORE A TEST**
\\
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 File Synchronization (ltsave) ======
During labtest, student home directories are stored locally on the machine where each student is working. Lab machines will send a compressed copy of each local labtest home directory to the file server under these circumstances:
* Every time a user logs out of a machine that is in labtest mode.
* Every time a machine is restarted that is in labtest mode.
* Every 15 minutes when a machine is in labtest mode. (In order to ensure that not all machines are sending data to the file server simultaneously, each machine will choose a random time to synchronize for the first time within the first 4 minutes, and will then syncronize every 15 minutes thereafter.)
Accessing ltsave data might be helpful for a number of reasons, including:
* Monitoring student progress during a test.
* Retrieval of forgotten submissions.
* Enabling students to move between machines during a test.
===== Accessing Ltsave Data (ltrestore) =====
Use the //ltrestore// command to access saved user labtest data.
Usage is as follows:
ltrestore - view all saves for in
ltrestore - restore data
Let's say your student "bob" forgot to submit a file "labtest1.zip" in the labtest for course EECS9999. First, let's see what data is available to restore for user "bob" in EECS9999 labtests:
% ltrestore 9999 bob
Available restore points:
9999 bob 134 ea02 02-08-2024-10:11:13
9999 bob 134 ea02 02-08-2024-10:26:27
9999 bob 134 ea02 02-08-2024-10:41:41
9999 bob 134 ea02 02-08-2024-10:56:54
9999 bob 134 ea02 02-08-2024-11:12:09
9999 bob 134 ea02 02-08-2024-11:27:23
9999 bob 134 ea02 02-08-2024-11:42:38
9999 bob 134 ea02 02-08-2024-11:50:23
We can see that there are actually 8 different restore points! However, all we really care about is the last one. Simply run ltrestore again, and this time paste in the data from the last line above:
% ltrestore 9999 bob 134 ea02 02-08-2024-11:50:23
Creating /cs/home/jas/ltrestore
Creating /cs/home/jas/ltrestore/9999-bob-134-ea02-02-08-2024-11:50:23 ...
Restoring /eecs/ltsave/course/9999/134/ea02/bob/02-08-2024-11:50:23.txz ...
Done.
Now, all you need to do is change into the newly created "ltrestore" directory in your home directory, and you'll find the restored user data:
% cd ~/ltrestore
% ls
9999-bob-134-ea02-02-08-2024-11:50:23/
% cd 9999-bob-134-ea02-02-08-2024-11:50:23/
% ls
Desktop/ eclipse-workspace/ ltinit/ mail/
Now let's search for the file "labtest1.zip":
% find . -name "labtest1.zip"
./ltinit/labtest1.zip
We found it! The file could be restored.
If necessary, you can restore multiple restore points as well:
% ltrestore 9999 bob 134 ea02 02-08-2024-10:11:13
...
% ltrestore 9999 bob 134 ea02 02-08-2024-10:26:27
...
% ltrestore 9999 bob 134 ea02 02-08-2024-10:41:41
...
===== Location of Ltsave Data =====
Faculty have direct access to the ltsave data in the /eecs/ltsave directory on EECS tech-supported Linux systems. While it is easier for Faculty to use the //ltrestore// command to restore student data, they also have direct access to the data in the filesystem if they choose.
The path right up to the student files will look like this:
/eecs/ltsave/course/
% tar --force-local -tf /eecs/ltsave/course/9999/103/ea01/jas/11-11-2014-17:28:40.txz
./
./.cshrc
./file1
./file2
./file3
NOTE: The --force-local option is required because tar considers files with a : in their name to be on a remote server.
===== Extracting Files From an Ltsave Archive =====
You can extract all the files from an ltsave archive like this:
% cd /tmp
% mkdir restore
% chmod 700 restore <- ensure the privacy of the restore directory
% tar --force-local -xf /eecs/ltsave/course/9999/103/ea01/jas/11-11-2014-17:28:40.txz
% ls
file1 file2 file3
You can also selectively extract files as well:
% tar --force-local -xJf /eecs/ltsave/course/9999/103/ea01/jas/11-11-2014-17:28:40.txz ./file1
NOTE: If you will be extracting multiple student submissions, be sure to extract each submission into a different directory. Otherwise, files and directories from one submission may over-write the files and directories with subsequent restores.
NOTE: It is significantly easier to use the //ltrestore// command to restore student data instead of using //tar// directly.
===== Retention =====
Ltsave data that is copied to /eecs/ltsave **will be saved for 60 days ONLY** after which it is deleted, and not recoverable. **Labtest data is NOT backed up as part of our daily backup routine.**
====== Moving Students from One Machine to Another ======
Sometimes, during labtest mode, you may require a student to move from one machine to another machine. This may be because the student is in the wrong area of the lab, or because there is some failure on the machine (eg. monitor). Labtest home directories are stored on the local machine, and not a network drive. Moving a student to another machine without some mechanism to copy student files from one machine to the other would mean starting with a brand new home directory, no files, and an unhappy student!
When a student moves from one machine to the another, and logs in, the system will check if the student has files from another machine stored in the labtest save cache. If they do, the student will see the following message: "Welcome! It seems you have worked on this labtest on another machine. You may ask one of the test supervisors for approval to transfer your work to this machine, or, hit Cancel to start again.". At this point, if the student hits "Cancel", then they are logged in with a new environment without restoring their files. If they want to restore their files from another machine, they need either **your** or your TAs approval!
To restore a students files from another machine, you will need to enter 3 pieces of information -- Labtest Admin (userid), Password, and Restore Machine. Select the labtest admin from the dropdown list. The labtest admins are specified by you when you request labtest mode. The admins are also displayed in the pcmode schedule. It's important that you check the list of admins before every labtest because neither the lab monitor nor tech staff will be able to restore a students files. After selecting your name from the admin list, enter your system password. Next, under "Restore Machine", a dropdown box lists all the machines where the student has been. Select a machine from which you wish to restore the students files, and click "OK".
After the system has verified your identity, the next screen will give you a list of all the last (up to) 15 date and times of syncs made from this students account on the selected machine. For simplicity, the most recent sync will be first. Select the date and time fo which you wish to restore the students files, and click "OK". The files will be restored.
Hit "Cancel" to return back to the main menu to select a different machine.
Every (approximately) 15 minutes in labtest mode, a copy of the student files are stored in the ltsave cache. In addition, every time a student logs out, or a machine is rebooted, a sync is also performed. Please note that if a machine seems totally hung, you can try the key sequence CTRL-ALT-BACKSPACE. This kills the X session which will immediately sync the students files to the ltsave cache as well. If you see the login screen again, you will know that the students files have been synced. On the other hand, if the machine is REALLY hung, and won't respond to any input, then the only way to sync the student files to the cache is to turn the machine off and back on. Once the machine boots up, the students files will be synced.
Students should always be made aware that they should be saving their files on a regular basis. If a machine crashes, and the student has not saved their files, obviously they won't be able to get them back.
Finally, keep in mind that if your labtest is using your own custom scripts that verify which machine a student is logging in to, and and will not allow a student to submit from more than one location, you may need to make manual adjustments to make this work.
If you have any questions, please feel free to e-mail tech.
====== Extending a Labtest ======
You can extend the time on a labtest for up to 2 hours using the pcmode webapp.
Login to the pcmode webapp here:
https://webapp.eecs.yorku.ca/pcmode
Presently, only faculty, grads, and tech staff can login.
Once you login, you will see a list of active jobs in the "Active Bookings" section that you are able to control. If there is more than one active booking, you will be able to select which booking you wish to control.
In the second part of the screen, you will see some basic booking details (date and time for the booking, mode, and hosts). This table is not meant to contain all the details of the booking. It is meant to list the basics to help to distinguish one booking from another.
Finally, in the last part of the screen, you will see the "Booking End Time by Host" table. This table will give you a list of all hosts that are part of this booking, and show you the current "End Time" for each host which will be either the real booking end time, or the extended time. If a booking has been extended for, the "Extended By" column will show who extended the booking. There will be one line in this table per host.
The screen looks like this:
{{:services:labtest:extend1.jpg|}}
===== Extending a Booking =====
1. Hit the "View Schedule" button and view the pcmode schedule to ensure that your booking extension will not conflict with the next scheduled booking.
2. Check off the hosts that you wish to extend in the "Booking End Time by Host" table.
3. Select the duration of the extension from the "Extension" drop-down box. You can extend the booking from anywhere between 5 minutes and 2 hours.
4. Press the "Extend" button. Your booking will be extended for the selected hosts. The "Booking End Time by Host" table will show the new end time for the selected hosts. It will also show who extended the time under the "Extended By" column.
**Please note:** When you extend a booking, you are always extending it from the original end booking time. That is, if you extend your booking for 5 minutes two times in a row, you will only be extending the booking 5 minutes, and not 10 minutes.
If the end time comes for any part of your booking, the checkbox in the "Select" column will be replaced with the word "DONE", and you will no longer be able to control that part of the booking.
===== Canceling a Booking Extension =====
1. Check off the hosts for which you wish to cancel the time extension.
2. Press the "Cancel Extension" button. The extended time on the selected hosts will be canceled.
====== Setting Up Deferred Exams ======
Deferred exams for a course are normally run in the following term. For example if an exam is deferred from the winter term, the students will probably write the deferred exam at the start of the summer term. By this time, /eecs/course has changed to point to the current term. In the current term, the course directory may be owned by different faculty, or the course may not even be taught.
When you book your deferred test, please provide to tech a session, term, and course. When machines are placed into labtest mode, /eecs/course/COURSE will be pointing to your course directory from the previous session, and term, so submit will work perfectly fine. Your course labtest web folder from the previous session and term will be mounted to /eecs/dept/wwww/labtest.
For example, assume that the current session in 2016-17 summer. The course is 2031. A deferred test is to be held for 2031 from the winter term. Follow these steps:
1. Create a submit directory for your deferred exam:
% cd /eecs/dept/course/2016-17/W/2031/submit <- you already have this directory from the previous session and term
% mkdir final <-- you can call your submit directory anything you like.
% chmod 770 final
% chgrp labtest final
2. Configure your labtest questions:
% cd /eecs/dept/www/course_archive/2016-17/W/2031/labtest <- web folder from the previous term.
Modify index.html for your new test.
Instruct your student to submit like this:
submit 2031 final filename
^---- or whatever name you chose.
3. E-mail tech to schedule your deferred exam. Be sure to let them know that this is a deferred exam. Provide them with the session, term, and course to ensure that the proper directories are mounted during your test.
4. Once tech has scheduled your deferred exam, consult the [[http://www.eecs.yorku.ca/schedule/pcmode|schedule]] and get your test ID. Please arrange to test your test. See the section entitled "Testing Your Labtest" for more details.
If you have any questions, please consult with tech.
====== Testing Your Labtest ======
Testing your labtest from a student account is extremely important. It will help you uncover and correct any potential problems with your test including file and directory permissions, verification that all links are working, etc. It will avoid having to deal with these problems on the day of your labtest, ensuring a much smoother labtest experience for both you and your students.
There are two ways to test your labtest:
* Labtest Cloud
* Lab System
===== Labtest Cloud (LTCloud) =====
Labtest Cloud is the most ideal solution for testing your labtest at the university, or even remotely. To access Labtest Cloud, you need to have:
* An EECS account
* A labtest Pcmode ID
* Tech must have enabled your EECS account with Labtest Cloud access for the given labtest ID (this will happen automatically for Faculty).
Access the Labtest Cloud URL here:
* https://webapp.eecs.yorku.ca/ltcloud?id=
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.
If the Labtest Cloud web connection doesn't work for you, or if you prefer to use a local VNC client to access the Labtest Cloud, then please click the "Toggle Connection Details" button. This will reveal the VNC connection details including hostname, port (always 5900), and password. You can use these details to connect to the Labtest Cloud directly from your local computers VNC client. If you are on a MAC, click on the vnc URL which should open the local VNC client. If you're on a Windows PC, you can use the VNC client in [[https://mobaxterm.mobatek.net/|MobaXterm]] or [[https://www.realvnc.com/en/connect/download/viewer/|RealVNCs VNC Viewer]].
When you're done with your Labtest Cloud instance, please be sure to logout. This ensures that your cloud instance will be free for someone else to use. To logout, click the small arrow at the top right corner of the screen, click on "Labtest Student", then "Logout". You can also double click the "Logout" icon on the desk. Your Labtest Cloud session will be terminated after 30 minutes of inactivity, or when you log out of the system. All files will be lost at that time. Note that if you close the Labtest Cloud window without logging out, someone will have to wait for your session to timeout before the host is available for use again.
===== Lab System =====
The next best way to test your labtest is on a lab system. Consult with tech, and we will place a lab system into labtest mode for your test at a specific scheduled date and time. Unless you are connecting hardware directly up to the lab machine, it's always preferable for you to use Labtest Cloud instead.
====== Labtest under Windows ======
Labtest is available for limited use under Windows, but requires consultation with tech. Machines will boot first into Linux labtest mode, and then Windows will run in a [[http://www.virtualbox.org/|VirtualBox]] session. Students login to what appears to be a Linux system, but after logging in, the VirtualBox session is immediately started, and Windows boots taking over the full screen. With labtest running underneath, we get these benefits:
* A web browser is started and will display the labtest start page, much like under Linux.
* All firewall limitations on what can/cannot be done automatically restrict the Windows configuration without additional changes.
* Students have access to their standard labtest home directory including any special additions for labtest mode (eg. "unsubmit").
* Student files will continue to be synced to our server every 15 minutes.
A few present limitations:
* We do not have a specific mechanism for students to "submit" their work from Windows. However, since all student data is copied to /eecs/ltsave anyway, it can be extracted from there.
* The software base for Windows labtest is very limited right now. Software includes Java, Eclipse, Firefox, and some other limited applications. If you need a particular application under Labtest for Windows, please consult with tech.
* VirtualBox image files are distributed to each of the local machines, but the files are quite large. Since we do not create a large image PER student, the Windows image is "immutable". That is, when the student logs out, their changes to the local system are lost. Changes to their "home" directory remain.
* This functionality is not available in WSC labtest.