Hi @jerome-jolidon_1453,

Thanks for all of the information, this is very helpful. I will make sure we can get these addressed. Can you tell me what your filtering level is on your connector?

Thanks,
Rich

Hi @jerome-jolidon_1453,

Can you share what npm connector filters you are using? I can verify that @microsoft/* works on NPM filters. I tested using a block of * and allow @microsoft/*. That allowed only @microsoft packages to be downloaded. I will add that if an npm package has already been cached, the download is still allowed. These filters only work if the package is remote and has not been cached.

I will note that I have found a UI bug that will not show the download button blocked for NPM packages, but if you attempt to download the package you will get a 404 error.

Thanks,
Rich

Hi @Stephen-Schaff,

This should not affect anything. If you are using a single domain (did not use multiple domains in the domains to search input), the domain does not need to be appended to the username. So your existing command-line tools should not be affected.

If you also need to be able to prepend your domain (ex: domain\user), I can send you some documentation on how to configure it. The previous login formats of username and username@domain.local will still work, but it adds the ability for domain\username. A small disclaimer though, the domain\user functionality is still in testing.

Thanks,
Rich

Hi @brett-polivka,

It looks like there was a mix-up in one of our branches. I just pushed an updated image with the ParallelEnumerable removed. Can you please give the proget.inedo.com/productimages/inedo/proget:5.3.23-ci.5 image a try?

Thanks,
Rich

Hi @Stephen-Schaff,

Thanks for confirming the extension version for me.

As for the user directory question, if you navigate to Administration -> Change User Directory Did you configure and select Active Directory (LDAP)? We previously had a configuration for a user directory called LDAP or Single Domain Active Directory (now called LDAP or Single Domain Active Directory (Legacy)). I wanted to verify you are not using an old LDAP implementation.

Thanks,
Rich

Hi @Stephen-Schaff,

The Publish Packages task should actually trump View & Download. When I test your steps, it shows me that the user has no effective permissions on the Base feed. To accomplish what you would like to do you should do the following:

1. Create a new Custom Task (in the Customize Tasks). Call it Publish Only and give it the Add Package attribute.
2. Add the user to publish on all feeds
3. Restrict Publish only on the Base feed

That should give you the publish restriction you are looking for. Can you please give that a try and let me know if that works?

Thanks,
Rich

Hi @saurulau,

It looks like your colleague submitted a support ticket with us. Is it OK to continue with that ticket, or would you like me also to work with you through this forum's post?

Thanks,
Rich

Hi @Stephen-Schaff,

I'm having a bit of trouble recreating this issue. Can you answer a few questions for me?

• What version of ProGet are you running?
• Is this installed on Windows or running in Docker?
• Can you please attach a screenshot of the attribute of the Publish Packages task?
  • You can find this by navigating to _Administration -> Users & Tasks -> Tasks -> Customize Tasksand clike on thePublish Packages` task.

Thanks,
Rich

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