Community
Chat Logs
Sunday, June 21, 2026
- * phaleth joined #primate
- phalethI had no clue that traefik works with podman
- phalethblue: https://gitea.repopack.app/repopack/provision/commit/4c9ab41ae44ef3a83bf07d3f043d7585f6a4134d
- * phaleth joined #primate
- bluehi phaleth
- bluetook me a while to realise I need to use port 2222 now :P
- bluebut yeah, checked in gitea and got it now
- blueanyway, traefik works like a charm on my comp locally
- blueI first tried to update haproxy on every app creation but it a bit of a pain
- blueit was*
- bluenow, traefik just reads podman container labels and automatically updates, pretty fast too, and there's a dashboard we could put under traefik.repopack.com or so and behind http basic auth
- blueI also moved back the plans to disk and added tests. the plans in the db thing wasn't well testable
- blueI also added a js/next-js plan which works
- blueand a go/binary plan which works as well
- bluephaleth: working on ssh now
- phalethhi blue
- phalethyeah, traefik looks convenient
- phalethso that'll be another priviledged container for traefik
- blueyes
- bluephaleth: we'll probably need to have the repopack repo in /opt, so that the git user can execute stuff there
- blueat least until we containerise it, then we need a different solution for that
- phalethdata that needs to be persisted will be stored in a volume somewhere in /opt/podman
- bluemhm
- phalethanyway, everything should be a git repo and ideally stored to postgres in real-time https://nesbitt.io/2026/02/26/git-in-postgres.html
- bluesounds great
- phalethyeah, best way is to have no volumes at all, configs can be provided at build time
- phalethif you need to have some files on host during testing then you can for sure create a volume, but for production usage postgres is the place to keep data I think
- phalethwe had this discussion long ago about two data targets that need to be kept in sync and coming up with yet another forgejo/gitea should be a mistake
- blueso you want to put git in the db?
- blueI've added ssh auth support. you can now add pubkeys under your account, and access the repo via ssh/git. the clone button is also wired
- phalethyeah, totally
- phalethnice
- blueI would be in favour of moving git into postgres, but I'd consider this an optimisation, because there's a lot of work involving parsing git-upload-pack and on pull generating git-receive-pack
- bluefor now shelling out to git is the cheapest, even if it's not the cleanest
- blueanyway, the last missing piece for us to deploy repopack.com is the mail login in and acl
- blueI might be able to finish it today, so we can start playing around with it on the server
- bluecurrently, login is restricted to @repopack.com addresses; only those can sign-up. that's a good low-effect limitation for now
- bluebut I still need to put it acl and make sure no one can access any repos
- blueput in*
- phalethok, we can test repopack with bare repos being on disk, but as soon as there are clients expecting uptime and fast redeployments and so on then I'd like to not end up in a migration situation
- phaleththe biggest advantage of having everything in db is that there can be a standalone VM just for db, so the whole system is much easier to maintain
- phalethall that will need to be backed up is the db VM, the rest can be considered temporary, if something strange starts happening, then the solution is to just redeploy on another VM while shutting down whatever garbage was running on the previous VM to maybe ban somebody after
- bluefair enough, we'll add the git-in-postgres as a high prio item
- * phaleth joined #primate
- phaleththis guy seems to like postgres https://nesbitt.io/2026/03/10/just-use-postgres.html
- blueya
- bluephaleth: auth codes coming
- bluethe mailer works, already verified
- bluephaleth: once I merge the acl stuff, do you think we could have a first go and trying to run repopack.com, or too early?
- blueI would consider it a pre-alpha, in the sense that it's wild testing and we could reset the db at any point, but I'd like to see if live if possible
- bluesee it*
- bluethe acl is pretty primitive, too: namespaces have an owner_id and you can only view namespaces you own (ones you created, or the initial namespace that's the same as your user), and their projects. but that's ok for now
- phalethyeah, sure, we can add basic auth to repopack.com and whitelist whoever is needed via haproxy
- phalethI know there will be auth, but it's just to disable any response for now
- bluefair enough
- blueok, let's do it
- bluethe acl code is in. I've recycled the db locally and tested a full run:
- blue- created a user with a @repopack.com address, using /auth/signup
- blue- got code, logged in with it, user created + namespace with the same name
- phaleththe readme is a bit out of place
- blue- created a project in that name
- blue- add my pubkey, clone project, created a minimal primate app, pushed, created app in the ui, deployment
- blueout of place?
- phalethI mean out of order
- blueoh
- phalethI think it's safe to remove the @repopack.com restriction since there is gonna be basic auth
- phalethcause we also need to know if e-mails are sent outside of the mail server
- bluefair enough
- blueI'll do it
- bluemy goal is that we can work on repopack itself at https://repopack.com/repopack/web asap, but for that I need to improve the `items` view. and also the `code` view so it can show commit diffs
- bluefor now, it's just no collaborative, but that's ok, will change soon
- bluenot collborative*
- phalethok, I don't understand all this SSH stuff in the readme, is that needed for deployment?
- blueyes
- bluewhat do you not understand? we need to edit /etc/ssh/sshd_config to run a script for the git user, whenever someone uses it
- blue AuthorizedKeysCommand /usr/local/bin/repopack-authorized-keys %u %t %k
- bluethis is one of two scripts we need to put in a place the git user can read them
- blueor well, wrappers, not scripts
- blueyou'll find those wrappers in the `dev` directory
- phalethyeah, well, it's not saying that
- blueThey should be executed through small system wrappers. The wrappers set the
- bluecurrent working directory to the Repopack project root before starting Bun.
- blueThat matters because `@rcompat/env` loads `.env.local` from the current working
- bluedirectory.
- blueTemplate wrappers live in:
- blue```txt
- phalethok, so the dev dir needs to be part of the image
- bluedev/repopack-authorized-keys
- bluedev/repopack-git-shell
- blue```
- bluethe flow is this
- bluesomeone does `git clone git@repopack.com:primate/primate
- bluesshd reads its config, sees it has an AuthorizedKeysCommand for user git
- blueso it executes
- blueAuthorizedKeysCommand /usr/local/bin/repopack-authorized-keys %u %t %k
- bluethis path needs to be executable by the git user on the host
- blueit could be in a container, but the host git user needs to be able to executable it
- blueto execute*
- blueall this wrapper does really it execute the script `authorized-keys.ts` inside the repopack repo, with the proper cwd
- phalethcurrently it's not just about running `npx primate build` and only having to copy over the build dir right?
- blueyes, for repopack app we need to do more
- phalethI understand git user needs to be created
- blueyes. but we already have that user, I think
- blue[blue@vmd170320 ~]$ id git
- blueuid=971(git) gid=971(git) groups=971(git)
- blueunless you just created it
- phalethno, wait
- blueiirc it gets autocreated if youinstall git
- phalethrepopack will be in it's own priviledged container
- bluethis is ok, but you still need a git user on the host
- blueand that git user needs to call into that container
- phalethtake a look at how it's done in gitea image https://gitea.repopack.app/repopack/provision/src/branch/master/nspawn/containers/gitea/gitea.md
- phaleththere is no need for git and git user on host OS, it just has to be able to reach podman
- phalethand also traefik, but traefik should be another priviledged container
- blueso when someone does `git clone git@repopack.com:primate/primate`, what happens?
- phalethhaproxy will route SSH traffic to repopack container
- phalethbut you know why I want to deploy all this to containers right? it's just to have the whole thing to be sort of modular and for the host OS to stay pure
- phalethanyway, can you uninstall @plsp/svelte from the project?
- phalethI think deploying with node is a better idea
- phalethI'll brb, need to get some groceries
- blueremoved @plsp/svelte
- blue16:00 < phaleth> but you know why I want to deploy all this to containers right? it's just to have the whole thing to be sort of modular and for the host OS to stay pure
- blueyes
- bluejust remember the ultimate goal should be to deploy repopack via itself, if that makes sense. maybe it wouldn't be 100% possible but it would be cool
- blue16:00 < phaleth> but you know why I want to deploy all this to containers right? it's just to have the whole thing to be sort of modular and for the host OS to stay pure16:00 < phaleth> but you know why I want to deploy all this to containers right? it's just to have the whole thing to be sort of modular and for the host OS to stay pure
- bluesorry, no idea how this message got sent, my laptop is developing its own personality
- bluebut I think it's the trackpadp
- phalethyeah, it'll be three containers: postgres, traefik and repopack, so far it seems
- bluecool
- * skillbot joined #primate
- bluephaleth: if you need any help getting repopack.com live, tell me
- phalethjust taking notes still, will see if there is any knowledge gap
- bluek
- phalethis repopack-git-shell used?
- blueyes
- blueGIT_SHELL_COMMAND=/usr/local/bin/repopack-git-shell
- blue const command = env.get("GIT_SHELL_COMMAND");
- blue const options = [
- blue "no-port-forwarding",
- blue `command="${quote(`${command} ${key.id}`)}"`,
- blue "no-X11-forwarding",
- blue "no-agent-forwarding",
- blue "no-pty",
- blue ];
- blue console.log(`${options.join(",")} ${key.public_key}`);
- blue(in scripts/authorized-keys.ts)
- bluethis console.log is actually significant: because sshd reads what you output to stdout, as the command to be executed
- phalethok, does that executable end up in the build dir after npx primate build executes?
- bluedev/repopoack-git-shell? no, currently not.
- bluethe setup as I have it locally, is that I copy dev/repopack-git-shell and dev/repopack-authorized-keys to /usr/local/bin
- phalethah, it's in dev dir
- bluewell, i copy them and edit REPOPACK_ROOT and BUN, as the readme says
- bluethis is /usr/local/bin/repopack-git-shell looks like on my comp
- blue#!/bin/sh
- bluecd /home/blue/git/repopack || exit 1
- blueexec /usr/bin/bun scripts/git-shell.ts "$@"
- bluerepopoack-authorized-keys is similar, just with scripts/authorized-keys.ts
- phalethomg bun :D
- phalethso I will use bun container then
- blueya
- blueI'm using bun.lock anyway with rp
- phalethnot sure if I need to use this install cmd
- phalethis that available on alpine?
- phalethI guess I can just copy those scripts to /usr/local/bin and make them executable
- blueya
- blueyou can
- phalethcan I put REPOPACK_ROOT into the .env.local? seems like I can't
- blueREPOPACK_ROOT is not an actual env variable
- blueit's meant to be replaced with wherever the repo is at
- phalethif I set that var in the image then it will not be available
- blueyes
- phaleththe repo is at? I actually don't understand the purpose of this var
- phalethand it looks like a troublemaker
- phalethboth of these scripts do as well
- bluethis doesn't really matter
- blueall you need to know is that when an ssh request comes out, we need to execute scripts/authorized-keys.ts, which will spit out a command for sshd, which will then need to executed scripts/git-shell.ts
- blueif you can do it without those wrappers, better
- blueto execute*
- bluethe wrappers I need to make it work locally, but I'm not running rp locally like you do on the server, inside containers
- phalethsounds like bun should do that
- blueif you can make it work without the wrappers, all the better
- blueI'm dumb so I went that way, you probably have a better solution :P
- phalethno clue what does "$@" mean, too cryptic
- blueall arguments, iirc
- phalethah, ok, but how are you executing these scripts? from repopack code?
- phalethI think these make the solution undeployable if the application needs them
- bot<discord:blue> So basically, we need a way to tell sshd to execute a script
- bot<discord:blue> I did it by hardcoding stuff into /etc/ssh/sshd_config
- bot<discord:blue> If you pass ssh traffic via haproxy to the container, still need this sshd_config executing a command when ssh is used
- bot<discord:blue> This all can take place in the container, I think
- phalethok, the bun alpine container does not have openssh-server
- phalethand two daemons should not run in the same container anyway
- phaleththat means another openssh-server container is needed
- phalethbut then how do I tell bun about this pretty much remote ssh server?
- phalethalso then I guess those two containers should share a volume, the question is which volume
- phalethI mean which path on disk, the one defined by REPOPACK_ROOT
- phalethI guess
- phalethI was hoping JS runtime could somehow act as sshd
- bot<discord:blue> That was the original idea with ssh2
- phaleth:)
- bot<discord:blue> Which we can still do, but this is a bit more straightforward
- bot<discord:blue> Can't we install openssh in the rp container?
- phaleththis is difficul to deploy, I'd have to use special image that can run two or more daemons and install both openssh-server and repopack website on top of that
- bot<discord:blue> Ok
- bot<discord:blue> I will look into ssh2 then
- bot<discord:blue> I have done it before
- bot<discord:blue> I can do it again
- phalethgreat :)
- phaleththere could be an openssh-server container if you can turn those local scripts into ssh clients (JS based)
- bot<discord:blue> Well, ssh2 is more beneficial if I want longterm to have git in the db
- bot<discord:blue> So
- bot<discord:blue> I guess now is bettet
- phalethok, agree
- bot<discord:blue> I think this should be the rp motto
- bot<discord:blue> Now is better
- bot<discord:blue> 🙂
- phalethyeah, sounds simple enough, people will like
- bot<discord:blue> Ya
- blueplan forward
- bluebun install ssh2
- bluethen create a primate module that wraps around it, starts the ssh server during onInit
- blueinternally, it can run on whatever port we like. so 2222 or whatever
- bluethen, when I use locally, the clone urls are localhost:2222/primate/primate or so
- bluewhen we use repopack.com, haproxy hands off 22 traffic to 2222 in the container
- bluemakes sense?
- phaleththe container can just use internal port 22, just like traefik does use 80, the outbound port will be randomly chosen
- phalethecho $((RANDOM % (65535 - 10000 + 1) + 10000))
- blueok
- blueI don't really care. the only difference to me is that I need to run port 22 locally with sudo
- blueso locally I'll do 2222, so we'll make the port configurable as SSH_PORT in .env.local
- phalethyeah, configurable is best
- bluek
- bluephaleth: ssh2 pivot almost done
- * jreicher joined #primate