| 19 Jul 2025 |
vog | I'd like to run keycloak with PostgreSQL connected via unix sockets. For that purpose, I'd like to add junixsocket to Nix, as I assume this is useful for other Java packages as well: https://github.com/kohlschutter/junixsocket | 20:07:13 |
vog | However, I'm a bit confused on how Java packages are meant to be added to Nixpkgs: | 20:08:51 |
vog |
- Looking at libraries like jogl, but also keycloak plugins, it seems to including binary releases is preferred over building Java libraries from source?
| 20:08:53 |
vog | *
- Looking at libraries like jogl, but also keycloak plugins, it seems to me that including binary releases is preferred over building Java libraries from source?
| 20:09:19 |
msgilligan | Why not just use JEP 380: https://openjdk.org/jeps/380 (it's in JDK 16 and later) | 20:09:22 |
msgilligan | * Why not just use JEP 380? https://openjdk.org/jeps/380 (it's in JDK 16 and later) | 20:09:54 |
emily | building Java libraries from source is hard (because binary .jars are what people push to Maven or whatever) | 20:09:54 |
vog | Is that supported by postgresql_jdbc, and if so, which JDBC URL should I form? | 20:10:07 |
emily | it's not really that useful when a "source build" has all its dependencies precompiled | 20:10:12 |
emily | from-scratch source builds for entire Java dep trees would be cool and there is stuff in Gradle that could make that work, but it's not where the ecosystem is by default | 20:10:30 |
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 |