Label Studio _really_ prefers using a direct object storage model. Can't
say I blame them, it makes sense given they are running Python.
I had to bump Authentik to not use its default port so that minio could
use its own default port. That seemed safest given that Authentik is
always proxied but minio/S3 may _not_ be. I'm just not sure.
It was rather rediculously hard to get the CSRF settings correct. I
don't think I can register new users on anything but the commandline at
this point via:
podman exec -it podman-label-studio /bin/bash
label-studio start --username <username> --password <password>
Where <username> should actually be an email.
This currently has the architecture hard-coded. That's bad, but nix is
hard, and there's probably a much better way to integrate this into the
system when I can be bothered to do it.
This was a huge hassle. I really wanted to see it working under a
non-root user since it writes files, but that ended up being impossible
because of several bugs in podman's rootless integration with NixOS.
I've kept pieces of the logic around and commented out in case I can fix
it in the future as it would be more secure.
I also tried to connect to Postgres over the unix domain socket, but the
problem here is that the container is built to run as root and I'd need
to do some elaborate mapping of the root user inside the container, the
non-root user outside the container, and the Postgres auth scheme.
This would be great stuff to sort out, but I'm out of time now to work
on it.
I move the secrets file to be more consistent with the naming.
I removed parts of the postgres config that is no longer needed now that
the database is running locally.
The podman integration was pretty janky because it relied on running a
pod and the NixOS integration with pods are essentially non-existent.
This led to issues with the port being improperly forwarded when
partially restarted.
Now instead I use a flake dedicated to running authentik. This allows me
to specify some of the config in the module directly and some in
secrets, which is really nice. I've additionally added some changes to
the listen address so that the service isn't exposed over public IP
addresses.
This includes a new paradigm for using a pgpass file, which is great, as
well as sorting out how to properly do a bash script shebang in a
service file.
I'm going to spin up some dev resources to see if I can figure out how
to compile the latest. In the mean time, this is doing what I want and
is going to get deployed.
I kept hitting errors like:
Something went wrong. Here's the specific error message we encountered: Operation failed after 3 attempts: 400 {"type":"error","error":{"type":"invalid_request_error","message":"\"claude-opus-4-20250514\" is not supported on this API. Please use the Messages API instead."}}
I believe from https://github.com/danny-avila/LibreChat/discussions/7554
that I may need to update the version of librechat I'm running.
With these changes I have librechat running and being properly
reverse-proxied and I can login via SSO. I was not able to get a
reasonable response yet from Claude.
