Native Agent Installation
install-agent.sh retains the original installation sequence: configuration, environment file, package download, package installation, service stop, service restart, and status. The original banner and configuration defaults remain, including HOST_FS_MOUNT=/host and DAPLOYI_ENVIRONMENT=docker.
The installer uses Bash and standard Linux utilities. It does not install a language runtime or a persistent pre-start helper. Supply the project token and control server settings appropriate to your deployment.
Configuration and directories
Explicit installer variables override saved values in /etc/default/daployi-agent. Other saved settings are retained. The environment file is replaced using a private temporary file and is owned by root:root with mode 0600. Configuration is parsed as data, never sourced or evaluated.
New native registration defaults to /var/lib/daployi-agent/registration.json. Explicit custom paths are respected. An existing legacy registration file under /host/var/lib/daployi-agent is retained when the configured path is empty. If both locations contain state, choose REGISTRATION_STATE_FILE explicitly.
Paths must be nonempty and absolute, without symlink, . or .. components or repeated/trailing slashes. A registration destination must be a regular file when it already exists. Registration contents are preserved; the installer does not create an empty registration file.
After package installation and the original service-stop step, the installer prepares:
| Purpose | Directory |
|---|---|
| Registration | Parent of REGISTRATION_STATE_FILE |
| Persisted results | REGISTRATION_STATE_FILE with .results appended |
| Compose, when enabled | DAPLOYI_AGENT_DIR/compose |
| Scripts and logs | .daployi/scripts and its logs directory beneath the service HOME |
| Script layout compatibility | DAPLOYI_AGENT_DIR/scripts and its logs directory |
DAPLOYI_AGENT_DIR defaults to .daployi beneath the service HOME. Preparation reads the installed systemd service's user, group, environment, and environment files. Newly created application directories normally have mode 0700 and belong to that service identity. Known application directories are repaired without recursively changing ownership. Existing shared parents of custom registration paths are left unchanged. Existing registration files are secured with mode 0600.
The installer verifies creating, writing, syncing, renaming, and removing a temporary file in each required directory as the service user. sync must support individual file operands, as GNU coreutils does. Overrides to another service identity require runuser. Failures report the path, identity, operation, and underlying utility error. Registration JSON validation remains the agent's responsibility.
Startup and reruns
A temporary systemd condition holds package-hook starts until directory preparation succeeds. The original service-stop step stays after package installation. The condition is removed immediately before the original restart and status steps.
If preparation fails, fix the reported error and rerun the installer. The temporary startup hold remains for the current boot. This is an installation-time check; the agent must retain its own startup checks for permission or mount changes after installation. DynamicUser, RootDirectory, and RootImage services require a separate preparation strategy.
RPM installation uses --replacepkgs to allow reinstallation. Downloads use a private temporary directory to avoid collisions with packages owned by another user. Local packages and custom download URLs still work.
Interactive installs authenticate with sudo once when necessary. Unattended installs require root or noninteractive sudo. Successful service startup is reported separately from device registration; inspect the agent's registration status or logs for that result.
If the earlier rewritten installer was used, a successful run removes only its known helper files and persistent systemd drop-ins. Registration data is retained. No persistent replacement helper is installed.