Distribution Servers

Overview

Distribution Servers turn an ET Ducky agent into a LAN-local file hub. Instead of every machine pulling installers, packages, or shared files down from the cloud over the WAN, you nominate one agent on a site to host them and serve them to its neighbors over HTTPS on the local network. Large transfers stay on the LAN, where they are fast and don't consume internet bandwidth.

The cloud remains the control plane: it stores the file catalog and access rules, decides who may read or write what, and issues short-lived signed tokens. The file bytes never flow through the ET Ducky cloud on the normal path — they move directly between the requesting machine and the hub agent on your LAN.

How storage works

There are two halves to a Distribution Server: the hub agent's local cache (where the bytes live) and the cloud catalog (where the metadata and access rules live).

Hub cache. When a file is published to a hub, the agent stores it in a content-addressable cache on its own disk — deduplicated by SHA-256, so two files with identical content occupy space once. Each blob has a stable id and a relative path (for example /installers/agent-setup.exe).
Cloud catalog. The cloud keeps a lightweight record per blob — its relative path, size, SHA-256, and tags — plus the connection and access-control rules. It never holds the file contents.
Cache quota. Each hub has a quota you set when you enable it. It can either scale with free disk (use a percentage of whatever space is free) or be a fixed size. When the cache fills, least-recently-used blobs are evicted; they re-populate on demand the next time they're requested.

Because the catalog and the bytes are separate, a file can exist in the catalog before it has been cached on a given hub, and the hub reconciles what it actually holds against the catalog as it heartbeats to the cloud.

Before you begin

You are an organization admin (enabling a hub and editing access rules requires admin rights).
The agent you want to use as a hub is online and reachable by other machines on its LAN.
The hub's listen port (default 8443) is open to the LAN through the host firewall.

Step 1 — Enable an agent as a hub

Open Agents, click the agent you want to host files, and open its Properties. The properties panel includes a Distribution Hub section.

Tick Enabled. The configuration fields appear.
Listen port — the TCP port the hub serves on (default 8443).
Listen interface — LAN only (recommended) binds to the local network interface; All interfaces exposes it more broadly (only if you understand the exposure).
Cache quota policy — Scale with disk (set a % of free disk to use) or Fixed size (set a byte cap).
Click Apply.

The setting is saved in the cloud and delivered to the agent on its next heartbeat, so the listener starts (or stops) within a few seconds — no restart or re-install required. Once the agent reports its listener is ready, it appears in the hub picker when you create a connection.

Step 2 — Create a connection

A connection is the addressable share that clients talk to. It binds one hub agent and carries the access rules.

Go to Integrations → Distribution Servers.
Click Add Connection.
Pick the hub agent you enabled in Step 1 and give the connection a name.
Save. A sensible default access rule is seeded for you, which you refine in Step 3.

Each connection row exposes actions to edit its access rules, create a personal mount key (and manage/revoke existing ones), view its reach state, and delete it.

Step 3 — Grant privileges (access control)

Access is governed by a list of rules on each connection. A rule grants a set of permissions to a principal on a path prefix.

Field	Meaning
Path prefix	The folder the rule applies to, e.g. `/` for the whole share or `/installers` for one folder. Rules apply to that prefix and everything beneath it.
Principal type	Everyone in org (all members), Role (an organization role such as `org:admin`), or User (one specific user).
Principal ID	Required for Role and User — the role name or user id the rule targets. Not needed for "Everyone in org".
Permissions	Any combination of `list`, `read`, `write`, `delete` (comma-separated). Defaults to `list,read`.

The four permissions:

list — see the names of files in a folder (browse / PROPFIND).
read — download file contents.
write — publish or overwrite files.
delete — remove files.

Most-specific rule wins. When more than one rule could apply to a path, the one with the longest matching prefix is used. This lets you grant broad read access at / and a narrower write grant deeper in the tree.

Worked example. A common setup is: Everyone in org gets list,read on / (so anyone can browse and download the share), and the org:admin role gets write,delete on /installers (so only admins can publish installers). Note these are independent grants — with exactly those two rules an admin can write to /installers but, because the most-specific rule there is write/delete only, would need a read or list grant added on /installers to browse it back. When in doubt, grant a single test principal list,read,write,delete on one path to confirm a round trip, then tighten.

Step 4 — Map a drive

