Posts made by Dan_Woolf

Hi @kichikawa_2913,

Glad to hear it is working now. I know the NuGet client does a lot of caching on it's side, so it is very possible that resetting the credentials for Visual Studio forced a reset of that, but I'm not positive. Either way, I'm happy it is working for you now! Please let us know if you find any other issues with it.

Thanks,
Dan

Hi @kichikawa_2913,

For managing the AD Credentials, that will be fixed in ProGet 6.0.11. Unfortunately, that was not caught in time for the release, but it is fixed in a current development branch.

So I just want to make sure I understand the current state.

• You have updated the AD Credentials to use a user that can query groups.
• When you test the permission in ProGet it shows view/download.
• When one of those users logs into the ProGet UI, they can view and download the packages fine.
• When they try to view and download from Visual Studio, it does not work.

Can you confirm that is correct?

When the user is using visual studio, are they logging in with their domain username and password? Or are they using an API key (username api the key as their password)? Can you try resetting the credentials used for visual studio? We have a walk through on how in our troubleshooting section of the how to add a repository to Visual Studio How To.

Thanks,
Dan

Hi @Russell-Kahler_4399,

If you open InedoHub you should see logs for the failed upgrade. Can you please look in there and tell us what database scripts failed to run?

Thanks,
Dan

Hi @mcascone,

Can you go to your Profile settings and tell me what your Homepage is set to?

Thanks,
Dan

Hi @mcascone,

Thanks for bringing this to our attention. It seems to default to support for me. Does it default as empty or Off Topic for you?

Thanks,
Dan

Hi @kichikawa_2913,

I would agree that does not look like a ProGet error. Please let us know what you find.

Thanks,
Dan

Hi @kichikawa_2913,

Do you happen to have multiple groups with the same name in different OUs? Your log output looks like it found the group, but then the search for the users is not returning any users. If you look at the last line of the debug statement you sent, it shows the group name and OUs it is using when searching. That starts at memberOf=CN=<Group_Name>,OU=.

Thanks,
Dan

Hi @dm-sidelnikov_5266,

This is most likely related to either something missing in the package's metadata or a feature missing in the Azure DevOps NuGet API. We have found that Azure DevOps can be a little loose when it comes to the NuGet API spec.

The easiest way for us to solve this would be to share access to your Azure DevOps registry, we can debug this and get a fix out pretty quickly for it. If that will not work for you, could you run Fiddler on your ProGet server and record the connector requests and send us the exported saz file to review? You can email these too us via support@inedo.com with a subject of "[QA-786] Azure DevOps Null Reference" and we can review it from there.

Thanks,
Dan

Also, I just reviewed the email you sent about the view effective privilege's and it looks like something is not linking up correctly for your users group. Would you be able to run the our AD Test tool 1.13.1 from a windows computer and see if your users show up when searching for members in that group? You will see a tab in that tool called "Get Group's Users". It will allow you to verify we are pulling those users back in that group.

Thanks,
Dan

Hi @kichikawa_2913,

When you are on the "Domains / User Directories" tab, you should see a link at the top that says "revert to single-directory mode". Steve is requesting that you click that link and see if the problems with the groups still exists.

Thanks,
Dan

Hi @marc-ledent_9164,

BuildMaster requires SQL Server to run and cannot be replaced with PostgreSQL. But, you can use BuildMaster to manage the change scripts for a PostgreSQL database. You will just need to install the PostgreSQL extension and create a PostgreSQL database connection. You can learn more by reviewing our CI/CD for Databases documentation.

Please let us know if you have any other questions!

Thanks,
Dan

Hi @kichikawa_2913,

Could you try two things for me?

1. Temporarily disable the Built-In directory and see if it works?
2. Re-enable Built-In and login with the user name in the format of "user@domail.local"?

Thanks,
Dan

Hi @kichikawa_2913,

I think I see what is happening. You currently have both the Built-in and the LDAD user directory enabled. I'm guessing you have users added to the Built-In directory with the same username and it is favoring them. Since those are not in the LDAP group, it is not accepting the permissions. Since you are currently only using the LDAP user directory, I would suggest disabling the Built-In directory.

