Differences

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

--- services:labtest:start [2025/02/13 10:39] – jas
+++ services:labtest:start [2025/04/02 13:53] (current) – jas
@@ Line 319: / Line 319: @@
 # <optional description>
 #version: <optional labtest version name>
-MM/DD/YYYY  HH:MM M labtest <HOSTSPEC>
+MM/DD/YYYY  HH:MM M labtest HOSTSPEC
-MM/DD/YYYY  HH:MM M default <HOSTSPEC>
+MM/DD/YYYY  HH:MM M default HOSTSPEC
 </code>
@@ Line 329: / Line 329: @@
   * 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:
@@ Line 381: / Line 381: @@
 </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 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 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>
@@ Line 423: / Line 423: @@
 </code>
-...  or you can create one long session 9:00 AM - 11:00 AM, but you will have to clear the lab manually between sessions yourself:
+...  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:
 <code>
@@ Line 1093: / Line 1093: @@
 In this section, we will configure labtest to provide secure access to an eClass quiz.
-===== 1.  Allow lab machines to access eClass in labtest mode =====
+===== 1.  Allow Lab Machines Limited Access To eClass In Labtest Mode =====
-First, you need to allow the lab machines limited access 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:
@@ Line 1115: / Line 1115: @@
 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>
@@ Line 1136: / Line 1142: @@
 <code>
-eclass.yorku.ca/mod/quiz?id=ID
+eclass.yorku.ca/mod/quiz/view.php?id=ID
 </code>
@@ Line 1303: / 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 1576: / 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.