Posts made by Dan_Woolf

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

Hi @bryan-ellis_2367,

What version of ProGet are you using?

I would also clear your cookies in your browser. It is most likely trying to use your previous login information still. One way to test this is to open a private browsing tab in your browser and see if you still have the same error.

Thanks,
Dan

Hi @mcascone,

The package deployment API will show in the History tab of the package. The Package usage block is actually part of Package Usage Scanners that are only supported on specific feed types. Which feed type are you using in this situation?

Thanks,
Dan

Hi @Fauzi-Ashurex_3595,

I see you have submitted a formal support ticket for this. I will post back the final solution to this post once it is fixed.

Thanks,
Dan

Hi @shiv03_9800,

No problem! Glad I can help!

Please let me know after Otter 3.0.11 is released if that fixes the PowerShell agent for you.

Thanks,
Dan

Hi @shiv03_9800,

Thank you for confirming that for me.

I was able to find a regression issue in the PowerShell Agentless Server configuration, OT-427. Our engineers were able to patch the issue and it will be released on Friday September 24 in Otter 3.0.11.

The setup instructions are pretty straight forward for setting up these servers. I have included the basics below. The key thing is to make sure to set the Temp Path on the servers.

For an SSH server:

1. Create a Secured Credential for the SSH credential
2. Create the server (make sure to set the temp path)
   • The temp path must exist on the remote server and the SSH user must have read/write/delete access to that folder

For a PowerShell server (Otter 3.0.11+):

1. Create a Username Password Secured Credential (Integrated Authentication will not work in Docker)
2. Create the server (make sure to set the temp path)
   • The temp path must exist on the remote server and the user must have read/write/delete access to that folder

Hope this helps!

Thanks,
Dan

Hi @shiv03_9800,

Thanks for sending this over to us. Just to clarify, you are to setup a PowerShell and an SSH based agentless servers and you are getting the listed errors and you are looking for how to set these up. Is that correct?

Thanks,
Dan

Hi @scusson_9923 ,

Thanks for sending the updated info. Would you be able to attach to output of the Clair container (docker attach <RUNNING_CLAIR_CONTAINER_NAME>) and run the vulnerability downloader from ProGet? Clair will output the exact HTTP error that is happening when connecting to ProGet. That will help to confirm if it is an SSL issue or not.

One other thing to try would be to upgrade Clair to 2.1.7. I know they fixed an issue relating to a RHEL feature they use, that happened to be affecting my test environment.

Sorry for the delay on our end. Clair has released a new version and API which makes finding the older documentation a bit harder. We have not tested it with the latest version of Clair (4.2.2), but I would expect their to be some API issues. We are waiting for Clair's development to stabilize a bit more before we implement the new API. Last time we tested it, Clair's v4 API had so many bugs that it prevented us from supporting it.

Thanks,
Dan

Hi @scusson_9923 ,

Can you please confirm that you do not see any errors in the diagnostic center after running a vulnerability scan? I just want to confirm that this is an SSL problem and not an underlying ProGet issue.

Thanks,
Dan

Hi @kichikawa_2913,

NuGet will always use a .nugetv2 folder under the packages root path, unless you customize it at the Feed level. If you change the Storage.PackageRootPath, it will change the location of the .nugetv2 folder. I will note though, if you change the Storage.PAckageRootPath, it will also update any other feed type path that has not already been changed. Currently the only way you can customize the NuGet storage path is at the Feed level.

Thanks,
Dan

Hi @antony-booth_1029 ,

I'm having trouble recreating this issue. Do you have Deployables configured with the different configuration environments? Also do you see the correct environment selected when you look at each configuration instance's settings?

Thanks,
Dan

Hi @mjc_4927,

Can you please let me know what version of BuildMaster you are running?

Your tasks look to be configured correctly. Let me chat with our engineering team and I'll let you know what I find out!

Thanks,
Dan

Hi @izzy95453_1154,

I think the next step is to verify that your connector is configured correctly. Can you search in the ProGet UI for mssql/server? That should return the remote image for SQL Server. If you then click on the the Remote Tags tab and then click on 2019-latest, you should see the command syntax for pulling that image. Can you please verify that matches what you are using?

~ Dan

Hello @izzy95453_1154,

I completely understand you frustration here and I will bring these comments up with the documentation team. I believe the documentation you are looking for exists in our private container registry documentation, but I will summarize it below.

Looking at your commands, I can definitely help you with this. The first thing you will need to do, is setup a private container registry. The Docker client by default requires SSL. Looking at your commands, you are currently using an HTTP protocol. This will require you to setup an insecure registry.

If you are requiring authentication, you then need to login to your registry. You can log in either with a username and password or you can generate an API Key and use api as the username and the key as your password. You can do that with the following command:

docker login {my-proget-domain}:{my-proget-port}

Once you have setup your insecure registry and logged in (if not using anonymous access) then you should be ready to pull your image. To pull the image above, the command syntax would be:

docker pull {my-proget-domain}:{my-proget-port}/{docker-feed-name}/mssql/server:2019-latest

The reason you are getting the syntax error above is because you are specifying http://. Docker requires just the server and port. I also want to point out that the Docker client requires a . in your domain name or :{port} to exist in the first url section. That is what the Docker CLI uses to identify this is a private registry and not Docker Hub. For example:

• ProGet URL: http://proget-server using the standard HTTP port 80, Docker URL proget-server:80\{feed-name}\{image}:{tag}
• ProGet URL: http://proget.localhost using the standard HTTP port 80, Docker URL: proget.localhost\{feed-name}\{image}:{tag}
• ProGet URL: http://proget-server:2365, Docker URL: proget-server:2365\{feed-name}\{image}:{tag}

In ProGet 6, we will be adding Feed usage instructions that should help guide users going forward. ProGet 6 will be released later this year.

Hope this helps!

~ Dan