Skip to content
Bl4DiEDiEBL4 edited this page Aug 5, 2026 · 3 revisions

Docker

Docker support is optional. Build the images from a local checkout on each machine, then run the master, slave, and sitebot containers from those local images.

For real installs, start with the deploy pack:

cd docker/deploy

It contains:

  • master-sitebot.compose.yml - master machine services
  • slave.compose.yml - remote slave machine service
  • init.sh - creates runtime config/data directories
  • master.env.example
  • slave.env.example

The Dockerfile has two build targets:

Target Binary Use
daemon weaveftpd master or slave daemon
sitebot sitebot IRC announce bot

Networking

The compose file uses host networking. That is intentional for FTP:

  • PASV/CPSV replies need the real host address.
  • Passive FTP often needs a wide port range.
  • FXP peer checks should see the real remote address.

This setup is meant for Linux servers. Docker Desktop on Windows/macOS does not behave the same way for host networking and FTP passive ports.

Master Machine

Initialize runtime files:

./init.sh master

Edit:

runtime/master/etc/config.yml
runtime/master/sitebot/etc/config.yml
master.env

Start master + sitebot:

docker compose --env-file master.env -f master-sitebot.compose.yml up -d master sitebot
docker compose --env-file master.env -f master-sitebot.compose.yml logs -f master sitebot

If the same machine should also be a storage slave:

docker compose --env-file master.env -f master-sitebot.compose.yml --profile local-slave up -d
docker compose --env-file master.env -f master-sitebot.compose.yml logs -f master sitebot local-slave

The local slave config is:

runtime/master/etc/config-slave-local.yml

It connects to 127.0.0.1:1099 because the containers use host networking. init.sh master also creates a LOCAL 127.0.0.1 source mask so the local slave can authenticate without an extra SITE command.

Remote Slave Machine

Initialize runtime files:

MASTER_HOST="203.0.113.10" SLAVE_NAME="SLAVE1" ./init.sh slave

Edit:

runtime/slave/etc/config.yml
slave.env

Before starting a mask-authenticated remote slave, register its source address on the master:

SITE SLAVE SLAVE1 ADDMASK 203.0.113.20/32

For mTLS, generate a client identity with ./setup.sh slavecert SLAVE1, copy the master CA and that slave's certificate/key into runtime/slave/etc/certs, and configure the three certificate paths in the slave config. See Master-Slave Authentication.

Start the slave:

docker compose --env-file slave.env -f slave.compose.yml up -d slave
docker compose --env-file slave.env -f slave.compose.yml logs -f slave

FIFO And Sitebot

The sitebot should run on the master machine. It reads daemon events from a local FIFO:

/app/etc/weaveftpd.sitebot.fifo

Separate master and sitebot containers are fine because both mount:

runtime/master/etc:/app/etc

Remote slaves do not need the FIFO and do not need the sitebot. Do not put the sitebot on a different machine unless you also add a network event transport; a POSIX FIFO is local filesystem IPC.

Manual Config Notes

Create normal runtime configs on the host:

cp etc/config-example.yml etc/config.yml
cp etc/config-slave-example.yml etc/config-slave.yml
cp sitebot/etc/config.yml.example sitebot/etc/config.yml

Inside the container, the repository is mounted under /app. Adjust the paths that the daemon and sitebot share:

# etc/config.yml
event_fifo: "/app/etc/weaveftpd.sitebot.fifo"
sitebot_config: "/app/sitebot/etc/config.yml"

# sitebot/etc/config.yml
event_fifo: "/app/etc/weaveftpd.sitebot.fifo"

Use container paths for certs and local storage too:

tls_cert: "/app/etc/certs/server.crt"
tls_key: "/app/etc/certs/server.key"
storage_path: "/app/site"

For a slave:

slave:
  roots:
    - "/app/site"

Local Build

Build the images locally:

docker compose build

Run only the master:

docker compose up -d master
docker compose logs -f master

Run master plus sitebot:

docker compose --profile sitebot up -d master sitebot
docker compose logs -f master sitebot

Run only the slave service on a slave box:

docker compose --profile slave up -d slave
docker compose logs -f slave

Permissions

The compose file defaults to root inside the container so existing bind-mounted etc, logs, userdata, and site directories keep working.

To run as your host user instead, make the mounted directories writable by that user and set:

export WEAVEFTPD_UID="$(id -u)"
export WEAVEFTPD_GID="$(id -g)"
docker compose up -d master

Keep real configs, certs, user files, logs, and site data mounted from the host. Do not bake them into the image.

Clone this wiki locally