Hi @scroak_6473 , I'm not sure what the issue is and the errors are very peculiar, I assume that everything works, until you restore the database? Afte restoring database, there are a few paths I would check under Admin > Advanced Settings: Extensions.BuiltInExtensionsPath <--- should be C:\Program Files\ProGet\Extensions Extensions.ExtensionsPath <--- should be C:\ProgramData\ProGet\Extensions Extensions.CommonCachePath <-- should be C:\ProgramData\ProGet\ExtensionsCache Extensions.UseNewExtensionLoader <--- should be checked And then after edting those, make sure to restart the web.

@scroak_6473 ooh I forgot to mention, but this feature was released a little while ago. It's a preview feature, and you can enable it by going to [User Icon] > Personal API Keys > Enable. LMK your thoughts!

Hi @scroak_6473, ProGet automatically handles creating a temporary API key for use with clair. When ProGet integrates with clair, it generates a temporary key to use to check layers for vulnerabilities then deletes it when the process completes. So there is nothing you have to do to authenticate clair to ProGet. If the key is still there after running the scan, my guess is an error occurred while trying to clean it up. As for the other error you are seeing, are you able to pull an image with that layer attached to it? I can probably create a SQL query for you to link a layer to the image if needed. Thanks, Rich

hi Simon, The default connection pool size for .NET's SQL Server connection is 100, so that behavior wouldn't be unexpected if there were a lot of requests to ProGet (very common in a package restore) and the database driver wasn't responding fast enough for whatever reason (also very common... too many network requests coming in, too many network requests going out, slow database server, etc.). The .NET Runtime will eventually close those connections, and they will then be terminated by the TCP stack shortly after (minutes?). Alana

Hi @atripp Just to let you know that I just upgraded version 5.3.24 and can confirm that this issue is now resolved! Thanks so much for all your help! Thanks Simon

Hi @scroak_6473, We have fixed the issue with creating new AD User Directories and vulnerability sources in .NET 5. It is set to release in ProGet 5.3.19 which is due out December 18, 2020. Thanks, Rich

hi @scroak_6473 , just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10 Getting LDAP/LDAPS to work on Linux was a whole different problem to solve; the three major libraries (DotNetCore, Mono, Novell) all had separate and strange bugs. We'll be blogging about this, but for now, it might be a step in the right direction for addressing the problems you're seeing, at the very least.

@scroak_6473 got it, thanks! Okay, I've requested to engineering about adding it to the upcoming ProGetCore container, and we'll update this with more details as we have i

Hi @scroak_6473, I created a branch and a blank page on GitHub for Docker Swarm. You should be able to add your notes and examples there. Please let me know if you have any issues! Thanks, Rich

That's amazing! Thanks so much @rhessinger You guys rock!

Hi @gdivis I can confirm that TimeZone can now be specified as an environment variable in ProGet 5.3.7 Thanks for including this! Simon

hi Simon, This records are maintained via Package Usage Scanning, which is something that routinely scans external resources for packages, and updates the status when a package is or isn't installed. It's a little different from deployment records, in that deployment records are historic data and package usage is current data. While you could write your own PackageContainerScanner by using the Inedo.SDK, Otter can collect the packages that are actually installed on various servers; the Otter-usage scanner (buitl in) simply queries to Otter about the status of those scans.

Hi @scroak_6473, Glad to hear it! Thanks, Rich

Sounds neat, we'd love to learn how you have it set-up! This is the first request for this, and like all feature requests, we want to make sure we can document it well. So I wonder, can you think of a way to improve our documentation with an example of your Stack File, and some mention how you're suing docker swarm to monitor things? Maybe as a subpage? Here's what we have now: https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker In any case, we are definitely open to collaborating with ways to improve not only our API, but our docs. Seems this might be a great way to work together? We honestly don't anything but basic knowledge on swarm / Stack Files, so if you could write how you set it up / monitor it, we will be happy to fix the code to work with the docs. I suspect changing the API to work as you requested would be infinitely easier for us than figuring out Docker swarm :) Also --- please note that we are now using proget.inedo.com instead DockerHub, it seems a lot of other vendors are doing the same, and it's easier for us to maintain our own build process (not possible on Dockerhub).

Hi @scroak_6473 , Yes, I have included this fix in 5.3 as well. It will be released as part of ProGet 5.3.1. Thanks, Rich

Hi @scroak_6473, That's great to hear that the impersonation has fixed the issue. We have fixed this issue to not require impersonation in ProGet 5.3.2. I will let you know if anything changes! Thanks, Rich