@atripp @joshuagilman_1054

TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...

• [System.Nullable``1[[System.Int32]]]
• [Nullable[int]]

... much easier to read

You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.

The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.

Hi @andreas-unverdorben_1551 ,

npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.

Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.

So, a much less powerful server doing a lot more processing is going to be a little slower ;)

Running ProGet in a server cluster will certainly help.

Cheers,
Dean

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

Hi @arkady-karasin_6391 ,

A 403 error means Not Authorized; since those are publicly-available repositories, my guess is that you have a Proxy or Content Filter that's blocking that URL, and the ProGet Server is getting a 403 response from that intermediate server.

-- Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

HI @parthu-reddy ,

Thanks for the feedback; I update the docs to mention that the feeds/permissiosn would also need to be updated as well.

We hope to handle an in-place migration in a future version, but didn't want to delay shipping the feed. Please let us know if you have any issues/feedback.

Note we are adding several improvements to the Maven (New) feeds in ProGet 2024.15:

• PG-2798 Add Direct Download (Artifact Import) Support for Maven (New) Feeds
• PG-2797 Add OSS Metadata Caching Support to Maven (New) Feeds
• PG-2796 Improve MavenIndex Download Visibility for New Feed Connectors
• PG-2792 Feed Management API Returns Empty Type on Maven2 and new feeds
• PG-2794 Add Simulated Directory Browsing to Maven (New) Feeds

-- Dean

Hi @parthu-reddy ,

I'm afraid we don't have enough information to help with this; it appears to be an error the tool you're using (packet), and there's not enough information in the screenshot to see what error packet is encountering. It just says "Packaged failed with could not download..."

We aren't familiar enough with packet to know how to follow their Stack Trace.

If you can't find a clear error message, I would use an HTTP Proxy tool like Fiddler Classic to inspect the traffic that packet is making, and see if you can spot an issue there.

I would also try downgrading packet , as it's very possible there's a regression in the tool.

-- Dean

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

Hi @stuart-houston_1512,

ProGet will download nightly updates of the vulnerability database from an inedo.com server.

If you're running in a totally air-gapped environment, then you obviously won't get these updates. However, each version of ProGet includes an up-to-date database, so upgrading will get you the updates.

--Dean

Hi @steviecoaster ,

The Native API can be a little finicky, especially since you can invoke with JSON, forum-encoded values, querystring, and I think even XML. But it sounds like you're on the right track.

Let me share the C# code that ProGet uses to set the password:

    using (var rfc2898 = new Rfc2898DeriveBytes(password ?? string.Empty, 10, 10000, HashAlgorithmName.SHA1))
    {
        var bytes = rfc2898.GetBytes(20);
        DB.Users_SetPassword(userName, bytes, rfc2898.Salt);
    }

... it looks a little different than the code you're using, so hopefully that will help!

-- Dean

Hi @russell_8876,

Thanks for all the additional details!

Actually, this is definitely a bug in pgutil, since it's sending a negative offset to ProGet, and then ProGet is responding with a 400 error ("Missing or invalid "offset" parameter.)

Asset uploaf capability is just a few weeks old, and I'm not sure if we tested with such a large file. Anyway, we'll get it looked at and let you know once fixed; just a small tweak needed here I think:

https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L240

-- Dean

Hi @noam-linux-2022_8869 ,

Here is documentation on how to enable HTTPS in our products on Windows and Linux:

• https://docs.inedo.com/docs/installation/installing-on-iis/installation-windows-https-support
• https://docs.inedo.com/docs/installation/linux/https-support

-- Dean

Hi @steviecoaster,

The Native API isn't hacky, just harder to used. Here is the documentation on the Native API:
https://docs.inedo.com/docs/proget/reference-api/proget-api-http#native-api-endpoints

We don't have any articles/guidance on how to call the Native API beyond what's there.

The Users_* procs have not changed in years and are very safe to use. There are a few forums posts here and there with "hints" on work with the User_ procs, like this:
https://forums.inedo.com/topic/4198/reset-proget-admin-password-via-api/2

-- Dean