search

immense / Remotely

A remote control and remote scripting solution, built with .NET 8, Blazor, and SignalR.
GNU General Public License v3.0
4.28k stars 1.6k forks source link

Latest Version - Windows install download just downloads PowerShell Script #875

Closed Articical closed 3 weeks ago

Articical commented 2 months ago

Describe the bug A clear and concise description of what the bug is. Ideally with a screenshot if applicable.

When attempting to download the background windows client via the "Downloads" page, the windows powershell script downloads and not the EXE.

To Reproduce Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Go to "Downloads" Select "Windows Installer (x64/x86)" Install-Remotely.ps1 will then download

Remotely Version Server (can be found on about page): 2024.02.23.1927 Agent (can be found in device card): N/A

Expected Behavior A clear and concise description of what you expected to happen.

Previous versions that I have used have always downloaded an EXE setup file as opposed to a powershell file.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional Context Add any other context about the problem here.

SoWhy commented 2 months ago

According to https://github.com/immense/Remotely/releases/tag/v2024.02.22.1231, this is a known problem since the latest versions, see commit https://github.com/immense/Remotely/commit/07905eedaf0fb0196ebd758ce414e3b425e7edaa

bitbound commented 3 weeks ago

This was intentional. The EXE installer will no longer be used. It was using a legacy version of .NET (called .NET Framework with WPF). The end goal was to make a cross-platform installer with Avalonia UI, or make the agent a self-contained EXE with CLI options to install itself, but I never got around to it.

For now, I added a copy-and-paste script for deploying the agent on a new Deploy page. This is on the preview tag if you want to test it.

image

blaine07 commented 2 weeks ago

This was intentional. The EXE installer will no longer be used. It was using a legacy version of .NET (called .NET Framework with WPF). The end goal was to make a cross-platform installer with Avalonia UI, or make the agent a self-contained EXE with CLI options to install itself, but I never got around to it.

For now, I added a copy-and-paste script for deploying the agent on a new Deploy page. This is on the preview tag if you want to test it.

image

Unsure if unintentional of config error on my part?

Since changing to "preview" tag the PS1 wont run to install remotely on windows devices.

The fix was, on the PS1 to edit line 24 and change my Hostname to HTTP from HTTPS. :scratches head: I haven't made any other config changes other than changing to "preview" tag.

Error I had before making this change: 6/11/2024 6:27:06 AM - Error occurred: At C:\Users\DVR\Downloads\Install-Remotely.ps1:107 char:18

Was this intentional?

bitbound commented 2 weeks ago

Unsure if unintentional of config error on my part?

What you're describing is likely a configuration issue. All the official docs on the issue can be found here.

To try to summarize: In order for the backend to correctly determine the host and scheme (http/https) of the original request (i.e. the URL in your browser's address bar), a few things need to happen. First, the backend has to have the IP address of the proxy in its KnownProxies list. Second, the correct forward headers need to be set in the requests proxied to the backend. And lastly, if there are multiple proxies that traffic goes through, each of those need to be configured correctly.

Without the above, the backend will see the scheme and/or host that the proxy uses. The scheme seems to particularly problematic, so I added this option on the Server Config page:

image

Enabling this will force all the install scripts to use HTTPS, regardless of what it sees from the proxy.

blaine07 commented 2 weeks ago

Unsure if unintentional of config error on my part?

What you're describing is likely a configuration issue. All the official docs on the issue can be found here.

To try to summarize: In order for the backend to correctly determine the host and scheme (http/https) of the original request (i.e. the URL in your browser's address bar), a few things need to happen. First, the backend has to have the IP address of the proxy in its KnownProxies list. Second, the correct forward headers need to be set in the requests proxied to the backend. And lastly, if there are multiple proxies that traffic goes through, each of those need to be configured correctly.

Without the above, the backend will see the scheme and/or host that the proxy uses. The scheme seems to particularly problematic, so I added this option on the Server Config page:

image

Enabling this will force all the install scripts to use HTTPS, regardless of what it sees from the proxy.

Yes, so I'll be honest here - your link is way above my comprehension.

I think you're on right track though; a proxy issue.

Currently going from Cloudflare Tunnel/Proxy>Internal Nginx Proxy Manager> Remotely. Would it work/be better if I went Cloudflare>Remotely and removed the internal "forward" through Nginx Proxy Manager? Would be one less place to have a mis-configured proxy? Issue is coming through Cloudflare as a Proxy I have no idea how I would set "known proxy" IP since with Cloudflare it changes?

blaine07 commented 2 weeks ago

image I dunno, I am still not sure something else isn't wrong though?