Posts made by rhessinger

Hi @Stephen-Schaff,

@atripp is correct. There was an issue previously that would ignore the specified type of a principal and favor a group, but that has been fixed for a bit now.

One thing that can still happen is accidentally selecting a group versus a user when adding a permission or restriction to a task. Currently, we just present the list of users and groups in the order they are returned from the domain. If a user and a group are using the same name, it may be difficult to decipher which one you are selecting.

Can you please tell us what version of the InedoCore extensions is installed? Also, can you please verify that you are using the Active Directory (LDAP) user directory?

Thanks,
Rich

Hi @scroak_6473,

ProGet automatically handles creating a temporary API key for use with clair. When ProGet integrates with clair, it generates a temporary key to use to check layers for vulnerabilities then deletes it when the process completes. So there is nothing you have to do to authenticate clair to ProGet. If the key is still there after running the scan, my guess is an error occurred while trying to clean it up.

As for the other error you are seeing, are you able to pull an image with that layer attached to it? I can probably create a SQL query for you to link a layer to the image if needed.

Thanks,
Rich

Hi Joshua,

It looks like the exception is missing the actual error message. I have added some code to improve that error. Could you install Get 1.10.2-CI.1 and see if we can get a better error message relating to what issue you are seeing?

You can manually install this extension by:

1. Download the new version
2. Rename it to Git.upack
3. Copy it to your Otter Extensions folder (You can find the location by checking the Extensions.ExtensionsPath in Administration -> Advanced Settings)
4. Restart the Otter web application (restart the application pool in IIS or restart the integrated web server service) and the Otter Service

Thanks,
Rich

Hi @Joshua_1353,

That all sounds correct. Can you please send a screenshot of your root folders in your Git branch? I'm thinking that maybe there is a folder conflict.

Thanks,
Rich

Hi @Joshua_1353,

I'm having a bit of trouble recreating this issue. I have a few questions for you to help get me started.

• What provider are you hosting your Git repository through?
• Are you using Secure Credentials to connect to this? Or are you using the username and password fields on the Git raft?
• Do you see any other errors in the diagnostics center?
• Did your Git repository have anything in it already or was it a blank repository?

This should help me try to recreate the error.

Thanks,
Rich

Hi @Jeff-West_5638,

Do you see the error in your Diagnostics Center under Administration? Could you please post that error stack trace here?

Thanks,
Rich

Hi Jeff,

The anonymous user has been moved to a built-in account in ProGet now, so it will not show up under the Users tab now. But, you should still be able to add Anonymous to tasks on the Tasks tab. I would recommend removing the anonymous permission you had set up on any task previously and re-add them. When you start to type Anonymous, you should see it pop up as an available user to select. Can you try that?

Thanks,
Rich

Hi Jeff,

Could you please provide a screenshot of what you are referring to with the Anonymous user no longer shows up under Users? Anonymous should be a built-in account and you should be able to add it to any task. Although being a free user, you do not have the ability to have feed level support. In that case, if you set anonymous globally, then all feeds will have anonymous access.

What version were you using in your lab that worked previously?

Thanks,
Rich

Hi @sonismile10_4270,

BuildMaster only supports Visual Studio Test (formerly MSTest), nUnit, and jUnit out of the box. I'm not very familiar with SOAP UI, but I think your best bet would be to use Soap UI's jUnit integration and then run the jUnit tests to track them in BuildMaster. If not, you would probably need to build a custom BuildMaster extension to support this. Please see our unit test documentation for more information.

Thanks,
Rich

Hi @markus4830,

I definitely recommend changing your NuGet.org connector to the V3 endpoint simply for the fact that NuGet.org is deprecating portions of their V2 API. The V3 endpoint on NuGet.org is also much faster than the V2 endpoint and the V2 endpoint on NuGet.org currently throttles package connections.

On the same note, I recommend the same thing for connecting to ProGet as well. Your error message above shows that your build server is connecting to the V2 endpoint for your ProGet NuGet feed. The V3 API is much more efficient in both database connections and overall SQL execution.

