[Bug]: Problems with xyOps not listening on default port 5522

[arminus]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Since I still have performa running on my host (and like to keep it running until I've fully migrated), I mapped then xyops container internal port 5522 to 5542. But it seems xySat has an issue with that.

For one, the generated "Add Server" command looks like this

curl -s "http://xyops.mydomain.com:5522/api/app/satellite/install?t=bc9fb6a26887e3a968a7cf2d3a7845c11de7c69b68b6121772e65c77082cb301" | sudo sh

which I need to change to https://xyops.mydomain.com since I expose this through an https proxy only.

Then I run the command, but the server doesn't appear, so I checked /opt/xyops/satellite/config.json which says

{
        "port": 5522,
        "secure": false,
...
        "hosts": [
                "xyops.myomain.com"
        ],
...

which cannot work?

So I change the port to 5542 in the xysat config.json, restart the xyops service and the sat server kind of appears in the servers list, but when I check config.json again, it reverts to port 5522 and the sat server shows up as offline (maybe after another restart, not quite sure).

Operating System

Docker version 29.2.1, build a5c7197

Node.js Version

image version

xyOps Version

v1.0.31

Server Setup

Single Conductor

Storage Setup

Default (SQLite + Filesystem)

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[jhuckaby]

So sorry for the confusion over this. If you want to change the port on which the xyOps web server listens, you need to change it in three key places:

• The base_app_url
• The WebServer.port
• The satellite.config.port

All three of these are configured on the conductor server, not on your remote servers.

I think the confusion here is over the satellite.config configuration object, because this lives on the primary conductor server, and it is automatically distributed out to all remote satellite servers each time they connect. It overwrites all values in the remote server config files (this is by design, so you can configure your fleet of servers from one central place).

So in effect, the /opt/xyops/satellite/config.json config file on your remote servers should not be edited directly (except in special cases). That file is largely "managed" by the primary conductor server.

[miku2365]

I've encountered a similar problem. It wasn't a listening issue, but rather a configuration file being overwritten. I have two services on a local network and one in a remote location. Since none of them are accessible from the public internet, I need to configure different hostnames and ports for the servers. For the local network, I use IP:5522, and for the remote network, I use Cloudflared tunnel forwarding. My current workaround is to remove the hostname and port values from satellite.config so that the settings I defined on the server don't get overwritten.

[arminus]

So sorry for the confusion over this. If you want to change the port on which the xyOps web server listens, you need to change it in three key places:

* The [base_app_url](https://docs.xyops.io/#Docs/config/base_app_url)

* The [WebServer.port](https://docs.xyops.io/#Docs/config/webserver-port)

hold on... Modifying WebServer.port changes the actual port the conductor is listening on. Which in a docker deployment is kind of not needed. Like I said initially, I mapped the xyops container internal port 5522 to 5542 (note that I have an https proxy which maps https://xyops.mydomain.com to localhost:5542)

    ports:
      - "5542:5522"

However, for the sake of sticking with your steps, I changed that (and also adjusted the docker port mapping to 5542:5542)

* The [satellite.config.port](https://docs.xyops.io/#Docs/config/satellite-config)

All three of these are configured on the conductor server, not on your remote servers.

After having changed that and having restarted the server, the client install command now reads:

curl -s "http://xyops.mydomain.com:5542/api/app/satellite/install?t=xxxxx" | sudo sh

i.e. it doesn't seem to pick up

"base_app_url": "https://xyops.mydomain.com"

Which is IMHO a bug.

However, when I now change
/opt/xyops/satellite/config.json port to 5542 (yeah, I shouldn't...) and restart the xysat service, it appears in the conductor.

I think the confusion here is over the satellite.config configuration object, because this lives on the primary conductor server, and it is automatically distributed out to all remote satellite servers each time they connect. It overwrites all values in the remote server config files (this is by design, so you can configure your fleet of servers from one central place).

So in effect, the /opt/xyops/satellite/config.json config file on your remote servers should not be edited directly (except in special cases). That file is largely "managed" by the primary conductor server.

And here's the problem. I repeated the installation for another xysat client (the first was on the docker host of the conductor), patched the install command to use base_app_url, still, /opt/xyops/satellite/config.json shows

{
        "port": 5542,
        "secure": false,
....
        "hosts": [
                "xyops.mydomain.com"
        ],
...

And it is able to connect, but it does that through http which is a no-go, i.e. I want it to connect through the base_app_url and my proxy and not expose port 5542 to the outside at all eventually.

[miku2365]

After having changed that and having restarted the server, the client install command now reads:修改并重启服务器后，客户端安装命令现在显示：

curl -s "http://xyops.mydomain.com:5542/api/app/satellite/install?t=xxxxx" | sudo sh

i.e. it doesn't seem to pick up也就是说，它似乎没有接收到信号。

"base_app_url": "https://xyops.mydomain.com"

Regarding this reference #14

[arminus]

Thanks, I wasn't aware of that, so the central takeaway for me from that issue is: "Please understand that setting this means that ALL of your satellite servers will connect ONLY to the hostname / port provided in satellite.config.host and satellite.config.port. "

Which implies that I need to keep WebServer.port, or rather WebServer.https_port open to be secure open and not expect to get the xysat connection through my standard proxy (because this would interfere with xyops potential array of possible conductors.

In which case, the connection URL the add server command spits out is also ok and not a bug like I assumed.

Then the next problem arises because the xysat installation doesn't work with the self signed certs i.e. I need https://github.com/jhuckaby/pixl-server-web#lets-encrypt--acme-tls-certificates - I typically try to avoid the hassle of maintaining certs per service by having the certs managed on the proxy only, but oh well...

So I guess in a nutshell, "this is not a bug but a feature" ...

[jhuckaby]

Oh lord, I completely forgot about #14 -- thank you @miku2365 -- I've been so busy with other things that I gave out some bad advice earlier. So sorry for the wild goose chase, @arminus, and thank you for sticking with us.

Yeah, self-signed certs are a problem, mainly because of the "bootstrap" process for adding new servers. The curl command doesn't accept self-signed certs unless you add a CLI flag, but inside the bootstrap shell script that runs there are additional curl commands. Adding --insecure to all of them would be tricky (especially since this also needs to work on Windows, which uses Powershell's Invoke-WebRequest instead of curl).

If all of your servers are Linux / macOS, Maybe I can introduce a new global configuration property, something like satellite.insecure_install, and if set to true it will "insecureize" all the bootstrap install curl commands and sub-commands. I am not exactly sure what this will entail, but I am willing to explore it.

Let me know if that is something you'd be interested in.

[arminus]

Let me know if that is something you'd be interested in.

I just added a -k to the downloaded installer's curl command and I don't have that many clients so this "hack" works for me.

What still bothers me a bit is that I need to keep 5523 open on the conductor's server, but I guess that can't be helped, so no real problem as long as I manage the firewall myself. I know though that in corporate environments, it's sometimes a challenge to get the network admins top open non default ports. But I see the point with multiple conductors, so, just saying ;-)

Thanks again for your help!

[jhuckaby]

I just added a -k to the downloaded installer's curl command and I don't have that many clients so this "hack" works for me.

Are.... you.... sure... that works? The initial curl installer downloads and executes a shell script that has nested (separate) curl commands that also have to run. One downloads the tarball and the other downloads an initial config file. What I was trying to explain above, is that those two "nested" (supplemental) curl commands from inside the shell script will NOT inherit the --insecure flag (they cannot, as they have no idea the outer command had it added).

That's why I was suggesting introducing a new future feature, i.e. a theoretical satellite.insecure_install config flag, which would "insecureize" ALL the inner nested supplemental curl commands.

[arminus]

Are.... you.... sure... that works?

Yes, I manged to set up a 2nd client that way. I ran the "outer" curl with -k and just downloaded the file to install.sh then patched it to use -k in its embedded curl call.

I mean I don't object a theoretical satellite.insecure_install option for sure, just saying I seem to have a workaround.

[jhuckaby]

...downloaded the file to install.sh then patched it to use -k in its embedded curl call.

Ohhhhh, sorry, I didn't realize. Thank you for clarifying.

Okay, I'll add the feature to my TODO list, but won't rush it.

Thanks!

[github-actions]

This issue has had no activity for 7 days, so it is being marked stale. If there is still no follow-up in 3 more days, it will be closed automatically.