Skip to content
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion book/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@
* [Authorization Header](./api_vc_auth_header.md)
* [Prometheus Metrics](./api_metrics.md)
* [Lighthouse UI (Siren)](./ui.md)
* [Configuration](./ui_configuration.md)
* [Installation](./ui_installation.md)
* [Authentication](./ui_authentication.md)
* [Usage](./ui_usage.md)
* [FAQs](./ui_faqs.md)
Expand Down
2 changes: 1 addition & 1 deletion book/src/ui.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ The UI is currently in active development. It resides in the
See the following Siren specific topics for more context-specific
information:

- [Configuration Guide](./ui_configuration.md) - Explanation of how to setup
- [Installation Guide](./ui_installation.md) - Explanation of how to setup
and configure Siren.
- [Authentication Guide](./ui_authentication.md) - Explanation of how Siren authentication works and protects validator actions.
- [Usage](./ui_usage.md) - Details various Siren components.
Expand Down
4 changes: 2 additions & 2 deletions book/src/ui_authentication.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,12 @@

## Siren Session

For enhanced security, Siren will require users to authenticate with their session password to access the dashboard. This is crucial because Siren now includes features that can permanently alter the status of the user's validators. The session password must be set during the [configuration](./ui_configuration.md) process before running the Docker or local build, either in an `.env` file or via Docker flags.
For enhanced security, Siren will require users to authenticate with their session password to access the dashboard. This is crucial because Siren now includes features that can permanently alter the status of the user's validators. The session password must be set during the [installation](./ui_installation.md) process before running the Docker or local build, either in an `.env` file or via Docker flags.

![exit](imgs/ui-session.png)

## Protected Actions

Prior to executing any sensitive validator action, Siren will request authentication of the session password. If you wish to update your password please refer to the Siren [configuration process](./ui_configuration.md).
Prior to executing any sensitive validator action, Siren will request authentication of the session password. If you wish to update your password please refer to the Siren [installation process](./ui_installation.md).

![exit](imgs/ui-auth.png)
8 changes: 4 additions & 4 deletions book/src/ui_faqs.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,20 +10,20 @@ The required API token may be found in the default data directory of the validat

## 3. How do I fix the Node Network Errors?

