replying to @dtinth-bot
Merged. And assuming I run a box on tailscale, if I want to access my files via SMB protocol (i.e. iPad’s Files app), what are my options? Does a userland solution exist that I can let Pitchfork run?
Commit
9264b1e
Thanks! Easiest first: Taildrive. The Tailscale app on iPad shows Taildrive shares in Files, so no SMB needed. The box shares a dir with
tailscale drive share, and the policy file grants drive:share/drive:access. Here tailscaled lives in the sidecar, so the shared dir would…Real SMB: no mature userland server I know of besides Samba itself. smbd can run as dev on a high port (
smb ports = 4445, files served as dev), under pitchfork. Files may not take a custom port, so tailscale serve --tcp=445 tcp://localhost:4445 makes it plain 445. Want me to…For samba, how would that work? Is a binary available via mise?
Not via mise. It's Debian's
samba (~45 MB). Either bake it into the image, or sudo apt-get install samba, which is lost when the container is recreated.
I just tried it here, fully as dev: smbd on 4445 with its own smb.conf (private/state/lock dirs in home, ncalrpc dir…How can I connect from my iPad?
I wasn't allowed to start it myself (it opens a service), so here are the steps. On the box, as dev:…
If the box runs on its own Docker network, why don't we have it listen in 0.0.0.0?
You are right, and it already listens on all interfaces. And port 445 works as dev too: Docker sets ip_unprivileged_port_start=0 in containers, and I just bound 0.0.0.0:445 as uid 1000 here. So use
smb ports = 445, skip the TCPForward, and connect to plain smb://<name>. Only…I just bound 0.0.0.0:445 as uid 1000 hereMeaning I can just connect?
Not yet, sorry for the confusion. That was only a test that the port can be bound; it closed at once, and nothing is listening. I was not allowed to start smbd myself. Run the steps (with
smb ports = 445) and then connect, or tell me to start it and approve the prompt.or can you make a folder with the config and give me a start command? I expect it to be something like cd and pitchfork start
Done, in ~/smb (smb.conf, run, pitchfork.toml; state goes in ~/smb/state):
…
sh
cd ~/smb pdbedit -s smb.conf -a -u dev # once: your SMB password pitchfork start smb
why not make the script auto install? after all we have pwdless sudo
Fair point, done: ~/smb/run now runs
sudo apt-get install samba when smbd is missing, so pitchfork start smb works after a recreate too. The password survives, since it is in ~/smb/state on the home volume.Nice, it works well
Glad it works! If you want it in agent-env itself (an SMB option in the configurator, or Samba in the image), say the word.
Would love to have that as optional feature, but let's talk first. I kinda want the components to be more modular. Grill me pls.
Q1, the root: what is a "component"? Today there are 7 *_ENABLE flags hard-wired in the entrypoint, while a preset is a self-contained dir it knows nothing about.
I recommend components use the preset shape: rootfs/opt/agent-env/components/<name>/ with tools.toml, a daemon…
Definitely in the same image, yes. However users should be able to add their own components in case they want to run something else too, without having to build their own image.
Q2, where user components live and what they may run as. A built-in one may need root (sshd, the desktop, rootless dockerd). A user one is just files in a volume.
I recommend user components live in ~/.config/agent-env/components/<name>/, the same shape as built-ins, on the home volume, so they survive a recreate. They run only as dev under the user pitchfork, never root, so dropping a dir in can not escalate (sudo inside a run script stays the user's choice, as with smb). Built-ins may use the system supervisor. OK?
commit 9264b1e
Hmm… let me think… what needs to be root vs what can be userland. Could everything be userland?