# sysmig Lightweight tool that manages host state in DB-migration (Flyway) style. Started for a 1GB VM (`ocrt-postgres`), but deployable to any machine via cloud-init. ## Usage ```bash sudo bash /opt/sysmig/sysmig up # apply all pending migrations (idempotent) sudo bash /opt/sysmig/sysmig down # roll back the last migration sudo bash /opt/sysmig/sysmig down all # roll back everything (reverse order) bash /opt/sysmig/sysmig status # show status (no root required) ``` - Migrations: `migrations/NNN-name.sh`, receiving `up`/`down` as `$1` - Applied history: `/var/lib/sysmig/applied` - applied entries never re-run - On failure the run aborts at that step; earlier steps stay applied ## Adding a new migration 1. Create `migrations/NNN-name.sh` (number higher than existing; leave gaps) 2. Implement both `up` and `down` cases - both must actually work 3. Commit & push, then on the server: `git pull && sudo bash sysmig/sysmig up` ## cloud-init integration ```yaml #cloud-config runcmd: - [ git, clone, , /opt/sysmig ] - [ bash, /opt/sysmig/sysmig, up ] ``` For a private repo you need an auth strategy: - **deploy key** (existing machines): register a read-only key on the repo - **fleet rollout**: make the repo public, or embed a read-only token in the https URL ## Current migrations | # | name | effect | |----|----------------------------|-----------------------------------------------| | 001 | create-swap | 2GB swap + fstab + vm.swappiness=10 | | 002 | disable-networkd-dispatcher| reclaim ~27MB RAM | | 003 | purge-exim4 | reclaim ~21MB RAM (package removed) | | 004 | purge-haveged | reclaim ~8MB RAM (package removed) | | 005 | mount-pgdata | /dev/sdb (20G) -> /var/lib/postgresql, fstab | | 006 | install-postgres | PG 18 via PGDG repo, cluster on the disk | ## Roadmap - `010-tune-postgres` - 1GB tuning (shared_buffers=128MB, work_mem=4MB, max_connections=30, ...)