docs: Change /serverdir/node -> node/data

docs/node/mainnet/eden-upgrade.md

@@ -173,15 +173,15 @@ running the following command:
 ``` bash
 # specify 'datadir' as your node's data directory
 oasis-node unsafe-reset \
-  --datadir=/serverdir/node \
+  --datadir=/node/data \
   --dry_run
 ```
 2. **Wipe blockchain state:** after reviewing the dry run results, proceed with
 the reset by running:
 ``` bash
 # specify 'datadir' as your node's data directory
 oasis-node unsafe-reset \
-  --datadir=/serverdir/node
+  --datadir=/node/data
 ```
 
 Transitioning confidential ParaTimes to the new network requires local state

docs/node/run-your-node/advanced/copy-state-from-one-node-to-the-other.md

@@ -28,7 +28,7 @@ If an Oasis Node is **not stopped** before its state is copied, its on-disk stat
 
 :::
 
-* Copy the following directories from your synced Oasis Node's working directory (e.g. `/node/`, `/srv/oasis/node`, `/serverdir/node`) to your new Oasis Node's working directory:
+* Copy the following directories from your synced Oasis Node's working directory (e.g. `/node/data`) to your new Oasis Node's working directory:
   * `tendermint/abci-state`
   * `tendermint/data`
 

docs/node/run-your-node/advanced/sync-node-using-state-sync.md

@@ -121,7 +121,7 @@ If you have an existing node that you trust, you can use its status output to
 retrieve the current block height and hash by running:
 
 ```
-oasis-node control status -a unix:/serverdir/node/internal.sock
+oasis-node control status -a unix:/node/data/internal.sock
 ```
 
 This will give you output like the following (non-relevant fields omitted):

docs/node/run-your-node/maintenance/handling-network-upgrades.md

@@ -64,7 +64,7 @@ While waiting for the network upgrade epoch, you can check the current height
 and epoch by running:
 
 ```bash
-oasis-node control status -a unix:/serverdir/node/internal.sock
+oasis-node control status -a unix:/node/data/internal.sock
 ```
 
 and observe the value of the `consensus.latest_height` and
@@ -115,7 +115,7 @@ State Changes], [Cobalt upgrade's Proposed State Changes]).
 ### Download and Verify the Provided Genesis File {#verify-genesis}
 
 In addition, download the new genesis file linked in the [Network Parameters]
-and save it as `/serverdir/etc/genesis.json`.
+and save it as `/node/etc/genesis.json`.
 
 Compare the dumped state with the downloaded genesis file:
 
@@ -328,7 +328,7 @@ you should use one. However, to start the node without a process manager you
 can start the [Oasis Node](../prerequisites/oasis-node.md) like this:
 
 ```bash
-oasis-node --config /serverdir/etc/config.yml
+oasis-node --config /node/etc/config.yml
 ```
 
 ## Clean Up

docs/node/run-your-node/maintenance/refreshing-certificates.md

@@ -4,7 +4,7 @@
 
 ### Steps on the Validator Node
 
-Go to your validator node's data directory, e.g. `/srv/oasis`, `/node`, `/serverdir/node`:
+Go to your validator node's data directory, e.g. `/node/data`:
 
 ```
 cd <PATH-TO-DATADIR>
@@ -85,7 +85,7 @@ The validator node will re-register itself automatically once it's connected to
 
 ### Steps on the Sentry Node
 
-Go to your sentry node's data directory, e.g. `/srv/oasis`, `/node`, `/serverdir/node`:
+Go to your sentry node's data directory, e.g. `/node/data`:
 
 ```
 cd <PATH-TO-DATADIR>
@@ -141,7 +141,7 @@ worker:
   registration:
     # In order for the node to register itself the entity.json of the entity
     # used to provision the node must be available on the node.
-    entity: /serverdir/node/entity/entity.json
+    entity: /node/etc/entity.json
   sentry:
     address:
       - "{{ sentry_node_grpc_public_key }}@{{ sentry_node_private_ip }}:9009"

docs/node/run-your-node/maintenance/wiping-node-state.md

@@ -7,7 +7,7 @@ severe corruption, it's important to note that your node will need some time to
 catch up with the rest of the network.
 
 The following instructions are based on the assumption that you have defined
-your `datadir` as `/serverdir/node` in your node's configuration.
+your `datadir` as `/node/data` in your node's configuration.
 
 ## State Wipe and Keep Node Identity
 
@@ -28,12 +28,12 @@ setup).
     ```bash
     # Do a dry run first to see which files will get deleted.
     oasis-node unsafe-reset \
-      --datadir=/serverdir/node \
+      --datadir=/node/data \
       --dry_run
 
     # Delete.
     oasis-node unsafe-reset \
-      --datadir /serverdir/node
+      --datadir /node/data
     ```
 3. Start the `oasis-node` server process.
 
