Problem
The team-operator is generating /etc/rstudio/workbench_nss.conf (note the underscore) which configures the NSS module to use the HTTP address:
server-address=http://workshop-workbench.posit-team.svc.cluster.local:80
Workbench already auto-generates the correct /etc/rstudio/workbench-nss.conf (note the hyphen) which uses the unix socket:
server-address=unix:/var/run/rstudio-server/rstudio-rserver/user-service.socket
admin-token-path=/etc/rstudio/admin-token
user-token-path=/etc/rstudio/user-token
verify-ssl-certs=1
Using the HTTP address instead of the unix socket is a known deadlock scenario for user provisioning. This was observed during a workshop with ~2,100 users where initial login via Keycloak OIDC/JIT provisioning was failing intermittently (users had to retry 3+ times to successfully sign in).
Expected Behavior
The team-operator should not generate workbench_nss.conf. Workbench handles this automatically and correctly uses the unix socket path by default.
Context
Problem
The team-operator is generating
/etc/rstudio/workbench_nss.conf(note the underscore) which configures the NSS module to use the HTTP address:Workbench already auto-generates the correct
/etc/rstudio/workbench-nss.conf(note the hyphen) which uses the unix socket:Using the HTTP address instead of the unix socket is a known deadlock scenario for user provisioning. This was observed during a workshop with ~2,100 users where initial login via Keycloak OIDC/JIT provisioning was failing intermittently (users had to retry 3+ times to successfully sign in).
Expected Behavior
The team-operator should not generate
workbench_nss.conf. Workbench handles this automatically and correctly uses the unix socket path by default.Context
dev.workshop.posit.teamdeployment