Files
computer-playbook/roles/svc-net-tor/files/Dockerfile
kevinveenbirkenbachandClaude Opus 5 28dd5462d7 fix(svc-net-tor): ask the running Tor for circuits instead of re-reading its config
The healthcheck ran `tor --verify-config`, which parses the torrc and never
speaks to the daemon. Ansible renders that file from a template, so it is valid
by construction and the probe could not fail once it existed: bootstrap
progress, circuit establishment and descriptor publication were all invisible,
and `retries` was a dead parameter. Swarm therefore reported the service healthy
while Tor was still coming up, and the readiness that actually gates deploys had
to be rebuilt beside it, in onion_self_reach.py and playwright's
wait_onion_reachable.sh.

The torrc already opens a cookie-authenticated control port, so the probe now
authenticates there and asks GETINFO status/circuit-established. That is the
question the container is supposed to answer. It needs no package the image
lacks: bash carries /dev/tcp and od hex-encodes the cookie, both present in
debian:trixie-slim.

Measured against real Tor, the public flavor reports healthy 6.1s after start
and chutney 54.6s, each confirmed by "Bootstrapped 100% (done)" in the container
log. Chutney is the slower of the two because its entrypoint brings up a whole
private network and waits for consensus before the node tor starts; its
localhost advantage only pays off afterwards, at publish and rendezvous. Both
fit ten minutes with margin to spare, so the flavor-dependent start window goes
and every timing is now the platform default. Three nocheck markers go with it,
including an interval of 60s whose own reason said the probe was "worth running
rarely" while setting twice the default frequency.

Two paths and one condition that had grown copies are pinned in vars/main.yml.
The Dockerfile takes the script locations as build args rather than repeating
them, reaching the entrypoint through a fixed symlink because ENTRYPOINT in exec
form would not expand the arg and would silently keep pointing at the old path.

One behaviour change worth stating plainly: a Tor that never establishes a
circuit is now reported unhealthy after the start window, where before it was
reported healthy forever. That is the point of the change, and it moves such a
failure from the later Playwright run to the service itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-09 23:21:03 +02:00

33 lines
1.2 KiB
Docker

ARG TOR_BASE_IMAGE
ARG TOR_BASE_VERSION
FROM ${TOR_BASE_IMAGE}:${TOR_BASE_VERSION}
ARG TOR_FLAVOR
ENV TOR_FLAVOR=${TOR_FLAVOR}
RUN rm -rf /var/lib/apt/lists/* \
&& apt-get -o Acquire::Retries=3 update \
&& apt-get -o Acquire::Retries=3 install -y --no-install-recommends tor \
&& if [ "${TOR_FLAVOR}" = "chutney" ]; then \
apt-get -o Acquire::Retries=3 install -y --no-install-recommends \
git ca-certificates python3 python3-cryptography python3-networkx \
python3-paramiko python3-rpyc python3-tomli-w python3-typeguard \
python3-typing-extensions \
&& git clone --depth=1 https://gitlab.torproject.org/tpo/core/chutney /opt/chutney \
&& sed -i 's/^\( *\)self\.controlport_base: int = 8000$/\1self.controlport_base: int = 18000/' \
/opt/chutney/lib/chutney/TorNet.py \
&& grep -q 'controlport_base: int = 18000' /opt/chutney/lib/chutney/TorNet.py ; \
fi \
&& rm -rf /var/lib/apt/lists/*
ARG TOR_ENTRYPOINT_PATH
ARG TOR_HEALTHCHECK_PATH
COPY entrypoint.sh ${TOR_ENTRYPOINT_PATH}
COPY healthcheck.sh ${TOR_HEALTHCHECK_PATH}
RUN chmod 0755 ${TOR_ENTRYPOINT_PATH} ${TOR_HEALTHCHECK_PATH} \
&& ln -s ${TOR_ENTRYPOINT_PATH} /tor-entrypoint
ENTRYPOINT ["/tor-entrypoint"]
CMD ["-f", "/etc/tor/torrc"]