> ## Documentation Index
> Fetch the complete documentation index at: https://link.datarelay.run/llms.txt
> Use this file to discover all available pages before exploring further.

# Linux Client

> Enroll and verify a Linux/systemd client using the current stable workflow.

# Linux Client

Linux/systemd remains the product's server and Linux-client foundation. In stable v2.2.1, client validation also includes macOS Apple Silicon and Windows 10 / PowerShell 5.1. For Linux, Ubuntu 24 physical, Rocky Linux 8.10/9.4, and Amazon Linux 2023 are Real E2E validated; Amazon Linux 2 remains container/CI portability only.

## What the client needs

Before enrollment, confirm:

* `sudo`/root access is available for installation
* the client can make outbound connections to the Data Relay Link server public endpoints
* any service you want to publish already exists and is reachable from the client
* for SSH, the SSH user already exists and `sshd` is running

Data Relay Link does not create operating-system users, passwords, SSH keys, or application services.

## Client lifecycle at a glance

The original field guide used the following lifecycle diagram to show where enrollment, service configuration, normal operation, updates, and removal fit together.

<img src="https://mintcdn.com/data-relay/RziF2R9Wr8UU8L7K/images/guides/50.png?fit=max&auto=format&n=RziF2R9Wr8UU8L7K&q=85&s=454b75c62f8663b4006c1d1663a6425b" alt="Data Relay Link client lifecycle" width="1448" height="1086" data-path="images/guides/50.png" />

The current v2.2.1 rule is the same at a high level: enroll once, keep the persistent CLIENT ID, change services through `drlink`, update without re-enrollment, and use the explicit lifecycle operations when retiring a client or releasing ports.

## Choose enrollment method

| Method                     | Best when                                            | Who chooses initial services? |
| -------------------------- | ---------------------------------------------------- | ----------------------------- |
| **Zero-Touch**             | server admin wants a ready-to-run command            | server admin                  |
| **Manual Enrollment Code** | remote operator should choose services interactively | remote operator               |

```mermaid theme={null}
flowchart TD
    A[Need to enroll a client] --> B{Should the server admin\npredefine the initial profile?}
    B -->|Yes| Z[Zero-Touch]
    B -->|No| M[Manual Enrollment Code]
    Z --> R[Run generated command once]
    M --> R
    R --> V[Verify client + server state]
```

## Recommended: Zero-Touch

For the easiest interactive server workflow:

```bash theme={null}
sudo drlink
```

Then:

```text theme={null}
create zero-touch
```

For an explicit SSH profile:

```bash theme={null}
sudo drlink create enrollment \
  --one-line \
  --ssh \
  --ssh-user <ssh-user> \
  --label branch-a
```

Replace `<ssh-user>` with an SSH account that already exists on the target machine. Run the **exact generated command** on the client; do not reconstruct the bootstrap payload manually.

## Manual Enrollment Code

On the server:

```bash theme={null}
sudo drlink create enrollment
```

Run the generated client bootstrap command and enter the short-lived Enrollment Code when prompted. The installer can then guide the remote operator through service selection.

## What happens during enrollment

```mermaid theme={null}
sequenceDiagram
    participant C as Linux client
    participant S as Data Relay Link server

    C->>S: bootstrap credential over HTTPS
    C->>C: verify server trust / CA path
    C->>S: enrollment
    S-->>C: CLIENT identity + service config
    C->>S: start outbound Data Relay Link control tunnel
```

## Verify on the client

```bash theme={null}
sudo drlink show version
sudo drlink show status
sudo drlink show services
sudo drlink show info
sudo drlink doctor
```

## Verify on the server

```bash theme={null}
sudo drlink show clients
sudo drlink show enrollments
sudo drlink show client <CLIENT-ID>
sudo drlink show client <CLIENT-ID> services
```

The client receives a persistent CLIENT ID. Normal reboots, supported service edits, and normal stable project updates do not require a new enrollment.

## Changing services later

Client-side service edits are staged:

```text theme={null}
add service
set service <service-id> target-host <host>
set service <service-id> target-port <port>
apply
```

Use `discard` before `apply` if you want to throw away pending changes.

## Important lifecycle rule

```text theme={null}
client uninstall != server release
```

Removing local client software does not automatically free the server's public-port reservations. See [Lifecycle Semantics](/operations/lifecycle).