Clients reach a connection over WebDAV at https://<hub-lan-ip>:<port>/dav/<label>/. Authentication uses HTTP Basic, where the username is a mount key id and the password is the mount key's secret — a short, long-lived, revocable credential scoped to your permissions. Because it's stable and compact, a mapped drive keeps working across reboots, and you can cut off access at any time by revoking the key.

The <label> is derived from the connection's name, and it's what the mapped drive is named on the client (e.g. a connection named FS-ETDUCKY mounts as a drive called FS-ETDUCKY). The mount details shown when you create a key include the exact URL. In the examples below, replace <hub-ip> with your hub agent's LAN address and 8443 with its listen port if you changed it.

Create a mount key

In Integrations → Distribution Servers, click New mount key on the connection's row (optionally give it a label, such as your device name). You'll get a username and a one-time secret, along with the hub's address. The secret is shown only once — use the Copy button and save it where your OS stores the mapped-drive credential. To review or revoke existing keys later, use Manage keys.

Trust the hub certificate (one-time)

The hub serves a self-signed certificate. WebDAV clients won't mount until that certificate is trusted by the operating system — this is a one-time step per device. On machines running the ET Ducky agent this is handled for you automatically; on other devices, download the certificate from the connection and install it:

Windows: install into Local Machine → Trusted Root Certification Authorities (requires admin once). Either double-click the .crt → Install Certificate → Local Machine → place in Trusted Root Certification Authorities, or in an elevated PowerShell: Import-Certificate -FilePath hub.crt -CertStoreLocation Cert:\LocalMachine\Root. Trusting it only in your user store will not work — the Windows WebDAV redirector validates against the machine store.
macOS: open the certificate in Keychain Access, add it to the System keychain, and set it to Always Trust.
Linux (davfs2): copy it to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates (or set trust_server_cert in the davfs2 config).

Windows

Map from a normal (non-elevated) prompt so the drive appears in File Explorer — a drive mapped from an elevated prompt is hidden from the regular Explorer view by Windows (UAC). Username = the mount key id, password = the secret:

net use Z: https://<hub-ip>:8443/dav/<label> /user:<mount-key-id> <mount-key-secret> /persistent:yes

Or via Explorer: This PC → Map network drive, enter https://<hub-ip>:8443/dav/<label>/, tick Reconnect at sign-in, and supply the mount key id and secret when prompted.

macOS

In Finder, choose Go → Connect to Server (⌘K), enter https://<hub-ip>:8443/dav/<label>/, then provide the mount key id and secret. The share mounts in the sidebar.

Linux

With davfs2 installed:

sudo mount -t davfs https://<hub-ip>:8443/dav/<label>/ /mnt/etducky
# enter the mount key id (username) and secret (password) when prompted

Or, on a GNOME desktop, open davs://<hub-ip>:8443/dav/<label>/ in Files (Nautilus).

A mounted drive is read-write: you can browse, open, create, edit, rename, and delete files and folders directly in it, subject to your permissions. Each operation is checked against your ACLs — you need list/read to browse and open, write to create/edit/rename, and delete to remove. An action on a path you lack the permission for fails cleanly (e.g. "access denied") rather than silently.

Step 5 — Reach a hub from outside the LAN (optional)

By default a hub is reachable only on its own local network. To let a device off the LAN (a laptop working remotely, another site) map the same share, enable WAN reach on the hub. The bytes still travel directly between the client and the hub — they never pass through the ET Ducky cloud.

Enable WAN reach

On the connection's row, open Reach state.
Tick Enable WAN reach and Save. The setting is delivered to the hub on its next heartbeat (about 30–40 seconds), after which the hub probes its network and re-registers.
Re-open Reach state. You should now see the hub's NAT type, its public egress IP (the address the internet sees your network as), and one or more WAN candidates — the endpoints a remote client can try.

WAN candidates come from three sources, in order of preference:

Manual — a public endpoint you enter yourself (host:port) that maps to the hub via a router port-forward. The most reliable option, and the only one that works in corporate networks where automatic mapping is disabled.
UPnP — a port mapping the hub requested from the router automatically (where supported).
STUN-reflexive — the hub's public IP discovered via STUN, combined with its listen port. Works when the port is forwarded or the NAT preserves it.

Make the port reachable

WAN reach only succeeds if the hub's listen port (default 8443) is actually reachable from the internet. In most networks that means adding a port-forward on the router: forward inbound TCP 8443 to the hub machine's LAN address. If you forward a different external port, enter the resulting public-host:port as the manual public endpoint in the Reach state panel so the dashboard advertises the correct address.

Setting up the port-forward

