Merge remote-tracking branch 'origin/main' into redactions

Author: Barb Cutler

Gemfile.lock

@@ -40,6 +40,7 @@ GEM
     faraday-net_http (3.1.1)
       net-http
     ffi (1.17.0-arm64-darwin)
+    ffi (1.17.0-x64-mingw-ucrt)
     ffi (1.17.0-x86_64-linux-gnu)
     forwardable-extended (2.6.0)
     gemoji (4.1.0)
@@ -219,7 +220,7 @@ GEM
       gemoji (>= 3, < 5)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0, < 5.0)
-    json (2.12.2)
+    json (2.13.0)
     kramdown (2.4.0)
       rexml
     kramdown-parser-gfm (1.1.0)
@@ -240,6 +241,8 @@ GEM
       uri
     nokogiri (1.16.7-arm64-darwin)
       racc (~> 1.4)
+    nokogiri (1.16.7-x64-mingw-ucrt)
+      racc (~> 1.4)
     nokogiri (1.16.7-x86_64-linux)
       racc (~> 1.4)
     octokit (4.25.1)
@@ -277,18 +280,21 @@ GEM
       concurrent-ruby (~> 1.0)
     unicode-display_width (1.8.0)
     uri (0.13.0)
+    wdm (0.2.0)
     webrick (1.9.1)
     yell (2.2.2)
 
 PLATFORMS
   arm64-darwin-22
   arm64-darwin-23
+  x64-mingw-ucrt
   x86_64-linux
 
 DEPENDENCIES
   github-pages (= 232)
   html-proofer (~> 3.19.4)
   json
+  wdm (>= 0.1.1)
   webrick (~> 1.9)
 
 BUNDLED WITH

_docs/developer/development_instructions/automated_grading.md

@@ -118,12 +118,14 @@ number:
 
 ---
 
-## Debugging 
+## Debugging
 
 To debug new features for autograding, it can be helpful to run
 `submitty_autograding_shipper.py` and `submitty_autograding_worker.py`
 interactively and inspect the output.
 