The other options would be to remove those users from the built-in directory or add groups to the Built-In with the same name as the LDAP groups and give those groups permissions.

Thanks,
Dan

Hi @kichikawa_2913,

Thanks for sending that over. Could you also screenshot the "Domains / User Directories" tab and send that over? Your permissions look correct, I'm wondering if there is another setting that might be conflicting.

Thanks,
Dan

Hi @kichikawa_2913,

Thanks for checking that for me. Based on the fact that you cannot view/download the packages via the UI, this sounds like a permissions configuration issue. Is it possible to share a screen shot of your permissions configuration? You can send it to support@inedo.com with the subject of [QA-785] Permissions Configuration if you do not feel comfortable posting on the forums. This will give us a better idea of things to check for (we would also not post any AD group names directly in the forums either).

One last thing, can you confirm the version of ProGet you are using and the version of the InedoCore extension you have installed?

Thanks,
DAn

Hi @kichikawa_2913,

I believe Steve is suggesting for each user to create a personal API key and then use that to authenticate their NuGet feed. That would allow you to use api as the username and api key as the password. As for where this would be setup, you would create the personal API key in ProGet and use that in the NuGet config.

Just a couple of other questions.

• Are users downloading packages using Visual Studio or the NuGet cli?
  • Visual Studio will actually use the Credential Manager and you would have to change the credentials in there.
  • The NuGet.config is typically better used for the NuGet CLI
• Can the user log in to ProGet's UI and view/download the packages in the feed from the UI?
  • This would indicate that the permissions are configured correctly in ProGet.

Thanks,
Dan

Hi @kichikawa_2913,

Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week!

Thanks,
Dan

Hi @kichikawa_2913,

Thank you for following up with us and letting us know it is working now. Also, thanks for clarifying the Docker network setup for me. This is related to how we changed the service messenger in ProGet v6.

I took a deeper look into the code and when setting the endpoint via the "change" link, it will override the configuration's shared value. Once that has been set, it will use the configuration associated with that node instead.

Based on your screenshot, it looks like it was using tcp://*:6001 as the shared configuration (even though you said not to), but failed to connect because it was trying to balance amongst the other nodes. If you were using a Docker network, this most likely would have worked because the individual nodes could have listened on 6001 as well.

After reviewing these changes, you would have to change the service messenger address on each service node in order to apply the configuration you are looking to use (which is what you did above).

Hopefully this gave a bit more context to this change.

Thanks,
Dan

Hi @kichikawa_2913,

I think the main issue here is that the Service.MessengerEndpoint configuration value is a shared configuration across all nodes in your cluster. Can you try setting that value to tcp://*:6001 and then restart all of your containers?

Also, just a couple of questions:

1. Are your Docker containers running on the same docker network?
2. Do you have High Availability enabled?

Thanks,
Dan

Hi @janne-aho_4082,

It looks like @rhessinger replied to your other ticket, EDO-8231, with another potential fix. We will update this forums post with the result of that test.

Thanks,
Dan

Hi @claudio_9251,

I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that.

Thanks,
Dan

Hi @sbindra_9387,

You should create a new free license for your preprod environment. Creating that new license will not affect your production activation. Just to verify, your preprod environment is pointing to a different database and different file storage than your production instance, is that correct?

I know you are running an older version of ProGet, but our guide on how to migrate a server should still work for ProGet 5.1. That guide will show you what you need to do to migrate your production instance to a test server.

Hope this helps!

Thanks,
Dan

Hi @araxnid_6067,

We are always happy to help. Please let us know if you have any other questions for us!

Thanks,
Dan

Hi @araxnid_6067,

You can see where those blobs are used by querying the [DockerImageLayers_Extended] view in SQL server. The file name should match the [Blob_Digest] column and that will show you which repository that uses. If you need to see tags too, you will need to join that with [DockerRepositoryTags_Extended] view on the [DockerRepository_Id] column.

Hope this helps!

Thanks,
Dan

Hi @cronventis,

