ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Monday, June 29, 2026

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