Native Agent Installation
install-agent.sh runs configuration, environment file updates, package download, package installation, folder preparation, service restart, and status. There is no separate service-stop step. 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.
Registration defaults to /host/var/lib/daployi-agent/registration.json, matching the agent. Unset, empty, and whitespace-only values use this default. Surrounding whitespace is trimmed from custom paths, and saved nonempty paths are retained unless explicitly overridden.
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, 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
Before package installation, the installer removes any leftover 95-daployi-install-preparation.conf runtime drop-in from the previous installer and reloads systemd so package hooks can start or restart the service. The sequence is package installation, folder preparation, service restart, and status.
If preparation fails, fix the reported error and rerun the installer. The installer exits before its final restart and leaves no startup guard. 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.