jcoffey-dev
7e04351b0f
Two changes that arrived together: the cutover phase (ARCHITECTURE.md 4.5) is implemented, and the rollback phase is deleted. Recovery from a failed migration is now explicitly the operator's own snapshot or backup, and out of scope for this tool. internal/cutover implements 4.5 as seven checkpointed steps: verify the staged binary's version, install it, preserve and rewrite the service definition, reload, start, wait for a healthy JMAP session, recalculate quotas. The unit is rewritten in place rather than generated from a template. An operator's unit carries hardening options, limits and dependencies this tool has no business having an opinion about, and regenerating it would silently drop them. It repoints ExecStart (preserving systemd's -@:+! prefix characters and every argument after the executable), updates --config, and strips recovery-mode Environment lines - leaving STALWART_RECOVERY_MODE=1 set would recovery-boot the service on every restart, forever. It refuses on a unit with no ExecStart, and on an Environment line mixing a recovery variable with others: a line it only partly understands is one it must not edit. Quota recalculation is the one step allowed to fail without failing the phase. Its wire format is grounded in Stalwart's x:Task schema reference - Task/set creating one AccountMaintenance per account with maintenanceType recalculateQuota - but the upgrade guide only documents the WebUI path, so two details remain inferred and are called out in stalwartapi/task.go: whether the schema's "read-only" annotation on accountId/maintenanceType means "immutable after creation", and whether a finished task simply leaves the queue (TaskStatus documents Pending/Retry/Failed with no success state). Warning rather than failing is the honest response to that uncertainty, and stale counters are an accounting problem next to calling for a restore of a machine that is otherwise migrated and serving mail. Docker deployments are refused outright: cutting a container over means pulling an image and recreating it, not swapping a binary. On removing rollback. The implementation worked and was tested, and it was removed because restoring bytes correctly is not the hard part. It copied file contents and permissions and verified every restored file against a manifest - and did not preserve ownership. Run as root, as this tool requires, it would have produced a byte-perfect, checksum-verified, root-owned data directory that Stalwart, running as its own user, could not open, and it would have reported success. The PostgreSQL path was worse: pg_dump without --clean emits CREATE TABLE + COPY, which fails replaying into a database whose tables still exist, and the ON_ERROR_STOP=1 added so a half-applied restore couldn't be reported as success turned that into a hard failure. None of it had ever run against a real server. A filesystem snapshot has none of these failure modes, because it never lost the metadata to begin with. So cutover's gate is no longer rollback.CanRollBack but an explicit RecoveryPointConfirmed acknowledgement. That is an assertion, not a check - this tool cannot verify someone else's snapshot - and its only value is that nobody migrates a production mail server having never been asked the question. Two consequences are accepted deliberately: restoring any pre-migration recovery point discards mail delivered since, and a failed migration now stops and reports rather than undoing itself. What the tool still does to make a manual restore easier: the old binary is preserved and never deleted, the original service definition is preserved before the rewrite, the settings and principals dumps stay on disk, and every artifact path and checksum stays in the checkpoint where `status <run-id>` can print it. Also removed: the `confirm` command stub and RollbackWindowClosed, whose only purpose was closing a rollback window that no longer exists, and checkpoint.PhaseRollback. Old state.json files still load - JSON ignores the now-unknown field. Still open, and recorded in 8: cutover ignores systemd drop-ins, so an ExecStart or Environment override in stalwart.service.d/*.conf is invisible to the rewrite - including the recovery variable it exists to strip; nothing prevents concurrent runs on the same run-id; and nothing in this repo has ever run against a real Stalwart, real systemd, or a real store.
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 restarts 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
|
|
}
|