Default core.host_url value is set to localhost instead of usable IP.

[SimonCahill]

Describe the bug
Default container install contains incorrect config.

core.host_url=http://localhost

is the default configuration; this is generally incorrect and should be set to the IP(v4) of the actual host.

This is especially irritating when installing onto a Proxmox server and giving the container a specific IP address.

To Reproduce
Steps to reproduce the behavior:

1. Create a container template using the latest or debian container
2. Launch container
3. Try to connect and be greeted with this log:

❯ curl -vvv 10.0.88.189
00:59:25.897424 [0-x] == Info: [READ] client_reset, clear readers
00:59:25.898068 [0-0] == Info: [SETUP] added
00:59:25.898208 [0-0] == Info:   Trying 10.0.88.189:80...
00:59:25.898398 [0-0] == Info: [SETUP] Curl_conn_connect(block=0) -> 0, done=0
00:59:25.899543 [0-0] == Info: connect to 10.0.88.189 port 80 from 10.0.88.193 port 46878 failed: Connection refused
00:59:25.899856 [0-0] == Info: Failed to connect to 10.0.88.189 port 80 after 2 ms: Could not connect to server
00:59:25.900150 [0-0] == Info: [SETUP] Curl_conn_connect(block=0) -> 7, done=0
00:59:25.900335 [0-0] == Info: [SETUP] Curl_conn_connect(), filter returned 7
00:59:25.900529 [0-0] == Info: [WRITE] [OUT] done
00:59:25.900660 [0-0] == Info: closing connection #0
curl: (7) Failed to connect to 10.0.88.189 port 80 after 2 ms: Could not connect to server

The teddycloud container will launch successfully, but no connection can be made to the web UI.

Setting the value to the IP of the container fixes the issue entirely:

