GURDN

Documentation / Operating it

Installation

What is installed, where, and what the installer refuses.

There is no public release yet. This page describes how installation works so it can be reviewed before one exists. See release status.

Requirements

  • Windows on 64-bit x86. There is no 32-bit or Arm build.
  • Administrative rights, for the installation only.
  • No account, no licence server and no network connection to install.

What is installed

  • The desktop interface and the privileged service executables, under Program Files.
  • A Windows service, registered under its own restricted service identity.
  • A data directory under ProgramData for the local store and the audit record.
  • Restrictive permissions on both, applied and then read back to confirm.

The install location is resolved from Windows rather than assembled from environment variables, so a machine with relocated system folders is handled correctly.

It runs as a transaction

Install, repair, upgrade and uninstall are one lifecycle, not four scripts. Every step records how to undo itself and reports whether it was already satisfied, so a repair does not redo work that is already correct. The phase is written before the work, so an interrupted run is visible to the next one.

A failure at any point walks the completed steps back. The reason is simple: a machine with the service registered but its files missing, or its directories created but unprotected, is less safe than a machine without GURDN at all.

What it refuses

  • Running unelevated. Checked first, so the result is a clear refusal rather than a half-finished install.
  • Writing outside its own directories. Every path is checked for containment, including paths that reach outside by crossing a junction or other reparse point.
  • Destructive uninstallation when ownership is uncertain. If GURDN cannot establish that something belongs to it, it leaves it and says so. There is no override flag, deliberately.

Exit codes

Every outcome has a specific code rather than a general failure, so an automated deployment can tell the difference between already installed, reboot required, a missing prerequisite, access denied, a service failure, a rolled back attempt, a mixed state, a corrupt package, an incompatible version and a refusal by security policy. Codes that mean a retry might help are distinguishable from those that do not.

Uninstallation

Uninstalling removes the service, the files and the machine changes GURDN made, putting back what it recorded before it changed them. Local data can be kept or removed, as a separate choice. Anything whose ownership cannot be established is left in place and reported.