Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

@sneh-patel_0294 and as an FYI, if you haven't already, you can request a ProGet Trial key from My.Inedo.com, and then set it to ProGet Enterprise, which supports the Clustered installation

Hi @sneh-patel_0294 ,

A "chained connector" would be something like, "(Feed A) --> (Feed B) --> (Feed C)". We've seen some set-ups like "(Feed A) -> ((Feed B) + (Feed C --> Feed F)+ (Feed D --> Feed G))", and every now and then a "loop" (where Feed A eventually connects back to Feed A). Those are really bad for performance, especially with NuGet v2 which requires a query every every single connector.

As for a clustered installation, here's our set-up guide for that:
https://docs.inedo.com/docs/installation/high-availability-load-balancing/high-availability-load-balancing

But to answer your questions... a sstandard share drive and a common SQL Server is fine. The main thing is to spread the incoming network traffic across multiple web nodes.

Cheers,
Alana

Hi @sneh-patel_0294 ,

The underlying issue is that you ProGet server is getting overloaded, and you need to find a way to reduce peak traffic or switch to a load-balanced solution. Removing NuGet V2 APIS, chained connectors, etc. are a good step in reducing traffic.

Keep in mind that the clients (build servers, dev workstations) are sending 1000's of simultaneous requests to ProGet at one time. ProGet is not a static file server (unlike nuget.org), and each request must be authenticated and often proxied/forwarded to connectors. There is only one network card on the server, and this is what happens when it gets overloaded.

As for why it's causing errors now, this is a result of changes to the underlying platform (.NET Framework to .NET Core). The older platform did a better job of throttling traffic under extreme load and, for whatever reason, didn't timeout as much.

You can configure a throttle in ProGet by going to Admin > HTTP/S Settings > Web Server > "edit", and then set a value of 100 or so. You mentioned a value of "500", but I would just set it to 100.

Cheers,
Alana

Hi @enrico-proget_8830 ,

Using ngnix is probably a better solution anyway if you don't mind setting that...
but the setting is now under Admin > HTTP Settings > Web Server " Edit"

Thanks,
Alana

Hi @udi-moshe_0021 ,

I don't know... as I mentioned, when we follow our instructions to set up a Debian feed in ProGet with a connector to http://ftp.debian.org/debian/ (Buster) it seemed to work fine. Other users seem to have no issues with the steps there, which is why it's likely your network.

Beyond that I really don't know enough about your configuration or apt troubleshooting to help further. I can't try to reproduce your environment, but if you provide the exact error messages from apt, I can search for them.

However, for faster help, please just simply search the error messages you are receiving from apt that you are receiving and follow the advice of articles that come up on Google. or ask ChatGPT.

Since I know very little about apt, all I can really do here is read the error messages, search for them, and link you to an article to try.

Thanks,
Alana

Hi @udi-moshe_0021 ,

Sure, anything would help; I'm basically looking for a very specific error message that I can search. Once you share the specific console outputs, I will try to search what the error means and summarize the results and how you might be able to troubleshoot it further.

I don't think there are any issues with your ProGet configuration, as it clearly works in Ubuntu desktop for you. It's likely a configuration of apt that you need to make, so you may wish to search the exact apt error messages as well.

Thanks,
Alana

Hi @udi-moshe_0021 ,

Can you can provide the specific commands and error messages you are receiving? I.e. just coyp/paste the entire console session with the commands you're typing and the output.

cheers
Alana

Thanks for clarifying that @rpangrazio_2287 , we'll explore that route as well.

We opted against DinD because of resource management (build servers can be rather resource-intensive) and general instability (not everything seems to work the same).

FYI - in case you haven't seen it already, BuildMaster does support Image-based Services (Containerized Builds)

Cheers,
Alana

Hi @rpangrazio_2287 ,

Thanks for sharing that solution; the general approach we arrived at was setting up an SSL Agent to connect to the BuildMaster's Docker host (Installing & Integrating with Docker Engine).

The approach you took is interesting; are you essentially installing Docker within the container? I assume that uses the Docker engine of the host, not like "docker in docker"?

Thanks,
Alana

Hi @udi-moshe_0021,

First and foremost, I would use the latest version of ProGet 2024. That eliminates any question of bugs that may have been fixed.

Otherwise, I'm afraid that we don't have a lot of experience in troubleshooting debian client issues. What I can say is that, when I follow our instructions to set up a Debian feed in ProGet with a connector to http://ftp.debian.org/debian/ (Buster) it seemed to work fine.

You may need to query the endpoints directly and see what data PRoGet is generating vs archive.ubuntu.org.

Thanks,
Alana