domdev

transmission on a freebsd server

2026-08-05T00:00:00+00:00

Installation</h2>

pkg</span> install transmission-daemon transmission-web transmission-cli</span></span></code></pre>
daemon</code> - required to install the service</p>
web</code> - installs the web interface</p>
cli</code> - for management</p>
Configuration</h2>
Enabling the service (daemon)</h2>
Via sysrc</code></p>
sysrc</span> transmission_enable="YES"</span></span></code></pre>
or manually add to /etc/rc.conf</code></p>
transmission_enable</span>=</span>"YES"</span></span></code></pre>Configuring settings.json</code></h2>
The config file is located at /usr/local/etc/transmission/home/settings.json</code></p>
⚠️ Important:</span></span>
Edit the file only while the service is stopped (service transmission stop),</span></span>
otherwise Transmission will reset all changes.</span></span></code></pre>
Some values in settings.json</code> are set via rc.conf variables; the default values are located at /usr/local/etc/rc.d/transmission</code>.
A useful file describing all the variables, what they do, and their default values.</p>
⚠️ Important:</span></span>
Values are taken from the variables, so if you set a value in settings.json,</span></span>
transmission may overwrite it</span></span></code></pre>Configuring the download directory</h2>
The download directory is set via a variable in rc.conf</code>:</p>
transmission_download_dir</span>=</span>"/mnt/transmission/downloads"</span></span></code></pre>
Default is /usr/local/etc/transmission/home/Downloads</code></p>
Access configuration</h2>
Download directory permissions</h3>
By default transmission runs under the transmission user and group, so the download directory permissions need to be set:</p>
chown</span> -R transmission:transmission /mnt/transmission/downloads</span></span></code></pre>
You can also add yourself to the transmission group:</p>
pw</span> groupmod transmission -m</span> $USER</span></span></code></pre>Login/password authentication</h3>
You can add login/password access:</p>
"rpc-authentication-required"</span>: </span>true</span>,</span></span>
"rpc-username"</span>: </span>"your_login"</span>,</span></span>
"rpc-password"</span>: </span>"your_password"</span>,</span></span></code></pre>
If this is on a home network and login/password isn't needed, it can be disabled:</p>
"rpc-authentication-required"</span>: </span>false</span>,</span></span></code></pre>Address restrictions</h3>
You can allow access from specific devices on the network,
set via the rpc-whitelist</code> parameter as a comma-separated string, with rpc-whitelist-enabled</code> turned on:</p>
"rpc-whitelist"</span>: </span>"127.0.0.1,192.168.1.2"</span>,</span></span>
"rpc-whitelist-enabled"</span>: </span>true</span>,</span></span></code></pre>
There's a similar setting, but for restricting the addresses at which the web interface will open.</p>
rpc-host-whitelist</code> (note the word host in the name), also set as a comma-separated string:</p>
"rpc-host-whitelist"</span>: </span>"transmission.lan,192.168.1.10"</span>,</span></span>
"rpc-host-whitelist-enabled"</span>: </span>true</span>,</span></span></code></pre>