+_NOTE: A cron job runs hourly to detect autograding shipper outages on the primary machine. To avoid interference during debugging, this job should be disabled before proceeding. See [Capture Cron Error Messages](/sysadmin/installation/system_customization#capture-cron-error-messages) for instructions on disabling the script._
+
 To do this:
 
 1. Stop the daemons (on each server, as appropriate)

_docs/developer/development_instructions/migrations.md

@@ -24,7 +24,7 @@ own unique list of migrations. They are:
 * course
 
 Where `system` migrations should deal mainly with package installation/changes,
-system changes, new dependencies, etc. `master` migraitons deals with changes to the master Submitty
+system changes, new dependencies, etc. `master` migrations deal with changes to the master Submitty
 database. `course` migrations are applied individually to each course
 detected in `/var/local/submitty/courses` and can be used to adjust the
 courses' DB, config files, etc.

_docs/developer/getting_started/make_a_pull_request.md

@@ -68,7 +68,7 @@ Be sure to read the [Suggestions for New Developers](/developer/getting_started/
 
       * `Submission` (includes bulk uploads, teams, late days, notebook gradeables, and other student features),
       * `Autograding` (includes router, container/docker),
-      * `Forum`,   
+      * `Forum` (Includes Live Chat),  
       * `Notifications` (includes email and grade inquiries),  
       * `TAGrading` (includes PDF annotation, peer grading),  
       * `InstructorUI` (includes course and gradeable configuration),  

_docs/developer/getting_started/vm_install_using_vagrant.md

@@ -121,7 +121,7 @@ M-Series ARM MacOS machines.*
    * You will need:     
       * [Ruby](https://www.ruby-lang.org/en/downloads)  
       * [Git](https://git-scm.com/downloads)  
-      * [Vagrant](https://www.vagrantup.com)  
+      * [Vagrant](https://developer.hashicorp.com/vagrant/install)
       * *M-SERIES ARM MacOS:* [QEMU](https://www.qemu.org)  
       * *EVERYONE ELSE:* [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
           * Ensure VirtualBox version is compatible with Vagrant.
@@ -146,8 +146,8 @@ M-Series ARM MacOS machines.*
       ```
 
    * **Windows**  
-      *You can just go to the respective sites and download the necessary binaries.*
-
+      Download the latest Vagrant AMD64 binary for windows.
+      *As of Vagrant version 2.4.7, Virtualbox 7.1.10 is compatible.*
 
    * **Ubuntu/Debian**
 
@@ -611,3 +611,15 @@ please follow the step below:
 The script should automatically handle the upgrading and issuing a self-signed
 certificate.  If your browser complains about the security, please head to
 [WebSocket](/developer/developing_the_php_site/websocket).
+
+---
+
+## Increasing VM Resources
+If you find that the VM is running slowly, you can increase the resources allocated to it. By default the VM is allocated 2GB of RAM and 2 CPUs. You can increase these values by setting the `VM_MEMORY` and `VM_CPUS` environment variables before running `vagrant up`. For example, to allocate 4GB of RAM and 4 CPUs, you can run:
+
+```sh
+export VM_MEMORY=4096
+export VM_CPUS=4
+vagrant up
+```
+If your system has 8GB of RAM it is recommended to set `VM_MEMORY` to 4096 (4GB) and `VM_CPUS` to 2 or 4. If your system has more RAM, you can increase these values further, but be careful not to allocate too much RAM as it may cause your host system to become unresponsive.

_docs/developer/getting_started/worker_vm.md

@@ -11,36 +11,70 @@ machines* in addition to your primary vagrant virtual machine.
 
 ## Automated Worker Installation
 
-These steps will create a worker machine alongside the normal Submitty machine.
-1. Make sure to destroy any existing vagrant machines with 
-```
-vagrant destroy
-```
+1. First set up your main/primary machine by following the normal
+   [VM Install using Vagrant](/developer/getting_started/vm_install_using_vagrant) instructions.
+
+2. Ensure you have [Python 3](https://www.python.org/downloads/) installed on your machine, run:
+   ```
+   python3 --version
+   ```
+
+3. To generate configuration for a worker machine, run:
+   ```
+   vagrant workers generate
+   ```
+   
+   If instead you need multiple workers, append the `-n` flag, ex. for 3 machines:
+   ```
+   vagrant workers generate -n 3
+   ```
 
-2. Ensure you have [Python 3](https://www.python.org/downloads/) installed on your machine
+   _NOTE: This will create the vagrant configuration file: `.vagrant/workers.json`._
 
-3. Generate configuration for the desired number of worker machines
+
+4. If you are on MacOS running QEMU, restart the network socket in public mode:
    ```
-   python3 generate_workers.py [-n NUM] [--ip-range IP_RANGE] [--base-port PORT]
+   vagrant workers socket restart --public
    ```
-   This will create or update a configuration file stored at `.vagrant/workers.json`.
-   Now you can create the virtual machines with:
+   _NOTE: Using the `--public` flag will make your worker VMs accessible to anyone
+   on your local network, which may be a modest security concern.
+   We suggest this to minimize possibility of errors while creating the
+   worker machines and will revert this in a later step._
+
+   _NOTE: Running a socket command while a worker machine is running can detach the
+   process, making the VM inaccessible to vagrant. If this happens and you are unable
+   to `vagrant workers halt`, then you may run `pkill -15 -f qemu-system-` to kill
+   all virtual machines running on your computer (including the main Submitty VM)._
+
+6. Now you can create the worker machine(s) with:
    ```
-   vagrant up
+   vagrant workers up
    ```
+   _NOTE: Do not use the --provider flag with this command, since it will conflict with the
+   provider of the main virtual machine._
 
-   If you happen to encounter error messages regarding IP addresses or port conflicts, you can manually edit the `workers.json` file as needed.
+   When this is finished, you should see the Submitty duck ASCII art for each new worker machine.
+
+7. You can verify that all the worker machines are running with:
+   ```
+   vagrant workers status
+   ```
 
-   __NOTE__: Do not edit the `workers.json` configuration file or run the aforementioned python script if there are any existing vagrant machines in your project. This can result in the existing VMs continuing to run in the background or storing their data with no clean way to remove them.
+8. `vagrant ssh` into the main virtual machine and run:
+   ```
+   refresh_vagrant_workers   # (runs python3 /usr/local/submitty/GIT_CHECKOUT/Submitty/.setup/bin/refresh_vagrant_workers.py)
+   submitty_install
+   ```
 
-4. To delete the worker machines and revert to a normal development setup, you can first run
+9. To stop the worker machines, you can run:
    ```
-   vagrant destroy
+   vagrant workers halt
+   vagrant workers socket stop
    ```
-   And confirm to delete all the existing virtual machines.
 
-   Next, you can delete the `workers.json` file, which will remove the worker configuration from your project.
-   The next `vagrant up` should only create the primary development virtual machine without any workers.
+   _For MacOS QEMU users: Once the virtual machine(s) are halted, if you would like to restart under
+   private networking, you may do so by omitting the `--public` flag from the `vagrant workers socket start` command._
+
 
 ---
 
@@ -50,14 +84,15 @@ If you would like to ensure the worker is functioning properly, or enter the wor
 
 To connect to a worker machine through SSH, run:
 ```
-vagrant ssh <worker-name>
+vagrant workers ssh <worker-name>
 ```
 
 If you want to test the connection between the primary VM and a worker, you can first `vagrant ssh` into the primary machine and then run this command to SSH into the worker from there:
 ```
-su submitty_daemon -c ssh submitty@<ip-address>
+su submitty_daemon -c ssh <worker-name>
 ```
-The IP address of the worker machine will be indicated in the `.vagrant/workers.json` file.
+
+The list of worker names can be displayed with `vagrant workers status`.
 
 __NOTE__: Depending on the performance of your computer and the size of the autograding queue passed to the worker, the SSH command may hang for some time.
 

_docs/developer/rensselaer_center_for_open_source/2025_Alexander_Lavallee.md

@@ -0,0 +1,6 @@
+---
+title: Alexander Lavallee 
+category: Developer > Rensselaer Center for Open Source (RCOS) > Summer 2025
+---
+
+coming soon

_docs/developer/rensselaer_center_for_open_source/2025_Christopher_Poon.md

@@ -0,0 +1,6 @@
+---
+title: Christopher Poon
+category: Developer > Rensselaer Center for Open Source (RCOS) > Summer 2025
+---
+
+coming soon

_docs/developer/rensselaer_center_for_open_source/2025_Giancarlo_Martinelli.md

@@ -0,0 +1,6 @@
+---
+title: Giancarlo Martinelli
+category: Developer > Rensselaer Center for Open Source (RCOS) > Summer 2025
+---
+
+coming soon

_docs/developer/rensselaer_center_for_open_source/2025_Jeffrey_Cordero.md

@@ -0,0 +1,6 @@
+---
+title: Jeffrey Cordero
+category: Developer > Rensselaer Center for Open Source (RCOS) > Summer 2025
+---
+
+coming soon