| 19 Jul 2025 |
 vog | Ok, no problem for me, actually this simplifies my packaging work. ;-) | 20:11:21 |
 msgilligan | I would like to see bootstrappable Java libraries/jars someday, but emily is right, it's not currently practical. | 20:11:58 |
| msgilligan | I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBCs drivers are using JEP 380 yet. | 20:14:11 |
| msgilligan | * I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBC drivers are using JEP 380 yet. | 20:15:14 |
| vog | Well, the PostgreSQL JDBC driver explicitly recommends using junixsocket: https://jdbc.postgresql.org/documentation/use/#unix-sockets | 20:15:41 |
| vog | (and doesn't mention JEP 380 at all) | 20:15:56 |
| vog | This article explains everything quite in detail: https://www.morling.dev/blog/talking-to-postgres-through-java-16-unix-domain-socket-channels/ | 20:22:16 |
| msgilligan | I'm currently reading it... | 20:22:37 |
| vog | Summary:
- With postgresql_jdbc we are out of luck with JEP 380, we do need junixsocket
| 20:22:44 |
| vog |
- The Vert.x Postgres Client does support JEP 380, and might even be accessible by keycloak given that keycloak uses Quarkus. But I have no idea how to configure this.
| 20:23:45 |
| vog | (at least that's my understand of this issue. Feel free to correct me.) | 20:25:02 |
| msgilligan | Are you going to use the Keycloak module: https://nixos.org/manual/nixos/stable/index.html#module-services-keycloak ? | 20:27:24 |
| vog | No, because I need it to run in a bwrap sandbox, in which running systemd is a pain. So I essentially just use pkgs.keycloak.override { ... my config, my plugins ... } and this serves my needs pretty well. | 20:33:03 |
| vog | (except for the missing unix socket support) | 20:33:20 |
 emily | systemd can all the bwrap sandboxing stuff itself | 20:33:26 |
| emily | many service modules in NixOS already apply a bunch of such hardening | 20:33:33 |
| emily | * systemd can do all the bwrap sandboxing stuff itself | 20:33:40 |
| vog | It's not just about hardening. It's about providing lightweight containers. | 20:34:02 |
| vog | So I need process supervision inside the sandbox, not outside. | 20:34:43 |
| emily | right, NixOS modules are quite bad about being unnecessarily singleton | 20:35:00 |
| vog | The s6 tool do perform this job perfectly. | 20:35:03 |
| emily | we do have NixOS containers for that, but they are moderately heavyweight | 20:35:18 |
 Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
right, NixOS modules are quite bad about being unnecessarily singleton Entire reason behind nix-minecraft lmao | 20:35:30 |
| Infinidoge 🏳️⚧️ | Being able to host Exactly One minecraft server sucks | 20:35:54 |
| vog | Ok, but back to you original quesion: No, I don't neet a module configuration, just a pkgs configuration. But why were you asking? | 20:36:28 |
| emily | unfortunately the module system is kind of bad (my hot take) | 20:36:33 |
| emily | (but the things we do with the module system are nice) | 20:36:47 |
| emily | do wish we had something that didn't make singletons the happy path | 20:37:02 |
| emily | because manual containerization sucks | 20:37:10 |
| vog | Ok, so I'm now back where I started. Many alternatives, but none of which appears interesting of even feasible to me. So I'd like to add junixsocket. | 20:39:36 |
