operators-guide: created generic docs maintenance.md and preliminary-steps.md to avoid redundancy

This commit is contained in:
serinko
2023-07-14 13:25:12 +02:00
committed by mfahampshire
parent cbee6153bd
commit 55cd1a8b91
8 changed files with 667 additions and 35 deletions
+3
View File
@@ -3,8 +3,11 @@
# Operators Guides
- [Node Setup Guides](./nodes/setup-guides.md)
- [Preliminary Steps](./preliminary-steps.md)
- [Mix Node](./nodes/mix-node-setup.md)
- [Gateway](./nodes/gateway-setup.md)
- [Network Requester](./nodes/network-requester-setup.md)
- [Validator](./nodes/validator-setup.md)
- [Maintenance](./nodes/maintenance.md)
- [Troubleshooting](./nodes/troubleshooting.md)
- [FAQ](./faq.md)
+7
View File
@@ -4,4 +4,11 @@ TODO
- [ ] List friendly VPS providers
- [ ] Explain difficulty running a node on a self-hosted machine
- [ ] Explain uNYM vs NYM. Why, ratio, etc
Some community questions:
Hi, do you know if it's on the roadmap for network nodes (requesters, socks5 client, etc.) to reconnect to another gateway if the current gateway's connection drops or has issues? I have to reset my requester and socks5 clients to connect them to a new gateway almost every day...😕 having to delete the entire folders associated with them
you should be able to switch gateway (and overwrite keys) using —force-register
--->
Binary file not shown.

After

Width:  |  Height:  |  Size: 115 KiB

