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

Hi @kc_2466 ,

Understood, that was the same reason given before.

Our products' AD/LDAP integration works different than JIRA/TeamCity (live lookup vs sync) so it's just not that simple.

We're not willing to add complexity to work-around "dumb" organizational policies -- what you described is the whole point of AD/LDAP (centrally administered access).

It's possible to delegate group administration in AD, but if they don't want to do that... I guess they are okay with you just creating less-secure built-in users until they get around to completing their tickets ;)

Thanks,
Alana

Hi @thomas_3037 ,

ProGet does not support these, as they are not "real" Debian repositories:

These are used only by the Debian installer and are not installed on a Debian system under normal circumstances.

Unlikely we would add support for them, given the highly-limited use case.

Thanks,
Alana

@tames_0545 I just thought of something, perhaps try a different versions of ProGet, instead of latest -- like maybe 25.0.3, 25.0.4, etc, perhaps into ProGet 2024 as well

Hi @tames_0545 ,

Sorry, no idea -- there is definitely something wrong with your environment but aside from the advice I gave earlier, I don't have any other troubleshooting steps. You may want to try a different environment / Docker host.

As I mentioned, it could something wrong with your database mount (/opt/proget/database) -- maybe that is getting deleted? Or it could be your security configuration that is interfering with the running container. We have seen some hyper-aggressive security tools that make things so secure nothing runs.

Thanks,
Alana

Hi @tames_0545 ,

A connection string should not be specified.

I haven't seen this behavior before; the container runs postgres on start to listen to port 5728 and I can't imagine how that would fail without an error message.

Perhaps there's some kind of issue with /opt/proget/database and that's causing the postgres process to crash; I would start here.

The only other thing I can imagine is some kind of security configuration that is interfering with the running container.

I would keep it as simple as possible. Once you get it working, you can try adding in the encryption key. Unless you absolutely need to use a Docker secret (those are complex and don't really do anything), just specify the encryption key with an environment variable

-e PROGET_ENCRYPTION_KEY='37D27A670394F7D82CE57F1F07D69747'

Cheers,
Alana

Hi @kc_2466,

Thanks for the suggestion; we've had this request in the past but don't believe it's a good fit.

It ought to be trivial to add a group to the AD/LDAP server, so it doesn't make sense to add a "quasi-group" feature on the ProGet end. That would increase complexity and could introduce unbehavior that is challenging to support and troubleshoot.

We haven't seen other products doing something like this, likely for these reasons.

Cheers,
Alana

Hi @kc_2466 , nice catch! We'll get it fixed via PG-3060 in the next maintenance release!

Hi @m-lee_3921 ,

Thanks for the heads-up; we'll get this fixed via PG-3059 in the next maintenance release (scheduled for later today).

And you're right -- its basically the same issue. SQL Server silently truncates string values whereas PostgreSQL does not, hence these errors.

We decided to not auto-truncate, since it's better to know about these cases than not. In this case, it's a IPv6 address that was longer than the 20-character limit. We plan to refactor API key logging at some point, so we'll just continue to truncate v6 IPs.

Thanks,
Alana

Hi @carsten_1879 ,

Can you try out buildmaster:25.0.0-ci.23 container image?

I would do a new/fresh installation - new applications created in it should use the new Git library. It seems to work, but would like to see if it works for you as well.

Thanks,
Alana

@it_6176 thanks for sharing!

You're right, we did not consider this usecase when designing Debian connectors. Our "default mode" in ProGet is "dynamic indexes", but the quirkiness of the Debian repository "API" and obscene size of operating-system libraries make that impractical when there is a lot of feed activity (i.e. packages being added to the feed via caching).

We are going to redesign this at some point, and allow for some kind of "periodic indexing" for some connectors. That would be run as a job, as opposed to triggered by a user's request.

As for the database.... we've had one other user report that those SQLLite databases "blew up" as well, and our conclusion is that "something" crashed at the wrong time. Probably, due to the resource overusage? It has something to do with the WAL Files, but we're not totally sure.

I think we just need some kind of regular clean-up for these "huge" connectors so the database doesn't get so huge.