TODO:

• [x] Add test for verify_connection_id
• [x] Move get_connection_id to udp module.
• [x] Move current_time to clock module.
• [x] Add "pepper" to the implementation: https://github.com/torrust/torrust-tracker/pull/60#issuecomment-1214172679
• [x] Write more documentation. Something like my comment here. I think I'm going to use the Rust /// inline documentation in this case.
• [x] Reimplement connection ID generation function using encryption as proposed by @da2ce7 here.
• [x] Use the function verify_connection_id to verify the UDP announce request.
• [x] Refactor handlers to avoid creating the EncryptedConnectionIdIssuer multiple times.
• [x] Generate SALT when the server starts. We call it SERVER_SCRET now.
• [x] Generate a random secret. We are using a fixed one.
• [x] Refactor code to include some improvements from @WarmBeer PR.
• [x] Change the Blowfish crate. The one we are using is deprecated.
• [ ] Refactor code to include some improvements from @da2ce7 PR.

REMOVED FROM TODO:

• [x] Change one of the tests where I use "sleep" instead of mocking time. We need to implement a new serializer where we can inject the time. It's out of the scope of this PR and it's only ten milliseconds the delay introduced in the test execution.

Hello, there seems to be an error with packed data when scraping announce both udp and http/s.

The format should be d5:filesd20, but on gbitt and torrust it is random, sometimes it is d5:filesd50, d5:filesd54, etc. Thats why almost all scrapers returns invalid data for info hash.

Seems like it is using aquatic source for scraping, but aquatic returns correct bytes of 20, where torrust doesn't.

@Power2All @WarmBeer

This is a re-work of PR-55 adding more features.

UPDATE ON: 2022/12/16

TASKS

• [x] Docker image
• [X] Publish the docker image manually (https://hub.docker.com/repository/docker/josecelano/torrust-tracker)
• [x] Cache for dependencies in Dockerfile is not working. It compiles all the dependencies every time you build the image.
• [x] Workflow to publish new docker images when new semver tags are created.
• [x] Fix broken test after moving database to storage/database dir.
• [x] Deploy sample app using SQLite with docker on Azure.
• [x] Docker compose configuration using MySQL instead of SQLite for development
• [x] Docker compose configuration using MySQL instead of SQLite for production. Moved to another repo.
• [x] Deploy sample app using MySQL with docker compose on Azure. Moved to another repo.

SUBTASKS (deploy with docker)

This option is a deployment to ACI using only one container with SQLite and no HTTPS.

• [x] Create a certificate with Let's Encrypt and use Rust (no Nginx). DISCARDED (I'll do it in the docker-compose version)
• [x] Enable HTTPS for the API.
• [x] Error duplciate port 6969.

SUBTASKS (deploy with docker-compose)

• [x] Create a certificate with Let's Encrypt and use Nginx. DISCARDED for this PR.
• [x] Auto-renew certificate with certbot. DISCARDED for this PR.
• [x] Use MySQL instead of SQLite

REQUIREMENTS

• Multistage builds with slim/alpine images for production
• Do not execute the container with the root user.
• Try to cache cargo dependencies with cargo-chef
• Build static rust binaries for x86_64 linux environments (without other system library dependencies)
• Consider using certificates for localhost too?
• Use Nginx with certbot on Production for HTTPS.
• Auto-renew certificate with cerbot or Nginx docker image with auto-renew.
• Use Github Actions cache for docker cache: https://docs.docker.com/build/building/cache/backends/gha/
• User semver for docker image tags.

OPTIONAL

• [x] .devcontainer configuration for GitHub Codespaces. DISCARDED for this PR.
• [x] docker compose configuration for docker env environments. DISCARDED for this PR.

LINKS

• https://github.com/docker/awesome-compose
• https://hub.docker.com/repository/docker/josecelano/torrust-tracker
• https://docs.docker.com/cloud/aci-integration/
• https://docs.docker.com/desktop/dev-environments/set-up/
• https://github.com/clux/muslrust
• https://github.com/LukeMathWalker/cargo-chef
• https://letsencrypt.org/docs/certificates-for-localhost/
• https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf
• https://github.com/docker/awesome-compose/tree/master/react-rust-postgres
• https://kerkour.com/rust-small-docker-image

