Space Engineers: Fix issue with remote API config

[krobertson]

This removes the setting for RemoteApiIP from the Space Engineers dedicated server configuration. I had found that having the option set was preventing the remote API from working at all. I had been trying to use it for the Prometheus exporter to monitor the server, but found anything that called to the API was hanging on reading a response and eventually gave up.

Then I was doing some experimenting with a config from an old server and found that the remote API was working. Through a process of elimination looking at system packages, Wine configuration, Docker, everything, I found all I had to do to my AMP instance was to remove this line and it worked. I am not sure how it affects the game internally, but it started working fine in AMP and out of AMP with the setting removed.

One way to test and verify is that if you enable the remote API and configure it, you can do a simple curl command:

curl -v <machine-ip>:8777/vrageremote/v1/session/players

With the RemoteApiIP setting in, the request will hang. You can see it sent the request, but it hangs on getting a response. You'll probably also note that on the instance status page, AMP won't show the remote API port as listening.

Without the RemoteApiIP, you should get a 403 Forbidden back and see a log message in game about unauthorized call.

[Greelan]

Did a particular binding cause the issue, such as 0.0.0.0?

[krobertson]

I don't know for sure. I have 2 AMP instances, one in a network with IPv6 and with only IPv4. I would call to the host with just an IPv4 address and all. I even went to just running the bare SE Dedicate Server through Steam on a Windows box and trying to use their rcon viewer tool. It was only when I restored and old world that I saw it was listening and could call to it.

Just to confirm I'm not crazy, set up an instance, turn on remote API, and see it the UI shows it as listening or if the curl call works.

[Greelan]

You're not crazy, just trying to pinpoint the issue. The remote api port has never listened on Linux, I'd understood it was due to wine. But clearly not if you got it to work.

I've seen other servers behave strangely if a config option for ip binding is set specifically to 0.0.0.0, hence the question.

[krobertson]

It works now, shows as listening, and I have metrics in my Grafana instance now.

[Greelan]

I tried a test instance on Linux. Even with the setting removed and the remote API enabled, the port doesn't listen. So idk

[krobertson]

Not sure. I was doing some testing tonight and it was working for me.

1. Spin up new instance. Remote API defaults to disabled, so curl call will fail immediately. Turn on remote API, set password, restart.
2. After restart, curl call will connect but will hang and never return. For me, the UI was then shorting that it was listening, but I have seen it not show it as listening before too. Edit the file to remove the line and trigger restart.
3. After restart, curl call will complete and return immediately. Log message will be written to the console about unauthorized call. I can also then fire up the rcon-exporter and have it succeed.

[Greelan]

OK, my bad, I didn't set the remote API password...

I've now done further testing, the issue is as I thought might be the case at the outset - the problem only arises if the API binding is specifically set to 0.0.0.0.

If the setting is not there at all, or if the setting is set to a specific IP, or the setting value is empty (but the setting is still there), then it appears to behave properly.

I think the best approach is to leave the setting in the file, but show the setting in the UI, with a default empty value, but with the ability for a user to bind it to a specific IP if desired (eg for security).

I will make those changes.

[Greelan]

Incidentally, while looking into this, I also managed to figure out how to get it to work on Windows when running in service mode

[Greelan]

Superseded by #1834

[Greelan]

Thanks for starting the sleuthing on this!