replying to @dtinth
I wasn't allowed to start it myself (it opens a service), so here are the steps. On the box, as dev:…
Commit
0f90f4f
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…
Hmm… let me think… what needs to be root vs what can be userland. Could everything be userland?
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.…
Surveyed everything. The glue every piece repeats:
1. an enable flag
2. a daemon (user pitchfork), with readiness (port/cmd/http) and sometimes depends
3. a loopback run script reading env with defaults
4. a gateway route under /~env/<name>, prefix stripped or passed through
5.…
- I wonder if we can get rid of the preset and make it also a component.
-
component.env - how about toml?
- run - I think this can link to a folder with pitchfork.toml so we can run pitchfork on it.
- I don't like the *_ENABLED env. Maybe better to have it not run in the…1. Presets as components: yes. opencode becomes a component that claims / . vanilla is simply "nothing claims /". PRIMARY_COMMAND becomes a tiny built-in component. One rule: at most one component may claim / .
2. TOML: yes, component.toml.
3. pitchfork.toml in the folder: works. I tested it: pitchfork namespaces daemons by folder name, so components/smb/pitchfork.toml shows up as smb/smbd. At boot the entrypoint runs
pitchfork start -l in each component folder. Readiness, depends and retry are then pitchfork's own fields, and component.toml only holds what pitchfork doesn't know: title, summary, the /~env/ route.
4. No *_ENABLE: agreed. A component that isn't on never gets started at all.
5. Today's preset files, using opencode as the example:
- tools.toml: mise tools to install into the home volume (the opencode CLI). Copied to ~/.config/mise/conf.d.
- login.sh: sourced by login shells (sets OPENCODE_SERVER and reads its password).
- environment: lines for /etc/environment, so ssh box opencode run ... (no login shell) sees them too.
- commands/: extra agent-env <cmd> subcommands (agent-env tui, agent-env password).
I'd keep the first and last as mise.toml and commands/, and fold the two env files into a single env.sh.
Next question: how is a component turned on? My recommendation: one list in compose, AGENT_ENV_COMPONENTS=opencode,smb, for built-ins in /opt. A component you put in ~/.config/agent-env/components/<name>/ runs because it is there; delete it to turn it off. OK?commit 0f90f4f
Sounds good. It should support symlinking.
agent-env-component.toml?
I think we should also have some kind of support for startup script or hook which runs before we start user-level pitchfork. Then this would let me write script that provision. I would put it in a compose…