@@ -43,14 +43,14 @@ setup).
 encounter the following error:
 
 ```
-common/Mkdir: path '/serverdir/node' has invalid owner: 1000. Expected owner: 0
+common/Mkdir: path '/node/data' has invalid owner: 1000. Expected owner: 0
 ```
 
 you need to run the `oasis-node` command as the exact user that owns the files,
 e.g.:
 
 ```
-sudo --user=#1000 -- oasis-node unsafe-reset --datadir=/serverdir/node --dry_run --log.level info
+sudo --user=#1000 -- oasis-node unsafe-reset --datadir=/node/data --dry_run --log.level info
 ```
 
 :::
@@ -70,6 +70,6 @@ To perform a full state wipe follow these steps:
 
 1. Stop the `oasis-node` server process (this will depend on your own deployment
 setup)
-2. Remove the `/serverdir/node` directory.
+2. Remove the `/node/data` directory.
 3. Redeploy your node. You'll need to copy your Node artifacts or create brand
 new ones.

docs/node/run-your-node/prerequisites/system-configuration.mdx

@@ -85,7 +85,7 @@ where this is done is a misconfiguration.
 :::info
 In these examples, we change the setup to run Oasis Services (e.g. Oasis Node)
 with a non-root system user named `oasis`.
-These instructions also assume that the node's datadir is `/serverdir/node`.
+These instructions also assume that the node's datadir is `/node/data`.
 
 Adjust these as appropriate to your setup.
 :::
@@ -139,7 +139,7 @@ logging-in as this user.
 3. Transfer ownership of the datadir to the `oasis` user:
 
 ```sh
-chown -R oasis /serverdir/node
+chown -R oasis /node/data
 ```
 
 See [Invalid Permissions] troubleshooting guide for more information.
@@ -168,8 +168,8 @@ After=network.target
 [Service]
 Type=simple
 User=oasis
-WorkingDirectory=/serverdir/node
-ExecStart=/serverdir/bin/oasis-node --config /serverdir/etc/config.yml
+WorkingDirectory=/node/data
+ExecStart=/node/bin/oasis-node --config /node/etc/config.yml
 Restart=on-failure
 RestartSec=3
 LimitNOFILE=1024000

docs/node/run-your-node/sentry-node.md

@@ -21,7 +21,7 @@ Before following this guide, make sure you've read the [Prerequisites](prerequis
 Sentry node identity keys can be initialized with:
 
 ```bash
-oasis-node identity init --datadir /serverdir/node
+oasis-node identity init --datadir /node/data
 ```
 
 ### Configuring Sentry Node
@@ -37,7 +37,7 @@ Before using this configuration you should collect the following information to
 * `{{ validator_tendermint_id }}`: This is the Tendermint ID (address) of the Oasis validator node that will be protected by the sentry node. This address can be obtained by running:
 
   ```bash
-  oasis-node identity tendermint show-node-address --datadir /serverdir/node
+  oasis-node identity tendermint show-node-address --datadir /node/data
   ```
 
   on the validator node.
@@ -46,7 +46,7 @@ Before using this configuration you should collect the following information to
 * `{{ validator_sentry_client_grpc_public_key }}`: This is the public TLS key of the Oasis validator node that will be protected by the sentry node. This public key can be obtained by running:
 
   ```bash
-   oasis-node identity show-sentry-client-pubkey --datadir /serverdir/node
+   oasis-node identity show-sentry-client-pubkey --datadir /node/data
   ```
 
   on the validator node. Note that the above command is only available in `oasis-node` from version 20.8.1 onward.
@@ -69,8 +69,8 @@ Before using this configuration you should collect the following information to
 ##
 
 # Set this to where you wish to store node data. The node artifacts
-# should also be located in this directory (for us this is /serverdir/node)
-datadir: /serverdir/node
+# should also be located in this directory (for us this is /node/data)
+datadir: /node/data
 
 # Logging.
 #
