The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue: ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 SecurityProtocolType.Tls SecurityProtocolType.Tls11 SecurityProtocolType.Ssl3; //createing HttpWebRequest after ServicePointManager settings HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.

It seems that PowerShell client doesn't provide much details about errors, so glad you could figure out what the issue was for powershellgallery.com. That message probably could mean a lot of things, and is probably unrelated to TLS/SSL.. So the first thing that's jumping out to me is this: WARNING: Unable to resolve package source 'http://proget.domain.org/nuget/ps' There is no https connection, so there'd be no TLS/SSL issues. But assuming you may have changed the url when posting this... here is a registry key you can use to force that setting (it makes that powershell command unnecessary) https://inedo.com/support/kb/1161/tls-v12-configuration-and-connection-errors If you're on HTTPS the other thing to look at would be certificates. Otherwise, you may need to use something like Fiddler to see the actual request/responses that PowerShell client is issuing/reciveing.

Hi @jan_ko , Thanks for sharing this; the .nuspec file looks okay to me, so it doesn't seem like a problem with the package. After building the agent pushed these nupkg's to the Azure DevOps Artifacts. This feed is connected to a ProGet connector. Well, I'm thinking the issue is in the Azure DevOps Artifacts API. We found many bugs in their feeds already (i.e. not implementing the API as specified). It happens to work in Visual Studio, or Visual Studio already worked around the bug. We can spot it very easily with a debugger; if you can share to use a feed url and credentials (I think it's just n access token?), then we can connect to the feed and see what's causing that error. You can send us the details via the ticket, so then it's not public. Cheers, Alana

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, This is an old thread but i have the same question. We're on 5.3.17 and have used up all of the space on C:\. We have 1TB on D:\, so I just want to move the PackagesRootPath to there. Does the above pattern still apply? thanks max

Hi @Stephen-Schaff, The latest tag is a bit odd. Each client handles it differently and I have found most clients will not repull a newer version if latest has already been pulled once. According to Docker's API (and Kubernetes), a client is supposed to pull the manifest from the server and compare it with the currently downloaded image and update if there is any difference, but I have found that does not always work. You can configure Kubernetes to always pull an image, but I cannot confirm how well it works. As for getting a list of tags, we basically have two ways. What it sounds like you are looking for is to just get a list of alternative tags. The only way to do this is to use our native API and using the DockerImages_GetTags method and grouping by DockerImage_Id. The other way to get a list of tags would be to use the docker API itself. This way will get all tags associated with a repository, not just the alternative tags. To do this: Make a get request to http://<your proget server>/v2/_auth with an Authorization header with the value of Basic <BASE 64 encoded username:password> The response will be a JSON object. Take the value in the token property Make a GET request to list all tags to http://<your proget server>/v2/<feed name>/<image>/tags/list (ex: `http://proget.localhost/v2/defaultdocker6/dotnet/core/aspnet/tags/list) In the header include an Authorization header with a value Bearer <token from step 1> This will return a JSON object that has an array property called tags That will get you a list of tags using the Docker API. Hope this helps! Thanks, Rich

Hi @shiv03_9800, We have just released a new version of Otter that includes a fix for the segmentation fault. You will need to make sure that .NET Framework 4.5.1 or greater is installed on the Windows server. But if you were able to run the Inedo Agent installer, then chances are you already have that installed. As for the Inedo Agent error, I talked with some colleagues and this is something we have seen on slower or congested networks when checking Inedo Agent has the components needed to communicate with Otter. Normally if you wait for the next server check to occur, the issue ends up resolving itself. There was another issue, however, that can affect PowerShell scripts when using the Docker version of Otter, OT-432. This was fixed in the latest release as well. Thanks, Rich

If you are using IIS for hosting your application, then the default upload file size is 4MB. To increase it, please use this below section in your asp.net web.config - <configuration> <system.web> <httpRuntime maxRequestLength="1048576" /> </system.web> </configuration> For IIS7 and above, you also need to add the lines below: <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="1073741824" /> </requestFiltering> </security> </system.webServer> Note: maxRequestLength is measured in kilobytes maxAllowedContentLength is measured in bytes

@stevedennis sorry for such a delayed reply. Our use case is simply because when we setup our shares on our SAN we setup a share per package type (python, NuGet, etc) just in case of the need to more granularly control backups/maintenance of the shares. We may run into different issues/needs depending on the package type or we may not, just wanted to have the ability.

Hi Igor, Thanks for the help in tracking this down. We've now fixed this in an internal build (logged as OT-428) . The fix will be in Otter v3.0.12, scheduled for release on October 8. If you'd like to test a prerelease build, you can pull the proget.inedo.com/productimages/inedo/otter:3.0.12-ci.1 image, which already contains the fix. -Greg

@mcascone do you happen to remember where you found that link? We are trying to be conservative about adding a ton of redirect rules... We are now running automated scans, so HOPEFULLY it's picking up bad links within the docs.

Hi @Stephen-Schaff , Yes, this can be a little bothersome. Actually this is something that we're considering for v6, to mostly replace the "impersonation" feature: Allow on Feeds: [feed1, feed2, «group1»] Feed Permission: View/Download Publish/Push Delete/Overwrite The "username" would still be there, but mostly for "personal api keys". Thanks, Alana

Hello; I'm not all that familiar with Ruby Gems, but I'll try to help. At first, I think the problem is that you're using host instead of source. gem push <gem file> --source http://<redacted>/rubygems/RubyGem Hope that does the trick :) FYI; we recently updated our RubyGems Documentation to help others get setup.

Thanks @antony-booth_1029 ! This should get fixed via BM-3740 in the next maintenance release of BuildMaster

It seems the package deployment endpoint is POST-only, but using the Native API you could use the Packages_GetPackageDeployments method. Down the line we can certainly consider adding GET method on the deployment api... if you can help us know what you/someone will use that info for ;)

@Dan_Woolf I got it fixed by changing some permissions. Somehow even though Admin had rights to the feed it would not show up. I removed admin and added Administrators now all is good. Thank you for your help!

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

@grant-sparks_1282 I'm surprised there's no index, but I guess that's a property popular repository, so we can make ProGet not error in this case. i logged PG-2007 to handle this :)

@mcascone yep, that's a good way of putting it!

Ah, that makes sense, the weirdness of the NuGet Gallery is why we're migrating to ProGet in the first place Anyway, thanks for the great support. Will definitely recommend ProGet in the future!