Posts made by Dan_Woolf

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

Hi @falk-winkler_2111,

Thanks for following up and letting us know this is resolved now. Can you please post what your final solution was?

Thanks,
Dan

Hi @jev_1362,

The file should be saved on the server in the storage path. Can you check and see if that file exists locally on the server? You can find the storage path for your asset directory by navigateing to Assets and then clicking the pencil to the right of the asset directory. Then click the Storage & Retention tab and you will see your storage path there.

Also, do you see any errors int eh diagnostics center when you try to download that file?

Thanks,
Dan

Hi @lukel_3991,

I think we have two different issues that are happening here. The first one it seems to not be synchronizing over the extensions. What version of PowerShell do you have installed on your remote server and the otter server? The PowerShell based agent-less servers connect using PSRemoting over WSMAN. Could you please try to connect to your remote server using Enter-PSSession in PowerShell on your Otter server and try to run some commands to make a temp folder and write a file to it using the same credentials Otter users to connect to that server? It almost feels like there may be a permissions issue.

The other issue seems like their could an issue with your OtterScript itself. Would you be able to share the OtterScript you are trying to run?

Thanks,
Dan

Hi @falk-winkler_2111,

Can you please try setting the Web.BaseUrl in Administration -> Advanced Settings to http://packages2.test.plano and restart your container? This will tell ProGet that the expected local URL is http://packages2.test.plano.

Thanks,
Dan

Hi @tcddpmonqxvfmiuyla_2318,

No problem, thanks for updating with what you found the problem to be.

Thanks,
Dan

Hi @paul_6112,

What are the hardware (or virtual hardware) specs of your server?

Thanks,
Dan

Hi @forcenet_4316,

Thanks for finding this for us. This looks to be a regression due to our recent API key changes. We have fixed this in our upcoming ProGet 6.0.2 release that is due out on Friday. These fixes are tracked in PG-2033 and PG-2034.

Thanks,
Dan

Hi @ashah_4271,

In summary, >> is SWIM syntax for OtterScript to create a string literal that allows multi-line strings. You could also use set $indexName = $PSEval('(Get-Date).AddMonths(-1).ToString("yyyy.MM.*")'); because that PowerShell is a single line and only has double quotes in it. I find the SWIM syntax works a bit better when embedding PowerShell inside of Otter Script because it removes risk when using single or double quotes within PowerShell. This is what I mixed up the first time. Simple PowerShell can normally use implicit string literals in the $PSEval function, but since there are double quotes, that breaks implicit string literals.

You can learn more about string literals in OtterScript in our Strings & Values documentation.

Thanks,
Dan

Hi @ashah_4271,

I'm not sure why this syntax error is happening, but I have a work-around for you. Can you please try:

##AH:UseTextMode


# Call DELETE on ElasticSearch
with retry = 3
{
    set $indexPSScript = >> (Get-Date).AddMonths(-1).ToString("yyyy.MM.*") >>;    
    set $indexName = $PSEval($indexPSScript);

    Get-Http $elasticUrl/$indexName
    (
        Method: DELETE
    );
}

Thanks,
Dan

Hi @ashah_4271,

I'm sorry, I should have calrified. I sent you some OtterScript to try. Can you please try this?

##AH:UseTextMode


# Call DELETE on ElasticSearch
with retry = 3
{
    set $indexName = $PSEval((Get-Date).AddMonths(-1).ToString("yyyy.MM.*"));

    Get-Http $elasticUrl/$indexName
    (
        Method: DELETE
    );
}

Thanks,
Dan

Hi @Stephen-Schaff,

Thank you very much for the suggestion. We will get this into the next release of ProGet (5.3.41 and 6.0.2). We are tracking the feature in PG-2020.

Thanks,
Dan

Hi @ashah_4271,

Since this is such a simple piece of PowerShell, I think the easiest way to handle this would be to use the $PSEval variable function. This should work for you:

set $indexName = $PSEval((Get-Date).AddMonths(-1).ToString("yyyy.MM.*"));

Can you please give this a try and let me know if that works?

Thanks,
Dan

Hi @philippe-camelio_3885,

This has been fixed and will be released in Otter 3.0.13 which is expected to be released on October 22nd 2021.

Thanks,
Dan

Hi @mcascone,

Do you see any errors in the diagnostics center?

Thanks,
Dan

Hi @mcascone,

Can you please verify what version of ProGet you are running? I know in older versions of ProGet 5.3, if you use the feed type of Private/internal packages or Validated/promoted packages, it will hide remote packages until at least 1 local package is added. Something to try is to change the Feed Type on the Manage Feed page to use Free/Open Source packages or Mixed packages to get remote packages to show. It looks like that was fixed in ProGet 5.3.20.

Thanks,
Dan

Hi @shiv03_9800,

I'm sorry for the confusion. That troubleshooting document is a bit different than what my goal was in my response. I wanted to get you to a folder that allowed you to control the permissions on that folder to remove a possible permissions issue in the Windows temp directory. I have seen on some occasions that the Windows temp directory will block deleting or modifying some existing folders. They easiest way to determine if that is the issue is to change the temp directory to a location that you can edit permissions on.

I also realize that troubleshooting document has a typo in it. The doc says to use Otter.RootPath as the element name, when you need to use OtterRootPath. Can you please confirm which element name you added to the Inedo Agent config?

Can you please clarify what you are referring to when you say that you need to reconfigure Otter to blank the temporary directory. The Inedo Agent based servers do not have an option to set a temporary path directly in Otter.

Thanks,
Dan

Hi @shiv03_9800,

What account do you have your Inedo Agent running as on your client server? We have seen some issues in the the past with the default temp directory (C:\Windows\Temp\InedoAgent\Otter) when running with the built-in accounts. This doesn't happen often, but we have seen it on a few occasions.

Could you please try adding an <OtterRootPath>Path to your custom temp directory</OtterRootPath> element to your Inedo Agent config? You can do this by:

1. Create a new temp directory on that server with full permissions to the account that the Inedo Agent service is running as
2. Edit the InedoAgent.config file under C:\ProgramData\Inedo\SharedConfig
3. Add the OtterRootPath element directly under InedoAgentConfig root element
4. Restart the Inedo Agent service

Can you please give this a try?

Thanks,
Dan

Hi @bryan-ellis_2367,

Can you please ty to restart your ProGet server? I have seen some issues like this before where certain components in ProGet is still caching the login credentials and a reboot refreshes it.

Thanks,
Dan