Thanks for the details. Let us know when you shift over to Azure k8s if that fixes your issue or not. I would love to figure out what configuration made it change that value, but I can definitely understand holding off until you make your final shift.

Thanks,
Dan

Hi @Mikhail-Riabukhin-ext_9798,

ProGet 6.0.7 is scheduled to release this Friday January 28th. We typically release every two weeks, with the occasional delay.

Hope this helps!

Thanks,
Dan

Hi @brett-polivka,

No problem! We are expecting this fix to be released on Friday. We will let you know if anything changes!

Thanks,
Dan

Hi @cronventis,

Just an update: We are still looking into the issue. We are currently having trouble recreating the same API output as yours. In our tests, the imageId returned for the container status contains a different digest. We are digging further into the Rancher documentation, specifically around their Kubernetes configuration.

If you have any tips on some specific Rancher/Kubernetes configurations we should look for, please let us know.

Thanks,
Dan

Hi @brett-polivka,

Thanks again for all the information. I was able to identify the issue and it will be fixed in ProGet 6.0.7. The issue is tracked in PG-2078. Once that is released, you will need to make sure Do not use library/ prefix for repositories without namespaces (this may be required for some container registries like Microsoft Container Registry) is checked.

Thanks,
Dan

Hi @brett-polivka,

Thanks for giving us an update on this. We are digging into this a bit further to see what is going on. Just out of curiosity, for one of the images that are missing the prefix. If you type the image name as 'library<image name>`, does it work then?

Thanks,
Dan

Hi @brett-polivka,

The manifest error is the generic error that the Docker CLI throws when it cannot find an image or something went wrong when pulling the image. Since you do not have any other package or container type (Helm, OCI, etc...) in your registry, it shouldn't cause any issue with ProGet.

Do you see any of your ACR containers in the ProGet UI? ACR does support container searching (or at least it did last time I tested it). Have you tried to enable Attempt to search the container registry in your connector advanced options? That will allow ProGet to list the available images. Could you also attempt to search by the exact image name in ProGet? Do you see your image then? If not, my guess is that your private ACR URL and/or credentials are incorrect.

Based on your ACR configuration, you may have to generate a token instead of using your password. See Microsoft's Authenticate with an Azure Container Registry documentation to see what credentials will work. Basically, if you see docker login under the "How to Authenticate" column, that username/password combination should work in ProGet.

Thanks,
Dan

Hi @brett-polivka,

I have a few questions for you.

• What version of ProGet are you currently running?
• Does your Azure Container Registry only include Docker images or does it also include OCI images?
• Does your registry include HELM packages as well?

Thanks,
Dan

Hi @claudio_9251,

Always happy to help! Please let us know if you still run into issues after the updgrade.

Thanks,
Dan

Hi @claudio_9251,

Thanks I was able to reproduce this and logged the fix as ticket PG-2077. This fix will be released in ProGet 6.0.6.

Thanks,
Dan

Hi @claudio_9251,

Thanks for sending this over. I can confirm we have received your email. Please give us a little bit of time to review and we will get back with your shortly.

Thanks,
Dan

Hi @kichikawa_2913,

Thanks for following up and letting us know that you found the solution!

Thanks,
Dan

Hi @mcascone,

So this is actually working as expected. We order by the version number itself instead of the upload date, which is why you are seeing that version on the bottom. When ordering, we order first by major, then minor, then patch. So in this case 1-PLATDEV > 1-develop, which is why 2.1.1-develop-2018 drops to the bottom.

I believe we have sent this to you before, but just in case we have not. We have created an article for
Best Practices for Versioning NuGet Packages in the Enterprise. This goes into a lot more detail on NuGet versioning.

Thanks,
Dan

Hi @cronventis,

Do you see any records in the ContainerUsage database table in the ProGet database. When the scanner runs, it will dump records into that table and then the UI will display the records from there.

Thanks,
Dan

Hi @cronventis,

Can you please tell me what version of ProGet you are using and what version of the Kubernetes extension you have installed? I can confirm that we have users that have it working successfully. When you say the scanner seems to work, does that mean that some images are detected and some are not?

