diff --git a/.continue/rules/global-file-standard.md b/.continue/rules/global-file-standard.md deleted file mode 100644 index 61f7f12..0000000 --- a/.continue/rules/global-file-standard.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -alwaysApply: true ---- - -Apply consistent coding standards, preserve existing project conventions, and avoid introducing breaking changes in all files unless explicitly requested. - -Also read and consider the repository state file when it exists: -- `STATE.md` - -When this file is present: -- use it as evolving project context, -- keep recommendations aligned with it, -- update suggestions to remain consistent with documented architecture, constraints, and review notes, -- update `STATE.md` as part of the same task whenever changes materially affect repository behavior, architecture, constraints, or review notes. \ No newline at end of file diff --git a/.memory/project.md b/.memory/project.md new file mode 100644 index 0000000..c2624bc --- /dev/null +++ b/.memory/project.md @@ -0,0 +1,30 @@ +# Project memory + +- Repo: `netupgrade` +- Language: Bash +- Entry point: `bin/netupgrade` +- Purpose: interactive SSH-based maintenance/upgrade CLI + +## Rules +- Keep it lightweight and shell-based +- Preserve backward compatibility when possible +- Treat config files as trusted shell input +- Be careful with SSH quoting and remote command construction +- Prefer small, reviewable changes +- Keep docs aligned with runtime behavior +- Avoid introducing `set -euo pipefail` without validating failure semantics + +## Current behavior +- Loads configs from `~/.config/netupgrade/*.cfg` +- Uses `NODES` entries: `host;display-name;action1;action2;...` +- Runs selected actions sequentially over SSH +- Defaults to `root@host`, or `SSH_USER@host` +- Logs to `~/netupgrade.log` +- Opens the log with `$EDITOR`, then `nano`, `vi`, or `less` + +## Sensitive areas +- SSH quoting +- `cmd:<...>` execution +- `docker-stacks:<...>` handling +- package-manager cleanup behavior +- error propagation \ No newline at end of file diff --git a/STATE.md b/STATE.md deleted file mode 100644 index 50100c7..0000000 --- a/STATE.md +++ /dev/null @@ -1,84 +0,0 @@ -# Repository state - -## Project summary -- Name: `netupgrade` -- Language: Bash -- Entry point: `bin/netupgrade` -- Purpose: interactive CLI to run maintenance and upgrade actions on multiple remote hosts over SSH -- Config model: Bash configuration files sourced from `~/.config/netupgrade/*.cfg` - -## Repository structure -- `bin/netupgrade`: main executable script containing CLI parsing, node selection, remote execution, and logging -- `config/netupgrade/*.cfg`: sample configuration files defining host groups and action sequences -- `README.md`: installation and usage documentation -- `TODO.md`: prioritized next actions and follow-up work - -## Current behavior -- Loads a Bash configuration file -- Expects a `NODES` array with entries formatted as `host;display-name;action1;action2;...` -- Displays an interactive multi-select checklist using `whiptail` -- Executes selected actions sequentially over SSH -- Uses `root@host` by default, or `SSH_USER@host` when configured -- Writes execution logs to `~/netupgrade.log` -- Opens the log with `$EDITOR`, then `nano`, `vi`, or `less`; if none is available, prints the log path and continues with the existing optional cleanup prompt - -## Supported actions -- `apt` -- `yum` -- `dnf` -- `pkg` -- `pacman` -- `apk` -- `reboot` -- `cmd:` -- `docker-stacks:` - -## Architecture and constraints -- The project is intentionally lightweight and shell-based -- The main execution flow still lives mostly in a single Bash script -- Configuration is code-driven rather than declarative, because config files are sourced as shell files -- Config files are trusted inputs and imply arbitrary code execution -- Remote operations are sequential, not parallel -- Logging is file-based and tightly coupled to command execution -- Backward compatibility for existing config files should be preserved where possible -- Changes to SSH command construction require extra care because quoting regressions are easy to introduce - -## Notable implementation details -- SSH execution is centralized through a `runSSH` helper -- `SSH_USER` is configurable and defaults to `root` -- `NODES` parsing was hardened to preserve spaces in action values such as `cmd:...` -- `cmd:<...>` is executed through a remote shell to support shell operators, but remains intentionally powerful and unsafe -- `reboot` now uses a direct SSH `reboot` invocation to keep the remote reboot path simple and predictable -- `docker-stacks` runs through a remote shell script sent over SSH stdin to improve path handling and quoting -- Startup dependency checks cover required local commands, including `mv` for log-summary rewriting - -## Sensitive areas for future changes -- SSH command construction and shell quoting behavior -- `cmd:<...>` execution semantics -- `docker-stacks:<...>` path handling and remote shell behavior -- Package-manager cleanup commands and confirmation flags -- Error propagation consistency across action types -- Documentation and runtime behavior alignment -- Sample configuration accuracy to avoid operator mistakes - -## Recent meaningful changes -- README and CLI help were aligned with current behavior, including the meaning of `-f` -- Startup dependency checks were added and updated -- Log viewer fallback was made more flexible -- `NODES` parsing was hardened to preserve spaces in action values -- SSH execution was centralized and made configurable through `SSH_USER` -- Remote command construction was improved for `pacman` and `docker-stacks`; `reboot` was simplified to a direct SSH command -- Log summary generation was rewritten to avoid `sed -i` interpolation and now replaces the log atomically -- `apk` and `apt` cleanup behavior was corrected to better match real package-manager semantics -- The sample configuration in `config/netupgrade/hypervisor-01.cfg` now keeps the alternate `docker-01` reboot example commented out rather than active by default -- A new `dnf` action was added alongside the existing `yum` action to support newer RPM-based systems without breaking existing configurations - -## Change guidance -- `STATE.md` should stay focused on current state, architecture, and constraints -- `TODO.md` should hold prioritized follow-up work and next implementation steps -- Prefer small, reviewable hardening changes over broad rewrites -- Keep the tool simple and admin-friendly -- Treat documentation consistency as part of functional correctness -- Be cautious with remote command construction, because quoting changes can easily introduce regressions -- Avoid introducing a global `set -euo pipefail` baseline in one step without first documenting and validating the intended failure semantics -- Focus future testing first on parsing, command construction, and result reporting diff --git a/TODO.md b/TODO.md deleted file mode 100644 index 07aea52..0000000 --- a/TODO.md +++ /dev/null @@ -1,33 +0,0 @@ -# TODO - -## Priorité haute - -### 1. Sécuriser les zones sensibles de construction de commandes SSH -- Revoir les zones de quoting encore fragiles -- Prioriser `cmd:<...>` et `docker-stacks:<...>` -- Réduire le risque de régressions lors des prochains durcissements - -## Priorité moyenne - -### 1. Ajouter un minimum de validation et de qualité shell -- Ajouter de la guidance ShellCheck dans le projet -- Envisager `shfmt` si cela reste léger -- Ajouter des vérifications simples autour des fichiers de configuration sourcés -- Rester incrémental, sans imposer brutalement un strict mode global - -### 2. Réduire progressivement la complexité du script principal -- Extraire des helpers quand cela réduit la duplication sans casser le comportement -- Simplifier les branches liées aux package managers -- Garder des changements petits et relisibles - -## Priorité basse - -### 1. Réfléchir à une configuration plus sûre si le projet grossit -- Le sourcing Bash reste acceptable tant que le modèle est assumé -- Si le projet s'étend, envisager à terme un format déclaratif plus sûr - -## Rappels de conduite -- Préserver la compatibilité des fichiers de configuration existants autant que possible -- Préférer de petits commits logiques -- Traiter la cohérence documentation/comportement comme un sujet fonctionnel -- Être particulièrement prudent sur toute modification du quoting ou des commandes distantes