Hi @stevedennis, Seeing the PG-2716 solution included in the last release 24.0.8, we upgraded. In 2024.8 version the creation of new Debian feed works perfect, but the feedGroup property doesn't seem to do it. Could you double check if feedGroup is the right name, and if it's included on current version?

Great! I don't believe that there is any public reporting of VISX package vulnerabilities, so this is not data that would be available in ProGet either

Hi @daniels, This is technically possible, but it's not something that we support out-of-the-box I'm afraid. The closest way to accomplish something like this would be: Use the Otter API to create a server entry with the appropriate roles (similar to what you'd do in the UI) Install/run the agent on the computer which will connect to Otter Use the Otter API to trigger a job/ remediation Optionally, remove the server from Otter and Stop/uninstall the Agent So it's not easy from the user perspective. However. if Otter and this approach looks like it will work for you, then it's something we can definitely explore together as a user/customer, and build out a use case / case study / etc. That'd be best to start a conversation w/ someone in our customer / sales team on that. Otherwise, there really hasn't been enough demand for this particular use case, and it's hard enough to market Otter's other use cases, let alone develop build new ones ;) FYI - note that you can also run the Inedo Agent in outgoing mode: https://docs.inedo.com/docs/inedoagent-overview#communication-modes Thanks, Steve

Turns out the errors I encountered were entirely related to the "new" SQL Server driver that ProGet 2024 was using. Although this was in beta for well over a year, it was "only" in production for a few months by the time we incorporated it into ProGet. This driver issue impacts anyone who uses .NET on Linux. As I mention, I think it's pretty clear that Microsoft has effectively abandoned SQL Server. It's one thing to release something this low-quality and untested... and another to have it linger with issues like this in production for months. We will be moving to Postgres, which do not have these endemic problems. In the meantime, I have instituted the "one year rule" for Microsoft products - meaning, unless it's been shipped in their general release channel for a year, we will not even consider using it.

Hi @matt-wood_5559, Our solution for Maven builds is to leverage CycloneDX to generate the SBOM, and then upload that SBOM to ProGet: https://docs.inedo.com/docs/proget-sca-java We had considered reproducing the functionality, but the only way to get dependency information from a Maven project is to create a Maven plugin and "watch" the build as it happens --- and that's already what CycloneDX does very effectively. If you can think of ways to make it easier to work with pgutil we're very open to that :) Thanks, Alana

Hi @matt-wood_5559, I think I understand what you're asking - basically you'd like to create a feed when some users see one set of packages, but other users see a different set? This is definitely not possible, and it's simply not something ProGet does from a design standpoint: i.e. "file-system type" granular permissions. While it might seem convenient or nice to give users "just a single URL" to access, it ends up makes things much more complicated to configure/use/maintain. Basically some users will get random "package not found" errors while others will build fine. It'd be very confusing and big headache. Instead, it's best to educate on different feeds/repositories, and help them use and request access as needed. Hope that helps, Alana

Ok that makes sense thanks, I can see the option to add addition files now.

Hi @matt-wood_5559, I might need a little more information / screenshots with what you're looking at here.... There could be a bug/oversight, etc. Perhps you could walk through steps / show screenshots of what you're seeing? If it's on maven central, we can then repro and take a look Thanks, Alana

Hi @matt-wood_5559, A Maven package's license is determined by the license field in the POM: https://maven.apache.org/pom.html#Licenses There are unfortunately no real standards here, and the author can put in anything from a SPDX Code (which is recommended, by the way) to a string like "Apache license" (which probably means apache 2.0, but who knows?). We would rather not guess what the author might have intended, so ProGet only detects licenses with SPDX codes and then lets you decide how assign which codes to other license types as you come across packages that don't follow SPDX. However, once you start associating those strings with licenses, it will work for future packages. Thanks, Alana

@forbzie22_0253 setting the proxy programmatically is not something we currently support or document at this time, but if you're dedicated you could use native API to the newly-developer settings API: https://github.com/Inedo/pgutil/blob/thousand/pgutil/Settings/ListCommand.cs It's configured via values in the Configuration table.

Hi @maciej-luszczynski_5271, Thanks for bringing this to our attention. I have corrected the example as suggested. Thanks, Dan

@atripp the health endpoint looks good, thanks

@francesco-campanella_3733 thanks for continuing to research this - we just haven't had a chance to look further. Did you try editing the feed settings (especially the Feed Features, which would save a new Feed Config), and then re-saving again? We will fix the bug, I would just like to be able to reproduce it so we know for sure what's causing it :)

