vwiebe/conductor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
conductor/SLICE12.md

8.2 KiB
Raw Blame History

SLICE12 — Fresh-install setup-conductor.sh update

Status: Complete — implemented and verified in disposable Ubuntu/Docker

Purpose

Update Skeleton Works' Conductor setup process to install the new standalone release and provide persistent installed-app storage.

Working instructions

Read CODEX.md and applicable AGENTS.md instructions before work. Current source and tests are authoritative. Preserve unrelated working-tree changes. Use this file as both the slice specification and its continuing log.

This slice is planned; do not start it as part of SLICE10. Update the checklist and append dated log entries as work proceeds. Record decisions, changed files, checks and results, failures, unresolved issues and the next action. Do not erase earlier log entries or claim VM/release acceptance from local tests alone.

Scope

  • Update /home/vwiebe/projects/skeletonworks-scripts/setup-conductor.sh to use the verified SLICE11 release.
  • Create/mount the persistent storage expected by the generic installed-app host.
  • Preserve customer URL discovery, Docker-based builds/runtime, persistent keys and existing first-run account setup.
  • Deliver favicon/title behavior through the Conductor release; do not patch frontend source from the setup script.
  • Keep Conductor mandatory in the SaaS offering while leaving Social Scheduler unregistered until its installer succeeds.
  • Give clear guidance for existing installations so fresh setup is not confused with the SLICE13 upgrade process.
  • Update installation and handover guides, including sudo for protected discovery/dry-run operations.

Acceptance checks

Action Purpose / expected behavior
Run setup on a fresh customer-style VM The selected release, default favicon, titles and management screens are present.
Inspect URLs, volumes and first-run setup They match the customer setup result and persist after restart.
Open Publishing before and after app installation No false app entry appears before its installer succeeds.
Install without host Node.js The Docker-based installation works without adding Node to the VM.

Boundaries and dependencies

Depends on SLICE11. Preserve the earlier completed slices and their logs.

The customer control panel and other SaaS backlog items remain outside these four slices. The user reports only one live Conductor instance, which has Social Scheduler installed. A clean Conductor reset is an available fallback if a safe retrofit is impractical; first record the exact scope and backup/recovery plan. This does not authorize wiping the entire VM or deleting Node-RED's saved connections or PostgreSQL's schedules.

Progress log

2026-09-13 — Plan recorded

  • Renamed the proposed four phases to SLICE10, SLICE11, SLICE12 and SLICE13, respectively.
  • Implementation has not started.

Current handoff

SLICE12 is complete. Updated scripts and guides are local working-tree changes. Proceed with SLICE13 only when requested; do not run fresh setup against the existing customer VM.

2026-09-13 — Implementation started

  • User authorized SLICE12 after the publicly verified v1.1.0 release.
  • Inspected bootstrap, Caddy setup, current setup and backup/restore wrappers. Bootstrap deploys all sibling shell scripts and installs Docker; no host Node installation is needed.
  • Preserve the existing /data named volume, customer URL/result-file contract, persistent keys and browser first-run administration.
  • Default to the verified v1.1.0 image digest. Add read-only dry-run and explicit existing-installation refusal. A preparation made by this new script can be resumed without replacing its keys.
  • The old scheduled backup wrapper omits installed-app assets. Update the matched backup/restore wrappers to the existing application backup v2 contract so fresh installations have complete recovery coverage.
  • Preserve pre-existing changes in skeletonworks-scripts (uninstall-wordpress, password-reset-conductor and removed mshield sidecars). The source snapshot is under /home/vwiebe/projects/.local/conductor-slice12-start.
  • No live VM deployment or upgrade is part of this slice. Test in disposable infrastructure only.

2026-09-13 — Implementation complete

  • setup-conductor.sh defaults to Conductor v1.1.0 at the verified OCI index digest sha256:ab5e7dcaed065a304660af31e53ffada290b22dc9176ffeb5817f2e7f07ac313. No new Conductor image, frontend patch or host Node installation is involved.
  • Preserved the customer URL, named /data volume and setup-result fields used by Social Scheduler. Created /data/applications under that same persistent volume. There are no seeded apps.
  • Added root/sudo guidance including dry-run, validated image/domain/resource inputs, correct base-domain/already-qualified/custom-FQDN resolution, capability/readiness checks and safe refusal of existing installations/data.
  • --no-start writes a private resumable preparation. Repeated preparation and later activation preserve the exact keys and Compose files. A completed or changed installation is not overwritten by fresh setup.
  • Added managed Caddy blocks, a protected configuration backup, candidate validation before replacement and graceful reload through stdin so a previously mounted file cannot supply stale bytes. Existing sites and unrelated cron entries are preserved.
  • Updated the matched Skeleton Works backup/restore wrappers to use the release's app-file backup mechanism. Backups include verified assets referenced by the SQLite snapshot, private keys and configuration; restore accepts v1/v2 and validates member paths/types, checksum coverage, format and hostname before changing files.
  • Added docs/SKELETONWORKS_INSTALL.md for the VM administrator and customer handover, including sudo discovery, three-script deployment, persistent storage, first-run administration, backup/recovery and the fresh-install/upgrade boundary. Updated README, docs/INSTALL.md and TESTING.md accordingly.

2026-09-13 — Verification and limits

  • PASS: Bash syntax, ShellCheck and --help for setup/backup/restore.
  • PASS: documentation links, governance and whitespace checks.
  • PASS: actual scripts in disposable Ubuntu 24.04 with its own Docker engine and no Node.js installed. No host Docker socket, host directory or customer data was mounted into that test host.
  • PASS: read-only dry-run, DNS/FQDN variants, invalid arguments, sudo guidance and unchanged legacy installation files.
  • PASS: no-start/repeat/resume, private file ownership/modes, exact key preservation, anonymous pull of the pinned image, package host readiness, non-root/read-only runtime and persistent app volume.
  • PASS: generated Caddy HTTPS route using local test certificates, preserved neighboring site and existing cron job, browser first-run administrator creation, Projects save, default favicon and appropriate setup/home/app titles.
  • PASS: initially empty Publishing, independent example app installation/launch without changing the core image, scheduled-user backup, corrupt/symlink/traversal/missing-app backup rejection before configuration changes, recovery of deliberately removed app files, and account/project/app persistence after container recreation.
  • PASS: visual review of fresh and populated Publishing screenshots under test-results/slice12; no browser errors.
  • Initial attempts exposed test-environment issues: nested Docker needed its official cgroup initialization, the first-run title expectation needed the existing Set up title, and fixture files needed a persistent directory instead of Docker-copied /tmp. Corrected the harness and reran the complete acceptance successfully. These were not changes to the released Conductor frontend.
  • The runner removed its disposable host and all nested containers/data. Evidence: test-results/slice12/result.json, browser-result.json, acceptance.log and screenshots.
  • A real customer VM deployment, public DNS/certificate issuance, complete Social Scheduler/Node-RED/PostgreSQL deployment and existing-image migration were not performed in this slice. SLICE11 already covered the scheduler package contract; SLICE13 owns the current VM's upgrade.
  • Changes remain uncommitted/unpushed in the local source folders. Pre-existing skeletonworks-scripts changes were preserved. No production service, user account, social credential, schedule or published release artifact was changed.