Found while build-testing the freshly regenerated image in a temp
data/config dir: opengist served REPLACE_HOSTNAME literally in every
generated URL, and http.git-enabled routes redirected to bogus paths,
because __update_conf_files() was patching a config file
($ETC_DIR/opengist.yaml) that doesn't exist -- the shipped config is
named config.yaml. Also normalized the substituted value: opengist's
external-url must be a full URL (scheme+host), not a bare hostname,
or it breaks absolute-URL/redirect generation; ssh.external-domain
must stay a bare domain, so it now gets its own REPLACE_SSH_HOSTNAME
token instead of reusing the schemed value.
Verified via: docker build, then a container run against a scratch
temp dir with data/config volumes -- health check reports healthy,
config.yaml shows the correct external-url/ssh.external-domain, and
/-/all, /-/login, /-/register all return 200 with real opengist HTML.
- rootfs/usr/local/etc/docker/init.d/00-opengist.sh: __update_conf_files
now targets $ETC_DIR/config.yaml (was opengist.yaml, a nonexistent
file), prefixes sysname with http:// when no scheme is present for
external-url, and replaces ssh.external-domain via a separate
REPLACE_SSH_HOSTNAME token using the unschemed hostname
- rootfs/tmp/etc/opengist/config.yaml: ssh.external-domain placeholder
changed from REPLACE_HOSTNAME to REPLACE_SSH_HOSTNAME
- TODO.AI.md: updated stale line numbers to match the just-regenerated entrypoint.sh functions file; clarified these are upstream-template findings, not locally fixable
- .env.scripts: synced version stamp to current template; preserved ENV_PULL_URL=casjaysdev/alpine (gen-dockerfile's --update path had a bug computing "alpine" instead, corrected manually per the casjaysdevdocker->casjaysdev/* base-image convention)
- rootfs/usr/local/bin/entrypoint.sh: regenerated from current template; fixes stale CONTAINER_NAME="alpine" -> "opengist" and normalizes whitespace
- rootfs/usr/local/etc/docker/functions/entrypoint.sh: replaced from template; picks up upstream fix for __symlink/__initialize_ssl_certs returning nonzero on success under set -e
- rootfs/root/docker/setup/00-init.sh, 01-system.sh, 02-packages.sh, 03-files.sh, 04-users.sh, 06-post.sh, 07-cleanup.sh: version stamp bump only, no logic change
- rootfs/root/docker/setup/05-custom.sh: version stamp bump only; restored the opengist binary download/install logic that the template regeneration would have wiped (this file is app-specific, not boilerplate)
Root cause: the `git` service user's UID is assigned dynamically (random,
non-persistent across container recreations), and __fix_permissions
re-chowns APPLICATION_DIRS on every startup to whatever UID `git`
currently has. However DATABASE_DIR / DATABASE_BASE_DIR (e.g.
/data/db/sqlite for the sqlite backend) live under /data/db, outside
APPLICATION_DIRS ($ETC_DIR $CONF_DIR $DATA_DIR $LOG_DIR $TMP_DIR
$RUN_DIR $VAR_DIR, where DATA_DIR is /data/opengist, not /data). So
whenever the on-disk DB ownership didn't already match the current
`git` UID, it was never corrected, and opengist failed every start
with "attempt to write a readonly database (8)", causing the
container to exit and get restarted indefinitely.
Reproduced against a live instance (git.casjay.work,
casjaysdevdocker/opengist:latest): confirmed via container logs and
`id git` vs `ls -la /data/db/sqlite` that the sqlite file's owning UID
did not match the current `git` UID, and manually chowning it fixed
that boot but the mismatch could recur on any future UID reassignment.
Reproduced locally by pre-seeding a volume with the DB owned by an
arbitrary UID (9999) and confirming, pre-fix, __fix_permissions never
touched it; post-fix, the container's first boot re-chowns it to the
newly assigned `git` UID and opengist starts cleanly.
- rootfs/usr/local/etc/docker/init.d/00-opengist.sh: after the
database-type case block resolves DATABASE_DIR/DATABASE_BASE_DIR,
append both to ADD_APPLICATION_DIRS so __fix_permissions picks them
up on every startup, regardless of database backend
Root cause: many functions in functions/entrypoint.sh ended with a bare,
unguarded `[ "$DEBUGGER" = "on" ] && echo/printf/__service_banner ...`
statement as their last executed line. With DEBUGGER unset (the default
runtime case), the `[ ]` test is false, so the function's implicit
return value is nonzero. Several of these functions (most critically
__symlink, called bare from __setup_mta) are invoked as unguarded
statements from other functions, and the whole entrypoint runs under
`set -eo pipefail`, so the nonzero return aborted the entire script
chain immediately after startup — explaining why the container only
printed the first log line and exited 1, and why it only worked with
DEBUGGER=on (which makes the echo run and return 0, masking the bug).
Verified via two clean docker buildx build + run cycles: before the
fix, `docker inspect` showed the container crash-looping (exit 1,
~3.9s uptime); after, `RestartCount=0 Status=running Health=healthy`
with opengist fully started, DEBUGGER unset.
- rootfs/usr/local/etc/docker/functions/entrypoint.sh: append `|| true`
to all 26 bare `[ "$DEBUGGER" = "on" ] && ...` statements so their
result never propagates as the enclosing function's return value
- TODO.AI.md: log 20 pre-existing script-lint findings on the same
file (missing `--` on grep, missing `local` on a few function-local
vars, missing VERSION= line) found incidentally while diagnosing
this bug; deferred as unrelated cleanup, not part of this fix
- .env.scripts: version-bump, use "alpine" instead of "casjaysdev/alpine" for ENV_PULL_URL, replace ssmtp with msmtp in ENV_PACKAGES
- Dockerfile: replace ssmtp with msmtp in PACK_LIST to match .env.scripts
Dockerfile
.env.scripts
Docker build was failing with "SSL: no alternative certificate subject
name matches target hostname" when curl resolved api.github.com/
github.com via dual-stack (IPv6-preferring) lookup. Forcing IPv4
(matching the pattern already used in the gitea container's
05-custom.sh) resolves it. Also fixed lint findings surfaced while
touching the file, and a real exit-code bug where the script always
exited 0 regardless of install success/failure.
- rootfs/root/docker/setup/05-custom.sh: add -4 to both curl calls;
prefix script-local vars with OPENGIST_ (matching setup-script env
prefix convention, project name not script filename); add -- to
grep; add matching VERSION= assignment for the ##@Version header;
fix trailing exit code capture that always exited 0 by exiting
$OPENGIST_EXITCODE directly instead of overwriting it with $? of an
unrelated command
- rootfs/usr/local/bin/entrypoint.sh:
1. The "start all services" gate
(`if [ "$START_SERVICES" = "yes" ] || [ -z "$1" ]`) always evaluated
true on a first-run container regardless of $1, because
START_SERVICES is force-set to "yes" whenever no PID file exists yet.
Any command passed to `docker run` — `exec ...`, `sh -c ...`,
`shell`, or an arbitrary program — was swallowed into the
service-start+monitor branch before reaching the `case "$1"`
statement that already handles those subcommands, hanging the
container as a daemon instead of running the given command. Changed
the condition to `if [ -z "$1" ]` so the daemon branch only fires
when no command was given at all.
2. The `*/bin/sh | */bin/bash | bash | sh | shell)` case branch
unconditionally shifted $1 before `__exec_command "$@"` (a bare
`exec "$@"`). For `docker run image sh -c 'cmd'` this turned the
exec into `exec -c cmd` (command not found, exit 127) instead of
`exec sh -c 'cmd'`. Split the branch: real interpreter names
(*/bin/sh, */bin/bash, bash, sh) now pass through unshifted; the
"shell" keyword (not a real interpreter) gets its own branch that
shifts and prepends "sh" to any remaining args, or falls back to a
bare `__exec_command` (exec bash -l) when none remain.
Verified `bash -n` passes. Found and fixed upstream in
dockersrc/go, confirmed identical in this repo's generated
entrypoint.sh, and mechanically applied here with the same patch.
Update volume mount examples and dockerHome variable from
the old /var/lib/srv/$USER/docker layout to /srv/$USER/docker.
- README.md: update volume path references to /srv/$USER/docker
README.md
rootfs/usr/local/bin/copy
rootfs/usr/local/bin/healthcheck
rootfs/usr/local/bin/symlink
The .local.sh block defined stub functions in memory but never
wrote the file to disk, so __file_exists_with_content always
failed and __create_service_env returned non-zero on every run.
Fix: use a heredoc to write the stub functions into .local.sh.
- rootfs/usr/local/etc/docker/init.d/00-opengist.sh: write .local.sh
via heredoc in __create_service_env; bump version to 202606261600-git
rootfs/usr/local/etc/docker/init.d/00-opengist.sh
Port bindings must use 172.17.0.1:{host}:{container} per Dockerfile
conventions — bare {port}:{port} was incorrect.
- README.md: Fix docker run and docker-compose port bindings to use
172.17.0.1:80:80 and 172.17.0.1:7823:7823
README.md
Rewrote the README from a generic boilerplate to accurate, complete
documentation reflecting the actual container configuration.
- README.md: Replace placeholder content with full project docs —
description of OpenGist (self-hosted Git-backed pastebin), dockermgr
install, manual docker run with correct ports (80 HTTP + 7823 SSH),
docker-compose example, volumes/ports/env var tables, OAuth2 config
section with callback URL pattern, and development/build instructions
README.md
--domainname on the container sets the kernel domainname, which c-ares
uses to infer a search domain even when /etc/resolv.conf has no search
line. This caused c-ares to query github.com.casjay.work AAAA and get
the host's own IPv6 address, routing all outbound HTTPS to the local
nginx instead of the real server.
Adding 'search .' and 'options ndots:0' explicitly disables search
domain inference regardless of the kernel domainname setting.
- rootfs/usr/local/etc/resolv.conf: add search . and options ndots:0
rootfs/usr/local/etc/resolv.conf
Hosts with a search domain cause containers to inherit it. When the
zone has a wildcard AAAA record, public hostnames resolve to the host's
own IPv6 address instead of the real server, breaking all outbound
HTTPS and DNS from inside the container.
The entrypoint already has a hook: if /usr/local/etc/resolv.conf
exists it replaces /etc/resolv.conf at container startup. Ship a
clean resolv.conf with Cloudflare + Google DNS and no search domain
so container DNS is always correct regardless of host configuration.
- rootfs/usr/local/etc/resolv.conf: new file — clean DNS, no search domain
rootfs/usr/local/etc/resolv.conf
Update the embedded entrypoint copies in rootfs/ to match the
upstream template change. Internal state files renamed to dotfiles
so they're not matched by `/run/*.pid` cleanup globs:
- /run/init.d/entrypoint.pid -> /run/.entrypoint.pid
- /run/no_exit.pid -> /run/.no_exit.pid
- /run/backup.pid -> /run/.backup.pid
- /run/__start_init_scripts.pid -> /run/.start_init_scripts.pid
Per-service PIDs in /run/init.d/ are unchanged.
rootfs/usr/local/bin/entrypoint.sh
rootfs/usr/local/etc/docker/functions/entrypoint.sh
rootfs/usr/local/etc/docker/init.d/00-opengist.sh
rootfs/usr/local/share/template-files/config/env/default.sample
rootfs/usr/local/share/template-files/config/env/examples/zz-entrypoint.sh
Aligns README install/run snippets with the new convention split:
rootfs/ for Dockerfile-build content (image filesystem), volumes/
for docker-compose host bind-mounts. Compose mounts, host bind
paths, and runtime data dirs are renamed; Dockerfile COPY/ADD
sources (where present) are preserved.
README.md
jason