Compare commits
2 commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
125c4edb49 | ||
|
|
a2197547c1 |
3 changed files with 126 additions and 66 deletions
documents/resources
125
documents/resources/bt-tracker.md
Normal file
125
documents/resources/bt-tracker.md
Normal file
|
|
@ -0,0 +1,125 @@
|
|||
---
|
||||
title: Hosting a BitTorrent UDP Tracker
|
||||
description: Setting up a tracker for use with LBRY P2P.
|
||||
---
|
||||
|
||||
*Warning: Unfortunately, some hosting providers explicitly forbids running a tracker in the ToS. Check with your ISP or VPS before running one yourself.*
|
||||
|
||||
The main difference from this guide to any other BitTorrent tracker guide is that it contains optional instructions for configuring a default peer IP fallback from a reflector node in the LBRY network.
|
||||
The software we are going to use is a [fork of chihaya](https://github.com/lbryio/tracker) with support for this optional feature of using default peer IPs.
|
||||
|
||||
# Configuration
|
||||
A default configuration can be found at `dist/example_config.yaml`.
|
||||
This is an example for an UDP server running on 6969 with metrics enabled. Remember to **change the private key** to some random string.
|
||||
|
||||
Also, "fixed peers" prehook is enabled with default IPs. This will include reflector on responses. Discard the section to disable it or ask around on Discord for different servers. Enabling it helps as a fallback for content with no seeds.
|
||||
```
|
||||
---
|
||||
tracker:
|
||||
announce_interval: "30m"
|
||||
min_announce_interval: "15m"
|
||||
metrics_addr: "0.0.0.0:6880"
|
||||
udp:
|
||||
addr: "0.0.0.0:6969"
|
||||
max_clock_skew: "10s"
|
||||
private_key: ">>>>CHANGE THIS TO SOME RANDOM THING<<<<"
|
||||
enable_request_timing: false
|
||||
allow_ip_spoofing: false
|
||||
max_numwant: 100
|
||||
default_numwant: 50
|
||||
max_scrape_infohashes: 50
|
||||
storage:
|
||||
name: "memory"
|
||||
config:
|
||||
gc_interval: "3m"
|
||||
peer_lifetime: "31m"
|
||||
shard_count: 1024
|
||||
prometheus_reporting_interval: "1s"
|
||||
prehooks:
|
||||
- name: "fixed peers"
|
||||
options:
|
||||
fixed_peers:
|
||||
- 51.81.57.64:5567
|
||||
- 135.148.122.112:5567
|
||||
```
|
||||
|
||||
# Running from Docker
|
||||
|
||||
This section assumes `docker` and `docker-compose` to be installed on a Linux distro. Please check official docs on how to install [Docker Engine](https://docs.docker.com/engine/install/) and [Docker Compose](https://docs.docker.com/compose/install/).
|
||||
|
||||
## Setting up
|
||||
In order to define a tracker service and let Docker Compose manage it, create a file named `docker-compose.yml` with:
|
||||
```
|
||||
version: "3"
|
||||
services:
|
||||
tracker:
|
||||
image: lbry/tracker
|
||||
command: --config /config/conf.yml
|
||||
volumes:
|
||||
- .:/config
|
||||
network_mode: host
|
||||
restart: always
|
||||
```
|
||||
Unfortunately the tracker does not work without `network_mode: host` due some bug with UDP on Docker. In this mode, firewall configuration needs to be done manually. If using `ufw`, try `ufw allow 6969`.
|
||||
|
||||
Now, move the configuration to the same directory as `docker-compose.yml`, naming it `conf.yml`. If it is not ready, check the configuration section above.
|
||||
|
||||
Start the tracker by running the following in the same directory as the compose file:
|
||||
`docker-compose up -d`
|
||||
Logs can be read with:
|
||||
`docker-compose logs`
|
||||
To stop:
|
||||
`docker-compose down`
|
||||
|
||||
## Building the containter (optional)
|
||||
A Dockerfile is provided within the repo. To build the container locally, run this command on the same directory the repo was cloned:
|
||||
`sudo docker build -f Dockerfile . -t some_name/tracker:latest`
|
||||
It will produce an image called `some_name/tracker`, which can be used in the Docker Compose section.
|
||||
|
||||
# Running from source as a service
|
||||
|
||||
Up to date guide will always live in the [chihaya repo](https://github.com/chihaya/chihaya#getting-started).
|
||||
|
||||
This section assumes Go language compiler to be installed. If that is not the case, please follow the [official instructions](https://go.dev/doc/install).
|
||||
|
||||
## Cloning and compiling
|
||||
```bash
|
||||
git clone https://github.com/lbryio/tracker.git
|
||||
cd tracker
|
||||
go build ./cmd/chihaya
|
||||
./chihaya --help
|
||||
```
|
||||
|
||||
## Running
|
||||
After configuring
|
||||
```bash
|
||||
./chihaya --config path/to/your/config.yaml
|
||||
```
|
||||
|
||||
For ease of maintenance, it is recommended to run the tracker as a service. As there are many ways of doing it, please check a guide on `init`, `systemd` or the way your operating system distribution recommends.
|
||||
|
||||
This is an example for running it under as the current user using `systemd`:
|
||||
```
|
||||
[Unit]
|
||||
Description=Chihaya BT tracker
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
#User=chihaya
|
||||
#Group=chihaya
|
||||
WorkingDirectory=/home/user/github/tracker
|
||||
ExecStart=/home/user/github/tracker/chihaya --config dist/example_config.yaml
|
||||
Restart=on-failure
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
To try it, change `/home/user/github/tracker` to where the code was cloned and run:
|
||||
```bash=
|
||||
mkdir -p ~/.config/systemd/user
|
||||
# PASTE FILE IN ~/.config/systemd/user/tracker.service
|
||||
systemctl --user enable tracker
|
||||
systemctl --user start tracker
|
||||
systemctl --user status tracker
|
||||
```
|
||||
|
|
@ -54,7 +54,7 @@ Configuration options are organized by their respective areas: Files, Wallet, Ne
|
|||
| known_dht_nodes | list | ['lbrynet1.lbry.com:4444'] | ['myDHT.lbry.com:4444'] | Bootstrap nodes for network connectivity |
|
||||
| max_connections_per_download | integer | 5 | 10 | Threads used to download blobs |
|
||||
| seek_head_blob_first | boolean | true | false | Search for first data blob after downloading sd blob |
|
||||
| tcp_port | integer | 4444 | 3334 | Port the SDK will listen on |
|
||||
| tcp_port | integer | 3333 | 3334 | Port the SDK will listen on |
|
||||
| concurrent_reflector_uploads| integer | 5 | 10 | Connections to use while uploading data to reflector |
|
||||
| reflect_streams | boolean | true | false | Send published data to reflector servers |
|
||||
| reflector_servers | list | ['reflector.lbry.com'] | ['myreflector.lbry.com'] | Server data will be reflected to |
|
||||
|
|
|
|||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
title: LBRY P2P: Settings and troubleshooting
|
||||
description: Guide on properly setting up P2P nodes and how to diagnose/fix common issues.
|
||||
---
|
||||
|
||||
# LBRY P2P: Settings and troubleshooting
|
||||
|
||||
A very important step in supporting the network resilience is hosting content in a decentralized way. This already happens when you stream content using the desktop version of LBRY APP, but sometimes we want to make sure this is working or dedicate larger amounts of resources for this task.
|
||||
|
||||
This document aims to explain P2P configuration and troubleshooting from small to large nodes. If you don't know how to change SDK settings, check [this other document first](https://lbry.tech/resources/daemon-settings).
|
||||
|
||||
## Reachability
|
||||
The first priority when seeding content is making sure there is a way for other nodes to reach you across the internet.
|
||||
|
||||
### Figuring out your ports
|
||||
In order to troubleshoot reachability, we start by checking your configuration for the UDP and TCP ports. By default, they will both be set to 4444. Those can be found on the configuration under the keys `udp_port` and `tcp_port`. Please set them both to the same value as this helps connectivity trough [hole punching](https://en.wikipedia.org/wiki/Hole_punching_(networking)) and ease of management.
|
||||
|
||||
### Checking for reachability
|
||||
There are some websites providing generic ways to check ports, like:
|
||||
- https://www.portcheckers.com/
|
||||
- https://portchecker.co/check
|
||||
|
||||
However, checking the port does not check if LBRY P2P protocol is working behind it. For a better check, we can use a tool hosted by Madiator, a community member.
|
||||
- To test for UDP (DHT): http://test.madiator.com:60666/dht/<your `udp_port`>
|
||||
- To test for TCP (P2P): http://test.madiator.com:60666/p2p/<your `tcp_port`>
|
||||
|
||||
As a last resource to test a remote machine DHT service, from a local SDK try:
|
||||
```bash
|
||||
lbrynet peer ping <DHT node id> <IP> <port>
|
||||
```
|
||||
|
||||
To find out what the `DHT node id` is, on the target machine run `lbrynet status` and look for `node_id` .
|
||||
|
||||
### I am unreachable. What now?
|
||||
|
||||
VPN users: check with your provider if they feature port forwarding. There are guides specific to each one, like [this one from Mullvad](https://mullvad.net/en/help/port-forwarding-and-mullvad/).
|
||||
|
||||
Domestic routers: there are websites like [this one](https://portforward.com/how-to-port-forward/) providing information on popular router models. Unfortunately, this document would be huge if we added port forwarding instructions for every router/firewall.
|
||||
|
||||
Servers: check if your firewall is blocking the SDK ports. For ufw on Linux, this is `sudo ufw allow <port>`.
|
||||
|
||||
If you still have trouble figuring that out, don't be shy, [ask the LBRY community on Discord!](https://chat.lbry.com/)
|
||||
|
||||
## Content blobs storage settings
|
||||
|
||||
Files in LBRY are composed by `content blobs`, which can be seen as chunks of binary encrypted data belonging to some content. By default, the SDK enables saving blobs to disk, which then can be served over P2P. To check if that is enabled, look for the `save_blobs` setting.
|
||||
|
||||
**The following settings are isolated. The space limit set for one does not apply to the other.**
|
||||
|
||||
### Setting up storage space control
|
||||
|
||||
By default, content blobs are kept as long as the files are still in your file list. If you wish to allocate a space limit for content blobs and let the SDK decide what to delete, set `blob_storage_limit` to a value in megabytes.
|
||||
|
||||
This won't delete your downloads from the file list. Instead, it deletes content blobs associated with older files as space for newer blobs is requested.
|
||||
|
||||
|
||||
### Setting up space for automatic contribution
|
||||
|
||||
This section is aimed at fully automatic contribution in background. Normal usage of the SDK with P2P enabled already helps the network, but requires interaction.
|
||||
|
||||
LBRY SDK can be configured to help the P2P network by automatically downloading and hosting content. This is ideal for contributing spare disk space and network bandwidth without further interaction.
|
||||
|
||||
Enabling: change `network_storage_limit` to the size (in megabytes) that will be used for automatic seeding.
|
||||
|
||||
Disabling: setting the space to 0 disables it. The space used will eventually be released automatically. For cleaning immediately, issue a `lbrynet blob clean` from command line.
|
||||
Loading…
Add table
Add a link
Reference in a new issue