[Merged by Bors] - Minor revision to Lighthouse Book on validator-manager

book/src/faq.md

@@ -40,6 +40,7 @@
 - [How do I check the version of Lighthouse that is running?](#misc-version)
 - [Does Lighthouse have pruning function like the execution client to save disk space?](#misc-prune)
 - [Can I use a HDD for the freezer database and only have the hot db on SSD?](#misc-freezer)
+- [Can Lighthouse log in local timestamp instead of UTC?](#misc-timestamp)
 
 ## Beacon Node
 
@@ -436,25 +437,40 @@ Monitoring](./validator-monitoring.md) for more information. Lighthouse has also
 
 ### <a name="net-bn-vc"></a> My beacon node and validator client are on different servers. How can I point the validator client to the beacon node?
 
-The settings are as follows:
-
-1. On the beacon node: 
-
-   Specify `lighthouse bn --http-address local_IP` so that the beacon node is listening on the local network rather than on the `localhost`. 
-
-1. On the validator client:
+The setting on the beacon node is the same for both cases below. In the beacon node, specify `lighthouse bn --http-address local_IP` so that the beacon node is listening on the local network rather than `localhost`. You can find the `local_IP` by running the command `hostname -I | awk '{print $1}'` on the server running the beacon node.
 
+1. If the beacon node and validator clients are on different servers *in the same network*, the setting in the validator client is as follows:
+
    Use the flag `--beacon-nodes` to point to the beacon node. For example, `lighthouse vc --beacon-nodes http://local_IP:5052` where `local_IP` is the local IP address of the beacon node and `5052` is the default `http-port` of the beacon node.
 
+   If you have firewall setup, e.g., `ufw`, you will need to allow port 5052 (assuming that the default port is used) with `sudo ufw allow 5052`.
+
    You can test that the setup is working with by running the following command on the validator client host:
 
    ```bash
    curl "http://local_IP:5052/eth/v1/node/version"
    ```
 
    You can refer to [Redundancy](./redundancy.md) for more information.
-
-   It is also worth noting that the `--beacon-nodes` flag can also be used for redundancy of beacon nodes. For example, let's say you have a beacon node and a validator client running on the same host, and a second beacon node on another server as a backup. In this case, you can use `lighthouse vc --beacon-nodes http://localhost:5052, http://local_IP:5052` on the validator client.
+
+2. If the beacon node and validator clients are on different servers *and different networks*, it is necessary to perform port forwarding of the SSH port (e.g., the default port 22) on the router, and also allow firewall on the SSH port. The connection can be established via port forwarding on the router.
+
+
+
+      In the validator client, use the flag `--beacon-nodes` to point to the beacon node. However, since the beacon node and the validator client are on different networks, the IP address to use is the public IP address of the beacon node, i.e., `lighthouse vc --beacon-nodes http://public_IP:5052`. You can get the public IP address of the beacon node by running the command ` dig +short myip.opendns.com @resolver1.opendns.com` on the server running the beacon node.
+
+      Additionally, port forwarding of port 5052 on the router connected to the beacon node is required for the vc to connect to the bn. To do port forwarding, refer to [how to open ports](./advanced_networking.md#how-to-open-ports).
+
+
+      If you have firewall setup, e.g., `ufw`, you will need to allow connections to port 5052 (assuming that the default port is used). Since the beacon node HTTP/HTTPS API is public-facing (i.e., the 5052 port is now exposed to the internet due to port forwarding), we strongly recommend users to apply IP-address filtering to the BN/VC connection from malicious actors. This can be done using the command:
+
+      ```
+      sudo ufw allow from vc_IP_address proto tcp to any port 5052
+      ```
+      where `vc_IP_address` is the public IP address of the validator client. The command will only allow connections to the beacon node from the validator client IP address to prevent malicious attacks on the beacon node over the internet.
+
+
+It is also worth noting that the `--beacon-nodes` flag can also be used for redundancy of beacon nodes. For example, let's say you have a beacon node and a validator client running on the same host, and a second beacon node on another server as a backup. In this case, you can use `lighthouse vc --beacon-nodes http://localhost:5052, http://IP-address:5052` on the validator client.
 
 ### <a name="net-ip"></a> Should I do anything to the beacon node or validator client settings if I have a relocation of the node / change of IP address?
 No. Lighthouse will auto-detect the change and update your Ethereum Node Record (ENR). You just need to make sure you are not manually setting the ENR with `--enr-address` (which, for common use cases, this flag is not used).
@@ -513,11 +529,9 @@ There is no pruning of Lighthouse database for now. However, since v4.2.0, a fea
 
 Yes, you can do so by using the flag `--freezer-dir /path/to/freezer_db` in the beacon node.
 
+### <a name="misc-timestamp"></a> Can Lighthouse log in local timestamp instead of UTC?
 
-
-
-
-
+The reason why Lighthouse logs in UTC is due to the dependency on an upstream library that is [yet to be resolved](https://github.com/sigp/lighthouse/issues/3130). Alternatively, using the flag `disable-log-timestamp` in combination with systemd will suppress the UTC timestamps and print the logs in local timestamps. 
 
 
 

book/src/validator-manager-create.md

@@ -124,7 +124,6 @@ The command will create two files:
 The VC which will receive the validators needs to have the following flags at a minimum:
 
 - `--http`
-- `--http-port 5062`
 - `--enable-doppelganger-protection`
 
 Therefore, the VC command might look like:
@@ -133,7 +132,6 @@ Therefore, the VC command might look like:
 lighthouse \
     vc \
     --http \
-    --http-port 5062 \
     --enable-doppelganger-protection
 ```
 

book/src/validator-manager-move.md

@@ -69,7 +69,6 @@ In reality, many host configurations are possible. For example:
 The source VC needs to have the following flags at a minimum:
 
 - `--http`
-- `--http-port 5062`
 - `--http-allow-keystore-export`
 
 Therefore, the source VC command might look like:
@@ -78,7 +77,6 @@ Therefore, the source VC command might look like:
 lighthouse \
     vc \
     --http \
-    --http-port 5062 \
     --http-allow-keystore-export
 ```
 
@@ -87,7 +85,6 @@ lighthouse \
 The destination VC needs to have the following flags at a minimum:
 
 - `--http`
-- `--http-port 5062`
 - `--enable-doppelganger-protection`
 
 Therefore, the destination VC command might look like:
@@ -96,7 +93,6 @@ Therefore, the destination VC command might look like:
 lighthouse \
     vc \
     --http \
-    --http-port 5062 \
     --enable-doppelganger-protection
 ```
 
@@ -167,6 +163,7 @@ At the same time, `lighthouse vc` will log:
 INFO Importing keystores via standard HTTP API, count: 1
 INFO Enabled validator                       voting_pubkey: 0xab6e29f1b98fedfca878edce2b471f1b5ee58ee4c3bd216201f98254ef6f6eac40a53d74c8b7da54f51d3e85cacae92f, signing_method: local_keystore
 INFO Modified key_cache saved successfully
+``````
 Once the operation completes successfully, there is nothing else to be done. The
 validators have been removed from the `src-host` and enabled at the `dest-host`.
 If the `--enable-doppelganger-protection` flag was used it may take 2-3 epochs