gortium/compose
1
1
Fork 0
Code Issues Pull Requests 18 Actions Packages Projects Releases Wiki Activity

feat: install custom Hermes tools at startup, remove deprecated fix-permissions.sh #23

Merged
gortium merged 2 commits from feat/hermes-custom-tools-startup into master 2026-05-13 13:52:37 +00:00
Conversation 0 Commits 2 Files Changed 3 +7 -41
Hermes commented 2026-05-12 17:38:48 +00:00
Collaborator
Copy Link

Problem

Custom Hermes tools (gitea, ssh, ollama, fork, qet, moa, connecteam) are stored in the persistent volume at /opt/data/hermes-tools/ but never loaded into /opt/hermes/tools/ on container start.

The fix-permissions.sh startup script is broken when run as non-root (chown silently fails) and its functionality is now handled upstream.

Solution

  1. Dockerfile: Add RUN chown -R hermes:hermes /opt/hermes/tools /opt/hermes/toolsets.py so the runtime user can write custom tools from the persistent volume at startup. No root at runtime.
  2. compose.yml: Override entrypoint to run install.sh (copies custom tools from volume) before chaining to the upstream entrypoint.sh.
  3. Remove fix-permissions.sh and the custom ENTRYPOINT from the Dockerfile -- the upstream entrypoint.sh is the correct entrypoint.

Startup chain

hermes: bash -c "install.sh && exec tini -> entrypoint.sh"
  hermes: install.sh copies tools to /opt/hermes/tools/ (dir is chowned at build)
  hermes: entrypoint.sh sources venv, creates dirs, runs gateway

No privilege escalation. Container runs entirely as the hermes user.

Why this works

  • The tools directory is chowned to hermes:hermes at image build time
  • install.sh runs as the hermes user and can write to the pre-chowned directory
  • Custom tools live in the persistent volume (updateable without rebuild)
  • Built-in tools update normally when pulling a new upstream image

Verification

After deploy: docker compose build hermes && docker compose up -d hermes
Then check: docker exec hermes ls /opt/hermes/tools/vm_tools.py

## Problem Custom Hermes tools (gitea, ssh, ollama, fork, qet, moa, connecteam) are stored in the persistent volume at /opt/data/hermes-tools/ but never loaded into /opt/hermes/tools/ on container start. The fix-permissions.sh startup script is broken when run as non-root (chown silently fails) and its functionality is now handled upstream. ## Solution 1. **Dockerfile**: Add `RUN chown -R hermes:hermes /opt/hermes/tools /opt/hermes/toolsets.py` so the runtime user can write custom tools from the persistent volume at startup. No root at runtime. 2. **compose.yml**: Override entrypoint to run `install.sh` (copies custom tools from volume) before chaining to the upstream entrypoint.sh. 3. **Remove fix-permissions.sh** and the custom ENTRYPOINT from the Dockerfile -- the upstream entrypoint.sh is the correct entrypoint. ## Startup chain ``` hermes: bash -c "install.sh && exec tini -> entrypoint.sh" hermes: install.sh copies tools to /opt/hermes/tools/ (dir is chowned at build) hermes: entrypoint.sh sources venv, creates dirs, runs gateway ``` No privilege escalation. Container runs entirely as the hermes user. ## Why this works - The tools directory is chowned to hermes:hermes at image build time - install.sh runs as the hermes user and can write to the pre-chowned directory - Custom tools live in the persistent volume (updateable without rebuild) - Built-in tools update normally when pulling a new upstream image ## Verification After deploy: `docker compose build hermes && docker compose up -d hermes` Then check: `docker exec hermes ls /opt/hermes/tools/vm_tools.py`
Hermes added 1 commit 2026-05-12 17:38:48 +00:00
feat: install custom tools at startup, remove deprecated fix-permissions.sh
Some checks failed
Build Hermes agent / build (pull_request) Failing after 41m55s
Details
Build ollama (gfx906) / build (pull_request) Failing after 2s
Details
4627199217
Hermes added 1 commit 2026-05-12 18:47:37 +00:00
refactor: chown tools dir at build time instead of root at runtime
Some checks failed
Build Hermes agent / build (pull_request) Failing after 3s
Details
Build ollama (gfx906) / build (pull_request) Failing after 2s
Details
e607982b21
gortium merged commit 3ba0345887 into master 2026-05-13 13:52:37 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Hermes gortium
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gortium/compose#23
No description provided.
Delete Branch "feat/hermes-custom-tools-startup"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?