jcoffey-dev
ade9906275
Rollback was the one phase gating everything else: `run` without --dry-run refused because this tool could not undo a cutover it had committed to. That reason is now gone, and the refusal has narrowed to the fact that there is no real cutover to undo yet. internal/rollback implements ARCHITECTURE.md 4.8 as eight checkpointed steps under PhaseRollback: verify-backup, stop-service, preserve-failed-state, restore-data, restore-binary, restore-service-config, start-service, verify-rollback. Three things depart from what 4.8 specified, each for a reason: - The backup is re-verified against its manifest *before* the service is stopped, which the design didn't call out. Finding a corrupt backup is survivable while the failed instance is still up, and unsurvivable once its data directory has been moved aside. - BuildPlan is separate from Run, so every reason to refuse (closed rollback window, FoundationDB, no recorded backup, unknown deployment kind, missing database credentials) is found before anything is touched. The CLI prints that resolved plan and acts only with --yes. - The restore is re-verified against the same manifest after writing. A restore that put back truncated bytes and reported success would be worse than one that failed outright. Nothing from the failed attempt is deleted: the half-migrated data directory and the displaced binary are moved to .failed-<run-id> names, so a retry after the underlying issue is fixed still has both the evidence and the artifacts. Afterwards a reduced validation suite runs against the *restored* instance (version, reachability, directory counts) rather than assuming the restore worked. internal/service is a new package holding the systemd/Docker control this needs. It's separate rather than living inside internal/rollback because cutover will need the identical operations, and because the commands that can take mail delivery down belong in one auditable place - the same reasoning that makes stalwartapi the only thing speaking JMAP. preflight.DeploymentKind is now a type alias for service.Kind so detection and control can't drift apart. Its Active() reads `systemctl is-active`'s output rather than its exit status: systemctl exits non-zero for every non-active state, so exit-status logic would make "inactive" - the answer a rollback most needs - look like a failure to read the state at all. Also fixes a pre-existing bug in `status`: Go's flag package stops parsing at the first positional argument, so `status <run-id> --state-dir X` looked the run up in the default directory and reported it missing. `rollback` would have inherited the same footgun on a command whose flags decide what gets overwritten. Still open: `confirm` cannot set RollbackWindowClosed. Rollback honours the flag and refuses when it's set, but closing the window is the point of no return for the backups this restores from, so it should land with the retention policy 6 describes rather than before it. Verified end to end against a fake systemd deployment: half-migrated data restored to its original contents, failed state preserved, old binary reinstalled and reporting 0.15.5, unit restarted, and a re-run of the completed rollback inert.
51 lines
1.5 KiB
Go
51 lines
1.5 KiB
Go
package preflight
|
|
|
|
import (
|
|
"context"
|
|
"os"
|
|
"os/exec"
|
|
|
|
"github.com/LINUXexpert-org/stalwart-migrator/internal/service"
|
|
)
|
|
|
|
// DeploymentKind is how a Stalwart instance appears to be run, which
|
|
// determines how cutover and rollback restart it. It's an alias for
|
|
// service.Kind rather than a parallel type: detection here and control
|
|
// there have to agree on the same vocabulary, and one definition can't
|
|
// drift from itself.
|
|
type DeploymentKind = service.Kind
|
|
|
|
const (
|
|
DeploymentSystemd = service.Systemd
|
|
DeploymentDocker = service.Docker
|
|
DeploymentUnknown = service.Unknown
|
|
)
|
|
|
|
var systemdUnitPaths = []string{
|
|
"/etc/systemd/system/stalwart.service",
|
|
"/lib/systemd/system/stalwart.service",
|
|
"/usr/lib/systemd/system/stalwart.service",
|
|
}
|
|
|
|
// DetectDeploymentKind makes a best-effort guess at how Stalwart is run
|
|
// here. It's deliberately conservative and cheap (file stats, one docker
|
|
// inspect) rather than exhaustive - an operator-supplied override should
|
|
// always be able to win over this, since the cost of guessing wrong here is
|
|
// cutover targeting the wrong thing.
|
|
func DetectDeploymentKind(ctx context.Context, containerName string) DeploymentKind {
|
|
for _, p := range systemdUnitPaths {
|
|
if _, err := os.Stat(p); err == nil {
|
|
return DeploymentSystemd
|
|
}
|
|
}
|
|
if containerName == "" {
|
|
containerName = "stalwart"
|
|
}
|
|
if _, err := exec.LookPath("docker"); err == nil {
|
|
if err := exec.CommandContext(ctx, "docker", "inspect", containerName).Run(); err == nil {
|
|
return DeploymentDocker
|
|
}
|
|
}
|
|
return DeploymentUnknown
|
|
}
|