If your NuGet feed in ProGet is still showing a V2 endpoint address, you will need to go to your feed's Manage Feed page by clicking the Manage Feed button and change the supported API to include JSON-LD (v3) . Your feed will still support V2 connections, but you should migrate all your builds to access it over the V3 endpoint.

I feel the combination of those two pieces should help bring down the number of concurrent connections to SQL server.

Thanks,
Rich

Hi @markus4830,

Thanks for sending that over. The Close Database Connections Early value was removed because we enabled that for everyone which helped this issue initially. Can you remind me, are you using the Docker version of ProGet or do you have it installed on Windows?

For the (big) build, is it multiple builds triggering at the same time, or is it just a single massive build with a lot of packages associated with it? I'm also noticing that you are using the NuGet v2 endpoint. Is it possible to switch your build to use the NuGet v3 version of your endpoint?

Thanks,
Rich

Hi @markus4830,

I think the first thing to check is if you are actually running out of connections or not. Can you please run the following SQL next time you see ProGet experiencing this problem? Can you also run it under normal load when everything is running normally?

SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NumberOfConnections --, loginame as LoginName
FROM sys.sysprocesses
WHERE dbid > 0 AND DB_NAME(dbid) = 'ProGet'
GROUP BY dbid --, loginame

I commented out the loginName, but you can uncomment that if you want to verify the connections are coming from ProGet versus other users connected to SQL server.

What is the number of connections you are seeing when you run that?

Thanks,
Rich

Hi @jn_7742,

This fix will be released in ProGet 5.3.21 which is due out January 22, 2021. When you upgrade and test this, can you please reply back and let us know if this worked for you?

Thanks,
Rich

Hi @viceice,

I took a look at this and it looks like the issue is that the GitHub repository is not returning the published date. I have put a fix in, PG-1871, which will release in ProGet 5.3.21.

Thanks,
Rich

Hi @viceice,

This typically happens because the NuGet package metadata has an invalid format. Does this error happen for all packages or just one?

We run into similar issues when connecting to Azure DevOps registries because they do not always follow NuGet's API spec. Are you able to send over the package registration metadata for a package with the issue? The index.json may also help with this. If you do not feel comfortable submitting this via the forums, you can email it to support@inedo.com. Just please let me know when you send it so I know to look in that mailbox for it.

Thanks,
Rich

Hi @Crimrose,

Thanks for posting a follow-up solution for this! I'll keep this in our notes incase this comes up again in the future!

Thanks,
Rich

Hi @nicolas-morissette_6285,

Thanks for sending that over. This confirmed my thoughts. It looks like they only include the SearchQueryService/3.0.0-beta, not the SearchQueryService, which is why the v3 connector does not work. I'm going to talk this over with the internal team and see how we want to approach it. ProGet currently does not implement the 3.0.0-beta API endpoint because it is still likely to change, which increases the likelihood of it breaking in ProGet.

I'll discuss this internally and figure out the best way to proceed.

Thanks for sending this over!

Thanks,
Rich

Hi @nicolas-morissette_6285,

Would you be able to post the JSON from your v3 API? It looks like AzureDevOps is missing the URL for the SearchQueryService. If you navigate to https://proget.inedo.com/nuget/NuGetLibraries/v3/index.json You'll see the very first service API URL is for SearchQueryService. I'm wondering if Azure DevOps is implementing a weird version of it, if at all. If you don't feel comfortable posting it here, you can email it to support@inedo.com, let me know, and I can pull it from there.

I'm sorry for the confusion. Since you originally posted the values from the registrations-gz, I made the assumption you were using the v3 API. The fix I added was for the V3 API JSON. I'll have to see what I can do with the V2 version because it parsed a little differently than the v3 version.

Thanks,
Rich

Hi @nicolas-morissette_6285,

Thanks for the updated information. This is most likely not a configuration issue with the connector. The only thing that could be affected by the connector setup is if you are using a v2 API NuGet feed instead of a v3 on from Azure DevOps, but I believe you already confirmed above that it was the v3 API from Azure DevOps.

Let me look into this a bit further. It looks that I must have changed the code that the UI uses, but not what the nuget.exe uses. I'm not sure how that is possible, but let me take another look.

Thanks,
Rich