@@ -93,7 +93,7 @@ log:
 
 # Path to the genesis file for the current version of the network.
 genesis:
-  file: /serverdir/etc/genesis.json
+  file: /node/etc/genesis.json
 
 # Worker configuration.
 worker:
@@ -175,7 +175,7 @@ oasis-node registry node init \
 `SENTRY_CONSENSUS_ID`: This is the Consensus ID of the sentry node in base64 format. This ID can be obtained from `consensus_pub.pem`:
 
 ```bash
-sed -n 2p /serverdir/node/consensus_pub.pem
+sed -n 2p /node/data/consensus_pub.pem
 ```
 
 on the sentry node.
@@ -207,15 +207,15 @@ Before using this configuration you should collect the following information to
 * `{{ sentry_node_grpc_public_key }}`: This is the sentry node's control endpoint TLS public key. This ID can be obtained by running:
 
   ```bash
-   oasis-node identity show-tls-pubkey --datadir /serverdir/node
+   oasis-node identity show-tls-pubkey --datadir /node/data
   ```
 
   on the sentry node. Note that the above command is only available in `oasis-node` from version 20.8.1 onward.
 
 * `{{ sentry_node_tendermint_id }}`: This is the Tendermint ID (address) of the sentry node that will be configured as a Persistent Peer. This ID can be obtained by running:
 
   ```bash
-  oasis-node identity tendermint show-node-address --datadir /serverdir/node
+  oasis-node identity tendermint show-node-address --datadir /node/data
   ```
 
   on the sentry node.
@@ -238,8 +238,8 @@ Before using this configuration you should collect the following information to
 ##
 
 # Set this to where you wish to store node data. The node artifacts
-# should also be located in this directory (for us this is /serverdir/node)
-datadir: /serverdir/node
+# should also be located in this directory (for us this is /node/data)
+datadir: /node/data
 
 # Logging.
 #
@@ -262,14 +262,14 @@ log:
 
 # Path to the genesis file for the current version of the network.
 genesis:
-  file: /serverdir/etc/genesis.json
+  file: /node/etc/genesis.json
 
 # Worker configuration.
 worker:
   registration:
     # In order for the node to register itself the entity.json of the entity
     # used to provision the node must be available on the node.
-    entity: /serverdir/node/entity/entity.json
+    entity: /node/etc/entity.json
   sentry:
     address:
       - "{{ sentry_node_grpc_public_key }}@{{ sentry_node_private_ip }}:9009"

docs/node/run-your-node/troubleshooting.md

@@ -34,7 +34,7 @@ Before you begin troubleshooting we suggest you check all of the following:
 Error Message:
 
 ```text
-common/Mkdir: path '/serverdir/node' has invalid permissions: -rwxr-xr-x
+common/Mkdir: path '/node/data' has invalid permissions: -rwxr-xr-x
 ```
 
 The `entity` and `node` directories both need to have permissions `rwx------`. Make sure you initialize the directory with correct permissions or change them using `chmod`:
@@ -44,16 +44,16 @@ mkdir --mode 700 --parents {entity,node}
 ```
 
 ```bash
-chmod 700 /serverdir/node
-chmod 700 /serverdir/entity
+chmod 700 /node/data
+chmod 700 /node/etc
 ```
 
 #### Permissions for .pem files
 
 Error Message example:
 
 ```text
-signature/signer/file: invalid PEM file permissions 700 on /serverdir/node/identity.pem
+signature/signer/file: invalid PEM file permissions 700 on /node/data/identity.pem
 ```
 
 All `.pem` files should have the permissions `600`. You can set the permissions for all `.pem` files in a directory using the following command:
@@ -62,12 +62,12 @@ All `.pem` files should have the permissions `600`. You can set the permissions
 chmod -R 600 /path/*.pem
 ```
 
-#### Serverdir Ownership
+#### Node directory Ownership
 
-Another possible cause of permission issues is not giving ownership of your `serverdir` to the user running the node (e.g. `docker-host` or replace with your user):
+Another possible cause of permission issues is not giving ownership of your `node/` to the user running the node (e.g. `docker-host` or replace with your user):
 
 ```bash
-chown -R docker-host:docker-host /serverdir
+chown -R docker-host:docker-host /node
 ```
 
 In general, to avoid problems when running docker, specify the user when running `docker` commands by adding the flag `--user $(id -u):$(id -g)`.