Chat Logs

  1. * phaleth joined #primate
  2. bluehi phaleth
  3. phalethhi blue
  4. phalethlong list https://freebsdfoundation.github.io/freebsd-laptop-testing/
  5. nevetFreeBSD Laptop Compatibility
  6. bluelol
  7. bluedid I tell you the ssd on my t480 broke down?
  8. blueI ordered a samsung 990 PRO NVMe M.2, 1TB, should be arriving today
  9. phalethalready huh
  10. bluewell it was a used computer
  11. blueI should have known tbh, to begin with. because when I first put superarch on it, the first install broke down in the middle. and then I had a sudden btrfs remounts root as readonly, once a week
  12. blueso I was expecting it
  13. bluethis 990 PRO NVME M.2 is totally an overkill for this computer: its throughput is roughly 4x than what the pci 3.0 x2 port can handle
  14. phalethok, as long as you don't loose any data it's fine, I also expect mine to break down
  15. bluebut it's a tlc thing, and it's reliable, I could just put it in the next comptuer
  16. blueand I prefer 1tb to the 512mb I had. these containers take a lot of room
  17. bluethe oracle container is like 5gb
  18. blue512gb*
  19. blueI've been working on repopack. so good news, I checked how gitea handles ssh, and it's easier than I thought. you have two options. you can have a hugebutt authorized_keys file where for every key, you specify a command and then you essentially have a command that gets the key and runs stuff
  20. blueor, the better solution is, there's an openssh config variable that does that as well
  21. blueand inside the run command, the key is available as OPENSSH_KEY or so
  22. blueso you can derive the user and the acl from that
  23. blueno need for ssh2 or other shenanigangs, we can keep to openssh
  24. blueanother thing I've been doing is putting plans into the database (not commited yet)
  25. blueso I've noticed the primate/node, primate/bun and primate/deno plans all end up having the same yaml
  26. phalethso there will be a huge openssh config file?
  27. blueno, we're going with the second option
  28. phaleththe variable? is there no size limit to that?
  29. blueit's programmatic
  30. blueso you have two options
  31. phalethyeah, I cannot imagine, but if openssh server has some sort of API then great
  32. bluehugebutt authorized_keys with these lines:
  33. phalethI can imageine the authorized_keys file
  34. phalethbut the problem is that it's a file and not a db
  35. bluecommand="/path/to/repopack serve key-42",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA
  36. blueor, you put in sshd_config
  37. blueAuthorizedKeysCommand /usr/local/bin/rp-authorize keys -e git -u %u -t %t -k %k
  38. blueAuthorizedKeysCommandUser git
  39. bluesmth like that
  40. phalethok, well, would be great if all of the data would be stored in the db as well and the application was just able to configure whatever necessary
  41. blueyes. the pubkeys will be in the db
  42. blueand this command will just run
  43. bluequery the db using the %k
  44. blueand do stuff
  45. phalethjust imagine you have a problem on PROD system and now you need the data and configs quickly
  46. blueit's all gonna be in the db
  47. phalethall the software I know and work with is making the process of debugging a problem very time consuming
  48. phalethcool
  49. bluethis rp-authorize or whatever will just query the db. fortunately primate can do that, because random .ts files can just import the db or stores and query in isolation
  50. phalethok, sounds good
  51. phalethnow the difficulty may only be in building the entire system, but that's expected
  52. phalethalso deploying
  53. bluewell, one of the milestones would be deploying rp locally, on rp
  54. bluefor that I might need haproxy locally, which is going to be a bit annoying
  55. blueesp with the subdomains and stuff
  56. phalethI think rp will just run in a priviledged container and there will only be one subdomain pointing to it
  57. phalethpriviledged so it can manage the haproxy configuration and connect to podman via localhost and whatnot
  58. blueya
  59. blueso as I was saying, I reworked the plans a bit
  60. phalethactually the repopack.com domain should point to it since it's hosting the website
  61. bluethey now have variants, which means different Containerfiles (it's a 1:n table)
  62. blueyes
  63. blueso the primate plan has node, node-lts, bun and deno variants. the main variant is node-lts, but you can choose another if you want
  64. phalethok, variants of containerfiles?
  65. blueyes. plan variants. a deployment_plan_variant table containing deployment_plan_id and containerfile
  66. phalethok, well, people will wanna run nextjs
  67. bluethat's a nextjs plan
  68. blueit's unrelated to the primate plan, and has other conditions (like a next.config.js file, and a next dependency)
  69. phalethbut if these variants are not difficult to create, as in it's kinda just configuration then why not
  70. blueyup
  71. bluehttps://superarch.org/variants.png
  72. phalethalso if it follows the idea of pre-built images then it may also make deployments fast
  73. blueyou cannot 100% prebuild the image because we're copying your code into. but you can prebuild some of it
  74. blueI also added the concept of extensions, to a plan. I don't know if it's going to be widely used but for primate it's super useful
  75. phalethah, so people should be able to edit those Containerfiles
  76. blueI was able to a define a go_mod extension for the primate plan, and then I could deploy apps/go (it needs a `go` executable)
  77. blueso RP can now technically deploy a primate app with go, python and ruby backends, even if combined
  78. bluewhich I don't think any service on earth can do
  79. phalethyeah
  80. phalethI think the idea is to make all nextjs plans paid and primate ones free :)
  81. blueand yes, people will be able to create their own custom plans, either for their own use, or submit for general use
  82. bluehaha, YES!
  83. blueanyway, before I commit those changes, I'll add a preseed step you can execute so you don't have to manually enter the plans I've entered
  84. bluethe nice thing now is that you can edit a plan, redeploy, and see if it improves/changes anything
  85. * jreicher joined #primate
  86. phalethwell, do you think it'd be possible to disallow editing of FROM lines? and also COPY lines
  87. phalethjust have the person specify where is the src dir in the repo
  88. bluethat's already done; you specify a path for your app
  89. phalethand also not allow any fetching of whatever from the interwebz, which is tricky
  90. phalethonly allow the builder to reach container registries
  91. phalethfor starters I'd just not allow anybody to edit a plan
  92. bluestep 1 is just us making plans. step 2 is users submit plans, and we approve them. step 3 are custom plans used by the user in his apps, but that's the most dangerous
  93. bluefor now we're going to stick to step 1 and if anyone needs anything he can create a support ticket on repopack.com/repopack/support repo
  94. phalethI think we can just let anybody do whatever but with very limited resources
  95. blueya
  96. phalethand if they want their app to run fast then they should not use nextjs or whatever :) just use primate to get all benefits
  97. phalethcause you know if you let people execute arbitrary code you might as well just let them deploy however they want
  98. phalethpodman has a bunch of not only resource limits but also rate limits, but it should be tricky to figure out the usage
  99. blueyes
  100. phalethsome rate limits will just have to be enforced by repopack
  101. blueremember that in the future, we're going to segment customers by vps/dedi if they're enterprise
  102. bluesince you'd need slas for these servers
  103. blueenterprise clients are gonna be the money cows, anyway
  104. phalethyeah, windows servers
  105. bluespeaking of slas, I belive contabo offers them
  106. bluehaha
  107. bluephaleth: I pushed out all the changes. I'll send you the json export
  108. blueyou just go to plans, click on Import JSON, select the file, and run it
  109. phalethjson
  110. blueyes
  111. blueeasiest way for you to seed the db
  112. phalethso why is not automatic? like on every start it can check if there is a seed script and if it executed that and if not then exec that
  113. blueit could be, but this was easier for now. we're gonna mess around a lot with those plans
  114. phalethI guess it's cause WIP :)
  115. blueexacty
  116. bluethe import and export are gonna go away anyway
  117. phalethok, I will have to try later
  118. bluecool
  119. bluenow you can also choose 'detect' in the plan configuration of an app
  120. blueif you choose an app, you will have the option of choosing a variant
  121. blueand all primate apps under the primate repo /apps, are adapted to be deployable by RP, given the plans I've provided you
  122. bluethough I think only the primate/bun variant handles extensions, for now
  123. blueso if you want to test apps/{go,python,ruby}, you'd need to use that variant
  124. blueif you a plan*, I meant
  125. blueif you choose a plan*
  126. bluehttps://github.com/primate-run/primate/commit/a822c25a842d21e2159b2eb8643e466c7f4b4298
  127. nevetmake all apps deployable · primate-run/primate@a822c25
  128. bluethis is the commit that adapted them. mostly moved the ports to .env.local instead of hardcoded in the primate config, since RP can't handle that
  129. blueand I've patched primate to read the PORT env variable if set, and if http.port wasn't explicitly set in the config
  130. blueso what happens is kinda cool. if you run those apps locally, they're gonna use the port in .env.local. which is great because you want different ports to be able to run them in parallel, with no conflicts
  131. bluebut if you run those apps through rp, they're isolated and you can just use the default PORT that the primate plan injects, which is 6161
  132. blueand then rp knows to map this inner port to some random external port 42xxx
  133. blueanother thing I did with primate is that it reads the HOST env variable if http.host isn't explicitly set
  134. bluethis was very important for rp, because primate's default is 127.0.0.1, that doesn't work in a container
  135. blueso the primate plan just injects 0.0.0.0 and everything works
  136. bluewe skirted around this problem by explicitly setting http.host to 0.0.0.0 in apps/website, if you remember. once we move to rp for deployment we won't need this hack
  137. bluehttps://github.com/primate-run/primate/blob/master/apps/website/config/app.ts#L9-L11
  138. bluethese 3 lines will disappear once we use rp to deploy the website
  139. bluewhich is good: they were only added so it works in podman
  140. phalethyeah, noone else will be deploying primate website on public intewebz
  141. phalethanyway, think about only having primate plans then a static plan and then a custom plan and that's it
  142. phalethcause nowadays people expect magic to happen and not to have to choose a plan
  143. blueya