The "disable" option description stated "Comment out (disable) this repo" but the implementation uses `Enabled: false` (deb822 format) instead of commenting. Update description to better reflect the action.
* Install Java via setup_java instead of distro openjdk
Apache Tika's Java runtime was installed by calling apt directly for
openjdk-17-jre-headless. This tied the JDK to whatever Debian ships, and
that coupling has now broken: openjdk-17 is no longer available on Debian
13 (Trixie), where openjdk-21 is current. It also made this the only
script in install/ that installs Java by hand, while every other Java
application in the repository uses the shared setup_java helper.
Switch to setup_java, which installs Eclipse Temurin from the Adoptium
repository. Temurin is versioned independently of the Debian release, so
a future distribution upgrade cannot remove the JDK out from under the
application the way this one did.
Java 21 satisfies both current and upcoming Tika: 3.x requires Java 11 or
newer, and 4.x raises the floor to Java 17.
The surrounding msg_info/msg_ok pair is dropped because setup_java emits
its own progress messages; keeping them would nest the output.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Bump Apache-Tika container to Debian 13
The container declared Debian 12 (Bookworm) as its base, which had become
an outlier: 475 of the repository's ct scripts target Debian 13 and only
22 still target 12. build.func also sets trixie as the default ARM64
template codename, so this script's declared base had drifted away from
the repository default.
The declared version is not cosmetic. check_container_os_guard() reads
var_os/var_version as the script's recommended OS and compares them
against a container's /etc/os-release, prompting on interactive runs and
aborting headless ones when they disagree. Debian 12 was also the reason
the previous openjdk-17 dependency looked valid; on Debian 13 that
package no longer exists, which is addressed in the preceding commit.
Existing Debian 12 containers keep working, because update_script only
replaces the Tika jar and never touches the operating system or Java.
They will, however, now hit the OS mismatch guard on update and be asked
to move to Debian 13 first. That is intended rather than a regression,
but it is a visible change for existing users.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Migrate Termix database to the new db/data layout introduced in 2.5.1, fail fast on backend build errors, and precreate the db/data directory on fresh installs.
Co-authored-by: P3RF3CTION <13474113+P3RF3CTION@users.noreply.github.com>
* pve-tool: storage share helper script for Proxmox
This script provides a menu-driven interface for managing various storage types in Proxmox, including SMB, NFS, and iSCSI. It includes functions for testing mounts, adding storage, and managing LXC mountpoints.
* bump function call
* add dynamic whiptail (feedback from #15882)
* broken whiptail in menu 4
* fix ui bug, more space for container names
* fix whiptail pick mountpoint
* Allow removing multiple LXC mountpoints
Update `remove_lxc_mountpoint` in `storage-share-helper.sh` to support multi-select mountpoint removal for a container. Each selected mountpoint is now confirmed individually (default No), processed independently, and reported in a final result summary with `removed`, `FAILED`, or `skipped` status.
* stupid whiptail.. now done
* Update storage-share-helper.sh
* OPNSense: Bump FreeBSD to 15 and OPNSense to 26.7
* fix user feedback
* fix typo
* fix url for image
* Replace fixed OPNsense wait with screen polling
Swap the hardcoded 1000-second sleep for an adaptive loop that watches VM console screendump hashes and proceeds after sustained stability. The new logic enforces a minimum 5-minute wait, checks every 30 seconds, and caps total wait at 40 minutes to handle slower hosts or screendump failures more reliably.
* Harden OPNsense build wait detection
Improves VM install completion detection by encapsulating screendump hashing in a helper, clearing stale dump files, and trying both `qm monitor` and `pvesh` monitor paths. The stability check now tolerates alternating A/B frames from a blinking login cursor instead of requiring one identical frame. It also adds elapsed-time progress output and a safe fallback to a fixed 12-minute wait when screendumps are unavailable, avoiding false completion or endless polling.
* core: add OS mismatch guard for container updates
Introduces `check_container_os_guard()` to compare the container's `/etc/os-release` against the script's recommended `var_os`/`var_version` before running updates. On mismatch, interactive runs now prompt to continue (default no), while silent/headless runs abort to avoid partial breakage on unsupported bases. A bypass flag (`var_ignore_os_mismatch=1|yes|true|on`) was added, and the guard is wired into all update entry paths in `start()`.
* Refine OS mismatch update guidance
Updates the OS version mismatch prompts in `check_container_os_guard()` to recommend upgrading the existing container OS to the target release before rerunning the update, instead of recreating the container. The skip/error path now uses the same guidance while still documenting `var_ignore_os_mismatch=1` as an override.
* Add persistent OS mismatch bypass option
Enhances `check_container_os_guard` to support a persistent opt-out for OS version mismatch checks. The prompt now uses a 3-option whiptail menu (cancel, continue once, continue and remember), and stores ignored targets in `/root/.helper-scripts-ignoreOSupdate` so users are re-prompted when a newer recommended OS appears. Messaging was also tightened to explicitly warn that bypassing may break updates and is unsupported.
* switch to /usr/local
* Re-download snappdf Chromium after Invoice Ninja updates
update_script() redeploys /opt/invoiceninja via CLEAN_INSTALL, which
wipes vendor/beganovich/snappdf/versions. That path isn't covered by
create_backup/restore_backup, so the Chromium binary snappdf needs for
PDF generation was missing after every update, breaking PDFs (#15942).
Re-run the same "vendor/bin/snappdf download" step the install script
already does, right after the backup is restored.
* Back up snappdf's Chromium download to avoid re-fetching on every update
vendor/bin/snappdf download is idempotent: it exits immediately without
downloading if versions/revision.txt already exists, and PDF generation
doesn't check that version against the installed snappdf package - it
just uses whatever's in versions/. So the cached Chromium build survives
just fine across an update via the existing backup/restore mechanism.
Add vendor/beganovich/snappdf/versions to create_backup/restore_backup;
keep the snappdf download call only as a safety net for when the backup
doesn't have it yet (e.g. the first update after this fix ships).
* Remove explanatory comment
Overwriting /etc/mongod.conf with only the replication block wiped
out storage.dbPath from the mongodb-org package default, so mongod
fell back to its compiled-in /data/db path, which was never created.
Append the replication section instead of replacing the file.
* Fix Nametag update failing with missing tailwindcss module
npm ci during update ran with devDependencies omitted, likely because
NODE_ENV=production was already present in the environment by then
(npm's documented default: omit=dev when NODE_ENV=production). Since
@tailwindcss/postcss is a devDependency, the subsequent `npm run build`
failed with "Cannot find module '@tailwindcss/postcss'". Force devDeps
to be installed regardless of NODE_ENV via --include=dev.
* Apply --include=dev to fresh installs too, for parity with update fix
Couldn't confirm within this repo why devDependencies would only be
omitted on update and not on a fresh install - create_backup/
restore_backup are plain file copies and nothing in tools.func sets
NODE_ENV or writes an .npmrc. Since npm ci runs before .env is sourced
in both scripts, apply the same explicit --include=dev to the installer
as defense-in-depth against the same class of failure.
Same bug as build.func's install-recovery menu: this "Remove broken
container?" prompt treated a hard read failure (broken/closed stdin,
I/O error) identically to a real 60s timeout, defaulting to pct
destroy either way. Only auto-remove on an actual timeout (read_rc >
128); on a genuine read failure, keep the container instead of
guessing and destroying it.
push-app-to-main[bot]