update proxy ACL to also cover cern.ch and opensciencegrid.org domains

.github/workflows/deploy.yml

@@ -5,7 +5,7 @@ on:
     branches: main
 jobs:
   build:
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-24.04
     steps:
     - name: checkout
       uses: actions/checkout@v2
@@ -15,7 +15,7 @@ jobs:
     - name: set up Python
       uses: actions/setup-python@v1
       with:
-        python-version: 3.8
+        python-version: 3.9
 
     - name: install mkdocs
       run: |

.github/workflows/test.yml

@@ -3,15 +3,15 @@ name: build tutorial
 on: [push, pull_request]
 jobs:
   build:
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-24.04
     steps:
     - name: checkout
       uses: actions/checkout@v2
 
     - name: set up Python
       uses: actions/setup-python@v1
       with:
-        python-version: 3.8
+        python-version: 3.9
 
     - name: Codespell action
       uses: codespell-project/actions-codespell@master

docs/access/proxy.md

@@ -56,7 +56,9 @@ You can use the following template for this:
 acl local_nodes src YOUR_CLIENT_IPS
 
 # Destination domains that are allowed
-acl stratum_ones dstdomain .YOURDOMAIN.ORG
+# cern.ch + opensciencegrid.org domains because of cvmfs-config.cern.ch repository,
+# which are provided via Stratum-1 mirror servers hosted by CERN and OSG
+acl stratum_ones dstdomain .cern.ch .opensciencegrid.org .YOURDOMAIN.ORG
 
 # Squid port
 http_port 3128
@@ -92,7 +94,8 @@ In this template, you *must* change two things in the Access Control List (ACL)
 For example, to allow connecting to the EESSI Stratum 1 replica servers, use:
 
 ```{ .apache .copy }
-acl stratum_ones dstdomain .eessi.science
+# public Stratum-1 mirror servers for EESSI are hosted under eessi.science domain
+acl stratum_ones dstdomain .cern.ch .opensciencegrid.org .eessi.science
 ```
 
 Note that this configuration assumes that port 3128 is accessible on the proxy server.

docs/configuration_hpc.md

@@ -126,7 +126,7 @@ The last scenario that we cover here is for HPC systems that do not have the Cer
 installed on the worker nodes, for example because the system administrators are not willing to install,
 configure, and maintain a CernVM-FS installation.
 
-Though less ideal than a native installaton of CernVM-FS, solutions to make CernVM-FS repositories accessible
+Though less ideal than a native installation of CernVM-FS, solutions to make CernVM-FS repositories accessible
 even in this case exist:
 
 * [Syncing a to another filesystem](#sync-other-filesystem)