<![CDATA[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

]]>https://forums.inedo.com/topic/5839/restart-dependent-config-cachingRSS for NodeTue, 15 Sep 2026 21:21:22 GMTTue, 15 Sep 2026 15:34:14 GMT60<![CDATA[Reply to Restart-dependent config caching on Tue, 15 Sep 2026 21:04:12 GMT]]>Hi @sai.pabbareddy,

We will be releasing ProGet 2026.11 this Friday, September 15th.

Thanks,
Rich

]]>https://forums.inedo.com/post/20044https://forums.inedo.com/post/20044Tue, 15 Sep 2026 21:04:12 GMT<![CDATA[Reply to Restart-dependent config caching on Tue, 15 Sep 2026 20:01:19 GMT]]>@rhessinger

Please let me know the release date for PG-3374. OS i can re verify that.

]]>https://forums.inedo.com/post/20042https://forums.inedo.com/post/20042Tue, 15 Sep 2026 20:01:19 GMT<![CDATA[Reply to Restart-dependent config caching on Tue, 15 Sep 2026 16:44:36 GMT]]>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

]]>https://forums.inedo.com/post/20037https://forums.inedo.com/post/20037Tue, 15 Sep 2026 16:44:36 GMT