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.

A server cluster can have up to 5 nodes; so in the case of a HA cluster, then it'd be the $10K for servers (But you could have up to 5).

@gdivis

We've clarified the instructions for mounting the packages volume. In short, both formats will persist packages beyond the container's lifetime, but if you already have packages stored somewhere, you'll need to mount that directory (as you discovered) instead of using the "proget-packages" Docker volume.

Hello; We are aware of the vulnerabilities. Our usage of this library is minimal, and we do not use it in a manner that would impact product security (i.e. "passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others). So please consider this a "false positive". Upgrading the library to 3.5.0 would add no value to ProGet users, but it would provide significant risk of UI regressions and risk of introducing unknown security vulnerabilities, that haven't yet been reported.

@atripp --registry is just the global arg for swapping out your registry on a per-command basis (instead of in a config file). But! i just realised what was wrong, apologies it's all on me. I still had the old url hardcoded in the publishConfig.registry key in the test modules package.json. i didn't realise that would make npm completely ignore the --registry arg, and blindly try and publish to the old registry address! which was why npm install etc were all working totally fine

@atripp said in ProGet Slow with Active Directory (New) directory: se we can make a few optimizations to recursive searching, but you shouldn't bee seing 5-second page load times in We also get incredible slow performance with "Search Recursively" enabled, our AD directory is quite large (tens of thousands of users), and having read this post, we have improved performance now as a result of disabling "search recursively". Ours was taking around 30 seconds to load a page before, it was pretty painful! I've developed an alternative to AD which suits our requirements and that is to use Atlassian Crowd - I'd be happy to share the source for that when it's finalised. (I also have a support ticket to log with AD regarding "A referral was returned from the server", but I'll post that through the proper support channels.)

@atripp Thanks for the answer. We will update and try again.

Hi, It looks like this is indeed an issue with the Content-Length header not being set properly when ProGet is running as a Linux container. I've logged this as PG-1740.

Hi @patchlings, No problem! We are still investigating some workarounds, but we don't have anything specific yet. We don't currently have a timeline for the .NET 5 switch. We have attempted a .NET Core transition in early 2019, but we ran into too many instability issues and scrapped it. We will wait for .NET 5 to be officially released (Microsoft says November 2020) before we attempt the switch, but it will all come down to the stability of ProGet on .NET 5. Thanks, Rich

Hi, I've solved the problem now. We have reverse proxy and the max request body size value was not set. I think that resulted in the proxy only allowing very small sized packages through, causing the slow network.

Great, thanks! What specific information is missing from the "landing" page? Even the "old" package page has many tabs, so not everything is displayed.

Try LongPathTool for this problem

Hello; this issue is known now, I've logged an issue and we'll get it fixed in the next release; PG-1727 Release is scheduled for Friday, but we may ship it sooner.

@rhessinger Thanks a lot. I will try it.

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, 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

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

This is the sort of error you can expect when the application code and database are not the same version. Had you installed the the same version you had on the old server, it wouldn't be a problem. But fortunately it's an easy fix I think. Just follow the Database Manual Installation Instructions and run inedosql against your database. Then it'll get updated to the right version. FYI please review the Backing Up & Restoring as well :)