ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Monday, June 29, 2026

  1. * jreicher joined #primate
  2. * jreicher joined #primate
  3. * phaleth joined #primate
  4. bluehi phaleth
  5. bot<discord:phaleth> hi blue
  6. phalethI'm trying to figure out how to pass args to postgres
  7. phalethlooks like yet another limitation of the API
  8. phalethmore work for podman exec
  9. phalethpodman service taking 677M of memory is too much
  10. bluethe postgres one?
  11. phalethnope, the podman TCP service
  12. blueoh, each one of them consumes 677M?
  13. phaleththe other one did, it just went down after a day
  14. bluewait, why did it go down, we need it
  15. phalethheh, I mean down in terms of lower memory usage
  16. blue● podman-api-containernetwork.service - Podman API Service
  17. blue Loaded: loaded (/etc/systemd/system/podman-api-containernetwork.service; enabled; preset: disabled)
  18. blue Active: active (running) since Sun 2026-06-28 17:07:47 CEST; 1 day 1h ago
  19. blueoh
  20. phalethI think we should try to deploy on freebsd
  21. bluebtw, I was gonna ask you, we need repopack to configure systemd jobs for the containers, so they're auto-restarted on reboot? or can we just have podman do it
  22. bluebecause I'd hate configuring a systemd job for every container, that's gonna turn into hell very quickly
  23. blueyeah, I don't mind getting another vps for freebsd
  24. phaleththere is a service called podman-restart.service, the unit files is written by podman people for the most part, but for some reason it sometimes fails to start all containers
  25. bluedamn
  26. phalethalso btw, the problem yesterday with certs not being renewed was cause of systemd-networkd
  27. phalethI think systemd has problems
  28. blueyeah
  29. bluean alternative to the podman-restart service, is repopack gradually putting containers online
  30. blueso I told you, I'm aiming for full redundancy of all systems
  31. blueso that we can update every vps at any time
  32. phalethyeah, if repopack can bring it up, but what can bring up repopack
  33. bluethat'd be pid1
  34. bluebut then pid1 would only need to start the repopack containers
  35. phalethrepopack will need to run on freebsd machine that'd never need to reboot or so heh
  36. bluenever need to reboot isn't a good plan
  37. bluesometimes needs to reboot, and how we solve that, is a better plan
  38. blueredundancy is key here, but it's a bit complicated to achieve
  39. blueif something doesn't require a db, like primate website, it's straightforward
  40. phalethback in old days of no bots poking around I had debian VPS running for two years without an update all exposed to the interwebz
  41. blueyeah but updates are expected in software, it's just part of it. if you get a kernel vulnerability, you have to update
  42. bluewe have to work around that
  43. blueI'd prefer a "we do it as if we constantly need to update" mindset
  44. blueeven if we don't end up constantly updating/rebooting, it's good to have the infrastructure gracefully take that
  45. bluethe only problem is how to switch over the containers
  46. phalethswitch over the containers?
  47. blueyes
  48. phalethlike to another server?
  49. blueyou have vps1 and vps2, now you wanna update vps1, so you switch all running containers to vps2. you start them on vps2, and point your dns resolver or whatever resolves stuff to vps2
  50. bluethen you finish updating vps1, you move back to it, then you update vps2
  51. bluethe only choke point becomes the dns resolver
  52. phalethI think in the end there should be one haproxy VPS doing all the load balancing
  53. phalethand behind it two repopacks switching
  54. blueya
  55. bluebut even that should be load-balanced/provided with redundancy
  56. phalethand then a bunch of cheap VPSes with containers being constantaly brought up and down however repopack sees fit
  57. blueya
  58. phalethconstantly*
  59. bluetechnically you can enter several ips for one dns
  60. phalethtoo complicated and DNS takes a moment to update
  61. blueand if you have an api for your dns server, then you use that
  62. phalethhaproxy is a good single point of failure
  63. phalethbut anyway, end of next month should be good to start messing around with freebsd
  64. bluethere's no good single point of failure
  65. blueya
  66. bluecan we run our own dns server?
  67. phalethnot sure, how do dns servers get to list like this https://public-dns.info/nameserver/de.html
  68. nevetDNS servers in Germany
  69. phalethlot of contabo ones there
  70. bluegood q
  71. bluedreamreal: don't you think nevet should at least say like: "Title: %s" or smth?
  72. blueright now he doesn't come off as a bot, but as a rambler :P3~
  73. dreamrealsure, why not
  74. dreamrealI'll file an issue
  75. bluethx