curl -vvv 10.0.88.189
01:12:22.093174 [0-x] == Info: [READ] client_reset, clear readers
01:12:22.093316 [0-0] == Info: [SETUP] added
01:12:22.093477 [0-0] == Info:   Trying 10.0.88.189:80...
01:12:22.093677 [0-0] == Info: [SETUP] Curl_conn_connect(block=0) -> 0, done=0
01:12:22.094581 [0-0] == Info: [SETUP] Curl_conn_connect(block=0) -> 0, done=1
01:12:22.094742 [0-0] == Info: Connected to 10.0.88.189 (10.0.88.189) port 80
01:12:22.094824 [0-0] == Info: using HTTP/1.x
01:12:22.094897 [0-0] => Send header, 75 bytes (0x4b)
0000: GET / HTTP/1.1
0010: Host: 10.0.88.189
0023: User-Agent: curl/8.14.1
003c: Accept: */*
0049:
01:12:22.095276 [0-0] == Info: Request completely sent off
01:12:22.095903 [0-0] <= Recv header, 32 bytes (0x20)
0000: HTTP/1.1 301 Moved Permanently
01:12:22.096080 [0-0] == Info: [WRITE] [OUT] wrote 32 header bytes -> 32
01:12:22.096221 [0-0] == Info: [WRITE] [PAUSE] writing 32/32 bytes of type c -> 0
01:12:22.096404 [0-0] == Info: [WRITE] download_write header(type=c, blen=32) -> 0
01:12:22.096604 [0-0] == Info: [WRITE] client_write(type=c, len=32) -> 0
01:12:22.096775 [0-0] <= Recv header, 16 bytes (0x10)
0000: Location: /web
01:12:22.096884 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=16) -> 0
01:12:22.097066 [0-0] == Info: [WRITE] [OUT] wrote 16 header bytes -> 16
01:12:22.097219 [0-0] == Info: [WRITE] [PAUSE] writing 16/16 bytes of type 4 -> 0
01:12:22.097382 [0-0] == Info: [WRITE] download_write header(type=4, blen=16) -> 0
01:12:22.097579 [0-0] == Info: [WRITE] client_write(type=4, len=16) -> 0
01:12:22.097750 [0-0] <= Recv header, 19 bytes (0x13)
0000: Connection: close
01:12:22.097931 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=19) -> 0
01:12:22.098087 [0-0] == Info: [WRITE] [OUT] wrote 19 header bytes -> 19
01:12:22.098207 [0-0] == Info: [WRITE] [PAUSE] writing 19/19 bytes of type 4 -> 0
01:12:22.098343 [0-0] == Info: [WRITE] download_write header(type=4, blen=19) -> 0
01:12:22.098527 [0-0] == Info: [WRITE] client_write(type=4, len=19) -> 0
01:12:22.098699 [0-0] <= Recv header, 22 bytes (0x16)
0000: Accept-Ranges: bytes
01:12:22.098866 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=22) -> 0
01:12:22.099038 [0-0] == Info: [WRITE] [OUT] wrote 22 header bytes -> 22
01:12:22.099191 [0-0] == Info: [WRITE] [PAUSE] writing 22/22 bytes of type 4 -> 0
01:12:22.099352 [0-0] == Info: [WRITE] download_write header(type=4, blen=22) -> 0
01:12:22.099523 [0-0] == Info: [WRITE] client_write(type=4, len=22) -> 0
01:12:22.099666 [0-0] <= Recv header, 16 bytes (0x10)
0000: Content-Type:
01:12:22.099835 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=16) -> 0
01:12:22.099965 [0-0] == Info: [WRITE] [OUT] wrote 16 header bytes -> 16
01:12:22.100171 [0-0] == Info: [WRITE] [PAUSE] writing 16/16 bytes of type 4 -> 0
01:12:22.100341 [0-0] == Info: [WRITE] download_write header(type=4, blen=16) -> 0
01:12:22.100552 [0-0] == Info: [WRITE] client_write(type=4, len=16) -> 0
01:12:22.100665 [0-0] <= Recv header, 2 bytes (0x2)
0000:
01:12:22.100820 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=2) -> 0
01:12:22.100981 [0-0] == Info: [WRITE] [OUT] wrote 2 header bytes -> 2
01:12:22.101130 [0-0] == Info: [WRITE] [PAUSE] writing 2/2 bytes of type 4 -> 0
01:12:22.101352 [0-0] == Info: [WRITE] download_write header(type=4, blen=2) -> 0
01:12:22.101519 [0-0] == Info: [WRITE] client_write(type=4, len=2) -> 0
01:12:22.101708 [0-0] == Info: [WRITE] xfer_write_resp(len=107, eos=0) -> 0
01:12:22.101849 [0-0] <= Recv data, 0 bytes (0x0)
01:12:22.101983 [0-0] == Info: [WRITE] [PAUSE] writing 0/0 bytes of type 81 -> 0
01:12:22.102167 [0-0] == Info: [WRITE] download_write body(type=81, blen=0) -> 0
01:12:22.102407 [0-0] == Info: [WRITE] client_write(type=81, len=0) -> 0
01:12:22.102588 [0-0] == Info: [WRITE] xfer_write_resp(len=0, eos=1) -> 0
01:12:22.102747 [0-0] == Info: [WRITE] [OUT] done
01:12:22.102878 [0-0] == Info: [READ] client_reset, clear readers
01:12:22.103052 [0-0] == Info: shutting down connection #0

Expected behavior
I expect a containerised application to contain sane defaults.

[SciLor]

Hey Simon,
thank you for your detailed report.

The core.host_url has nothing to do with your connection problems. It is only used for MQTT / HASS URLs for the images.
https://github.com/search?q=repo%3Atoniebox-reverse-engineering%2Fteddycloud%20core.host_url&type=code

Setting a sane default is impossible from the server side, as teddyCloud usually runs in a container within dockers networking. The 172.* IP wouldn't be reachable.
It may be solvable by using the frontend. But then, it depends on, how the user sets up his teddyCloud and how he connects to it.

[SimonCahill]

This is an interesting fact, seeming as setting the core.host_url property fixed the connectivity issue within the container.

Are you sure this is only used for MQTT? From my own experience using MQTT for various jobs, MQTT hosts are generally prefixed with mqtt:// before the host, unless you're using MQTT via Websockets?

It may be solvable by using the frontend. But then, it depends on, how the user sets up his teddyCloud and how he connects to it.

The latest build uses the teddycloud_web repo, if I'm not mistaken?

A possible fix would be to use environment variables - however I'm generally not savvy with Docker and containers - I avoid them where possible.

Any further assistance would be appreciated.

[SciLor]

Yes, as said, it is only used for the URLs of the images in mqtt.

The teddyCloud Web repo is for the frontend part, this one for the backend.