If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui [`configuration`](./ui_configuration.md#configuration).
If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui [`installation`](./ui_installation.md#configuration).

## 4. How do I connect Siren to Lighthouse from a different computer on the same network?

Siren is a webapp, you can access it like any other website. We don't recommend exposing it to the internet; if you require remote access a VPN or (authenticated) reverse proxy is highly recommended.
Siren is a webapp, you can access it like any other website. We don't recommend exposing it to the internet; if you require remote access a VPN or (authenticated) reverse proxy is highly recommended.
That being said, it is entirely possible to have it published over the internet, how to do that goes well beyond the scope of this document but we want to emphasize once more the need for *at least* SSL encryption if you choose to do so.

## 5. How can I use Siren to monitor my validators remotely when I am not at home?

Most contemporary home routers provide options for VPN access in various ways. A VPN permits a remote computer to establish a connection with internal computers within a home network. With a VPN configuration in place, connecting to the VPN enables you to treat your computer as if it is part of your local home network. The connection process involves following the setup steps for connecting via another machine on the same network on the Siren configuration page and [`configuration`](./ui_configuration.md#configuration).
Most contemporary home routers provide options for VPN access in various ways. A VPN permits a remote computer to establish a connection with internal computers within a home network. With a VPN configuration in place, connecting to the VPN enables you to treat your computer as if it is part of your local home network. The connection process involves following the setup steps for connecting via another machine on the same network on the Siren configuration page and [`installation`](./ui_installation.md#configuration).

## 6. Does Siren support reverse proxy or DNS named addresses?

Yes, if you need to access your beacon or validator from an address such as `https://merp-server:9909/eth2-vc` you should configure Siren as follows:
Yes, if you need to access your beacon or validator from an address such as `https://merp-server:9909/eth2-vc` you should configure Siren as follows:
`VALIDATOR_URL=https://merp-server:9909/eth2-vc`

## 7. Why doesn't my validator balance graph show any data?
Expand Down
72 changes: 51 additions & 21 deletions book/src/ui_configuration.md → book/src/ui_installation.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,19 +8,46 @@ To ensure proper functionality, the Siren app requires Lighthouse v4.3.0 or high

## Configuration

Siren requires a connection to both a Lighthouse Validator Client and a Lighthouse Beacon Node.
Siren requires a connection to both a Lighthouse Validator Client and a Lighthouse Beacon Node.

Both the Beacon node and the Validator client need to have their HTTP APIs enabled.
Both the Beacon node and the Validator client need to have their HTTP APIs enabled.
These ports should be accessible from Siren. This means adding the flag `--http` on both beacon node and validator client.

To enable the HTTP API for the beacon node, utilize the `--gui` CLI flag. This action ensures that the HTTP API can be accessed by other software on the same machine.

> The Beacon Node must be run with the `--gui` flag set.

## Running the Docker container (Recommended)
## Running Siren with Docker Compose (Recommended)

We recommend running Siren's container next to your beacon node (on the same server), as it's essentially a webapp that you can access with any browser.

1. Clone the Siren repository:

```
git clone https://github.com/sigp/siren
cd siren
```

1. Copy the example `.env.example` file to `.env`:
```
cp .env.example .env
```

1. Edit the `.env` file filling in the required fields. A beacon node and validator url needs to be
specified as well as the validator clients `API_TOKEN`, which can be obtained from the [`Validator Client Authorization Header`](./api_vc_auth_header.md).

1. Run the containers with docker compose
```
docker compose up -d
```

1. You should now be able to access siren at the url (provided SSL is enabled):
```
https://localhost
```

## Running Siren in Docker

1. Create a directory to run Siren:

```bash
Expand All @@ -29,9 +56,9 @@ We recommend running Siren's container next to your beacon node (on the same ser
cd Siren
```

1. Create a configuration file in the `Siren` directory: `nano .env` and insert the following fields to the `.env` file. The field values are given here as an example, modify the fields as necessary. For example, the `API_TOKEN` can be obtained from [`Validator Client Authorization Header`](./api_vc_auth_header.md)
1. Create a configuration file in the `Siren` directory: `nano .env` and insert the following fields to the `.env` file. The field values are given here as an example, modify the fields as necessary. For example, the `API_TOKEN` can be obtained from

A full example with all possible configuration options can be found [here](https://github.com/sigp/siren/blob/stable/.env.example).
A full example with all possible configuration options can be found [here](https://github.com/sigp/siren/blob/stable/.env.example).

```
BEACON_URL=http://localhost:5052
Expand All @@ -43,32 +70,35 @@ We recommend running Siren's container next to your beacon node (on the same ser
1. You can now start Siren with:

```bash
docker run --rm -ti --name siren --env-file $PWD/.env --net host sigp/siren
docker run -ti --name siren --env-file $PWD/.env -p 443:443 sigp/siren
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if this will still work, without the --net host. @antondlr and I have discussed about this before. Because there are users running BN and VC not using docker (e.g., systemd), so --net host is somehow required

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I guess maybe its the container trying to access local instances. I use the docker compose for this and it works fine.

I guess @antondlr will have to chime in for --net host. My understanding is that it's not needed, but I might be missing something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, age is 100% right. --net=host is dangerous and should not be used lightly.
the problem is, a LOT of our users have setup their nodes with the somer esat guides, which runs CL/EL though systemd and limits the api ports to 127.0.0.1 ... which is not accessible through docker.

a solution for that is to use --add-host=host.docker.internal:host-gateway on linux hosts, buuuutttt that doesn't work when Docker was installed as a Snap (which used to be default on Ubuntu but I think it no longer is?)

I'm not sure how --net=host ever became the default, almost recommended way to run Siren... it should be a last resort fix, and only for people who understand the implications.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For those running BN and VC without docker (systemd), without --net=host, will it work? I get how --net host is no good, is there another way to get around?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I run BN and VC without docker using systemd and what I've written here works perfectly fine.

I think the only case is if they set their HTTP IP in the CLI of BN and VC to 127.0.0.1 then it won't work.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a comment about handling this edge case. I dont think we need --net host. People just need to expose their HTTP API I guess, or add the flag that anton said.

I've commented on this in the docs now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@antondlr could you chime in on this? We discussed before that without --net host, those running systemd will not be able to connect to Siren. Changing the BEACON_URL to http://docker.host.internal:5052 or adding --add-host=host.docker.internal:host-gateway sigp/siren also doesn't work

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we discussed this in detail at devcon, and it is indeed as age says:
either expose the api on 0.0.0.0 (or, their specific IP, or anything else more broad than 127.0.0.1 really), or run Siren with --net=host.

Changing the BEACON_URL to http://docker.host.internal:5052 or adding --add-host=host.docker.internal:host-gateway sigp/siren also doesn't work

you'd have to do both, simultaneously, and this only works for regular docker installs iirc, not for "snap" installs (like you have on your server?). (and it's host.docker.internal not docker.host.internal but that's just a typo I assume?)

I can help debug / find a way for a specific setup like yours but there are no magic solutions here that preserve max security. the tradeoff is between exposing the BN/VC API more broadly, or running Siren with net=host, that will always be the crux of it for setups where Lighthouse doesn't run in Docker.
which of those is "best" is a personal choice; we landed on (ab)using net=host to unblock people because that way, no change to people's running Lighthouse instance would be necessary, but it's definitely not without downsides.
lmk if you want to go over it again why and how this all happens; I can explain in a call but typing it all out would be a course in itself :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I remember, the "lesser of the two evils" - either exposing the API or using --net host

So long as it works, then it's good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the record, this doesn't have anything do with Systemd. I run lighthouse with systemd and without. I don't use the net=host and everything works fine. It is only for users who are not exposing their API, i.e have not set --http-address to .

I expose my HTTP API so I can access it and query things, its only accessible on my internal LAN.

```

Note that, due to the `--net=host` flag, this will expose Siren on ports 3000, 80, and 443. Preferably, only the latter should be accessible. Adjust your firewall and/or skip the flag wherever possible.

If it fails to start, an error message will be shown. For example, the error

1. Siren should be accessible at the url:
```
http://localhost:5062 unreachable, check settings and connection
https://localhost
```

means that the validator client is not running, or the `--http` flag is not provided, or otherwise inaccessible from within the container. Another common error is:
## Possible Docker Errors

```
validator api issue, server response: 403
```
Note that when use SSL, you will get an SSL warning. Advanced users can mount their own certificates or disable SSL altogether, see the `SSL Certificates` section below. This error is safe to ignore.

which means that the API token is incorrect. Check that you have provided the correct token in the field `API_TOKEN` in `.env`.
If it fails to start, an error message will be shown. For example, the error

```
http://localhost:5062 unreachable, check settings and connection
```

When Siren has successfully started, you should see the log `LOG [NestApplication] Nest application successfully started +118ms`, indicating that Siren has started.
means that the validator client is not running, or the `--http` flag is not provided, or otherwise inaccessible from within the container. Another common error is:

1. Siren is now accessible at `https://<the-servers-ip>` (when used with `--net=host`). You will get a warning about an invalid certificate, this can be safely ignored.
```
validator api issue, server response: 403
```

which means that the API token is incorrect. Check that you have provided the correct token in the field `API_TOKEN` in `.env`.

> Note: We recommend setting a strong password when running Siren to protect it from unauthorized access.
When Siren has successfully started, you should see the log `LOG [NestApplication] Nest application successfully started +118ms`, indicating that Siren has started (in the docker logs).

Advanced users can mount their own certificates or disable SSL altogether, see the `SSL Certificates` section below.
> Note: We recommend setting a strong password when running Siren to protect it from unauthorized access.

## Building From Source

Expand Down Expand Up @@ -101,7 +131,7 @@ By default, internally, Siren is running on port 80 (plain, behind nginx), port

[mkcert](https://github.com/FiloSottile/mkcert) is a tool that makes it super easy to generate a self-signed certificate that is trusted by your browser.

To use it for `siren`, install it following the instructions. Then, run `mkdir certs; mkcert -cert-file certs/cert.pem -key-file certs/key.pem 127.0.0.1 localhost` (add or replace any IP or hostname that you would use to access it at the end of this command).
To use it for `siren`, install it following the instructions. Then, run `mkdir certs; mkcert -cert-file certs/cert.pem -key-file certs/key.pem 127.0.0.1 localhost` (add or replace any IP or hostname that you would use to access it at the end of this command).
To use these generated certificates, add this to to your `docker run` command: `-v $PWD/certs:/certs`

The nginx SSL config inside Siren's container expects 3 files: `/certs/cert.pem` `/certs/key.pem` `/certs/key.pass`. If `/certs/cert.pem` does not exist, it will generate a self-signed certificate as mentioned above. If `/certs/cert.pem` does exist, it will attempt to use your provided or persisted certificates.
Expand Down
Loading