I'm not sure what I may be missing. Everything seem to be working and all categories etc. show up. Account created access seem to work. Doing a test with the debian net ISO and or any other torrent and I get " only .torrent files can be uploaded" even though they are .torrent files.

Is Docker support planned? A docker container for the tracker and backend/frontend would be amazing.

https://blog.logrocket.com/packaging-a-rust-web-service-using-docker/

BEP 15: https://www.bittorrent.org/beps/bep_0015.html

This is what the BEP 15 says about the connection ID:

UDP connections / spoofing In the ideal case, only 2 packets would be necessary. However, it is possible to spoof the source address of a UDP packet. The tracker has to ensure this doesn't occur, so it calculates a value (connection_id) and sends it to the client. If the client spoofed it's source address, it won't receive this value (unless it's sniffing the network). The connection_id will then be send to the tracker again in packet 3. The tracker verifies the connection_id and ignores the request if it doesn't match. Connection IDs should not be guessable by the client. This is comparable to a TCP handshake and a syn cookie like approach can be used to storing the connection IDs on the tracker side. A connection ID can be used for multiple requests. A client can use a connection ID until one minute after it has received it. Trackers should accept the connection ID until two minutes after it has been send.

And this is the current implementation:

pub fn get_connection_id(remote_address: &SocketAddr) -> ConnectionId {
    match std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH) {
        Ok(duration) => ConnectionId(((duration.as_secs() / 3600) | ((remote_address.port() as u64) << 36)) as i64),
        Err(_) => ConnectionId(0x7FFFFFFFFFFFFFFF),
    }
}

Originally posted by @josecelano in https://github.com/torrust/torrust-tracker/issues/60#issuecomment-1210961955

When you run the tracker the first time, you see this output:

No config file found.
Creating config file..
thread 'main' panicked at 'Please edit the config.TOML in the root folder and restart the tracker.', src/main.rs:22:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Running the tracker without the setting file has a side effect. It creates a setting file with the default configuration.

$ cat config.toml
log_level = "info"
mode = "public"
db_driver = "Sqlite3"
db_path = "data.db"
announce_interval = 120
min_announce_interval = 120
max_peer_timeout = 900
on_reverse_proxy = false
external_ip = "0.0.0.0"
tracker_usage_statistics = true
persistent_torrent_completed_stat = false
inactive_peer_cleanup_interval = 600
remove_peerless_torrents = true

[[udp_trackers]]
enabled = false
bind_address = "0.0.0.0:6969"

[[http_trackers]]
enabled = false
bind_address = "0.0.0.0:6969"
ssl_enabled = false
ssl_cert_path = ""
ssl_key_path = ""

[http_api]
enabled = true
bind_address = "127.0.0.1:1212"

[http_api.access_tokens]
admin = "MyAccessToken"

I suggest showing a message like this:

No config file found: "config.toml".
You can create the default settings file running: cargo run --bin install

That "install" binary could be extended in the feature to be an installation assistant if you run it in interactive mode.

But the main reason for this change is I'm working on setting up docker configuration to automate deployments for the Turrust tracker and running a process that returns an error that could lead to errors while building docker images or others tasks.

On the other hand, I always prefer to be explicit about side effects. Besides, showing an error the first time you run a tracker could make people think the application is not good.

If you do not like that approach, the second option could be to ask the user if they want to create that file, but I do not like that option because it forces the app to be always interactive. We should have added an option to avoid that question in this case and return an error message with an error return value (not a panic message).

Commit 7abe0f5bde1e209553d1a1e2d6fe644cd46a9395 introduced an unwanted change. Thread for statistics is always created regardless configuration.

This commit reverts that change. The config option:

config.tracker_usage_statistics

defines wether the statistics should be enabled or not.

Wouldn't it be useful to publish it on https://crates.io/?

I would like to write more documentation for the package. For example, for API endpoints like this:

If we do that, we can automatically have online documentation on https://docs.rs/.

If for some reason, we do not want to publish it yet, we could deploy the documentation to GitHub Pages.

This implementation is very basic and not optimal. However it should be secure and works as a proof of concept.

It works by testing many possible connection cookies for each time extent (a quantified period of time), until one matches. If there are no matches, then the cookie is either expired or otherwise invalid.

