Files
nexus-sync/docs/client.md
T
2026-06-25 02:39:25 +03:00

61 lines
1.8 KiB
Markdown

# Client
The core idea - it sends its key and basic info about itself (hostname, local
time, anything else?) to a server known by ip/domain.
In response it can get either a plain "ok" or a command to execute.
It sends requests to the server at a certain frequency, gradually increasing but
dropping sharply when a command is received in the response (in case something
else needs to be executed).
There is a lower bound on the frequency (roughly 1/minute).
Example flow
```
...
client -> server: hello!, i'm $(hostname), uuid= , ts=
server -> client: ok, 200
*waits 45s*
client -> server: hello!, i'm $(hostname), uuid= , ts=
server -> client: ok, 200
*waits 46s*
client -> server: hello!, i'm $(hostname), uuid= , ts=
server -> client: ok, execute "ip a", 200
client: *execute*
client -> server: hello!, i'm $(hostname), uuid= , ts=, stdout= , stderr= , ...
*waits 23s*
```
Additional info about command execution may be needed (at least the error code).
+ the set of allowed commands should probably be limited on the client
+ encryption / server identification should be considered explicitly
## Allowed commands
The client runs only the commands described in its local YAML config file. Only
`name` and `description` are sent to the server; the `cmd` field stays on the
client and is not controlled by the server.
Example:
```yaml
server_url: "http://127.0.0.1:5852"
client_id: "linux-client"
client_token: "change-me-client-token"
allowed_commands:
- name: hostname
description: "Get the hostname of the client machine"
cmd: "hostname"
- name: network_interfaces
description: "Get network interface information"
cmd: "ip addr show"
logging_level: "INFO"
```
The file is looked up as `nexus.yml`/`nexus.yaml` in the current directory, then
in `$XDG_CONFIG_HOME`, then in `~/.config`, then as
`~/.config/nexus/config.yml`/`.yaml`.