Ah ha, thanks! I updated the docs to include CommonCachePath instructions.

Hi @msimkin_1572, Looking at the Azure DevOps documentation here, you should be able to generate a personal access token (PAT) and connect to it using a username as anything and a password as the PAT. In ProGet 5.2, only NuGet v2 API's are supported, so make sure to follow the instructions for connecting it to a NuGet v2 client. In ProGet 5.3 and later, we have added NuGet v3 support. Could you give that a try? Thanks, Rich

Hi @dilshaat_6115, Glad you got it working! Just some extra information for you. The component name is dependent on the component name of the package you updated. In my case, I uploaded a package to ProGet using the main component. So I had to use deb http://192.168.55.103:8624/ hms-ubuntu main. Here is an example of how my package looked in ProGet. [image: 1600268252615-3abb0b34-2ef9-41f3-a4cc-c4868272370a-image.png] Thanks, Rich

Hello; I'm not able to reproduce this on the latest ProGet, and I'm thinking the problem may have been the package file was on disk from the previous version. Here's what I did: Create a new Feed with a connector to NuGet NuGet Download package using the URL /nuget/nuuget-public/package/ProxyKit/2.3.3+build.0 File on disk is ProxyKit.2.3.3.nupkg Cheers, Alana

We've got this fixed. If you'd like to try it, it's available as proget.inedo.com/productimages/inedo/progetcore:5.3.12-ci.1

Hi @bvandehey_9055, The URL you are using looks correct. IF you click on the Download button and the package actually downloads, then that verifies that it successfully connected. If it was failing to connect to WhiteSource, you would see a page that looks like this: [image: 1600177920154-67e1fc0d-3ddf-40d9-bb7b-a417385cb628-image.png] If you want to verify that ProGet is communicating with WhiteSource, I would just put in a bad value for WhiteSource and attempt to download the package from the ProGet UI. If you get a similar error to above, that verifies the communication to WhiteSource. Are you using the Product Name or the Product Token in the Product field in the configuration? I would try to use the product token first. If all of that is setup, then it is most likely an issue with the rules set up within WhiteSource. Thanks, Rich

Thanks for the detailed writeup! We've just published v1.0.1 of pgscan that should fix the issues you've described. v1.0.1 will now actually write errors and other info to the console like it's supposed to. There is also now a --api-key argument to allow it to authenticate with ProGet. Downloads are here: https://github.com/Inedo/pgscan/releases

@atripp I will try the progetcore when I manage to have some time but I can confirm the issue I reported was solved in proget v5.3.10. Thank you.

@rhessinger The issue was solved with v5.3.10 release. Thank you.

Thanks for updating and letting us know the problem was related to a connection string!

@jyip_5228 FYI, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image as well. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10

hi @scroak_6473 , just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10 Getting LDAP/LDAPS to work on Linux was a whole different problem to solve; the three major libraries (DotNetCore, Mono, Novell) all had separate and strange bugs. We'll be blogging about this, but for now, it might be a step in the right direction for addressing the problems you're seeing, at the very least.

@atripp Good news Thank you

@rhessinger Good news thank you

Hi @viceice, Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline. Thanks, Rich

That's amazing! Thanks so much @rhessinger You guys rock!

@ludovic_2596 this sounds familiar, from an early version of 5.3, but I can't find a report for it. It seems to work fine in the latest version for me.. can you try the upgrade?

@scroak_6473 got it, thanks! Okay, I've requested to engineering about adding it to the upcoming ProGetCore container, and we'll update this with more details as we have i

hi @Adam1, I looked into this further, and this is by design, but it should really be clarified in the UI a little bit better (I updated the docs). A server can exist in multiple environments, but it's not recommended. Basically, when a server is in multiple environments, then there can be no single environment in context. This means that the variable function $EnvironmentName will return empty, and variables cannot be resolved against those environments. This is unlike a role (which is set when executing a configuration plan, or explicitly set with for role X). So, in this case, I recommend you to use multiple roles.