Makefile targets

[geoffgeoffgeoff3]

This is not really an issue, but a question: There are three related targets: state-create, state-init, and clean-volumes. Is there redundancy we can eliminate, or can you explain the different uses of them so I can add some explanations in the README?

[AndresCdo]

Hi @geoffgeoffgeoff3

• state-init: Safe setup. Creates folders, fixes permissions, runs state-create only if DB is missing. Non-destructive.
• state-create: Resets DB (volDB) but keeps files in volExport and volStarexec. Use for fresh schema.
• clean-volumes: Wipes everything (volDB, volExport, volStarexec). Full reset.

Destructive order:
state-init → state-create → clean-volumes

Typical use:

• First run: make start
• Reuse state: make start
• Reset DB only: make state-create && make start
• Full reset: make clean-volumes && make start
• Share state: make state-pack / make state-restore FILE=... && make start

Notes:

• state-create can orphan files if data already exists.
• clean-volumes is irreversible.
• Fix permission issues: make state-fix-perms.

[geoffgeoffgeoff3]

Very good. I have updated the REAME. I also renamed clean-volumes to state-delete. Next question ... what is in volDB vs. volExport and VolStarexec? They are treated differently by state-init and state-create and state-delete

[AndresCdo]

volDB

• Path: $(SAVED_STATE_DIR)/volDB → /var/lib/mysql
• Holds all MariaDB data: system tables, ibdata1, logs, user DBs.
• Needs all-or-nothing: either keep it intact or fully reinit. state-create wipes only volDB and runs mysql_install_db for a clean DB. Healthcheck depends on this.

volExport

• Path: $(SAVED_STATE_DIR)/volExport → /export
• Stores StarExec artifacts: job outputs, result archives, solver uploads, benchmark packages, bundles.
• Safe across DB resets (files are just blobs). App can re-link via new DB rows.
• Owned by 153:160. Not cleared by state-create, only by state-delete.

volStarexec

• Path: $(SAVED_STATE_DIR)/volStarexec → /home/starexec
• StarExec home: configs, temp dirs, uploads, logs, cached solvers/benchmarks.
• Must persist across restarts. Owned by 152:160. Removed only by state-delete.

How targets handle them

• state-init: makes all three, fixes perms, initializes DB only if empty. Leaves export/home untouched.
• state-create: resets only volDB, keeps export/home, reapplies chown.
• state-delete: wipes everything (irreversible).

Quick check

ls -1 $(SAVED_STATE_DIR)/volDB | head
podman exec -it starexec-app bash -c "ls -1 /export | head"
podman exec -it starexec-app bash -c "du -sh /home/starexec/* 2>/dev/null | head"

[geoffgeoffgeoff3]

New aspects from email ...

Podman and mkcert must be treated as prerequisites. They should not be
silently installed inside make start, since that introduces privilege
prompts and OS-specific variance. Explicit dependency documentation in the
README is cleaner.
2.
A separate make software_install target is acceptable if you want
automation, but it should remain opt-in, not implicit in make start. Users
need to be aware they are installing system software.

Please add that target. Remove the installation of mkcert from "make start".
I will add a note in the README for users to run "make software_install",
or ensure they have podman and mkcert and libnss3-tools and (anything else?)
installed.