Hi @Crimrose,

When you first start the ProGet container, our code will run a database schema update to make any missing changes. My guess is that in your Kubernetes cluster, you have a mix of 5.3.15 pods and 5.3.16 pods all trying to access the database at the same time, causing Kubernetes to stop and restart pods. I would stop all your ProGet pods and try starting just a 5.3.16 pod and see if that works.

If that does not work, you can manually update the database schema. To do this, you would need to download the manual install files from my.inedo.com and download inedosql from GitHub. Inedosql is a cross platform application, so you can run it directly on Linux using the .NET 5 CLI or downloading the specific Linux version or from a Windows machine. Then you can follow just the Run inedosql to update the database section of the manual install guide. The SQLScripts folder exists in the Manual Install files.

Hope this helps!

Thanks,
Rich

Hi @churst,

Sorry for the delay in my response, glad you were able to find it!

As for your account, if you can submit a ticket on my.inedo.com and include your license key, I can associate your email address with your my.inedo.com account.

Thanks,
Rich

Hi @arozanski_1087,

I think I may have finally tracked this issue down. Would you be able to manually install the Inedo Core 1.7.11-CI.1 extension and see if that fixes your issue? There is one spot that does not properly apply the user and group filter upon saving and I'm thinking I may have fixed it.

Thanks,
Rich

Hi @Crimrose and @hyt5036_7430,

I just made some tweaks to our 1.9 packages and released the ProGet 5.3.16 compatible extensions as -RC versions. If you change your Extensions.UpdateFeedUrl to https://proget.inedo.com/feeds/PrereleaseExtensions you can install the latest RC version of these extensions and they will work with the proget or progetmono image. Since the proget and progetmono images include the exact same features, you can switch between them without loss of data.

Thanks,
Rich

Hi @churst,

It looks like this may be related to KB#1758. Could you please take a look at this first and let me know if this fixes your issue?

Thanks,
Rich

Hi @anrey-ne_0903,

Is this a new Docker feed you have created? IF so, this may be related to this other post https://forums.inedo.com/topic/3081/a-500-error-occurred-in-d-could-not-find-a-part-of-the-path-var-proget-packages-docker-f1. We currently have a bug that throws an error when pushing to the first feed created in each package type when using the proget Docker image. This will be fixed in ProGet 5.3.17, but that forums post has a manual work around to fix that issue.

If this is not the issue, then my next question would be is this a recent upgrade of the proget docker image?

Thanks,
Rich

Hi @Crimrose,

Chocolatey feeds are a form of NuGet feed that uses the standard NuGet API, but we optimize ProGet's UI to present it in a slightly different fashion. You can see the differences listed in our Chocolatey documentation. This means that you can push chocolatey packages via the NuGet CLI push command. Since you are running this on Linux, you will need to use the .NET Core or .NET 5 based CLI to perform this push.

Alternatively, you can upload this manually in the ProGet UI.

Thanks,
Rich

Hi @Crimrose and @hyt5036_7430,

The difference in the proget.inedo.com/productimages/inedo/proget and the proget.inedo.com/productimages/inedo/progetmono is that the proget image is built using .Net Core 3.1 (it will be .NET 5 in ProGet 5.3.17) and progetmono uses the Mono framework with our code compiled to .NET Framework 4.5.2 as @Crimrose has mentioned above. We actually have a blog post on this.

The issue you are running into is that the Kubernetes extension did not add support for .Net Core until version 1.9.0-CI.5 of the Kubernetes extension. Do not use 1.9.0-CI.6 because that includes on .NET 5 in preparation of ProGet 5.3.17. To install 1.9.0-CI.5, you will need to follow the Extension Manual Install Guide and you will need to make sure to copy the extension to the Extensions.ExtensionsPath inside the container using docker exec -it <image name> sh using the shell or copy it to the folder the container is mapped to on the Docker host.

The Whitesource and Sonatype extensions have this same issue currently.

I hope this helps! Please let me know if you have any questions.

Thanks,
Rich

Hi @harald-s-hanssen_2554 and @viceice,

I was able to finally track down this issue. It seems to only affect ProGet running on Linux (Docker) when attempting to look for existing packages prior to adding a package or image. I have created a ticket, PG-1852, to track this fix. It will be released this Friday, November 20, 2020, in ProGet 5.3.17. Thanks for all the help in troubleshooting this!

Thanks,
Rich

Hi @harald-s-hanssen_2554,

I have found that sometimes I will run into permission errors when created the folder on the host side when using WSL or WSL2. Sometimes if I create the folder on the host side, I end up having to manually chmod the folder inside the container. I have found different Linux OSes and Versions will vary based on this as well.

Thanks,
Rich

Hi @arozanski_1087,

I apologize for all the back and forth I'm struggling a bit to recreate this issue. I have even tried to just add a computer by searching it by name and I still cannot recreate this. Would you be able to perform a test search in the Advanced Settings of your Active Directory provider? Does that also return the computer accounts?

Thanks,
Rich

Hi @arozanski_1087,

You are correct. G is for group or gMSA. The only thing that makes sense is that your AD has a group or a gMSA for your user account with the same name and it is return the group first. You could manually change the DB record to remove the $ and that should then work. But that is an annoying manual step. Can you please verify that the user you are testing with does not have a Group of gMSA named as AROZANSKI$ in AD?

Thanks,
Rich

Hi @harald-s-hanssen_2554,

The current workaround is to manually create the feed folder. For example /var/proget/packages/.nugetv2/F1. This issue only happens when it is the first feed of that package type. We are still looking into the cause of the issue. It is only a problem with the docker image.

Thanks,
Rich

Hi @arozanski_1087,

Thanks for sending that over. I took a look into the code and checked some things and I don't see anything that would look up the computer name. Can you look at the [Privileges] table in the ProGet database? Do the usernames include the $ in there also? Also, do you have any sort of reverse-proxy sitting in front of ProGet?

Thanks,
Rich

Hi @nicolas-morissette_6285,

No problem. I'll let you know if anything is delayed in that release!

Thanks,
Rich

Hi @vaclav-nadrasky_0945,

It looks like there is a bug in the visual editor that is stripping that off. I have created a ticket, OT-382, to track the fix. As for if this is the best practice, I'm going to pass you over to @atripp for that. She is our Otter Script expert.

Thanks,
Rich

Hoi @arozanski_1087,

Can you please tell us what version of ProGet you are running and also, can you please tell us what version of the InedoCore extension is installed on your ProGet instance?

Thanks,
Rich

Hi @nicolas-morissette_6285,

I apologize for the back and forth with them. I just created a ticket, PG-1851, to add a special case for handling this kind of package from Azure DevOps Registry. It is set to release in ProGet 5.3.17 which is due out November 20, 2020.

Thanks,
Rich

Hi @arozanski_1087,

This is really peculiar because we have an explicit filter on all of our LDAP queries to be a user, msDS-GroupManagedServiceAccount, or group. Does each user account have their own group managed service account?

Thanks,
Rich

Hi @nkerifacclaud_6931,

Could you try disabling BitDefender temporarily to rule that out? Also, this could simply be related to the fact that Windows 7 is no longer in support and their may be a security patch to the .Net Framework which is causing the error. Since Windows 7 no longer gets updates, it would not get any new patches for the .Net Framework or the FTP server. We leverage the classes built-in to the .Net Framework for FTP connections.

Thanks,
Rich