Hi @tcochran_0018,
This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.
Thanks,
Dan
Hi @tcochran_0018,
This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.
Thanks,
Dan
Hi @kichikawa_2913,
Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week!
Thanks,
Dan
Hi @kichikawa_2913,
Thank you for following up with us and letting us know it is working now. Also, thanks for clarifying the Docker network setup for me. This is related to how we changed the service messenger in ProGet v6.
I took a deeper look into the code and when setting the endpoint via the "change" link, it will override the configuration's shared value. Once that has been set, it will use the configuration associated with that node instead.
Based on your screenshot, it looks like it was using tcp://*:6001
as the shared configuration (even though you said not to), but failed to connect because it was trying to balance amongst the other nodes. If you were using a Docker network, this most likely would have worked because the individual nodes could have listened on 6001 as well.
After reviewing these changes, you would have to change the service messenger address on each service node in order to apply the configuration you are looking to use (which is what you did above).
Hopefully this gave a bit more context to this change.
Thanks,
Dan
Hi @kichikawa_2913,
Thanks for following up and letting us know that you found the solution!
Thanks,
Dan
Hi @claudio_9251,
I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that.
Thanks,
Dan
I see the email, thanks for sending this over! Please give me some time to review and I'll let you know what I find.
@pieter-mertens_0372, your issue may be related. Although both products are owned by Microsoft, they still differ in their implementation. Does this happen for all packages or just a specific subset?
Thanks,
Dan
Hi @arozanski_1087,
We talked it over in our team meeting yesterday and decided to change ProGet to always create a new release when one doesn't exist and add new dependencies when the release does exist. This way that parameter will not be needed. So you will just need to upgrade ProGet to v2022.23 when it is released later today.
As for the Yarn support and scanning multiple package types in the initial scan, we plan to work on that early next week, so we should have something for you soon.
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 @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
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
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
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
I didn't realize how you were running ProGet. Are you currently running the ProGet Docker Image using an Azure App Service?
Thanks,
Dan
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:
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