TimeExtent is a simple structure that contains base increment (duration), and amount (a multiplier for the base the base increment). The resulting product of the base and the multiplier is the total duration of the time extent.

TimeExtentClock is a helper that generates time extents based upon the increment length and the time of the clock, this clock is specialised according to the test predicate with the DefaultClockExtentMaker type.

These modules will be used by the later connection cookie implementation.

The tracker only needs a database if it wants to persist torrent statistics and private tracker keys between reboots. In all other cases a database should not be necessary.

Hey there!

Is there a document that describes how to set up a tracker and a local client to seed a specific file/folder? In other words, how can I configure a tracker and a seeder-client on my local machine to share a specific file?

When you run the application or the tests you see these warnings:

$ cargo test
   Compiling torrust-tracker v2.3.0 (/home/josecelano/Documents/github/committer/josecelano/torrust/torrust-tracker)
warning: opaque type `impl warp::Filter + Clone + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection>` does not satisfy its associated type bounds
  --> src/api/routes.rs:50:63
   |
50 | pub fn routes(tracker: &Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
   |                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
  ::: /home/josecelano/.cargo/registry/src/github.com-1ecc6299db9ec823/warp-0.3.3/src/filter/mod.rs:40:19
   |
40 |     type Extract: Tuple; // + Send;
   |                   ----- this associated type bound is unsatisfied for `impl Reply`
   |
   = note: `#[warn(opaque_hidden_inferred_bound)]` on by default
help: add this bound
   |
50 | pub fn routes(tracker: &Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
   |                                                                                          ++++++++++++++++++++++

warning: opaque type `impl warp::Filter + Clone + warp::filter::FilterBase<Extract = impl Reply, Error = Infallible>` does not satisfy its associated type bounds
  --> src/http/routes.rs:12:62
   |
12 | pub fn routes(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply, Error = Infallible> + Clone {
   |                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
  ::: /home/josecelano/.cargo/registry/src/github.com-1ecc6299db9ec823/warp-0.3.3/src/filter/mod.rs:40:19
   |
40 |     type Extract: Tuple; // + Send;
   |                   ----- this associated type bound is unsatisfied for `impl Reply`
   |
help: add this bound
   |
12 | pub fn routes(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = Infallible> + Clone {
   |                                                                                         ++++++++++++++++++++++

warning: opaque type `impl warp::Filter + Clone + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection>` does not satisfy its associated type bounds
  --> src/http/routes.rs:19:60
   |
19 | fn announce(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply, Error = Rejection> + Clone {
   |                                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
  ::: /home/josecelano/.cargo/registry/src/github.com-1ecc6299db9ec823/warp-0.3.3/src/filter/mod.rs:40:19
   |
40 |     type Extract: Tuple; // + Send;
   |                   ----- this associated type bound is unsatisfied for `impl Reply`
   |
help: add this bound
   |
19 | fn announce(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = Rejection> + Clone {
   |                                                                                       ++++++++++++++++++++++

warning: opaque type `impl warp::Filter + Clone + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection>` does not satisfy its associated type bounds
  --> src/http/routes.rs:29:58
   |
29 | fn scrape(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply, Error = Rejection> + Clone {
   |                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
  ::: /home/josecelano/.cargo/registry/src/github.com-1ecc6299db9ec823/warp-0.3.3/src/filter/mod.rs:40:19
   |
40 |     type Extract: Tuple; // + Send;
   |                   ----- this associated type bound is unsatisfied for `impl Reply`
   |
help: add this bound
   |
29 | fn scrape(tracker: Arc<tracker::Tracker>) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = Rejection> + Clone {
   |                                                                                     ++++++++++++++++++++++

warning: `torrust-tracker` (lib) generated 4 warnings
warning: `torrust-tracker` (lib test) generated 4 warnings (4 duplicates)

We are going to replace Warp with Axum, so it may not make sense to fix them.

Workflow to publish the crate on crates.io.

It only works if the secret CRATES_TOKEN exists in the crates-io-torrust environment.

Since crates.io does not support scoped tokens, we can publish the crate using a fork where the crate owners can set up their crates.io tokens without sharing them with other maintainers.

Discussed in https://github.com/torrust/torrust-tracker/discussions/132