+2 -1
View File
@@ -23,7 +23,8 @@ If you are looking for information on grants and beta-release Nym apps, check ou
* [Network requesters](./nodes/network-requester-setup.md)
* [Validators](./nodes/validator-setup.md)
**Troubleshooting and FAQ**
**Maintenance, troubleshooting and FAQ**
* [Maintenance](./nodes/maintenance.md)
* [Troubleshooting](./nodes/troubleshooting.md)
* [FAQ](./faq.md)
@@ -1 +1,253 @@
# Gateway
# Gateways
> The Nym gateway was built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first.
> Any syntax in `<>` brackets is a user's unique variable. Exchange with a corresponding name without the `<>` brackets.
## Current version
```
<!-- cmdrun ../../../../target/release/nym-gateway --version | grep "Build Version" | cut -b 21-26 -->
```
## Preliminary steps
Make sure you do the preparation listed in the [preliminary steps page](../preliminary-steps.md) before setting up your gateway.
## Gateway setup
Now that you have built the codebase, set up your wallet, and have a VPS with the `nym-gateway` binary, you can set up your gateway with the instructions below.
To begin, move to `/taget/release` directory from which you run the node commands:
```
cd target/release
```
### Viewing command help
You can check that your binaries are properly compiled with:
```
./nym-gateway --help
```
~~~admonish example collapsible=true title="Console output"
```
<!-- cmdrun ../../../../target/release/nym-gateway --help -->
```
~~~
You can also check the various arguments required for individual commands with:
```
./nym-gateway <COMMAND> --help
```
### Initialising your gateway
To check available configuration options use:
```
./nym-gateway init --help
```
~~~admonish example collapsible=true title="Console output"
```
<!-- cmdrun ../../../../target/release/nym-gateway init --help -->
```
~~~
The following command returns a gateway on your current IP with the `id` of `supergateway`:
```
./nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq
```
~~~admonish example collapsible=true title="Console output"
```
<!-- cmdrun ../../../../target/release/nym-gateway init --id supergateway --host $(curl ifconfig.me) --wallet-address n1eufxdlgt0puwrwptgjfqne8pj4nhy2u5ft62uq -->
```
~~~
The `$(curl ifconfig.me)` command above returns your IP automatically using an external service. Alternatively, you can enter your IP manually if you wish. If you do this, remember to enter your IP **without** any port information.
### Bonding your gateway
#### Via the Desktop wallet
You can bond your gateway via the Desktop wallet.
1. Open your wallet, and head to the `Bonding` page, then select the node type `Gateway` and input your node details (Location format is <CITY>, <COUNTRY>). Press `Next`
2. Enter the `Amount`, `Operating cost` and press `Next`.
3. You will be asked to run a the `sign` command with your `gateway` - copy and paste the long signature as the value of `--contract-msg` and run it.
```
./nym-mixnode sign --id <YOUR_ID> --contract-msg <PAYLOAD_GENERATED_BY_THE_WALLET>
```
It will look something like this:
~~~admonish example collapsible=true title="Console output"
```
./nym-gateway sign --id upgrade_test --contract-msg 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a
_ __ _ _ _ __ ___
| '_ \| | | | '_ \ _ \
| | | | |_| | | | | | |
|_| |_|\__, |_| |_| |_|
|___/
(nym-gateway - version {{platform_release_version}})
>>> attempting to sign 2Mf8xYytgEeyJke9LA7TjhHoGQWNBEfgHZtTyy2krFJfGHSiqy7FLgTnauSkQepCZTqKN5Yfi34JQCuog9k6FGA2EjsdpNGAWHZiuUGDipyJ6UksNKRxnFKhYW7ri4MRduyZwbR98y5fQMLAwHne1Tjm9cXYCn8McfigNt77WAYwBk5bRRKmC34BJMmWcAxphcLES2v9RdSR68tkHSpy2C8STfdmAQs3tZg8bJS5Qa8pQdqx14TnfQAPLk3QYCynfUJvgcQTrg29aqCasceGRpKdQ3Tbn81MLXAGAs7JLBbiMEAhCezAr2kEN8kET1q54zXtKz6znTPgeTZoSbP8rzf4k2JKHZYWrHYF9JriXepuZTnyxAKAxvGFPBk8Z6KAQi33NRQkwd7MPyttatHna6kG9x7knffV6ebGzgRBf7NV27LurH8x4L1uUXwm1v1UYCA1WSBQ9Pp2JW69k5v5v7G9gBy8RUcZnMbeL26Qqb8WkuGcmuHhaFfoqSfV7PRHPpPT4M8uRqUyR4bjUtSJJM1yh6QSeZk9BEazzoJqPeYeGoiFDZ3LMj2jesbJweQR4caaYuRczK92UGSSqu9zBKmE45a
>>> decoding the message...
>>> message to sign: {"nonce":0,"algorithm":"ed25519","message_type":"gateway-bonding","content":{"sender":"n1ewmme88q22l8syvgshqma02jv0vqrug9zq9dy8","proxy":null,"funds":[{"denom":"unym","amount":"100000000"}],"data":{"gateway":{"host":"62.240.134.189","mix_port":1789,"clients_port":9000,"location":"62.240.134.189","sphinx_key":"FKbuN7mPdoCG9jA3CkAfXxC5X4rHhqeMVtmfRtJ3cFZd","identity_key":"3RoAhR8gEdfBETMjm2vbMFzKddxXDdE9ygBAnJHWqSzD","version":"1.1.13"}}}}
```
~~~
* Copy the resulting signature:
```
>>> The base58-encoded signature is:
2SPDjLjX4b6XEtkgG7yD8Znsb1xycL1edFvRK4JcVnPsM9k6HXEUUeVS6rswRiYxoj1bMgiRKyPDwiksiuyxu8Xi
```
* And paste it into the wallet nodal, press `Next` and confirm the transaction.
![Paste Signature](../images/wallet-screenshots/wallet-gateway-sign.png)
* Your gateway is now bonded.
> You are asked to `sign` a transaction on bonding so that the mixnet smart contract is able to map your nym address to your node. This allows us to create a nonce for each account and defend against replay attacks.
#### Via the CLI (power users)
If you want to bond your mix node via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#bond-a-mix-node) docs.
### Running your gateway
The `run` command starts the gateway:
```
./nym-gateway run --id <YOUR_ID>
```
### Upgrading your gateway
Upgrading your node is a two-step process:
* Updating the binary and `config.toml` on your VPS
* Updating the node information in the [mixnet smart contract](../nyx/mixnet-contract.md). **This is the information that is present on the [mixnet explorer](https://explorer.nymtech.net)**.
>These instructions are specifically regarding upgrading your gateway binary from one version to another. If you want to change node information such as the listening port, you can do this by clicking the `node settings` tab in the `Bonding` page of the wallet.
#### Step 1: Upgrading your binary
Follow these steps to upgrade your binary and update its config file:
* pause your gateway process.
* replace the existing binary with the newest binary (which you can either compile yourself or grab from our [releases page](https://github.com/nymtech/nym/releases)).
* re-run `init` with the same values as you used initially. **This will just update the config file, it will not overwrite existing keys**.
* restart your gateway process with the new binary.
> Do **not** use the `upgrade` command: there is a known error with the command that will be fixed in a subsequent release.
#### Step 2: Updating your node information in the smart contract
Follow these steps to update the information about your node which is publically avaliable from the [Nym API](https://validator.nymtech.net/api/swagger/index.html) and information displayed on the [mixnet explorer](https://explorer.nymtech.net).
You can either do this graphically via the Desktop Wallet, or the CLI.
#### Updating node information via the Desktop Wallet
* Navigate to the `Bonding` page and click the `Node Settings` link in the top right corner:
![Bonding page](../images/wallet-screenshots/bonding.png)
* Update the fields in the `Node Settings` page and click `Submit changes to the blockchain`.
![Node Settings Page](../images/wallet-screenshots/node_settings.png)
#### Updating node information via the CLI
If you want to bond your mix node via the CLI, then check out the [relevant section in the Nym CLI](../tools/nym-cli.md#upgrade-a-mix-node) docs.
## VPS Setup and Automation
### Configure your firewall
Although your gateway is now ready to receive traffic, your server may not be - the following commands will allow you to set up a properly configured firewall using `ufw`:
```
# check if you have ufw installed
ufw version
# if it is not installed, install with
sudo apt install ufw -y
# enable ufw
sudo ufw enable
# check the status of the firewall
sudo ufw status
```
Finally open your gateway's p2p port, as well as ports for ssh and incoming traffic connections:
```
sudo ufw allow 1789,22,9000/tcp
# check the status of the firewall
sudo ufw status
```
For more information about your gateway's port configuration, check the [gateway port reference table](#gateway-port-reference) below.
### Automating your gateway with systemd
Although it's not totally necessary, it's useful to have the gateway automatically start at system boot time. Here's a systemd service file to do that:
```ini
[Unit]
Description=Nym Gateway ({{platform_release_version}})
StartLimitInterval=350
StartLimitBurst=10
[Service]
User=nym
LimitNOFILE=65536
ExecStart=/home/nym/nym-gateway run --id supergateway
KillSignal=SIGINT
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
```
Put the above file onto your system at `/etc/systemd/system/nym-gateway.service`.
Change the path in `ExecStart` to point at your gateway binary (`nym-gateway`), and the `User` so it is the user you are running as.
If you have built nym on your server, and your username is `jetpanther`, then the start command might look like this:
`ExecStart=/home/jetpanther/nym/target/release/nym-gateway run --id your-id`. Basically, you want the full `/path/to/nym-gateway run --id whatever-your-node-id-is`
Then run:
```
systemctl enable nym-gateway.service
```
Start your node:
```
service nym-gateway start
```
This will cause your node to start at system boot time. If you restart your machine, the node will come back up automatically.
You can also do `service nym-gateway stop` or `service nym-gateway restart`.
Note: if you make any changes to your systemd script after you've enabled it, you will need to run:
```
systemctl daemon-reload
```
This lets your operating system know it's ok to reload the service configuration.
## Gateway related Validator API endpoints
Numerous gateway related API endpoints are documented on the Validator API's [Swagger Documentation](https://validator.nymtech.net/api/swagger/index.html). There you can also try out various requests from your broswer, and download the response from the API. Swagger will also show you what commands it is running, so that you can run these from an app or from your CLI if you prefer.
## Ports
All gateway specific port configuration can be found in `$HOME/.nym/gateways/<your-id>/config/config.toml`. If you do edit any port configs, remember to restart your gateway.
### Gateway port reference
| Default port | Use |
|--------------|---------------------------|
| 1789 | Listen for Mixnet traffic |
| 9000 | Listen for Client traffic |
@@ -0,0 +1,357 @@
# Maintenance
<!---
TODO
- [ ] Compare mixnode, gateway and NR steps of upgrading and automation and make a generic page - this one - for all of them with additional notes for particular nodes
--->
<!---From mixnode with serinkos edits--->
### Upgrading your mix node
Upgrading your node is a two-step process:
* Updating the binary and `~/.nym/mixnodes/<YOUR_ID>/config.toml` on your VPS
* Updating the node information in the [mixnet smart contract](../nyx/mixnet-contract.md). **This is the information that is present on the [mixnet explorer](https://explorer.nymtech.net)**.
#### Step 1: Upgrading your binary
Follow these steps to upgrade your mix node binary and update its config file:
* pause your mix node process.
* replace the existing binary with the newest binary (which you can either [compile yourself](https://nymtech.net/docs/binaries/building-nym.html) or grab from our [releases page](https://github.com/nymtech/nym/releases)).
* re-run `init` with the same values as you used initially. **This will just update the config file, it will not overwrite existing keys**.
* restart your mix node process with the new binary.
#### Step 2: Updating your node information in the smart contract
Follow these steps to update the information about your mix node which is publically avaliable from the [Nym API](https://validator.nymtech.net/api/swagger/index.html) and information displayed on the [mixnet explorer](https://explorer.nymtech.net).
You can either do this graphically via the Desktop Wallet, or the CLI.
#### Updating node information via the Desktop Wallet
* Navigate to the `Bonding` page and click the `Node Settings` link in the top right corner:
\
![Bonding page](../images/wallet-screenshots/bonding.png)
* Update the fields in the `Node Settings` page and click `Submit changes to the blockchain`.
\
![Node Settings Page](../images/wallet-screenshots/node_settings.png)
#### Updating node information via the CLI
If you want to bond your mix node via the CLI, then check out the [relevant section in the Nym CLI](../../documentation/docs/src/tools/nym-cli.md#upgrade-a-mix-node) docs.
---
## VPS Setup and Automation
### Configure your firewall
The following commands will allow you to set up a firewall using `ufw`.
```
# check if you have ufw installed
ufw version
# if it is not installed, install with
sudo apt install ufw -y
# enable ufw
sudo ufw enable
# check the status of the firewall
sudo ufw status
```
Finally open your mix node's p2p port, as well as ports for ssh and ports `8000` and `1790` for verloc and measurement pings:
```
sudo ufw allow 1789,1790,8000,22/tcp
# check the status of the firewall
sudo ufw status
```
For more information about your mix node's port configuration, check the [mix node port reference table](./mix-node-setup.md#mixnode-port-reference) below.
### Automating your mix node with tmux and systemd
It's useful to have the mix node automatically start at system boot time.
#### tmux
One way is to use `tmux` shell on top of your current VPS terminal. Tmux is a terminal multiplexer, it allows you to create several terminal windows and panes from a single terminal. Processes started in `tmux` keep running after closing the terminal as long as the given `tmux` window was not terminated.
Use the following command to get `tmux`.
Platform|Install Command
---|---
Arch Linux|`pacman -S tmux`
Debian or Ubuntu|`apt install tmux`
Fedora|`dnf install tmux`
RHEL or CentOS|`yum install tmux`
macOS (using Homebrew|`brew install tmux`
macOS (using MacPorts)|`port install tmux`
openSUSE|`zypper install tmux`
In case it didn't work for your distribution, see how to build `tmux` from [version control](https://github.com/tmux/tmux#from-version-control).
**Running tmux**
No when you installed tmux on your VPS, let's run a mixnode on tmux, which allows you to detach your terminal and let the mixnode run on its own on the VPS.
* Pause your mixnode
* Start tmux with the command
```
tmux
```
* The terminal should stay in the same directory, just the layout changed into tmux default layout.
* Start the mixnode again with a command:
```
./nym-mixnode run --id <YOUR_ID>
```
* Now, without closing the tmux window, you can close the whole terminal and the mixnode (and any other process running in tmux) will stay active.
* Next time just start your teminal, ssh into the VPS and run the following command to attach back to your previous session:
```
tmux attach session
```
* To see keybinding options of tmux press `ctrl`+`b` and after 1 second `?`
#### systemd
Here's a systemd service file to do that:
```ini
[Unit]
Description=Nym Mixnode ({{mix_node_release_version}})
StartLimitInterval=350
StartLimitBurst=10
[Service]
User=<USER>
LimitNOFILE=65536
ExecStart=/home/<USER>/<PATH>/nym-mixnode run --id <YOUR_ID>
KillSignal=SIGINT
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
```
Put the above file onto your system at `/etc/systemd/system/nym-mixnode.service`.
Change the `<PATH>` in `ExecStart` to point at your mix node binary (`nym-mixnode`), and the `<USER>` so it is the user you are running as.
If you have built nym in the `$HOME` directory on your server, and your username is `jetpanther`, then the start command might look like this:
`ExecStart=/home/jetpanther/nym/target/release/nym-mixnode run --id your-id`. Basically, you want the full `/path/to/nym-mixnode run --id whatever-your-node-id-is`
Then run:
```
systemctl enable nym-mixnode.service
```
Start your node:
```
service nym-mixnode start
```
This will cause your node to start at system boot time. If you restart your machine, the node will come back up automatically.
You can also do `service nym-mixnode stop` or `service nym-mixnode restart`.
Note: if you make any changes to your systemd script after you've enabled it, you will need to run:
```
systemctl daemon-reload
```
This lets your operating system know it's ok to reload the service configuration.
#### Setting the ulimit
Linux machines limit how many open files a user is allowed to have. This is called a `ulimit`.
`ulimit` is 1024 by default on most systems. It needs to be set higher, because mix nodes make and receive a lot of connections to other nodes.
If you see errors such as:
```
Failed to accept incoming connection - Os { code: 24, kind: Other, message: "Too many open files" }
```
This means that the operating system is preventing network connections from being made.
##### Set the ulimit via `systemd` service file
Query the `ulimit` of your mix node with:
```
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep nym-mixnode | grep -v grep |head -n 1 | awk '{print $1}')/limits
```
You'll get back the hard and soft limits, which looks something like this:
```
Max open files 65536 65536 files
```
If your output is **the same as above**, your node will not encounter any `ulimit` related issues.
However if either value is `1024`, you must raise the limit via the systemd service file. Add the line:
```
LimitNOFILE=65536
```
Reload the daemon:
```
systemctl daemon-reload
```
or execute this as root for system-wide setting of `ulimit`:
```
echo "DefaultLimitNOFILE=65535" >> /etc/systemd/system.conf
```
Reboot your machine and restart your node. When it comes back, use `cat /proc/$(pidof nym-mixnode)/limits | grep "Max open files"` to make sure the limit has changed to 65535.
##### Set the ulimit on `non-systemd` based distributions
In case you chose tmux option for mixnode automatization, see your `ulimit` list by running:
```
ulimit -a
# watch for the output line -n
-n: file descriptors 1024
```
You can change it either by running a command:
```
ulimit -u -n 4096
```
or editing `etc/security/conf` and add the following lines:
```
# Example hard limit for max opened files
username hard nofile 4096
# Example soft limit for max opened files
username soft nofile 4096
```
Then reboot your server and restart your mixnode.
<!---FROM GATEWAY GUIDE - NO EDITS SO FAR--->
#### Step 1: Upgrading your binary
Follow these steps to upgrade your binary and update its config file:
* pause your gateway process.
* replace the existing binary with the newest binary (which you can either compile yourself or grab from our [releases page](https://github.com/nymtech/nym/releases)).
* re-run `init` with the same values as you used initially. **This will just update the config file, it will not overwrite existing keys**.
* restart your gateway process with the new binary.
> Do **not** use the `upgrade` command: there is a known error with the command that will be fixed in a subsequent release.
#### Step 2: Updating your node information in the smart contract
Follow these steps to update the information about your node which is publically avaliable from the [Nym API](https://validator.nymtech.net/api/swagger/index.html) and information displayed on the [mixnet explorer](https://explorer.nymtech.net).
You can either do this graphically via the Desktop Wallet, or the CLI.
#### Updating node information via the Desktop Wallet
* Navigate to the `Bonding` page and click the `Node Settings` link in the top right corner:
![Bonding page](../images/wallet-screenshots/bonding.png)
* Update the fields in the `Node Settings` page and click `Submit changes to the blockchain`.
![Node Settings Page](../images/wallet-screenshots/node_settings.png)
#### Updating node information via the CLI
If you want to bond your mix node via the CLI, then check out the [relevant section in the Nym CLI](../tools/nym-cli.md#upgrade-a-mix-node) docs.
---
## VPS Setup and Automation
### Configure your firewall
Although your gateway is now ready to receive traffic, your server may not be - the following commands will allow you to set up a properly configured firewall using `ufw`:
```
# check if you have ufw installed
ufw version
# if it is not installed, install with
sudo apt install ufw -y
# enable ufw
sudo ufw enable
# check the status of the firewall
sudo ufw status
```
Finally open your gateway's p2p port, as well as ports for ssh and incoming traffic connections:
```
sudo ufw allow 1789,22,9000/tcp
# check the status of the firewall
sudo ufw status
```
For more information about your gateway's port configuration, check the [gateway port reference table](#gateway-port-reference) below.
### Automating your gateway with systemd
Although it's not totally necessary, it's useful to have the gateway automatically start at system boot time. Here's a systemd service file to do that:
```ini
[Unit]
Description=Nym Gateway ({{platform_release_version}})
StartLimitInterval=350
StartLimitBurst=10
[Service]
User=nym
LimitNOFILE=65536
ExecStart=/home/nym/nym-gateway run --id supergateway
KillSignal=SIGINT
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
```
Put the above file onto your system at `/etc/systemd/system/nym-gateway.service`.
Change the path in `ExecStart` to point at your gateway binary (`nym-gateway`), and the `User` so it is the user you are running as.
If you have built nym on your server, and your username is `jetpanther`, then the start command might look like this:
`ExecStart=/home/jetpanther/nym/target/release/nym-gateway run --id your-id`. Basically, you want the full `/path/to/nym-gateway run --id whatever-your-node-id-is`
Then run:
```
systemctl enable nym-gateway.service
```
Start your node:
```
service nym-gateway start
```
This will cause your node to start at system boot time. If you restart your machine, the node will come back up automatically.
You can also do `service nym-gateway stop` or `service nym-gateway restart`.
Note: if you make any changes to your systemd script after you've enabled it, you will need to run:
```
systemctl daemon-reload
```
This lets your operating system know it's ok to reload the service configuration.
## Gateway related Validator API endpoints
Numerous gateway related API endpoints are documented on the Validator API's [Swagger Documentation](https://validator.nymtech.net/api/swagger/index.html). There you can also try out various requests from your broswer, and download the response from the API. Swagger will also show you what commands it is running, so that you can run these from an app or from your CLI if you prefer.
@@ -28,42 +28,11 @@ The `nym-mixnode` binary is currently one point version ahead of the rest of the
## Preliminary steps
There are a couple of steps that need completing before starting to set up your mix node:
- preparing your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html)
- requisitioning a VPS (Virtual Private Server)
### Wallet preparation
#### Mainnet
Before you initialise and run your mixnode, head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html).
If you don't already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mixnode is 100 `NYM`, but make sure you have a bit more to account for gas costs.
`NYM` can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several [exchanges](https://www.coingecko.com/en/coins/nym#markets).
> Remember that you can **only** use Cosmos `NYM` tokens to bond your mixnode. You **cannot** use ERC20 representations of `NYM` to run a node.
#### Sandbox testnet
Make sure to download a wallet and create an account as outlined above. Then head to our [token faucet](https://faucet.nymtech.net/) and get some tokens to use to bond it.
### VPS Hardware Specs
You will need to rent a VPS to run your mix node on. One key reason for this is that your node **must be able to send TCP data using both IPv4 and IPv6** (as other nodes you talk to may use either protocol).
For the moment, we haven't put a great amount of effort into optimizing concurrency to increase throughput, so don't bother provisioning a beastly server with multiple cores. This will change when we get a chance to start doing performance optimizations in a more serious way. Sphinx packet decryption is CPU-bound, so once we optimize, more fast cores will be better.
For now, see the below rough specs:
- Processors: 2 cores are fine. Get the fastest CPUs you can afford.
- RAM: Memory requirements are very low - typically a mix node may use only a few hundred MB of RAM.
- Disks: The mixnodes require no disk space beyond a few bytes for the configuration files.
Make sure you do the preparation listed in the [preliminary steps page](../preliminary-steps.md) before setting up your mixnode.
## Mix node setup
Now that you have built the [codebase](https://nymtech.net/docs/binaries/building-nym.html), set up your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html), and have a VPS with the `nym-mixnode` binary, you can set up your mix node with the instructions below.
Now that you have built the [codebase](https://nymtech.net/docs/binaries/building-nym.html), set up your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html), and have a VPS with the `nym-mixnode` binary, you can set up your mix node with the instructions below.
To begin, move to `/taget/release` directory from which you run the node commands:
@@ -0,0 +1,43 @@
# Preliminary Steps
> The Nym mixnode, gateway and network requester binaries were built in the [building nym](https://nymtech.net/docs/binaries/building-nym.html) section. If you haven't yet built Nym and want to run the code, go there first.
## Preliminary steps
There are a couple of steps that need completing before starting to set up your mixnode, gateway or a network requester:
- preparing your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html)
- requisitioning a VPS (Virtual Private Server)
### Wallet preparation
#### Mainnet
Before you initialise and run your mixnode, head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html).
If you don't already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mixnode is 100 `NYM`, but make sure you have a bit more to account for gas costs.
`NYM` can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several [exchanges](https://www.coingecko.com/en/coins/nym#markets).
> Remember that you can **only** use Cosmos `NYM` tokens to bond your mixnode. You **cannot** use ERC20 representations of `NYM` to run a node.
#### Sandbox testnet
Make sure to download a wallet and create an account as outlined above. Then head to our [token faucet](https://faucet.nymtech.net/) and get some tokens to use to bond it.
### VPS Hardware Specs
You will need to rent a VPS to run your node on. One key reason for this is that your node **must be able to send TCP data using both IPv4 and IPv6** (as other nodes you talk to may use either protocol).
For the moment, we haven't put a great amount of effort into optimizing concurrency to increase throughput, so don't bother provisioning a beastly server with multiple cores. This will change when we get a chance to start doing performance optimizations in a more serious way. Sphinx packet decryption is CPU-bound, so once we optimize, more fast cores will be better.
For now, see the below rough specs:
- Processors: 2 cores are fine. Get the fastest CPUs you can afford.
#### For Nym Mixnode
- RAM: Memory requirements are very low - typically a mix node may use only a few hundred MB of RAM.
- Disks: The mixnodes require no disk space beyond a few bytes for the configuration files.
#### For Nym Gateway
- RAM: Memory requirements depend on the amount of users your Gateway will be serving at any one time. If you're just going to be using it yourself, then minimal RAM is fine. **If you're running your Gateway as part of a Service Grant, get something with at least 4GB RAM.**
- Disks: much like the amount of RAM your Gateway could use, the amount of disk space required will vary with the amount of users your Gateway is serving. **If you're running your Gateway as part of a Service Grant, get something with at least 40GB storage.**