esp rust: setting up defmt
2026-07-06T00:00:00+00:00
Setting up defmt on ESP32-C6 (esp-hal + probe-rs)</h2>
Notes on migrating from rtt-target</code> to defmt</code> for logging over RTT.</p>
1. Dependencies</h2>
[</span>dependencies</span>]</span></span>
defmt</span>     =</span> "1.1.1"</span></span>
defmt-rtt</span> =</span> "1.3.0"</span></span></code></pre>
rtt-target</code> can be removed — defmt-rtt</code> replaces it.</p>
2. Linking: the .defmt</code> section</h2>
Error at startup:</p>
Error: Failed to parse defmt data</span></span>
defmt version found, but no `.defmt` section - check your linker configuration</span></span></code></pre>
Cause: the defmt.x</code> linker script (shipped with the defmt-rtt</code> crate) isn't linked in.</p>
Fix — add a flag to .cargo/config.toml</code>:</p>
[</span>build</span>]</span></span>
rustflags</span> =</span> [</span></span>
  "-C"</span>,</span> "link-arg=-Tdefmt.x"</span>,</span></span>
]</span></span></code></pre>3. Transport initialization</h2>
defmt</code> by itself only formats messages — where they're sent is decided by a separate transport crate.
Since the project already had an RTT channel (via rtt-target</code>), the logical choice is defmt-rtt</code>:</p>
use</span> defmt_rtt </span>as</span> _</span>;</span> // wires up RTT as the transport for defmt</span></span></code></pre>
Important: rtt_target::rtt_init_print!()</code> must be removed — two ways of initializing the RTT channel conflict.</p>
4. The mandatory timestamp</h2>
Without it the build fails at link time:</p>
undefined symbol: _defmt_timestamp</span></span></code></pre>
Every defmt frame includes a timestamp per the protocol, so it needs to be set explicitly:</p>
defmt</span>::</span>timestamp!</span>(</span></span>
    "</span>{</span>=u64:us</span>}</span>"</span>,</span></span>
    esp_hal</span>::</span>time</span>::</span>Instant</span>::</span>now</span>()</span></span>
        .</span>duration_since_epoch</span>()</span></span>
        .</span>as_micros</span>()</span></span>
);</span></span></code></pre>
Here :us</code> tells the host (probe-rs) to format the number as seconds with a fractional part
(e.g. 12.345678</code>), instead of printing raw microseconds.</p>
If a timestamp isn't needed at all, an empty format can be left — the symbol still gets
defined for linking:</p>
defmt</span>::</span>timestamp!</span>(</span>""</span>);</span></span></code></pre>5. "Builds, but prints nothing"</h2>
The likely cause is the log level not being set via the DEFMT_LOG</code> environment variable (the defmt</code> analog of RUST_LOG</code> from env_logger</code>).
By default, info</code> level doesn't pass through.</p>
Quick check:</p>
DEFMT_LOG</span>=</span>info</span> cargo</span> run --release</span></span></code></pre>
To avoid setting the variable every time, put it in .cargo/config.toml</code>:</p>
[</span>env</span>]</span></span>
DEFMT_LOG</span> =</span> "info"</span></span></code></pre>Final checklist</h2>


defmt</code> + defmt-rtt</code> in dependencies, rtt-target</code> removed</li>

-Tdefmt.x</code> in rustflags</code></li>

use defmt_rtt as _;</code> in main.rs</code>, old rtt_init_print!()</code> removed</li>

defmt::timestamp!</code> defined (otherwise linking fails)</li>

DEFMT_LOG</code> set (directly or via [env]</code> in .cargo/config.toml</code>)</li>
</ul>


db-mcp: connect your database to AI
2026-05-30T00:00:00+00:00
I needed a private utility for work and personal projects: read data from databases, but never write. Existing solutions weren't what I wanted — those that existed were JS/Python packages. I just needed a simple binary: download and run, without Node.js or other overhead. Plus, always nice to build something yourself :)</p>
So I built db-mcp</strong> (github</a>) — a lightweight Rust binary that:</p>

Reads from PostgreSQL, MySQL/MariaDB, SQLite, and ClickHouse via URL scheme</li>
Works with Claude, OpenCode, Jan, Zed, and any MCP-compatible client</li>
Simple and safe by design: read-only (SELECT only), parameterized queries</li>
Builds once with all backends enabled — choose your database at startup</li>
Ships as a fully static Linux binary (musl, no glibc at runtime)</li>
</ul>
Why this was needed</h2>
At work, I often need to give Claude access to data: fetch information, analyze, provide context for scripting. Requirements were:</p>

Safe</strong> (read-only, parameterized queries)</li>
Private</strong> (runs locally, nothing sent to cloud)</li>
Universal</strong> (not just Claude — I use OpenCode, Zed, Jan for different tasks)</li>
</ul>
How it works</h2>
db-mcp is a stdio MCP server written in Rust. You point it at a database URL via the --database-url</code> flag or the DATABASE_URL</code> env var:</p>
db-mcp</span> --database-url postgres://user:pass@localhost:5432/mydb</span></span>
db-mcp</span> --database-url mysql://user:pass@localhost:3306/mydb</span></span>
db-mcp</span> --database-url sqlite:///absolute/path/to/data.db</span></span>
db-mcp</span> --database-url clickhouse://default:pass@localhost:8123/default</span></span></code></pre>
The server detects the engine from the URL scheme and connects. Then Claude/OpenCode/Jan can use three tools:</p>
Tool</th> Params</th> What it does</th></tr></thead>