Hi Simon,

Unfortunately hitting the URL in the browser will not show the underlying error because the Docker client is a relatively chatty client. It will hit a number of different API endpoints to perform the login. You would need to use a tool like Wireshark or Fiddler to proxy requests to the server to see which URL has the problem.

Are you using nginx as a reverse-proxy to ProGet? Is it possible to bypass it to try to use docker login directly on the ProGet server to rule out any header manipulation issues?

Thanks,
Rich

Hi @nicolas-morissette_6285,

You should not need to do anything to the connector. Can you try and open the package in the ProGet UI? Does that package/version load? Also, can you download it within the ProGet UI?

Thanks,
Rich

Hi @scroak_6473,

We have fixed the issue with creating new AD User Directories and vulnerability sources in .NET 5. It is set to release in ProGet 5.3.19 which is due out December 18, 2020.

Thanks,
Rich

Hi @nicolas-morissette_6285,

No problem. Thanks for moving the comment over here! I will delete it from the other topic.

I can confirm the fix I made was released and is currently in the code. Do you see any errors in the Diagnostic Center in ProGet?

Thanks,
Rich

Hi @scroak_6473,

For the add new User Directory and add new Vulnerability source, we have identified the issue and we are currently investigating the cause of it. It has to do with changes in .NET 5 for parsing types from strings. I will update this when we have a bit more information on it.

As for the AD stuff. That is definitely the issue, the LDAPS certificate is not being viewed as a valid certificate. I think we will need to investigate this further on how to bypass certificate validation. I would prefer you to open a new thread to discuss this issue with LDAPS in Docker. To answer your question, our code for connecting to Active Directory exists on GitHub in the inedox-InedoCore extension. It also includes a windows application for testing AD connections, including LDAPS. The library we are using on .NET 5 is Novell.Directory.Ldap.NETStandard. For the .NET 4.5.2 target, we use the typical System.DirectoryServices. We always encourage Pull Requests with fixes for this also!

Hope this helps!

Thanks,
Rich

Glad to hear the workaround works. We are still currently working on the issue to fix the Add New functionality in .NET 5. To the best of my knowledge, LDAPS is currently working and we have users that are using it currently. Can you please tell me what issue you are having with LDAPS?

Thanks,
Rich

Hi @scroak_6473,

I was able to recreate your issue. I think this may be an issue with the .NET 5 version of ProGet and creating a new Active Directory (LDAP) user directory. If one is already created, I do not have any issues editing it.

As a workaround, I would suggest changing over to the progetmono image and create the new user directory, then change back to the proget image to configure it.

I will reply back when I have an update on a proper fix for this.

Thanks,
Rich

Hi @shijiyong_6709,

I just wanted to confirm that you are using docker login -u admin https://proget.company.com and not docker login -u admin. Is that correct?

The first thing we need to figure out is if the problem exists in your ProGet configuration or in your nginx configuration. Can you start with temporarily allowing anonymous access to your Docker registry in ProGet, does Docker pull work then?

Thanks,
Rich

Hi @arozanski_1087,

That's great! I'm sorry it took this long to get this working. Thanks for working with me to figure this out! I'm going to make a change to the documentation right now to include the requirement of naming the extension file. I will also get a full release of this extension out today so it will lock in that version with the ProGet release tomorrow.

Thanks,
Rich

Hi @arozanski_1087,

Glad a reboot of the OS fixed it. Can you try renaming the downloaded version to InedoCore.upack. I noticed ProGet gave me some issues installing the extension manually when leaving the version number on there.

Thanks,
Rich

Hi @arozanski_1087,

You can also try flipping back to the Built-in User Directory by reseting the base admin account. You won't lose any AD users you have setup, it just simply switches ProGet to use the Built-in directory and resets the Admin password back to Admin.

Thanks,
Rich

Hi @arozanski_1087,

Did you restart IIS or the Integrated Web Server after copying the upack file back? Also, did your upack file have a version number in the name? Or was it just InedoCore.upack? I doubt this, but can you navigate directly to /administration/extensions? Could you also take a screen shot of the files in the Extensions folder?

Thanks,
Rich

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