Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @gravufo ,

Did you get any errors during the upgrade process? Also, could you download inedosql and check for errors from the inedosql GitHub page?

Thanks,
Rich

Hi @scroak_6473,

So I finally figured it out. Our ProGet docker image actually runs mono to run ProGet. Apparently this is an issue with the new way we load extensions in mono. I have put a fix in the next version of ProGet (5.3.6), but if you would like to leverage it now, you will just need to change a config value. Just navigate to Administration -> Advanced Settings and locate the value Extensions.UseNewExtensionLoader and uncheck it and save. Then you will need to restart your docker image, i.e. sudo docker restart proget. Then the vulnerability source should start working, or at least show you any real issues you have.

Thanks,
Rich

Hi @scroak_6473.

I have been able to recreate the error and I can confirm that this is only an issue with running ProGet in docker. I'm currently working to fix this issue.

Thanks,
Rich

Hi @eduardbabayan_1578 ,

What version of ProGet are you running?

Thanks,
Rich

Hi @antony-booth_1029 ,

Looks like we had an issue in how the javascript resource is loading for this modal. I have fixed this and it will be released in the next version of BuildMaster 6.2.14 which is due out at the end of this week.

Thanks,
Rich

Hi @scroak_6473,

We are still working on the issue. It looks to be only an issue with the ProGet docker image, but I don't have a lead on why yet. If you have the ability to install this on windows, I can confirm it is working there. I know you are running a free trial of ProGet. If you need to extend the trial because of this issue, please contact us through https://inedo.com/contact.

Thanks,
Rich

Hi @scroak_6473 ,

I working on reproducing this locally, but I'm running into some issues with my local Docker installation. I'll reply once I run some local tests. The majority of my testing for Clair has been done using the windows IIS or integrated web service installs.

Thanks,
Rich

Hi @luminiscence_6236 ,

I'm glad to hear you figured out the issue. I'm going to add an internal ticket to add better error handling around docker connectors.

Thanks,
Rich

Hi @scroak_6473,

I was hoping recreating the source would fix it. Based on your error, it looks like the error happens before it even attempts to call Clair. If it made at least one call to Clair, your output would look similar to this:

Can you provide a screenshot of your extensions page? I would like to verify the extension versions. Also, could you screenshot your Manage Feed -> Detection & Blocking tab?

Thanks,
Rich

Hi @luminiscence_6236 ,

If you click on the Containers link at the top. Does it error when you click on a local tag? Also do you have any connectors on your docker registry?

Thanks,
Rich

Hi @scroak_6473 ,

Everything looks to be correct. Can you try removing your vulnerability source from your Docker feed, then delete the vulnerability source then re-add it again and reassociate it to your feed? The only thing I can assume from that error stack trace is it is failing to parse the Configuration for your vulnerability source.

Thanks,
Rich

Hi @scroak_6473 ,

Do you have any other vulnerability sources setup? Or just clair?

Thanks,
Rich

Hi @scroak_6473,

I think i see your issue. Can you please change your URL to http://proget.qa.xxxx.xxxx (or https:// if you are using SSL). The Base URL requires the http:// or https:// in the value. This might be causing your issue.

Thanks,
Rich

Hi @luminiscence_6236 ,

Do you see any other errors in the diagnostic center? Does the page load when you click the Containers link at the top of the page? If that is the one that is erroring, are you able to navigate to your registry by first going to the Feeds then clicking on your registry there?

Thanks,
Rich

Hi @scroak_6473,

Could you please verify what version of ProGet you are currently running? Is it 5.2.3 or 5.3.2? I also think that there is a bug with Clair in 5.3.2, would you be able to upgrade to 5.3.4 and test it again? You can find the 5.3.4 Docker image on our public ProGet: https://proget.inedo.com/containers/repositories/tags/overview?feedId=22&repositoryName=inedo%2Fproget&tag=5.3.4.

Can you also tell me which Clair image you have installed on your Docker host?

Also, you will need to make sure that the Clair image has access to ProGet. The flow of Clair is a bit weird. First ProGet will make a request to Clair to start the process. Clair will then make a request to ProGet (with a temporary auth key) to download each image layer to scan. Then ProGet will make one final call to Clair to download the found vulnerability data.

Once, you send me this information we can figure out where to go from there. I do have a way to manually test the calls to Clair leveraging a PowerShell script, but the information gathering to run it is a bit tedious.

Thanks,
Rich

Hi @luminiscence_6236 ,

Could you please provide the entire stack trace for the error? You should be able to retrieve it from the Diagnostics Center on the Administration page.

Thanks,
Rich

Hi @patchlings,

No problem! We are still investigating some workarounds, but we don't have anything specific yet.

We don't currently have a timeline for the .NET 5 switch. We have attempted a .NET Core transition in early 2019, but we ran into too many instability issues and scrapped it. We will wait for .NET 5 to be officially released (Microsoft says November 2020) before we attempt the switch, but it will all come down to the stability of ProGet on .NET 5.

Thanks,
Rich

Hi @patchlings ,

That is the heart of the Mono bug that I referenced. Currently Mono has a memory leak around HTTP requests which will cause our connectors to hang when the memory usage is too high. They have reduced the leaking substantially starting in Mono 5.16, but there is still a leak. If you search around on this error, you will find similar questions with almost identical errors still in 2020. Unfortunately, we are in the hands of the Mono team until we switch off Mono and migrate to .NET 5.

Thanks,
Rich