cap total connections, and document the P2P port 8444
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 2m12s
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 2m12s
The daemon has always listened on 8444 and nothing published it, so every node built from this image was outbound-only. Publishing it is now a documented choice rather than an omission -- including the two things that are not obvious from the config: peers are told the port from `port` in keys.dat rather than the one you mapped it to (so only 8444:8444 works), and the node's own address is never configured at all, because every peer replaces the hardcoded 127.0.0.1 in the version message with the IP it sees on the socket. An open port needs a brake, hence BITMESSAGE_MAXTOTALCONNECTIONS. It defaults to the PyBitmessage stock 200, so nothing changes for existing users of the image. The key is inserted when the stock config lacks it instead of trusting the substitution: the PyBitmessage clone is unpinned, and a silent no-op would ship a node that looks capped and is not. The API port in the example compose moves to loopback, which is what the README already prescribed.
This commit is contained in:
@@ -14,8 +14,11 @@ The container generates a Bitmessage Deterministic Addresses based on a `BITMESS
|
||||
|
||||
Here are some example snippets to help you get started creating a container.
|
||||
|
||||
The XML-RPC API controls the daemon completely and has no TLS. Set your own
|
||||
credentials and keep the port on loopback.
|
||||
The container has two ports and they are not interchangeable. **8442** is the
|
||||
XML-RPC API: it controls the daemon completely and has no TLS, so set your own
|
||||
credentials and keep it on loopback. **8444** is the Bitmessage P2P port:
|
||||
publish it to let other nodes connect in, leave it unpublished to stay
|
||||
outbound-only. The daemon listens on both inside the container either way.
|
||||
|
||||
## docker-compose
|
||||
|
||||
@@ -33,8 +36,10 @@ services:
|
||||
- BITMESSAGE_SEED_ADDRESSES=1
|
||||
- BITMESSAGE_TTL=172800
|
||||
- BITMESSAGE_STOPRESENDINGAFTERXDAYS=60
|
||||
- BITMESSAGE_MAXTOTALCONNECTIONS=40
|
||||
ports:
|
||||
- 127.0.0.1:8442:8442
|
||||
- 127.0.0.1:8442:8442 # API — loopback only
|
||||
- 8444:8444 # P2P — omit this line to stay outbound-only
|
||||
volumes:
|
||||
- bitmessage:/home/bitmessage
|
||||
|
||||
@@ -52,7 +57,9 @@ docker run -d \
|
||||
-e BITMESSAGE_SEED_ADDRESSES=1 \
|
||||
-e BITMESSAGE_TTL=172800 \
|
||||
-e BITMESSAGE_STOPRESENDINGAFTERXDAYS=60 \
|
||||
-e BITMESSAGE_MAXTOTALCONNECTIONS=40 \
|
||||
-p 127.0.0.1:8442:8442 \
|
||||
-p 8444:8444 \
|
||||
-v bitmessage:/home/bitmessage \
|
||||
registry.bitdeals.org/bitmessage
|
||||
```
|
||||
@@ -64,6 +71,7 @@ Container images are configured using parameters passed at runtime.
|
||||
|Parameter|Function|
|
||||
|:--------|:-------|
|
||||
|-p 127.0.0.1:8442|API port. The daemon always binds `0.0.0.0` inside the container, so what you publish decides who reaches it|
|
||||
|-p 8444|Bitmessage P2P port. Optional: without it the node still connects out to peers, it just cannot be connected to. Must be published as `8444:8444` — see Notes|
|
||||
|-v /home/bitmessage|Data directory: `keys.dat` (identity, settings) and `messages.dat`. Without it the node is a new node after every update|
|
||||
|-e BITMESSAGE_API_USER|XML-RPC API user. Default: `bitmessage_api_user` — change it|
|
||||
|-e BITMESSAGE_API_PASSWORD|XML-RPC API password. Default: `bitmessage_api_password` — change it, see Notes|
|
||||
@@ -72,6 +80,7 @@ Container images are configured using parameters passed at runtime.
|
||||
|-e BITMESSAGE_TTL|The expiration of newly send messages, in seconds. Default: `172800`|
|
||||
|-e BITMESSAGE_STOPRESENDINGAFTERXDAYS|Stop resending unreceived message after X days. Default: `30`|
|
||||
|-e BITMESSAGE_APIVARIANT|provides xml or json-RPC API. Default: `legacy`|
|
||||
|-e BITMESSAGE_MAXTOTALCONNECTIONS|Cap on all connections at once, inbound and outbound together (`maxoutboundconnections` is 8, so this minus 8 is the inbound headroom). Default: `200`, the PyBitmessage stock value — lower it when the P2P port is published|
|
||||
|
||||
# Notes
|
||||
|
||||
@@ -84,3 +93,20 @@ Container images are configured using parameters passed at runtime.
|
||||
- The container turns healthy once the daemon has a network connection, which
|
||||
on a new node takes a few minutes. The start period also covers the startup
|
||||
`VACUUM` of `messages.dat`.
|
||||
- **The P2P port must be published as `8444:8444`.** The daemon tells peers the
|
||||
port from its own config (`port` in `keys.dat`), not the port you mapped it
|
||||
to, so `8555:8444` advertises a port nobody can reach. A different host port
|
||||
needs `extport` in `keys.dat`, which this container does not template.
|
||||
- **Your own address is never configured.** The version message carries a
|
||||
hardcoded `127.0.0.1` that every peer discards in favour of the IP it sees on
|
||||
the socket, and it takes the port from that same message. So a node with 8444
|
||||
published is found by the network on its own, as soon as it connects out —
|
||||
there is no host IP or DNS name to set anywhere. The one exception is a Tor
|
||||
hidden service, which needs an explicit `onionhostname`.
|
||||
- **Publishing 8444 is a deliberate security trade-off.** The daemon runs on
|
||||
Python 2 and already parses untrusted data from its outbound peers, so an open
|
||||
port does not create that exposure — it changes *who* may connect, *when*, and
|
||||
*how many*. The pre-handshake parser becomes reachable by anyone, and the
|
||||
practical risk is resource exhaustion rather than code execution. Keep
|
||||
`BITMESSAGE_MAXTOTALCONNECTIONS` low and put memory and CPU limits on the
|
||||
container.
|
||||
|
||||
Reference in New Issue
Block a user