b35a3d6574
There has been over 1 year of commit history leading up to this point, but almost all of that has had some kind network configuration or secrets built into the code. As of today all of that has been removed, and the codebase can finally be published! I am keeping a private copy of the previous commit history, though it's unclear if it will ever be able to be published.
95 lines
3.1 KiB
Markdown
95 lines
3.1 KiB
Markdown
# Adding a Host to the Network
|
|
|
|
This document guides an admin through adding a single host to the network. Keep
|
|
in mind that the steps described here must be done for _each_ host the user
|
|
wishes to add.
|
|
|
|
There are two ways for a user to add a host to the cryptic-net network.
|
|
|
|
- If the user is savy enough to obtain their own `cryptic-net` binary, they can
|
|
do so. The admin can then generate a `bootstrap.tgz` file for their host,
|
|
give that to the user, and the user can run `cryptic-net daemon` using that
|
|
bootstrap file.
|
|
|
|
- If the user is not so savy, the admin can generate a custom `cryptic-net`
|
|
binary with the `bootstrap.tgz` embedded into it. The user can be given this
|
|
binary and run `cryptic-net daemon` without any configuration on their end.
|
|
|
|
From the admin's perspective the only difference between these cases is one
|
|
extra step.
|
|
|
|
## Step 1: Choose Hostname
|
|
|
|
The user will need to provide you with a name for their host. The name should
|
|
conform to the following rules:
|
|
|
|
* It should only contain lowercase letters, numbers, and hyphens.
|
|
|
|
* It should begin with a letter.
|
|
|
|
* It should end with a letter or number.
|
|
|
|
## Step 2: Add Host to Network
|
|
|
|
The admin should choose an IP for the host. The IP you choose for the new host
|
|
should be one which is not yet used by any other host, and which is in the VPN's
|
|
set of allowed IPs.
|
|
|
|
The admin should perform the following command from their own host:
|
|
|
|
```
|
|
cryptic-net hosts add --name <name> --ip <ip>
|
|
```
|
|
|
|
## Step 3: Create a `bootstrap.tgz` File
|
|
|
|
Access to an `admin.tgz` file is required for this step.
|
|
|
|
To create a `bootstrap.tgz` file for the new host, the admin should perform the
|
|
following command from their own host:
|
|
|
|
```
|
|
cryptic-net hosts make-bootstrap \
|
|
--name <name> \
|
|
--admin-path <path to admin.tgz> \
|
|
> bootstrap.tgz
|
|
```
|
|
|
|
The resulting `bootstrap.tgz` file should be treated as a secret file that is
|
|
shared only with the user it was generated for. The `bootstrap.tgz` file should
|
|
not be re-used between hosts either.
|
|
|
|
If the user already has access to a `cryptic-net` binary then the new
|
|
`bootstrap.tgz` file can be given to them as-is, and they can proceed with
|
|
running their host's `cryptic-net daemon`.
|
|
|
|
### Encrypted `admin.tgz`
|
|
|
|
If `admin.tgz` is kept in an encrypted format on disk (it should be!) then the
|
|
decrypted form can be piped into `make-bootstrap` over stdin. For example, if
|
|
GPG is being used to secure `admin.tgz` then the following could be used to
|
|
generate a `bootstrap.tgz`:
|
|
|
|
```
|
|
gpg -d <path to admin.tgz.gpg> | cryptic-net hosts make-boostrap \
|
|
--name <name> \
|
|
--admin-path - \
|
|
> bootstrap.tgz
|
|
```
|
|
|
|
Note that the value of `--admin-path` is `-`, indicating that `admin.tgz` should
|
|
be read from stdin.
|
|
|
|
## Step 4: Optionally, Build Binary
|
|
|
|
If you wish to embed the `bootstrap.tgz` into a custom binary for the user (to
|
|
make installation _extremely_ easy for them) then you can run the following:
|
|
|
|
```
|
|
nix-build --arg bootstrap <path to bootstrap.tgz> -A appImage
|
|
```
|
|
|
|
The resulting binary can be found in the `result` directory which is created.
|
|
Note that this binary should be treated like a `bootstrap.tgz` in terms of its
|
|
uniqueness and sensitivity.
|