Thank you. I will do that.

@lm said in HTTPS with self hosted ProGet and internal web server: There is updated documentation with step-by-step instructions here: Thank you. I was confused by the section "IIS & Web Hosting on Windows". I only searched in "ProGet". It should also be mentioned to open the other port as well which should be pretty obvious but who knows. I now only need someone here to provide a certificate.

The logic is fairly simple, but in general the changes are: when you push a file to /symbols, the symbols will be indexed and the file will be saved as .snupkg when you request a symbol from /symbols, the .snupkg will be returned instead of the .nupkg file when you delete a package, the .snupkg file will also be deleted There's of course some details to work out, but with this approach, we're not treating .snupkg files as "NuGet Packages", so they won't show up in feeds.

@rhessinger great :)

@atripp I thought the fix was for Otter !

We made and tested several changes to the installer a while back, but it's not something we regularly test/verify. Please share what you find work! Thanks.

Nice password ;) Did you try restarting the agent service? (inedo.agent.exe)? I looked again (feel free to request access as well), and compared this against the messaging protocol that we use. The error is happening during the handshake. Now I'm starting to think that Otter isn't actually connecting to the Inedo Agent... but that other thing is sending back a different response? Normally the other thing would just disconnect, but I guess maybe not? Anyways Wireshark should tell you... Here's the full handshake, where you can see that Otter assumes the first byte received is a valid encryption mode (0,1,2). internal async Task SendHandshakeAsync(AgentEndpoint endpoint) { if (this.disposed) throw new ObjectDisposedException(nameof(ServerConnection)); var buffer = new MemoryStream(); var writer = new BinaryWriter(buffer); writer.Write(ProtocolGuid.ToByteArray()); writer.Write(AgentProtocolVerisons.Agent1); writer.Write(AgentProtocolVerisons.Agent2); try { var initialIV = new byte[16]; using (var cts = new CancellationTokenSource(30 * 1000)) { await this.Stream.WriteAsync(buffer.GetBuffer(), 0, (int)buffer.Length, cts.Token).ConfigureAwait(false); await this.Stream.FlushAsync(cts.Token).ConfigureAwait(false); var mode = (AgentEncryptionMode)this.Stream.ReadByte(); if (mode == AgentEncryptionMode.Ssl) { var stream = new SslStream(this.Stream, false); try { await stream.AuthenticateAsClientAsync(endpoint.HostName).ConfigureAwait(false); } catch (Exception ex) { throw new AgentConnectionException(AgentConnectionError.BadCertificate, ex.Message, ex); } this.Stream = stream; } else if (mode == AgentEncryptionMode.Aes) { if (endpoint.EncryptionKey == null) throw new AgentConnectionException(AgentConnectionError.BadEncryptionKey, "The server requires an encryption key, but a key has not been configured."); int count = await this.Stream.ReadBlockAsync(initialIV, 0, 16).ConfigureAwait(false); if (count != 16) throw new AgentConnectionException(AgentConnectionError.BadHandshake); this.messageFormatter = new MessageFormatter.AesMessageFormatter(endpoint.EncryptionKey, initialIV); } else if (mode != AgentEncryptionMode.None) { throw new AgentConnectionException(AgentConnectionError.BadHandshake, "The server requires an encryption mode that is not supported by this client."); }

@rhessinger Thank you for this, it worked. I was able to successfully login and setup new users and privileges etc.

Those are handled at different abstraction layers; the agent code doesn't have any knowledge of the context its being run in (i.e. OtterScript, the Service, etc). That's the intent of that "with credentials" setup, to allow this information to pass down.

Hi @viceice, Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline. Thanks, Rich

Thanks Greg, That cleared it all up for me.

Yet one more solution (after 6+ months). After trying all the possible solutions mentioned above - if you are still seeing the error: Response status code does not indicate success: 405 (Method Not Allowed). then most likely you need to disable your WebDav IIS plugin. You may either remove the IIS feature from the machine or if you need to keep the feature you may disable it only for this website. You may do this by editing the Web.config file (by default located here: C:\Program Files\ProGet\WebApp) and add two entries as shown below: <system.webServer> <modules> <remove name="WebDAVModule" /> </modules> <handlers> <remove name="WebDAV" /> </handlers> </system.webServer>" Note: the Modules and Handlers section should already exist, you only need to add the line <remove name="xxx"> for each section. I think Proget Dev team should integrate this in the Web.config by default to prevent future issues.. Thanks HS

Thank you, @rhessinger, for clarification. Yes, I use common blob storage, and all that makes sense now.

Hello, All good, thank you for the support, the investigation and the oncoming fixes. Cheers, Jérôme

@atripp Thank you for your time and the fix. I can wait for the next release. Best regards PhilippeC.

Hi @atripp. Yes, that worked. Thank you for all the help. -marc

Hi @gdivis, I've just installed v7.0.14 and the behaviour seems improved. On the original thread track; Using hub v1.3.7 the upgrade from v7.0.13 to v7.0.14 went through without getting stuck. After upgrade, both Test and Production web pages were able to load in less than 2 minutes. There is CPU spiking; but seems more spread out and the max memory is now two thirds of what it was; however within 6 minutes of startup its back around the 160MB - 350MB (it was idling at 160MB before upgrade) which is a definite improvement. Thanks, Paul

Does one of your embedded scripts contain a reference to a module that doesn't exist on a remote server, e.g. Web Server Administration for IIS? Unfortunately the error returned by PowerShell is fairly useless in determining which exact module is missing :)