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