Add Makefile for production builds
This commit is contained in:
parent
6fd34e3a8c
commit
d015422be7
|
@ -5,3 +5,4 @@ node_modules
|
||||||
*.iml
|
*.iml
|
||||||
bin
|
bin
|
||||||
target
|
target
|
||||||
|
/mutagen.sh
|
||||||
|
|
|
@ -0,0 +1,38 @@
|
||||||
|
# Makefile for production builds. This is not meant, or optimized, for incremental or debug builds. Use the devnet for
|
||||||
|
# development. For the sake of decentralization, we specifically avoid the use of prebuilt containers wherever possible
|
||||||
|
# to increase diversity - operators sourcing their compiler binaries from different sources is a good thing.
|
||||||
|
|
||||||
|
SHELL = /usr/bin/env bash
|
||||||
|
MAKEFLAGS += --no-builtin-rules
|
||||||
|
|
||||||
|
PREFIX ?= /usr/local
|
||||||
|
OUT = build
|
||||||
|
BIN = $(OUT)/bin
|
||||||
|
|
||||||
|
.PHONY: dirs
|
||||||
|
dirs: Makefile
|
||||||
|
@mkdir -p $(BIN)
|
||||||
|
|
||||||
|
.PHONY: install
|
||||||
|
install: bridge
|
||||||
|
install -m 744 $(BIN)/* $(PREFIX)/bin
|
||||||
|
setcap cap_ipc_lock=+ep $(PREFIX)/guardiand
|
||||||
|
|
||||||
|
.PHONY: generate
|
||||||
|
generate: dirs
|
||||||
|
./generate-protos.sh
|
||||||
|
|
||||||
|
.PHONY: bridge
|
||||||
|
bridge: $(BIN)/guardiand
|
||||||
|
|
||||||
|
.PHONY: $(BIN)/guardiand
|
||||||
|
$(BIN)/guardiand: dirs
|
||||||
|
cd bridge && go build -o mod=readonly -o ../$(BIN)/guardiand github.com/certusone/wormhole/bridge
|
||||||
|
|
||||||
|
.PHONY: agent
|
||||||
|
agent: $(BIN)/guardiand-solana-agent
|
||||||
|
|
||||||
|
.PHONY: $(BIN)/guardiand-solana-agent
|
||||||
|
$(BIN)/guardiand-solana-agent: dirs
|
||||||
|
cd solana/agent && cargo build --release
|
||||||
|
cp solana/target/release/agent $(BIN)/guardiand-solana-agent
|
|
@ -68,45 +68,38 @@ git checkout <the stable tag you want to compile>
|
||||||
Then, compile the release binaries as an unprivileged build user:
|
Then, compile the release binaries as an unprivileged build user:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# this doesn't actually work yet - the Makefile has yet to be written
|
|
||||||
# TOOD: https://github.com/certusone/wormhole/issues/120
|
|
||||||
make agent bridge
|
make agent bridge
|
||||||
|
|
||||||
# Install binaries to /usr/local/bin in case of a local compilation workflow.
|
|
||||||
sudo make install
|
|
||||||
```
|
```
|
||||||
|
|
||||||
You'll end up with the following binaries in `build/`:
|
You'll end up with the following binaries in `build/`:
|
||||||
|
|
||||||
- `wormhole-guardiand` is the main Wormhole bridge node software.
|
- `guardiand` is the main Wormhole bridge node software.
|
||||||
- `wormhole-solana-agent` is a helper service which runs alongside Wormhole and exposes a gRPC API
|
- `guardiand-solana-agent` is a helper service which runs alongside Wormhole and exposes a gRPC API
|
||||||
for Wormhole to interact with Solana and the Wormhole contract on Solana.
|
for Wormhole to interact with Solana and the Wormhole contract on Solana.
|
||||||
- `wormhole-solana-cli` is a CLI you can use to manually interact with the Wormhole contract on Solana.
|
|
||||||
You don't strictly need this on a production machine, but it can be useful for debugging.
|
|
||||||
|
|
||||||
Consider these recommendations, not a tutorial to be followed blindly. You'll want to integrate this with your
|
Consider these recommendations, not a tutorial to be followed blindly. You'll want to integrate this with your
|
||||||
existing build pipeline. If you need Dockerfile examples, you can take a look at our devnet deployment.
|
existing build pipeline. If you need Dockerfile examples, you can take a look at our devnet deployment.
|
||||||
|
|
||||||
|
If you want to compile and deploy locally, you can run `sudo make install` to install the binaries to /usr/local/bin.
|
||||||
|
|
||||||
|
If you deploy using a custom pipeline, you need to set the `CAP_IPC_LOCK` capability on the binary (e.g. doing the
|
||||||
|
equivalent to `sudo setcap cap_ipc_lock=+ep`) to allow it to lock its memory pages to prevent them from being paged out.
|
||||||
|
See below on why - this is a generic defense-in-depth mitigation which ensures that process memory is never swapped out
|
||||||
|
to disk. Please create a GitHub issue if this extra capability represents an operational or compliance concern.
|
||||||
|
|
||||||
## Key Generation
|
## Key Generation
|
||||||
|
|
||||||
To generate a guardian key, you only need to only build the Go bridge.
|
To generate a guardian key, install guardiand first. If you generate the key on a separate machine, you may want to
|
||||||
|
compile guardiand only, without compiling the agent or installing it:
|
||||||
|
|
||||||
It requires [Go](https://golang.org/dl/) >= 1.15.5. Clone the Wormhole repo
|
make bridge
|
||||||
and build the binary:
|
sudo setcap cap_ipc_lock=+ep ./build/bin/guardiand
|
||||||
|
|
||||||
git clone https://github.com/certusone/wormhole
|
Generate a new key using the `keygen` subcommand:
|
||||||
cd wormhole/
|
|
||||||
./generate-protos.sh
|
|
||||||
cd bridge/
|
|
||||||
go build github.com/certusone/wormhole/bridge
|
|
||||||
sudo setcap cap_ipc_lock=+ep ./bridge
|
|
||||||
|
|
||||||
Then, generate a new key:
|
guardiand keygen --desc "Testnet key foo" /path/to/your.key
|
||||||
|
|
||||||
./bridge keygen --desc "Testnet key foo" /path/to/your.key
|
The key file includes a human-readable part that includes the public key and the description.
|
||||||
|
|
||||||
The key file includes a human-readable part that includes the public key
|
|
||||||
and the description.
|
|
||||||
|
|
||||||
## Deploying
|
## Deploying
|
||||||
|
|
||||||
|
@ -145,7 +138,7 @@ storage or an HSM/vault whenever the node is rebooted. You might want to disable
|
||||||
specific to Wormhole - this applies to any hot keys.
|
specific to Wormhole - this applies to any hot keys.
|
||||||
|
|
||||||
Our node software takes extra care to lock memory using mlock(2) to prevent keys from being swapped out to disk, which
|
Our node software takes extra care to lock memory using mlock(2) to prevent keys from being swapped out to disk, which
|
||||||
is why it requires extra capabilities.
|
is why it requires extra capabilities. Yes, other chains might want to do this too :-)
|
||||||
|
|
||||||
Storing keys on an HSM or using remote signers only partially mitigates the risk of server compromise - it means the key
|
Storing keys on an HSM or using remote signers only partially mitigates the risk of server compromise - it means the key
|
||||||
can't get stolen, but an attacker could still cause the HSM to sign malicious payloads. Future iterations of Wormhole
|
can't get stolen, but an attacker could still cause the HSM to sign malicious payloads. Future iterations of Wormhole
|
||||||
|
|
Loading…
Reference in New Issue