@atripp thanks, resolved now.

Hi @sebastian, Thanks for sharing your thoughts on this! Few things to point out... [1] The "Missing Package Problem" is not as bad in ProGet 2024, mostly because it will only apply when there's a license rule. In ProGet 2023, a "missing package" would happen even for vulnerabilities. [2] We're working on a new feature/module (tentatively called "Remote Metadata") that is intended to routinely cache/update meatdata from public repos like nuget.org, npmjs.org, etc. This feature enables two usecases: Routinely update "server-side metadata" like Deprecated, Unlisted on cached packages Fetch metadata for packages not in ProGet during build analysis It works somewhat independently, and basically it'll just show up on the Admin tabs as like "Remote Metadata" and you can configure providers, urls, etc. I hope to have a prototype in a couple weeks and will post some details on a new forum posts. As an FYI this is something we will limit in the Free/Basic editions and have full-featured in the ProGet Enterprise product. [3] "Package In ProGet" could be a policy rule to add after RMetadata feature, though it's probably not a big deal if ProGet can detect licenses thanks to RMetadata Best, Alex

Hi @sebastian, I took a quick look, but its not a simple cherry-pick; this is a bug in the code that does policy analysis, and there were enough changes between ProGet 2023 and ProGet 2024 in that to make it a bit risky / time-consuming to bring over... Thanks, Alana

Just wanted to give a brief update to the issue from @mortenf_3736 that we discussed via the support ticket. We were never able to get to the bottom of it, but it was entirely related to running on ACA. Container Setup VM Setup Azure Container Apps - Running 4 minimum replicas, max 8 replicas, each 3 cores and 6gb memory Two D4 (4 cores, 16GB memory) VM with internal load balancer in front between them Mapped storage from Azure Storage Account v2 Fileshare Managed Premium Shared Disk, connected to Fail-over Cluster and shared between both VM Azure SQL Database with 4 cores dedicated Azure SQL Database Server less, scaling between 0.5 to 4 cores This doesn't seem to be related to Linux/Docker/Kubernetes, as we have several high-traffic users on Kubernetes clusters without issues like this. However, we have seen a handful of Azure-related problems over the years that manifested in ProGet: a bad hard drive that was constantly corrupting packages another had really slow disk I/O (one server out of a handful) we've seen a buggy storage driver cause some big impacts across some kind of storage configuration So we believe the issue is the Azure platform itself, similar to the above hardware/software glitches we've uncovered over the past. We're doing our best to research/identifying issues, and Inedo/ProGet Users aren't the only ones who are experiencing pain like this. Consider this report from a Azure "big data" user: I have suffered from chronic socket exceptions in multiple Azure platforms - just as everyone else is describing. The main pattern I've noticed is that they happen within Microsoft's proprietary VNET components (private endpoints). They are particularly severe in multi-tenant environments where several customers can be hosted on the same hardware (or even in containers within the same VM. The problems are related to bugs in Microsofts software-defined-networking components (SDN proxies like "private endpoints" or "managed private endpoints"). I will typically experience these SDN bugs in a large "wave" that impacts me for an hour and then goes away. The problems have been trending for the worse over the past year, and I've opened many tickets (Power BI, ADF, and Synapse Spark). Other Azure users (who are much more technical than we are) have confirmed that there are indeed severe issues with their SDN infrastructure. Microsoft does appear to be aware of these endemic issues with their platform, and for the time being we simply cannot recommend using Azure's container services for anything that will have any kind of load. Hope that gives some insight in case anyone stumbles across this thread. Alana

Thanks, we're planning to upgrade tomorrow. Will keep you updated.

Hi @arkady-karasin_6391, I'm afraid we don't have enough information to troubleshoot the problem. The use case you describe (using ProGet as an offline cache) is very common, so it might be some kind of misconfiguration on the npm side or something. I don't realy know. I would check the npm logs, try to monitor http traffic, etc. If you can "see" the package in ProGet as a Remote Package, and then download the package from the web page, then the npm client can do the same. The npm API cannot "see" whether it's a local, cached, or remote package, so the package is pulled regardless. Best, Alana