2026/02/01

Sunday, February 1, 2026 (#32)

Saturday Sunday Monday posts: prev < this > next

Fixing Connection Clades, part 5a

So, you might think it would make the most sense to lay out connections like this (using hetz1 as an example):

1:[db client @ local] ⇒ 2:[ssh to hetz1] ⇒ 3:[db server @ local]

I think maybe this works if we're using ssh as a tunnel, but not if we're using it to wrap commands. With the latter, that sequence would result in something like:

SELECT * FROM TableName; echo "SELECT * FROM TableName;" > ssh sysuser@hetz1 mariadb -udbuser -pdbpass -hlocalhost "echo \"SELECT * FROM TableName;\" > ssh sysuser@hetz1"

...which would not work, because it's trying to get MariaDB to execute a bash command. What we need is something more like

SELECT * FROM TableName; mariadb -udbuser -pdbpass -hlocalhost "SELECT * FROM TableName;" echo "mariadb -udbuser -pdbpass -hlocalhost \"SELECT * FROM TableName;\"" > ssh sysuser@hetz1

I think this means that if we want to use ssh to wrap commands, it needs to be a different class and configured in a different order.

Later

...but now we start to run into issues with the existing nomenclature. So far, the terms "Client" and "Server" have been kind of relative: a Client always has a Server to talk to – but an intermediate Server is also a Client, and needs another Server to talk to, until we get to the very last piece (a Process, but also a Server?) which actually executes the request.

This means, though, that an Engine Server is also a Client, which kind of messes up the nice dichotomy. (Maybe it's not an Engine Client, but just a Base Client?)