Hi @maciej-luszczynski_5271,

Thanks for bringing this to our attention. I have corrected the example as suggested.

Thanks,
Dan

Hi @parthu-reddy,

Can you tell me what version of ProGet you are using? It looks like this issue was fixed recently, PG-2688, in ProGet 2024.5. I believe if you upgrade to 2024.5, that should fix your issue.

Thanks,
Dan

Hi @forbzie22_0253,

ProGet will connect to https://my.inedo.com/services/v1/activate for activation.

Thanks,
Dan

Hi @lucas-almeida_8120,

This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon.

Thanks,
Dan

Hi @forbzie22_0253,

You can do this using our Bulk Import via a drop path feature. We have a helpful How To Bulk Import Packages Into A Feed From Disk article in our documentation.

Please let us know if you have any other questions!

Thanks,
Dan

Hi @itops_6398,

I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look.

With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later.

Thanks,
Dan

Hi @itops_6398,

Are you still using the defaults for the LDAP Overrides? Unfortunately, AD LDAP queries give very little log output. Right now you are seeing the amount of logging we receive from the AD server. The best way to see more details is to log into your Active Directory server and look in the Windows Event Log to see the errors found in the connection.

On a separate note, when it comes to configuring an Azure Enterprise Application SAML provider to link to your active directory. I have found that changing the nameidentifier claim to use a transformation of ExtractMailPrefix() on the attribute user.userprincipalname will extract the username and typically link well to Active Directory usernames.

Thanks,
Dan

Hi @carl-westman_8110,

Thanks for clarifying that for me. So that changes things a bit. When it comes to the LDAPS issue, the original suggestion for adding the certificate will not work. The LDAPS certificate needs to be added directly to the trusted certificates in the Container, not the app service. We don't have much advice on this as of yet, but let me talk internally on this and see what my colleagues say.

As for the actual SSL certificate in ProGet, you will need to follow the Configuring HTTPS without a Reverse Proxy guide in the Linux HTTPS Support. That will show you how to configure the SSL certificate within the container itself and not the app service. We also have more guidance on converting certificate files to different formats at the bottom of our HTTPS support on Windows documentation.

Thanks,
Dan

Hi @carl-westman_8110,

I didn't realize how you were running ProGet. Are you currently running the ProGet Docker Image using an Azure App Service?

Thanks,
Dan

Hi @carl-westman_8110,

The rejected certificate was from your Active Directory provider, not the Azure Web App itself. This is normally due to Active Directory generating its own certificates. I'm not exactly sure how to trust them in Azure, but it looks like you can register CA certificates on an Azure Web App using Microsoft's documentation: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code

As an alternative, you can edit your User Directory in ProGet and on the Connection tab, you can change to "Use LDAPS and bypass the certificate errors". That will allow ProGet to bypass the certificate validation process.

Thanks,
Dan

Hi @k_2363,

We found an issue in our Native API related to our .NET 6 upgrade that was preventing certain values from converting properly. That has been resolved and will be released on Friday in ProGet 2023.18.

Thanks,
Dan

Hi @Jon,

Thanks for sending this over to us. It looks like there is an issue with the configuration API and it's causing it to always return a 404 error. I have added a ticket, OT-497, to fix this issue, and it should be released on Friday this week in Otter 2022.13.

Thanks,
Dan

Hi @caterina,

This has been an issue we see from time to time and it is related to NuGet's request caching. One thing to try first is to make sure you do not have IIS request caching enabled. To do this:

1. Navigate to your ProGet site in IIS
2. Double click on "Output caching"
3. On the right, click "Edit Feature Settings..."
4. Uncheck both "Enable cache" and "Enable Kernel Cache"
5. Click OK

The next thing to try is to clear NuGet's HTTP cache. You can do that by running the following NuGet command:

nuget locals http-cache -clear

Typically the combination of these will resolve the issue. Can you please try these next time you have the issue?

Thanks,
Dan

Hi @guyk,

After some research, it looks like scope-mapped tokens require a custom authentication procedure. It looks like if you use an Admin User, it will then use the standard Docker authentication procedure. Would you be able to try that and see if it works with ProGet?

Thanks,
Dan

Hi @guyk,

Thanks for confirming that for me. On that same email you sent me, can you please send me a repository name that is available to that token?

Thanks,
Dan

Hi @guyk,

The error I'm getting is a 401 unauthorized exception. Can you confirm that the token you sent me is a token password? Following Micorosft's documentation https://learn.microsoft.com/en-us/azure/container-registry/container-registry-repository-scoped-permissions, you need to create a token password for the token. Then the docker login username is the name of the token and the password is the token password.

Thanks,
Dan

Hi @guyk,

Thanks, I have it and I'm testing now. I'll reach out shortly and let you know what I find.

Thanks,
Dan

Hi @chrisblankde,

Can you please tell me what metadata you are trying to update? If it is just the version, you can use the Repackage API. If it is something other than the version, in ProGet 2023, we added the ability to edit the upack metadata directly in ProGet. You can do that by navigating to the package version in your universal package feed and then click "Edit Package" in the upper right corner.

If neither of those options works for you, then what you suggested (download/extract/edit/repack/upload) would be the way to handle this.

Thanks,
Dan

Hi @guyk,

You are correct, the proxy settings are global, not at a feed level.

Would you be able to provide us with a URL and a scope-mapped token we can debug with? You can email these to support@inedo.com with the subject of [QA-1148]. If so, we can easily debug this and see what is going on. Once we complete the fix, we can let you know and you can revoke access from us.

Thanks,
Dan

Hi @guyk,

Glad to hear that fixed your issue with the Docker hub connector. When it comes to "Attempt to search", this options does work on Microsoft's container registry, GitLab's container registry, and Google Cloud (gcr/k8s). It only actually affects searching for images though. When it is unchecked, it just requires exact image name searches.

The manifest error is definitely annoying, unfortunately, Docker itself filters out all returned errors and just displays that "not found: manifest unknown: manifest unknown" message. Along with that, when it comes to querying other Docker registries, they throw a lot of errors instead of just returning an empty dataset when an image is not found. That makes it hard to produce meaningful entries into our logs.

As for the Azure container registry. Are you using a public or private registry? One thing we have noticed is the Azure container registry can have multiple package types mixed into it. When you mix package types, ProGet has a hard time using that registry. If you can provide us with an example, we can quickly debug it and let you know what is wrong with the connection.

Thanks,
Dan