mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-09-15 06:09:08 +02:00
fix(calibre-web): make kepubify executable so Kobo sync can be enabled (#3041)
* fix(calibre-web): make kepubify executable so Kobo sync can be enabled The LinuxServer base image installs kepubify with `curl -o /usr/bin/kepubify` and never marks it executable, so the file ships as mode 0644. Calibre-web's resolve_binary_path() only accepts a binary that passes os.access(X_OK), so enabling Kobo sync failed with "Kepubify binary not found" even when the path was set to /usr/bin by hand. Verified against the published layer of lscr.io/linuxserver/calibre-web:arm64v8-latest, whose tar header for usr/bin/kepubify reads `-rw-r--r-- 0/0 3670016`. Set mode 0755 on it at build time, unguarded: if a future base image stops shipping the binary, the build should fail rather than ship a broken add-on. Calibre-web separately only autodetects kepubify under /opt/kepubify, never /usr/bin, so the setting was stored empty on the first start and never retried. Fill it in with /usr/bin from the cont-init script that already applies conditional settings to app.db, and only while it is still empty, so a path the user set by hand is never overwritten. Fixes https://github.com/alexbelgium/hassio-addons/issues/3040 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(calibre-web): publish kepubify under a name calibre-web accepts The first attempt was incomplete. It read binary_helper.py at calibre-web master, which accepts a bare "kepubify"; the shipped 0.6.27 tag does not: SUPPORTED_KEPUBIFY_BINARIES = ("kepubify-linux-64bit", "kepubify-linux-32bit") So there are two independent defects, and the chmod only fixed one. The base image installs the converter with `curl -o /usr/bin/kepubify`, which leaves it mode 0644 *and* names it something calibre-web will not look for. A symlink alone does not fix it either: os.access() follows the symlink and tests the target, and the target has no execute bit for anyone, root included. Verified against the exact 0.6.27 resolution logic, on a scratch tree: symlink only -> '' (still broken) chmod only -> '' (still broken) chmod 0755 + symlink -> '/opt/kepubify' Put the symlink in /opt/kepubify, which is where calibre-web's own autodetect_kepubify_binary() already looks, rather than in /usr/bin where only our own database write would find it. init_config() re-runs that detection on every start while the column is NULL, so calibre-web now configures the path itself and a fresh install needs no second restart. That in turn shrinks the cont-init statement: instead of hardcoding a path it resets an empty value to NULL, which un-sticks calibre-web's own detection for installs that already persisted "". A path set by hand is not empty and is left alone. Mode measured on the published add-on image, all 28 layers scanned: ghcr.io/alexbelgium/calibre_web-aarch64:0.6.27.3 carries usr/bin/kepubify at mode 0o644 in the base layer and nowhere else. Reported by @andMaximus in https://github.com/alexbelgium/hassio-addons/issues/3040 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(calibre-web): keep /usr/bin resolving for the manual workaround CodeRabbit spotted that an install already storing "/usr/bin" stays broken: that value is not empty, so the cont-init statement leaves it alone, and with the symlink only in /opt/kepubify it no longer resolves under 0.6.27. The case is real and narrow. A failed save never persists the value -- _configuration_result() calls config.load() on the error path, discarding it -- so the only way to hold "/usr/bin" is a save that succeeded, which requires having first applied the workaround published in the issue thread: ln -sf /usr/bin/kepubify /usr/bin/kepubify-linux-64bit Anyone who did that, and anyone copying that comment, would have been broken again by this PR. Fixed with one more symlink rather than CodeRabbit's suggested migration of "/usr/bin" back to NULL, because that would overwrite a path the user set by hand. Making their setting keep working is better than resetting it. Verified against the 0.6.27 resolution logic: symlink in /opt only stored '/usr/bin' -> '' plus /usr/bin symlink stored '/usr/bin' -> '/usr/bin/kepubify-linux-64bit' autodetect -> '/opt/kepubify' Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Alexandre
@@ -1,4 +1,9 @@
|
||||
|
||||
## 0.6.27.4 (2026-09-04)
|
||||
- Fix: Kobo sync could not be enabled, failing with "Kepubify binary not found" even when the path was set by hand. The LinuxServer base image installs the converter as `/usr/bin/kepubify` with `curl -o`, which leaves it mode 0644 and gives it a name calibre-web does not accept : `binary_helper.py` only takes `kepubify-linux-64bit` or `kepubify-linux-32bit`, and only when `os.access(X_OK)` passes. The addon now makes the binary executable and publishes it as `/opt/kepubify/kepubify-linux-64bit`, the directory calibre-web's own autodetection already probes, so the path is filled in without any manual step (https://github.com/alexbelgium/hassio-addons/issues/3040)
|
||||
- Fix: on installs created before that change, calibre-web had already run its autodetection once, found nothing usable and stored an empty path, and it never retries. An empty path is now reset so calibre-web detects the converter itself at the next start. A path set by hand is left alone
|
||||
- Fix: `/usr/bin` also keeps working as a converter path, so the setting stored by anyone who applied the manual `ln -sf /usr/bin/kepubify /usr/bin/kepubify-linux-64bit` workaround keeps resolving after the update instead of silently breaking again
|
||||
|
||||
## 0.6.27.3 (2026-08-30)
|
||||
- Doc: explain in the README that Calibre-Web's optional extras (metadata, kobo, gdrive, gmail, goodreads, ldap, oauth, comics) are already installed by the LinuxServer base image, that `pip install calibreweb[...]` inside the container is useless and not persistent, and that the cover fields on the Edit Metadata page are gated on `Enable Uploads` plus the user's `Upload` permission (https://github.com/alexbelgium/hassio-addons/issues/1143)
|
||||
- Fix: remove the Dockerfile step that claimed to install the Calibre binaries into `/opt/calibre`. There is no `wget` in the image, so the command failed silently and left the layer empty; the binaries are and were provided at start by the default `linuxserver/mods:universal-calibre` docker mod
|
||||
|
||||
@@ -45,8 +45,23 @@ ARG CONFIGLOCATION="/config"
|
||||
RUN chmod 744 /ha_lsio.sh && if grep -qr "lsio" /etc; then /ha_lsio.sh "$CONFIGLOCATION"; fi && rm /ha_lsio.sh
|
||||
|
||||
# Specific images modifications
|
||||
# The base image installs kepubify with "curl -o /usr/bin/kepubify", which both leaves it mode
|
||||
# 0644 and gives it a name calibre-web does not accept : binary_helper.py only takes
|
||||
# "kepubify-linux-64bit" or "kepubify-linux-32bit", and only when os.access(X_OK) passes. Both
|
||||
# defects have to be fixed, which is why enabling Kobo sync failed with "Kepubify binary not
|
||||
# found" even when the path was set by hand. Publish it under an accepted name in /opt/kepubify,
|
||||
# the directory calibre-web's own autodetect_kepubify_binary() already probes, so calibre-web
|
||||
# fills the setting in itself. The second link keeps /usr/bin working as well : that is the value
|
||||
# already stored by anyone who applied the "ln -sf /usr/bin/kepubify /usr/bin/kepubify-linux-64bit"
|
||||
# workaround, and their setting is not empty, so it is left alone below and has to keep resolving.
|
||||
# Unguarded on purpose: if a future base image stops shipping the binary, the build must fail here
|
||||
# rather than ship a silently broken add-on.
|
||||
RUN \
|
||||
usermod --home /config abc
|
||||
usermod --home /config abc \
|
||||
&& chmod 0755 /usr/bin/kepubify \
|
||||
&& mkdir -p /opt/kepubify \
|
||||
&& ln -s /usr/bin/kepubify /opt/kepubify/kepubify-linux-64bit \
|
||||
&& ln -s /usr/bin/kepubify /usr/bin/kepubify-linux-64bit
|
||||
|
||||
##################
|
||||
# 3 Install apps #
|
||||
|
||||
@@ -116,5 +116,5 @@ schema:
|
||||
slug: calibre-web
|
||||
udev: true
|
||||
url: https://github.com/alexbelgium/hassio-addons/tree/master/calibre_web
|
||||
version: "0.6.27.3"
|
||||
version: "0.6.27.4"
|
||||
video: true
|
||||
|
||||
@@ -32,6 +32,14 @@ else
|
||||
# before calibre-web, so a failure here is not fatal : the next start applies it.
|
||||
trusted_ips_error=$(sqlite3 /config/app.db "update settings set config_reverse_proxy_trusted_ips='127.0.0.1,::1,::ffff:127.0.0.1,172.30.32.0/23,::ffff:172.30.32.0/119,'||coalesce(config_reverse_proxy_trusted_ips,'') where coalesce(config_reverse_proxy_trusted_ips,'') not like '%::ffff:172.30.32.0/119%'" 2>&1) ||
|
||||
bashio::log.warning "Could not set the ingress trusted ip list, it will be applied at next start (${trusted_ips_error})"
|
||||
|
||||
# Calibre-web autodetects kepubify only while this setting is still NULL. On every install
|
||||
# that predates the Dockerfile fix above, that detection already ran, found nothing usable and
|
||||
# stored an empty string, so it is never retried. Put an empty value back to NULL and
|
||||
# calibre-web detects /opt/kepubify itself when it starts, a few seconds after this runs.
|
||||
# A path the user set by hand is not empty and is left alone.
|
||||
kepubify_error=$(sqlite3 /config/app.db "update settings set config_kepubifypath = NULL where config_kepubifypath = ''" 2>&1) ||
|
||||
bashio::log.warning "Could not reset the kepubify path, it will be applied at next start (${kepubify_error})"
|
||||
fi
|
||||
|
||||
bashio::log.info "Default username:password is admin:admin123"
|
||||
|
||||
Reference in New Issue
Block a user