Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Restart-dependent config caching
-
Permission and directory config changes don't take effect until a service restart
We've run into this twice during our Enterprise trial evaluation and want to check if it's expected behavior.
Case 1 — RBAC: We removed two permission grants from the Anonymous user/group ("Administer globally" and "View & Download Packages globally") via pgutil security permissions remove. pgutil security permissions list immediately confirmed the grants were gone from the database. Despite that, requests with fabricated/wrong credentials (which should now fall through with no permissions at all) continued to succeed at both package downloads and admin-level actions (creating a feed) immediately after the change. Only after we ran docker restart proget did the fix actually take effect — re-running the identical tests afterward, everything correctly failed with 401/403.
Case 2 — Directory config: Separately, while configuring an LDAP user directory, we changed the "User Search Base" field and saved it. The LDAP server's own connection log showed ProGet still querying with the old (incorrect) search base on the next login attempt. Again, only a docker restart proget made the new value actually take effect.
Is this expected — i.e., does permission/directory configuration get cached in memory and only reloaded on service restart? If so:
- Is there a lighter-weight way to force that cache to refresh in a production deployment, short of a full service restart?
- Is this documented anywhere, so we can build it into our own change-management process?
Thanks,
Sai -
Hi @sai.pabbareddy,
For case 1, there is a cash of the users permissions for a short while (~5 minutes). You can force a cache reset on Administration -> Manage security -> Tasks/Permissions page, hover over Test Privileges, and then click Clear Cache. That will force the operation to take effect immediately. This is most likely happening because the bad user was already logged in prior to the change of permissions.
For case 2, that same cache from case 1 looks like it also affects this as well and the clear cache button should also fix this. Looking at the code, it looks like there was a regression that removed the user directory cache clearing, but left in the user privleges cache clearing.
I added a ticket, PG-3374, to fix these and it will be released in ProGet 2026.11.
Thanks,
Rich -
Please let me know the release date for PG-3374. OS i can re verify that.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login