Commit

f6d1d50

replying to @dtinth
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…
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…
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.
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
…
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.
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…
Almost everything. Looking at what runs here: Must stay root (the core, not components): - sshd: it logs you in as dev - the gateway (caddy + oauth2-proxy as gateway): an edge hole must not land in the account with sudo, and dev's code must not read its secrets - the…
Agree. Please look at all the core and components. What are the common things it need to do? For example, I might want to set up a daemon that runs whenever this container runs. I would have to configure pitchfork myself, etc. So I am thinking of something more convention-based.…
Good, so built-in integrations stay in /opt and components are the thin convention layer on top. I am surveying every core piece and integration now for the glue they share (daemon, route, env, tools, commands, index link…). Back with a list and the next question.

commit f6d1d50