administrators

Hi Dan,

In general, a ProGet feed will be slower than a "real" Debian repository. The reason is that Debian repositories are just static file system like this:
http://ftp.us.debian.org/debian/dists/bookworm/

There is obviously a lot more overhead with each ProGet request, since index files are dynamically generated, involve connectors, need to be permission-checked, etc.

In addition, ProGet indexes the Debian indexes on-demand, which means downloading all of the Contents-*.gz files and indexing those. Like in here: http://ftp.us.debian.org/debian/dists/bookworm/main/

While these files are cached, they do need to be updated when the remote repository updates.

And note that each web node maintains its own local index cache, so you will see these long-running requests multiple times. Some organizations will periodically "warm up" the indexes periodically by just hitting the InRelease endpoint.

Hope that helps,
Alana

Hi @sgardj_2482 ,

ProGet's Integrated Web Server already supports Windows Integrated Authentication (WIA). Actually it supports WIA better than better than IIS in that only the Web UI and supported feeds (or ones you configure) will do the WIA challenge.

Behind the scenes, the Integrated Web Server (IWS) uses Kestrel unless you're doing so-called "port sharing", which would be having two web applications sharing the same port. That's becoming less and less common, and isn't something Microsoft recommends anymore.

If you bind to a host name in IWS (i.e. port sharing), then the operating-system level HTTP.SYS component is used. That is much less flexible with WIA and every request must be authenticated. Which means it'll never work with Docker, npm, etc. So it's not recommended.

Thanks,
Alana

Hi @michal-roszak_0767,

Can you please post what the fix was?

Thanks,
Rich

Hi @michal-roszak_0767 ,

401/403 are not logged, so you won't see a server side event.

403 means authentication was successful but the permissions are not OK

My guess is that the wrong feed or credentials are being specified. Like maybe using an API key?

Thanks,
Alana

Hi @michal-roszak_0767,

I'm not sure, but maybe it's something simple like a typo. I don't see it though.

That 401 message will occur when credentials weren't sent.

Behind the scenes, pgutil uses that API and authenticates by adding the same header:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L37

Perhaps you can use a proxy like Fiddler or ProxyMan to see the difference in HTTP Traffic?

Thanks,
Alana

Hi Fritz,

We appreciate the feedback on this! ProGet 2025 will indeed have a separate dedicated mount for the database, but we didn't include this in the preview. As to the other issues, yes we do have a supervisor that attempts to start postgres and perform a clean shutdown on container stop... but there are some bugs we are working through, likely made worse by the ownership issues you discovered.

These concerns will absolutely be addressed before launch.

Again, thanks for trying it out and please let us know of any other issues you find or suggestions you may have!

-Greg

Hi @dimas,

I've looked into this and it appears that restricted and multiverse in noble-backports do not actually have any packages in their indexes. It's a quirk of how these connectors are implemented in ProGet that components with no packages indexed are omitted from the output index. Is this causing a problem for you? We can look into changing this behavior, but it likely won't be a trivial fix.

-Greg

Hi @bill-hertzing_2810,

It sounds like you want to enable API v3, which uses the `v3/index.json' URL suffix?

In that case, make sure to set the useApiV3 property is set. Also, I don't think you can set all those properties on create... you may have to create, and then update.

Also note that you cannot set the endpointUrl property, it's just readonly. That is generated based on the incoming reques, so if you're viewing it on localhost you'll see that. If you view it on myserver.corp you'll see that, etc.

Hope that helps,
Alana

Hi @parthu-reddy ,

This looks more related to Server Overload / Database than anything to me. Note how all the requests are coming in at exact same second. Can you throttle your load balancer a bit, so they don't all hit at the same time? Even a slight delay will help.

FYI - we are tracking a recent regression to SQL Server analysis engine (???) that is causing one particular query (NuGet_GetPackage) to go incredibly slow under extreme traffic. For some reason, it's using the wrong plan suddly. It's been happening to a few users after a recent upgrade/patch to SQL Server. We have a work-around but would like to test it in the field against a user.

Thanks,
Alana

Hi @marc-ledent_9164 ,

This is available in InedoCore-3.0.4, so if you go to Admin > Extensions, you should be bale to update.

thanks,
Alana