list_tables</code></td> —</td> List user tables</td></tr>
describe_table</code></td> table</code>, schema?</code></td> Columns, types, nullability</td></tr>
query</code></td> sql</code></td> Run a SELECT, returns JSON rows</td></tr>
</tbody></table>
A query</code> call returns plain JSON, so the model gets real values to reason about:</p>
[</span></span>
  { "</span>id</span>":</span> 1</span>, "</span>email</span>":</span> "ada@example.com"</span>, "</span>created_at</span>":</span> "2026-05-01 09:12:33"</span> },</span></span>
  { "</span>id</span>":</span> 2</span>, "</span>email</span>":</span> "linus@example.com"</span>, "</span>created_at</span>":</span> "2026-05-03 14:50:01"</span> }</span></span>
]</span></span></code></pre>Safe by design</h3>
SELECT-only enforcement lives in the server, not in the adapters. Anything that doesn't start with SELECT</code> (case-insensitive, after trim) is rejected — that even blocks CTE tricks like WITH ... INSERT ... RETURNING</code>. Every adapter uses parameterized queries, never string-concatenated SQL. For an extra layer, point it at a read-only database role.</p>
Setup for different tools</h2>
All clients launch the same binary; the difference is just where the config file lives. I prefer passing the URL through DATABASE_URL</code> so it isn't visible in the args list.</p>
Claude Code (CLI)</h3>
cli</strong></p>
claude</span> mcp add db</span> \</span></span>
  --env DATABASE_URL=postgres://user:pass@localhost:5432/mydb</span> \</span></span>
  -- /absolute/path/to/db-mcp</span></span></code></pre>
