Without this, is empty and entrypoint.sh runs bare 'hermes'
which defaults to interactive chat mode. With a non-TTY stdin
this exits immediately with prompt_toolkit's 'Input is not a
terminal' warning, causing a container restart loop.
The profile gateways (run-multi-gateways.sh) were unaffected
because the script passes 'gateway run' explicitly.
- Add libolm-dev system dep (required by mautrix[encryption])
- Add mautrix[encryption] + openai pip packages to build
- These were previously installed inline at container startup and
persisted via the fragile venv volume mount (now removed)
The volume mount /mnt/HoardingCow_docker_data/Hermes/venv overrides the
container's built-in .venv with whatever is on the host. On a fresh start
or after a clean build, an empty/missing venv directory causes entrypoint.sh
line 62 (source .venv/bin/activate) to fail with set -e.
The Docker image already builds a complete venv — persisting it on the host
is unnecessary and fragile.
- Add run-multi-gateways.sh to /opt/data/hermes-tools/ that reads
HERMES_PROFILES env var and spawns one gateway per profile
- Update entrypoint to call the script before the main entrypoint
- Set HERMES_PROFILES=ashley,claire,finn,matt,paul (was default)
Closes PR #47 (feat/multi-profile-gateways). Builds on 548e15d's cleaner
env-var-driven approach — compose.yml stays declarative, logic in script.
The chown -R hermes:hermes was running as non-root user 'hermes'
since USER hermes was set earlier. The new upstream base image
(v0.12.0+) has tools/ owned by root, so the chown fails.
Previous base image happened to have tools/ owned by hermes,
making the chown a silent no-op.
- Replace rsync with cp -a (rsync unavailable in latest upstream base image)
- Remove npm run build step (fork's package.json has no build script)
- Remove himalaya-ro.sh from build context (deployed via install.sh)
- Add hermes to ai_net network for Traefik access
- Add Traefik labels routing hermes.lazyworkhorse.net to dashboard port 9119
update-alternatives --set fails because the base image only registers
iptables-legacy as an alternative. The iptables-nft binary (/usr/sbin/iptables-nft)
exists but isn't in the alternatives database. Direct ln -sf bypasses this.
In Alpine 3.18+, the 'iptables' package IS the nftables variant.
iptables-nft is not a separate package. The binary is already in
the base image — only need to flip update-alternatives.
- Switch FROM weejewel/wg-easy:latest (4yr old, Alpine 3.11) to
ghcr.io/wg-easy/wg-easy:latest (actively maintained, Alpine krypton)
- Use update-alternatives instead of raw ln -sf to flip iptables
from legacy to nftables backend
- Fix compose build context: ./vpn -> . (Dockerfile was at same level)
The weejewel/wg-easy image lacked iptables-nft package in Alpine 3.11.
The new official image has it available, we just flip the alternatives.
The old ln -sf approach was fragile across Alpine versions.
wg-easy's Alpine wg-quick uses legacy iptables which requires the
iptable_nat kernel module. On NixOS kernels compiled without legacy
netfilter modules, the container crashes in a restart loop:
iptables v1.8.3 (legacy): can't initialize iptables table 'nat'
Table does not exist (do you need to insmod?)
Fix: build a custom image that installs Alpine's iptables-nft package
and symlinks iptables -> iptables-nft (nftables backend).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
