Skip to main content

add-bareos-version

Add a new Bareos version directory (Dockerfile + docker-entrypoint.sh) for a given component and flavor (alpine|ubuntu). Use when the user asks to add support for Bareos N-ubuntu or N-alpine, or fill missing version/flavor combos. Also use when the user types "add Bareos 26 ubuntu" or "generate missing Bareos versions".

Informations de source

Dépôt
dark-vex/bareos
Dernière activité de la source
29 septembre 2026 à 17:41
Langue détectée de SKILL.md
anglais
Étoiles
1
Forks
0

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Explorateur de fichiers
2 fichiers

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
add-bareos-version
description
Add a new Bareos version directory (Dockerfile + docker-entrypoint.sh) for a given component and flavor (alpine|ubuntu). Use when the user asks to add support for Bareos N-ubuntu or N-alpine, or fill missing version/flavor combos. Also use when the user types "add Bareos 26 ubuntu" or "generate missing Bareos versions".
allowed-tools
["Read","Write","Edit","Glob","Grep","Bash"]
# add-bareos-version skill Generates missing Bareos Docker image directories. ## Upstream source table See `references/upstream-sources.md` for the authoritative mapping of Bareos version → Alpine tag and Ubuntu repo URL. **Verify this table before generating** — do not assume; run the probe commands in that file if unsure. ## Workflow ### 1. Resolve inputs Accept: a list of `{component, version, flavor}` tuples. Examples: - "Add 26-ubuntu for all standard components" → four tuples: director-pgsql, storage, client, webui, each with version=26, flavor=ubuntu - "Generate client/23-alpine" → one tuple **Standard components** = director-pgsql, storage, client, webui. The api component uses a pip-pinned pattern; handle it separately only if explicitly requested. ### 2. Look up upstream source From `references/upstream-sources.md`: - If the version has no upstream source for the requested flavor → stop and tell the user what's missing. - If the source is marked `current/` → note that the image will install whatever Bareos is current (as of the build date, not the directory name). ### 3. Find the reference template Find the nearest existing directory with the **same component** and **same flavor**: - Same component, closest version, same flavor (e.g. for client/26-ubuntu, reference is client/25-ubuntu) - Read its `Dockerfile` and `docker-entrypoint.sh` in full — use these as the basis for the new files ### 4. Generate the Dockerfile and entrypoint Write the new `Dockerfile` and `docker-entrypoint.sh` directly, adapting the reference template with: - The target directory name (e.g. `client/26-ubuntu`) - The FROM change: e.g. `FROM ubuntu:jammy` (Ubuntu 22.04) - The BAREOS_KEY and BAREOS_REPO values from the upstream sources table - Any differences in how the gpg key is handled between v21 and v22+ style (see below) ### 5. Write files ```bash mkdir -p <component>/<version>-<flavor> # Write Dockerfile # Write docker-entrypoint.sh chmod +x <component>/<version>-<flavor>/docker-entrypoint.sh ``` ### 6. Validate one representative build Run `docker build --check` (or `docker build --platform linux/amd64 --no-cache -t test-bareos:local .`) from inside the new directory. If it fails, fix the Dockerfile/entrypoint directly and rebuild. Do not attempt to build all generated dirs in one pass — do one, verify, then continue. ### 7. Report State what was generated, which tuples were skipped (upstream not found), whether the test build passed. ## Alpine custom-apk checksum verification When the reference template downloads a custom-built `.apk` tarball from a GitHub Release (the `BAREOS_APK_REPO`/`BAREOS_APK_RELEASE`/`BAREOS_APK_VER` ARGs and `curl ... -o /tmp/bareos-apks.tar.gz` pattern), carry over its `ARG BAREOS_APK_SHA256_<ARCH>` and the `echo "${bareos_sha256} /tmp/bareos-apks.tar.gz" | sha256sum -c -` step right after the download. For a new asset (a new version), download it and compute its sha256 before writing the ARG value — never invent or skip the checksum. Also copy `bareos-alpine-packages/keys/bareos-apk@dark-vex.rsa.pub` into the new directory and keep the `COPY bareos-apk@dark-vex.rsa.pub /etc/apk/keys/...` line before the `RUN`: the custom packages are signed with that key and are installed without `--allow-untrusted`. ## Ubuntu key handling difference - v20–21 (old style): `curl -Ls $BAREOS_KEY -o /tmp/bareos.key` then `apt-key add /tmp/bareos.key` - v22+ (new style): `curl -fsSL $BAREOS_KEY -o /tmp/bareos.key`, check that the only fingerprint in the file equals `ARG BAREOS_KEY_FINGERPRINT` (`gpg --batch --show-keys --with-colons` + `awk`), then `gpg --batch --dearmor -o /usr/share/keyrings/bareos.gpg /tmp/bareos.key` and `[signed-by=/usr/share/keyrings/bareos.gpg]` in sources.list When generating v26-ubuntu, ensure the old gpg style described above is adapted to the new style shown in v25-ubuntu, including `ARG BAREOS_KEY_FINGERPRINT` and the fingerprint check. Take the fingerprint from the upstream sources table; if the key changed, verify the new fingerprint against a second source (keyserver or Bareos docs) before updating it — never drop the check.
Voir sur GitHub