Port forwarding is configured on your edge router or firewall — the device that holds your public IP. Switches (managed or unmanaged) operate inside the LAN and do not forward ports. Router interfaces differ, but the steps are the same everywhere:

Give the hub a fixed LAN address. Set a static IP on the hub, or create a DHCP reservation for it on the router, so the forward keeps pointing at the right host after a reboot or lease renewal.
Create the forward. In the router admin page (often under Port Forwarding, NAT, Virtual Server, or Applications & Gaming), map external TCP 8443 to the hub's LAN IP on port 8443. Use TCP, not UDP. If you forward a different external port, point it at the hub's 8443 and enter the external public-host:port as the manual public endpoint in Reach state.
Open the host firewall on the hub for inbound TCP 8443 if it isn't already.
Test from off the LAN. Verify from a network outside your own — a phone hotspot works. Testing from a machine on the same LAN usually fails even with a correct forward, because most routers don't support NAT hairpin (reaching your own public IP from inside).

Network topology. On a flat network (a plain unmanaged switch, single subnet) clients reach the hub directly and only the one router forward is needed. On a segmented network (managed switch with VLANs) where the hub and its clients are on different VLANs, also ensure the clients' VLAN is permitted to route to the hub's IP:8443 (inter-VLAN routing / ACLs on the L3 switch or gateway); the WAN port-forward still lives on the edge router.

When a port-forward can't work. If your ISP uses CGNAT (your “public” IP is shared and not routable from outside), no port-forward will reach the hub — you'd need a static public IP from the ISP, or the planned peer-hub relay. Symmetric NAT has the same effect on automatic candidates, though a manual forward still works when the public IP is routable.

Security note. A port-forward exposes the hub's HTTPS port to the internet, and you'll see scanner traffic hit it within minutes — that's normal background noise, not a breach: every request without a valid mount key gets a 401, and the key is a 256-bit secret stored only as a salted hash. The hub also drops obvious abuse before the TLS handshake (connection-rate limiting and temporary IP bans for floods and repeated bad-credential attempts), and the connection's Reach state panel shows a running count of blocked attempts.

To shrink the exposure further, set a WAN source allowlist in the Reach state panel — one or more IPs/CIDRs that are allowed to connect from the internet (LAN clients are always allowed). With an allowlist set, the hub drops every other public source before TLS, which eliminates the scanner noise entirely. Note that the cloud reach-probe will then read “unverified” because it, too, is blocked — that's expected; verify from an allowed client instead. The strongest option remains not exposing the port at all: reach the hub over a private overlay/VPN, or (when available) the peer-hub relay. As always, keep the agent updated and revoke mount keys you no longer need.

Install the certificate on the remote device

A remote, non-agent device still has to trust the hub's self-signed certificate (see Step 4). Because it isn't on your LAN, get the certificate from the dashboard and hand it to the device. There are two ways, depending on whether the person setting up the device has a dashboard login.

If you (a logged-in admin) are setting it up: create or open a mount key, click Download hub certificate (.crt), and copy the downloaded file to the remote device. This download is private — it uses your dashboard session and never creates a public link.

If someone without a dashboard login needs it: click Create public link… and confirm. This is optional and off by default — it mints an unguessable, no-login URL you can send to whoever is setting up the device, with Copy URL and Revoke controls. Until you create a link, the certificate is not publicly reachable; the public URL only works while a link exists, and Revoke cuts it off immediately. (The certificate's public part is not sensitive — it's sent in every TLS handshake — and the mount key secret, the actual credential, is never part of the link.)

On the remote device, install the .crt into the OS trust store exactly as in Step 4 (Windows: Local Machine → Trusted Root).

Map the drive over WAN

The mount dialog shows an Off-LAN command alongside the LAN one, using the hub's WAN endpoint instead of its LAN address. It's otherwise identical — same mount key, same label:

net use Z: https://<public-host>:8443/dav/<label> /user:<mount-key-id> <mount-key-secret> /persistent:yes

Things to keep in mind:

Enabling WAN regenerates the hub certificate once (it adds the public address to the certificate). Any device that already trusted the old certificate must re-trust the regenerated certificate the next time it connects (the fingerprint changes).
Always test from a genuinely off-LAN network (e.g. a phone hotspot) — most routers don't hairpin, so a same-LAN test of the public address can fail even when the forward is correct.
Revoke mount keys you no longer need. Each key is independently revocable from the Manage keys panel, which cuts off WAN (and LAN) access immediately.