claude.json</strong></p>
{</span></span>
  "</span>mcpServers</span>": {</span></span>
    "</span>db-mcp</span>": {</span></span>
      "</span>type</span>":</span> "stdio"</span>,</span></span>
      "</span>command</span>":</span> "/absolute/path/to/db-mcp"</span>,</span></span>
      "</span>args</span>": [],</span></span>
      "</span>env</span>": {</span></span>
        "</span>DATABASE_URL</span>":</span> "postgres://user:pass@localhost:5432/mydb"</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
Restart Claude and the tools appear.</p>
OpenCode</h3>
In your opencode.json</code> (project or ~/.config/opencode/opencode.json</code>):</p>
{</span></span>
  "</span>$schema</span>":</span> "https://opencode.ai/config.json"</span>,</span></span>
  "</span>mcp</span>": {</span></span>
    "</span>database</span>": {</span></span>
      "</span>type</span>":</span> "local"</span>,</span></span>
      "</span>command</span>": [</span>"db-mcp"</span>,</span> "--database-url"</span>,</span> "sqlite:///home/me/work/data.sqlite"</span>],</span></span>
      "</span>enabled</span>":</span> true</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>Jan</h3>
Jan has built-in MCP support (Settings → MCP Servers). The equivalent config is a command + args + env entry:</p>
{</span></span>
  "</span>database</span>": {</span></span>
    "</span>command</span>":</span> "/absolute/path/to/db-mcp"</span>,</span></span>
    "</span>args</span>": [],</span></span>
    "</span>env</span>": {</span></span>
      "</span>DATABASE_URL</span>":</span> "postgres://prod.example.com:5432/analytics"</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>Zed</h3>
In settings.json</code> (custom MCP servers live under context_servers</code>, not lsp</code>):</p>
{</span></span>
  "</span>context_servers</span>": {</span></span>
    "</span>db-mcp</span>": {</span></span>
      "</span>enabled</span>":</span> true</span>,</span></span>
      "</span>remote</span>":</span> false</span>,</span></span>
      "</span>command</span>":</span> "/absolute/path/to/db-mcp"</span>,</span></span>
      "</span>args</span>": [],</span></span>
      "</span>env</span>": {</span></span>
        "</span>DATABASE_URL</span>":</span> "postgres://user:pass@localhost:5432/mydb"</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>In practice</h2>
Scenario 1: development context</h3>
In Claude Code:</span></span>
"Help me write a migration to add a new field.</span></span>
Check the current users table structure."</span></span>
</span>
Claude:</span></span>
1. Calls db-mcp (describe_table) → gets current schema</span></span>
2. Sees existing fields and constraints</span></span>
3. Generates a correct migration for your actual database</span></span></code></pre>Scenario 2: data analysis in OpenCode</h3>
In OpenCode analyzing metrics:</span></span>
"How many active users this month?</span></span>
What are the most popular features?"</span></span>
</span>
OpenCode uses db-mcp (query), the model sees real numbers</span></span>
and provides analysis grounded in actual data.</span></span></code></pre>Scenario 3: debugging in Jan</h3>
Jan with db-mcp helps debug:</span></span>
"Are there orders without user_id in the orders table?"</span></span>
</span>
Jan queries through db-mcp, sees there are 12 such records,</span></span>
suggests how to fix it.</span></span></code></pre>Installation</h2>
Quick install (Linux and macOS Apple Silicon) — auto-detects OS/arch, verifies the checksum, installs to ~/.local/bin</code> by default:</p>
curl</span> --proto '=https' --tlsv1.2 -sSf</span> \</span></span>
  https://raw.githubusercontent.com/zeslava/db-mcp/main/install.sh</span> |</span> sh</span></span></code></pre>
Or grab a release tarball manually (Linux x86_64/aarch64, macOS arm64, Windows x86_64):</p>
TARGET</span>=</span>x86_64-unknown-linux-gnu</span></span>
curl</span> -sSL "https://github.com/zeslava/db-mcp/releases/latest/download/db-mcp-</span>${TARGET}</span>.tar.gz"</span> \</span></span>
  |</span> tar</span> -xz</span></span>
install</span> -m</span> 755</span> "db-mcp-</span>${TARGET}</span>/db-mcp" "</span>$HOME</span>/.local/bin/db-mcp"</span></span></code></pre>
Or build from source:</p>
git</span> clone https://github.com/zeslava/db-mcp</span></span>
cd</span> db-mcp</span></span>
cargo</span> build --release</span></span>
./target/release/db-mcp</span> --database-url postgres://localhost/mydb</span></span></code></pre>Benefits of this approach</h2>

✅ One binary for four engines (PostgreSQL, MySQL/MariaDB, SQLite, ClickHouse)</li>
✅ Works everywhere: Claude, OpenCode, Jan, Zed, any MCP client</li>
✅ No runtime overhead (no JS, Python) — pure Rust, static musl binary on Linux</li>
✅ Safe by design: SELECT-only, parameterized queries</li>
✅ Private: runs locally or in your infrastructure</li>
✅ Simple setup: just a database URL</li>
</ul>
What's next</h2>

Support for more databases (and beyond)</li>
Query logging and audit trails</li>
Per-table access control (for more granular permissions)</li>
Server mode</li>
</ul>

domdev

transmission on a freebsd server

esp rust: setting up defmt

Setting up defmt on ESP32-C6 (esp-hal + probe-rs)</h2> Notes on migrating from rtt-target</code> to defmt</code> for logging over RTT.</p>

db-mcp: connect your database to AI

In practice</h2>

What's next</h2> Support for more databases (and beyond)</li> Query logging and audit trails</li> Per-table access control (for more granular permissions)</li> Server mode</li> </ul>

Setting up defmt on ESP32-C6 (esp-hal + probe-rs)</h2>
Notes on migrating from `rtt-target</code> to defmt</code> for logging over RTT.</p>`

What's next</h2>

Support for more databases (and beyond)</li>
Query logging and audit trails</li>
Per-table access control (for more granular permissions)</li>
Server mode</li> </ul>