#[Resolved] rmfakecloud-proxy proxy doesn't run on RMPP

1 messages · Page 1 of 1 (latest)

versed phoenix
#

The command to install the proxy on the device doesn't work out of the box (sh -c "$(wget https://raw.githubusercontent.com/ddvk/rmfakecloud/master/scripts/device/automagic.sh -O-)"), so instead, since the automagic script just downloads and runs the installer, you can pull down the installer.sh and rsync it to the device.

Running it goes through most of the steps and would appear to install things correctly, but, the logs show:

Oct 01 21:06:37 {hostname} systemd[1]: Started reverse proxy.
Oct 01 21:06:37 {hostname} systemd[74739]: proxy.service: Failed to execute /home/root/rmfakecloud/rmfake-proxy: Exec format error
Oct 01 21:06:37 {hostname} systemd[74739]: proxy.service: Failed at step EXEC spawning /home/root/rmfakecloud/rmfake-proxy: Exec format error

Checking the ExecStart string, ExecStart=/home/root/rmfakecloud/rmfake-proxy -cert /home/root/rmfakecloud/proxy.bundle.crt -key /home/root/rmfakecloud/proxy.key {servername} and trying to run that from scratch, you get the following error:

-sh: /home/root/rmfakecloud/rmfake-proxy: cannot execute binary file: Exec format error

System Info:

  • RMPP running 3.14.1.10
  • Filesystem was mounted RW

An additional question I had:
The other thing I was trying to suss out is that it seems like the device is running a proxy so that it can intercept the calls to appspot and then redirect them to wherever you have the rmfakecloud server installed, but the way some of the docs are written doesn't seem entirely clear, especially if you're running the server behind an nginx reverse-proxy anyway.

I have otherwise made modifications to the /etc/hosts and so if I pull down a static aarch64 tcpdump, I can see the traffic trying to go to my host, but nothing there (though that's probably because the server_name is my server hostname, not listening for any of the other names).

Thus, not entirely sure which step or which thing is intended.

narrow spoke
#

The reason it doesn't work is because the binary is compiled for an armv7 system (rm2) but the RM3 is on an aarch64 system

versed phoenix
#

Right, I figured that based on what Eems was saying yesterday. Is this perhaps a better post for the Issues tab on that repo? (I also figured documenting it here was useful).

Alternatively, the question I had about which things are getting proxied at which step is the other thing I was looking to follow up on.

elder burrow
elder burrow
#

It's written with go, so it should be extremely straight forward to cross compile to aarch64 instead. According to my limited knowledge from what I've heard from others.

#

I'm not sure if the repo has automated builds implemented yet though, so that probably would be needed.

versed phoenix
#

Never written Go before, so not sure there. Could stumble my way through it, can see if I have some time coming up

elder burrow
#

It shouldn't require code changes to the application itself, just running the build and telling to to build for aarch64 instead. As for automated builds through a pipeline...that would be more work if it's missing.

narrow spoke
elder burrow
#

They probably thought it was going to be that when they started

versed phoenix
versed phoenix
#

And merged!

I guess since Discord isn't actually a support tool, there's no way to mark the thread as "resolved?"

elder burrow
#

You can update the title to add [Resolved] or something similar

#

usually the thread just auto "closes", but someone could always revivie it

versed phoenix
#

[Resolved} rmfakecloud-proxy proxy doesn't run on RMPP