Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 mfahampshire
|
b89c3f4281 | ||
|
mfahampshire
|
5f97baa936 |
@@ -1,20 +0,0 @@
|
||||
import {Accordion, AccordionItem} from "@nextui-org/react";
|
||||
|
||||
export const App = () => {
|
||||
const defaultContent =
|
||||
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.";
|
||||
|
||||
return (
|
||||
<Accordion variant="shadow">
|
||||
<AccordionItem key="1" aria-label="Accordion 1" title="Accordion 1">
|
||||
{defaultContent}
|
||||
</AccordionItem>
|
||||
<AccordionItem key="2" aria-label="Accordion 2" title="Accordion 2">
|
||||
{defaultContent}
|
||||
</AccordionItem>
|
||||
<AccordionItem key="3" aria-label="Accordion 3" title="Accordion 3">
|
||||
{defaultContent}
|
||||
</AccordionItem>
|
||||
</Accordion>
|
||||
);
|
||||
}
|
||||
@@ -1,22 +0,0 @@
|
||||
import { Tabs } from "nextra/components";
|
||||
import Mixnodes from "components/operators/snippets/mixnode-migrate-tab-snippet.mdx";
|
||||
import Gateways from "components/operators/snippets/gateway-migrate-tab-snippet.mdx";
|
||||
|
||||
export const MigrateTabs = () => {
|
||||
return (
|
||||
<div>
|
||||
<Tabs
|
||||
items={[<code>nym-mixnode</code>, <code>nym-gateway</code>]}
|
||||
//defaultIndex="1"
|
||||
defaultIndex={1}
|
||||
>
|
||||
<Tabs.Tab>
|
||||
<Mixnodes />
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
<Gateways />
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
@@ -1,21 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import Mixnodes from 'components/operators/snippets/mixnode-run-tab-snippet.mdx';
|
||||
import EntryGateway from 'components/operators/snippets/entry-gateway-run-tab-snippet.mdx';
|
||||
import ExitGateway from 'components/operators/snippets/exit-gateway-run-tab-snippet.mdx';
|
||||
|
||||
export const RunTabs = () => {
|
||||
|
||||
return (
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<code>mixnode</code>,
|
||||
<code>exit-gateway</code>,
|
||||
<code>entry-gateway</code>
|
||||
]} defaultIndex={1}>
|
||||
<Tabs.Tab><Mixnodes /></Tabs.Tab>
|
||||
<Tabs.Tab><ExitGateway /></Tabs.Tab>
|
||||
<Tabs.Tab><EntryGateway /></Tabs.Tab>
|
||||
</Tabs>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
@@ -1,34 +0,0 @@
|
||||
<>
|
||||
If you run a `nym-node` for the first time, you will need to specify a few parameters, please read the section [Essential Parameters & Variables](#essential-paramteters--varibles) before you start and make sure that your `nym-node` is up to date with the [latest version](https://github.com/nymtech/nym/releases/).
|
||||
|
||||
**Initialise and run:**
|
||||
|
||||
To initialise and test run with yur node with all needed options, use this command:
|
||||
```sh
|
||||
./nym-node run --id <ID> --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "<HOSTNAME>" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --accept-operator-terms-and-conditions --wireguard-enabled true
|
||||
```
|
||||
If you prefer to have a generic local identifier set to `default-nym-node`, skip `--id` option.
|
||||
|
||||
We highly recommend to setup [reverse proxy and WSS](proxy-configuration.md) for `nym-node`. If you haven't configured any of that, skip `--hostname` flag.
|
||||
|
||||
In any case `--public-ips` is a necessity for your node to bond to API and communicate with the internet.
|
||||
|
||||
**Initialise only** without running the node with `--init-only` command :
|
||||
|
||||
Adding `--init-only` option results in `nym-node` initialising a configuration file `config.toml` without running - a good option for an initial node setup. Remember that if you using this flag on a node which already has a config file, this will not over-write the values, unless used with a specified flag `--write-changes` (`-w`) - a good option for introducing changes to your `config.toml` file.
|
||||
|
||||
```sh
|
||||
./nym-node run --id <ID> --init-only --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "<HOSTNAME>" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --wireguard-enabled true
|
||||
```
|
||||
|
||||
In the example above we dropped `--accept-operator-terms-and-conditions` as the flag must be added to a running command explicitly and it is not stored in the config, `--init-only` will not run the node.
|
||||
|
||||
**Deny init**
|
||||
|
||||
`--deny-init` was introduced as an additional safety for migration from legacy binaries to `nym-node` to prevent operators initialise over existing nodes. For most of the operators, this flag is not needed.
|
||||
|
||||
In this example we run the node with custom `--id` without initialising, using `--deny-init` command:
|
||||
```sh
|
||||
./nym-node run --id <ID> --deny-init --mode entry-gateway --accept-operator-terms-and-conditions
|
||||
```
|
||||
</>
|
||||
@@ -1,35 +0,0 @@
|
||||
<>
|
||||
If you run a `nym-node` for the first time, you will need to specify a few parameters, please read the section [Essential Parameters & Variables](#essential-paramteters--varibles) before you start and make sure that your `nym-node` is up to date with the [latest version](https://github.com/nymtech/nym/releases/).
|
||||
|
||||
**Initialise and Run**
|
||||
|
||||
To initialise and test run your node, use this command:
|
||||
```sh
|
||||
./nym-node run --id <ID> --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "<HOSTNAME>" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --accept-operator-terms-and-conditions --wireguard-enabled true
|
||||
```
|
||||
If you prefer to have a generic local identifier set to `default-nym-node`, skip `--id` option.
|
||||
|
||||
We highly recommend to setup [reverse proxy and WSS](proxy-configuration.md) for `nym-node`. If you haven't configured any of that, skip `--hostname` flag.
|
||||
|
||||
In any case `--public-ips` is a necessity for your node to bond to API and communicate with the internet.
|
||||
|
||||
|
||||
**Initialise only** without running the node with `--init-only` command:
|
||||
|
||||
Adding `--init-only` option results in `nym-node` initialising a configuration file `config.toml` without running - a good option for an initial node setup. Remember that if you using this flag on a node which already has a config file, this will not over-write the values, unless used with a specified flag `--write-changes` (`-w`) - a good option for introducing changes to your `config.toml` file.
|
||||
|
||||
```sh
|
||||
./nym-node run --id <ID> --init-only --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname "<HOSTNAME>" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --wireguard-enabled true
|
||||
```
|
||||
|
||||
In the example above we dropped `--accept-operator-terms-and-conditions` as the flag must be added to a running command explicitly and it is not stored in the config, `--init-only` will not run the node.
|
||||
|
||||
**Deny init**
|
||||
|
||||
`--deny-init` was introduced as an additional safety for migration from legacy binaries to `nym-node` to prevent operators initialise over existing nodes. For most of the operators, this flag is not needed.
|
||||
|
||||
In this example we run the node with custom `--id` without initialising, using `--deny-init` command:
|
||||
```sh
|
||||
./nym-node run --id <ID> --deny-init --mode exit-gateway --accept-operator-terms-and-conditions
|
||||
```
|
||||
</>
|
||||
@@ -1,23 +0,0 @@
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
<>
|
||||
Migrate your `nym-gateway` to `nym-node --mode entry-gateway` or `--mode exit-gateway` using these commands:
|
||||
<Steps>
|
||||
###### 1. Move relevant info from `config.toml`
|
||||
```sh
|
||||
./nym-node migrate --config-file ~/.nym/gateways/<GATEWAY_ID>/config/config.toml gateway
|
||||
```
|
||||
|
||||
###### 2. Initialise with new `nym-node` config chosing one of the options below:
|
||||
|
||||
- as `entry-gateway`:
|
||||
```sh
|
||||
./nym-node run --id <ID> --mode entry-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname <HOSTNAME> --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --accept-operator-terms-and-conditions --wireguard-enabled true
|
||||
```
|
||||
|
||||
- or as `exit-gateway`:
|
||||
```sh
|
||||
./nym-node run --id <ID> --mode exit-gateway --public-ips "$(curl -4 https://ifconfig.me)" --hostname <HOSTNAME> --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 --location <LOCATION> --accept-operator-terms-and-conditions --wireguard-enabled true
|
||||
```
|
||||
</Steps>
|
||||
</>
|
||||
@@ -1,16 +0,0 @@
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
<>
|
||||
Migrate your `nym-mixnode` to `nym-node --mode mixnode` using these commands:
|
||||
<Steps>
|
||||
###### 1. Move relevant info from `config.toml`
|
||||
```sh
|
||||
./nym-node migrate --config-file ~/.nym/mixnodes/<ID>/config/config.toml mixnode
|
||||
```
|
||||
|
||||
###### 2. Initialise with new `nym-node` config
|
||||
```sh
|
||||
./nym-node run --mode mixnode --id <ID> --location <LOCATION> --mixnet-bind-address 0.0.0.0:1789 --http-bind-address 0.0.0.0:8080 --accept-operator-terms-and-conditions
|
||||
```
|
||||
</Steps>
|
||||
</>
|
||||
@@ -1,31 +0,0 @@
|
||||
<>
|
||||
If you run a `nym-node` for the first time, you will need to specify a few parameters, please read the section [Essential Parameters & Variables](#essential-paramteters--varibles) before you start and make sure that your `nym-node` is up to date with the [latest version](https://github.com/nymtech/nym/releases/).
|
||||
|
||||
**Initialise and Run:**
|
||||
|
||||
To initialise and run your node, use this command:
|
||||
|
||||
```sh
|
||||
./nym-node run --mode mixnode --mixnet-bind-address 0.0.0.0:1789 --verloc-bind-address 0.0.0.0:1790 --http-bind-address 0.0.0.0:8080 --public-ips "$(curl -4 https://ifconfig.me)" --accept-operator-terms-and-conditions
|
||||
```
|
||||
|
||||
**Init only**
|
||||
|
||||
Adding `--init-only` option results in `nym-node` initialising a configuration file `config.toml` without running - a good option for an initial node setup. Remember that if you using this flag on a node which already has a config file, this will not over-write the values, unless used with a specified flag `--write-changes` (`-w`) - a good option for introducing changes to your `config.toml` file.
|
||||
|
||||
Initialise only with a custom `--id` and `--init-only` command:
|
||||
```sh
|
||||
./nym-node run --mode mixnode --id <ID> --init-only --mixnet-bind-address 0.0.0.0:1789 --verloc-bind-address 0.0.0.0:1790 --http-bind-address 0.0.0.0:8080 --public-ips "$(curl -4 https://ifconfig.me)" --accept-operator-terms-and-conditions
|
||||
```
|
||||
|
||||
If you prefer to have a generic local identifier set to `default-nym-node`, skip `--id` option.
|
||||
|
||||
**Deny init**
|
||||
|
||||
`--deny-init` was introduced as an additional safety for migration from legacy binaries to `nym-node` to prevent operators initialise over existing nodes. For most of the operators, this flag is not needed.
|
||||
|
||||
In this example we run the node with custom `--id` without initialising, using `--deny-init` command:
|
||||
```sh
|
||||
./nym-node run --mode mixnode --id <ID> --deny-init --accept-operator-terms-and-conditions
|
||||
```
|
||||
</>
|
||||
@@ -1,13 +0,0 @@
|
||||
Open the needed ports for `nym-node` by running these commands:
|
||||
|
||||
```sh
|
||||
ufw allow 22/tcp # SSH - you're in control of these ports
|
||||
ufw allow 80/tcp # HTTP
|
||||
ufw allow 443/tcp # HTTPS
|
||||
ufw allow 1789/tcp # Nym specific
|
||||
ufw allow 1790/tcp # Nym specific
|
||||
ufw allow 8080/tcp # Nym specific - nym-node-api
|
||||
ufw allow 9000/tcp # Nym Specific - clients port
|
||||
ufw allow 9001/tcp # Nym specific - wss port
|
||||
ufw allow 51822/udp # WireGuard
|
||||
```
|
||||
@@ -1,10 +0,0 @@
|
||||
Open the needed ports for `validator` by running these commands:
|
||||
|
||||
```sh
|
||||
ufw allow 1317 # REST API server endpoint
|
||||
ufw allow 26656 # Listen for incoming peer connections
|
||||
ufw allow 26660 # Listen for Prometheus connections
|
||||
ufw allow 22 # SSH port
|
||||
ufw allow 80 # http port
|
||||
ufw allow 443/tcp # https port
|
||||
```
|
||||
@@ -1,7 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
If you want to bond or upgrade your `nym-node` via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#upgrade-a-mix-node) docs.
|
||||
|
||||
<Callout>
|
||||
If you run in mode `--entry-gateway` or `--exit-gateway`, visit [Nym Harbour Master](https://harbourmaster.nymtech.net/) to get all the probe info about your node directly from API.
|
||||
</Callout>
|
||||
@@ -1,9 +0,0 @@
|
||||
- Open your Desktop wallet
|
||||
|
||||
- Navigate to the `Bonding` page and click the `Node Settings` link in the top right corner
|
||||
|
||||
|
||||
|
||||
- Update the fields in the `Node Settings` page (usually the field `Version` is the only one to change) and click `Submit changes to the blockchain`.
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
Thursday, October 24th 2024, 15:17:10 UTC
|
||||
Monday, October 28th 2024, 13:47:55 UTC
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
```sh
|
||||
[2m2024-10-28T13:47:56.315512Z[0m [32m INFO[0m [2mnym-api/src/main.rs[0m[2m:[0m[2m41[0m[2m:[0m Starting nym api...
|
||||
Usage: nym-api [OPTIONS] <COMMAND>
|
||||
|
||||
Commands:
|
||||
@@ -9,9 +10,9 @@ Commands:
|
||||
|
||||
Options:
|
||||
-c, --config-env-file <CONFIG_ENV_FILE>
|
||||
Path pointing to an env file that configures the Nym API
|
||||
Path pointing to an env file that configures the Nym API [env: NYMAPI_CONFIG_ENV_FILE_ARG=]
|
||||
--no-banner
|
||||
A no-op flag included for consistency with other binaries (and compatibility with nymvisor, oops)
|
||||
A no-op flag included for consistency with other binaries (and compatibility with nymvisor, oops) [env: NYMAPI_NO_BANNER_ARG=]
|
||||
-h, --help
|
||||
Print help
|
||||
-V, --version
|
||||
|
||||
@@ -44,6 +44,8 @@ Options:
|
||||
Specify whether detailed system crypto hardware information should be exposed. default: true [env: NYMNODE_HTTP_EXPOSE_CRYPTO_HARDWARE=] [possible values: true, false]
|
||||
--mixnet-bind-address <MIXNET_BIND_ADDRESS>
|
||||
Address this node will bind to for listening for mixnet packets default: `0.0.0.0:1789` [env: NYMNODE_MIXNET_BIND_ADDRESS=]
|
||||
--mixnet-announce-port <MIXNET_ANNOUNCE_PORT>
|
||||
If applicable, custom port announced in the self-described API that other clients and nodes will use. Useful when the node is behind a proxy [env: NYMNODE_MIXNET_ANNOUNCE_PORT=]
|
||||
--nym-api-urls <NYM_API_URLS>
|
||||
Addresses to nym APIs from which the node gets the view of the network [env: NYMNODE_NYM_APIS=]
|
||||
--nyxd-urls <NYXD_URLS>
|
||||
@@ -60,6 +62,8 @@ Options:
|
||||
The prefix denoting the maximum number of the clients that can be connected via Wireguard. The maximum value for IPv4 is 32 and for IPv6 is 128 [env: NYMNODE_WG_PRIVATE_NETWORK_PREFIX=]
|
||||
--verloc-bind-address <VERLOC_BIND_ADDRESS>
|
||||
Socket address this node will use for binding its verloc API. default: `0.0.0.0:1790` [env: NYMNODE_VERLOC_BIND_ADDRESS=]
|
||||
--verloc-announce-port <VERLOC_ANNOUNCE_PORT>
|
||||
If applicable, custom port announced in the self-described API that other clients and nodes will use. Useful when the node is behind a proxy [env: NYMNODE_VERLOC_ANNOUNCE_PORT=]
|
||||
--entry-bind-address <ENTRY_BIND_ADDRESS>
|
||||
Socket address this node will use for binding its client websocket API. default: `0.0.0.0:9000` [env: NYMNODE_ENTRY_BIND_ADDRESS=]
|
||||
--announce-ws-port <ANNOUNCE_WS_PORT>
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
|
||||
import TimeNow from 'components/outputs/api-scraping-outputs/time-now.md';
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
<strong>
|
||||
The data on this page were last time updated on <span style={{display: 'inline-block'}}><TimeNow /></span>.
|
||||
</strong>
|
||||
</Callout>
|
||||
@@ -1,6 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Our documentation often refer to syntax annotated in `<>` brackets. We use this expression for variables that are unique to each user (like path, local moniker, versions etcetra).
|
||||
Any syntax in `<>` brackets needs to be substituted with your correct name or version, without the `<>` brackets. If you are unsure, please check our table of essential [parameters and variables](https://nymtech.net/docs/operators/variables.html).
|
||||
</Callout>
|
||||
@@ -1,12 +0,0 @@
|
||||
|
||||
import { Callout } from 'nextra/components';
|
||||
import TimeOutput from 'components/snippets-general/time-now.mdx';
|
||||
|
||||
export const TimeNow = () => {
|
||||
|
||||
return (
|
||||
<div>
|
||||
<TimeOutput />
|
||||
</div>
|
||||
)
|
||||
}
|
||||
@@ -1,10 +0,0 @@
|
||||
import VariableInfo from './snippets-general/varible-info-snippet.mdx';
|
||||
|
||||
export const VarInfo = () => {
|
||||
|
||||
return (
|
||||
<div>
|
||||
<VariableInfo/ >
|
||||
</div>
|
||||
)
|
||||
}
|
||||
Vendored
+1
-1
@@ -2,4 +2,4 @@
|
||||
/// <reference types="next/image-types/global" />
|
||||
|
||||
// NOTE: This file should not be edited
|
||||
// see https://nextjs.org/docs/pages/building-your-application/configuring/typescript for more information.
|
||||
// see https://nextjs.org/docs/basic-features/typescript for more information.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
"author": "Nym Technologies SA",
|
||||
"scripts": {
|
||||
"generate:commands": "../scripts/next-scripts/autodoc.sh",
|
||||
"prebuild": "../scripts/prebuild.sh",
|
||||
"generate:tables": "../scripts/next-scripts/python-prebuild.sh",
|
||||
"predev": "../scripts/prebuild.sh",
|
||||
"build": "next build",
|
||||
"dev": " next dev",
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
{
|
||||
"introduction": "Introduction",
|
||||
"changelog": "Changelog",
|
||||
"release-cycle": "Release Cycle",
|
||||
"variables": "Variables & Parameters",
|
||||
"sandbox": "Sandbox Testnet",
|
||||
"binaries": "Binaries",
|
||||
"nodes": "Operator Guides",
|
||||
"troubleshooting": "Troubleshooting",
|
||||
"tokenomics": "Tokenomics",
|
||||
"faq": "FAQ",
|
||||
"community-counsel": "Community Counsel",
|
||||
"---": {
|
||||
"type": "separator"
|
||||
},
|
||||
"archive": "Archive",
|
||||
"misc": "Misc."
|
||||
}
|
||||
@@ -1,7 +0,0 @@
|
||||
# Archived Pages
|
||||
|
||||
This section contains old but still relevant pages/guides, archived for backwards compatibility. The content of the pages is not updated. See the top of every page informing you about the last time of update.
|
||||
|
||||
Pages listed in archive section will eventually be terminated as they will become completely irrelevant with time.
|
||||
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
{
|
||||
"faq": "FAQ"
|
||||
}
|
||||
@@ -1,109 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Project Smoosh - FAQ
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
**This is an archived page for backwards compatibility. We have switched to [`nym-node` binary](../../nodes/nym-node.mdx), please [migrate](../../nodes/nym-node/setup.mdx#migrate) your nodes. The content of this page is not updated since April 26th 2024. Eventually this page will be terminated!**
|
||||
</Callout>
|
||||
|
||||
> We aim on purpose to make minimal changes to reward scheme and software. We're just 'smooshing' together stuff we already debugged and know works.
|
||||
> -- Harry Halpin, Nym CEO
|
||||
|
||||
|
||||
This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the [Mix Nodes FAQ page](mixnodes-faq.md) holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page.
|
||||
|
||||
If any questions are not answered or it's not clear for you in which stage project Smoosh is right now, please reach out in Node Operators [Matrix room](https://matrix.to/#/#operators:nymtech.chat).
|
||||
|
||||
|
||||
### What are the changes?
|
||||
|
||||
Project Smoosh will have four steps, please follow the table below to track the dynamic progress:
|
||||
|
||||
| **Step** | **Status** |
|
||||
| :--- | :--- |
|
||||
| **1.** Combine the `nym-gateway` and `nym-network-requester` into one binary | ✅ done |
|
||||
| **2.** Create [Exit Gateway](../../legal/exit-gateway.md): Take the `nym-gateway` binary including `nym-network-requester` combined in \#1 and switch from [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a new [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) | ✅ done |
|
||||
| **3.** Combine all the nodes in the Nym Mixnet into one binary, that is `nym-mixnode`, `nym-gateway` (entry and exit) and `nym-network-requester`. | ✅ done |
|
||||
| **4.** Adjust reward scheme to incentivise and reward Exit Gateways as a part of `nym-node` binary, implementing [zkNym credentials](https://youtu.be/nLmdsZ1BsQg?t=1717). | 🛠️ in progress |
|
||||
| **5.** Implement multiple node functionalities into one `nym-node` connected to one Nyx account. | 🛠️ in progress |
|
||||
|
||||
These steps will be staggered over time - period of several months, and will be implemented one by one with enough time to take in feedback and fix bugs in between.
|
||||
Generally, the software will be the same, just instead of multiple binaries, there will be one Nym Node (`nym-node`) binary. Delegations will remain on as they are now, per our token economics (staking, saturation etc)
|
||||
|
||||
### What does it mean for Nym nodes operators?
|
||||
|
||||
We are exploring two potential methods for implementing binary functionality in practice and will provide information in advance. The options are:
|
||||
|
||||
1. Make a selection button (command/argument/flag) for operators to choose whether they want their node to provide all or just some of the functions nodes have in the Nym Mixnet. Nodes functioning as Exit Gateways (in that epoch) will then have bigger rewards due to their larger risk exposure and overhead work with the setup.
|
||||
|
||||
2. All nodes will be required to have the Exit Gateway functionality. All nodes are rewarded the same as now, and the difference is that a node sometimes (some epochs) may be performing as Exit Gateway sometimes as Mix node or Entry Gateway adjusted according the network demand by an algorithm.
|
||||
|
||||
### Where can I read more about the Exit Gateway setup?
|
||||
|
||||
We created an [entire page](../../legal/exit-gateway.md) about the technical and legal questions around Exit Gateway.
|
||||
|
||||
### What is the change from allow list to deny list?
|
||||
|
||||
The operators running Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays. The main change will be to expand the original short [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) to a more permissive setup. An [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will constrain the hosts that the users of the Nym VPN and Mixnet can connect to. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym VPN and Mixnet clients.
|
||||
|
||||
### How will the Exit policy be implemented?
|
||||
|
||||
Follow the dynamic progress of exit policy implementation on Gateways below:
|
||||
|
||||
| **Step** | **Status** |
|
||||
| :--- | :--- |
|
||||
| **1.** By default the [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) filtering is disabled and the [`allowed.list`](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) filtering is going to continue be used. This is to prevent operators getting surprised by upgrading their Gateways (or Network Requesters) and suddenly be widely open to the internet. To enable the new exit policy, operators must use `--with-exit-policy` flag or modify the `config.toml` file. | ✅ done |
|
||||
| **2.** The exit policy is part of the Gateway setup by default. To disable this exit policy, operators must use `--disable-exit-policy` flag. | ✅ done |
|
||||
| **3.** The exit policy is the only option. The `allowed.list` is completely removed. | ✅ done |
|
||||
|
||||
Keep in mind the table above only relates to changes happening on Gateways. For the Project Smoosh progress refer to the [table above](#what-are-the-changes). Whether Exit Gateway functionality will be optional or mandatory part of every active Nym Node depends on the chosen [design](./smoosh-faq.md#what-does-it-mean-for-nym-nodes-operators).
|
||||
|
||||
### Can I run a Mix Node only?
|
||||
|
||||
It depends which [design](#what-does-it-mean-for-nym-nodes-operators) will ultimately be used. In case of the first - yes. In case of the second option, all the nodes will be setup with Exit Gateway functionality turned on.
|
||||
|
||||
## Token Economics & Rewards
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
For any specifics on Nym token economics and Nym Mixnet reward system, please read the [Nym token economics paper](https://nymtech.net/nym-cryptoecon-paper.pdf).
|
||||
</Callout>
|
||||
|
||||
### What are the incentives for the node operator?
|
||||
|
||||
In the original setup there were no incentives to run a `nym-network-requester` binary. After the transition all the users will buy multiple tickets of zkNyms credentials and use those as [anonymous e-cash](https://arxiv.org/abs/2303.08221) to pay for their data traffic ([`Nym API`](https://github.com/nymtech/nym/tree/master/nym-api) will do the do cryptographical checks to prevent double-spending). All collected fees get distributed to all active nodes proportionally to their work by the end of each epoch.
|
||||
|
||||
### How does this change the token economics?
|
||||
|
||||
The token economics will stay the same as they are, same goes for the reward algorithm.
|
||||
|
||||
### How are the rewards distributed?
|
||||
|
||||
This depends on [design](#what-does-it-mean-for-nym-nodes-operators) chosen. In case of \#1, it will look like this:
|
||||
|
||||
As each operator can choose what roles their nodes provide, the nodes which work as open Gateways will have higher rewards because they are the most important to keep up and stable. Besides that the operators of Gateways may be exposed to more complication and possible legal risks.
|
||||
|
||||
The nodes which are initialized to run as Mix Nodes and Gateways will be chosen to be on top of the active set before the ones working only as a Mix Node.
|
||||
|
||||
I case we go with \#2, all nodes active in the epoch will be rewarded proportionally according their work.
|
||||
|
||||
In either way, Nym will share all the specifics beforehand.
|
||||
|
||||
### How will be the staking and inflation after project Smoosh?
|
||||
|
||||
Nym will run tests to count how much payment comes from the users of the Mixnet and if that covers the reward payments. If not, we may need to keep inflation on to secure incentives for high quality Gateways in the early stage of the transition.
|
||||
|
||||
### When project smooth will be launched, it would be the mixmining pool that will pay for the Gateway rewards based on amount of traffic routed ?
|
||||
|
||||
Yes, the same pool. Nym's aim is to do minimal modifications. The only real modification on the smart contract side will be to get into top X of 'active set' operators will need to have open Gateway function enabled.
|
||||
|
||||
### What does this mean for the current delegators?
|
||||
|
||||
From an operator standpoint, it shall just be a standard Nym upgrade, a new option to run the Gateway software on your node. Delegators should not have to re-delegate.
|
||||
|
||||
## Legal Questions
|
||||
|
||||
### Are there any legal concerns for the operators?
|
||||
|
||||
So far the general line is that running a Gateway is not illegal (unless you are in Iran, China, and a few other places) and due to encryption/mixing less risky than running a normal VPN node. For Mix Nodes, it's very safe as they have "no idea" what packets they are mixing.
|
||||
|
||||
There are several legal questions and analysis to be made for different jurisdictions. To be able to share resources and findings between the operators themselves we created a [Community Legal Forum](../../community-counsel/exit-gateway.mdx).
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"pre-built-binaries": "Pre-built Binaries",
|
||||
"building-nym": "Building from Source"
|
||||
}
|
||||
@@ -1,78 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
|
||||
# Building from Source
|
||||
|
||||
> Nym runs on Mac OS X, Linux, and Windows. All nodes **except the Desktop Wallet and NymConnect** on Windows should be considered experimental - it works fine if you're an app developer but isn't recommended for running nodes.
|
||||
|
||||
## Building Nym
|
||||
|
||||
Nym has two main codebases:
|
||||
|
||||
- the [Nym platform](https://github.com/nymtech/nym), written in Rust. This contains all of our code _except_ for the validators.
|
||||
- the [Nym validators](https://github.com/nymtech/nyxd), written in Go.
|
||||
|
||||
> This page details how to build the main Nym platform code. **If you want to build and run a validator, [go here](../nodes/validator-setup.md) instead.**
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Debian/Ubuntu: `pkg-config`, `build-essential`, `libssl-dev`, `curl`, `jq`, `git`
|
||||
|
||||
```sh
|
||||
apt install pkg-config build-essential libssl-dev curl jq git
|
||||
```
|
||||
|
||||
- Arch/Manjaro: `base-devel`
|
||||
|
||||
```sh
|
||||
pacman -S base-devel
|
||||
```
|
||||
|
||||
- Mac OS X: `pkg-config` , `brew`, `openss1`, `protobuf`, `curl`, `git`
|
||||
Running the following the script installs Homebrew and the above dependencies:
|
||||
|
||||
```sh
|
||||
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
||||
```
|
||||
|
||||
- `Rust & cargo >= {{minimum_rust_version}}`
|
||||
|
||||
We recommend using the [Rust shell script installer](https://www.rust-lang.org/tools/install). Installing cargo from your package manager (e.g. `apt`) is not recommended as the packaged versions are usually too old.
|
||||
|
||||
If you really don't want to use the shell script installer, the [Rust installation docs](https://forge.rust-lang.org/infra/other-installation-methods.html) contain instructions for many platforms.
|
||||
|
||||
## Download and Build Nym Binaries
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
You cannot build from GitHub's .zip or .tar.gz archive files on the releases page - the Nym build scripts automatically include the current git commit hash in the built binary during compilation, so the build will fail if you use the archive code (which isn't a Git repository). Check the code out from github using `git clone` instead.
|
||||
</Callout>
|
||||
|
||||
The following commands will compile binaries into the `nym/target/release` directory:
|
||||
|
||||
```sh
|
||||
rustup update
|
||||
git clone https://github.com/nymtech/nym.git
|
||||
cd nym
|
||||
|
||||
git reset --hard # in case you made any changes on your branch
|
||||
git pull # in case you've checked it out before
|
||||
|
||||
git checkout master # master branch has the latest release version: `develop` will most likely be incompatible with deployed public networks
|
||||
|
||||
cargo build --release # build your binaries with **mainnet** configuration
|
||||
```
|
||||
|
||||
Quite a bit of stuff gets built. The key working parts are:
|
||||
|
||||
* [Nym Node](../nodes/nym-node/nym-node.mdx): `nym-node`
|
||||
* [Validator](../nodes/validator-setup.mdx)
|
||||
* [websocket client](https://nymtech.net/developers/clients/websocket-client.html): `nym-client`
|
||||
* [socks5 client](https://nymtech.net/developers/clients/socks5-client.html): `nym-socks5-client`
|
||||
* [webassembly client](https://nymtech.net/developers/clients/webassembly-client.html): `webassembly-client`
|
||||
* [nym-cli tool](https://nymtech.net/docs/tools/nym-cli.html): `nym-cli`
|
||||
* [nym-api](../nodes/validator-setup/nym-api.mdx): `nym-api`
|
||||
* [nymvisor](../nodes/maintenance/nymvisor-upgrade.mdx): `nymvisor`
|
||||
|
||||
The repository also contains Typescript applications which aren't built in this process. These can be built by following the instructions on their respective docs pages.
|
||||
* [Nym Wallet](https://nymtech.net/docs/wallet/desktop-wallet.html)
|
||||
* [Network Explorer UI](https://nymtech.net/docs/explorers/mixnet-explorer.html)
|
||||
@@ -1,46 +0,0 @@
|
||||
import { Steps } from 'nextra/components'
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
|
||||
# Pre-built Binaries
|
||||
|
||||
This page is for operators who prefer to download ready made binaries. The [Github releases page](https://github.com/nymtech/nym/releases) has pre-built binaries which should work on Ubuntu 22.04 and other Debian-based systems, but at this stage cannot be guaranteed to work everywhere.
|
||||
|
||||
If the pre-built binaries don't work or are unavailable for your system, you will need to build the platform yourself.
|
||||
|
||||
## Setup Binaries
|
||||
|
||||
<VarInfo />
|
||||
|
||||
<Steps>
|
||||
|
||||
1. ###### Download binary
|
||||
- Go to [Nym release page](https://github.com/nymtech/nym/releases/), choose binary to download, click with a right button and `Copy Link...`
|
||||
- Download from your terminal using `curl` or `wget` tool:
|
||||
```sh
|
||||
# using curl
|
||||
curl -L <LINK> -o <PATH>/nym-node
|
||||
|
||||
# using wget
|
||||
wget <LINK>
|
||||
```
|
||||
In case you want to download binary to your current working directory, drop `<PATH>` from the command
|
||||
|
||||
In case you want to download binary to your current working directory, drop `<PATH>` from the command
|
||||
|
||||
###### 2. Make the binary executable
|
||||
- Open terminal in the same directory and run:
|
||||
```sh
|
||||
chmod +x <BINARY>
|
||||
# for example: chmod +x nym-mixnode
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
Now you can use your binary. Follow the guide according to the type of your binary.
|
||||
|
||||
* [Nym Nodes](../nodes/nym-node.mdx)
|
||||
* [Validators](../nodes/validator-setup.mdx)
|
||||
|
||||
You can reconfigure your binaries at any time by editing the config file located at `~/.nym/<BINARY_TYPE>/<ID>/config/config.toml` and restarting the binary process.
|
||||
|
||||
`<ID>` represents a local moniker that is **never** transmitted over the network. It's used to select which local config and key files (stored in `./nym`) to use for startup.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,17 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
|
||||
# Community Counsel
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
**The entire content of this section is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/).**
|
||||
</Callout>
|
||||
|
||||
Running an Exit Gateway is a commitment and as such is exposed to various challenges. Besides different legal regulations typical difficulties may be dealing with VPS or ISP providers. Our strength lies in decentralised community of squads and individuals supporting each other. Sharing examples of [landing pages](landing-pages.md), templates for communication and FAQs is a great way to empower other operators sharing the mission of liberating internet. Below is a simple way how to create a pull request directly to Nym Operator Guide docs.
|
||||
|
||||
## How to add content
|
||||
|
||||
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.md).
|
||||
@@ -1,7 +0,0 @@
|
||||
{
|
||||
"exit-gateway": "Exit Gateway",
|
||||
"jurisdictions": "Jurisdictions",
|
||||
"isp-list": "ISP List",
|
||||
"landing-pages": "Landing Pages",
|
||||
"add-content": "How to Add Info"
|
||||
}
|
||||
@@ -1,76 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
# Adding Content to Legal Forum
|
||||
|
||||
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in, to share solutions to the challenges they encountered when running Exit Gateway, and create a pull request (PR).
|
||||
|
||||
First of all, please join our [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) and post any information or questions there.
|
||||
|
||||
To add your information to this book, you can create a PR directly to our [repository](https://github.com/nymtech/nym/tree/develop/documentation/operators/src/legal).
|
||||
|
||||
<VarInfo/>
|
||||
|
||||
## Steps to make a pull request:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Write down your legal findings, suggestions, communication templates, FAQ in a text editor
|
||||
|
||||
###### 2. Clone `nymtech/nym` repository or pull in case you already have it and switch to `develop` branch
|
||||
|
||||
- Clone the repository
|
||||
```sh
|
||||
git clone https://github.com/nymtech/nym.git
|
||||
```
|
||||
|
||||
- Go to the directory nym
|
||||
```sh
|
||||
cd nym
|
||||
```
|
||||
|
||||
- Switch to branch develop and update the branch
|
||||
```sh
|
||||
git checkout develop
|
||||
git pull origin develop
|
||||
```
|
||||
|
||||
|
||||
###### 3. Make your own branch based off `develop` and switch to it
|
||||
|
||||
- Choose a descriptive and consise name without using `<>` brackets
|
||||
|
||||
```sh
|
||||
git checkout -b operators/community-counsel/<NEW_BRANCH_NAME>
|
||||
|
||||
# example: git checkout -b operators/community-counsel/alice-vps-faq-template
|
||||
```
|
||||
|
||||
- Verify that you are on the right branch
|
||||
```sh
|
||||
git branch
|
||||
```
|
||||
|
||||
###### 4. Save your legal findings as `<JURISDICTION_NAME>.md` to `/nym/documentation/docs/pages/operators/community-counsel/jurisdictions` or add info to an existing page
|
||||
|
||||
###### 5. Add to git, commit and push your changes
|
||||
|
||||
```sh
|
||||
cd documentation/docs/pages/operators/community-counsel/jurisdictions
|
||||
git add <FILE_NAME>.md
|
||||
git commit -am "<DESCRIBE YOUR CHANGES>"
|
||||
git push origin operators/community-counsel/<NEW_BRANCH_NAME>
|
||||
```
|
||||
###### 6. Create a pull request
|
||||
|
||||
- Open the git generated link in your browser, fill the description and click on `Create a Pull Request` button
|
||||
```sh
|
||||
# the url will look like this
|
||||
https://github.com/nymtech/nym/pull/new/operators/community-counsel/<NEW_BRANCH_NAME>
|
||||
```
|
||||
###### 7. Notify others in the [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) about the PR.
|
||||
|
||||
- Someone from the team will reach out to you, stay in touch to finalise the PR
|
||||
|
||||
</Steps>
|
||||
@@ -1,137 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
|
||||
# Community Counsel: Running Exit Gateway
|
||||
|
||||
|
||||
This page is a part of Nym Community Counsel (before Legal Forum) and its content is composed by shared advices in [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) as well as though pull requests done by the node operators directly to our [repository](https://github.com/nymtech/nym/tree/develop/documentation/docs/pages/operators), reviewed by Nym DevRels.
|
||||
|
||||
This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a **clear policy**, one which will remain the **same for all operators** running Nym nodes. [**Nym exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) is a combination of safeguards like (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy aims to find a healthy compromise between protecting the operators and NymVPN users against attacks while allowing for as wide experience when accessing the internet through Nym Network.
|
||||
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences.
|
||||
</Callout>
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
* This document outlines a plan to change Nym Gateways from operating with an ‘allow’ to a ‘deny’ list to enable broader uptake and usage of the Nym Mixnet. It provides operators with an overview of the plan, pros and cons, legal as well as technical advice.
|
||||
|
||||
* Nym is committed to ensuring privacy for all users, regardless of their location and for the broadest possible range of online services. In order to achieve this aim, the Nym Mixnet needs to increase its usability across a broad range of apps and services.
|
||||
|
||||
* Currently, Nym Gateway nodes only enable access to apps and services that are on an ‘allow’ list that is maintained by the core team.
|
||||
|
||||
* To decentralise and enable privacy for a broader range of services, this initiative will have to transition from the current ‘allow’ list to a ‘deny’ list - [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). In accordance with the (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464))
|
||||
|
||||
* This will enhance the usage and appeal of Nym products for end users. As a result, increased usage will ultimately lead to higher revenues for Nym operators.
|
||||
|
||||
* Nym core team cannot provide operators with definitive answers regarding the potential risks of operating open Gateways. However, there is online evidence of operating Tor exit relays:
|
||||
* From a technical perspective, Nym node operators may need to implement additional controls, such as dedicated hardware and IP usage, or setting up an HTML exit notice on port 80.
|
||||
* From an operational standpoint, node operators may be expected to actively manage their relationship with their ISP or VPS provider and respond to abuse requests using the proposed templates.
|
||||
* Legally, exit relays are typically considered "telecommunication networks" and are subject to intermediary liability protection. However, there may be exceptions, particularly in cases involving criminal law and copyright claims. Operators could seek advice from local privacy associations and may consider running nodes under an entity rather than as individuals.
|
||||
|
||||
* This document serves as the basis for a consultation with Nym node operators on any concerns or additional support and information you need for this change to be successful and ensure maximum availability, usability and adoption.
|
||||
|
||||
## Goal of the initiative
|
||||
|
||||
**Nym supports privacy for everyone, everywhere.**
|
||||
|
||||
To offer a better and more private everyday experience for its users, Nym would like them to use any online services they please, without limiting its access to a few messaging apps or crypto wallets.
|
||||
|
||||
To achieve this, operators running Exit Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays following this [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt).
|
||||
|
||||
## Pros and cons of the initiative
|
||||
|
||||
Previous setup: Running nodes supporting strict SOCKS5 app-based traffic
|
||||
|
||||
| **Dimension** | **Pros** | **Cons** |
|
||||
| :--- | :--- | :--- |
|
||||
| Aspirational | | - Very limited use cases, not supportive of the “Privacy for everyone everywhere” aspiration - Limited appeal to users, low competitiveness in the market, thus low usage |
|
||||
| Technical | - No changes required in technical setup | |
|
||||
| Operational | - No impact on operators operations (e.g., relationships with VPS providers) - Low overhead - Can be run as an individual | |
|
||||
| Legal | - Limited legal risks for operators | |
|
||||
| Financial | | - Low revenues for operators due to limited product traction |
|
||||
|
||||
|
||||
The new setup: Running nodes supporting traffic of any online service (with safeguards in the form of a denylist)
|
||||
|
||||
| **Dimension** | **Pros** | **Cons** |
|
||||
| :--- | :--- | :--- |
|
||||
| Aspirational | - Higher market appeal of a fully-fledged product able to answer all users’ use cases - Relevance in the market, driving higher usage | |
|
||||
| Technical | - Very limited changes required in the technical setup (changes in the allow -> denylist) | - Increased monitoring required to detect and prevent abuse (e.g. spam) |
|
||||
| Operational | | - Higher operational overhead, such as dealing with DMCA / abuse complaints, managing the VPS provider questions, or helping the community to maintain the denylist - Administrative overhead if running nodes as a company or an entity |
|
||||
| Legal | | - Ideally requires to check legal environment with local privacy association or lawyer | Financial | - Higher revenue potential for operators due to the increase in network usage | - If not running VPS with an unlimited bandwidth plan, higher costs due to higher network usage |
|
||||
|
||||
## Exit Gateways: New setup
|
||||
|
||||
In our previous technical setup, Network Requesters acted as a proxy, and only made requests that match an allow list. That was a default IP based list of allowed domains stored at Nym page in a centralised fashion possibly re-defined by any Network Requester operator.
|
||||
|
||||
This restricts the hosts that the NymConnect app can connect to and has the effect of selectively supporting messaging services (e.g. Telegram, Matrix) or crypto wallets (e.g. Electrum or Monero). Operators of Network Requesters can have confidence that the infrastructure they run only connects to a limited set of public internet hosts.
|
||||
|
||||
The principal change in the new configuration is to make this short allow list more permissive. Nym's [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will restrict the hosts to which Nym Mixnet and Nym VPN users are permitted to connect. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym Mixnet VPN and VPN clients (both wrapped in the same app).
|
||||
|
||||
As of now we the Gateways will be defaulted to a combination of (nowadays deprecated) `Tor Null deny list` (note: Tornull is not affiliated with Tor Project) - reproduction permitted under Creative Commons Attribution 3.0 United States License which is IP-based, e.g., `ExitPolicy reject 5.188.10.0/23:*` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy will remain the same for all the nodes, without any option to modify it by Nym node operators individually, to secure stable and reliable service for the end users.
|
||||
|
||||
For exit relays on ports 80 and 443, the Gateways will exhibit an HTML page resembling the one proposed by [Tor](https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html). By doing so, the operator will be able to disclose details regarding their Gateway, including the currently configured exit policy, all without the need for direct correspondence with regulatory or law enforcement agencies. It also makes the behavior of Exit Gateways transparent and even computable (a possible feature would be to offer a machine readable form of the notice in JSON or YAML).
|
||||
|
||||
We also recommend operators to check the technical advice from [Tor](https://community.torproject.org/relay/setup/exit/).
|
||||
|
||||
## Community Counsel & Legal environment of Nym Exit Gateway
|
||||
|
||||
The Node Operators Community Counsel pages are divided according [jurisdictions](jurisdictions.mdx). Nym Node operators are invited to add their legal findings or helpful suggestions directly through [pull requests](add-content.mdx). This can be done as a new legal information (or entire new country) to the list of [jurisdictions](jurisdictions.mdx) or in a form of an advice to [Community counsel pages](../community-counsel.mdx), like sharing examples of Exit Gateway [landing pages](landing-pages.md), templates etcetra.
|
||||
|
||||
## How to add content
|
||||
|
||||
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.mdx).
|
||||
|
||||
## Tor legal advice
|
||||
|
||||
Giving the legal similarity between Nym Exit Gateways and Tor Exit Relays, it is helpful to have a look in [Tor community Exit Guidelines](https://community.torproject.org/relay/community-resources/tor-exit-guidelines/). This chapter is an exert of tor page.
|
||||
|
||||
Note that Tor states:
|
||||
> This FAQ is for informational purposes only and does not constitute legal advice.
|
||||
|
||||
*Check legal advice prior to running an exit relay*
|
||||
|
||||
* Understand the risks associated with running an exit relay; E.g., know legal paragraphs relevant in the country of operations:
|
||||
- US [DMCA 512](https://www.law.cornell.edu/uscode/text/17/512); see [EFF's Legal FAQ for Tor Operators](https://community.torproject.org/relay/community-resources/eff-tor-legal-faq) (a very good and relevant read for other countries as well)
|
||||
- Germany’s [TeleMedienGesetz 8](https://www.gesetze-im-internet.de/tmg/__8.html) and 15](https://www.gesetze-im-internet.de/tmg/__15.html)
|
||||
- Netherlands: [Artikel 6:196c BW](http://wetten.overheid.nl/BWBR0005289/Boek6/Titel3/Afdeling4A/Artikel196c/)
|
||||
- Austria: [E-Commerce-Gesetz 13](http://www.ris.bka.gv.at/Dokument.wxe?Abfrage=Bundesnormen&Dokumentnummer=NOR40025809)
|
||||
- Sweden: [16-19 2002:562](https://lagen.nu/2002:562#P16S1)
|
||||
* Top 3 advice
|
||||
- Have an abuse response letter
|
||||
- Run relay from a location that is not home
|
||||
- Read through the legal resources that Tor-supportive lawyers put together: [www.eff.org/pages/legal-faq-tor-relay-operators](https://www.eff.org/pages/legal-faq-tor-relay-operators) or [www.noisebridge.net/wiki/Noisebridge_Tor/FBI](https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI)
|
||||
* Consult a lawyer / local digital rights association / the EFF prior to operating an exit relay, especially in a place where exit relay operators have been harassed or not operating before. Note that Tor DOES NOT provide legal advice for specific countries. It only provides general advice (itself or in partnership), eventually skewed towards [US audiences](https://www.eff.org/pages/legal-faq-tor-relay-operators).
|
||||
|
||||
|
||||
*Run an exit relay within an entity*
|
||||
|
||||
As an organisation - it might help from a liability perspective
|
||||
* Within your university
|
||||
* With a node operators’ association (e.g., a Torservers.net partner)
|
||||
* Within a company
|
||||
|
||||
*Be ready to respond to abuse complaints*
|
||||
|
||||
* Make your contact details (email, phone, or even fax) available, instead of those of the ISP
|
||||
* Reply in a timely manner (e.g., 24 hours) using the [provided templates](https://community.torproject.org/relay/community-resources/tor-abuse-templates)
|
||||
* Note that Tor states: *“We are not aware of any case that made it near a court, and we will do everything in our power to support you if it does.”*
|
||||
* Document experience with ISPs at [community.torproject.org/relay/community-resources/good-bad-isps](https://community.torproject.org/relay/community-resources/good-bad-isps/)
|
||||
|
||||
Useful links:
|
||||
|
||||
* Tor abuse templates:
|
||||
- [community.torproject.org/relay/community-resources/tor-abuse-templates/](https://community.torproject.org/relay/community-resources/tor-abuse-templates/)
|
||||
- [gitlab.torproject.org/legacy/trac/-/wikis/doc/TorAbuseTemplates](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorAbuseTemplates) (from 2020)
|
||||
- [github.com/coldhakca/abuse-templates/blob/master/generic.template](https://github.com/coldhakca/abuse-templates/blob/master/generic.template)
|
||||
|
||||
* DMCA response templates:
|
||||
- [community.torproject.org/relay/community-resources/eff-tor-legal-faq/tor-dmca-response/](https://community.torproject.org/relay/community-resources/eff-tor-legal-faq/tor-dmca-response/)
|
||||
- [2019.www.torproject.org/eff/tor-dmca-response.html](https://2019.www.torproject.org/eff/tor-dmca-response.html) (from 2011)
|
||||
- [github.com/coldhakca/abuse-templates/blob/master/dmca.template](https://github.com/coldhakca/abuse-templates/blob/master/dmca.template)
|
||||
@@ -1,21 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import IspTable from 'components/outputs/csv2md-outputs/isp-sheet.md';
|
||||
|
||||
|
||||
# Where to host your `nym-node`?
|
||||
|
||||
Inspired by a valuable resource, done by Tor community - [*Good Bad ISPs*](https://community.torproject.org/relay/community-resources/good-bad-isps/), LunarDAO squad initiated a table customised for Nym Exit Gateways operators.
|
||||
|
||||
This ISP list is fully managed by Nym operator community and it serves as a space to share their experience of running Exit Gateways on various Internet Service Providers (ISPs). The ISPs greatly differ in regards to services they offer as well as to their openess of hosting exit routing software.
|
||||
|
||||
Please share any experiences running a node like policies, complains, legal issues and solutions, discrepancy between offers and reality (bandwidth, IP range, locations) or anything regarding pricing or customer support.
|
||||
|
||||
If you came across any legal findings, please share them in our [list of jurisdictions](jurisdictions.md).
|
||||
|
||||
While we trust that Nym node operators are honest, we would like to ask everyone to do your own research.
|
||||
|
||||
<Callout type="warning" emoji="">
|
||||
To edit or add information to the ISP list, make changes to the csv file located [here](https://github.com/nymtech/nym/blob/develop/documentation/docs/data/csv/isp-sheet.csv) and submit your edits as a pull request according to [this guide](add-content.mdx).
|
||||
</Callout>
|
||||
|
||||
<IspTable />
|
||||
@@ -1,17 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Exit Gateway - Jurisdictions
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences.
|
||||
</Callout>
|
||||
|
||||
There is no one silver bullet covering the entire globe. Every jurisdiction has different set of laws and practices regarding internet traffic routing. Therefore the Node Operators Legal Forum pages are divided per region.
|
||||
|
||||
These are some findings from our legal team as an example:
|
||||
|
||||
- [Switzerland](jurisdictions/swiss.mdx)
|
||||
- [United States](jurisdictions/united-states.mdx)
|
||||
|
||||
> Nym Node operators are invited to add their legal findings directly through [pull requests](add-content.mdx).
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"swiss": "Switzerland",
|
||||
"united-states": "USA"
|
||||
}
|
||||
@@ -1,75 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Legal environment: Switzerland
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences.
|
||||
</Callout>
|
||||
|
||||
## Findings from our legal team
|
||||
|
||||
> **Note:** The information shared below is in the stage of conclusions upon final confirmation. The text is a not edited exert from a legal counsel. Nym core team is asking for more clarifications.
|
||||
|
||||
### Operators of Exit Nodes
|
||||
|
||||
#### Telecoms Law
|
||||
|
||||
As well as operators of normal mixnet nodes, operators of exit nodes might be considered telecommunications providers according to the broad term of the telecommunications act (TCA).
|
||||
The regulatory consequences have already been laid out in section 5.1.2.2.1 above.
|
||||
|
||||
#### Telecoms Surveillance Law
|
||||
|
||||
Unlike normal mixnet nodes, exit nodes might have information about the communication party which uses the respective exit node (in particular its IP address). They might therefore be a target for surveillance authorities, at least at first glance.
|
||||
|
||||
However, as the IP address of the communications party is disguised on the other side of the communications through the Nym encryption infrastructure, the usual situation, where an IP address or another trace of an Internet user is found in the connection with a criminal activity (e.g., in a web server protocol), and then used in cooperation with the user’s provider to identify the user, is not going to take place.
|
||||
|
||||
The same is true for the opposite side: The node operator does not see the communication party of his user.
|
||||
|
||||
Experience has shown that Swiss investigative authorities are aware of these limitations and do not conduct investigations against individuals who operate TOR nodes, for example. In one specific case that I know of, the investigation was stopped by the police as soon as it was clear that a TOR node was being operated.
|
||||
|
||||
I therefore consider the risk for an exit node operator to become involved in a SPTA proceeding as low.
|
||||
|
||||
Nevertheless, in such a situation, exit node operators providers would have to provide the authorities with the information already available to them (Art. 22 Para. 3 SPTA), and they would have to tolerate monitoring by the authorities or by the persons commissioned by the service of the data which the monitored person transmits or stores using derived communications services (Art. 27 Para. 1 SPTA; see above, 5.1.1.2). There is no duty of data retention for providers of derived communication services, though.
|
||||
|
||||
The risk for exit node operators of being upgraded according to Art. 22 Para. 4 SPTA is low to non existent for the reasons mentioned above.
|
||||
|
||||
#### Intelligence Service Law
|
||||
|
||||
Operators of exit nodes do not provide wire-based telecommunications services either and therefore do not fall under the IntelSA.
|
||||
|
||||
### Nym as VPN provider
|
||||
|
||||
#### Telecoms Law
|
||||
|
||||
Nym as a VPN operator might be considered a telecommunication provider under the newly revised TCA, as the term now also covers operators of Over-the-Top services which are carried out over the internet.
|
||||
|
||||
However I consider possible administrative burdens arising from this qualification as negligible (see above, 5.1.2.1).
|
||||
|
||||
#### Telecoms Surveillance Law
|
||||
|
||||
VPN providers have information about the communication party which uses the respective exit node (in particular its IP address). They might therefore be a target for surveillance authorities, at least at first glance.
|
||||
|
||||
However, for the same reason I see a risk low for exit node operators to become involved in a SPTA proceeding (the IP address is not visible to the communication partner, which is exactly the reason the Nym VPN is being used at all), I also see a low risk for Nym itself to become involved in such a proceeding (see above, 5.1.3.2).
|
||||
|
||||
#### Intelligence Service Law
|
||||
|
||||
VPN operators do not provide wire-based telecommunications services and therefore do not fall under the IntelSA.
|
||||
|
||||
### EU chat control regulation in particular
|
||||
|
||||
According to a EU commission proposal for a regulation laying down rules to prevent and combat child sexual abuse (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX: 52022PC0209) hosting providers and providers of so-called interpersonal communication services should be obliged to perform an assessment of risks of online child sexual abuse. Additionally an obligation for certain providers should be established to detect such abuse, to report it via the EU Centre, to remove or disable access to, or to block online child sexual abuse material when so ordered.
|
||||
|
||||
'Interpersonal communications service’ means a service normally provided for remuneration that enables direct interpersonal and interactive exchange of information via electronic communications networks between a finite number of persons, whereby the persons initiating or participating in the communication determine its recipient(s) and does not include services which enable interpersonal and interactive communication merely as a minor ancillary feature that is intrinsically linked to another service (Art. 2 Point 5 Directive (EU) 2018/1972, which is also relevant for the mentioned proposal).
|
||||
|
||||
Interpersonal communications services are services that enable interpersonal and interactive exchange of information. Interactive communication entails that the service allows the recipient of the information to respond. The proposal therefore only covers services like traditional voice calls between two individuals but also all types of emails, messaging services, or group chats. Examples for services which do not meet those requirements are linear broadcasting, video on demand, websites, social networks, blogs, or exchange of information between machines (Directive (EU) 2018/1972, Consideration 17).
|
||||
|
||||
Neither the Nym encryption infrastructure nor the NYM VPN are used as means for an interactive exchange of information in the aforementioned sense (of e-mail, messaging, chats or similar).
|
||||
|
||||
I therefore consider the risk arising from the mentioned proposal for Nym as low, be it as software developer or VPN operator.
|
||||
|
||||
However, an application provider which uses the Nym encryption infrastructure to provide encrypted chat services or similar could still fall under the proposal. This might pose a commercial risk for Nym as the provider of the basic infrastructure for such services, because such services might lose their commercial value for end customers.
|
||||
|
||||
Currently the EU decision on chat control has been postponed because there is a blocking minority which can prevent the adoption of the respective parts of the law. In addition, even EU internal lawyers held that the proposal was clearly in violation of the EU charter of fundamental rights and would therefore be nullified by the EU courts in case it would still be enacted by the parliament.
|
||||
|
||||
I therefore consider the risk that the mentioned proposal is enacted by the EU authorities and finally upheld by the courts in its planned form as low.
|
||||
|
||||
@@ -1,23 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Legal environment: United States
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The following part is for informational purposes only. Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the [Node Operator](https://matrix.to/#/#operators:nymtech.chat) and [Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) channels on Element to share best practices and experiences.
|
||||
</Callout>
|
||||
|
||||
## Findings from our legal team
|
||||
|
||||
> **Note:** The information shared below is in the stage of conclusions upon final confirmation. The text is a not edited exert from a legal counsel. Nym core team is asking for more clarifications.
|
||||
|
||||
The US legal counsel have so far provided the following advice:
|
||||
|
||||
The legal risk faced by VPN operators subject to United States jurisdiction depends on various statutes and regulations related to privacy, anonymity, and electronic communications. The key areas to consider are: intermediary liability and exceptions, data protection, copyright infringement, export controls, criminal law, government requests for data and assistance, and third party liability.
|
||||
|
||||
As outlined in Part A, the United States treats VPNs as telecommunications networks subject to intermediary liability protection from wrongful conduct that occurs on its network. However, such protections do have exceptions including criminal law and copyright claims that are worth considering. In the United States, I am not aware of an individual ever being prosecuted or convicted for running a node for a dVPN or a Privacy Enhancing Network.
|
||||
|
||||
However, as discussed in Part B-C, VPN operators are subject to law enforcement requests for access or assistance in obtaining access to data relevant to an investigation into allegedly unlawful conduct that was facilitated by the network as an intermediary. As shown in Part C, governments may also request assistance from node operators for certain high-level and national security targets.
|
||||
|
||||
Finally, as outlined in Parts D-G, VPN operators may also be subject to non-criminal liability including (Part D) failing to respond to notices under the DMCA, (Part E) privacy and data protection law, (Part F) third party lawsuits stemming from wrongful acts committed using the network, and (G) export control violations.
|
||||
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Landing Pages
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The entire content of this page is under [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/).
|
||||
</Callout>
|
||||
|
||||
> Nym Node operators are invited to add their legal findings and suggestions directly through [pull requests](add-content.mdx).
|
||||
|
||||
Exit Gateway landing page is a great and transparent way to prevent possible troubles by providing people with basic facts, links to laws and regulations on a given topic as well as operator's contact info. To inspire each other we share some examples how Nym community handled this issue below.
|
||||
|
||||
Initiated by an amazing pull request from Avril 14th we made a complete guide to setup landing page behind [reverse proxy and Web Secure Socket](../nodes/nym-node/configuration/proxy-configuration.mdx) for Nym Nodes.
|
||||
@@ -1,26 +0,0 @@
|
||||
**ISP**,**Locations**,**Public IPv6**,**Crypto Payments**,**Comments**,**Last Updated**
|
||||
[Flokinet](https://flokinet.is),"Netherlands, Iceland, Romania,France","Yes, needs a ticket and custom setup","yes, including XMR","Very slow customer support","05/2024"
|
||||
[BitLaunch](https://bitlaunch.io),"Canada, USA, UK","No","Yes","Expensive. Digial Ocean through BitLanch has IPv6","05/2024"
|
||||
[Hostinger](https://hostinger.com),"France, Lithuania, India, USA, Brazil","Yes, out of the box","Yes","Crypto payments must be done per each server monthly or annually.","05/2024"
|
||||
[Linode](https://linode.com),"USA, Canada, Japan, India, Indonesia, Sweden, Netherlands, Germany, Brazil, France, UK, Australia, Italy","Yes out of the box","No, only through [BitLAunch](https://bitlaunch.io)","IPv6 sometimes need to be re-added in Networking tab, no reboot needed","05/2024"
|
||||
[Cherry Servers](https://www.cherryservers.com),"Lithuania, Netherlands, USA, Singapore","No","Yes","Issued IP doesn’t match the location offered by the provider.","05/2024"
|
||||
[Njalla](https://nja.la),"Sweden","Yes","Yes","Privacy vandguards! The biggest VPS 45 is 3 cores only, but it works better than many “larger” servers on the market.","05/2024"
|
||||
[HostSailor](https://hostsailor.com),"USA","Yes, based on ticket","Yes","The IPv6 setup needs custom research and is not documented","05/2024"
|
||||
[Misaka](https://www.misaka.io/),"South Africa","Yes, native support","No","Very Expensive","05/2024"
|
||||
[IsHosting](https://ishosting.com/en),"Brazil, Netherlands","Yes, based on ticket","Yes","Expensive","05/2024"
|
||||
[AlexHost](https://alexhost.com),"Moldova, Bulgaria, Sweden, Netherlands","Yes, on by default","Yes","They allow TOR Bridges, Relays. Exit nodes are only allowed on dedicated servers (prices start from 26 EUR)","07/2024"
|
||||
[iHostArt](https://ihostart.com),"Romania","Yes, on by default","Yes","Super permissive provider. They do allow Tor Exit/Relay/Bridge. Pro-free speech etc. Recently, IPv6 geolocation was set to North Korea, so be aware.","07/2024"
|
||||
[Incognet](https://incognet.io),"Netherlands and USA","Yes, on by default","Yes","They allow Tor exit nodes but you must adhere to their rules https://incognet.io/tor-exits","07/2024"
|
||||
[vSys Host](https://vsys.host),"Ukraine, Netherlands, USA","Yes, on by default","Yes","Pretty permissive provider registered in Ukraine. Should allow Relay/Exit nodes but nothing in T&C, so better double check.","07/2024"
|
||||
[LiteServer](https://liteserver.nl),"Netherlands","Yes, on by default","Yes","Very reliable Dutch provider. They do allow Relay nodes but for Exit nodes you need to contact them. Always check T&C https://liteserver.nl/legal","07/2024"
|
||||
[TerraHost](https://terrahost.no),"Norway","Yes, on by default","Yes","Very reliable Norwegian provider. Only allow exit nodes on Dedicated servers subject to certain caveats (you must open a ticket). Always check T&C https://terrahost.no/avtalebetingelser","07/2024"
|
||||
[Mevspace](https://mevspace.com),"Poland","Yes, on by default","Yes","Flexible Polish providers with 3 DCs in Poland. They do allow Tor Exit nodes but you may need a dedicated server for this. Make sure you open a ticket to check. As of today's date, they have 48h for 1 EUR tariff","07/2024"
|
||||
[Hostiko](https://hostiko.com.ua),"Ukraine, Germany","Yes, on by default","Yes","Ukrainian provider. They allow Exit nodes on Germany boxes but limit the bandwidth, you also have to restrict certain ports like 25 and 587. Make sure you open a ticket.","07/2024"
|
||||
[Hostslick](https://hostslick.com),"Netherlands, Germany","Yes, on by default","Yes","Good amount of bandwidth for the price. Make sure you open the ticket if you want to run Exit node","07/2024"
|
||||
[RDP](https://rdp.sh),"Netherlands, USA, Poland","Yes, on by default","Yes","German provider. Exit nodes are allowed, policy is here https://rdp.sh/docs/faq/tor ports 25,465,587 must be closed. Make sure you open a ticket before running an exit node.","07/2024"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@@ -1,5 +0,0 @@
|
||||
{
|
||||
"general-faq": "General Operators",
|
||||
"nym-nodes-faq": "Nym Nodes",
|
||||
"nyx-faq": "Nyx & Validators"
|
||||
}
|
||||
@@ -1,47 +0,0 @@
|
||||
# General Operators FAQ
|
||||
|
||||
## Nym Network
|
||||
|
||||
To see different stats about Nym Network live, we recommend you to visit [Nym Harbourmaster](https://harbourmaster.nymtech.net) and dynamic [Nym token page](https://nymtech.net/about/token.
|
||||
|
||||
### Is there an explorer for Nym Mixnet?
|
||||
|
||||
Yes, there are..
|
||||
|
||||
**Built by Nym**
|
||||
|
||||
* [Nym Explorer](https://explorer.nymtech.net/)
|
||||
* [Sandbox testnet](https://sandbox-explorer.nymtech.net/)
|
||||
* [Nym Harbourmaster](https://harbourmaster.nymtech.net)
|
||||
|
||||
**Built by community**
|
||||
|
||||
* [ExploreNYM](https://explorenym.net/)
|
||||
* [Mixplorer](https://mixplorer.xyz/)
|
||||
|
||||
|
||||
### Which VPS providers would you recommend?
|
||||
|
||||
Consider in which jurisdiction you reside and where do you want to run a node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to choose smaller and decentralised VPS providers over the most known ones controlling a majority of the internet. Nym operators community started an ISP table called [*Where to host your nym node?*](../community-counsel/isp-list.mdx), check it out and add your findings!
|
||||
|
||||
### Why is a node setup on a self-hosted machine so tricky?
|
||||
|
||||
We don't recommend this setup because it's really difficult to get a static IP and route IPv6 traffic.
|
||||
|
||||
### What's the Sphinx packet size?
|
||||
|
||||
The sizes are shown in the configs [here](https://github.com/nymtech/nym/blob/develop/common/nymsphinx/params/src/packet_sizes.rs#L32) (default is the one clients use, the others are for research purposes, not to be used in production as this would fragment the anonymity set). More info can be found [here](https://github.com/nymtech/nym/blob/develop/common/nymsphinx/anonymous-replies/src/reply_surb.rs#L80).
|
||||
|
||||
### Why a Mix Node and a Gateway cannot be bonded with the same wallet?
|
||||
|
||||
Because of the way the smart contract works we keep it one-node one-address at the moment. This will change very soon as a `nym-node` will be run with multiple modes.
|
||||
|
||||
### Which nodes are the most needed to be setup to strengthen Nym infrastructure and which ones bring rewards?
|
||||
|
||||
At this point the most crucial component needed are [Exit Gateways](../nodes/nym-node/setup.mdx#initialise--run) routing wireguard.
|
||||
|
||||
### Are Nym Nodes whitelisted?
|
||||
|
||||
Nope, anyone can run a Nym Node. whether your node is chosen to mix is purely reliant on the node's performance and reputation (self stake + delegations).
|
||||
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Nym Nodes related Frequently Asked Questions
|
||||
|
||||
### What determines the rewards when running a `nym-node --mode mixnode`?
|
||||
|
||||
The stake required for a node (currently only mode `--mixnode`) to achieve maximum rewards is called Node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 40% of the staking supply locked in Mix Nodes.
|
||||
|
||||
The node stake saturation point, is given by the stake supply, target level of staking divided between all bonded nodes.
|
||||
|
||||
This design ensures the nodes aim to have a same size of stake (reputation) which can be done by delegation staking, as well as it secures a whale prevention and decentralization of staking, as any higher level of delegated NYM than Nsat per node results in worsening reward ratio. On the contrary, the more nodes are bonded in the mixnet, the lower is Nsat. The equilibrium is reached when the staked tokens are delegated equally across the registered nodes and that's our basis for this incentive system.
|
||||
|
||||
- Nym mixnet active set - the mixing nodes rewarded - is currently 240 nodes. The selection and reward distribution happens every epoch (60 min) and the criteria for node to be chosen into the active set is:
|
||||
|
||||
> ACTIVE_SET_PROBABILITY = NODE_PERFORMANCE ^ 20 * STAKE_SATURATION
|
||||
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
We are working on a new tokenomics and reward pages. Coming out soon.
|
||||
</Callout>
|
||||
@@ -1,18 +0,0 @@
|
||||
## Validators and Tokens
|
||||
|
||||
### What's the difference between NYM and uNYM?
|
||||
|
||||
> 1 NYM = 1 000 000 uNYM
|
||||
|
||||
### Why some Nyx blockchain operations take one hour and others are instant?
|
||||
|
||||
This is based on the definition in [Nym's CosmWasm](https://github.com/nymtech/nym/tree/develop/common/cosmwasm-smart-contracts) smart contracts code.
|
||||
|
||||
Whatever is defined as [a pending epoch event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L35-L103) will get resolved at the end of the current epoch.
|
||||
|
||||
And whatever is defined as [a pending interval event](https://github.com/nymtech/nym/blob/b07627d57e075b6de35b4b1a84927578c3172811/common/cosmwasm-smart-contracts/mixnet-contract/src/pending_events.rs#L145-L172) will get resolved at the end of the current interval.
|
||||
|
||||
### Why is validator set entry whitelisted?
|
||||
|
||||
We understand that the early days of the Nyx blockchain will face possible vulnerabilities in terms of size - easy to disrupt or halt the chain if a malicious party entered with a large portion of stake. Besides that, there are some legal issues we need to address before we can distribute the validator set in a fully permissionless fashion.
|
||||
|
||||
@@ -1,50 +0,0 @@
|
||||
# Introduction
|
||||
|
||||
This is **Nym's Operators guide**, containing information and setup guides for the various components of Nym network and Nyx blockchain validators.
|
||||
|
||||
Nym network (also known as mixnet) routes and mixes packets through Gateways and Mixnodes, all run from the same binary called `nym-node`.
|
||||
|
||||
```ascii
|
||||
┌─►mix──┐ mix mix
|
||||
│ │
|
||||
Entry │ │ Exit
|
||||
client ───► Gateway ──┘ mix │ mix ┌─►mix ───► Gateway ───► internet
|
||||
│ │
|
||||
│ │
|
||||
mix └─►mix──┘ mix
|
||||
```
|
||||
|
||||
If you are new to Nym and want to learn about the Mixnet, explore kickstart options and demos, learn how to integrate with the network, and follow developer tutorials check out the [Developer Portal](https://nymtech.net/docs/developers/).
|
||||
|
||||
If you want to dive deeper into Nym's architecture, clients, nodes, and SDK examples visit the [technical docs](https://nymtech.net/docs/network).
|
||||
|
||||
|
||||
## Popular pages
|
||||
|
||||
**Binary Information**
|
||||
|
||||
* [Building Nym](binaries/building-nym.mdx)
|
||||
* [Pre-built Binaries](binaries/pre-built-binaries.mdx)
|
||||
|
||||
**Node setup and usage guides:**
|
||||
|
||||
* [Nym Node](nodes/nym-node/nym-node.mdx)
|
||||
* [Nymvisor](nodes/maintenance/nymvisor-upgrade.mdx)
|
||||
* [Validators](nodes/validator-setup.mdx)
|
||||
* [Nym API Setup](nodes/validator-setup/nym-api.mdx)
|
||||
|
||||
**Maintenance, troubleshooting and FAQ**
|
||||
|
||||
* [FAQ](faq/nym-nodes-faq.mdx)
|
||||
* [Maintenance](nodes/maintenance.mdx)
|
||||
* [Troubleshooting](troubleshooting/nodes.mdx)
|
||||
|
||||
**Community Counsel**
|
||||
|
||||
* [Exit Gateway](community-counsel/exit-gateway.mdx)
|
||||
* [Community Counsel](community-counsel.mdx)
|
||||
* [How to Add Info](community-counsel/add-content.mdx)
|
||||
|
||||
**Archive**
|
||||
|
||||
*[FAQ: Project Smoosh](archive/faq/smoosh-faq.mdx)
|
||||
@@ -1,17 +0,0 @@
|
||||
# Code of Conduct
|
||||
|
||||
We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
|
||||
|
||||
Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
|
||||
|
||||
Please be kind and courteous. There’s no need to be mean or rude.
|
||||
|
||||
Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
|
||||
|
||||
Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
|
||||
|
||||
We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behaviour that excludes people in socially marginalized groups.
|
||||
|
||||
Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust moderation team immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.
|
||||
|
||||
Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.
|
||||
@@ -1,11 +0,0 @@
|
||||
# Licensing
|
||||
|
||||
As a general approach, licensing is as follows this pattern:
|
||||
|
||||
* <p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://nymtech.net/docs">Nym Documentation</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://nymtech.net">Nym Technologies</a> is licensed under <a href="http://creativecommons.org/licenses/by-nc-sa/4.0/?ref=chooser-v1" target="_blank" rel="license noopener noreferrer" style="display:inline-block;">CC BY-NC-SA 4.0<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/nc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1"></a></p>
|
||||
|
||||
* Nym applications and binaries are [GPL-3.0-only](https://www.gnu.org/licenses/)
|
||||
|
||||
* Used libraries and different components are [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) or [MIT](https://mit-license.org/)
|
||||
|
||||
For accurate information, please check individual files.
|
||||
@@ -1,9 +0,0 @@
|
||||
# Terms and Conditions
|
||||
|
||||
With `nym-node` version `1.1.3`, NymTech SA introduced [**Operators Terms & Conditions**]({{toc_page}}) for operators who want their nodes to become a part of the active set of Nym Mixnet.
|
||||
|
||||
There has been a long ongoing discussion whether and how to apply Terms and Conditions for Nym network operators, with an aim to stay aligned with the philosophy of Free Software and provide legal defense for both node operators and Nym developers. To understand better the reasoning behind this decision, you can listen to the first [Nym Operator Town Hall](https://www.youtube.com/live/7hwb8bAZIuc?si=3mQ2ed7AyUA1SsCp&t=915) introducing the T&Cs or to [Operator AMA with CEO Harry Halpin](https://www.youtube.com/watch?v=yIN-zYQw0I0) from June 4th, 2024, explaining pros and cons of T&Cs implementation.
|
||||
|
||||
Accepting T&Cs is done via an explicit flag `--accept-operator-terms-and-conditions` added to `nym-node run` command.
|
||||
|
||||
More information on how to setup your node or check whether any node has T&C accepted can be found in [`nym-node` setup guide](nodes/setup.md#terms--conditions).
|
||||
@@ -1,7 +0,0 @@
|
||||
{
|
||||
"preliminary-steps": "Preliminary Steps",
|
||||
"nym-node": "Nym Node",
|
||||
"validator-setup": "Nyx Validator Setup",
|
||||
"maintenance": "Maintenance",
|
||||
"performance-and-testing": "Performance Monitoring & Testing"
|
||||
}
|
||||
@@ -1,304 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import {Accordion, AccordionItem} from "@nextui-org/react";
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import PortsNymNode from 'components/operators/snippets/ports-nym-node.mdx';
|
||||
import PortsValidator from 'components/operators/snippets/ports-validator.mdx'
|
||||
|
||||
# Maintenance
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Useful commands
|
||||
|
||||
* **`--no-banner`**: Adding `--no-banner` startup flag will prevent Nym banner being printed even if run in tty environment.
|
||||
|
||||
* **`build-info`**: A `build-info` command prints the build information like commit hash, rust version, binary version just like what command `--version` does. However, you can also specify an `--output=json` flag that will format the whole output as a json, making it an order of magnitude easier to parse.
|
||||
|
||||
For example `./target/debug/nym-network-requester --no-banner build-info --output json` will return:
|
||||
```json
|
||||
{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"}
|
||||
```
|
||||
|
||||
## Configure your firewall
|
||||
|
||||
Although your `nym-node` or `validator` (denoted as `<NODE>`) is now ready to receive traffic, your server may not be. The following commands will allow you to set up a firewall using `ufw`.
|
||||
|
||||
SSH to your server as `root` or become one running `sudo -i` or `su`. If you prefer to administrate your VPS from a user environment, supply the commands with prefix `sudo`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Start with setting up the essential tools on your server.
|
||||
|
||||
- Get your system up to date
|
||||
```sh
|
||||
apt update -y && apt --fix-broken install
|
||||
```
|
||||
|
||||
- Install dependencies
|
||||
```sh
|
||||
apt -y install ca-certificates jq curl wget ufw jq tmux pkg-config build-essential libssl-dev git
|
||||
```
|
||||
|
||||
- Double check ufw is installed correctly
|
||||
```sh
|
||||
apt install ufw --fix-missing
|
||||
```
|
||||
|
||||
###### 2. Configure your firewall using Uncomplicated Firewall (UFW)
|
||||
|
||||
For a `nym-node` or Nyx validator to recieve traffic, you need to open ports on the server. The following commands will allow you to set up a firewall using `ufw`.
|
||||
|
||||
- Check if you have `ufw` installed:
|
||||
```sh
|
||||
ufw version
|
||||
```
|
||||
|
||||
- If it's not installed, install with:
|
||||
```sh
|
||||
apt install ufw -y
|
||||
```
|
||||
|
||||
- Enable ufw
|
||||
```sh
|
||||
ufw enable
|
||||
```
|
||||
|
||||
- Check the status of the firewall
|
||||
```sh
|
||||
ufw status
|
||||
```
|
||||
|
||||
###### 3. Open all needed ports to have your firewall for `nym-node` working correctly
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<code>nym-node</code>,
|
||||
<code>validator</code>,
|
||||
]} defaultIndex="0">
|
||||
<MyTab><PortsNymNode /></MyTab>
|
||||
<MyTab><PortsValidator /></MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
- In case of reverse proxy setup add:
|
||||
```sh
|
||||
ufw allow 443/tcp
|
||||
```
|
||||
|
||||
- Re-check the status of the firewall:
|
||||
```sh
|
||||
ufw status
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
For more information about your node's port configuration, check the [port reference table](#ports) below.
|
||||
|
||||
## Backup a node
|
||||
|
||||
Anything can happen to the server on which your node is running. To back up your `nym-node` keys and configuration protects the operators against the negative impact of unexpected events. To restart your node on another server, two essential pieces are needed:
|
||||
|
||||
1. Node keys to initialise the same node on a new VPS
|
||||
2. Access to the bonding Nym account (wallet seeds) to edit the IP on smart contract
|
||||
|
||||
Assuming that everyone access their wallets from local machine and does *not* store their seeds on VPS, point 2. should be a given.
|
||||
To backup your `nym-node` keys and configuration in the easiest way possible, copy the entire config directory `.nym` from your VPS to your local desktop, using a special copy command `scp`:
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Never store your mnemonic seed anywhere online nor do *not* share it with anyone!
|
||||
</Callout>
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create a directory where you want to store your backup
|
||||
```sh
|
||||
mkdir -pv <PATH_TO_TARGET_DIRECTORY>
|
||||
```
|
||||
|
||||
###### 2. Copy configuration folder `.nym` from your VPS to your newly created backup directory
|
||||
|
||||
```sh
|
||||
scp -r <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/nym-nodes/<ID> <PATH_TO_TARGET_DIRECTORY>
|
||||
```
|
||||
|
||||
###### 3. Verify the success of the backup
|
||||
|
||||
The `scp` command should print logs, an operator can see directly whether it was successful or if it encountered any error. However, double check that all your needed configuration is in the backup target directory.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Restoring a node
|
||||
|
||||
In case your VPS shut down and you have a [backup](#backup-a-node) of your node keys and access to your bonding wallet, you can easily restore your node on another server without losing your delegation.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Prepare new VPS
|
||||
|
||||
- On VPS: Do all [preliminary steps](preliminary-steps.mdx) needed to run a `nym-node`.
|
||||
|
||||
- On VPS: Create a `.nym/nym-nodes` configuration folder:
|
||||
```sh
|
||||
mkdir -pv ~/.nym/nym-nodes
|
||||
```
|
||||
|
||||
###### 2. Restore your node configuration
|
||||
|
||||
From machine where your node is backed up (usually local desktop): Copy the folder with your node keys and configuration to the newly created folder on your VPS using `scp` command. Make sure to grab the entire `nym-node` configuration folder, which is called after your local `nym-node` identifier (`<ID>`), the `-r` (recursive) flag will take care of all sub-directories and their content:
|
||||
```sh
|
||||
scp -r <PATH_TO_LOCAL_NODE_CONFIGURATION_FOLDER> <VPS_USER_NAME>@<VPS_HOST_ADDRESS>:~/.nym/nym-nodes/
|
||||
```
|
||||
|
||||
The `scp` command should print logs, an operator can see directly whether it was successful or if it encountered any error. However, double check that all your needed configuration is in the target directory `.nym/nym-nodes` on your VPS.
|
||||
|
||||
|
||||
###### 3. Configure your node on the new VPS
|
||||
|
||||
* Edit `~/.nym/nym-nodes/<ID>/config/config.toml` config with the new listening address IP - it's the one under the header `[host]`, called `public_ips = [<PUBLIC_IPS>,]` and add your new location (field `location = <LOCATION>`, formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided). You can see your IP by running a command `echo "$(curl -4 https://ifconfig.me)"`.
|
||||
|
||||
* Try to run the node and see if everything works.
|
||||
|
||||
* Setup the [systemd](nym-node/configuration.mdx#systemd) automation (don't forget to add the [terms and conditions flag](nym-node/setup.mdx#terms--conditions)) to `ExecStart` command, reload the daemon and run the service.
|
||||
|
||||
###### 4. Change the node smart contract info via the wallet interface
|
||||
|
||||
Open Nym Wallet, go to *Bonding*, open *Settings* and change *Host* value to the new `nym-node` IP address. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks, returning zero performance.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Moving a node
|
||||
|
||||
In case of a need to move a Nym Node from one machine to another and avoiding to lose the delegation, here are few steps how to do it.
|
||||
|
||||
<Steps>
|
||||
|
||||
##### 1. Prepare both servers
|
||||
|
||||
Assuming both machines are remote VPS.
|
||||
|
||||
* Make sure your `~/.ssh/<SSH_KEY>.pub` is in both of the servers `~/.ssh/authorized_keys` file
|
||||
* Create a `nym-node` folder in the target VPS. SSH in from your terminal and run:
|
||||
|
||||
```sh
|
||||
# in case none of the nym configs was created previously
|
||||
mkdir ~/.nym
|
||||
|
||||
#in case no `nym-node` was initialized previously
|
||||
mkdir ~/.nym/nym-nodes
|
||||
```
|
||||
|
||||
###### 2. Move the node data and keys to the new machine
|
||||
|
||||
* Open your **local terminal** (as that one's ssh key is authorized in both of the VPS) and run:
|
||||
```sh
|
||||
scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:~/.nym/nym-nodes <TARGET_USER_NAME>@<TARGET_HOST_ADDRESS>:~/.nym/nym-nodes/
|
||||
```
|
||||
|
||||
###### 3. Open new/target VPS terminal and configure the node
|
||||
|
||||
* Edit `~/.nym/nym-nodes/<ID>/config/config.toml` config with the new listening address IP - it's the one under the header `[host]`, called `public_ips = [<PUBLIC_IPS>,]` and add your new location (field `location = <LOCATION>`, formats like: 'Jamaica', or two-letter alpha2 (e.g. 'JM'), three-letter alpha3 (e.g. 'JAM') or three-digit numeric-3 (e.g. '388') can be provided). You can see your IP by running a command `echo "$(curl -4 https://ifconfig.me)"`.
|
||||
|
||||
* Try to run the node and see if everything works.
|
||||
|
||||
* Setup the [systemd](nym-node/configuration.mdx#systemd) automation (don't forget to add the [terms and conditions flag](nym-node/setup.mdx#terms--conditions)) to `ExecStart` command, reload the daemon and run the service. If you want to use the exact same service config file, you can also copy it from one VPS to another following the same logic by opening your **local terminal** (as that one's ssh key is authorized in both of the VPS) and running:
|
||||
```sh
|
||||
scp -r -3 <SOURCE_USER_NAME>@<SOURCE_HOST_ADDRESS>:/etc/systemd/system/nym-node.service <TARGET_USER_NAME>@<TARGET_HOST_ADDRESS>:/etc/systemd/system/nym-node.service
|
||||
```
|
||||
|
||||
###### 4. Change the node smart contract info via the wallet interface
|
||||
|
||||
* Open Nym Wallet, go to *Bonding*, open *Settings* and change *Host* value to the new `nym-node` IP address. Otherwise the keys will point to the old IP address in the smart contract, and the node will not be able to be connected, and it will fail up-time checks, returning zero performance.
|
||||
|
||||
* Make sure to stop the old node.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Rename Node Local Identifier
|
||||
|
||||
Local node identifier, denoted as `<ID>` accross the documentation (not the identity key) is a name chosen by operators which defines where the nodes configuration data will be stored, where the ID determines the path to `~/.nym/nym-nodes/<ID>/`. This ID is never shared on the network.
|
||||
|
||||
When running a [`nym-node`](nym-node/nym-node.mdx), a local identifier specified with a flag `--ID <ID>` is no longer necessary. Nodes without a specified ID will be assigned a default ID `default-nym-node`. This streamlines node management, particularly for operators handling multiple nodes via ansible and other automation scripts, as all data is stored at `~/.nym/nym-nodes/default-nym-node`.
|
||||
|
||||
If you already operate a `nym-node` and wish to change the local ID to `default-nym-node` or anything else, follow the steps below to do so.
|
||||
|
||||
<Callout>
|
||||
In the example we use `default-nym-node` as a target `<ID>`, if you prefer to use another name, edit the syntax in the commands accordingly.
|
||||
</Callout>
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Copy the configuration directory to the new one
|
||||
|
||||
```sh
|
||||
cp -r ~/.nym/nym-nodes/<ID> ~/.nym/nym-nodes/default-nym-node/
|
||||
```
|
||||
|
||||
###### 2. Rename all original `<ID>` occurrences in `config.toml` to `default-nym-node`
|
||||
|
||||
```sh
|
||||
# check occurences of the <SOURCE_ID>
|
||||
grep -ir "<ID>" ~/.nym/nym-nodes/default-nym-node/*
|
||||
```
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
If your node `<ID>` was too generic (like 'gateway' etc) and it occurs elsewhere than just a custom value, **do not use `sed` command but rewrite the values manually using a text editor!**
|
||||
</Callout>
|
||||
|
||||
- If you are clear with occurrence found above, move on using `sed` command:
|
||||
|
||||
```sh
|
||||
sed -i -e "s/<ID>/default-nym-node/g" ~/.nym/nym-nodes/default-nym-node/config/config.toml
|
||||
```
|
||||
|
||||
- If you are not sure and want to play it safe, do it manually by opening `config.toml` and rewriting each occurence of `<ID>`:
|
||||
```sh
|
||||
nano ~/.nym/nym-nodes/default-nym-node/config/config.toml
|
||||
```
|
||||
|
||||
###### 3. Validate by rechecking the config file content
|
||||
```sh
|
||||
# either re-run
|
||||
grep -ir "<ID>" ~/.nym/nym-nodes/default-nym-node/*
|
||||
|
||||
# or by reading the config file
|
||||
less ~/.nym/nym-nodes/default-nym-node/config/config.toml
|
||||
```
|
||||
- Pay extra attention to the `hostname` line. In case its value was somehow correlated with the source `<ID>` string you may need to correct it back
|
||||
|
||||
###### 4. Reload your [systemd service daemon](nym-node/configuration.mdx#systemd) and restart the service
|
||||
|
||||
- If you chosen `default-nym-node` as an ID, you can drop `--id` flag from node running commands, otherwise specify with the new `<ID>`.
|
||||
- If automation isn't your thing, simply reboot the node. To automate with `systemd` is highly recommended.
|
||||
|
||||
###### 5. Be careful before removing old config
|
||||
|
||||
- If you double-checked that everything works fine, you can consider removing your old config directory
|
||||
|
||||
</Steps>
|
||||
|
||||
## Ports
|
||||
|
||||
All `<NODE>`-specific port configuration can be found in `$HOME/.nym/<NODE>/<YOUR_ID>/config/config.toml`. If you do edit any port configs, remember to restart your client and node processes.
|
||||
|
||||
### Nym Node Port Reference
|
||||
| Default port | Use |
|
||||
| ------------ | ------------------------- |
|
||||
| `1789` | Listen for Mixnet traffic |
|
||||
| `1790` | Listen for VerLoc traffic |
|
||||
| `8080` | Metrics http API endpoint |
|
||||
| `1789` | Listen for Mixnet traffic |
|
||||
| `9000` | Listen for Client traffic |
|
||||
| `9001` | WSS |
|
||||
| `51822/udp` | WireGuard |
|
||||
|
||||
### Validator Port Reference
|
||||
|
||||
All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator.
|
||||
|
||||
| Default port | Use |
|
||||
|--------------|--------------------------------------|
|
||||
| 1317 | REST API server endpoint |
|
||||
| 26656 | Listen for incoming peer connections |
|
||||
| 26660 | Listen for Prometheus connections |
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"manual-upgrade": "Manual Node Upgrade",
|
||||
"nymvisor-upgrade": "Automatic Node Upgrade: Nymvisor"
|
||||
}
|
||||
@@ -1,95 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import DesktopWalletUpdate from 'components/operators/snippets/update-desktop-wallet-steps.mdx';
|
||||
import CliUpdate from 'components/operators/snippets/update-cli-steps.mdx'
|
||||
|
||||
# Manual Node Upgrade
|
||||
|
||||
This page explains how to upgrade [`nym-node`](#nym-node-upgrade) or [`validator`](#validator-upgrade) to the latest version in a few steps. If you prefer to automate the process, try to setup your flow with [Nymvisor](nymvisor-upgrade.md).
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Nym node Upgrade
|
||||
|
||||
**Upgrading your node is a straight forward two-step process:**
|
||||
|
||||
<Steps>
|
||||
|
||||
#### 1. Updating the binary and `~/.nym/nym-nodes/<ID>/config/config.toml` on your VPS
|
||||
|
||||
#### 2. Updating the node information in the [mixnet smart contract](https://nymtech.net/docs/nyx/mixnet-contract.html). This is the information that is present on the [mixnet explorer](https://explorer.nymtech.net).
|
||||
|
||||
</Steps>
|
||||
|
||||
Below are detailed steps how to do it:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Upgrading node binary and information in config file
|
||||
|
||||
- Pause your node process.
|
||||
- If you run your node as `systemd` service (recommended), run: `service nym-node stop`
|
||||
- Otherwise open the terminal window with your node logs and press `ctrl + c`
|
||||
|
||||
- Replace the existing `nym-node` binary with the newest binary (which you can either [compile yourself](../../binaries/building-nym.mdx) or [download](../../binaries/pre-built-binaries.mdx).
|
||||
|
||||
- [Re-run with the same values](../nym-node/setup.mdx#initialise--run) as you use to run your `nym-node`. If you want keep changes in your config file, use flag `-w` (`--write-changes`), **This will just update the config file, it will not overwrite existing keys**.
|
||||
- If you automated your node with `systemd` (recommended) run:
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
service nym-node start
|
||||
```
|
||||
|
||||
- If you want to monitor the logs of your `nym-node.service`, run:
|
||||
```sh
|
||||
journalctl -f -u nym-node.service
|
||||
```
|
||||
|
||||
###### 2. Updating your node information in the smart contract
|
||||
|
||||
Follow these steps to update the information about your `nym-node` which is publicly available 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.
|
||||
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<strong>Desktop Wallet (recommended)</strong>,
|
||||
<strong>CLI (superusers)</strong>,
|
||||
]} defaultIndex="0">
|
||||
<MyTab><DesktopWalletUpdate/></MyTab>
|
||||
<MyTab><CliUpdate/></MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
</Steps>
|
||||
|
||||
## Validator Upgrade
|
||||
|
||||
Upgrading from `v0.31.1` -> `v0.32.0` process is fairly simple. Grab the `v0.32.0` release tarball from the [`nyxd` releases page](https://github.com/nymtech/nyxd/releases), and untar it. Inside are two files:
|
||||
|
||||
- The new validator (`nyxd`) v0.32.0
|
||||
- The new `wasmvm` (it depends on your platform, but most common filename is `libwasmvm.x86_64.so`)
|
||||
|
||||
Wait for the upgrade height to be reached and the chain to halt awaiting upgrade, then:
|
||||
|
||||
- Coopy `libwasmvm.x86_64.so` to the default LD_LIBRARY_PATH on your system (on Ubuntu 20.04 this is `/lib/x86_64-linux-gnu/`) replacing your existing file with the same name.
|
||||
- Swap in your new `nyxd` binary and restart.
|
||||
|
||||
You can also use something like [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/main/tools/cosmovisor) - grab the relevant information from the current upgrade proposal [here](https://nym.explorers.guru/proposal/9).
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Cosmovisor will swap the `nyxd` binary, but you'll need to already have the `libwasmvm.x86_64.so` in place.
|
||||
</Callout>
|
||||
|
||||
### Common Reasons Validator Being Jailed
|
||||
|
||||
The most common reason for your validator being jailed is that it runs out of memory because of bloated syslogs.
|
||||
|
||||
Running the command `df -H` will return the size of the various partitions of your VPS.
|
||||
|
||||
If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog archives and restart your validator process.
|
||||
|
||||
@@ -1,338 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import NymvisorBuildInfo from 'components/outputs/command-outputs/nymvisor-build-info.md';
|
||||
import NymvisorHelp from 'components/outputs/command-outputs/nymvisor-help.md';
|
||||
import NymvisorInitDaemon from 'components/outputs/command-outputs/nymvisor-init-daemon.md';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
|
||||
export const NymvisorInitD = () => (
|
||||
<div>
|
||||
</div>
|
||||
);
|
||||
|
||||
# Automatic Node Upgrade: Nymvisor Setup & Usage
|
||||
|
||||
> The Nymvisor binary was built in the [building nym](../../binaries/building-nym.mdx) section. If you haven't yet built Nym and want to run the code, go there first. You can build just Nymvisor with `cargo build --release --bin nymvisor`.
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## What is Nymvisor?
|
||||
|
||||
Nymvisor is a process manager for Nym binaries that monitors the Nym release information for any newly released binaries. If it detects any changes, Nymvisor can automatically download the binary, stop the current binary, switch from the old binary to the new one, and finally restart the underlying process with the new binary.
|
||||
|
||||
In essence, it tries to mirror the behaviour of [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/main/tools/cosmovisor), a tool used by Cosmos blockchain operators for managing/automating chain upgrades. Nymvisor, however, introduces some Nym-specific changes since, for example, upgrade information is obtained from our GitHub [releases page](https://github.com/nymtech/nym/releases) instead of (in the case of Cosmos blockchains) governance proposals.
|
||||
|
||||
### Supported Binaries
|
||||
|
||||
You can use Nymvisor to automate the upgrades of the following binaries:
|
||||
|
||||
* `nym-api`
|
||||
* `nym-node`
|
||||
* `nym-client`
|
||||
* `nym-socks5-client`
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Nymvisor is an early and experimental software. Users should use it at their own risk.
|
||||
</Callout>
|
||||
|
||||
## Current version
|
||||
|
||||
<NymvisorBuildInfo />
|
||||
|
||||
## Preliminary steps
|
||||
|
||||
You need to have at least one Nym Node / client / Nym API instance already set up on the **same VPS** that you wish to run Nymvisor on.
|
||||
|
||||
<Callout>
|
||||
Using Nymvisor presumes your VPS is running an operating system that is compatible with the pre-compiled binaries availiable on the [Github releases page](https://github.com/nymtech/nym/releases). If you're not, then until we're packaging for a greater variety of operating systems, you're stuck with [manually upgrading your node](manual-upgrade.mdx).
|
||||
</Callout>
|
||||
|
||||
## Setup and Usage
|
||||
|
||||
### Viewing command help
|
||||
|
||||
You can check that your binaries are properly compiled with:
|
||||
|
||||
```sh
|
||||
./nymvisor --help
|
||||
```
|
||||
|
||||
Which should return a list of all available commands.
|
||||
|
||||
<NymvisorHelp />
|
||||
|
||||
You can also check the various arguments required for individual commands with:
|
||||
|
||||
```sh
|
||||
./nymvisor <COMMAND> --help
|
||||
```
|
||||
|
||||
### Initialising your Nymvisor Instance
|
||||
|
||||
> This example will use the Nym Node binary as an example - however replacing `nym-node` with any other [supported binary](#supported-binaries) will work the same.
|
||||
|
||||
Initialise your Nymvisor instance with the following command. You must initialise Nymvisor with the binary you wish to add upgrades for:
|
||||
|
||||
```sh
|
||||
./nymvisor init --daemon-home ~/.nym/nym-node/<ID> <PATH>/nym-node
|
||||
```
|
||||
|
||||
Where the value of `--daemon-home` might be `~/.nym/nym-nodes/default-nym-node` and `<PATH>` might be `/home/sakine/nym/target/release/nym-node`, or wherever your node binary is located.
|
||||
|
||||
By default this will create config files at `~/.nym/nymvisors/instances/nym-node-default/config/config.toml` as shown in the console output above. For config options look at the different `--flags` available, or the [environment variables](#environment-variables) section below.
|
||||
|
||||
### Running your Nymvisor Instance
|
||||
|
||||
Nymvisor acts as a wrapper around the specified node process - it has to do this in order to be able to pause and restart this process. As such, you need to run your node _via_ Nymvisor!
|
||||
|
||||
The interface to the `nymvisor run <ARGS>` command is quite simple. Any argument passed after the `run` command will be passed directly to the underlying daemon, for example: `nymvisor run run --id default-nym-node` will run the `$DAEMON_NAME run --id default-nym-node` command (where `DAEMON_NAME` is the name of the binary itself (e.g. `nym-api`, `nym-node`, etc.)).
|
||||
|
||||
`run` Nymvisor and start your node via the following command. Make sure to stop any existing node before running this command.
|
||||
|
||||
```sh
|
||||
./nymvisor run run --id <ID>
|
||||
```
|
||||
|
||||
Nymvisor will now manage your node process (for an in-depth overview of this command check the [in-depth command information](./nymvisor-upgrade.md#commands-in-depth) below). It will periodically poll [this endpoint](https://nymtech.net/.wellknown/nym-node/upgrade-info.json) (replace `nym-node` with whatever node you may actually be running via Nymvisor) and check for a new `version` of the binary it is watching. If this exists, it will then, using the information proceed with these steps:
|
||||
|
||||
<Steps>
|
||||
|
||||
* Pause your node process
|
||||
* Grab the new binary (`version`)
|
||||
* Verify it against the provided `checksum`
|
||||
* Perform a data backup of the existing node
|
||||
* Replace the old binary with the new one
|
||||
* Restart the process
|
||||
|
||||
</Steps>
|
||||
|
||||
And that's it!
|
||||
|
||||
### Creating an Adhoc Upgrade
|
||||
|
||||
This section is for advanced users. Generally users **will not have to use this command**.
|
||||
|
||||
`nymvisor add-upgrade <PATH_TO_EXECUTABLE> --upgrade-name=<NAME> --arg1=value1 --arg2=value2 ...` can be used to amend an existing `upgrade-plan.json` by creating new entries or to add an executable to an existing scheduled upgrade so that it would not have to be downloaded.
|
||||
|
||||
Situations in which this command might be used are:
|
||||
- An adhoc upgrade if e.g. a patched version of a binary was required
|
||||
- If a user doesn't trust the verification process of Nymvisor's pipeline and wishes to build/verify the binary themselves before using Nymvisor to perform the upgrade
|
||||
- If a user isn't using a currently supported operating system and needs to manually specify a binary they have built themselves
|
||||
|
||||
Similarly to `init`, `add-upgrade` requires a positional argument specifying a valid path to the upgrade binary. Furthermore, the `--upgrade-name` keyword argument must be set in order to declare the upgrade name. The remaining arguments are optional. They include:
|
||||
|
||||
- `--force` - if specified, will allow Nymvisor to overwrite existing upgrade binary / `upgrade-info.json` files if they already exist
|
||||
- `--add-binary` - indicate that this command should only add binary to an existing scheduled upgrade
|
||||
- `--now` - if specified will force the upgrade to be performed immediately (technically not 'immediately' within few seconds). It can't be specified alongside either `--upgrade-time` or `--upgrade-delay` arguments
|
||||
- `--publish-date` - if a new `upgrade-info.json` file is going to be created, this argument will specify the `publish_date` metadata field. Otherwise, the current time will be used. The [RFC3339 datetime](https://www.rfc-editor.org/rfc/rfc3339) format is expected
|
||||
- `--upgrade-time` - specifies the time at which the provided upgrade will be performed (RFC3339 formatted). If left unset, the upgrade will be performed in 15 minutes. It can't be specified alongside either `--now` or `--upgrade-delay` arguments.
|
||||
- `--upgrade-delay` - specifies delay until the provided upgrade is going to get performed. If let unset, the upgrade will be performed in 15 minutes. It can't be specified alongside either `--upgrade_time` or `--now` arguments.
|
||||
|
||||
|
||||
## Maintenance and Configuration
|
||||
|
||||
Check the [Nymvisor Configuration page](nymvisor-upgrade/nymvisor-configuration.mdx) for information on Nymvisor process maintenance and automation. You can find more in-depth information about the various aspects of Nymvisor such as what happens [under the hood](#commands-in-depth) for various commands.
|
||||
|
||||
## Config
|
||||
|
||||
The output format of `nymvisor config` can be further configured with `--output` argument. By default a human-readable text representation is used:
|
||||
```ini
|
||||
id: nym-node-default
|
||||
daemon name: nym-node
|
||||
daemon home: /home/nym/.nym/nym-nodes/default-nym-node
|
||||
upstream base upgrade url: https://nymtech.net/.wellknown/
|
||||
disable nymvisor logs: false
|
||||
CUSTOM upgrade data directory ""
|
||||
upstream absolute upgrade url: ""
|
||||
allow binaries download: true
|
||||
enforce download checksum: true
|
||||
restart after upgrade: true
|
||||
restart on failure: false
|
||||
on failure restart delay: 10s
|
||||
max startup failures: 10
|
||||
startup period duration: 2m
|
||||
shutdown grace period: 10s
|
||||
CUSTOM backup data directory ""
|
||||
UNSAFE skip backups false
|
||||
```
|
||||
|
||||
- Adding `--output=json` would format the same data into JSON which can be more easily parsed programmatically to e.g. pipe the output into `jq` for further processing.
|
||||
```sh
|
||||
nymvisor config --output=json
|
||||
```
|
||||
- Outputs:
|
||||
```json
|
||||
{"nymvisor":{"id":"nym-node-default","upstream_base_upgrade_url":"https://nymtech.net/.wellknown/","upstream_polling_rate":"1h","disable_logs":false,"upgrade_data_directory":null},"daemon":{"name":"nym-node","home":"/home/nym/.nym/nym-nodes/default-nym-nodee","absolute_upstream_upgrade_url":null,"allow_binaries_download":true,"enforce_download_checksum":true,"restart_after_upgrade":true,"restart_on_failure":false,"failure_restart_delay":"10s","max_startup_failures":10,"startup_period_duration":"2m","shutdown_grace_period":"10s","backup_data_directory":null,"unsafe_skip_backup":false}}
|
||||
```
|
||||
|
||||
## CLI Overview
|
||||
|
||||
Command options are:
|
||||
|
||||
- `help`, `--help`, or `-h` - Output Nymvisor help information and display the available commands.
|
||||
- `config` - Display the current Nymvisor configuration, that means displaying the current configuration file that might have been overridden with environment variables value that Nymvisor is using.
|
||||
- `init` - Generate a `config.toml` file for this instance of Nymvisor that will use the provided arguments alongside any environmental variables that are set.
|
||||
- `add-upgrade` - Add an upgrade manually to Nymvisor. This command allows you to easily add the binary corresponding to an upgrade or amend the existing `upgrade-plan.json` whilst creating new `upgrade-info.json` file.
|
||||
- `build-info` - Output the build information.
|
||||
- `daemon-build-info` - Output the build information of the current binary used by the associated daemon.
|
||||
- `run` - Run the configured binary using the rest of the provided arguments.
|
||||
- `-V` or `--version` - Output the Nymvisor version
|
||||
|
||||
Similarly to other Nym binaries, Nymvisor supports a global `--config-env-file` or `-c` flag that allows specifying path to a `.env` file defining any relevant environmental variables that are going to be applied to any of the Nymvisor commands as described in the [Environment section](#environment-variables).
|
||||
|
||||
For commands that depend on Nymvisor config file (i.e. all but `init`), the configuration file is loaded as follows:
|
||||
|
||||
- If available, reading `$NYMVISOR_CONFIG_PATH`
|
||||
- Otherwise, if `$NYMVISOR_ID` is set, a default path will be used, i.e. `$HOME/.nym/nymvisors/instances/$NYMVISOR_ID/config/config.toml`
|
||||
- Finally, if there's only a single `nymvisor` instance instantiated (as defined by directories in `$HOME/.nym/nymvisors/instances`), that one will be loaded
|
||||
- If all of the above fails, an error is returned
|
||||
|
||||
Nymvisor attempts to load the file from the derived path. If it fails, it attempts to use one of the older schemes and upgrade it as it goes, the loaded configuration is then overridden with any value that might have been set in the environment.
|
||||
|
||||
## Environment Variables
|
||||
|
||||
<Callout>
|
||||
Please note environmental variables take precedence over any arguments passed, i.e. if one were to specify `--daemon_home="/foo"` and set `DAEMON_HOME="bar"`, the value of `"bar"` would end up being used.
|
||||
</Callout>
|
||||
|
||||
For any of its commands as described in [CLI Overview section](#cli-overview), Nymvisor reads its configuration from the following environment variables:
|
||||
|
||||
- `NYMVISOR_ID` is the human-readable identifier of the particular Nymvisor instance.
|
||||
- `NYMVISOR_CONFIG_PATH` is used to manually override path to the configuration file of the Nymvisor instance.
|
||||
- `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL` (defaults to https://nymtech.net/.wellknown/) is the base url of the upstream source for obtaining upgrade information for the daemon. It will be used fo constructing the full url, i.e. `$NYMVISOR_UPSTREAM_BASE_UPGRADE_URL/$DAEMON_NAME/upgrade-info.json`.
|
||||
- `NYMVISOR_UPSTREAM_POLLING_RATE` (defaults to 1h) is polling rate the upstream url for upgrade information.
|
||||
- `NYMVISOR_DISABLE_LOGS` (defaults to `false`). If set to `true`, this will disable Nymvisor logs (but not the underlying process) completely.
|
||||
- `NYMVISOR_UPGRADE_DATA_DIRECTORY` is the custom directory for upgrade data - binaries and upgrade plans. If not set, the global Nymvisors' data directory will be used instead.
|
||||
- `DAEMON_NAME` is the name of the binary itself (e.g. `nym-api`, `nym-node`, etc.).
|
||||
- `DAEMON_HOME` is the location where the `nymvisor/` directory is kept that contains the auxiliary files associated with the underlying daemon instance, such as any backups or current version information, e.g. `$HOME/.nym/nym-api/my-nym-api`, `$HOME/.nym/nym-nodes/default-nym-node`, etc.
|
||||
- `DAEMON_ABSOLUTE_UPSTREAM_UPGRADE_URL` is the absolute (i.e. the full url) upstream source for upgrade plans for this daemon. The url has to point to an endpoint containing a valid `UpgradeInfo` json file. If set it takes precedence over `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL`.
|
||||
- `DAEMON_ALLOW_BINARIES_DOWNLOAD` (defaults to `true`), if set to `true`, it will enable auto-downloading of new binaries (as declared by urls in corresponding `upgrade-info.json` files). For security reasons one might wish to disable it and instead manually provide binaries by either placing them in the appropriate directory or by invoking `add-upgrade` command.
|
||||
- `DAEMON_ENFORCE_DOWNLOAD_CHECKSUM` (defaults to `true`), if set to `true` Nymvisor will require that a checksum is provided in the upgrade plan for the upgrade binary to be downloaded. If disabled, Nymvisor will not require a checksum to be provided, but still check the checksum if one is provided.
|
||||
- `DAEMON_RESTART_AFTER_UPGRADE` (defaults to `true`), if set to `true` Nymvisor will restart the subprocess with the same command-line arguments and flags (but with the new binary) after a successful upgrade. Otherwise (`false`), Nymvisor stops running after an upgrade and requires the system administrator to manually restart it. **Note restart is only after the upgrade and does not auto-restart the subprocess after an error occurs.** That is controlled via `DAEMON_RESTART_ON_FAILURE`.
|
||||
- `DAEMON_RESTART_ON_FAILURE` (defaults to `true`), if set to `true`, Nymvisor will restart the subprocess with the same command-line arguments and flags if it has terminated with a non-zero exit code.
|
||||
- `DAEMON_FAILURE_RESTART_DELAY` (defaults to 10s), if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this will specify a delay between the process shutdown (with a non-zero exit code) and it being restarted.
|
||||
- `DAEMON_MAX_STARTUP_FAILURES` (defaults to 10) if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this defines the maximum number of startup failures the subprocess can experience in a quick succession before no further restarts will be attempted and Nymvisor will terminate.
|
||||
- `DAEMON_STARTUP_PERIOD_DURATION` (defaults to 120s) if `DAEMON_RESTART_ON_FAILURE` is set to `true`, this defines the length of time during which the subprocess is still considered to be in the startup phase when its failures are going to be counted towards the limit defined in `DAEMON_MAX_STARTUP_FAILURES`.
|
||||
- `DAEMON_SHUTDOWN_GRACE_PERIOD` (defaults to 10s), specifies the amount of time Nymvisor is willing to wait for the subprocess to undergo graceful shutdown after receiving an interrupt before it sends a kill signal.
|
||||
- `DAEMON_BACKUP_DATA_DIRECTORY` specifies custom backup directory for daemon data. If not set, `DAEMON_HOME/nymvisor/backups` is used instead.
|
||||
- `DAEMON_UNSAFE_SKIP_BACKUP` (defaults to `false`), if set to `true`, all upgrades will be performed directly without performing any backups. Otherwise (`false`), Nymvisor will back up the contents of `DAEMON_HOME` before trying the upgrade.
|
||||
|
||||
## Dir structure
|
||||
|
||||
The folder structure of Nymvisor is heavily inspired by Cosmovisor, but with some notable changes to accommodate our binaries having possibly multiple instances due to their different `--id` flags. The data is spread through three main directories:
|
||||
|
||||
- In a global `nymvisors` data directory shared by all Nymvisor instances (default: `$HOME/.nym/nymvisors/data`) that contains daemon upgrade plans, binaries and upgrades histories. It includes a sub-directory for each version of the application (i.e. `genesis` or `upgrades/<NAME>`). Within each sub-directory is the application binary (i.e. `bin/$DAEMON_NAME`), the associated `upgrade-info.json` and any additional auxiliary files associated with each binary. `current` is a symbolic link to the currently active directory (i.e. `genesis` or `upgrades/<NAME>`)
|
||||
|
||||
- In a home directory of a particular `nymvisor` instance (e.g. `$HOME/.nym/nymvisors/instances/<NYMVISOR_INSTANCE_ID>/`). It includes sub-directories for its configuration file (i.e. `config/config.toml`), that preconfigures the instance, and for any additional persistent data that might be added in the future (i.e. `data`)
|
||||
|
||||
- In a `nymvisor` data directory inside the home directory of the managed daemon instance (default: `$HOME/.nym/$DAEMON_NAME/nymvisor`) that contains sub-directories for data backups (i.e. `backups/<NAME>`) and current version information (`current-version-info.json`)
|
||||
|
||||
A sample full structure looks as follows:
|
||||
|
||||
```sh
|
||||
~/.nym
|
||||
├── nymvisors
|
||||
│ ├── instances
|
||||
│ │ ├── <id1>
|
||||
│ │ │ ├── config
|
||||
│ │ │ │ └── config.toml
|
||||
│ │ │ └── data
|
||||
│ │ │ └── ...
|
||||
│ │ └── <id2>
|
||||
│ │ └── ...
|
||||
│ └── data
|
||||
│ ├── nym-api
|
||||
│ │ ├── current -> genesis or upgrades/<name>
|
||||
│ │ ├── genesis
|
||||
│ │ │ ├── bin
|
||||
│ │ │ │ └── nym-api
|
||||
│ │ │ └── upgrade-info.json
|
||||
│ │ ├── upgrades
|
||||
│ │ │ └── <upgrade-name>
|
||||
│ │ │ ├── bin
|
||||
│ │ │ │ └── nym-api
|
||||
│ │ │ └── upgrade-info.json
|
||||
│ │ ├── upgrade-history.json
|
||||
│ │ └── upgrade-plan.json
|
||||
│ ├── nym-node
|
||||
│ │ └── ...
|
||||
│ └── $DAEMON_NAME
|
||||
│ └── ...
|
||||
└── nym-api
|
||||
├── <id1>
|
||||
│ ├── config
|
||||
│ │ └── <nym-api-config-data>
|
||||
│ ├── data
|
||||
│ │ └── <nym-api-data>
|
||||
│ └── nymvisor
|
||||
│ ├── backups
|
||||
│ │ └── <upgrade-name>
|
||||
│ │ └── ....
|
||||
│ └── current-version-info.json
|
||||
└── <id2>
|
||||
└── ...
|
||||
```
|
||||
|
||||
## Commands In-Depth
|
||||
This section outlines what happens under the hood with the following commands:
|
||||
|
||||
### `init`
|
||||
|
||||
`init` does the following:
|
||||
|
||||
- Executes the `$DAEMON_NAME build-info` command on the daemon executable to check its validity and obtain its name
|
||||
- Creates the required directory structure:
|
||||
- `$DAEMON_HOME/nymvisor` folder if it doesn't yet exist
|
||||
- `$DAEMON_BACKUP_DATA_DIRECTORY` folder if it doesn't yet exist
|
||||
- `$NYMVISOR_UPGRADE_DATA_DIRECTORY` folder if it doesn't yet exist
|
||||
- `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/bin` folder if it doesn't yet exist
|
||||
- `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/upgrades` folder if it doesn't yet exist
|
||||
- Copies the provided executable to `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/bin/$DAEMON_NAME`
|
||||
- Generates initial `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis/upgrade-info.json` file based on the provided binary
|
||||
- Generates initial `$DAEMON_HOME/nymvisor/current-version-info.json` file based on the provided binary
|
||||
- Creates a `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/current` symlink pointing to `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/genesis`
|
||||
- Saves the Nymvisor instance's config file to `$NYMVISOR_CONFIG_PATH` and creates the full directory structure for the file
|
||||
- Outputs (to `stdout`) the full configuration used
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
`nymvisor init` is specifically for initializing Nymvisor, and should **not** be confused with a daemon's `init` command - such as `nym-socks5-client init` (e.g. `nymvisor run init`).
|
||||
</Callout>
|
||||
|
||||
### `run`
|
||||
|
||||
`nymvisor run` is a lightweight wrapper around the underlying daemon. It uses only a single thread and spawns three simple tasks:
|
||||
|
||||
- An upstream puller that checks the upstream source (as defined by `DAEMON_ABSOLUTE_UPSTREAM_UPGRADE_URL` or derived from `NYMVISOR_UPSTREAM_BASE_UPGRADE_URL`) for any recently released upgrades. It then creates appropriate `upgrade-info.json` file and updates the `upgrade-plan.json`
|
||||
- A file watcher for the `upgrade-plan.json` file that can notify the main run loop of upgrades that were added by either the above upstream puller task or via the `add-upgrade` command,
|
||||
- The daemon run loop that:
|
||||
- Runs the `DAEMON_NAME` with the provided arguments until:
|
||||
- It completes the execution (with any exit code),
|
||||
- Nymvisor receives a `SIGINT`, `SIGTERM` or `SIGQUIT`,
|
||||
- A new upgrade is scheduled to be performed (by other task watching for changes in `upgrade-plan.json` and waiting until the `upgrade_time`,
|
||||
- If `DAEMON_UNSAFE_SKIP_BACKUP` is not set to `true`, it backups the content of `DAEMON_HOME` directory,
|
||||
- Performs the binary upgrade by:
|
||||
- Creating a temporary, exclusive and non-blocking, `upgrade.lock` file for the `DAEMON_NAME`. `flock` with `LOCK_EX | LOCK_NB` is used for that purpose. The file is created in case users didn't read any warnings and attempted to run multiple instances of `nymvisor` managing the same `DAEMON_NAME`,
|
||||
- Downloading the upgrade binary for the runners architecture using one of the urls defined in `upgrade-info.json`. Note, however, that this is only done if the binary associated with the `<UPGRADE-NAME>` does not already exist and `DAEMON_ALLOW_DOWNLOAD_BINARIES` is set to `true`,
|
||||
- If the binary has been downloaded and `DAEMON_ENFORCE_DOWNLOAD_CHECKSUM` is set to true, the file checksum is verified using the specified algorithm,
|
||||
- Verifying the upgrade binary - checking if it's a valid executable with expected `build-info`. Note that this will also set `a+x` bits on the file if those permissions have not already been set,
|
||||
- removing the queued upgrade from `upgrade-plan.json`,
|
||||
- Inserting new upgrade into the `upgrade-history.json`,
|
||||
- Updating the `current-version-info.json`,
|
||||
- Updating the `$NYMVISOR_UPGRADE_DATA_DIRECTORY/$DAEMON_NAME/current` symlink to the upgrade directory,
|
||||
- Removing the `upgrade.lock` file.
|
||||
- The above loop is repeated if either:
|
||||
- The daemon has crashed and `DAEMON_MAX_STARTUP_FAILURES` has not been reached yet,
|
||||
- The daemon has successfully been upgraded, `DAEMON_RESTART_AFTER_UPGRADE` has been set to `true` and the manual flag on the performed upgrade has been set to `false`.
|
||||
|
||||
### `add-upgrade`
|
||||
|
||||
`nymvisor add-upgrade` does the following:
|
||||
|
||||
- Executes the `$DAEMON_NAME build-info` command on the daemon executable to check its validity and obtain its name
|
||||
- Attempts to load existing `upgrade-info.json` for the provided `<upgrade-name>`. If it already exists and neither `--force` nor `--add-binary` was specified, Nymvisor will terminate
|
||||
- Checks if `upgrades/<UPGRADE_NAME>/$DAEMON_NAME` binary already exists. If it does and `--force` flag was not specified, Nymvisor will terminate the provided upgrade binary is copied to its appropriate location
|
||||
- if applicable, new `upgrade-info.json` is created and written to its appropriate location
|
||||
- `upgrade-plan.json` is updated with the new upgrade details. If there's an active Nymvisor instance running, this change will be detected to initialise upgrade process
|
||||
@@ -1,3 +0,0 @@
|
||||
{
|
||||
"nymvisor-configuration": "Nymvisor Configuration"
|
||||
}
|
||||
-98
@@ -1,98 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
|
||||
# Nymvisor Configuration
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Nymvisor Automation with `systemd`
|
||||
|
||||
This section contains guide how to setup `systemd` automation for Nymvisor. If you are looking for other chapters, visit these pages: [VPS setup](../../../preliminrary-steps/vps-setup.mdx), advanced terminal tools like [tmux and nohup setup](../../nym-node/configuration.mdx#vps-setup-and-automation), [`nym-node` automation](../../nym-node/configuration.mdx#systemd) or [`validator` automation](../../validator-setup/nyx-configuration#automation).
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Since you're planning to run your node via a Nymvisor instance, as well as creating a Nymvisor `.service` file, you will also want to **stop any previous node automation process you already have running**.
|
||||
</Callout>
|
||||
|
||||
SSH to your server as `root` or become one running `sudo -i` or `su`. If you prefer to administrate your VPS from a user environment, supply the commands with prefix `sudo`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create a service file
|
||||
|
||||
To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nymvisor.service` and follow the [next steps](#2-following-steps-for-nym-node-running-as-systemd-service).
|
||||
|
||||
- Open service file in a text editor
|
||||
```sh
|
||||
nano /etc/systemd/system/nymvisor.service
|
||||
```
|
||||
|
||||
- Paste this config file, substitute `<USER>` and `<PATH>` with your correct values and add all flags to run your `nymvisor` to `ExecStart` line instead of `<ARGUMENTS>`:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Nymvisor <VERSION>
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=<USER> # replace this with whatever user you wish
|
||||
LimitNOFILE=65536
|
||||
ExecStart=<PATH>/nymvisor run <ARGUMENTS>
|
||||
KillSignal=SIGINT
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
- Save config and exit
|
||||
|
||||
###### 2. Following steps for `nymvisor` running as `systemd` service
|
||||
|
||||
Once your service file is saved follow these steps.
|
||||
|
||||
- Reload systemctl to pickup the new unit file:
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
- Enable the newly created service:
|
||||
```sh
|
||||
systemctl enable nymvisor.service
|
||||
```
|
||||
|
||||
- Start your Nymvisor instance as a `systemd` service:
|
||||
```sh
|
||||
service nymvisor start
|
||||
```
|
||||
|
||||
This will cause your Nymvisor instance to start at system boot time. If you restart your machine, your service will come back up automatically.
|
||||
|
||||
###### 3. Useful `systemd` commands for easier management
|
||||
|
||||
- You can monitor system logs of your node by running:
|
||||
```sh
|
||||
journalctl -u nymvisor -f
|
||||
```
|
||||
|
||||
- Or check service status by running:
|
||||
```sh
|
||||
systemctl status nymvisor.service
|
||||
# for example systemctl status nymvisor.service
|
||||
```
|
||||
|
||||
- You can also do `service nymvisor stop` or `service nymvisor restart`.
|
||||
|
||||
###### 4. Anytime you make any changes to your `systemd` script after you've enabled it, you will need to run:
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
service nymvisor restart
|
||||
```
|
||||
|
||||
This lets your operating system know it's ok to reload the service configuration and restarts the node in a graceful way.
|
||||
|
||||
</Steps>
|
||||
@@ -1,24 +0,0 @@
|
||||
import { VarInfo } from 'components/variable-info.tsx'
|
||||
|
||||
# Nym Node
|
||||
|
||||
|
||||
NYM NODE is a tool for running a node within the Nym network. Nym Nodes containing functionality such as `mixnode`, `entry-gateway` and `exit-gateway` are fundamental components of Nym Mixnet architecture. Nym Nodes are ran by decentralised node operators.
|
||||
|
||||
To setup any type of Nym Node, start with either building [Nym's platform](../binaries/building-nym.mdx) from source or download [pre-compiled binaries](../binaries/pre-built-binaries.mdx) on the [configured server (VPS)](preliminary-steps/vps-setup.mdx) where you want to run the node. Your Nym Node will need to be bonded before it can be run. We recommend most users use the [Nym desktop wallet](preliminary-steps/wallet-preparation.mdx) for this.
|
||||
|
||||
**Follow [preliminary steps](preliminary-steps.mdx) page before you configure and run a `nym-node`!**
|
||||
|
||||
## Steps for Nym Node Operators
|
||||
|
||||
Once [VPS and Nym wallet are configured](preliminary-steps.mdx), binaries ready, the operators of `nym-node` need to:
|
||||
|
||||
1. **[Setup](nym-node/setup.mdx) the node**
|
||||
|
||||
2. **[Configure](nym-node/configuration.mdx) the node and optionally automation, Wireguard, WSS, reversed proxy ...**
|
||||
|
||||
3. **[Run](nym-node/setup.mdx#initialise--run) the node or [the service](nym-node/configuration.md#systemd)**
|
||||
|
||||
4. **[Bond](nym-node/bonding.mdx) the node to the Nym API, using Nym wallet**
|
||||
|
||||
Make sure to follow the steps thoroughly, in case you find any point difficult don't hesitate to ask in our [Operators channel](https://matrix.to/#/#operators:nymtech.chat).
|
||||
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"setup": "Setup & Run",
|
||||
"configuration": "Configuration",
|
||||
"bonding": "Bonding",
|
||||
"bak-setup": {
|
||||
"display": "hidden"
|
||||
},
|
||||
"snippets": {
|
||||
"display": "hidden"
|
||||
}
|
||||
}
|
||||
@@ -1,100 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components'
|
||||
|
||||
# Bonding Nym Node
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
To you unbond your Nym Node means you are leaving Nym network and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with **no delegations**.
|
||||
</Callout>
|
||||
|
||||
Nym Mixnet operators are rewarded for their work every epoch (60 minutes). To prevent centralisation, [Nym API](../validator-setup/nym-api.mdx) is ran by distributed validators on Nyx blockchain.
|
||||
|
||||
You are asked to `sign` a transaction and bond your node to Nyx blockchain 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.
|
||||
|
||||
**Before you bond your `nym-node` make sure you went through all the previous steps**
|
||||
|
||||
1. [Build](../../binaries/building-nym.mdx) or [download](../../binaries/pre-built-binaries.mdx) `nym-node` binary
|
||||
2. [Configure VPS]( ../preliminary-steps/vps-setup.mdx) correctly
|
||||
3. [Prepare Nym wallet](../preliminary-steps/wallet-preparation.mdx)
|
||||
4. [Setup & Run](setup.mdx) the node
|
||||
5. [Configure your node](configuration.mdx)
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Do not bond your node to the API if the previous steps weren't finished. Bad connectivity, closed ports, or other poor setup will result in your node getting blacklisted.
|
||||
</Callout>
|
||||
|
||||
## Bond via the Desktop wallet (recommended)
|
||||
|
||||
You can bond your `nym-node` via the Desktop wallet.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Insert bonding information
|
||||
|
||||
- Open your wallet, and head to the `Bond` page, then select the node type `Mixnode` and input your node details. Press `Next`.
|
||||
- To find out your `nym-node` details, run this command in your VPS:
|
||||
```sh
|
||||
./nym-node bonding-information --id <ID>
|
||||
```
|
||||
- To get a correct host address, run this command in your VPS
|
||||
```sh
|
||||
echo "$(curl -4 https://ifconfig.me)"
|
||||
```
|
||||
|
||||
###### 2. Bond to correct ports
|
||||
|
||||
- In your wallet: Open the box called `Show advanced options` and make sure all your ports are set correctly, like the values in this table:
|
||||
|
||||
| Node type | Port name | Correct port value |
|
||||
| :-- | :-- | :-- |
|
||||
| Mixnode | Mix port | `1789` |
|
||||
| Mixnode | Verloc port | `1790` |
|
||||
| Mixnode | HTTP api port (picture below) | `8080` |
|
||||
| Gateway (entry & exit) | Mix port | `1789` |
|
||||
| Gateway (entry & exit) | Client WS API port | `9000` |
|
||||
|
||||
- If you bonding `nym-node --mode mixnode` through *Bond mixnode* desktop wallet menu, change manually *HTTP api port* value from deprecated `8000` to `8080` - a generic `nym-node` HTTP port (for all modes).
|
||||
|
||||
|
||||
|
||||
###### 3. Enter your values and sign with your node
|
||||
|
||||
- Enter the `Amount`, `Operating cost` and `Profit margin` and press `Next`
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
|
||||
If you are part of [Nym Delegation Program](https://delegations.explorenym.net) or Service Grants Program, make sure your values are within the [rules](https://forum.nymtech.net/t/nym-delegations-program-update/466) of the programs. Operators setting up larger OP or PM than defined in the rules will be excluded from the program without prior warning!
|
||||
</Callout>
|
||||
|
||||
- You will be asked to run a `sign` command with your `nym-node` - copy and paste the long signature as the value of `--contract-msg` and sing it on your VPS:
|
||||
|
||||
```sh
|
||||
./nym-node sign --contract-msg <PAYLOAD_GENERATED_BY_THE_WALLET>
|
||||
```
|
||||
|
||||
- Copy the resulting signature string and paste it into the wallet nodal, press `Next` and confirm the transaction:
|
||||
|
||||
```sh
|
||||
# This is just an example, copy the one from your process
|
||||
>>> The base58-encoded signature is:
|
||||
2bbDJSmSo9r9qdamTNygY297nQTVRyQaxXURuomVcRd7EvG9oEC8uW8fvZZYnDeeC9iWyG9mAbX2K8rWEAxZBro1
|
||||
```
|
||||
|
||||
|
||||
|
||||
*This image is just an example, copy-paste your own base58-encoded signature*
|
||||
|
||||
</Steps>
|
||||
|
||||
Your node will now be bonded and ready to receive traffic, latest at the beginning of the next epoch (at most 1 hour).
|
||||
|
||||
|
||||
If everything worked, you'll see your node running on the either the [Sandbox testnet network explorer](https://sandbox-explorer.nymtech.net) or the [mainnet network explorer](https://explorer.nymtech.net), depending on which environment you're running.
|
||||
|
||||
|
||||
## Bond 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.
|
||||
|
||||
@@ -1,432 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx'
|
||||
|
||||
export const ManagerIPOutput = () => (
|
||||
<div>
|
||||
Correct <code>./network_tunnel_manager.sh fetch_and_display_ipv6</code> output
|
||||
</div>
|
||||
);
|
||||
|
||||
export const ManagerTablesOutput = () => (
|
||||
<div>
|
||||
Correct <code>./network_tunnel_manager.sh check_nymtun_iptables</code> output
|
||||
</div>
|
||||
);
|
||||
|
||||
export const ShowTun = () => (
|
||||
<div>
|
||||
Correct <code>ip addr show nymtun0</code> output
|
||||
</div>
|
||||
);
|
||||
|
||||
|
||||
|
||||
# Nym Node Configuration
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Basic Changes
|
||||
|
||||
Nym Node can be configured directly by editing the config file (`config.toml`) located at `~/.nym/nym-nodes/<ID>/config/config.toml` (by default `~/.nym/nym-nodes/default-nym-node/config/config.toml`) or through commands on the binary.
|
||||
|
||||
### Node Description
|
||||
|
||||
Operators can add a description themselves to share more information about their `nym-node` publicly.
|
||||
|
||||
To add or change `nym-node` description is done by editing `description.toml` file located in `~/.nym/nym-nodes/<ID>/data/description.toml`. After saving, don't forget to reload and restart your node [service](#systemd) or simply restart your `nym-node` if you run it without a service (not recommended).
|
||||
|
||||
**Query description**
|
||||
|
||||
Nodes description can be queried from API endpoint `/api/v1/description` or via Swagger API UI page `/api/v1/swagger/#/Node/description`.
|
||||
|
||||
```bash
|
||||
curl -X 'GET' \
|
||||
'http://<PUBLIC_IP>:8080/api/v1/description' \
|
||||
-H 'accept: application/json'
|
||||
|
||||
# or for https reversed proxy or WSS setup
|
||||
curl -X 'GET' \
|
||||
'https://<HOSTNAME>/api/v1/description' \
|
||||
-H 'accept: application/json'
|
||||
```
|
||||
|
||||
## Commands & Examples
|
||||
|
||||
Disable sharing of system hardware info with the network:
|
||||
|
||||
```sh
|
||||
./nym-node run --id <ID> --deny-init --mode entry-gateway -w --expose-system-hardware false --expose-system-info false
|
||||
```
|
||||
|
||||
Alternatively these values can be changed in `config.toml` of your node. After saving, don't forget to reload and restart your node [service](#systemd) or simply restart your `nym-node` if you run it without a service (not recommended).
|
||||
|
||||
> Note: `--expose-system-info false` supersedes `--expose-system-hardware false`. If both are present with conflicting values, the system hardware will not be shown.
|
||||
|
||||
## VPS Setup and Automation
|
||||
|
||||
> Replace `<NODE>` variable with type of node you run, in majority of cases this will be `nym-node` (depreciated `nym-mixnode`, `nym-gateway` or `nym-network-requester` are no longer supported).
|
||||
|
||||
Although it’s not totally necessary, it's useful to have `nym-node` automatically start at system boot time. We recommend to run your remote operation via [`tmux`](#tmux) for easier management and a handy return to your previous session. For full automation, including a failed node auto-restart and `ulimit` setup, [`systemd`](#systemd) is a recommended choice for all operators, as it allows much more automation leading to better uptime and performance.
|
||||
|
||||
> Do any of these steps and run your automated node before you start bonding process!
|
||||
|
||||
### nohup
|
||||
|
||||
`nohup` is a command with which your terminal is told to ignore the `HUP` or 'hangup' signal. This will stop the node process ending if you kill your session.
|
||||
|
||||
```sh
|
||||
nohup ./<NODE> run <ARGUMENTS> # use all the flags you use to run your node
|
||||
```
|
||||
|
||||
### 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**
|
||||
|
||||
Now you have installed tmux on your VPS, let's run a Mix Node on tmux, which allows you to detach your terminal and let your `<NODE>` run on its own on the VPS.
|
||||
|
||||
* Pause your `<NODE>`
|
||||
* Start tmux with the command
|
||||
```sh
|
||||
tmux
|
||||
```
|
||||
* tmux terminal should open in the same working directory, just the layout changed into tmux default layout.
|
||||
* Start the `<NODE>` again with a command:
|
||||
```sh
|
||||
./<NODE> run <ARGUMENTS> # use all the flags you use to run your node
|
||||
```
|
||||
* Now, without closing the tmux window, you can close the whole terminal and the `<NODE>` (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:
|
||||
```sh
|
||||
tmux attach-session
|
||||
```
|
||||
* To see keybinding options of tmux press `ctrl`+`b` and after 1 second `?`
|
||||
|
||||
### systemd
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create a service file
|
||||
|
||||
To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nym-node.service` and follow the [next steps](#2-following-steps-for-nym-node-running-as-systemd-service).
|
||||
|
||||
- Open service file in a text editor
|
||||
```sh
|
||||
nano /etc/systemd/system/nym-node.service
|
||||
```
|
||||
|
||||
- Paste this config file, substitute `<USER>` and `<PATH>` with your correct values and add all flags to run your `nym-node` to `ExecStart` line instead of `<ARGUMENTS>`:
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Nym Node
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=<USER>
|
||||
LimitNOFILE=65536
|
||||
ExecStart=<PATH>/nym-node run <ARGUMENTS> # add all the flags you use to run your node
|
||||
KillSignal=SIGINT
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
[Accepting T&Cs](setup.md#terms--conditions) is done via a flag `--accept-operator-terms-and-conditions` added explicitly to `nym-node run` command every time. If you use systemd automation, add the flag to your service file's `ExecStart` line.
|
||||
</Callout>
|
||||
|
||||
- Save config and exit
|
||||
|
||||
<Callout>
|
||||
Make sure your `ExecStart <PATH>` and `run` command `<ARGUMENTS>` are correct!
|
||||
|
||||
Example: If you have built nym in the `$HOME` directory on your server, your username is `jetpanther`, and node `<ID>` is `puma`, then the `ExecStart` line (command) in the script located in `/etc/systemd/system/nym-node.service` for might look like this:
|
||||
`ExecStart=/home/jetpanther/nym/target/release/nym-node run --id puma`.
|
||||
|
||||
Basically, you want the full path to `nym-node`. If you are unsure about your `<PATH>`, then `cd` to your directory where you run your `<NODE>` from and run `pwd` command which returns the full path for you.
|
||||
</Callout>
|
||||
|
||||
###### 2. Following steps for `nym-node` running as `systemd` service
|
||||
|
||||
Once your service file is saved follow these steps.
|
||||
|
||||
- Reload systemctl to pickup the new unit file:
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
- Enable the newly created service:
|
||||
```sh
|
||||
systemctl enable nym-node.service
|
||||
```
|
||||
|
||||
- Start your `<NODE>` as a `systemd` service:
|
||||
```sh
|
||||
service nym-node start
|
||||
```
|
||||
|
||||
This will cause your `<NODE>` to start at system boot time. If you restart your machine, your `<NODE>` will come back up automatically.
|
||||
|
||||
###### 3. Useful `systemd` commands for easier management
|
||||
|
||||
- You can monitor system logs of your node by running:
|
||||
```sh
|
||||
journalctl -u nym-node -f
|
||||
```
|
||||
|
||||
- Or check service status by running:
|
||||
```sh
|
||||
systemctl status nym-node.service
|
||||
# for example systemctl status nym-node.service
|
||||
```
|
||||
|
||||
- You can also do `service <NODE> stop` or `service <NODE> restart`.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Anytime you make any changes to your `systemd` script after you've enabled it, you will need to run:
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
service nym-node restart
|
||||
```
|
||||
|
||||
This lets your operating system know it's ok to reload the service configuration and restarts the node in a graceful way.
|
||||
</Callout>
|
||||
</Steps>
|
||||
|
||||
|
||||
## Connectivity Test and Configuration
|
||||
|
||||
During our ongoing testing events [Fast and Furious](https://nymtech.net/events/fast-and-furious) we found out, that after introducing IP Packet Router (IPR) and [Nym exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) on embedded Network Requester (NR) by default, only a fragment of Gateways routes correctly through IPv4 and IPv6. We built a useful monitor to check out your Gateway (`nym-node --mode exit-gateway`) at [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/).
|
||||
|
||||
IPv6 routing is not only a case for gateways. Imagine a rare occasion when you run a `mixnode` without IPv6 enabled and a client will sent IPv6 packets through the Mixnet through such route:
|
||||
```ascii
|
||||
[client] -> [entry-gateway] -> [mixnode layer 1] -> [your mixnode] -> [IPv6 mixnode layer3] -> [exit-gateway]
|
||||
```
|
||||
In this (unusual) case your `mixnode` will not be able to route the packets. The node will drop the packets and its performance would go down. For that reason it's beneficial to have IPv6 enabled when running a `mixnode` functionality.
|
||||
|
||||
<Callout>
|
||||
We recommend operators to configure their `nym-node` with the full routing configuration.
|
||||
|
||||
However, most of the time the packets sent through the Mixnet are IPv4 based. The IPv6 packets are still pretty rare and therefore it's not mandatory from operational point of view to have this configuration implemented if you running only `mixnode` mode.
|
||||
|
||||
If you preparing to run a `nym-node` with all modes enabled in the future, this setup is required.
|
||||
</Callout>
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
For everyone participating in Delegation Program or Service Grant program, this setup is a requirement!
|
||||
</Callout>
|
||||
|
||||
### Quick IPv6 Check
|
||||
|
||||
You can always check IPv6 address and connectivity by using some of these methods:
|
||||
<br />
|
||||
<AccordionTemplate name="Testing IPv6 methods">
|
||||
```sh
|
||||
# locally listed IPv6 addresses
|
||||
ip -6 addr
|
||||
|
||||
# globally reachable IPv6 addresses
|
||||
ip -6 addr show scope global
|
||||
|
||||
# with DNS
|
||||
dig -6 TXT +short o-o.myaddr.l.google.com @ns1.google.com
|
||||
dig -t aaaa +short myip.opendns.com @resolver1.opendns.com
|
||||
|
||||
# https check
|
||||
curl -6 https://ifconfig.co
|
||||
curl -6 https://ipv6.icanhazip.com
|
||||
|
||||
# using telnet
|
||||
telnet -6 ipv6.telnetmyip.com
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Make sure to keep your IPv4 address enabled while setting up IPv6, as the majority of routing goes through that one!
|
||||
</Callout>
|
||||
|
||||
### Routing Configuration
|
||||
|
||||
While we're working on Rust implementation to have these settings as a part of the binary build, to solve these connectivity requirements in the meantime we wrote a script [`network_tunnel_manager.sh`](https://gist.github.com/tommyv1987/ccf6ca00ffb3d7e13192edda61bb2a77) to support operators to configure their servers and address all the connectivity requirements.
|
||||
|
||||
Networking configuration across different ISPs and various operation systems does not have a generic solution. If the provided configuration setup doesn't solve your problem check out [IPv6 troubleshooting](../../troubleshooting/vps-isp.mdx#ipv6-troubleshooting) page. Be aware that you may have to do more research, customised adjustments or contact your ISP to change settings for your VPS.
|
||||
|
||||
The `nymtun0` interface is dynamically managed by the `exit-gateway` service. When the service is stopped, `nymtun0` disappears, and when started, `nymtun0` is recreated.
|
||||
|
||||
The `nymwg` interface is used for creating a secure wireguard tunnel as part of the Nym Network configuration. Similar to `nymtun0`, the script manages iptables rules specific to `nymwg` to ensure proper routing and forwarding through the wireguard tunnel. The `nymwg` interface needs to be correctly configured and active for the related commands to function properly. This includes applying or removing iptables rules and running connectivity tests through the `nymwg` tunnel.
|
||||
|
||||
The script should be used in a context where `nym-node` is running to fully utilise its capabilities, particularly for fetching IPv6 addresses or applying network rules that depend on the `nymtun0` and `nymwg` interfaces and to establish a WireGuard tunnel.
|
||||
|
||||
**Before starting with the following configuration, make sure you have the [latest `nym-node` binary](https://github.com/nymtech/nym/releases) installed and your [VPS setup](../preliminary-steps/vps-setup.mdx) finished properly!**
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Download `network_tunnel_manager.sh`, make executable and run:
|
||||
|
||||
```sh
|
||||
curl -L https://gist.githubusercontent.com/tommyv1987/ccf6ca00ffb3d7e13192edda61bb2a77/raw/74241cc06492b955e582052939090f57a285a65e/network_tunnel_manager.sh -o network_tunnel_manager.sh && \
|
||||
chmod +x network_tunnel_manager.sh && \
|
||||
./network_tunnel_manager.sh
|
||||
```
|
||||
|
||||
###### 2. Make sure your `nym-node` service is up and running and bond
|
||||
|
||||
- **If you setting up a new node and not upgrading an existing one, keep it running and [bond](bonding.mdx) your node now**. Then come back here and follow the rest of the configuration.
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
**Run the following steps as root or with `sudo` prefix!**
|
||||
</Callout>
|
||||
|
||||
|
||||
###### 3. Setup IP tables rules
|
||||
|
||||
- Apply the rules for IPv4 and IPv6:
|
||||
```sh
|
||||
./network_tunnel_manager.sh apply_iptables_rules
|
||||
```
|
||||
|
||||
- The process may prompt you if you want to save current IPv4 and IPv6 rules, choose yes.
|
||||
|
||||
|
||||
|
||||
- At this point you should see a `global ipv6` address.
|
||||
```sh
|
||||
./network_tunnel_manager.sh fetch_and_display_ipv6
|
||||
```
|
||||
<br />
|
||||
<AccordionTemplate name={<ManagerTablesOutput/>}>
|
||||
```sh
|
||||
iptables-persistent is already installed.
|
||||
Using IPv6 address: 2001:db8:a160::1/112 #the address will be different for you
|
||||
operation fetch_ipv6_address_nym_tun completed successfully.
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
###### 4. Check Nymtun IP tables:
|
||||
|
||||
```sh
|
||||
./network_tunnel_manager.sh check_nymtun_iptables
|
||||
```
|
||||
|
||||
- If there's no process running it wouldn't return anything.
|
||||
- In case you see `nymtun0` but not active, this is probably because you are setting up a new (never bonded) node and not upgrading an existing one.
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name={<ManagerIPOutput/>}>
|
||||
```sh
|
||||
iptables-persistent is already installed.
|
||||
network Device: eth0
|
||||
---------------------------------------
|
||||
|
||||
inspecting IPv4 firewall rules...
|
||||
Chain FORWARD (policy DROP 0 packets, 0 bytes)
|
||||
0 0 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
|
||||
0 0 ACCEPT all -- nymtun0 eth0 0.0.0.0/0 0.0.0.0/0
|
||||
0 0 ACCEPT all -- eth0 nymtun0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
|
||||
0 0 ACCEPT all -- nymtun0 eth0 0.0.0.0/0 0.0.0.0/0
|
||||
0 0 ACCEPT all -- eth0 nymtun0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
|
||||
0 0 ACCEPT all -- nymtun0 eth0 0.0.0.0/0 0.0.0.0/0
|
||||
0 0 ACCEPT all -- eth0 nymtun0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
|
||||
---------------------------------------
|
||||
|
||||
inspecting IPv6 firewall rules...
|
||||
Chain FORWARD (policy DROP 0 packets, 0 bytes)
|
||||
0 0 ufw6-reject-forward all * * ::/0 ::/0
|
||||
0 0 ACCEPT all eth0 nymtun0 ::/0 ::/0 state RELATED,ESTABLISHED
|
||||
0 0 ACCEPT all nymtun0 eth0 ::/0 ::/0
|
||||
0 0 ACCEPT all eth0 nymtun0 ::/0 ::/0 state RELATED,ESTABLISHED
|
||||
0 0 ACCEPT all nymtun0 eth0 ::/0 ::/0
|
||||
0 0 ACCEPT all eth0 nymtun0 ::/0 ::/0 state RELATED,ESTABLISHED
|
||||
0 0 ACCEPT all nymtun0 eth0 ::/0 ::/0
|
||||
operation check_nymtun_iptables completed successfully.
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
###### 5. Apply rules for wireguad routing
|
||||
|
||||
```sh
|
||||
./network_tunnel_manager.sh apply_iptables_rules_wg
|
||||
```
|
||||
|
||||
###### 6. Apply rules to configure DNS routing and allow ICMP piung test for node probing (network testing)
|
||||
|
||||
```sh
|
||||
./network_tunnel_manager.sh configure_dns_and_icmp_wg
|
||||
```
|
||||
|
||||
###### 7. Check `nymtun0` interface and test routing configuration
|
||||
|
||||
```sh
|
||||
ip addr show nymtun0
|
||||
```
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name={<ShowTun/>}>
|
||||
```sh
|
||||
# your addresses will be different
|
||||
8: nymtun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1420 qdisc fq_codel state UNKNOWN group default qlen 500
|
||||
link/none
|
||||
inet 10.0.0.1/16 scope global nymtun0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 2001:db8:a160::1/112 scope global
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::ad08:d167:5700:8c7c/64 scope link stable-privacy
|
||||
valid_lft forever preferred_lft forever`
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
- Validate your IPv6 and IPv4 networking by running a joke test via Mixnet:
|
||||
```sh
|
||||
./network_tunnel_manager.sh joke_through_the_mixnet
|
||||
```
|
||||
|
||||
- Validate your tunneling by running a joke test via WG:
|
||||
```sh
|
||||
./network_tunnel_manager.sh joke_through_wg_tunnel
|
||||
```
|
||||
|
||||
- **Note:** WireGuard will return only IPv4 joke, not IPv6. WG IPv6 is under development. Running IPR joke through the mixnet with `./network_tunnel_manager.sh joke_through_the_mixnet` should work with both IPv4 and IPv6!
|
||||
|
||||
|
||||
###### 8. Enable wireguard
|
||||
|
||||
Now you can run your node with the `--wireguard-enabled true` flag or add it to your [systemd service config](#systemd). Restart your `nym-node` or [systemd](#2-following-steps-for-nym-nodes-running-as-systemd-service) service (recommended):
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload && service nym-node restart
|
||||
```
|
||||
- Optionally, you can check if the node is running correctly by monitoring the service logs:
|
||||
|
||||
```sh
|
||||
journalctl -u nym-node.service -f -n 100
|
||||
```
|
||||
</Steps>
|
||||
|
||||
|
||||
Make sure that you get the validation of all connectivity. If there are still any problems, please refer to [troubleshooting section](../../troubleshooting/vps-isp.mdx#incorrect-gateway-network-check).
|
||||
|
||||
|
||||
## Next Steps
|
||||
|
||||
There are a few more good suggestions for `nym-node` configuration, like Web Secure Socket or Reversed Proxy setup. These are optional and you can skip them if you want. Visit [Proxy configuration](configuration/proxy-configuration.mdx) page to see the guides.
|
||||
@@ -1,3 +0,0 @@
|
||||
{
|
||||
"proxy-configuration": "WSS & Reverese Proxy"
|
||||
}
|
||||
-579
@@ -1,579 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
export const IndexPage = () => (
|
||||
<>
|
||||
An example template for <code>index.html</code> page
|
||||
</>
|
||||
);
|
||||
|
||||
# Reverse Proxy & Web Secure Socket
|
||||
|
||||
This section will guide you in setting up a reverse proxy for serving `nym-node` HTTP requests and to set up a custom [landing page](../../../community-counsel/landing-pages.mdx) for your node.
|
||||
|
||||
In later sections, you will be setting up secure websocket (wss) to add additional security and encrypt connections coming to your node. Follow [this guide](#web-secure-socket-setup) for installation.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Since SSL certificates can only be issued for a domain name and not an IP address, it is essential for you to register a new domain name and configure a domain record pointing to your node's IP address
|
||||
</Callout>
|
||||
|
||||
<VarInfo />
|
||||
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The commands in this setup need to be run with root permission. Either add a prefix `sudo` or execute them from a root shell.
|
||||
</Callout>
|
||||
|
||||
## Reverse Proxy Setup
|
||||
|
||||
The following snippet needs be modified as described below according to the public identity that you may want to show on this public notice, i.e. your graphics and your email.
|
||||
It would allow you to serve it as a landing page resembling the one proposed by [Tor](https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html) but with all the changes needed to adhere to the Nym's operators case.
|
||||
|
||||
|
||||
|
||||
### HTML File Customization
|
||||
|
||||
File for html configuration are by convention located at `/var/www/<HOSTNAME>` directory and it's subdirectories. We refer to this directory as `<LANDING_PAGE_ASSETS_PATH>`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Start by creating your directory landing page directory:
|
||||
```sh
|
||||
mkdir -p /var/www/<HOSTNAME>
|
||||
```
|
||||
|
||||
###### 2. Create html landing page
|
||||
|
||||
- Use your own html code (check this [markdown to html tool](https://markdowntohtml.com/)) or copy the template below to a new file called `index.html` located in `/var/www/<HOSTNAME>` directory.
|
||||
|
||||
|
||||
<AccordionTemplate name={<IndexPage/>}>
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html lang="en-US">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>This is a NYM Exit Gateway</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<link rel="icon" type="image/png" href="">
|
||||
<style>
|
||||
:root {
|
||||
font-family: Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace;
|
||||
}
|
||||
:root{
|
||||
--background-color: #121726;
|
||||
--text-color: #f2f2f2;
|
||||
--link-color: #fb6e4e;
|
||||
}
|
||||
html{
|
||||
background: var(--background-color);
|
||||
}
|
||||
body{
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
padding-left: 5vw;
|
||||
padding-right: 5vw;
|
||||
max-width: 1000px;
|
||||
}
|
||||
h1{
|
||||
font-size: 55px;
|
||||
text-align: center;
|
||||
color: var(--title-color)
|
||||
}
|
||||
p{
|
||||
color: var(--text-color);
|
||||
}
|
||||
p, a{
|
||||
font-size: 20px;
|
||||
}
|
||||
a{
|
||||
color: var(--link-color);
|
||||
text-decoration: none;
|
||||
}
|
||||
a:hover{
|
||||
filter: brightness(.8);
|
||||
text-decoration: underline;
|
||||
}
|
||||
.links{
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
justify-content: space-evenly;
|
||||
}
|
||||
.links > a{
|
||||
margin: 10px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
</style>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<main>
|
||||
<h1>This is a NYM Exit Gateway</h1>
|
||||
<p style="text-align:center">
|
||||
<img class="logo" src="<FIXME>">
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You are most likely accessing this website because you've had some issue with
|
||||
the traffic coming from this IP. This router is part of the <a
|
||||
href="https://nymtech.net/">NYM project</a>, which is
|
||||
dedicated to <a href="https://nymtech.net/about/mission">create</a> outstanding
|
||||
privacy software that is legally compliant without sacrificing integrity or
|
||||
having any backdoors.
|
||||
This router IP should be generating no other traffic, unless it has been
|
||||
compromised.</p>
|
||||
|
||||
<p>
|
||||
The Nym mixnet is operated by a decentralised community of node operators
|
||||
and stakers. The Nym mixnet is trustless, meaning that no parts of the system
|
||||
nor its operators have access to information that might compromise the privacy
|
||||
of users. Nym software enacts a strict principle of data minimisation and has
|
||||
no back doors. The Nym mixnet works by encrypting packets in several layers
|
||||
and relaying those through a multi-layered network called a mixnet, eventually
|
||||
letting the traffic exit the Nym mixnet through an exit gateway like this one.
|
||||
This design makes it very hard for a service to know which user is connecting to it,
|
||||
since it can only see the IP-address of the Nym exit gateway:</p>
|
||||
|
||||
<p style="text-align:center;margin:40px 0">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="500" viewBox="0 0 490.28 293.73" style="width:100%;max-width:600px">
|
||||
<desc>Illustration showing how a user might connect to a service through the Nym network. The user first sends their data through three daisy-chained encrypted Nym nodes that exist on three different continents. Then the last Nym node in the chain connects to the target service over the normal internet.</desc>
|
||||
<defs>
|
||||
<style>
|
||||
.t{
|
||||
fill: var(--text-color);
|
||||
stroke: var(--text-color);
|
||||
}
|
||||
</style>
|
||||
</defs>
|
||||
<path fill="#6fc8b7" d="M257.89 69.4c-6.61-6.36-10.62-7.73-18.36-8.62-7.97-1.83-20.06-7.99-24.17-.67-3.29 5.85-18.2 12.3-16.87 2.08.92-7.03 11.06-13.28 17-17.37 8.69-5.99 24.97-2.87 26.1-10.28 1.04-6.86-8.33-13.22-8.55-2.3-.38 12.84-19.62 2.24-8.73-6.2 8.92-6.9 16.05-9.02 25.61-6.15 12.37 4.83 25.58-2.05 33.73-.71 12.37-2.01 24.69-5.25 37.39-3.96 13 .43 24.08-.14 37.06.63 9.8 1.58 16.5 2.87 26.37 3.6 6.6.48 17.68-.82 24.3 1.9 8.3 4.24.44 10.94-6.89 11.8-8.79 1.05-23.59-1.19-26.6 1.86-5.8 7.41 10.75 5.68 11.27 14.54.57 9.45-5.42 9.38-8.72 16-2.7 4.2.3 13.93-1.18 18.45-1.85 5.64-19.64 4.47-14.7 14.4 4.16 8.34 1.17 19.14-10.33 12.02-5.88-3.65-9.85-22.04-15.66-21.9-11.06.27-11.37 13.18-12.7 17.52-1.3 4.27-3.79 2.33-6-.63-3.54-4.76-7.75-14.22-12.01-17.32-6.12-4.46-10.75-1.17-15.55 2.83-5.63 4.69-8.78 7.82-7.46 16.5.78 9.1-12.9 15.84-14.98 24.09-2.61 10.32-2.57 22.12-8.81 31.47-4 5.98-14.03 20.12-21.27 14.97-7.5-5.34-7.22-14.6-9.56-23.08-2.5-9.02.6-17.35-2.57-26.2-2.45-6.82-6.23-14.54-13.01-13.24-6.5.92-15.08 1.38-19.23-2.97-5.65-5.93-6-10.1-6.61-18.56 1.65-6.94 5.79-12.64 10.38-18.63 3.4-4.42 17.45-10.39 25.26-7.83 10.35 3.38 17.43 10.5 28.95 8.57 3.12-.53 9.14-4.65 7.1-6.62zm-145.6 37.27c-4.96-1.27-11.57 1.13-11.8 6.94-1.48 5.59-4.82 10.62-5.8 16.32.56 6.42 4.34 12.02 8.18 16.97 3.72 3.85 8.58 7.37 9.3 13.1 1.24 5.88 1.6 11.92 2.28 17.87.34 9.37.95 19.67 7.29 27.16 4.26 3.83 8.4-2.15 6.52-6.3-.54-4.54-.6-9.11 1.01-13.27 4.2-6.7 7.32-10.57 12.44-16.64 5.6-7.16 12.74-11.75 14-20.9.56-4.26 5.72-13.86 1.7-16.72-3.14-2.3-15.83-4-18.86-6.49-2.36-1.71-3.86-9.2-9.86-12.07-4.91-3.1-10.28-6.73-16.4-5.97zm11.16-49.42c6.13-2.93 10.58-4.77 14.61-10.25 3.5-4.28 2.46-12.62-2.59-15.45-7.27-3.22-13.08 5.78-18.81 8.71-5.96 4.2-12.07-5.48-6.44-10.6 5.53-4.13.38-9.2-5.66-8.48-6.12.8-12.48-1.45-18.6-1.73-5.3-.7-10.13-1-15.45-1.37-5.37-.05-16.51-2.23-25.13.87-5.42 1.79-12.5 5.3-16.73 9.06-4.85 4.2.2 7.56 5.54 7.45 5.3-.22 16.8-5.36 20.16.98 3.68 8.13-5.82 18.29-5.2 26.69.1 6.2 3.37 11 4.74 16.98 1.62 5.94 6.17 10.45 10 15.14 4.7 5.06 13.06 6.3 19.53 8.23 7.46.14 3.34-9.23 3.01-14.11 1.77-7.15 8.49-7.82 12.68-13.5 7.14-7.72 16.41-13.4 24.34-18.62zM190.88 3.1c-4.69 0-13.33.04-18.17-.34-7.65.12-13.1-.62-19.48-1.09-3.67.39-9.09 3.34-5.28 7.04 3.8.94 7.32 4.92 7.1 9.31 1.32 4.68 1.2 11.96 6.53 13.88 4.76-.2 7.12-7.6 11.93-8.25 6.85-2.05 12.5-4.58 17.87-9.09 2.48-2.76 7.94-6.38 5.26-10.33-1.55-1.31-2.18-.64-5.76-1.13zm178.81 157.37c-2.66 10.08-5.88 24.97 9.4 15.43 7.97-5.72 12.58-2.02 17.47 1.15.5.43 2.65 9.2 7.19 8.53 5.43-2.1 11.55-5.1 14.96-11.2 2.6-4.62 3.6-12.39 2.76-13.22-3.18-3.43-6.24-11.03-7.7-15.1-.76-2.14-2.24-2.6-2.74-.4-2.82 12.85-6.04 1.22-10.12-.05-8.2-1.67-29.62 7.17-31.22 14.86z"/>
|
||||
<g fill="none">
|
||||
<path stroke="#cf63a6" stroke-linecap="round" stroke-width="2.76" d="M135.2 140.58c61.4-3.82 115.95-118.83 151.45-103.33"/>
|
||||
<path stroke="#cf63a6" stroke-linecap="round" stroke-width="2.76" d="M74.43 46.66c38.15 8.21 64.05 42.26 60.78 93.92M286.65 37.25c-9.6 39.44-3.57 57.12-35.64 91.98"/>
|
||||
<path stroke="#e4c101" stroke-dasharray="9.06,2.265" stroke-width="2.27" d="M397.92 162.52c-31.38 1.26-90.89-53.54-148.3-36.17"/>
|
||||
<path stroke="#cf63a6" stroke-linecap="round" stroke-width="2.77" d="M17.6 245.88c14.35 0 14.4.05 28-.03"/>
|
||||
<path stroke="#e3bf01" stroke-dasharray="9.06,2.265" stroke-width="2.27" d="M46.26 274.14c-17.52-.12-16.68.08-30.34.07"/>
|
||||
</g>
|
||||
<g transform="translate(120.8 -35.81)">
|
||||
<circle cx="509.78" cy="68.74" r="18.12" fill="#240a3b" transform="translate(-93.3 38.03) scale(.50637)"/>
|
||||
<circle cx="440.95" cy="251.87" r="18.12" fill="#240a3b" transform="translate(-93.3 38.03) scale(.50637)"/>
|
||||
<circle cx="212.62" cy="272.19" r="18.12" fill="#240a3b" transform="translate(-93.3 38.03) scale(.50637)"/>
|
||||
<circle cx="92.12" cy="87.56" r="18.12" fill="#240a3b" transform="translate(-93.3 38.03) scale(.50637)"/>
|
||||
<circle cx="730.88" cy="315.83" r="18.12" fill="#67727b" transform="translate(-93.3 38.03) scale(.50637)"/>
|
||||
<circle cx="-102.85" cy="282.18" r="9.18" fill="#240a3b"/>
|
||||
<circle cx="-102.85" cy="309.94" r="9.18" fill="#67727b"/>
|
||||
</g>
|
||||
<g class="t">
|
||||
<text xml:space="preserve" x="-24.76" y="10.37" stroke-width=".26" font-size="16.93" font-weight="700" style="line-height:1.25" transform="translate(27.79 2.5)" word-spacing="0"><tspan x="-24.76" y="10.37">The user</tspan></text>
|
||||
<text xml:space="preserve" x="150.63" y="196.62" stroke-width=".26" font-size="16.93" font-weight="700" style="line-height:1.25" transform="translate(27.79 2.5)" word-spacing="0"><tspan x="150.63" y="196.62">This server</tspan></text>
|
||||
<text xml:space="preserve" x="346.39" y="202.63" stroke-width=".26" font-size="16.93" font-weight="700" style="line-height:1.25" transform="translate(27.79 2.5)" word-spacing="0"><tspan x="346.39" y="202.63">Your service</tspan></text>
|
||||
<text xml:space="preserve" x="34.52" y="249.07" stroke-width=".26" font-size="16.93" font-weight="700" style="line-height:1.25" transform="translate(27.79 2.5)" word-spacing="0"><tspan x="34.52" y="249.07">Nym network link</tspan></text>
|
||||
<text xml:space="preserve" x="34.13" y="276.05" stroke-width=".26" font-size="16.93" font-weight="700" style="line-height:1.25" transform="translate(27.79 2.5)" word-spacing="0"><tspan x="34.13" y="276.05">Unencrypted link</tspan></text>
|
||||
<path fill="none" stroke-linecap="round" stroke-width="1.67" d="M222.6 184.1c-2.6-15.27 8.95-23.6 18.43-38.86m186.75 45.61c-.68-10.17-9.4-17.68-18.08-23.49"/>
|
||||
<path fill="none" stroke-linecap="round" stroke-width="1.67" d="M240.99 153.41c.35-3.41 1.19-6.17.04-8.17m-7.15 5.48c1.83-2.8 4.58-4.45 7.15-5.48"/>
|
||||
<path fill="none" stroke-linecap="round" stroke-width="1.67" d="M412.43 173.21c-2.2-3.15-2.54-3.85-2.73-5.85m0 0c2.46-.65 3.85.01 6.67 1.24M61.62 40.8C48.89 36.98 36.45 27.54 36.9 18.96M61.62 40.8c.05-2.58-3.58-4.8-5.25-5.26m-2.65 6.04c1.8.54 6.8 1.31 7.9-.78"/>
|
||||
<path fill="none" stroke-linecap="round" stroke-linejoin="round" stroke-width="2.44" d="M1.22 229.4h247.74v63.1H1.22z"/>
|
||||
</g>
|
||||
</svg>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="https://nymtech.net/about/mixnet">Read more about how Nym works.</a></p>
|
||||
|
||||
<p>
|
||||
Nym relies on a growing ecosystem of users, developers and researcher partners
|
||||
aligned with the mission to make sure Nym software is running, remains usable
|
||||
and solves real problems. While Nym is not designed for malicious computer
|
||||
users, it is true that they can use the network for malicious ends. This
|
||||
is largely because criminals and hackers have significantly better access to
|
||||
privacy and anonymity than do the regular users whom they prey upon. Criminals
|
||||
can and do build, sell, and trade far larger and more powerful networks than
|
||||
Nym on a daily basis. Thus, in the mind of this operator, the social need for
|
||||
easily accessible censorship-resistant private, anonymous communication trumps
|
||||
the risk of unskilled bad actors, who are almost always more easily uncovered
|
||||
by traditional police work than by extensive monitoring and surveillance anyway.</p>
|
||||
|
||||
<p>
|
||||
In terms of applicable law, the best way to understand Nym is to consider it a
|
||||
network of routers operating as common carriers, much like the Internet
|
||||
backbone. However, unlike the Internet backbone routers, Nym mixnodes do not
|
||||
contain identifiable routing information about the source of a packet and do
|
||||
mix the user internet traffic with that of other users, making communications
|
||||
private and protecting not just the user content but the metadata
|
||||
(user's IP address, who the user talks to, when, where, from what device and
|
||||
more) and no single Nym node can determine both the origin and destination
|
||||
of a given transmission.</p>
|
||||
|
||||
<p>
|
||||
As such, there is little the operator of this Exit Gateway can do to help you
|
||||
track the connection further. This Exit Gateway maintains no logs of any of the
|
||||
Nym mixnet traffic, so there is little that can be done to trace either legitimate or
|
||||
illegitimate traffic (or to filter one from the other). Attempts to
|
||||
seize this router will accomplish nothing.</p>
|
||||
|
||||
<!-- FIXME: US-Only section. Remove if you are a non-US operator -->
|
||||
<!--
|
||||
<p>
|
||||
Furthermore, this machine also serves as a carrier of email, which means that
|
||||
its contents are further protected under the ECPA. <a
|
||||
href="https://www.law.cornell.edu/uscode/text/18/2707">18
|
||||
USC 2707</a> explicitly allows for civil remedies ($1000/account
|
||||
<i>plus</i> legal fees)
|
||||
in the event of a seizure executed without good faith or probable cause (it
|
||||
should be clear at this point that traffic with an originating IP address of
|
||||
FIXME_DNS_NAME should not constitute probable cause to seize the
|
||||
machine). Similar considerations exist for 1st amendment content on this
|
||||
machine.</p>
|
||||
-->
|
||||
<!-- FIXME: May or may not be US-only. Some non-US tor nodes have in
|
||||
fact reported DMCA harassment... -->
|
||||
<!--
|
||||
<p>
|
||||
If you are a representative of a company who feels that this router is being
|
||||
used to violate the DMCA, please be aware that this machine does not host or
|
||||
contain any illegal content. Also be aware that network infrastructure
|
||||
maintainers are not liable for the type of content that passes over their
|
||||
equipment, in accordance with <a
|
||||
href="https://www.law.cornell.edu/uscode/text/17/512">DMCA
|
||||
"safe harbor" provisions</a>. In other words, you will have just as much luck
|
||||
sending a takedown notice to the Internet backbone providers.
|
||||
</p>
|
||||
-->
|
||||
|
||||
<p>To decentralise and enable privacy for a broad range of services, this
|
||||
Exit Gateway adopts an <a href="https://nymtech.net/.wellknown/network-requester/exit-policy.txt">Exit Policy</a>
|
||||
in accordance with the <a href="https://tornull.org/">Tor Null ‘deny’ list</a>
|
||||
and the <a href="https://tornull.org/tor-reduced-reduced-exit-policy.php">Tor reduced policy</a>,
|
||||
which are two established safeguards.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
That being said, if you still have a complaint about the router, you may email the
|
||||
<a href="mailto:>YOUR_EMAIL_ADDRESS>">maintainer</a>. If complaints are related
|
||||
to a particular service that is being abused, the maintainer will submit that to the
|
||||
NYM Operators Community in order to add it to the Exit Policy cited above.
|
||||
If approved, that would prevent this router from allowing that traffic to exit through it.
|
||||
That can be done only on an IP+destination port basis, however. Common P2P ports are already blocked.</p>
|
||||
|
||||
<p>
|
||||
You also have the option of blocking this IP address and others on the Nym network if you so desire.
|
||||
The Nym project provides a <a href="https://explorer.nymtech.net/network-components/gateways">
|
||||
web service</a> to fetch a list of all IP addresses of Nym Gateway Exit nodes that allow exiting to a
|
||||
specified IP:port combination. Please be considerate when using these options.</p>
|
||||
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
###### 3. If you used the template above - before you save and close the file, make sure to edit the text, especially the information in these points:
|
||||
|
||||
- Add your own favicon logo on the line:
|
||||
```html
|
||||
<link rel="icon" type="image/png" href="">
|
||||
```
|
||||
|
||||
- Add your header logo on the line:
|
||||
```html
|
||||
<img class="logo" src="<FIXME>">
|
||||
```
|
||||
|
||||
- By either setting the URl to the image (if you're hosting it publicly, i.e. on your web server)
|
||||
```html
|
||||
href="<PATH_TO_YOUR_PUBLIC_URL>"
|
||||
|
||||
# and
|
||||
|
||||
src="<PATH_TO_YOUR_PUBLIC_URL>"
|
||||
```
|
||||
|
||||
- **or** by adding the image inline as base64 encoded image
|
||||
```html
|
||||
href="href="data:image/x-icon;base64,AAABAAMA....""
|
||||
|
||||
# and
|
||||
|
||||
src="href="data:image/x-icon;base64,AAABAAMA....""
|
||||
```
|
||||
|
||||
- Add the email address you're willing to use for being contacted.
|
||||
```
|
||||
<a href="mailto:><YOUR_EMAIL_ADDRESS>">maintainer</a>
|
||||
```
|
||||
|
||||
- If you're running the node within the US check the sections marked as `FIXME`, add your DNS name and un-comment those.
|
||||
|
||||
###### 4. Save and exit
|
||||
|
||||
</Steps>
|
||||
|
||||
Now your html page is configured.
|
||||
|
||||
### `nym-node` Configuration
|
||||
|
||||
When done with the customization, you'll need to make sure your `nym-node` uploads the file and reference to it. This is done by opening your node configuration file located at `~/.nym/nym-nodes/<ID>/config/config.toml` and changing the value of the line `landing_page_assets_path` on the `[http]` section:
|
||||
```toml
|
||||
landing_page_assets_path = '<LANDING_PAGE_ASSETS_PATH>'
|
||||
```
|
||||
|
||||
### Reverse Proxy Configuration
|
||||
|
||||
You may set up a [reverse proxy](https://www.nginx.com/resources/glossary/reverse-proxy-server) in order to serve this landing page with proper SSL and DNS management, i.e. to resolve it to `https://<HOSTNAME>`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Configure Nginx and firewall
|
||||
|
||||
- Install `nginx`:
|
||||
```sh
|
||||
sudo apt install nginx
|
||||
```
|
||||
|
||||
- Setup firewall with `ufw`. `ufw` has three profile pre-configured for `nginx`, we will need the first one for `nym-node`:
|
||||
|
||||
- `Nginx Full`: This profile opens both port 80 (normal, unencrypted web traffic) and port 443 (TLS/SSL encrypted traffic)
|
||||
- `Nginx HTTP`: This profile opens only port 80 (normal, unencrypted web traffic)
|
||||
- `Nginx HTTPS`: This profile opens only port 443 (TLS/SSL encrypted traffic)
|
||||
|
||||
```sh
|
||||
ufw allow 'Nginx Full'
|
||||
|
||||
# you can verify by
|
||||
ufw status
|
||||
|
||||
# possibly reload ufw by
|
||||
ufw reload
|
||||
```
|
||||
|
||||
- Disable the default Nginx landing page
|
||||
|
||||
```
|
||||
systemctl status nginx
|
||||
unlink /etc/nginx/sites-enabled/default
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
###### 2. Add your endpoint configuration to Nginx by creating a config file
|
||||
|
||||
- Open file in a text editor
|
||||
```sh
|
||||
nano /etc/nginx/sites-available/<HOSTNAME>
|
||||
```
|
||||
- Paste the text below to the editor and change `<HOSTNAME>` occurrences to your domain name:
|
||||
|
||||
```ini
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
# Replace <HOSTNAME> with your domain name
|
||||
server_name <HOSTNAME>;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8080;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
}
|
||||
}
|
||||
```
|
||||
- Note: This guide assumes that the HTTP port used by you is `8080` (recommended default) . Adjust the configuration accordingly if you have defined
|
||||
a custom port for your `nym-node` HTTP connections
|
||||
|
||||
###### 3. Activate and test Nginx configuration
|
||||
|
||||
- Create a symlink to `/etc/nginx/sites-enabled`:
|
||||
|
||||
```sh
|
||||
ln -s /etc/nginx/sites-available/<HOSTNAME> /etc/nginx/sites-enabled
|
||||
```
|
||||
|
||||
- Test your configuration syntax:
|
||||
|
||||
```sh
|
||||
nginx -t
|
||||
```
|
||||
|
||||
Nginx must report that the config is "ok" and the test was successful.
|
||||
|
||||
- Restart `nginx`:
|
||||
|
||||
```sh
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
###### 4. Get an `SSL` certificate using certbot and restart `nym-node`
|
||||
|
||||
```sh
|
||||
apt install certbot python3-certbot-nginx
|
||||
certbot --nginx --non-interactive --agree-tos --redirect -m <YOUR_EMAIL_ADDRESS> -d <HOSTNAME>
|
||||
```
|
||||
|
||||
- Restart your `nym-node` or if you're running your `nym-node` as a [`systemd` service](../configuration.mdx#systemd), restart your service:
|
||||
```sh
|
||||
systemctl daemon-reload && service nym-node restart
|
||||
```
|
||||
|
||||
###### 5. Verify that your page is working
|
||||
|
||||
- Check for the page being served reading the service logs
|
||||
```sh
|
||||
journalctl -u nym-node.service | grep 8080
|
||||
```
|
||||
```sh
|
||||
# where you should see
|
||||
... Started NymNodeHTTPServer on 0.0.0.0:8080
|
||||
```
|
||||
|
||||
Now your `nginx` should be configured, up and running. Test it by inserting your `<HOSTNAME>` as a URL in a browser.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Web Secure Socket Setup
|
||||
|
||||
This section assumes that you have already configured a reverse proxy and have set it up to work over https. If not, head over to [the reverse proxy section](#reverse-proxy-configuration) to configure it.
|
||||
|
||||
We strongly recommend node operators to configure secure web sockets on their nodes. This will provide clients a more secure way to connect to your node.
|
||||
|
||||
You can read more about *Secure Socket Layer* (SSL) in [here](https://www.geeksforgeeks.org/secure-socket-layer-ssl/).
|
||||
|
||||
Remember that there may be some unique variables and customization depending on the way your reverse proxy is setup which you may have to adjust when configuring WSS to ensure correct functionality.
|
||||
|
||||
<Callout>
|
||||
To see description of used variables (noted in `<>` brackets), visit [Variables & Paramteres](https://nymtech.net/docs/operators/variables.html) page.
|
||||
</Callout>
|
||||
|
||||
#### Firewall configuration
|
||||
|
||||
Make sure to open all [needed ports](../../preliminary-steps/vps-setup.mdx#configure-your-firewall), adding your `<ANNOUNCE_WSS_PORT>`:
|
||||
|
||||
```sh
|
||||
ufw allow <WSS_PORT>/tcp
|
||||
|
||||
# for example
|
||||
# ufw allow 9001/tcp
|
||||
```
|
||||
|
||||
#### WSS configuration
|
||||
|
||||
This section assumes that you have already configured a reverse proxy and have set it up to work over https. If not, head over to [the reverse proxy section](#reverse-proxy) to configure it.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create a new Nginx configuration file called `/etc/nginx/sites-available/wss-config-nym`
|
||||
|
||||
- Open text editor
|
||||
```sh
|
||||
nano /etc/nginx/sites-available/wss-config-nym
|
||||
```
|
||||
- Paste the block below. Don't forget to insert your correct values.
|
||||
|
||||
```ini
|
||||
#############################################################
|
||||
# EXCHANGE ALL <HOSTNAME> & <ANNOUNCE_WSS_PORT> VARIABLES ! #
|
||||
#############################################################
|
||||
|
||||
server {
|
||||
listen <ANNOUNCE_WSS_PORT> ssl http2;
|
||||
listen [::]:<ANNOUNCE_WSS_PORT> ssl http2;
|
||||
|
||||
server_name <HOSTNAME>;
|
||||
|
||||
ssl_certificate /etc/letsencrypt/live/<HOSTNAME>/fullchain.pem;
|
||||
ssl_certificate_key /etc/letsencrypt/live/<HOSTNAME>/privkey.pem;
|
||||
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
|
||||
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
|
||||
|
||||
access_log /var/log/nginx/access.log;
|
||||
error_log /var/log/nginx/error.log;
|
||||
|
||||
# Ignore favicon requests
|
||||
location /favicon.ico {
|
||||
return 204;
|
||||
access_log off;
|
||||
log_not_found off;
|
||||
}
|
||||
|
||||
location / {
|
||||
|
||||
add_header 'Access-Control-Allow-Origin' '*';
|
||||
add_header 'Access-Control-Allow-Credentials' 'true';
|
||||
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, HEAD';
|
||||
add_header 'Access-Control-Allow-Headers' '*';
|
||||
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection "Upgrade";
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
|
||||
proxy_pass http://localhost:9000;
|
||||
proxy_intercept_errors on;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
###### 2. Activate and test Nginx WSS configuration
|
||||
|
||||
- Create a symlink to `/etc/nginx/sites-enabled`:
|
||||
```sh
|
||||
ln -s /etc/nginx/sites-available/wss-config-nym /etc/nginx/sites-enabled
|
||||
```
|
||||
|
||||
- Test your configuration syntax:
|
||||
```sh
|
||||
nginx -t
|
||||
```
|
||||
|
||||
###### 3. Restart `nginx`
|
||||
```sh
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
###### 4. Finally, configure your `nym-node` to announce the port and hostname of your WSS and restart the node
|
||||
|
||||
- Open your node configuration file located at `~/.nym/nym-nodes/<ID>/config/config.toml`
|
||||
```sh
|
||||
nano ~/.nym/nym-nodes/<ID>/config/config.toml
|
||||
```
|
||||
|
||||
- And change the values of `announce_wss_port` in the `[entry_gateway]` and `hostname` in the `[host]` section:
|
||||
|
||||
```toml
|
||||
announce_wss_port = <ANNOUNCE_WSS_PORT>
|
||||
|
||||
# example
|
||||
# announce_wss_port = 9001
|
||||
|
||||
hostname = '<HOSTNAME>'
|
||||
|
||||
# example
|
||||
# hostname = 'exit-gateway1.squad.nsl'
|
||||
```
|
||||
|
||||
- Restart your `nym-node`
|
||||
```sh
|
||||
systemctl daemon-reload && service nym-node restart
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
Your `nym-node` should be configured to run over WSS now. Test it using the steps in the chapter [below](#test-wss-setup).
|
||||
|
||||
### Test WSS Setup
|
||||
|
||||
You can do a few quick checks to test that your installation worked out and your `nym-node` is running correctly using WSS:
|
||||
|
||||
- Check out connection with `wscat` from another (local) machine:
|
||||
```sh
|
||||
# install
|
||||
sudo apt install node-ws
|
||||
|
||||
# run
|
||||
wscat -c wss://<HOSTNAME>:<WSS_PORT>
|
||||
```
|
||||
|
||||
- Check Swagger API of your node using the hostname: `https://<HOSTNAME>/api/v1/swagger/#/`
|
||||
|
||||
@@ -1,172 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { MigrateTabs } from 'components/operators/nodes/node-migrate-command-tabs';
|
||||
import BuildInfo from 'components/outputs/command-outputs/nym-node-build-info.md';
|
||||
import NymNodeHelp from 'components/outputs/command-outputs/nym-node-help.md';
|
||||
import NymNodeRunHelp from 'components/outputs/command-outputs/nym-node-run-help.md';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
# Nym Node Setup & Run
|
||||
|
||||
This documentation page provides a guide on how to set up and run a [NYM NODE](../nym-node.mdx), along with explanations of available flags, commands, and examples.
|
||||
|
||||
## Current version
|
||||
|
||||
<BuildInfo />
|
||||
|
||||
## Summary
|
||||
|
||||
<VarInfo/ >
|
||||
|
||||
To run a new node, you can simply execute the `nym-node` command without any flags. By default, the node will set necessary configurations. If you later decide to change a setting, you can use the `-w` flag.
|
||||
|
||||
The most crucial aspect of running the node is specifying the `--mode`. At the moment it can be only one of three: `mixnode`, `entry-gateway`, and `exit-gateway`.
|
||||
|
||||
Currently the `nym-node` binary can only be run in a single `--mode` at any one time. In the future however, operators will be able to specify multiple modes that a single `nym-node` binary can run. Our goal is to have as many nodes as possible enabling multiple modes, and allow the Nym API to position the node according the network's needs in the beginning of each epoch.
|
||||
|
||||
Every `exit-gateway` mode is basically an `entry-gateway` with NR (Network Requester) and IPR (IP Packet Router) enabled. This means that every `exit-gateway` is automatically seen as an `entry-gateway` but not the opposite.
|
||||
|
||||
Gateway operators can check out the node performance, connectivity and much more in our new tool [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/).
|
||||
|
||||
To determine which mode your node is running, you can check the `:8080/api/v1/roles` endpoint. For example:
|
||||
```sh
|
||||
# sustitude <IPv4_ADDRESS> or <HOSTNAME> with the one corresponding to your node
|
||||
# for http
|
||||
http://<IPv4_ADDRESS>:8080/api/v1/roles
|
||||
# or
|
||||
http://<IPv4_ADDRESS>/api/v1/roles
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/roles
|
||||
```
|
||||
|
||||
Everything necessary will exist on your node by default. For instance, if you're running a mixnode, you'll find that a NR (Network Requester) and IPR (IP Packet Router) address exist, but they will be ignored in `mixnode` mode.
|
||||
|
||||
For more information about available endpoints and their status, you can refer to:
|
||||
```sh
|
||||
# sustitude <IPv4_ADDRESS> or <HOSTNAME> with the one corresponding to your node
|
||||
# for http
|
||||
http://<IPv4_ADDRESS>:8080/api/v1/swagger/#/
|
||||
# or
|
||||
http://<IPv4_ADDRESS>/api/v1/swagger/#/
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/swagger/#/
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
### Help Command
|
||||
|
||||
There are a few changes from the individual binaries used in the past. For example by default `run` command does `init` function as well, local node `--id` will be set by default unless specified otherwise etcetera.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
You can always use `--help` flag to see the commands or arguments associated with a given command.
|
||||
</Callout>
|
||||
|
||||
Run `./nym-node --help` to see all available commands:
|
||||
|
||||
<NymNodeHelp />
|
||||
|
||||
To list all available flags for each command, run `./nym-node <COMMAND> --help` for example `./nym-node run --help`:
|
||||
|
||||
<AccordionTemplate name="Command output">
|
||||
<NymNodeRunHelp />
|
||||
</AccordionTemplate>
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
The Wireguard flags currently have limited functionality. From version `1.1.6` ([`v2024.9-topdeck`](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.9-topdeck)) wireguard is available and recommended to be switched on for nodes running as Gateways. Keep in mind that this option needs a bit of a special [configuration](configuration.md#wireguard-setup).
|
||||
</Callout>
|
||||
|
||||
### Terms & Conditions
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
From `nym-node` version `1.1.3` onward is required to accept [**Operators Terms & Conditions**]({{toc_page}}) in order to be part of the active set. Make sure to read them before you add the flag.
|
||||
</Callout>
|
||||
|
||||
There has been a long ongoing discussion whether and how to apply Terms and Conditions for Nym network operators, with an aim to stay aligned with the philosophy of Free Software and provide legal defense for both node operators and Nym developers. To understand better the reasoning behind this decision, you can listen to the first [Nym Operator Town Hall](https://www.youtube.com/live/7hwb8bAZIuc?si=3mQ2ed7AyUA1SsCp&t=915) introducing the T&Cs or to [Operator AMA with CEO Harry Halpin](https://www.youtube.com/watch?v=yIN-zYQw0I0) from June 4th, 2024, explaining pros and cons of T&Cs implementation.
|
||||
|
||||
Accepting T&Cs is done via a flag `--accept-operator-terms-and-conditions` added explicitly to `nym-node run` command every time. If you use [systemd](configuration.md#systemd) automation, add the flag to your service file's `ExecStart` line.
|
||||
|
||||
To check whether any node has T&Cs accepted or not can be done by querying Swagger API endpoint `/auxiliary_details` via one of these ports (depending on node setup):
|
||||
```sh
|
||||
# sustitude <NODE_IP_ADDRESS> or <NODE_DOMAIN> with a real one
|
||||
http://<NODE_IP_ADDRESS>:8080/api/v1/auxiliary_details
|
||||
https://<NODE_DOMAIN>/api/v1/auxiliary_details
|
||||
http://<NODE_IP_ADDRESS>/api/v1/auxiliary_details
|
||||
```
|
||||
|
||||
```sh
|
||||
# substitude <PUBLIC_IP> with a real one
|
||||
curl -X 'GET' \
|
||||
'http://<NODE_IP_ADDRESS>:8080/api/v1/auxiliary-details' \
|
||||
-H 'accept: application/json'
|
||||
|
||||
{
|
||||
"location": "Kurdistan",
|
||||
"accepted_operator_terms_and_conditions": true
|
||||
}
|
||||
```
|
||||
|
||||
### Commands & Examples
|
||||
|
||||
**`nym-node` introduces a default human readible ID (local only) `default-nym-node`, which is used if there is not an explicit custom `--id <ID>` specified. All configuration is stored in `~/.nym/nym-nodes/default-nym-node/config/config.toml` or `~/.nym/nym-nodes/<ID>/config/config.toml` respectively.**
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
All commands with more options listed below include `--accept-operator-terms-and-conditions` flag, read [Terms & Conditions](#terms--conditions) chapter above before executing these commands.
|
||||
</Callout>
|
||||
|
||||
#### Essential Parameters & Variables
|
||||
|
||||
Running a `nym-node` in a `mixnode` mode requires less configuration than a full `exit-gateway` setup, we recommend operators to still follow through with all documented [configuration](configuration.md). Before you scroll down to syntax examples for the mode of your choice please familiarise yourself with the essential [paramters and variables](../../variables.mdx) convention we use in the guide.
|
||||
|
||||
<Callout>
|
||||
To prevent over-flooding of our documentation we cannot provide with every single command syntax as there is a large combination of possibilities. Please read the [variables and parameters page](../../variables.mdx), use the explanation in `--help` option and common sence.
|
||||
</Callout>
|
||||
|
||||
|
||||
### Initialise & Run
|
||||
|
||||
When we use `run` command the node will do `init` as well, unless we specify with a flag `--deny-init`. Below are some examples of initialising and running `nym-node` with different modes (`--mode`) like `mixnode`, `entry-gateway`, `exit-gateway`.
|
||||
|
||||
Please keep in mind that currently you can run only one functionality (`--mode`) per a `nym-node` instance. We are yet to finalise implement the multi-functionality solution under one node bonded to one Nyx account. Every `exit-gateway` can function as `entry-gateway` by default, not vice versa.
|
||||
|
||||
There is a simple default command to initialise and run your node: `./nym-node run --mode <MODE>`, however there quite a few parameters to be configured. When `nym-node` gets to be `run`, these parameters are read by the binary from the configuration file located at `.nym/nym-nodes/<ID>/config/config.toml`.
|
||||
|
||||
If an operator specifies any paramteres with optional flags alongside `run` command, these parameters passed in the option will take place over the ones in `config.toml` but they will not overwrite them by default. To overwrite them with the values passed with `run` command, a flag `-w` (`--write-changes`) must be added.
|
||||
|
||||
Alternatively operators can just open a text editor and change these values manually. After saving the file,don't forget to restart the node or reload and restart the service. If all values are setup correctly in `config.toml`, then operator can use as simple command as `nym-node run --mode <MODE> --accept-operators-terms-and-conditions`, or alternatively paste this command with a correct path to your binary to your `ExecStart` line into a [systemd `nym-node.service`](configuration.md#systemd) config file.
|
||||
|
||||
**Below is a step by step guide how to initialise and run `nym-node`. Each tab represents one functionality.**
|
||||
|
||||
<RunTabs />
|
||||
|
||||
<Callout>
|
||||
**We recommend operators to setup an [automation](configuration.md#systemd) flow for their nodes, using systemd!**
|
||||
|
||||
In such case, you can `run` a node to initalise it or try if everything works, but then stop the proces and paste your entire `run` command syntax (below) to the `ExecStart` line of your `/etc/systemd/system/nym-node.service` and start the node as a [service](configuration.md#following-steps-for-nym-nodes-running-as-systemd-service).
|
||||
</Callout>
|
||||
|
||||
### Migrate
|
||||
|
||||
<Callout type="warning">
|
||||
Migration is a must for all deprecated nodes (`nym-mixnode`, `nym-gateway`). These binaries from version 1.1.35 (`nym-gateway`) and 1.1.37 (`nym-mixnode`) onwards will no longer have `init` command and `nym-node` is the only binary to use for `gateway` or `mixnode` fucntionalities.
|
||||
|
||||
**Nym cannot promise 100% serialisation for operators migrating from long outdated versions to the newest ones. If you are about to migrate, start with [`nym-node v1.1.0`](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.3-eclipse) and keep upgrading version by version all the way to the latest one.**
|
||||
</Callout>
|
||||
|
||||
Operators who are about to migrate their nodes need to configure their [VPS](vps-setup.md) and setup `nym-node` which can be downloaded as a [pre-built binary](../binaries/pre-built-binaries.md) or compiled from [source](../binaries/building-nym.md).
|
||||
|
||||
To migrate a `nym-mixnode` or a `nym-gateway` to `nym-node` is fairly simple, use the `migrate` command with `--config-file` flag pointing to the original `config.toml` file, with a conditional argument defining which type of node this configuration belongs to. Examples are below.
|
||||
|
||||
Make sure to use `--deny-init` flag to prevent initialisation of a new node.
|
||||
|
||||
<MigrateTabs />
|
||||
|
||||
### Next steps
|
||||
|
||||
If there are any problems checkout the troubleshooting section or report an issue.
|
||||
|
||||
Follow up with [configuration](configuration.mdx) page for automation, reversed proxy setup and other tweaks, then head straight to [bonding](bonding.mdx) page to finalise your setup.
|
||||
@@ -1,47 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
|
||||
# Performance Monitoring & Testing
|
||||
|
||||
Nym Mixnet has been running on mainnet for quite some time. There is still work to be done in order for the network to meet its full potential - mass adoption of privacy through fully distributed Mixnet.
|
||||
|
||||
As developers we need to be constantly improving the software. Operators have as much important role, keep their nodes up to date, monitor their performance and share their feedback with the rest of the community and core developers.
|
||||
|
||||
Therefore [monitoring](#monitoring) and [testing](#testing) are essential pieces of our common work. We call out all Nym operators to join the efforts!
|
||||
|
||||
## Monitoring
|
||||
|
||||
There are multiple ways to monitor performance of nodes and the machines on which they run. For the purpose of maximal privacy and decentralisation of the data - preventing Nym Mixnet from any global adversary takeover - we created these pages as a source of mutual empowerment, a place where operators can share and learn new skills to **setup metrics monitors on their own infrastructure**.
|
||||
|
||||
### Guides to Setup Own Metrics
|
||||
|
||||
A list of different scripts, templates and guides for easier navigation:
|
||||
|
||||
* [`nym-gateway-probe`](perfomance-and-testing/gateway-probe.mdx) - a useful tool used under the hood of [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net)
|
||||
* [Prometheus and Grafana](performance-and-testing/prometheus-grafana.mdx) self-hosted setup
|
||||
* [Nym-node CPU cron service](https://gist.github.com/tommyv1987/97e939a7adf491333d686a8eaa68d4bd) - an easy bash script by Nym core developer [@tommy1987](https://gist.github.com/tommyv1987), designed to monitor a CPU usage of your node, running locally
|
||||
* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/develop/scripts/prom_targets.py) - a useful python program to request data from API and can be run on its own or plugged to more sophisticated flows
|
||||
|
||||
### Collecting Testing Metrics
|
||||
|
||||
For the purpose of the performance testing Nym core developers plan to run instances of Prometheus and Grafana connected to Node explorer in the house. The network overall key insights we seek from these tests are primarily internal. We're focused on pinpointing bottlenecks, capacity loads, and monitoring cpu usage on the nodes' machines.
|
||||
|
||||
|
||||
## Testing
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
For the moment we paused Fast and Furious `perf` environment. All load and speed testing is carried on directly Nym Mainnet as this is the only way to collect real performance data.
|
||||
</Callout>
|
||||
|
||||
We do testing in order to **understand and increase the overall quality of the Nym Network**. The main takeaways of such event are:
|
||||
|
||||
1. Understanding of the network behavior under full load
|
||||
- How many mixnet client users can all active set entry gateways handle simultaneously?
|
||||
- How much sustained IP traffic can a subset of mainnet nodes sustain?
|
||||
2. Needed improvements of Nym Node binaries to improve the throughput on mainnet
|
||||
3. Measurement of required machine specs
|
||||
4. Raw data record
|
||||
5. Increase quality of Nym Nodes
|
||||
6. Show each operator a way to monitor their nodes in a distributed fashion
|
||||
7. Adjust rewarding based on the machine specs and server pricing
|
||||
|
||||
Visit [Nym Harbour Master](https://harbourmaster.nymtech.net/) monitoring page to monitor network components (nodes) performance.
|
||||
@@ -1,5 +0,0 @@
|
||||
{
|
||||
"gateway-probe": "Gateway Probe",
|
||||
"node-api-check": "Node API Check",
|
||||
"prometheus-grafana": "Prometheus & Grafana"
|
||||
}
|
||||
@@ -1,91 +0,0 @@
|
||||
# Nym Gateway Probe
|
||||
|
||||
Nym Node operators running Gateway functionality are already familiar with the monitoring tool [Harbourmaster.nymtech.net](https://harbourmaster.nymtech.net). Under the hood of Nym Harbourmaster runs iterations of `nym-gateway-probe` doing various checks and displaying the results on the interface. Operators don't have to rely on the probe ran by Nym and wait for the data to refresh. With `nym-gateway-probe` everyone can check any Gateway's networking status from their own computer at any time. In one command the client queries data from:
|
||||
|
||||
- [`nym-api`](https://validator.nymtech.net/api/v1/gateways)
|
||||
- [`explorer-api`](https://explorer.nymtech.net/api/v1/gateways)
|
||||
- [`harbour-master`](https://harbourmaster.nymtech.net/)
|
||||
|
||||
|
||||
## Preparation
|
||||
|
||||
We recommend to have install all [the prerequisites](../binaries/building-nym.md#prerequisites) needed to build `nym-node` from source including latest [Rust Toolchain](https://www.rust-lang.org/tools/install).
|
||||
|
||||
## Installation
|
||||
|
||||
`nym-gateway-probe` source code is in [`nym-vpn-client`](https://github.com/nymtech/nym-vpn-client) repository. The client needs to be build from source.
|
||||
|
||||
1. Clone the repository:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/nymtech/nym-vpn-client.git
|
||||
```
|
||||
|
||||
2. Build `nym-gateway-probe`:
|
||||
|
||||
```sh
|
||||
cd nym-vpn-client/nym-vpn-core
|
||||
|
||||
cargo build --release -p nym-gateway-probe
|
||||
```
|
||||
|
||||
## Running the Client
|
||||
|
||||
To list all commands and options run the binary with `--help` command:
|
||||
|
||||
```sh
|
||||
./target/release/nym-gateway-probe --help
|
||||
```
|
||||
|
||||
- Output:
|
||||
|
||||
```sh
|
||||
Usage: nym-gateway-probe [OPTIONS]
|
||||
|
||||
Options:
|
||||
-c, --config-env-file <CONFIG_ENV_FILE> Path pointing to an env file describing the network
|
||||
-g, --gateway <GATEWAY>
|
||||
-n, --no-log
|
||||
-h, --help Print help
|
||||
-V, --version Print version
|
||||
|
||||
```
|
||||
|
||||
To run the client, simply add a flag `--gateway` with a targeted gateway identity key.
|
||||
|
||||
```sh
|
||||
./target/release/nym-gateway-probe --gateway <GATEWAY_IDENTITY_KEY>
|
||||
```
|
||||
|
||||
For any `nym-node --mode exit-gateway` the aim is to have this outcome:
|
||||
|
||||
```json
|
||||
{
|
||||
"gateway": "<GATEWAY_IDENTITY_KEY>",
|
||||
"outcome": {
|
||||
"as_entry": {
|
||||
"can_connect": true,
|
||||
"can_route": true
|
||||
},
|
||||
"as_exit": {
|
||||
"can_connect": true,
|
||||
"can_route_ip_v4": true,
|
||||
"can_route_ip_external_v4": true,
|
||||
"can_route_ip_v6": true,
|
||||
"can_route_ip_external_v6": true
|
||||
},
|
||||
"wg": {
|
||||
"can_register": true,
|
||||
"can_handshake": true,
|
||||
"can_resolve_dns": true,
|
||||
"ping_hosts_performance": 1.0,
|
||||
"ping_ips_performance": 1.0
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**If your Gateway is blacklisted, the probe will not work.**
|
||||
|
||||
If you don't provide a `--gateway` flag it will pick a random one to test.
|
||||
|
||||
@@ -1,162 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import NodeApiCheckHelp from 'components/outputs/command-outputs/node-api-check-help.md';
|
||||
import NodeApiCheckQueryHelp from 'components/outputs/command-outputs/node-api-check-query-help.md'
|
||||
|
||||
# Node API Check
|
||||
|
||||
<VarInfo />
|
||||
|
||||
Operating a `nym-node` is not a *"set and forget"* endeavor, it takes some work. To diagnose node network performance through querying APIs, is a good knowledge to have. These are the main places to look for API endpoints regarding `nym-node`:
|
||||
|
||||
- [`openapi.json`](https://validator.nymtech.net/api/v1/openapi.json): a list of all endpoints
|
||||
- [Swagger UI page](https://validator.nymtech.net/api/swagger/index.html)
|
||||
|
||||
Besides that, node operators can check out their node performance, connectivity and much more on [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net/).
|
||||
|
||||
### Basic API usage
|
||||
|
||||
For information about available endpoints and their status, you can refer to:
|
||||
```sh
|
||||
# for http
|
||||
http://<PUBLIC_IP>:8080/api/v1/swagger/#/
|
||||
# or
|
||||
http://<PUBLIC_IP>/api/v1/swagger/#/
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/swagger/#/
|
||||
```
|
||||
|
||||
For example to determine which mode your node is running, you can check `:8080/api/v1/roles` endpoint:
|
||||
```sh
|
||||
# for http
|
||||
http://<PUBLIC_IP>:8080/api/v1/roles
|
||||
# or
|
||||
http://<PUBLIC_IP>/api/v1/roles
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/roles
|
||||
```
|
||||
|
||||
## `node_api_check.py`
|
||||
|
||||
To make this a bit easier, we made a CLI tool querying all available API endpoints based on node `Identity Key` (further denoted as `<ID_KEY>`) called `node_api_check.py`. To diagnose your node performance, whether by yourself or by sharing an output in our [operator channel](https://matrix.to/#/#operators:nymtech.chat), this tool provides you with a quick overview of live data. We recommend to run this checker alongside [`nym_gateway_probe`](gateway-probe.md) to triage both performance and an actual routing.
|
||||
|
||||
Besides querying any bonded node APIs, `nym_api_check.py` has a function counting all existing nodes in provided version.
|
||||
|
||||
### Setup
|
||||
|
||||
#### Pre-requsities
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Install and configure Python3
|
||||
|
||||
|
||||
- Start with installing Python3:
|
||||
```sh
|
||||
sudo apt install python3
|
||||
```
|
||||
|
||||
- Make sure Python3 is your default Python version:
|
||||
```sh
|
||||
update-alternatives --install /usr/bin/python python /usr/bin/python3 1
|
||||
```
|
||||
|
||||
- Verify:
|
||||
```sh
|
||||
python --version
|
||||
|
||||
# should return higher than 3
|
||||
```
|
||||
|
||||
- Install Python modules `tabulate`, `pandas` and `argparse` either using [`pip`](https://python.land/virtual-environments/installing-packages-with-pip) or if you installed Python3 system-wide you can install modules directly:
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<strong>Using <code>pip</code></strong>,
|
||||
<strong>System-wide Python installation</strong>,
|
||||
]} defaultIndex="1">
|
||||
<MyTab>
|
||||
```sh
|
||||
pip install tabulate pandas argparse
|
||||
```
|
||||
</MyTab>
|
||||
<MyTab>
|
||||
```sh
|
||||
sudo apt install python3-tabulate python3-pandas python3-argparse -y
|
||||
```
|
||||
</MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
###### 2. Install `node_api_check.py` and make executable
|
||||
|
||||
To run the program you neet to have [`node_api_check.py`](https://github.com/nymtech/nym/tree/develop/scripts/node_api_check.py) and [`api_endpoints.json`](https://github.com/nymtech/nym/tree/develop/scripts/api_endpoints.json).
|
||||
|
||||
- If you [compiled from source](../../binaries/building-nym.mdx), you already have both of these files. Note that the latest version of this program may be on `develop` branch.
|
||||
|
||||
- If you prefer to download them individually, do it by opening terminal in your desired location and running:
|
||||
```sh
|
||||
wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/node_api_check.py
|
||||
|
||||
wget https://raw.githubusercontent.com/nymtech/nym/tree/develop/api_endpoints.json
|
||||
```
|
||||
|
||||
- Make executable:
|
||||
```sh
|
||||
chmod u+x node_api_check.py
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
Now you are ready to check your node.
|
||||
|
||||
### Usage & Commands
|
||||
|
||||
- Run the program with `--help` flag to see the available commands:
|
||||
```sh
|
||||
./node_api_check.py --help
|
||||
```
|
||||
|
||||
- Command Output:
|
||||
|
||||
<NodeApiCheckHelp />
|
||||
|
||||
#### `query_stats`
|
||||
|
||||
When you want to see all the options connected to any command, add a `--help` flag after the command of your choice. Command `query_stats` is the most useful one of this program.
|
||||
|
||||
```sh
|
||||
./node_api_check query_stats --help
|
||||
```
|
||||
|
||||
- Command output:
|
||||
|
||||
<NodeApiCheckQueryHelp/ >
|
||||
|
||||
The most common usage may be `./node_api_check.py query_stats <ID_KEY>` where `<ID_KEY>` is required, substitute it with node Identity Key.
|
||||
|
||||
**Optional arguments**
|
||||
|
||||
| Flag | Shortcut | Description |
|
||||
| :--- | :--- | :--- |
|
||||
| `--markdown` | `-m` | returns output in markdown format |
|
||||
| `--no_routing_history` | None | returns output without routing history which can be lengthy |
|
||||
| `--no_verloc_metrics` | None | returns output without verloc measurement which can be lengthy |
|
||||
| `--output` | `-o` | exports output to a file, possible to add a target path |
|
||||
|
||||
#### `version_count`
|
||||
|
||||
<Callout>
|
||||
To see a quick overview of `nym-node` version distribution in numbers and graph, visit [Nym Harbourmaster](https://harbourmaster.nymtech.net).
|
||||
</Callout>
|
||||
|
||||
Another command is `version_count` where at least one `nym-node` version is required. In case of multiple version count, separate the versions with space. We recommend to run this command with `--markdown` flag for a nicer output. This is an example where we want to look up how many registered nodes are on versions `1.1.0`, `1.1.1`, `1.1.2` and `1.1.3`:
|
||||
```sh
|
||||
./node_api_check version_count 1.1.0 1.1.1 1.1.2 1.1.3 --markdown
|
||||
```
|
||||
|
||||
-37
@@ -1,37 +0,0 @@
|
||||
# Prometheus & Grafana
|
||||
|
||||
Besides monitoring node performance, it's quite useful to setup monitoring system for servers on which operators run their nodes.
|
||||
|
||||
The combination of Prometheus and Grafana is a common stack used by Nym team for internal monitoring as well as by core community operators like [ExploreNym](https://github.com/ExploreNYM/self-hosted-monitor).
|
||||
|
||||
## Prometheus
|
||||
|
||||
[Prometheus](https://prometheus.io) is a free and open source monitoring systems. It allows operators to have their metrics, events, and alerts under full control. This ecosystem offers multiple advantages:
|
||||
|
||||
- Collects and records metrics from servers, containers, and applications
|
||||
- Provides a [flexible query language (PromQL)](https://prometheus.io/docs/prometheus/latest/querying/basics/)
|
||||
- Multiple modes visualization tools
|
||||
- An alerting mechanism that sends notifications
|
||||
|
||||
Prometheus collects and stores its metrics as time series data, i.e. metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels.
|
||||
|
||||
## Grafana
|
||||
|
||||
[Grafana](https://grafana.com/docs/grafana/latest/) is an open-source analytics and interactive front end. It is widely used for its easy to manage dashboards with visualizations like graphs, charts and alerts, all connected to live data sources.
|
||||
|
||||
## Setup Guides
|
||||
|
||||
There are various ways how to setup this stack. You can chose based on your preferences to do your own flow or follow some of the documented ones:
|
||||
|
||||
- [ExploreNYM scripts](prometheus-grafana/explorenym-scripts.mdx) for self-hosted monitoring
|
||||
- Setup monitoring in a Docker container (*Under review - will be out soon*)
|
||||
|
||||
## References and further reading
|
||||
|
||||
* [Prometheus release page](https://prometheus.io/download/)
|
||||
* [Prometheus documentation](https://prometheus.io/docs/introduction/overview/)
|
||||
* Installation [guide to install Prometheus](https://www.cherryservers.com/blog/install-prometheus-ubuntu) on Ubuntu by cherryservers
|
||||
* [Grafana installation guide](https://grafana.com/docs/grafana/latest/setup-grafana/installation/debian/)
|
||||
* Nym's script [`prom_targets.py`](https://github.com/nymtech/nym/blob/develop/scripts/prom_targets.py) - a python program to request data from API and can be plugged to this stack
|
||||
* [Nym-node CPU cron service](https://gist.github.com/tommyv1987/97e939a7adf491333d686a8eaa68d4bd) - an easy bash script by Nym core developer [@tommy1987](https://gist.github.com/tommyv1987), designed to monitor a CPU usage of your node, running locally
|
||||
|
||||
-6
@@ -1,6 +0,0 @@
|
||||
{
|
||||
"explorenym-scripts": "ExploreNYM Scripts",
|
||||
"docker-monitor": {
|
||||
"display": "hidden"
|
||||
}
|
||||
}
|
||||
-149
@@ -1,149 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
# ExploreNym Monitoring Scripts
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
This setup and the scripts included were not written by Nym developers. As always do your own audit before installing any scripts on your machine and familiarize yourself with the security risks involved when opening ports or allowing http access.
|
||||
</Callout>
|
||||
|
||||
## Community Monitoring Tools
|
||||
|
||||
Individual operators, node families and squads are the foundation of distributed network. There has been a great number of tools coming out of this community some of which can be deployed for the node monitoring setup.
|
||||
|
||||
## ExploreNYM Tools
|
||||
|
||||
Long term involved operator Pawnflake, an author of [ExploreNYM](https://explorenym.net/) explorer, created a monitoring flow, which can be used by other operators called [`self-hosted-monitor`](https://github.com/ExploreNYM/self-hosted-monitor). It utilises bash scripts to enable operators setup [Prometheus](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus.sh) and [Grafana](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/grafana.sh) together with [Node Exporter](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/node-exporter.sh) and [Nginx](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/nginx-certbot.sh) to run their metrics monitoring stack locally.
|
||||
|
||||
In collaboration with ExploreNYM we published a [step by step guide](#setup) to set this up.
|
||||
|
||||
ExploreNYM also has a network measuring instance called `enym-monitor`. This setup is very simple for users, however it means that their data are all aggregated into one server such design always brings a risk of centralisation of distributed node's data into one computer.
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Make sure you understand and properly evaluate what degree of control you give permission to before granting access to your data to any tools running on someone else's servers.
|
||||
</Callout>
|
||||
|
||||
## Setup
|
||||
|
||||
**Minimum requirements of the monitor stack**
|
||||
|
||||
- 2 CPU
|
||||
- 4 GB RAM
|
||||
- 20 GB of free disk space.
|
||||
|
||||
SSH to your server as `root` or become one running `sudo -i` or `su`. If you prefer to administrate your VPS from a user environment, supply the commands with prefix `sudo`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. The monitoring part setup
|
||||
|
||||
This can be setup on another VPS than the node if desired. We recommend to try to set this up on the same VPS, as your node as we expect the machine to be strong enough to handle the node with enough capacity reserve for monitor.
|
||||
|
||||
- Install git
|
||||
```sh
|
||||
apt install git
|
||||
```
|
||||
|
||||
- Clone the repository to `~/self-hosted-monitor`
|
||||
```sh
|
||||
git clone https://github.com/ExploreNYM/self-hosted-monitor ~/self-hosted-monitor
|
||||
```
|
||||
|
||||
- Give permissions to [`prometheus.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus.sh) script and run it to setup Prometheus
|
||||
```sh
|
||||
chmod +x ~/self-hosted-monitor/prometheus.sh && ~/self-hosted-monitor/prometheus.sh
|
||||
```
|
||||
|
||||
- Give permissions to [`grafana.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/grafana.sh) script and run it to setup Grafana
|
||||
```sh
|
||||
chmod +x ~/self-hosted-monitor/grafana.sh && ~/self-hosted-monitor/grafana.sh
|
||||
```
|
||||
|
||||
- Open port `3000` to allow access to Grafana
|
||||
```sh
|
||||
sudo ufw allow 3000
|
||||
```
|
||||
|
||||
- You can now access Grafana at `http://<IP_ADDRESS>:3000`.
|
||||
|
||||
- *Optional step*: If you have a registered domain and prefer to use it with `https`, give permissions to [`nginx-certbot.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/nginx-certbot.sh) script and run it to setup Nginx and Certbot
|
||||
```sh
|
||||
chmod +x ~/self-hosted-monitor/nginx-certbot.sh && ~/self-hosted-monitor/nginx-certbot.sh
|
||||
```
|
||||
|
||||
- Give permissions to [`prometheus-target.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/prometheus-target.sh) script and run it to add a scrape target. This can be run multiple times to add a new server to be monitored via Prometheus/
|
||||
```sh
|
||||
chmod +x ~/self-hosted-monitor/prometheus-target.sh && ~/self-hosted-monitor/prometheus-target.sh
|
||||
```
|
||||
|
||||
###### 2. The target server (the part to be monitored) setup
|
||||
|
||||
- In case you run this part on another VPS: Install git
|
||||
```sh
|
||||
apt install git
|
||||
```
|
||||
|
||||
- In case you run this part on another VPS: Clone the repository to `~/self-hosted-monitor`
|
||||
```sh
|
||||
git clone https://github.com/ExploreNYM/self-hosted-monitor ~/self-hosted-monitor
|
||||
```
|
||||
|
||||
- Give permissions to [`node-exporter.sh`](https://github.com/ExploreNYM/self-hosted-monitor/blob/main/node-exporter.sh) script and run it to setup Node exporter.
|
||||
```sh
|
||||
chmod +x ~/self-hosted-monitor/node-exporter.sh && ~/self-hosted-monitor/node-exporter.sh
|
||||
```
|
||||
|
||||
###### 3. Grafana dashboard setup
|
||||
|
||||
Finally we need to access Grafana dashboards.
|
||||
|
||||
- Open a browser at `http://<IP_ADDRESS>:3000` or `https://<HOSTNAME>` (depends on your setup), enter username `admin` and password `admin` and setup new credentials on prompt
|
||||
|
||||
- Setup *Data source* by opening menu -> `Connections` -> `Data sources` -> `+ Add new data source` -> `Prometheus`
|
||||
|
||||
|
||||
|
||||
|
||||
- In the field *Connection* next to `Prometheus server URL` enter `http://localhost:9090` (regardless if you accessing Grafana via `http` or `https` as this is for internal connection on the server). When you are done in the bottom confirm by `Save & Test`
|
||||
|
||||
- In the menu open: `Dashboards` -> `+ Create dashboard` -> `Import dashboard`
|
||||
|
||||
|
||||
|
||||
- ID field: enter `1860` -> `Load`
|
||||
|
||||
|
||||
|
||||
- In *Import dashboard* page select Prometheus in the bottom and finally `Import`
|
||||
|
||||
|
||||
|
||||
</Steps>
|
||||
|
||||
Now you have your Prometheus panels displayed via Grafana dashboard for a simple monitoring of your node.
|
||||
|
||||
## Verification and Troubleshooting
|
||||
|
||||
To ensure that your services are running correctly, you can verify that by running `systemctl status <SERVICE>` or run a `journalctl -f -u <SERVICE>` to print service logs. It shall return status `Active: active (running)`. For example:
|
||||
|
||||
- To check if Prometheus service is active:
|
||||
```sh
|
||||
systemctl status prometheus
|
||||
```
|
||||
|
||||
- To check if Grafana service is active:
|
||||
```sh
|
||||
systemctl status grafana-server
|
||||
```
|
||||
|
||||
- To check if node-exporter service is active:
|
||||
```sh
|
||||
systemctl status node_exporter
|
||||
```
|
||||
|
||||
- To run journal log:
|
||||
```sh
|
||||
journalctl -f -u prometheus # or any other service you want to see
|
||||
```
|
||||
@@ -1,10 +0,0 @@
|
||||
# Preliminary Steps
|
||||
|
||||
> The `nym-node` binary 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.
|
||||
|
||||
There are a couple of steps that need completing before starting to set up your `nym-node`:
|
||||
|
||||
1. **[Prepare your wallet](preliminary-steps/wallet-preparation.mdx):** [desktop](https://nymtech.net/docs/wallet/desktop-wallet.html) or [CLI](../../developers/tools/nym-cli/commands.mdx).
|
||||
2. **[Requisition and setup a VPS](preliminary-steps/vps-setup.mdx)** (Virtual Private Server)
|
||||
|
||||
Make sure to follow these steps carefully as it prevents a lot of troubleshooting later on.
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"wallet-preparation": "Nym Wallet Preparation",
|
||||
"vps-setup": "VPS Setup"
|
||||
}
|
||||
@@ -1,274 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';import { Tabs } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import PortsNymNode from 'components/operators/snippets/ports-nym-node.mdx';
|
||||
import PortsValidator from 'components/operators/snippets/ports-validator.mdx'
|
||||
|
||||
# VPS Setup & Configuration
|
||||
|
||||
We aim for Nym Network to be reliable and quality base layer of privacy accross the globe, while growing as distributed as possible. It's essential to have a fine tuned machine as a foundation for the nodes to meet the requirements and be rewarded for their work.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
A sub-optimally configured VPS often results in a non-functional node. To follow these steps carefully will save you time and money later on.
|
||||
</Callout>
|
||||
|
||||
## 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).
|
||||
|
||||
Tor community created a very helpful table called [*Good Bad ISPs*](https://community.torproject.org/relay/community-resources/good-bad-isps/), you can use that one as a guideline for your choice of ISP for your VPS.
|
||||
|
||||
**Update:** Nym community started an ISP table called [*Where to host your nym node?*](../../community-counsel/isp-list.mdx), check it out and add your findings!
|
||||
|
||||
### `nym-node`
|
||||
|
||||
Before we conclude the testing with exact results, these are the rough specs:
|
||||
|
||||
| **Hardware** | **Minimum Specification** w
|
||||
| :--- | ---: |
|
||||
| CPU Cores | 4 |
|
||||
| Memory | 4 GB RAM |
|
||||
| Storage | 40 GB |
|
||||
| Connectivity | IPv4, IPv6, TCP/IP, UDP |
|
||||
| Bandwidth | 1Tb |
|
||||
| Port speed | 1Gbps |
|
||||
|
||||
### Nyx validator
|
||||
|
||||
The specification mentioned below is for running a full node alongside the nym-api. It is recommended to run `nym-api` and a full Nyx node on the same machine for optimum performance.
|
||||
|
||||
Bear in mind that credential signing is primarily CPU-bound, so choose the fastest CPU available to you.
|
||||
|
||||
#### Minimum Requirements
|
||||
|
||||
| Hardware | **Minimum Specification** |
|
||||
|----------|--------------------------------------------|
|
||||
| CPU | 8-cores, 2.8GHz base clock speed or higher |
|
||||
| RAM | 16GB DDR4+ |
|
||||
| Disk | 500 GiB+ NVMe SSD |
|
||||
|
||||
#### Recommended Requirements
|
||||
|
||||
| Hardware | **Minimum Specification** |
|
||||
|----------|---------------------------------------------|
|
||||
| CPU | 16-cores, 2.8GHz base clock speed or higher |
|
||||
| RAM | 32GB DDR4+ |
|
||||
| Disk | 1 TiB+ NVMe SSD |
|
||||
|
||||
|
||||
#### Full node configuration (validator)
|
||||
|
||||
To install a full node from scratch, refer to the [validator setup guide](../validator-setup.mdx) and follow the steps outlined there.
|
||||
|
||||
## VPS Configuration
|
||||
|
||||
Before node or validator setup, the VPS needs to be configured and tested, to verify your connectivity and make sure that your provider wasn't dishonest with the offered services.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
The commands listed in this chapter must be executed with a prefix `sudo` or from a root shell.
|
||||
</Callout>
|
||||
|
||||
### Install Dependencies & Configure Firewall
|
||||
|
||||
SSH to your server as `root` or become one running `sudo -i` or `su`. If you prefer to administrate your VPS from a user environment, supply the commands with prefix `sudo`.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Start with setting up the essential tools on your server.
|
||||
|
||||
- Get your system up to date
|
||||
```sh
|
||||
apt update -y && apt --fix-broken install
|
||||
```
|
||||
- Install dependencies
|
||||
```sh
|
||||
apt -y install ca-certificates jq curl wget ufw jq tmux pkg-config build-essential libssl-dev git
|
||||
```
|
||||
- Double check ufw is installed correctly
|
||||
```sh
|
||||
apt install ufw --fix-missing
|
||||
```
|
||||
|
||||
###### 2. Configure your firewall using Uncomplicated Firewall (UFW)
|
||||
|
||||
For a `nym-node` or Nyx validator to recieve traffic, you need to open ports on the server. The following commands will allow you to set up a firewall using `ufw`.
|
||||
|
||||
- Check if you have `ufw` installed:
|
||||
```sh
|
||||
ufw version
|
||||
```
|
||||
- If it's not installed, install with:
|
||||
```sh
|
||||
apt install ufw -y
|
||||
```
|
||||
- Enable ufw
|
||||
```sh
|
||||
ufw enable
|
||||
```
|
||||
- Check the status of the firewall
|
||||
```sh
|
||||
ufw status
|
||||
```
|
||||
|
||||
###### 3. Open all needed ports to have your firewall for `nym-node` working correctly
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<code>nym-node</code>,
|
||||
<code>validator</code>,
|
||||
]} defaultIndex="0">
|
||||
<MyTab><PortsNymNode/></MyTab>
|
||||
<MyTab><PortsValidator/></MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
- In case of reverse proxy setup add:
|
||||
```sh
|
||||
ufw allow 443/tcp
|
||||
```
|
||||
|
||||
- Re-check the status of the firewall:
|
||||
```sh
|
||||
ufw status
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
For more information about your node's port configuration, check the [port reference table](#ports-reference-table) below.
|
||||
|
||||
## Setting `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 Nym Nodes make and receive a lot of connections with each others.
|
||||
|
||||
If you see errors such as:
|
||||
|
||||
```sh
|
||||
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
|
||||
|
||||
The ulimit setup is relevant for maintenance of Nym Node only.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Query the `ulimit` with:
|
||||
|
||||
- For 'nym-node`:
|
||||
```sh
|
||||
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep nym-node | grep -v grep |head -n 1 | awk '{print $1}')/limits
|
||||
```
|
||||
- For nyx validator
|
||||
```sh
|
||||
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep nymd | grep -v grep |head -n 1 | awk '{print $1}')/limits
|
||||
```
|
||||
|
||||
You'll get back the hard and soft limits, which looks something like this:
|
||||
|
||||
```sh
|
||||
Max open files 65536 65536 files
|
||||
```
|
||||
|
||||
If your output is **the same as above**, your node will *not* encounter any `ulimit` related issues.
|
||||
|
||||
###### 2. If either value is `1024`, you must raise the limit
|
||||
|
||||
- We recommend doing it via the `systemd` service file. Following the steps in [this guide](../nym-node/configuration.mdx#systemd).
|
||||
- You will see there a line setting new `ulimit` threshold.
|
||||
```sh
|
||||
LimitNOFILE=65536
|
||||
```
|
||||
|
||||
###### 3. Alternatively you can execute this command for system-wide setting of `ulimit`:
|
||||
|
||||
```sh
|
||||
echo "DefaultLimitNOFILE=65535" >> /etc/systemd/system.conf
|
||||
```
|
||||
- Then reboot your server, and restart your node. When it comes back, use:
|
||||
```sh
|
||||
# for nym-node
|
||||
cat /proc/$(pidof nym-node)/limits | grep "Max open files"
|
||||
|
||||
# for validator
|
||||
cat /proc/$(pidof nym-validator)/limits | grep "Max open files"
|
||||
```
|
||||
|
||||
- Make sure the limit has changed to `65535`.
|
||||
|
||||
</Steps>
|
||||
|
||||
### Set `ulimit` on non `systemd` based distributions
|
||||
|
||||
In case you choose tmux option for Nym Node automation, see your `ulimit` list by running:
|
||||
|
||||
```sh
|
||||
ulimit -a
|
||||
```
|
||||
|
||||
Watch for the output line `-n`:
|
||||
```sh
|
||||
-n: file descriptors 1024
|
||||
```
|
||||
|
||||
You can change it either by running a command:
|
||||
```sh
|
||||
ulimit -u -n 4096
|
||||
```
|
||||
|
||||
or editing `etc/security/conf` and add the following lines:
|
||||
|
||||
```sh
|
||||
# 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 node.
|
||||
|
||||
|
||||
## Ports reference tables
|
||||
|
||||
All node-specific port configuration can be found in `$HOME/.nym/<BINARY_TYPE>/<ID>/config/config.toml`. If you do edit any port configs, remember to restart your client node processes and change the configuration in the wallet settings.
|
||||
|
||||
### Nym node port reference
|
||||
|
||||
#### Mix Node functionality ports
|
||||
|
||||
| Default port | Use |
|
||||
| ------------ | ------------------------- |
|
||||
| `1789` | Listen for Mixnet traffic |
|
||||
| `1790` | Listen for VerLoc traffic |
|
||||
| `8080` | Metrics http API endpoint |
|
||||
|
||||
#### Gateway functionality ports
|
||||
|
||||
| Default port | Use |
|
||||
|-----------------|-------------------------------|
|
||||
| `1789` | Listen for Mixnet traffic |
|
||||
| `9000` | Listen for Client traffic |
|
||||
| `9001` | WSS |
|
||||
| `8080, 80, 443` | Reversed Proxy & Swagger page |
|
||||
| `51822/udp` | WireGuard |
|
||||
|
||||
#### Embedded Network Requester functionality ports
|
||||
|
||||
| Default port | Use |
|
||||
|--------------|---------------------------|
|
||||
| `9000` | Listen for Client traffic |
|
||||
|
||||
### Validator port reference
|
||||
|
||||
All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator.
|
||||
|
||||
| Default port | Use |
|
||||
|--------------|--------------------------------------|
|
||||
| `1317` | REST API server endpoint |
|
||||
| `26656` | Listen for incoming peer connections |
|
||||
| `26660` | Listen for Prometheus connections |
|
||||
@@ -1,18 +0,0 @@
|
||||
# Nym Wallet Preparation
|
||||
|
||||
## Mainnet
|
||||
|
||||
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 NYM tokens. The minimum amount required to bond a node is 100 `NYM`, but make sure you have a bit more to account for gas costs.
|
||||
|
||||
`NYM` can be purchased via [Bity](https://bity.com) 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 node. 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 [Sandbox Testnet page](../../sandbox.mdx#sandbox-token-faucet) and request testnet NYM tokens.
|
||||
|
||||
|
||||
@@ -1,591 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
# Validators
|
||||
|
||||
|
||||
> Nym has two main codebases:
|
||||
> - the [Nym platform](https://github.com/nymtech/nym), written in Rust. This contains all of our code except for the validators.
|
||||
> - the [Nym validators](https://github.com/nymtech/nyxd), written in Go & maintained as a no-modification fork of [wasmd](https://github.com/CosmWasm/wasmd)
|
||||
|
||||
The validator is a Go application which implements it's functionalities using [Cosmos SDK](https://v1.cosmos.network/sdk). The underlying state-replication engine is powered by [CometBFT](https://cometbft.com/), where the consensus mechanism is based on the [Tendermint Consensus Algorithm](https://arxiv.org/abs/1807.04938). Finally, a [CosmWasm](https://cosmwasm.com) smart contract module controls crucial mixnet functionalities like decentralised directory service, node bonding, and delegated mixnet staking.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
We are currently running mainnet with a closed set of reputable validators. To ensure decentralisation of Nyx chain, we are working on a mechanism to onboard new validators to the network. To join the waitlist, please drop an email to `validators [at] nymtech.net` with details of your setup, experience and any other relevent information
|
||||
</Callout>
|
||||
|
||||
## Building your validator
|
||||
|
||||
<VarInfo />
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Start with installing prerequisites needed for validator to work. Run following commands with root permissions or `sudo` prefix.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Install `git`, `gcc`, `jq`
|
||||
|
||||
* Debian-based systems:
|
||||
```sh
|
||||
apt install git build-essential jq
|
||||
```
|
||||
|
||||
* optional additional manual pages can be installed with:
|
||||
```sh
|
||||
apt-get install manpages-dev
|
||||
```
|
||||
|
||||
* Arch-based systems:
|
||||
Install `git`, `gcc` and `jq` with the following:
|
||||
```
|
||||
pacman -S git gcc jq
|
||||
```
|
||||
|
||||
###### 2. Install `Go` language
|
||||
|
||||
`Go` can be installed via the following commands (taken from the [Go Download and install page](https://go.dev/doc/install)):
|
||||
|
||||
- First remove any existing old Go installation and extract the archive you just downloaded into /usr/local:
|
||||
|
||||
```sh
|
||||
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.20.10.linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
- Then add /usr/local/go/bin to the PATH environment variable
|
||||
```sh
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
source $HOME/.profile
|
||||
```
|
||||
|
||||
- Verify `Go` is installed with:
|
||||
|
||||
```sh
|
||||
go version
|
||||
```
|
||||
|
||||
- Should return something like:
|
||||
```sh
|
||||
go version go1.20.10 linux/amd64
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
### Download a precompiled validator binary
|
||||
|
||||
You can find pre-compiled binaries for Ubuntu `22.04` and `20.04` [here](https://github.com/nymtech/nyxd/releases).
|
||||
|
||||
### Manually compiling your validator binary
|
||||
|
||||
The codebase for the Nyx validators can be found [here](https://github.com/nymtech/nyxd).
|
||||
|
||||
The validator binary can be compiled by running the following commands:
|
||||
```sh
|
||||
git clone https://github.com/nymtech/nyxd.git
|
||||
cd nyxd
|
||||
|
||||
# Make sure to check releases for the latest version information
|
||||
git checkout release/<NYXD_VERSION>
|
||||
|
||||
# Build the binaries
|
||||
make build
|
||||
```
|
||||
At this point, you will have a copy of the `nyxd` binary in your `build/` directory. Test that it's compiled properly by running:
|
||||
|
||||
```sh
|
||||
./build/nyxd
|
||||
```
|
||||
|
||||
You should see a similar help menu printed to you:
|
||||
<br />
|
||||
<AccordionTemplate name="Console output">
|
||||
```sh
|
||||
Nyx Daemon (server)
|
||||
|
||||
Usage:
|
||||
nyxd [command]
|
||||
|
||||
Available Commands:
|
||||
completion Generate the autocompletion script for the specified shell
|
||||
config Create or query an application CLI configuration file
|
||||
debug Tool for helping with debugging your application
|
||||
export Export state to JSON
|
||||
genesis Application's genesis-related subcommands
|
||||
help Help about any command
|
||||
init Initialize private validator, p2p, genesis, and application configuration files
|
||||
keys Manage your application's keys
|
||||
prune Prune app history states by keeping the recent heights and deleting old heights
|
||||
query Querying subcommands
|
||||
rollback rollback cosmos-sdk and tendermint state by one height
|
||||
rosetta spin up a rosetta server
|
||||
start Run the full node
|
||||
status Query remote node for status
|
||||
tendermint Tendermint subcommands
|
||||
testnet subcommands for starting or configuring local testnets
|
||||
tx Transactions subcommands
|
||||
version Print the application binary version information
|
||||
|
||||
Flags:
|
||||
-h, --help help for nyxd
|
||||
--home string directory for config and data
|
||||
--log_format string The logging format (json|plain) (default "plain")
|
||||
--log_level string The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
|
||||
--trace print out full stack trace on errors
|
||||
|
||||
Use "nyxd [command] --help" for more information about a command.
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
### Linking `nyxd` to `libwasmvm.so`
|
||||
|
||||
`libwasmvm.so` is the wasm virtual machine which is needed to execute smart contracts in `v0.26.1`. This file is renamed in `libwasmvm.x86_64.so` in `v0.31.1` and above.
|
||||
|
||||
If you downloaded your `nyxd` binary from Github, you will have seen this file when un-`tar`-ing the `.tar.gz` file from the releases page.
|
||||
|
||||
If you are seeing an error concerning this file when trying to run `nyxd`, then you need to move the `libwasmvm.x86_64.so` file to correct location.
|
||||
|
||||
Simply `cp` or `mv` that file to `/lib/x86_64-linux-gnu/` and re-run `nyxd`.
|
||||
|
||||
### Adding `nyxd` to your `$PATH`
|
||||
You'll need to set `LD_LIBRARY_PATH` in your user's `~/.bashrc` or `~/.zshrc` file (depends on the terminal you use), and add that to our path. Replace `/home/<USER>/<PATH-TO-NYM>/binaries` in the command below to the locations of `nyxd` and `libwasmvm.so` and run it. If you have compiled these on the server, they will be in the `build/` folder:
|
||||
|
||||
```sh
|
||||
NYX_BINARIES=<PATH>/<BINARY>
|
||||
```
|
||||
- If you are using another shell like zsh replace '.bashrc' with the relevant config file
|
||||
|
||||
```sh
|
||||
echo 'export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:'NYX_BINARIES >> ~/.bashrc
|
||||
echo 'export PATH=$PATH:'${NYX_BINARIES} >> ~/.bashrc
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
- Test everything worked:
|
||||
|
||||
```sh
|
||||
nyxd
|
||||
```
|
||||
|
||||
- This should return the regular help menu:
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name="Console output">
|
||||
```sh
|
||||
Nyx Daemon (server)
|
||||
|
||||
Usage:
|
||||
nyxd [command]
|
||||
|
||||
Available Commands:
|
||||
completion Generate the autocompletion script for the specified shell
|
||||
config Create or query an application CLI configuration file
|
||||
debug Tool for helping with debugging your application
|
||||
export Export state to JSON
|
||||
genesis Application's genesis-related subcommands
|
||||
help Help about any command
|
||||
init Initialize private validator, p2p, genesis, and application configuration files
|
||||
keys Manage your application's keys
|
||||
prune Prune app history states by keeping the recent heights and deleting old heights
|
||||
query Querying subcommands
|
||||
rollback rollback cosmos-sdk and tendermint state by one height
|
||||
rosetta spin up a rosetta server
|
||||
start Run the full node
|
||||
status Query remote node for status
|
||||
tendermint Tendermint subcommands
|
||||
testnet subcommands for starting or configuring local testnets
|
||||
tx Transactions subcommands
|
||||
version Print the application binary version information
|
||||
|
||||
Flags:
|
||||
-h, --help help for nyxd
|
||||
--home string directory for config and data
|
||||
--log_format string The logging format (json|plain) (default "plain")
|
||||
--log_level string The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
|
||||
--trace print out full stack trace on errors
|
||||
|
||||
Use "nyxd [command] --help" for more information about a command.
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
## Initialising your validator
|
||||
|
||||
### Prerequisites:
|
||||
|
||||
- FQDN Domain name
|
||||
- IPv4 and IPv6 connectivity
|
||||
|
||||
Choose a name for your validator and use it in place of `<ID>` in the following command:
|
||||
|
||||
```sh
|
||||
# Mainnet
|
||||
nyxd init <ID> --chain-id=nyx
|
||||
|
||||
# Sandbox testnet
|
||||
nyxd init <ID> --chain-id=sandbox
|
||||
```
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
`init` generates `priv_validator_key.json` and `node_key.json`.
|
||||
|
||||
If you have already set up a validator on a network, **make sure to back up the key located at**
|
||||
`~/.nyxd/config/priv_validator_key.json`.
|
||||
|
||||
If you don't save the validator key, then it can't sign blocks and will be jailed all the time, and
|
||||
there is no way to deterministically (re)generate this key.
|
||||
</Callout>
|
||||
|
||||
At this point, you have a new validator, with its own genesis file located at `$HOME/.nyxd/config/genesis.json`. You will need to replace the contents of that file that with either the Nyx Mainnet or Sandbox Testnet genesis file.
|
||||
|
||||
You can use the following command to download them for the correct network:
|
||||
|
||||
```sh
|
||||
# Mainnet
|
||||
wget -O $HOME/.nyxd/config/genesis.json https://nymtech.net/genesis/genesis.json
|
||||
|
||||
# Sandbox testnet
|
||||
curl https://rpc.sandbox.nymtech.net/snapshots/genesis.json | jq '.result.genesis' > $HOME/.nyxd/config/genesis.json
|
||||
```
|
||||
|
||||
### `config.toml` configuration
|
||||
|
||||
Edit the following config options in `$HOME/.nyxd/config/config.toml` to match the information below for your network:
|
||||
|
||||
- Mainnet:
|
||||
```sh
|
||||
persistent_peers = "ee03a6777fb76a2efd0106c3769daaa064a3fcb5@51.79.21.187:26656"
|
||||
laddr = "tcp://0.0.0.0:26656"
|
||||
```
|
||||
|
||||
- Sandbox testnet:
|
||||
```sh
|
||||
cors_allowed_origins = ["*"]
|
||||
persistent_peers = "26f7782aff699457c8e6dd9a845e5054c9b0707e@:3.72.19.120:26656"
|
||||
laddr = "tcp://0.0.0.0:26656"
|
||||
```
|
||||
|
||||
These affect the following:
|
||||
|
||||
* `persistent_peers = "<PEER_ADDRESS>@<DOMAIN>.nymtech.net:26666"` allows your validator to start pulling blocks from other validators. **The main sandbox validator listens on `26666` instead of the default `26656` for debugging**. It is recommended you do not change your port from `26656`.
|
||||
* `laddr = "tcp://0.0.0.0:26656"` is in your p2p configuration options
|
||||
|
||||
Optionally, if you want to enable [Prometheus](https://prometheus.io/) metrics then the following must also match in the `config.toml`:
|
||||
|
||||
- `prometheus = true`
|
||||
- `prometheus_listen_addr = ":26660"`
|
||||
|
||||
> Remember to enable metrics in the 'Configuring Prometheus metrics' section below as well.
|
||||
|
||||
And if you wish to add a human-readable moniker to your node:
|
||||
|
||||
- `moniker = "<YOUR_VALIDATOR_NAME>"`
|
||||
|
||||
Finally, if you plan on using [Cockpit](https://cockpit-project.org/documentation.html) on your server, change the `grpc` port from `9090` as this is the port used by Cockpit.
|
||||
|
||||
### `app.toml` configuration
|
||||
In the file `$HOME/.nyxd/config/app.toml`, set the following values:
|
||||
|
||||
- Mainnet
|
||||
```sh
|
||||
minimum-gas-prices = "0.025unym,0.025unyx"
|
||||
```
|
||||
|
||||
- Sandbox testnet:
|
||||
```sh
|
||||
minimum-gas-prices = "0.025unym,0.025unyx"
|
||||
```
|
||||
|
||||
### Setting up your validator's admin user
|
||||
You'll need an admin account to be in charge of your validator. Set that up with:
|
||||
|
||||
```sh
|
||||
nyxd keys add nyxd-admin
|
||||
```
|
||||
|
||||
<Callout title="Key Backends">
|
||||
Cosmos SDK offers multiple backends for securing your keys. Please refer to the Cosmos SDK [docs on available keyring backends](https://docs.cosmos.network/main/user/run-node/keyring#available-backends-for-the-keyring) to learn more
|
||||
</Callout>
|
||||
|
||||
While using the default settings, this will add keys for your account to your system's keychain and log your name, address, public key, and mnemonic. As the instructions say, remember to **write down your mnemonic**.
|
||||
|
||||
You can get the current account address with:
|
||||
|
||||
```sh
|
||||
nyxd keys show nyxd-admin -a
|
||||
```
|
||||
|
||||
Type in your keychain **password**, not the mnemonic, when asked.
|
||||
|
||||
## Starting your validator
|
||||
|
||||
Everything should now be ready to go. You've got the validator set up, all changes made in `config.toml` and `app.toml`, the Nym genesis file copied into place (replacing the initial auto-generated one). Now let's validate the whole setup:
|
||||
|
||||
```sh
|
||||
nyxd validate-genesis
|
||||
```
|
||||
|
||||
If this check passes, you should receive the following output:
|
||||
|
||||
```sh
|
||||
File at /path/to/genesis.json is a valid genesis file
|
||||
```
|
||||
|
||||
> If this test did not pass, check that you have replaced the contents of `/<PATH>/.nyxd/config/genesis.json` with that of the correct genesis file.
|
||||
|
||||
### Setting up nyxd as full node (non-signing)
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Skip this section if you're planning to run a validator node to join network consensus. To ensure security & maximum availability of validators, do not expose additional services to the Internet
|
||||
</Callout>
|
||||
|
||||
Unlike signing validators, full nodes do not propose / sign blocks. A full node is typically used for indexing blocks produced on the chain and for exposing web interfaces such as RPC, API and gRPC endpoints required for external applications/services to interact with the blockchain.
|
||||
|
||||
By default, API server is disabled and RPC/gRPC servers listen to the loopback address only. In a production setup, it is recommended to use a webserver such as Nginx or caddy to proxy requests to the endpoints as required.
|
||||
|
||||
To enable Cosmos REST API, you can enable it in `$HOME/.nyxd/config/app.toml` like :
|
||||
|
||||
```toml
|
||||
[api]
|
||||
|
||||
# Enable defines if the API server should be enabled. Toggle this to `true`
|
||||
enable = true
|
||||
|
||||
# Swagger defines if swagger documentation should automatically be registered.
|
||||
# You can also expose swagger documentation by toggling the below configuration to true
|
||||
swagger = true
|
||||
```
|
||||
|
||||
For more information on enabling access to various endpoints via Nginx, refer to the [example configuration here](./maintenance.md#setup)
|
||||
|
||||
### Open firewall ports
|
||||
|
||||
Before starting the validator, we will need to open the firewall ports:
|
||||
|
||||
```sh
|
||||
# if ufw is not already installed:
|
||||
sudo apt install ufw
|
||||
sudo ufw enable
|
||||
|
||||
# Customise according to your port bindings. This is only for reference
|
||||
# 26656 : p2p gossip port
|
||||
# 26660: If prometheus is enabled
|
||||
# 22 : Default SSH port
|
||||
sudo ufw allow 26656,26660,22
|
||||
|
||||
## !! FOR FULL NODES ONLY !! - exposing Nginx for serving web requests
|
||||
sudo ufw allow 80,443
|
||||
|
||||
# to check everything worked
|
||||
sudo ufw status
|
||||
```
|
||||
|
||||
For more information about your validator's port configuration, check the [validator port reference table](./maintenance.md#ports) below. These can be customised in `app.toml` and `config.toml` files.
|
||||
|
||||
> If you are planning to use [Cockpit](https://cockpit-project.org/) on your validator server then you will have defined a different `grpc` port in your `config.toml` above: remember to open this port as well.
|
||||
|
||||
Start the validator:
|
||||
|
||||
```sh
|
||||
nyxd start
|
||||
```
|
||||
|
||||
Once your validator starts, it will start requesting blocks from other validators. This may take several hours. Once it's up to date, you can issue a request to join the validator set with the command below.
|
||||
|
||||
### Syncing from a snapshot
|
||||
If you wish to sync from a snapshot on **mainnet** use Polkachu's [mainnet](https://polkachu.com/networks/nym) resources.
|
||||
|
||||
If you wish to sync from a snapshot on **Sandbox testnet** use the below commands, which are a modified version of Polkachu's excellent resources. These commands assume you are running an OS with `apt` as the package manager:
|
||||
|
||||
```sh
|
||||
# install lz4 if necessary
|
||||
sudo apt install snapd -y
|
||||
sudo snap install lz4
|
||||
|
||||
# download the snapshot
|
||||
wget -O nyxd-sandbox-snapshot-data.tar.lz4 https://rpc.sandbox.nymtech.net/snapshots/nyxd-sandbox-snapshot-data.tar.lz4
|
||||
|
||||
# reset your validator state
|
||||
nyxd tendermint unsafe-reset-all
|
||||
|
||||
# unpack the snapshot
|
||||
lz4 -c -d nyxd-sandbox-snapshot-data.tar.lz4 | tar -x -C $HOME/.nyxd
|
||||
```
|
||||
|
||||
You can then restart `nyxd` - it should start syncing from a block > 2000000.
|
||||
|
||||
### Joining Consensus
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
You can skip this section if you are planning to run a full-node. This step will make your node a signing validator which joins network consensus
|
||||
</Callout>
|
||||
|
||||
Once your validator has synced and you have received tokens, you can join consensus and produce blocks.
|
||||
|
||||
- Mainnet:
|
||||
```sh
|
||||
nyxd tx staking create-validator
|
||||
--amount=<10000000unyx>
|
||||
--pubkey=$(/home/<USER>/<PATH-TO>/nyxd/binaries/nyxd tendermint show-validator)
|
||||
--moniker="<YOUR_VALIDATOR_NAME>"
|
||||
--chain-id=nyx
|
||||
--commission-rate="0.10"
|
||||
--commission-max-rate="0.20"
|
||||
--commission-max-change-rate="0.01"
|
||||
--min-self-delegation="1"
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
--from=<"KEYRING_NAME">
|
||||
--node=https://rpc.nymtech.net:443
|
||||
```
|
||||
|
||||
- Sandbox Testnet:
|
||||
```sh
|
||||
nyxd tx staking create-validator
|
||||
--amount=<10000000unyx>
|
||||
--pubkey=$(/home/<USER>/<PATH-TO>/nym/binaries/nyxd tendermint show-validator)
|
||||
--moniker="<YOUR_VALIDATOR_NAME>"
|
||||
--chain-id=sandbox
|
||||
--commission-rate="0.10"
|
||||
--commission-max-rate="0.20"
|
||||
--commission-max-change-rate="0.01"
|
||||
--min-self-delegation="1"
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
--from=<"KEYRING_NAME">
|
||||
--node https://rpc.sandbox.nymtech.net:443
|
||||
```
|
||||
|
||||
You'll need Nyx tokens on mainnet / sandbox to perform the above tasks.
|
||||
|
||||
|
||||
If you want to edit some details for your node you will use a command like this:
|
||||
|
||||
- Mainnet:
|
||||
```sh
|
||||
nyxd tx staking edit-validator
|
||||
--chain-id=nyx
|
||||
--moniker="<YOUR_VALIDATOR_NAME>"
|
||||
--details="Nyx validator"
|
||||
--security-contact="<YOUR_EMAIL>"
|
||||
--identity="<YOUR_IDENTITY>"
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
--from="KEYRING_NAME"
|
||||
```
|
||||
|
||||
- Sandbox testnet
|
||||
```sh
|
||||
nyxd tx staking edit-validator
|
||||
--chain-id=sandbox
|
||||
--moniker="<YOUR_VALIDATOR_NAME>"
|
||||
--details="Sandbox testnet validator"
|
||||
--security-contact="your email"
|
||||
--identity="<YOUR_IDENTITY>"
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
--from="KEYRING_NAME"
|
||||
```
|
||||
|
||||
With above command you can specify the `gpg` key last numbers (as used in `keybase`) as well as validator details and your email for security contact.
|
||||
|
||||
### Automating your validator with systemd
|
||||
You will most likely want to automate your validator restarting if your server reboots. Checkout the [maintenance page](./maintenance.md#systemd) with a quick tutorial.
|
||||
|
||||
### Setting the ulimit
|
||||
|
||||
Linux machines limit how many open files a user is allowed to have. This is called a `ulimit`. We need to set it to a higher value than the default 1024. Follow the instructions in the [maintenance page](./maintenance.md#Setting-the-ulimit) to change the `ulimit` value for validators.
|
||||
|
||||
## Using your validator
|
||||
### Un-jailing your validator
|
||||
If your validator gets jailed, you can fix it with the following command:
|
||||
|
||||
- Mainnet:
|
||||
```sh
|
||||
nyxd tx slashing unjail
|
||||
--broadcast-mode=block
|
||||
--from="KEYRING_NAME"
|
||||
--chain-id=nyx
|
||||
--gas=auto
|
||||
--gas-adjustment=1.4
|
||||
--gas-prices=0.025unyx
|
||||
```
|
||||
|
||||
- Sandbox Testnet:
|
||||
```sh
|
||||
nyxd tx slashing unjail
|
||||
--broadcast-mode=block
|
||||
--from="KEYRING_NAME"
|
||||
--chain-id=sandbox
|
||||
--gas=auto
|
||||
--gas-adjustment=1.4
|
||||
--gas-prices=0.025unyx
|
||||
```
|
||||
|
||||
### Upgrading your validator
|
||||
|
||||
To upgrade your validator, follow the steps on the [maintenance page](./maintenance.md#setting-the-ulimit).
|
||||
|
||||
#### Common reasons for your validator being jailed
|
||||
|
||||
Your validator will be jailed if your node:
|
||||
- misses _`x`_ amount of blocks in _`y`_ interval, where _`x`_ and _`y`_ are parameters set by chain governance
|
||||
- performs double signing (two conflicting signatures on the same block using the same key)
|
||||
|
||||
Double signing is a serious infraction. If a node double signs, all the delegators to the node (including self-delegation) will be slashed by 5%. Additionally, the node will be permanently jailed and removed from consensus (called _tombstoning_)
|
||||
|
||||
One of the most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.
|
||||
|
||||
Running the command `df -H` will return the size of the various partitions of your VPS. If the partition with blockchain data is almost full, try pruning the blockchain data or expanding the storage size.
|
||||
|
||||
### Day 2 operations with your validator
|
||||
|
||||
You can check your current balances with:
|
||||
|
||||
```sh
|
||||
nyxd query bank balances ${ADDRESS}
|
||||
```
|
||||
|
||||
For example, on the Sandbox testnet this would return:
|
||||
|
||||
```yaml
|
||||
balances:
|
||||
- amount: "919376"
|
||||
denom: unym
|
||||
pagination:
|
||||
next_key: null
|
||||
total: "0"
|
||||
```
|
||||
|
||||
You can, of course, stake back the available balance to your validator with the following command.
|
||||
|
||||
> **Remember to save some tokens for gas costs!**
|
||||
|
||||
- Mainnet:
|
||||
```sh
|
||||
nyxd tx staking delegate VALOPERADDRESS AMOUNTunyx
|
||||
--from="KEYRING_NAME"
|
||||
--keyring-backend=os
|
||||
--chain-id=nyx
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
```
|
||||
|
||||
- Sandbox Testnet:
|
||||
```sh
|
||||
nyxd tx staking delegate VALOPERADDRESS AMOUNTunyx
|
||||
--from="KEYRING_NAME"
|
||||
--keyring-backend=os
|
||||
--chain-id=sandbox
|
||||
--gas="auto"
|
||||
--gas-adjustment=1.15
|
||||
--gas-prices=0.025unyx
|
||||
```
|
||||
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"nym-api": "Nym API Setup",
|
||||
"nyx-configuration": "Nyx Validator & NymAPI Config"
|
||||
}
|
||||
@@ -1,304 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import {Accordion, AccordionItem} from "@nextui-org/react";
|
||||
import ApiBuildInfo from 'components/outputs/command-outputs/nym-api-build-info.md';
|
||||
import NymApiHelp from 'components/outputs/command-outputs/nym-api-help.md';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
# Nym API Setup
|
||||
|
||||
> The nym-api binary was built in the [building nym](../../binaries/building-nym.mdx) section. If you haven't yet built Nym and want to run the code, go there first. You can build just the API with `cargo build --release --bin nym-api`.
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## What is the Nym API?
|
||||
|
||||
The Nym API is a binary that will be operated by the Nyx validator set. This binary can be run in several different modes, and has two main bits of functionality:
|
||||
|
||||
* Network monitoring (calculating the routing score of Mixnet nodes)
|
||||
* Generation and validation of [zk-nyms](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a), our implementation of the Coconut Selective Disclosure Credential Scheme.
|
||||
|
||||
This is important for both the proper decentralisation of the network uptime calculation and, more pressingly, enabling the NymVPN to utilise privacy preserving payments.
|
||||
|
||||
The process of enabling these different aspects of the system will take time. At the moment, Nym API operators will only have to run the binary in a minimal 'caching' mode in order to get used to maintaining an additional process running alongside a full node.
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
It is highly recommended to run `nym-api` alongside a full node and NOT a validator node, since you will be exposing HTTP port(s) to the Internet. We also observed degradation in p2p and block signing operations when `nym-api` was run alongside a signing validator.
|
||||
</Callout>
|
||||
|
||||
### Rewards
|
||||
|
||||
Operators of Nym API will be rewarded for performing the extra work of taking part in credential generation. These rewards will be calculated **separately** from rewards for block production.
|
||||
|
||||
Rewards for credential signing will be calculated hourly, with API operators receiving a proportional amount of the reward pool (333NYM per hour / 237,600 NYM per month), proportional to the percentage of credentials they have signed.
|
||||
|
||||
### Hardware Requirements
|
||||
|
||||
The specification mentioned below is for running a full node alongside the nym-api. It is recommended to run `nym-api` and a full Nyx node on the same machine for optimum performance.
|
||||
|
||||
Bear in mind that credential signing is primarily CPU-bound, so choose the fastest CPU available to you.
|
||||
|
||||
#### Minimum Requirements
|
||||
|
||||
| Hardware | Minimum Specification |
|
||||
|----------|--------------------------------------------|
|
||||
| CPU | 8-cores, 2.8GHz base clock speed or higher |
|
||||
| RAM | 16GB DDR4+ |
|
||||
| Disk | 500 GiB+ NVMe SSD |
|
||||
|
||||
#### Recommended Requirements
|
||||
|
||||
| Hardware | Minimum Specification |
|
||||
|----------|---------------------------------------------|
|
||||
| CPU | 16-cores, 2.8GHz base clock speed or higher |
|
||||
| RAM | 32GB DDR4+ |
|
||||
| Disk | 1 TiB+ NVMe SSD |
|
||||
|
||||
### Full node configuration
|
||||
|
||||
To install a full node from scratch, refer to the [validator setup guide](../validator-setup.mdx) and follow the steps outlined there.
|
||||
|
||||
Additionally, to ensure `nym-api` works as expected, ensure the configuration is as below:
|
||||
|
||||
<Steps>
|
||||
|
||||
1. ###### Ensure transaction index is turned on in your `config.toml`:
|
||||
|
||||
```toml
|
||||
[tx_index]
|
||||
|
||||
# Ensure that this is not set to "null". You're free to use any indexer
|
||||
|
||||
indexer = "kv"
|
||||
```
|
||||
|
||||
2. ###### Ensure pruning settings are manually configured
|
||||
|
||||
`nym-api` needs to check validity of user-submitted transactions (in the past) while issuing credentials and as part of double-spend check. Hence, aggressively pruning data will lead to errors with your `nym-api`
|
||||
|
||||
Make sure your pruning settings are configured as below in `app.toml`:
|
||||
|
||||
```toml
|
||||
pruning = "custom"
|
||||
|
||||
# This number is likely to be updated once zk-nym signing goes live
|
||||
pruning-keep-recent = "750000"
|
||||
pruning-interval = "100"
|
||||
```
|
||||
|
||||
The example value of `100` for `pruning-interval` can be customised as per your requirement.
|
||||
|
||||
</Steps>
|
||||
|
||||
### Credential Generation
|
||||
|
||||
Validators that took part in the DKG ceremony became part of the 'quorum' generating and verifying zk-nym credentials. These will initially be used for private proof of payment for NymVPN (see our blogposts [here](https://blog.nymtech.net/nymvpn-an-invitation-for-privacy-experts-and-enthusiasts-63644139d09d) and [here](https://blog.nymtech.net/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet-a3470c9ab10a) for more on this), and in the future will be expanded into more general use-cases such as [offline ecash](https://arxiv.org/abs/2303.08221).
|
||||
|
||||
The DKG ceremony was used to create a subset of existing validators who run `nym-api` alongside a Nyx full-node. As outlined above, they are the ones taking part in the generation and verification of zk-nym credentials. The size of the 'minimum viable quorum' is 10 - the intial set taking part in DKG was 17 validators. This is in order to have some redundancy in the case of a validator dropping or going offline.
|
||||
|
||||
DKG ceremony in points:
|
||||
|
||||
* The deployment and initialisation of [`group`](https://github.com/nymtech/nym/tree/develop/contracts/multisig/cw4-group) and [`multisig`](https://github.com/nymtech/nym/tree/develop/contracts/multisig) contracts by Nym. Validators that are members of the `group` contract are the only ones that were able to take part in the ceremony.
|
||||
* The deployment and initialisation of an instance of the [DKG contract](https://github.com/nymtech/nym/tree/develop/contracts/coconut-dkg) by Nym.
|
||||
* Validators updated their `nym-api` configs with the address of the deployed contracts. They also stopped running their API instance in caching only mode, instead switching over run with the `--enabled-credentials-mode`.
|
||||
* From the perspective of validator operators, this is all they had to do. Under the hood, each `nym-api` instance then took part in several rounds of key submission, verification, and derivation. This will continue until quorum is acheived.
|
||||
|
||||
## Current version
|
||||
|
||||
<ApiBuildInfo />
|
||||
|
||||
## Setup and Usage
|
||||
|
||||
### Viewing command help
|
||||
You can check that your binary is properly compiled with:
|
||||
|
||||
```bash
|
||||
./nym-api --help
|
||||
```
|
||||
|
||||
Which should return a list of all available commands.
|
||||
|
||||
<NymApiHelp />
|
||||
|
||||
You can also check the various arguments required for individual commands with:
|
||||
|
||||
```bash
|
||||
./nym-api <COMMAND> --help
|
||||
```
|
||||
|
||||
### Initialising your Nym API Instance in caching mode
|
||||
|
||||
Initialise your API instance with:
|
||||
|
||||
```bash
|
||||
./nym-api init
|
||||
```
|
||||
|
||||
You can optionally pass a local identifier for this instance with the `--id` flag. Otherwise the ID of your instance defaults to `default`.
|
||||
|
||||
### Enabling credential signing on your Nym API instance
|
||||
|
||||
To engage in the Distributed Key Generation (DKG) ceremony, it's essential to transition your `nym-api` instance from its default caching mode to the active credential signing mode. This section guides you through the process of enabling credential signing
|
||||
|
||||
#### Generate a new wallet
|
||||
|
||||
Begin by generating a new wallet address specifically for your instance to use in credential signing mode. Utilize the `nyxd` command-line tool with the following command:
|
||||
|
||||
```bash
|
||||
nyxd keys add signer
|
||||
```
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
It's critical to securely back up the mnemonic phrase generated during this process. This mnemonic is your key to recovering the wallet in the future, so store it in a secure, offline location.
|
||||
</Callout>
|
||||
|
||||
#### Fund the address
|
||||
|
||||
Next, deposit NYM tokens into the newly created wallet address to ensure it can cover transaction fees incurred during the credential signing process. `nym-api` will not operate if the wallet's balance falls below 10 NYM tokens, displaying an error message upon startup.
|
||||
|
||||
We recommend beginning with an initial deposit of 100 NYM tokens and monitoring the balance regularly, topping it up as necessary to maintain operational readiness.
|
||||
|
||||
#### Update API configuration
|
||||
|
||||
With your new wallet ready and funded, proceed to update your `nym-api` configuration to enable credential signing:
|
||||
|
||||
Update your `config.toml` located in `$HOME/.nym/nym-api/foo/config/config.toml` as below:
|
||||
|
||||
Enable the coconut signer:
|
||||
|
||||
```toml
|
||||
[coconut_signer]
|
||||
# Specifies whether coconut signing protocol is enabled in this process.
|
||||
enabled = true # This was previously false
|
||||
```
|
||||
|
||||
Set your announce address if it is empty. This is the URL you previously configured for your `nym-api` instance
|
||||
|
||||
```toml
|
||||
# This is the address you previously configured for the nym-api
|
||||
# Not to be confused with the Cosmos REST API URL
|
||||
announce_address = 'https://nym-api.your.tld/'
|
||||
```
|
||||
|
||||
Finally, input the mnemonic phrase generated during the wallet creation step into the mnemonic field
|
||||
|
||||
```toml
|
||||
mnemonic = '<YOUR_MNEMONIC>'
|
||||
```
|
||||
|
||||
After completing these steps, your `nym-api` instance is configured to participate in credential signing and the DKG ceremony.
|
||||
|
||||
### Running your Nym API Instance
|
||||
|
||||
The API binary currently defaults to running in caching mode. You can run your API with:
|
||||
|
||||
```bash
|
||||
./nym-api run --id <ID>
|
||||
```
|
||||
|
||||
By default the API will be trying to query your full node running locally on `localhost:26657`. If your node is hosted elsewhere, you can specify the RPC location by using the `--nyxd-validator ` flag on `run`:
|
||||
|
||||
```bash
|
||||
./nym-api run --id <ID> --nyxd-validator https://rpc-nym.yourcorp.tld:443
|
||||
```
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
You can also change the value of `local_validator` in the config file found by default in `$HOME/.nym/nym-api/<ID>/config/config.toml`.
|
||||
</Callout>
|
||||
|
||||
This process is quite noisy, but informative:
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name="Console output">
|
||||
```bash
|
||||
Starting nym api...
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch > 🔧 Configured for release.
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > address: 127.0.0.1
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > port: 8000
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > workers: 4
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > max blocking threads: 512
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > ident: Rocket
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > IP header: X-Real-IP
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > temp dir: /tmp
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > http/2: true
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > keep-alive: 5s
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > tls: disabled
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > shutdown: ctrlc = true, force = true, signals = [SIGTERM], grace = 2s, mercy = 3s
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > log level: critical
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > cli colors: true
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch > 📬 Routes:
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_registered_names) GET /v1/names
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes) GET /v1/mixnodes
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_gateways) GET /v1/gateways
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_services) GET /v1/services
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /v1/openapi.json
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_full_circulating_supply) GET /v1/circulating-supply
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_current_epoch) GET /v1/epoch/current
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set) GET /v1/mixnodes/active
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes_detailed) GET /v1/mixnodes/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set) GET /v1/mixnodes/rewarded
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_gateways_described) GET /v1/gateways/described
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_interval_reward_params) GET /v1/epoch/reward_params
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_blacklisted_mixnodes) GET /v1/mixnodes/blacklisted
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_blacklisted_gateways) GET /v1/gateways/blacklisted
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_total_supply) GET /v1/circulating-supply/total-supply-value
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_circulating_supply) GET /v1/circulating-supply/circulating-supply-value
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set_detailed) GET /v1/mixnodes/active/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set_detailed) GET /v1/mixnodes/rewarded/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /cors/<status>
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/index.css
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/index.html
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui.css
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/oauth2-redirect.html
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-bundle.js
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-config.json
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-initializer.js
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > GET /swagger/swagger-ui-standalone-preset.js
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnodes_detailed) GET /v1/status/mixnodes/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_inclusion_probabilities) GET /v1/status/mixnodes/inclusion_probability
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_status) GET /v1/status/mixnode/<mix_id>/status
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_active_set_detailed) GET /v1/status/mixnodes/active/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_rewarded_set_detailed) GET /v1/status/mixnodes/rewarded/detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_stake_saturation) GET /v1/status/mixnode/<mix_id>/stake-saturation
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (get_mixnode_inclusion_probability) GET /v1/status/mixnode/<mix_id>/inclusion-probability
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (network_details) GET /v1/network/details
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (nym_contracts) GET /v1/network/nym-contracts
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > (nym_contracts_detailed) GET /v1/network/nym-contracts-detailed
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch > 📡 Fairings:
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Validator Cache Stage (ignite)
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Circulating Supply Cache Stage (ignite)
|
||||
2023-12-12T14:29:55.800Z INFO rocket::launch::_ > Shield (liftoff, response, singleton)
|
||||
2023-12-12T14:29:55.801Z INFO rocket::launch::_ > CORS (ignite, request, response)
|
||||
2023-12-12T14:29:55.801Z INFO rocket::launch::_ > Node Status Cache (ignite)
|
||||
2023-12-12T14:29:55.801Z INFO rocket::shield::shield > 🛡️ Shield:
|
||||
2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > X-Content-Type-Options: nosniff
|
||||
2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > X-Frame-Options: SAMEORIGIN
|
||||
2023-12-12T14:29:55.801Z INFO rocket::shield::shield::_ > Permissions-Policy: interest-cohort=()
|
||||
2023-12-12T14:29:55.801Z WARN rocket::launch > 🚀 Rocket has launched from http://127.0.0.1:8000
|
||||
2023-12-12T14:29:56.375Z INFO nym_api::nym_contract_cache::cache::refresher > Updating validator cache. There are 888 mixnodes and 105 gateways
|
||||
2023-12-12T14:29:56.375Z INFO nym_api::node_status_api::cache::refresher > Updating node status cache
|
||||
2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > Updating circulating supply cache
|
||||
2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the mixmining reserve is now 220198535489690unym
|
||||
2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the number of tokens still vesting is now 145054386857730unym
|
||||
2023-12-12T14:29:57.359Z INFO nym_api::circulating_supply_api::cache > the circulating supply is now 634747077652580unym
|
||||
2023-12-12T14:30:00.803Z INFO nym_api::support::caching::refresher > node-self-described-data-refresher: refreshing cache state
|
||||
2023-12-12T14:31:56.290Z INFO nym_api::nym_contract_cache::cache::refresher > Updating validator cache. There are 888 mixnodes and 105 gateways
|
||||
2023-12-12T14:31:56.291Z INFO nym_api::node_status_api::cache::refresher > Updating node status cache
|
||||
```
|
||||
</AccordionTemplate>
|
||||
|
||||
## Automation
|
||||
|
||||
You will most likely want to automate your validator restarting if your server reboots. Checkout the [maintenance page](nyx-configuration.mdx#nym-api-systemd-automation) for an example `service` file.
|
||||
|
||||
You can also use `nymvisor` to automatically update the `nym-api` node. The steps to install Nymvisor can be found [here](../maintenance/nymvisor-upgrade.mdx).
|
||||
|
||||
## Exposing web endpoint using HTTPS
|
||||
It is recommended to expose the webserver over HTTPS by using a webserver like Nginx. An example configuration for configuring Nginx is listed on [Reverse proxy page](../nym-node/configuration/proxy-configuration.mdx). If you're using a custom solution, ensure to allow requests from anywhere by setting a permissive CORS policy.
|
||||
|
||||
For example, it is configured in Nginx using: `add_header 'Access-Control-Allow-Origin' '*';`
|
||||
|
||||
@@ -1,327 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import {Accordion, AccordionItem} from "@nextui-org/react";
|
||||
|
||||
# Nyx Validator & Nym API Configuration
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Automation
|
||||
|
||||
### Validator `systemd` Automation
|
||||
|
||||
To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nymd.service` and follow the steps below running all commands with root permissions (root shell or `sudo` prefix).
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create an init service file
|
||||
|
||||
- Open text editor
|
||||
|
||||
```sh
|
||||
nano /etc/systemd/system/nymd.service
|
||||
```
|
||||
|
||||
- Paste this file
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Nyxd
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=<USER> # change to your user
|
||||
Type=simple
|
||||
Environment="LD_LIBRARY_PATH=<PATH>" # change to correct path
|
||||
ExecStart=<PATH>/nymd start # change to correct path
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
LimitNOFILE=infinity
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
###### 2. Start validator as `systemd` service
|
||||
|
||||
- To pick up new unit file, run:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
- Enable the service:
|
||||
|
||||
```sh
|
||||
systemctl enable nymd
|
||||
```
|
||||
|
||||
- Start the service:
|
||||
|
||||
```sh
|
||||
systemctl start nymd
|
||||
```
|
||||
|
||||
- Optionally you can monitor status logs by running:
|
||||
```sh
|
||||
journalctl -f -u nymd
|
||||
```
|
||||
|
||||
###### 3. If you make any changes to your `systemd` script after you've enabled it
|
||||
|
||||
- You need to run:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
This lets your operating system know it's ok to reload the service configuration. Then restart your validator.
|
||||
|
||||
</Steps>
|
||||
|
||||
### Nym API `systemd` Automation
|
||||
|
||||
|
||||
To automate with `systemd` use this init service file by saving it as `/etc/systemd/system/nym-api.service` and follow the steps below running all commands with root permissions (root shell or `sudo` prefix).
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create an init service file
|
||||
|
||||
- Open text editor
|
||||
```sh
|
||||
nano /etc/systemd/system/nym-api.service
|
||||
```
|
||||
|
||||
- Paste this file
|
||||
```ini
|
||||
[Unit]
|
||||
Description=NymAPI
|
||||
StartLimitInterval=350
|
||||
StartLimitBurst=10
|
||||
|
||||
[Service]
|
||||
User=<USER> # change to your user
|
||||
Type=simple
|
||||
ExecStart=<PATH>/nym-api start # change to correct path
|
||||
Restart=on-failure
|
||||
RestartSec=30
|
||||
LimitNOFILE=infinity
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
###### 2. Start your API as `systemd` service
|
||||
|
||||
- To pick up new unit file, run:
|
||||
```sh
|
||||
systemctl daemon-reload # to pickup the new unit file
|
||||
```
|
||||
|
||||
- Enable the service:
|
||||
```sh
|
||||
systemctl enable nym-api # to enable the service
|
||||
```
|
||||
|
||||
- Start the service:
|
||||
```sh
|
||||
systemctl start nym-api # to actually start the service
|
||||
```
|
||||
|
||||
- Optionally you can monitor status logs by running:
|
||||
```sh
|
||||
journalctl -f -u nym-api # to monitor system logs showing the service start
|
||||
```
|
||||
|
||||
**Note:** if you make any changes to your `systemd` script after you've enabled it, you will need to run:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
###### 3. If you make any changes to your `systemd` script after you've enabled it
|
||||
|
||||
- You need to run:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
This lets your operating system know it's ok to reload the service configuration. Then restart your API.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Nym API (previously 'Validator API') endpoints
|
||||
|
||||
Numerous API endpoints are documented on the Nym API (previously 'Validator API')'s [Swagger Documentation](https://validator.nymtech.net/api/swagger/index.html). There you can also try out various requests from your browser, 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.
|
||||
|
||||
```sh
|
||||
sudo ufw allow 'Nginx Full'
|
||||
```
|
||||
|
||||
Check nginx is running via systemctl:
|
||||
|
||||
```sh
|
||||
systemctl status nginx
|
||||
```
|
||||
|
||||
Which should return:
|
||||
|
||||
```sh
|
||||
● nginx.service - A high performance web server and a reverse proxy server
|
||||
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Fri 2018-04-20 16:08:19 UTC; 3 days ago
|
||||
Docs: man:nginx(8)
|
||||
Main PID: 2369 (nginx)
|
||||
Tasks: 2 (limit: 1153)
|
||||
CGroup: /system.slice/nginx.service
|
||||
├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
|
||||
└─2380 nginx: worker process
|
||||
```
|
||||
|
||||
## Full Node Configuration
|
||||
|
||||
Proxying various full node services through port 80 can then be done by creating a file with the following at `/etc/nginx/sites-enabled/nyxd-webrequests.conf`:
|
||||
|
||||
Setting up a reverse proxy using a webserver such as Nginx allows you to easily configure SSL certificates for the endpoints. When running on mainnet, it is recommended to encrypt all web traffic to your node.
|
||||
|
||||
```sh
|
||||
### To expose RPC server
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
server_name "<rpc.nyx.yourdomain.tld>";
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:26657;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
}
|
||||
|
||||
location /websocket {
|
||||
proxy_pass http://127.0.0.1:26657;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection "Upgrade";
|
||||
proxy_set_header Host $host;
|
||||
}
|
||||
}
|
||||
|
||||
### To expose Cosmos API server
|
||||
server {
|
||||
server_name "<api.nyx.yourdomain.tld>";
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:1317;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
proxy_set_header Host $http_host;
|
||||
proxy_set_header Upgrade websocket;
|
||||
proxy_set_header Connection Upgrade;
|
||||
}
|
||||
}
|
||||
|
||||
### To expose GRPC endpoint
|
||||
server {
|
||||
server_name "<grpc.nyx.yourdomain.tld>";
|
||||
location / {
|
||||
grpc_pass 127.0.0.1:9090;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## nym-api Configuration
|
||||
|
||||
```sh
|
||||
### To expose nym-api webserver
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
server_name "<nym-api.nyx.yourdomain.tld>";
|
||||
add_header 'Access-Control-Allow-Origin' '*';
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8000;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Followed by:
|
||||
|
||||
```sh
|
||||
sudo apt install certbot nginx python3
|
||||
certbot --nginx -m <EMAIL> --agree-tos
|
||||
```
|
||||
|
||||
<Callout>
|
||||
If using a VPS running Ubuntu 20: replace `certbot nginx python3` with `python3-certbot-nginx`
|
||||
</Callout>
|
||||
|
||||
These commands will get you an https encrypted nginx proxy in front of the various endpoints.
|
||||
|
||||
## Configuring Prometheus metrics (optional)
|
||||
|
||||
Configure Prometheus with the following commands (adapted from NodesGuru's [Agoric setup guide](https://nodes.guru/agoric/setup-guide/en)):
|
||||
|
||||
```sh
|
||||
echo 'export OTEL_EXPORTER_PROMETHEUS_PORT=9464' >> $HOME/.bashrc
|
||||
source ~/.bashrc
|
||||
sed -i '/\[telemetry\]/{:a;n;/enabled/s/false/true/;Ta}' $HOME/.nymd/config/app.toml
|
||||
sed -i "s/prometheus-retention-time = 0/prometheus-retention-time = 60/g" $HOME/.nymd/config/app.toml
|
||||
sudo ufw allow 9464
|
||||
echo 'Metrics URL: http://'$(curl -s ifconfig.me)':26660/metrics'
|
||||
```
|
||||
|
||||
Your validator's metrics will be available to you at the returned 'Metrics URL'.
|
||||
|
||||
```sh
|
||||
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
|
||||
# TYPE go_gc_duration_seconds summary
|
||||
go_gc_duration_seconds{quantile="0"} 6.7969e-05
|
||||
go_gc_duration_seconds{quantile="0.25"} 7.864e-05
|
||||
go_gc_duration_seconds{quantile="0.5"} 8.4591e-05
|
||||
go_gc_duration_seconds{quantile="0.75"} 0.000115919
|
||||
go_gc_duration_seconds{quantile="1"} 0.001137591
|
||||
go_gc_duration_seconds_sum 0.356555301
|
||||
go_gc_duration_seconds_count 2448
|
||||
# HELP go_goroutines Number of goroutines that currently exist.
|
||||
# TYPE go_goroutines gauge
|
||||
go_goroutines 668
|
||||
# HELP go_info Information about the Go environment.
|
||||
# TYPE go_info gauge
|
||||
go_info{version="go1.15.7"} 1
|
||||
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
|
||||
# TYPE go_memstats_alloc_bytes gauge
|
||||
go_memstats_alloc_bytes 1.62622216e+08
|
||||
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
|
||||
# TYPE go_memstats_alloc_bytes_total counter
|
||||
go_memstats_alloc_bytes_total 2.09341707264e+11
|
||||
# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
|
||||
# TYPE go_memstats_buck_hash_sys_bytes gauge
|
||||
go_memstats_buck_hash_sys_bytes 5.612319e+06
|
||||
# HELP go_memstats_frees_total Total number of frees.
|
||||
# TYPE go_memstats_frees_total counter
|
||||
go_memstats_frees_total 2.828263344e+09
|
||||
# HELP go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started.
|
||||
# TYPE go_memstats_gc_cpu_fraction gauge
|
||||
go_memstats_gc_cpu_fraction 0.03357798610671518
|
||||
# HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.
|
||||
# TYPE go_memstats_gc_sys_bytes gauge
|
||||
go_memstats_gc_sys_bytes 1.3884192e+07
|
||||
```
|
||||
|
||||
|
||||
## Validator port reference
|
||||
|
||||
All validator-specific port configuration can be found in `$HOME/.nymd/config/config.toml`. If you do edit any port configs, remember to restart your validator.
|
||||
|
||||
| Default port | Use |
|
||||
|--------------|--------------------------------------|
|
||||
| 1317 | REST API server endpoint |
|
||||
| 26656 | Listen for incoming peer connections |
|
||||
| 26660 | Listen for Prometheus connections |
|
||||
|
||||
@@ -1,93 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Release Cycle
|
||||
|
||||
Nym operator community is growing in quality and quantity. With node operators and developers joining the effort to make the Mixnet more robust and scalable, testing new features, sharing integration pull requests and generally taking an active part in Nym development, more transparency on the release cycle is required.
|
||||
|
||||
The core team therefore established a flow with different environments:
|
||||
|
||||
- ***local***: Developers use their local environments for feature building
|
||||
- ***canary***: Nym internal testing environment managed by Qualtiy Assurance team (QA)
|
||||
- [***sandbox***](sandbox.mdx): Public testnet, including testnet NYM token available in the [faucet](sandbox.mdx#sandbox-token-faucet)
|
||||
- ***mainnet***: Nym Mixnet - the production version of Nym network
|
||||
|
||||
## Release Flow
|
||||
|
||||
Frequency of releases to mainnet is aimed to be every ~14 days. This time window is an optimal compromise between periodicity and quality assurance/testing, key factors playing an essential role in development.
|
||||
|
||||
| **Stage** | **Environment** | **Branch** | **Ownership** |
|
||||
| :-- | :-- | :-- | :-- |
|
||||
| development work | local/canary | feature branches | devs |
|
||||
| cut and test release | canary | release branch | QA |
|
||||
| bug fixing | canary | directly on release branch | QA & devs |
|
||||
| put release on sandbox | sandbox | release -> master/develop | QA |
|
||||
| promote release to mainnet after 3-5 days | mainnet | master | QA |
|
||||
|
||||
```ascii
|
||||
▲ ▲
|
||||
│ │
|
||||
│ merge back into develop │
|
||||
MAINNET ├─────────────────────────►│
|
||||
easy │ │
|
||||
autopromotion│ │
|
||||
▲ │ │
|
||||
│ │ │
|
||||
│ │ │◄───────────────────────────────┐
|
||||
│ │ │ │
|
||||
└───release │ │ │
|
||||
to x◄───────────────┐ │ │
|
||||
sandbox ▲ │ │◄────────────────────────┐ │
|
||||
│ ┌────────────► │ │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ bug │ │ │ │
|
||||
│ │ fix │ │◄─────────────────┐ │ │
|
||||
│ │ │ │ │ │ │
|
||||
│ │ │ │ M │ │ │
|
||||
│ └────────────┤ │ I │ │ │
|
||||
│ │ │ L │ │ │
|
||||
│ └─────────x E │ │ │
|
||||
│ release ▲ S │ │ │
|
||||
^ │ cut │ T │ │ │
|
||||
: │ --- │ O │ │ │
|
||||
: │ fixed │ N │ │ │
|
||||
: │ release │ E │ │ │
|
||||
: │ every │ feature-bob3 │ │ │
|
||||
: │ 14 days ├──────────────────┘ │ │
|
||||
: │ │ │ │
|
||||
: │ │ │ │
|
||||
: │ │ feature-bob2 │ │
|
||||
: │ ├─────────────────────────┘ │
|
||||
: │ │ │
|
||||
: │ │ │
|
||||
: │ │ feature-bob1 │
|
||||
: │ ├────────────────────────────────┘
|
||||
: │ │
|
||||
: │ │
|
||||
:t │ │
|
||||
:i │ │
|
||||
:m │ │
|
||||
:e │ │
|
||||
|
||||
master develop feature branches
|
||||
|
||||
ENVs
|
||||
┌─────────┬────────┬──────────────────────────┬─────────────────────────────────┐
|
||||
│mainnet │sandbox │ QA / canary │ development │
|
||||
│ │ │ │ │
|
||||
└─────────┴────────┴──────────────────────────┴─────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Changes & Collaboration
|
||||
|
||||
To track changes easily, builders and operators can visit one of the following:
|
||||
|
||||
- [*CHANGELOG.md*](https://github.com/nymtech/nym/blob/master/CHANGELOG.md): Raw changelog of merged feauters in Nym's monorepo, managed by devs and QA.
|
||||
- [*Changelog page*](changelog.mdx): A detailed explanation, testing steps and updated summary of documentation changes, managed by devrels.
|
||||
|
||||
In case you want to propose changes or resolve some of the existing [issues](https://github.com/nymtech/nym/issues), start [here](https://github.com/nymtech/nym/issues/new/choose). If you want to add content to the Operators Guide, visit [this page](community-counsel/add-content.mdx).
|
||||
|
||||
<Callout>
|
||||
Feature tickets need explicit (while concise) wording because that title is eventually added to the changelog. Keep in mind that bad ticket naming results in bad changelog.
|
||||
|
||||
If you want to run in the testing environment, follow our [Sandbox testnet](sandbox.mdx) guide.
|
||||
</Callout>
|
||||
@@ -1,71 +0,0 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';import { Tabs } from 'nextra/components'
|
||||
|
||||
# Sandbox Testnet
|
||||
|
||||
Nym node operators can run their nodes in Nym Sandbox testnet environment. Whether it's testing new configuration, hot features from Nym developers or just trying to setup a node for the first time, this environment is for you.
|
||||
|
||||
Below are steps to [setup your environment](#sandbox-environment-setup) and an introduction to [Sandbox token faucet](#sandbox-token-faucet).
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
This page is for Nym node operators. If you want to run NymVPN CLI over Sandbox testnet, visit [NymVPN CLI Testnet guide](https://nym-vpn-cli.sandbox.nymtech.net/).
|
||||
</Callout>
|
||||
|
||||
## Sandbox Environment Setup
|
||||
|
||||
<VarInfo/ >
|
||||
|
||||
To run Nym binaries in Sandbox testnet, you need to get `sandbox.env` configuration file and point your binary to it. Follow the steps below:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Create Sandbox environment config file by saving [this](https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env) as `sandbox.env` in the same directory as your binaries:
|
||||
```sh
|
||||
curl -o sandbox.env -L https://raw.githubusercontent.com/nymtech/nym/develop/envs/sandbox.env
|
||||
```
|
||||
- In case you want to save the file elsewhere, change the path in '-o' flag
|
||||
|
||||
###### 2. Run your `nym-node` with an additional flag `-c` or `--config-env-file`
|
||||
- Specify a path to `sandbox.env`
|
||||
- Add all needed commands and options - for example:
|
||||
|
||||
<Tabs items={[<code>mixnode</code>, <code>exit-gateway</code>]}>
|
||||
<Tabs.Tab>
|
||||
This example is for `nym-node --mode mixnode`.
|
||||
```sh
|
||||
./nym-node --config-env-file <PATH>/sandbox.env run --mode mixnode
|
||||
```
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
This example is for `nym-node --mode exit-gateway`.
|
||||
```sh
|
||||
./nym-node --config-file-env <PATH>/sandbox.env run --mode exit-gateway --id <ID> --public-ips "$(curl -4 https://ifconfig.me)" --hostname "<HOSTNAME>" --http-bind-address 0.0.0.0:8080 --mixnet-bind-address 0.0.0.0:1789 true --location <CLOCATION>
|
||||
```
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
- In case you downloaded `sandbox.env` to same directory, `<PATH>` is not needed
|
||||
|
||||
###### 3. Bond your node to Nym Sandbox environment
|
||||
- Open [Nym Wallet](https://nymtech.net/download/wallet) and switch to testnet
|
||||
- Go to [faucet.nymtech.net](https://faucet.nymtech.net) and aquire 101 testnet NYM tokens
|
||||
- Follow the steps on the [bonding page](nodes/nym-node/bonding.mdx)
|
||||
|
||||
|
||||
|
||||
</Steps>
|
||||
|
||||
<Callout>
|
||||
1. If you [built Nym from source](../binaries/building-nym.md), you already have `sandbox.env` as a part of the monorepo (`nym/envs/sandbox.env`). Giving that you are likely to run `nym-node` from `nym/target/release`, the flag will look like this `--config-env-file ../../envs/sandbox.env`
|
||||
|
||||
2. You can export the path to `sandbox.env` to your environmental variables:
|
||||
```sh
|
||||
export NYMNODE_CONFIG_ENV_FILE_ARG=<PATH>/sandbox.env
|
||||
```
|
||||
</Callout>
|
||||
|
||||
## Sandbox Token Faucet
|
||||
|
||||
To run your nodes in Sandbox environment, you need testnet version of NYM token, that can be aquired from [faucet.nymtech.net](https://faucet.nymtech.net).
|
||||
|
||||
To prevent abuse, the faucet is rate-limited - your request will fail if the requesting wallet already has 101 NYM tokens.
|
||||
@@ -1,7 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
stake_unyx=$(curl -s -L https://api.nymtech.net/cosmos/staking/v1beta1/pool | jq 'values["pool"]["bonded_tokens"]')
|
||||
stake_unyx=$(python -c "print(int($stake_unyx))")
|
||||
stake_nyx=$(python -c "print($stake_unyx / 1000000)")
|
||||
voting288k_percent=$(python -c "print(288000 / $stake_nyx * 100)")
|
||||
echo ${voting288k_percent:0:4}%
|
||||
@@ -1,4 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
stake=$(curl -s -L https://api.nymtech.net/cosmos/staking/v1beta1/pool | jq 'values["pool"]["bonded_tokens"]')
|
||||
echo ${stake:1:2}.${stake:3:3}
|
||||
@@ -1,6 +0,0 @@
|
||||
{
|
||||
"validator-rewards": "Nyx Validator Rewards",
|
||||
"mixnet-rewards": {
|
||||
"display": "hidden"
|
||||
}
|
||||
}
|
||||
@@ -1,46 +0,0 @@
|
||||
<!-- THIS PAGE IS ALL COMMENTED FROM SUMMARY - NO NEED TO REVIEW YET!!! -->
|
||||
|
||||
<!-- DROPPING THIS FROM THE MAINTENANCE -->
|
||||
|
||||
### Mix Node Reward Estimation API endpoint
|
||||
|
||||
The Reward Estimation API endpoint allows Mix Node operators to estimate the rewards they could earn for running a Nym Mix Node with a specific `MIX_ID`.
|
||||
|
||||
> The `<MIX_ID>` can be found in the "Mix ID" column of the [Network Explorer](https://explorer.nymtech.net/network-components/mixnodes/active).
|
||||
|
||||
The endpoint is a particularly common for Mix Node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the Mix Node, the quality of the Mix Node's performance, and the overall demand for Mix Nodes in the network. This information can be useful for Mix Node operators in deciding whether or not to run a Mix Node and in optimizing its operations for maximum profitability.
|
||||
|
||||
Using this API endpoint returns information about the Reward Estimation:
|
||||
|
||||
```sh
|
||||
/status/mixnode/<MIX_ID>/reward-estimation
|
||||
```
|
||||
|
||||
Query Response:
|
||||
|
||||
```sh
|
||||
"estimation": {
|
||||
"total_node_reward": "942035.916721770541325331",
|
||||
"operator": "161666.263307386408152071",
|
||||
"delegates": "780369.65341438413317326",
|
||||
"operating_cost": "54444.444444444444444443"
|
||||
},
|
||||
```
|
||||
|
||||
> The unit of value is measured in `uNYM`.
|
||||
|
||||
- `estimated_total_node_reward` - An estimate of the total amount of rewards that a particular Mix Node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of Mix Nodes currently active in the network, and the amount of network traffic being processed by the Mix Node.
|
||||
|
||||
- `estimated_operator_reward` - An estimate of the amount of rewards that a particular Mix Node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the operator's stake in the network.
|
||||
|
||||
- `estimated_delegators_reward` - An estimate of the amount of rewards that Mix Node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the delegator's stake in the network.
|
||||
|
||||
- `estimated_node_profit` - An estimate of the profit that a particular Mix node operator can expect to earn. This value is calculated by subtracting the Mix Node operator's `operating_costs` from their `estimated_operator_reward` for the current epoch.
|
||||
|
||||
- `estimated_operator_cost` - An estimate of the total cost that a particular Mix Node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a Mix Node, such as server hosting fees, and other expenses associated with operating the Mix Node.
|
||||
|
||||
### Validator: Installing and configuring nginx for HTTPS
|
||||
#### Setup
|
||||
[Nginx](https://www.nginx.com/resources/glossary/nginx) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.
|
||||
|
||||
Install `nginx` and allow the 'Nginx Full' rule in your firewall:
|
||||
@@ -1,67 +0,0 @@
|
||||
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { MigrateTabs } from 'components/operators/nodes/node-migrate-command-tabs';
|
||||
import NyxPercentStake from 'components/outputs/nyx-outputs/nyx-percent-stake.md';
|
||||
import NyxTotalStake from 'components/outputs/nyx-outputs/nyx-total-stake.md';
|
||||
import { TimeNow } from 'components/time-now.tsx';
|
||||
|
||||
# Nyx Validator Rewards
|
||||
|
||||
<TimeNow />
|
||||
|
||||
## Summary
|
||||
|
||||
* Nyx Validators are rewarded in NYM tokens from the Nym mixmining pool and increasingly from apps that run on the Nym mixnet, the first of which is the NymVPN.
|
||||
* Validators are rewarded for two different types of work: signing blocks in the Nyx chain and running the NymAPI to monitor mixnet routing and sign zk-nym credentials.
|
||||
* New validators can join via a NYM-to-NYX swap contract after contacting us and getting whitelisted. The contract will not allow more than 1% of total stake increase per month to prevent sudden hostile takeovers. Current stake is <span style={{display: 'inline-block'}}><NyxTotalStake /></span> million Nyx. Rate: 1:4.8 ~ 288k NYX for 60k NYM \=\> <span style={{display: 'inline-block'}}><NyxPercentStake /></span> voting power
|
||||
* NYX tokens serve no other purpose than self-delegation for voting power and governance. All rewards are in NYM and distributed directly to the validators self-delegation address and are not distributed to stakers.
|
||||
* The contract will only allow swapping NYM to NYX and will **not** allow exchanging NYX back to NYM. A NYX holder who wishes to sell their NYX stake will have to do so via OTC trades.
|
||||
|
||||
## Validator Rewards
|
||||
|
||||
Nyx Validators perform two types of work for which they will be rewarded:
|
||||
|
||||
### 1. Signing blocks in the Nyx chain
|
||||
|
||||
A “block signing monitor" monitors blocks being produced on the Nyx chain and gathers the signatures present on every block. After an epoch ends, the monitor will assess performance of a validator and distribute tokens (to the self-delegation wallet) proportional to the voting period and uptime of the validator.
|
||||
|
||||
### 2. Running the NymAPI to monitor Mixnet routing and sign zk-nyms (Nym’s anonymous credentials)
|
||||
|
||||
Validator rewards initially come from the Nym mixmining pool with additional rewards increasingly coming from paid applications running on the Nym mixnet. The first paid application is the NymVPN. Nyx validators will be rewarded for their work directly in NYM tokens to their validator self-delegation address.
|
||||
|
||||
1. **From mixmining pool** - at a rate of 1000 NYM per hour, of which 2/3 are distributed for signing blocks and 1/3 for zk-nyms. These are stable in NYM, and therefore will fluctuate in their fiat value depending on exchange rate.
|
||||
|
||||
2. **From vpn user subscriptions** - the rate is tied to the growth of NymVPN subscriptions and will be stable in fiat, fluctuating in NYM depending on exchange rate. 1/3 will be distributed for signing blocks and 2/3 for zk-nyms.
|
||||
|
||||
| Source | Signing blocks | Running NymAPI | Currency |
|
||||
| :-- | --: | --: | :---: |
|
||||
| Mixmining pool | 2/3 | 1/3 | NYM |
|
||||
| NymVPN | 1/3 | 2/3 | fiat |
|
||||
|
||||
#### zk-nyms
|
||||
|
||||
The zk-nyms enable people to anonymously prove access rights to the upcoming NymVPN client without having to reveal payment details that might compromise their privacy. This is the first of what we imagine to be many possible use-cases for the zk-nym scheme.
|
||||
|
||||
### Allocation of Rewards from Nym mixmining pool
|
||||
|
||||
Rewards for validators will be distributed at an hourly rate from the mixmining pool. The amount is 1000 NYM per hour to be distributed among all validators. The fraction of mixmining rewards received by each individual validator is proportional to its contributions to the network.
|
||||
|
||||
Two thirds of the available rewards (670 NYM per hour) are distributed proportionally to each validator’s share when signing blocks in the chain, for which tx fees are also received in the same proportion; while the last third (330 NYM per hour) is allocated to validators running the NymAPI, proportionally to their contribution to signing zk-nym credentials.
|
||||
|
||||
The rewards are stable in NYM and fluctuate in their fiat value depending on the exchange rate of NYM tokens.
|
||||
|
||||
## Permissionless Nyx Chain
|
||||
|
||||
To allow new validators to join Nyx chain a new smart contract will be set up to release NYX in exchange for NYM. This contract allows a limited amount of NYM tokens to be deposited per month. The deposited NYM tokens are added to the mixmining pool and thus contribute to future rewards of all nodes and validators.
|
||||
|
||||
The smart contract will have two parameters:
|
||||
|
||||
1. the maximum amount of NYX available for purchase per month
|
||||
2. the NYM-to-NYX exchange rate offered by the contract
|
||||
|
||||
### Maximum Amount of NYX Available for Purchase per Month
|
||||
|
||||
The contract will not allow more than 1% of total stake increase per month to prevent sudden hostile takeovers. Current stake level is <span style={{display: 'inline-block'}}><NyxTotalStake /></span> million Nyx.
|
||||
@@ -1,5 +0,0 @@
|
||||
{
|
||||
"vps-isp": "Troubleshooting VPS Setup",
|
||||
"nodes": "Nym Node",
|
||||
"validators": "Validators"
|
||||
}
|
||||
@@ -1,488 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
|
||||
# Nym Node Troubleshooting
|
||||
|
||||
If you have problems running a `nym-node` you are likely to find a solution here.
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## Binary Build Problems
|
||||
|
||||
### I am trying to build from the GitHub archive files and the build fails
|
||||
|
||||
GitHub automatically includes `.zip` and `tar.gz` files of the Nym repository in its release. You cannot extract these and build - you'll see something like this:
|
||||
|
||||
```sh
|
||||
process didn't exit successfully: `/build/nym/src/nym-0.12.1/target/release/build/nym-socks5-client-c1d0f76a8c7d7e9a/build-script-build` (exit status: 101)
|
||||
--- stderr
|
||||
thread 'main' panicked at 'failed to extract build metadata: could not find repository from '/build/nym/src/nym-0.12.1/clients/socks5'; class=Repository (6); code=NotFound (-3)', clients/socks5/build.rs:7:31
|
||||
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
|
||||
warning: build failed, waiting for other jobs to finish...
|
||||
error: build failed
|
||||
```
|
||||
|
||||
Why does this happen?
|
||||
|
||||
We have scripts which automatically include the Git commit hash and Git tag in the binary for easier debugging later. If you download a .zip and try building from that, it's not a Git repository and build will fail as above.
|
||||
|
||||
What to do?
|
||||
|
||||
* Follow the instructions in the Binaries section to [build nym from source](../binaries/building-nym.mdx) or [download precompiled binaries](../binaries/pre-build-binaries.mdx)
|
||||
* To upgrade, follow the [upgrade instructions](../nodes/maintenance/manual-upgrade.mdx)
|
||||
|
||||
## General Node Config
|
||||
|
||||
### Where can I find my private and public keys and config?
|
||||
|
||||
All config and keys files are stored in a directory named after your node local identifier (`<ID>`) which you chosen (if not, default one is `default-nym-node`), and can be found at the following PATH: `$HOME/.nym/nym-node/<NODE_ID>` where `$HOME` is a home directory of the user (your current user in this case) that launched the node or client.
|
||||
|
||||
The directory structure for each node will be roughly as follows:
|
||||
|
||||
```sh
|
||||
~/.nym/nym-nodes/
|
||||
└── default-nym-node
|
||||
├── config
|
||||
│ └── config.toml
|
||||
└── data
|
||||
├── aes128ctr_ipr_ack
|
||||
├── aes128ctr_nr_ack
|
||||
├── clients.sqlite
|
||||
├── cosmos_mnemonic
|
||||
├── description.toml
|
||||
├── ed25519_identity
|
||||
├── ed25519_identity.pub
|
||||
├── ed25519_ipr_identity
|
||||
├── ed25519_ipr_identity.pub
|
||||
├── ed25519_nr_identity
|
||||
├── ed25519_nr_identity.pub
|
||||
├── ipr_gateways_info_store.sqlite
|
||||
├── nr_gateways_info_store.sqlite
|
||||
├── nr_persistent_reply_store.sqlite
|
||||
├── x25519_ipr_dh
|
||||
├── x25519_ipr_dh.pub
|
||||
├── x25519_noise
|
||||
├── x25519_noise.pub
|
||||
├── x25519_nr_dh
|
||||
├── x25519_nr_dh.pub
|
||||
├── x25519_sphinx
|
||||
└── x25519_sphinx.pub
|
||||
```
|
||||
|
||||
<Callout>
|
||||
If you `cat` the `public_sphinx.pem` key, the output will be different from the public key you will see on Nym [dashboard](https://explorer.nymtech.net/). The reason for this is that `.pem` files are encoded in **base64**, however on the web they are in **base58**. Don't be confused if your keys look different. They are the same keys, just with different encoding.
|
||||
</Callout>
|
||||
|
||||
### Accidentally killing your node process on exiting session
|
||||
|
||||
When you close your current terminal session, you need to make sure you don't kill the Mix Node process! There are multiple ways on how to make it persistent even after exiting your ssh session, the easiest solution is to use `tmux` or `nohup`, and the more elegant solution is to run the node with `systemd`. Read the automation manual [here](../nodes/nym-node/configuration.mdx#automating-your-node-with-tmux-and-systemd).
|
||||
|
||||
### What is `verloc` and do I have to configure my Nym Node to implement it?
|
||||
|
||||
`verloc` is short for _verifiable location_. Mix Nodes and Gateways now measure speed-of-light distances to each other, in an attempt to verify how far apart they are. In later releases, this will allow us to algorithmically verify node locations in a non-fake-able and trustworthy manner.
|
||||
|
||||
You don't have to do any additional configuration for your node to implement this, it is a passive process that runs in the background of the mixnet.
|
||||
|
||||
## Node Functionality Specific Troubleshooting
|
||||
|
||||
**Choose the mode that you want to troubleshoot.**
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<strong>Mode <code>mixnode</code></strong>,
|
||||
<strong>Mode <code>entry-gateway</code> & <code>exit-gateway</code></strong>,
|
||||
]} defaultIndex="1">
|
||||
<MyTab>
|
||||
## Mixnode Mode
|
||||
|
||||
### How can I tell my node is up and running and mixing traffic?
|
||||
|
||||
First of all check the 'Mixnodes' section of either of the Nym Network Explorers:
|
||||
* [Mainnet](https://explorer.nymtech.net/)
|
||||
* [Sandbox testnet](https://sandbox-explorer.nymtech.net/)
|
||||
|
||||
You can also check [Nym Harbourmaster](https://harbourmaster.nymtech.net) which now also includes mixnode mode.
|
||||
|
||||
There are a few community explorers as well.
|
||||
|
||||
* [ExploreNYM](https://explorenym.net/)
|
||||
* [Mixplorer](https://mixplorer.xyz/)
|
||||
|
||||
Enter your **identity key** to find your node. Check the contents of the `Mixnode stats` and `Routing score` sections.
|
||||
|
||||
You can run [Node API Check CLI](../testing/node-api-check.mdx) to query all API endpoints of your node at once.
|
||||
|
||||
[Here](https://github.com/cosmos/chain-registry/blob/master/nyx/chain.json#L158-L187) is a dictionary with Nyx chain registry entry regarding all explorers.
|
||||
|
||||
If you want more information, or if your node isn't showing up on the explorer of your choice and you want to double-check, here are some examples on how to check if the node is configured properly.
|
||||
|
||||
#### Check from your VPS
|
||||
|
||||
Additional details can be obtained via various methods after you connect to your VPS:
|
||||
|
||||
##### Socket statistics with `ss`
|
||||
|
||||
```sh
|
||||
sudo ss -s -t | grep 1789 # if you have specified a different port in your Mix Node config, change accordingly
|
||||
```
|
||||
|
||||
This command should return a lot of data containing `ESTAB`. This command should work on every unix based system.
|
||||
|
||||
##### List open files and reliant processes with `lsof`
|
||||
|
||||
- Check if lsof is installed:
|
||||
```sh
|
||||
lsof -v
|
||||
```
|
||||
|
||||
- Install if not installed
|
||||
```sh
|
||||
sudo apt install lsof
|
||||
```
|
||||
|
||||
- Run against nym-mix-node node port
|
||||
```sh
|
||||
sudo lsof -i TCP:1789 # if you have specified a different port in your mixnode config, change accordingly
|
||||
```
|
||||
- This command should return something like this:
|
||||
|
||||
```sh
|
||||
nym-node 103349 root 53u IPv6 1333229972 0t0 TCP [2a03:b0c0:3:d0::ff3:f001]:57844->[2a01:4f9:c011:38ae::5]:1789 (ESTABLISHED)
|
||||
nym-node 103349 root 54u IPv4 1333229973 0t0 TCP nym:57104->194.5.78.73:1789 (ESTABLISHED)
|
||||
nym-node 103349 root 55u IPv4 1333229974 0t0 TCP nym:48130->static.236.109.119.168.clients.your-server.de:1789 (ESTABLISHED)
|
||||
nym-node 103349 root 56u IPv4 1333229975 0t0 TCP nym:52548->vmi572614.contaboserver.net:1789 (ESTABLISHED)
|
||||
nym-node 103349 root 57u IPv6 1333229976 0t0 TCP [2a03:b0c0:3:d0::ff3:f001]:43244->[2600:1f18:1031:2401:c04b:2f25:ca79:fef3]:1789 (ESTABLISHED)
|
||||
```
|
||||
|
||||
##### Query `systemd` journal with `journalctl`
|
||||
|
||||
```sh
|
||||
sudo journalctl -u nym-node -o cat | grep "Since startup mixed"
|
||||
```
|
||||
|
||||
If you have created `nym-node.service` file (i.e. you are running your [Nym Node via `systemd`](../nodes/nym-node/configuration.mdx#systemd) - recommended) then this command shows you how many packets have you mixed so far, and should return a list of messages like this:
|
||||
|
||||
```sh
|
||||
2021-05-18T12:35:24.057Z INFO nym_node::node::metrics > Since startup mixed 233639 packets!
|
||||
2021-05-18T12:38:02.178Z INFO nym_node::node::metrics > Since startup mixed 233739 packets!
|
||||
2021-05-18T12:40:32.344Z INFO nym_node::node::metrics > Since startup mixed 233837 packets!
|
||||
2021-05-18T12:46:08.549Z INFO nym_node::node::metrics > Since startup mixed 234081 packets!
|
||||
2021-05-18T12:56:57.129Z INFO nym_node::node::metrics > Since startup mixed 234491 packets!
|
||||
```
|
||||
|
||||
You can add ` | tail` to the end of the command to watch for new entries in real time if needed.
|
||||
|
||||
##### build-info
|
||||
|
||||
A `build-info` command prints the build information like commit hash, rust version, binary version just like what command `--version` does. However, you can also specify an `--output=json` flag that will format the whole output as a json, making it an order of magnitude easier to parse.
|
||||
|
||||
For example `./target/debug/nym-node --no-banner build-info --output json` will return:
|
||||
|
||||
```sh
|
||||
{"binary_name":"nym-network-requester","build_timestamp":"2023-07-24T15:38:37.00657Z","build_version":"1.1.23","commit_sha":"c70149400206dce24cf20babb1e64f22202672dd","commit_timestamp":"2023-07-24T14:45:45Z","commit_branch":"feature/simplify-cli-parsing","rustc_version":"1.71.0","rustc_channel":"stable","cargo_profile":"debug"}
|
||||
```
|
||||
|
||||
#### Check from your local machine
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Scan ports with `nmap`
|
||||
|
||||
```sh
|
||||
nmap -p 1789 <PUBLIC_IP> -Pn
|
||||
```
|
||||
|
||||
If your Nym Node is configured properly it should output something like this:
|
||||
|
||||
```sh
|
||||
bob@desktop:~$ nmap -p 1789 95.296.134.220 -Pn
|
||||
|
||||
Host is up (0.053s latency).
|
||||
|
||||
PORT STATE SERVICE
|
||||
1789/tcp open hello
|
||||
```
|
||||
|
||||
###### 2. Check with `telnet`
|
||||
|
||||
Your node should connect to telnet when running:
|
||||
```sh
|
||||
telnet <PUBLIC_IP> <PORT>
|
||||
```
|
||||
|
||||
###### 3. Query online nodes:
|
||||
|
||||
```sh
|
||||
curl --location --request GET 'https://validator.nymtech.net/api/v1/mixnodes/'
|
||||
```
|
||||
|
||||
Will return a list all nodes currently online.
|
||||
|
||||
You can query Gateways by replacing `mixnodes` with `gateways` in the above command, and can query for the Mix Nodes and Gateways on the Sandbox testnet by replacing `validator` with `sandbox-validator`.
|
||||
|
||||
</Steps>
|
||||
|
||||
#### Check with Network API
|
||||
|
||||
We currently have an API set up returning our metrics tests of the network. There are two endpoints to ping for information about your Mix Node, `report` and `history`. Find more information about this in the [Mixnodes metrics documentation](../nodes/maintenance.md#metrics--api-endpoints).
|
||||
|
||||
For more information about available endpoints and their status, you can refer to:
|
||||
```sh
|
||||
# for http
|
||||
http://<PUBLIC_IP>:8080/api/v1/swagger/#/
|
||||
|
||||
# for https reversed proxy
|
||||
https://<HOSTNAME>/api/v1/swagger/#/
|
||||
```
|
||||
|
||||
### Why is my node not mixing any packets?
|
||||
|
||||
If you are still unable to see your node on the dashboard, or your node is declaring it has not mixed any packets, there are several potential issues:
|
||||
|
||||
- The firewall on your host machine is not configured properly. Checkout the [instructions](../nodes/preliminary-steps/vps-setup.mdx#configure-your-firewall).
|
||||
- You provided incorrect information when bonding your node.
|
||||
- You are running your node from a VPS without IPv6 support.
|
||||
- You did not configure your router firewall while running the node from your local machine behind NAT, or you are lacking IPv6 support
|
||||
- Your Mix Node is not running at all, it has either exited / panicked or you closed the session without making the node persistent. Check out the [instructions](../nodes/nym-node/configuration.mdx#automating-your-node-with-tmux-and-systemd).
|
||||
|
||||
<Callout type="warning" emoji="">
|
||||
Your Nym Node **must speak both IPv4 and IPv6** in order to cooperate with other nodes and route traffic. This is a common reason behind many errors we are seeing among node operators, so check with your provider that your VPS is able to do this!
|
||||
</Callout>
|
||||
|
||||
#### Check IPv6 Connectivity
|
||||
|
||||
You can always check IPv6 address and connectivity by using some of these methods:
|
||||
|
||||
- Locally listed IPv6 addresses
|
||||
```sh
|
||||
ip -6 addr
|
||||
```
|
||||
- Globally reachable IPv6 addresses
|
||||
```sh
|
||||
ip -6 addr show scope global
|
||||
```
|
||||
|
||||
- With DNS
|
||||
```sh
|
||||
dig -6 TXT +short o-o.myaddr.l.google.com @ns1.google.com
|
||||
dig -t aaaa +short myip.opendns.com @resolver1.opendns.com
|
||||
```
|
||||
|
||||
- https check
|
||||
```sh
|
||||
curl -6 https://ifconfig.co
|
||||
curl -6 https://ipv6.icanhazip.com
|
||||
```
|
||||
|
||||
- Using telnet
|
||||
```sh
|
||||
telnet -6 ipv6.telnetmyip.com
|
||||
```
|
||||
If your connection doesn't work make sure to follow [VPS IPv6 setup](../nodes/nym-node/configuration.mdx#connectivity-test-and-configuration). If there is more troubleshooting needed, check out [VPS IPv6 troubleshooting](vps-isp.mdx#ipv6-troubleshooting) page.
|
||||
|
||||
|
||||
#### Incorrect bonding information
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
All delegated stake will be lost when un-bonding! However the Nym Node must be operational in the first place for the delegation to have any effect.
|
||||
</Callout>
|
||||
|
||||
Check that you have provided the correct information when bonding your Nym Node in the web wallet interface. When in doubt and without any delegations on your node, un-bond and then re-bond your node!
|
||||
|
||||
|
||||
### Running on a local machine behind NAT with no fixed IP address
|
||||
|
||||
Your ISP has to be IPv6 ready if you want to run a Nym Node on your local machine. Sadly, in 2020, most of them are not and you won't get an IPv6 address by default from your ISP. Usually it is an extra paid service or they simply don't offer it.
|
||||
|
||||
Before you begin, check if you have IPv6 [here](https://test-ipv6.cz/) or by running command explained in the [section above](#no-ipv6-connectivity). If not, then don't waste your time to run a node which won't ever be able to mix any packet due to this limitation. Call your ISP and ask for IPv6, there is a plenty of it for everyone!
|
||||
|
||||
If all goes well and you have IPv6 available, you will also need to edit your `config.toml` file each time your IPv4 address changes, that could be a few days or a few weeks. Check the your IPv4 in the [section above](#no-ipv6-connectivity).
|
||||
|
||||
Additional configuration on your router might also be needed to allow traffic in and out to port 1789 and IPv6 support.
|
||||
|
||||
Make sure you check if your node is really mixing. We are aiming to improve the setup for operators running locally, however you may need a bit of patience to set this up from your home behind NAT.
|
||||
|
||||
### Common errors and warnings
|
||||
|
||||
Most of the `ERROR` and `WARN` messages in your node logs are benign - as long as your node outputs `since startup mixed X packets!` (`X` must be > 0) in your logs (and this number increases over time), your node is mixing packets. If you want to be sure, check the Nym [dashboard](https://sandbox-explorer.nymtech.net/) or see other ways on how to check if your node is mixing properly as outlined in the section [**How can I tell my node is up and running and mixing traffic?**](#how-can-i-tell-my-node-is-up-and-running-and-mixing-traffic?) above.
|
||||
|
||||
</MyTab>
|
||||
<MyTab>
|
||||
## Gateways Mode
|
||||
|
||||
### My `exit-gateway` is running but appears offline in the explorer
|
||||
|
||||
Let your Gateway run and follow these steps:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Check if your [firewall configuration](../nodes/preliminary-steps/vps-setup.mdx#configure-your-firewall)
|
||||
|
||||
- If `ufw` is active and if the necessary ports are open / allowed, including the ones for Swagger page and Reversed proxy/WSS if this is your case.
|
||||
|
||||
###### 2. See if the Gateway is not on the [list of blacklisted Gateways](https://validator.nymtech.net/api/v1/gateways/blacklisted)
|
||||
|
||||
###### 3. If it's blacklisted, check out the [point below](#my-gateway-is-blacklisted)
|
||||
|
||||
</Steps>
|
||||
|
||||
### My Gateway is blacklisted
|
||||
|
||||
Nym API measures performance by routing traffic through the Mixnet. If the average of a Gateway's routing score in past 24h is less than 50%, the Gateway gets blacklisted and it remains so until its performance is higher than 50%.
|
||||
|
||||
In case your Gateway appeared on the [blacklist](https://validator.nymtech.net/api/v1/gateways/blacklisted), it's because there is some flaw in the configuration. The most common sources of problems are:
|
||||
|
||||
- Outdated version of `nym-node`
|
||||
- Bonding before starting the node/service
|
||||
- Bonding before opening [needed ports](../nodes/preliminary-steps/vps-setup.mdx#configure-your-firewall)
|
||||
- VPS restarted without operator having a [systemd automation](../nodes/nym-node/configuration.mdx#systemd) or some alert notification flow setup (so the operator doesn't know the node was stopped)
|
||||
- IP address or host is [incorrectly configured](../nodes/nym-node/setup.mdx)
|
||||
- Process logs grew too big
|
||||
- Node is wrapped in [systemd service](../nodes/nym-node/configuration.mdx#systemd) and the operator forgot to run `systemctl daemon-reload` after last changes
|
||||
|
||||
**What to do**
|
||||
|
||||
Begin with a sanity check by opening [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net) and check your node there. To query all API endpoints of your node at once, you can run [Node API Check CLI](../testing/node-api-check.mdx). To see IPv4 and IPv6 routing in real time (harbourmaster can have a cache up to 90 min), run [Gateway Probe CLI](../testing/gateway-probe.mdx).
|
||||
|
||||
Then follow these steps:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Make sure your node is on the [latest version](../changelog.mdx) and it's running . Do *not* stop it if there is no need!
|
||||
|
||||
###### 2. Open all [needed ports](../nodes/preliminary-steps/vps-setup.mdx#configure-your-firewall)
|
||||
|
||||
###### 3. Check your `config.toml` - often people have filled `hostname` without the domain being registered to `nym-node` IP, or a wrong IP address after moving their node.
|
||||
|
||||
###### 4. [Check Gateway Connectivity](#check-gateway-connectivity)
|
||||
|
||||
###### 5. See logs of your Gateway and search [for errors](#nym-node-errors) - if you find any unusual one, you can ask in the [Element Node Operators](https://matrix.to/#/#operators:nymtech.chat) channel
|
||||
|
||||
If your logs show that your Node has `cover down: 0.00` that means that the embedded IPR and NR is not sending any cover traffic.
|
||||
|
||||
###### 6. [Check out if your `syslog`s](vps-isp.mdx#pruning-logs) aren't eating all your disk space and prune them
|
||||
|
||||
###### 7. When all problems are addressed: Restart the node service
|
||||
|
||||
Don't forget `systemctl daemon-reload`) and wait until your node gets above 50% of performance (average of last 24h) - this will likely take 24-48 hours. During this time your node is tested by `nym-api` and every positive response picks up your routing score.
|
||||
|
||||
###### 8. If your node doesn't pick up the routing score within 24h try changing mode
|
||||
|
||||
If it stayed on zero performance and you succeed in all the checks above, while your running in `--mode exit-gateway`, run it as `--mode entry-gateway`. When your node is above 75% performance (past 24h), switch back to `--mode exit-gateway`.
|
||||
|
||||
<Callout>
|
||||
**Do not repeatedly restart your Nym Node without reason, your routing score will only get worse!**
|
||||
</Callout>
|
||||
|
||||
</Steps>
|
||||
|
||||
### Check Gateway connectivity
|
||||
|
||||
Here are a few steps to check whether your Gateway is actually connecting.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Check out the API endpoints
|
||||
|
||||
Start with checking if your Gateway IPR and NR is active. To determine which mode your node is running, you can check the `:8080/api/v1/roles` endpoint. For example:
|
||||
```sh
|
||||
# for http
|
||||
http://<PUBLIC_IP>:8080/api/v1/roles
|
||||
# or
|
||||
http://<PUBLIC_IP>/api/v1/roles
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/roles
|
||||
```
|
||||
|
||||
Everything necessary will exist on your node by default. For instance, if you're running a mixnode, you'll find that a NR (Network Requester) and IPR (IP Packet Router) address exist, but they will be ignored in `mixnode` mode.
|
||||
|
||||
For more information about available endpoints and their status, you can refer to:
|
||||
```sh
|
||||
# for http
|
||||
http://<PUBLIC_IP>:8080/api/v1/swagger/#/
|
||||
# or
|
||||
http://<PUBLIC_IP>/api/v1/swagger/#/
|
||||
|
||||
# for reversed proxy/WSS
|
||||
https://<HOSTNAME>/api/v1/swagger/#/
|
||||
```
|
||||
|
||||
|
||||
###### 2. Configure IPv4 and IPv6 tables and rules
|
||||
|
||||
In case you haven't lately, follow the steps in the node [configuration](../nodes/nym-node/configuration.mdx) chapter [connectivity test and configurastion](../nodes/nym-nodes/configuration.mdx#connectivity-test-and-configuration).
|
||||
|
||||
|
||||
###### 3. Test connectivity
|
||||
|
||||
Telnet - from your local machine try to connect to your VPS bu running:
|
||||
|
||||
```sh
|
||||
telnet <PUBLIC_IP> <PORT>
|
||||
```
|
||||
|
||||
[Websocket wcat](https://github.com/websockets/wscat):
|
||||
|
||||
- Install on your local machine:
|
||||
```sh
|
||||
sudo apt install node-ws
|
||||
```
|
||||
|
||||
- Run `wscat` pointing to the IP of your VPS with port `9000`:
|
||||
```
|
||||
wscat -c ws://<PUBLIC_IP>:<PORT>
|
||||
```
|
||||
|
||||
</Steps>
|
||||
|
||||
### My exit Gateway "is still not online..."
|
||||
|
||||
The Nyx chain epoch takes up to 60 min. To prevent the Gateway getting blacklisted, it's essential to start it before the bonding process and let it running. In case it already got [blacklisted](#my-gateway-is-backlisted) check the steps above.
|
||||
|
||||
</MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
{/*
|
||||
THIS NEEDS TO BE REWORKED
|
||||
### When enabling `ip_packet_router` (IPR) I get a `client-core error`
|
||||
|
||||
This error tells you that you already have IPR keys in your data storage, to activate them you have two options:
|
||||
|
||||
1. Open `~/.nym/nym-nodes/<ID>/config/config.toml` and **set the correct values**
|
||||
```toml
|
||||
[ip_packer_router_enabled]
|
||||
enabled = true
|
||||
|
||||
# UNDER [storage_paths] CHANGE
|
||||
ip_packet_router_config = '~/.nym/nym-nodes/<ID>/config/ip_packet_router_config.toml'
|
||||
```
|
||||
|
||||
2. Or **remove the IPR data storage and initialise a new one** with these commands
|
||||
```toml
|
||||
rm -rf ~/.nym/nym-nodes/<ID>/data/ip-packet-router-data
|
||||
|
||||
./nym-gateway setup-ip-packet-router --id <ID>
|
||||
```
|
||||
|
||||
### My `ip_packet_router` (IPR) seems to not work
|
||||
|
||||
There are a few steps to mitigate problems with IPR:
|
||||
|
||||
1. Check out the issue right above regarding the [Exit Gateway config](#when-enabling-ip_packet_router-ipr-i-get-a-client-core-error)
|
||||
2. Open your browser and checkout the Swagger UI page and see if all the roles are enabled:
|
||||
```sh
|
||||
# in case of IP
|
||||
http://<YOUR_LISTENING_IP_ADDRESS>:8080/api/v1/roles
|
||||
|
||||
# in case of hostname domain
|
||||
https://<YOUR_DOMAIN>/api/v1/roles
|
||||
```
|
||||
3. Make sure all your [ports are open](https://nymtech.net/operators/nodes/maintenance.html#configure-your-firewall) properly
|
||||
4. Make sure to run your Gateway with embedded IPR as root. Either in a root shell with your configs in `/root/.nym/` or with a command `sudo -E` which gives root privileges but looks for user config folder
|
||||
5. If it's all good in the API but you don't see the right tick/badge in the [Performance testing list](https://nymtech.net/events/fast-and-furious), just wait some time and then try to refresh the page
|
||||
*/}
|
||||
@@ -1,18 +0,0 @@
|
||||
# Validators Troubleshooting
|
||||
|
||||
### Common reasons for your validator being jailed
|
||||
|
||||
The most common reason for your validator being jailed is that your validator is out of memory because of bloated syslogs.
|
||||
|
||||
- Running the command `df -H` will return the size of the various partitions of your VPS.
|
||||
|
||||
- If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog archives and restart your validator process.
|
||||
|
||||
- You can [check out if your `syslog`s](vps-isp.mdx#pruning-logs) aren't eating all your disk space and prune them.
|
||||
|
||||
|
||||
## Where can I get more help?
|
||||
|
||||
The fastest way to reach one of us or get a help from the community, visit our [Telegram Node Setup Help Chat](https://t.me/nymchan_help_chat) or head to our [Discord](https://nymtech.net/go/discord).
|
||||
|
||||
For more tech heavy question join our [Matrix core community channel](https://matrix.to/#/#general:nymtech.chat), where you can meet other builders and Nym core team members.
|
||||
@@ -1,158 +0,0 @@
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { Callout } from 'nextra/components';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
|
||||
# Troubleshooting VPS Setup
|
||||
|
||||
<VarInfo/>
|
||||
|
||||
## IPv6 troubleshooting
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
To monitor connectivity of your Exit Gateway, use results of probe testing displayed in [harbourmaster.nymtech.net](https://harbourmaster.nymtech.net).
|
||||
</Callout>
|
||||
|
||||
### Incorrect Gateway Network Check
|
||||
|
||||
Nym operators community is working on a Nym version of tors [good bad ISP table](https://community.torproject.org/relay/community-resources/good-bad-isps/). There is no one solution fits all when it comes to connectivity setup. The operation of `nym-node` will vary depending on your ISP and chosen system/distribution. While few machines will work out of the box, most will work after uisng our connectivity configuration guide, some need more adjustments.
|
||||
|
||||
Begin with the steps listed in [*Connectivity Test and Configuration*](../nodes/preliminary-steps/vps-setup.mdx#connectivity-test-and-configuration) chapter of the VPS setup page. If you still have a problem with the IPv6 connectivity try:
|
||||
|
||||
<Steps>
|
||||
|
||||
1. Nym operators community started an ISP table called [*Where to host your nym node?*](../community-counsel/isp-list.mdx), check it out and add your findings!
|
||||
|
||||
2. Tor community created a helpful [table of ISPs](https://community.torproject.org/relay/community-resources/good-bad-isps/). Make sure your one is listed there as a *"good ISP"*. If not, consider migrating!
|
||||
|
||||
3. Checkout your VPS dashboard and make sure your IPv6-public enabled.
|
||||
|
||||
4. If you are able to add IPv6 address `/64` range, do it.
|
||||
|
||||
|
||||
|
||||
5. Search or ask your ISP for additional documentation related to IPv6 routing and ask them to provide you with `IPv6 IP address` and `IPv6 IP gateway address`
|
||||
- For example Digital Ocean setup isn't the most straight forward, but it's [well documented](https://docs.digitalocean.com/products/networking/ipv6/how-to/enable/#on-existing-droplets) and it works.
|
||||
|
||||
6. Search for guides regarding your particular system and distribution. For Debian based distributions using `systemd`, some generic guides such as [this one](https://cloudzy.com/blog/configure-ipv6-on-ubuntu/) or [this one](https://help.ovhcloud.com/csm/en-ie-vps-configuring-ipv6?id=kb_article_view&sysparm_article=KB0047567) work as well.
|
||||
|
||||
</Steps>
|
||||
|
||||
### Network configuration
|
||||
|
||||
On modern Debian based Linux distributions, the network is configured by either [Netplan](https://netplan.io/) or [ifup/ifdown](https://manpages.debian.org/testing/ifupdown/ifup.8.en.html) utilities. It is very easy to check which one you have.
|
||||
|
||||
- If you have the following folder `/etc/netplan` which has got a YAML file - you are likely to have Netplan.
|
||||
- If you have the following folder `/etc/network` and it is not empty - you are likely to have ifup/down.
|
||||
|
||||
Most contemporary Ubuntu/Debian distributions come with Netplan, however it is possible that your hosting provider is using a custom version of ISO. For example, Debian 12 (latest version as of June 2024) may come with ifup/down.
|
||||
|
||||
Nym operator community members have tested a VPS with Netplan and where in some cases `nym-node --mode exit-gateway` was not routing IP packets properly even after running `network_tunnel_manager.sh` script. We are working on a guide to setup Netplan configuration manually for such cases.
|
||||
|
||||
Configuration of ifup/ifdown is a bit simpler. If the `network_tunnel_manager.sh` script doesn't do the job, open `/etc/network/interfaces` file (research if your system uses a different naming for it) and configure it similarly to this:
|
||||
|
||||
```ini
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
auto eth0
|
||||
iface eth0 inet static
|
||||
address <YOUR_IPV4_ADDRESS>
|
||||
netmask NETMASK
|
||||
|
||||
gateway <ISP_IPV4_GATEWAY>
|
||||
iface eth0 inet6 static
|
||||
accept_ra 0
|
||||
address <YOUR_IPV6_ADDRESS>
|
||||
netmask 64
|
||||
gateway <ISP_IPV6_GATEWAY>
|
||||
post-up /sbin/ip -r route add <YOUR_IPV6_GATEWAY> dev eth0
|
||||
post-up /sbin/ip -r route add default via <YOUR_IPV6_GATEWAY>
|
||||
```
|
||||
Last two lines are particularly important as they enable IPv6 routing. You can find YOUR_IPV6_GATEWAY using your server's control panel. There is no single way to find the gateway, so please access your control panel to find yours or open a support ticket. Here is an example of how it looks on [OVH](https://help.ovhcloud.com/csm/en-ie-vps-configuring-ipv6?id=kb_article_view&sysparm_article=KB0047567).
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Be extra careful editing this file since you may lock yourself out of the server. If it happens, you can always access the server via the hoster's VNC panel.
|
||||
</Callout>
|
||||
|
||||
Once finished, save the file and reboot the server. Now, running `ip a` command should return correct IPv4 and IPv6 addresses.
|
||||
|
||||
Finally re-run `network_tunnel_manager.sh` script, following the steps in node [IPv6 configuration chapter](../nodes/nym-node/configuration.mdx#ipv6-configuration).
|
||||
|
||||
## Other VPS troubleshooting
|
||||
|
||||
### Virtual IPs and hosting via Google & AWS
|
||||
|
||||
For true internet decentralization we encourage operators to use diverse VPS providers instead of the largest companies offering such services. If for some reasons you have already running AWS or Google and want to setup a `<NODE>` there, please read the following.
|
||||
|
||||
On some services (AWS, Google, etc) the machine's available bind address is not the same as the public IP address. In this case, bind `--host` to the local machine address returned by `$(curl -4 https://ifconfig.me)`, but that may not the public IP address to bond your `<NODE>` in the wallet.
|
||||
|
||||
You can run `ifconfig` command. For example, on a Google machine, you may see the following output:
|
||||
|
||||
```sh
|
||||
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
|
||||
inet 10.126.5.7 netmask 255.255.255.255 broadcast 0.0.0.0
|
||||
...
|
||||
```
|
||||
|
||||
The `ens4` interface has the IP `10.126.5.7`. But this isn't the public IP of the machine, it's the IP of the machine on Google's internal network. Google uses virtual routing, so the public IP of this machine is something else, maybe `36.68.243.18`.
|
||||
|
||||
To find the right IP configuration, contact your VPS provider for support to find the right public IP and use it to bond your `<NODE>` with the `nym-api` via Nym wallet.
|
||||
|
||||
### Self-hosted nodes
|
||||
|
||||
On self-hosted machine it's a bit more tricky. In that case as an operator you must be sure that your ISP allows for public IPv4 and IPv6 and then it may be a bit of playing around to find the right configuration. One way may be to bind your binary with the `--host` flag to local address `127.0.0.1` and run `echo "$(curl -4 https://ifconfig.me)"` to get a public address which you use to bond your Mix Node to `nym-api` via Nym wallet.
|
||||
|
||||
It's up to you as a node operator to ensure that your public and private IPs match up properly.
|
||||
|
||||
### Pruning Logs
|
||||
|
||||
Running a `nym-node` as a standalone process or wrapped in a service can produce gigabytes of logs. Eventually your operation can malfunction due to the logs chewing up too much disk space or memory. Below are two scripts that can help you clean this up.
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
`rm` is a powerful tool, without an easy way of revoking. If you need to extract or backup anything, do it now. Make sure you understand what you removing before you execute these commands.
|
||||
</Callout>
|
||||
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. See what's eating all your diskspace
|
||||
|
||||
```sh
|
||||
sudo find /var -type f -printf "%s\t%p\n" | sort -n -r | head -n 20 | ls -lh
|
||||
sudo find /var -type f -exec ls -lh {} + 2>/dev/null | sort -k 5 -n -r | head -n 20
|
||||
|
||||
sudo du -h --max-depth=1 /var
|
||||
sudo du -h /var/log
|
||||
```
|
||||
###### 2. Prune those logs
|
||||
```sh
|
||||
sudo rm -f /var/log/syslog.1
|
||||
sudo rm -f /var/log/syslog
|
||||
journalctl --disk-usage
|
||||
sudo journalctl --vacuum-time=3d
|
||||
sudo journalctl --vacuum-size=50M
|
||||
```
|
||||
|
||||
###### 3.Enforce log rotation
|
||||
```sh
|
||||
sudo logrotate --force /etc/logrotate.conf
|
||||
sudo service rsyslog restart
|
||||
```
|
||||
|
||||
###### 4. Remove all old packages
|
||||
```sh
|
||||
sudo apt-get clean
|
||||
sudo apt-get autoremove
|
||||
|
||||
sudo apt-get clean
|
||||
sudo rm -rf /var/lib/apt/lists/*
|
||||
sudo apt-get update
|
||||
|
||||
for snap in $(sudo snap list --all | awk '/disabled/{print $1, $3}'); do
|
||||
sudo snap remove $snap
|
||||
done
|
||||
```
|
||||
|
||||
</Steps>
|
||||
@@ -1,17 +0,0 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
import VariablesTable from 'components/outputs/csv2md-outputs/variables.md';
|
||||
|
||||
# Essential Parameters & Variables
|
||||
|
||||
Our documentation often refer to syntax annotated in `<>` brackets. We use this expression for variables that are unique to each user (like path, local moniker, versions etcetra). Any syntax in `<>` brackets needs to be substituted with your correct name or version, without the `<>` brackets.
|
||||
|
||||
Below is a table listing the most essential variables and parameters which they may come along with, together with description and syntax example. It should help operators and developers to familiarise themselves with the convention of parameters and variables we use across the documentation.
|
||||
|
||||
|
||||
<Callout>
|
||||
To prevent over-flooding of our documentation we cannot provide with every single command syntax as there is a large combination of possibilities. Remember that you can always print the options using a `--help` flag together with any binary command.
|
||||
</Callout>
|
||||
|
||||
<VariablesTable />
|
||||
|
||||
|
||||
Reference in New Issue
Block a user