Thanks,
Dan

Hi @p-boeren_9744,

I did receive the email, thank you for that. This mostly confirms my thought. There is still one issue, but I think it has to do with this package being downloaded anonymously first prior to adding login information to the NPM client. This fix is being tracked in ticket, PG-2059, and is scheduled to release on Friday in ProGet 6.0.5.

Thanks,
Dan

Hi @darkbasics_6739,

We found the issue and the fix will be released on Friday in Otter 3.0.17. This looks to be a regression from our .NET 5 conversion for our Docker image and tends to only affect specific operations. It just so happens that our demo PowerShell script and our Verify Hotfix example uses the features that this affects.

Thanks for catching this for us!

Thanks,
Dan

Hi @hwittenborn,

You are using the correct username. When using a username/password with an API key, the username should be api. Would you be able to share your configuration for the API key? It sounds like there is something incorrect in its settings.

If your user account has access to push packages/images to ProGet, could you try using a personal API key? When using a personal API key, you should still use the username api.

Thanks,
Dan

Hi @lockhead,

I think I see what the issue might be. Would you be able to capture the requests made from NPM to ProGet using a tool like fiddler and send them over to us? You can send the requests to support@inedo.com using the subject prefixed with [QA-706] . This would help greatly to confirm my thoughts.

Thanks,
Dan

Hi @darkbasics_6739,

Thanks for verifying that for us. Are you using the InedoAgent on the remote server or the PowerShell Agent? If you are running the InedoAgent, what version do you have installed? Also, could you try running it again? I have seen in some instances the download of the Scripting extension on the remote machine takes a bit longer and causes a similar error. I have found that typically this is resolved by the second Server check.

One last check, can you please verify what version of the Scripting extension you have installed? You can find that by navigating to Administration -> Extensions (Plug-ins)

Thanks,
Dan

Hi @darkbasics_6739,

What version of Otter are you running? Also, do you have it installed on Linux (Docker) or Windows? We had this issue with an older version of Otter when running on Linux (Docker), but it was fixed in Otter 3.0.14.

Thanks,
Dan

Hi @v-makkenze_6348,

Can you please share your IIS configuration settings that you have used? Can you specifically include any caching settings you have as well?

Thanks,
Dan

@scusson_9923 said in How to create an Asset Directory subfolder via the API:

https://docs.inedo.com/docs/proget-reference-api-asset-directories-api

Hi @scusson_9923,

I think the issue is that you are missing the -X in your curl command which is making curl think the URL is POST instead. Could you please try the following command:

curl -X POST https://<ProGet_server>/endpoints/<asset_dir>/<new_dir>/ --user <user>:<password>

Thanks,
Dan

Hello,

I believe the issue is because you have Windows Authentication enabled in IIS. Currently active directory authentication and integrated authentication (windows authentication) is only available in paid editions of ProGet. Please try disabling Windows Authentication in IIS and see if that fixes the issue.

Thanks,
Dan

Hi @kurt-burri_8500,

I think you are looking for our [Package Consumers] (https://docs.inedo.com/docs/proget-packages-package-consumers) feature in ProGet. Unfortunately, the automated way of doing this requires a paid version of ProGet, but you can manually add the consumer records. The automated way would be to run our pgscan tool against the source code and it will record a package consumer record on each of it's dependencies.

This feature will be more helpful going forward, so it's not exactly your use case. If you have access to the source code, you could either use a tool like Agent Ransack to search the contents of files for that package Id or fork our pgscan tool and modify it to scan through your projects and output which ones are consuming that dependency.

You could also try to use the feed APIs that the client tools use to walk the packages and look for dependencies, but there is not much guidance I can give there (especially since each feed type differs greatly) and this solution can get pretty complex pretty quickly.

Hope this helps!

Thanks,
Dan

Hi @kurt-burri_8500,

Could you please give us a little more context to this? Currently in the ProGet UI, the dependencies for a package will show on the Dependencies tab for the package version you are looking for. Are you looking for something different than that?

Thanks,
Dan