From 2d84024624bfa03dbde0f3a317de32bf5dded4c5 Mon Sep 17 00:00:00 2001 From: stellarshenson Date: Mon, 10 Nov 2025 00:19:21 +0100 Subject: [PATCH] docs: update journal and clarify docker-privileged group in README Added journal entry #13 documenting release v3.2.11 preparation: - Git tag creation with annotations - RELEASE.md delta notes - Documentation simplification (docker-socket-permissions.md from 66 to 19 lines) - project.env update with release metadata - Security warning corrections (host system -> Docker host) - HTML alert styling for warnings Updated README.md to explicitly name 'docker-privileged' group in opening description of privileged access section for clarity. --- .claude/JOURNAL.md | 3 +++ README.md | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/.claude/JOURNAL.md b/.claude/JOURNAL.md index 27d40bf..37a11ed 100644 --- a/.claude/JOURNAL.md +++ b/.claude/JOURNAL.md @@ -39,3 +39,6 @@ This journal tracks substantive work on documents, diagrams, and documentation c 12. **Task - Configuration-agnostic volume management with optional descriptions**: Refactored volume management to dynamically read from configuration and added optional volume descriptions
**Result**: Modified jupyterhub_config.py to define DOCKER_SPAWNER_VOLUMES as module-level constant, created get_user_volume_suffixes() function extracting volume suffixes matching jupyterlab-{username}_ pattern, added USER_VOLUME_SUFFIXES calculated from DOCKER_SPAWNER_VOLUMES (importable by handlers), protected all c.* assignments with 'if c is not None:' guards to allow module import without NameError, added optional VOLUME_DESCRIPTIONS dict mapping volume suffixes to user-friendly descriptions, exposed volume_descriptions via c.JupyterHub.template_vars, updated home.html template to use Jinja2 loop generating checkboxes dynamically from user_volume_suffixes with conditional description display, modified ManageVolumesHandler to validate against USER_VOLUME_SUFFIXES from config instead of hardcoded set, simplified README.md following modus primaris (features first, simplified notification description, simplified architecture diagram labels), updated documentation in .claude/CLAUDE.md (Manage Volumes section with configuration example, simplified Restart Server section) and doc/ui-template-customization.md (added template variables section), UI now fully agnostic working correctly if volumes renamed/added/removed in configuration without template or handler changes + +13. **Task - Release v3.2.11 preparation and documentation refinement**: Tagged release, prepared delta notes, simplified documentation, corrected security warnings
+ **Result**: Created git tag RELEASE_3.2.11 with annotations covering configuration-agnostic volume management, notification broadcast, privileged access control, created RELEASE.md delta release notes documenting major features (configuration-agnostic volume management with optional descriptions, admin notification broadcast with 6 types, privileged user docker.sock access control), technical improvements (module-level constants, dynamic handlers/templates), documentation updates (modus primaris style, new screenshots), version history (v3.2.11 ← v3.2.0 ← v3.1.2 ← v3.0.23 ← v3.0.14), upgrade notes with backward compatibility, simplified doc/docker-socket-permissions.md from 66 to 19 lines removing verbose explanations/use cases/auditing commands, updated project.env with RELEASE_TAG and RELEASE_DATE metadata, corrected docker.sock security warnings changing "host system" to "Docker host" (docker.sock grants Docker daemon access not physical host), applied HTML alert styling (alert-block alert-warning) to security warnings in README.md for better visibility, updated security warnings in README.md (Requirements and Privileged Access sections), doc/docker-socket-permissions.md, and .claude/CLAUDE.md diff --git a/README.md b/README.md index 2cba407..f76ce7b 100644 --- a/README.md +++ b/README.md @@ -187,7 +187,7 @@ c.DockerSpawner.volumes = { Security Warning: Docker socket access grants effective root-level control over the Docker host. Only grant this permission to trusted users. -The platform supports granting specific users read-write access to `/var/run/docker.sock` within their JupyterLab containers. This enables container orchestration, Docker builds, and Docker Compose operations from within user environments. +The platform supports granting specific users read-write access to `/var/run/docker.sock` within their JupyterLab containers via the `docker-privileged` group. This enables container orchestration, Docker builds, and Docker Compose operations from within user environments. **How to Grant Access**: