Fix reproducibility issues with libyuv and improve tenboxd installation (#117)

* fix: pin libyuv to a specific commit to ensure reproducibility

- Updated the LIBYUV_REF argument in Dockerfile.jammy to a specific commit to avoid issues with NEON inline assembly in the stable branch that breaks the arm64 build-base.
- Modified the git clone command to check out the specified commit, ensuring consistent build outputs across runs.

* fix(linux): reload env file on re-install and clean enabled state on remove

Two reinforcing bugs prevented `install-linux.sh` from reliably
applying /etc/tenbox/tenboxd.env on a re-install:

1. prerm did not call `systemctl disable tenboxd`, so the [Install]
   symlink under /etc/systemd/system/multi-user.target.wants/ survived
   `apt-get remove`. The next `apt-get install tenbox` therefore saw
   is-enabled=true in postinst and ran `deb-systemd-invoke restart`
   *before* install-linux.sh had a chance to write the env file,
   leaving the daemon running with empty TENBOX_CLOUD_URL /
   TENBOX_DATA_DIR and disconnected from the cloud tunnel.

2. install-linux.sh used `systemctl enable --now tenboxd`, which
   no-ops the start when the daemon is already active — so even after
   the env file landed, systemd never re-read it. Switched to an
   explicit `enable + restart` so the freshly written env always wins.

Verified end-to-end: purge -> reinstall -> install-linux.sh now prints
the my.tenbox.ai/pair?code=... URL on the first try, and the daemon's
cmdline carries the correct --cloud-url and --data-dir.

docs/linux-update.md documents the new flow plus the existing
/run/tenbox/tenbox.sock + tenbox-group permission model.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: 78

VERSION

@@ -1 +1 @@
-0.7.8
+0.7.9

docs/linux-update.md

@@ -76,7 +76,36 @@ sudo apt-get install tenbox=0.7.5
 The package's `postinst` reloads systemd and bounces `tenboxd` only if
 the unit was already enabled — fresh installs are still gated on
 `scripts/install-linux.sh` writing `/etc/tenbox/tenboxd.env` and calling
-`systemctl enable --now tenboxd`.
+`systemctl enable + restart tenboxd` (note: not `enable --now`, because
+on a re-install `--now` would no-op when the daemon is already active
+and the freshly written env file would never be loaded). Symmetrically,
+`prerm` runs `systemctl disable tenboxd` so a subsequent
+`apt install tenbox` doesn't see a stale enabled state and start the
+daemon before the env file lands.
+
+## Socket permissions and the `tenbox` group
+
+`tenboxd` listens on `/run/tenbox/tenbox.sock`. The deb's `postinst`
+creates a system group `tenbox` and a system user `tenbox` (the user
+is reserved for a future drop-priv step; today the daemon still runs
+as root for `/dev/kvm` and `apt-get`). At startup the daemon:
+
+1. Lets systemd create `/run/tenbox/` mode `0755` (owned `root:root`).
+2. After `Listen()` succeeds, reads `TENBOX_SOCKET_GROUP` from the
+   environment (set to `tenbox` by the unit file), and `chown :tenbox`
+   + `chmod 0660` on the socket file itself.
+
+The result mirrors libvirt and docker: the directory is
+world-traversable so any user can `stat(2)` the socket and the CLI
+can give an honest `permission denied` error rather than a misleading
+`no such file`, but only members of the `tenbox` group can `connect(2)`.
+The installer adds `$SUDO_USER` to the group automatically; new
+shells (or `newgrp tenbox`) pick up the membership.
+
+CLI default-socket lookup is in `client.cpp:DefaultSocketPath()` and
+goes: `$TENBOX_SOCK` → `/run/tenbox/tenbox.sock` (if `/run/tenbox`
+exists) → `$XDG_RUNTIME_DIR/tenbox.sock` (per-user dev daemon) →
+`/tmp/tenbox-<uid>.sock` (last-resort fallback).
 
 ## Stop all VMs first
 

packaging/build-base/Dockerfile.jammy

@@ -56,7 +56,13 @@ ENV CXXFLAGS="-O2 -fPIC"
 # Pin upstream versions so build outputs are reproducible across runs.
 ARG X264_REF=stable
 ARG OPUS_VERSION=1.5.2
-ARG LIBYUV_REF=stable
+# libyuv: pin to a specific commit on main rather than tracking the
+# `stable` branch. The stable branch occasionally ships NEON inline
+# assembly that jammy's binutils 2.38 rejects (e.g. `ld1 {v4.16b},
+# [x3, 80]` without the required `#` on the immediate offset), which
+# breaks the arm64 build-base. Pinning a known-good main commit also
+# makes the static archive bit-for-bit reproducible across runs.
+ARG LIBYUV_REF=b438739c8b08eba2c562a62ea5961f6215d525ed
 ARG FFMPEG_VERSION=6.1.1
 # libcurl is statically linked into tenboxd. Pinning the version here
 # (instead of pulling whatever apt has) means the LLM proxy's HTTP
@@ -94,7 +100,8 @@ RUN curl -fsSL "https://downloads.xiph.org/releases/opus/opus-${OPUS_VERSION}.ta
 # cmake_minimum_required is older than what cmake 4 will accept by
 # default. The flag tells cmake "treat this project as if it asked for
 # at least 3.5 policy semantics" without us having to fork upstream.
-RUN git clone --depth 1 --branch ${LIBYUV_REF} https://chromium.googlesource.com/libyuv/libyuv \
+RUN git clone https://chromium.googlesource.com/libyuv/libyuv \
+    && git -C libyuv checkout ${LIBYUV_REF} \
     && cmake -S libyuv -B libyuv/build -G Ninja \
         -DCMAKE_BUILD_TYPE=Release \
         -DCMAKE_INSTALL_PREFIX=$DEPS_PREFIX \

packaging/debian/prerm

@@ -11,6 +11,16 @@ case "$1" in
         if systemctl is-active --quiet tenboxd 2>/dev/null; then
             deb-systemd-invoke stop tenboxd || true
         fi
+        # Drop the [Install] symlinks too. Without this, the unit
+        # remains `enabled` after `apt-get remove tenbox`, and a
+        # subsequent fresh `apt install tenbox` would have postinst
+        # see is-enabled=true and call `deb-systemd-invoke restart`
+        # *before* install-linux.sh has had a chance to write
+        # /etc/tenbox/tenboxd.env, leaving the daemon running with
+        # empty TENBOX_CLOUD_URL / TENBOX_DATA_DIR.
+        if systemctl is-enabled --quiet tenboxd 2>/dev/null; then
+            systemctl disable tenboxd >/dev/null 2>&1 || true
+        fi
         ;;
 esac
 

scripts/install-linux.sh

@@ -179,8 +179,15 @@ enable_systemd() {
     # but deliberately does not enable it, because the env file above
     # is what makes the unit actually safe to launch with the right
     # cloud URL / data dir.
+    #
+    # `enable --now` would only `start` (not `restart`) the service,
+    # which is fine on a brand-new install. But on a re-install the
+    # daemon may already be active from a previous run; in that case
+    # `--now` becomes a no-op and the freshly written env file is
+    # ignored. Force a restart so the new env always wins.
     systemctl daemon-reload
-    systemctl enable --now tenboxd
+    systemctl enable tenboxd >/dev/null
+    systemctl restart tenboxd
 }
 
 await_pair_url() {