Skip to content

Dufs Runtime

The optional chatshare serve directory-login gateway sits in front of Dufs; it is not a fork. It reads existing instance state without reinitialization or changes to Dufs binary/config/accounts/files or installed assets. The configuration below still describes native Dufs; gateway directory and management access has an additional server-side gate. See security boundaries.

Responsibility boundary

ChatShare does not modify Dufs source. It combines official release assets, configuration, custom UI assets, and a Linux user service into a ChatArch-managed runtime.

Layer Responsibility
Dufs HTTP/WebDAV, directory UI, HTTP Digest Auth, uploads, and reads
ChatShare Release selection and integrity, ChatArch paths, configuration, web assets, systemd user lifecycle, and local or configured-remote publication/directory queries
Reverse proxy TLS, trusted Host enforcement, external ingress, and request limits; outside this CLI

Client mode

A new machine without ~/.chatarch/chatshare/instances/default/instance.json does not have a server fault. If its active ChatEnv chatshare profile has CHATSHARE_DUFS_BASE_URL, CHATSHARE_DUFS_USERNAME, and CHATSHARE_DUFS_PASSWORD, chatshare put, tree, and url automatically use the remote Dufs HTTP client:

  • put authenticates to preflight the destination, creates missing parent directories one MKCOL at a time, then uploads with a Content-Length 1 MiB streaming PUT. It never aggregates the whole file in memory and does not claim unverified atomic create-only behavior across independent writers.
  • tree requests ?json for the selected directory with Basic Auth; the existing gateway/Dufs policy protects the directory listing itself.
  • url uses authenticated HEAD before returning a concrete-file link built from the configured base URL.
  • HTTP requires HTTPS by default; HTTP is allowed only for loopback localhost/127.0.0.1/::1. A base URL cannot contain URL credentials, a query, or a fragment.

Client mode does not install Dufs, create a local data root, register remote hosts, or alter the remote service. When a local server instance exists, the same commands keep their managed-local behavior. See Quick Start for configuration.

Layout

~/.chatarch/chatshare/
├── runtimes/dufs/
│   ├── v0.46.0/
│   │   ├── dufs
│   │   └── install.json
│   └── current -> v0.46.0
├── instances/default/
│   ├── config.yaml
│   ├── instance.json
│   ├── assets/dufs/
│   │   ├── index.html
│   │   ├── index.css
│   │   └── index.js
│   ├── data/
│   └── logs/access.log
└── services/chatshare-dufs.service

The active Linux unit is ~/.config/systemd/user/chatshare-dufs.service. It is the user-supervisor entry; the binary, configuration, data, logs, and canonical unit source remain ChatArch-owned.

Installation transaction

chatshare dufs install:

  1. Requests release metadata for a pinned sigoden/dufs tag.
  2. Selects the unique .tar.gz asset for the OS and architecture.
  3. Requires a valid sha256: digest in GitHub asset metadata.
  4. Downloads inside the target runtime directory while streaming SHA-256.
  5. Extracts only the regular dufs member and rejects links or path traversal.
  6. Runs the non-listening dufs --version check.
  7. Atomically replaces the versioned binary and current pointer.

A download, digest, extraction, or version failure never replaces the currently usable binary.

Configuration

The default config is loopback-only with shared HTTP Digest Auth:

serve-path: '<managed-data-root>'
bind: 127.0.0.1
port: 5000
auth:
  - '<username>:<password>@/:rw'
  - '@/'
allow-upload: true
allow-delete: false
allow-search: true
allow-symlink: false
allow-archive: true
allow-hash: true
enable-cors: false
assets: '<managed-assets-root>'
log-file: '<managed-access-log>'

The placeholders are not copyable credentials. The real password is read first from the active ChatEnv chatshare profile, or from the process environment variable selected by --password-env; generated config.yaml and instance.json files use mode 0600, and directories use mode 0700. status and JSON output never read or display the password. assets points at the custom Dufs UI that ChatShare syncs into ~/.chatarch/chatshare/instances/default/assets/dufs/ for the in-page login dialog.

Lifecycle

service install generates the user unit and runs systemctl --user daemon-reload. Login-time startup is enabled only with explicit --enable.

start, stop, and restart do not signal processes directly; they operate on chatshare-dufs.service. status returns inactive as a normal service state instead of treating it as a CLI crash.

Upgrade and rollback

  • Upgrades require explicit --version vX.Y.Z.
  • current changes only after the new version completes the installation transaction.
  • Binary upgrades do not migrate or delete configuration and data.
  • Roll back by installing an already trusted old version with install --version <old>, then restart.
  • ChatShare does not automatically delete old runtimes; garbage collection requires a separate design.