Reissue IP addr (or other vars) to GEA if cloning machines?

[emcdee]

It would appear that in my cloned machines (Win 10 systems), the GEA is up and running but not working.
In fact have stopped, pruned, and recreated the docker container that came with the clone… but still no.
Like the new GEA shows online (new key and all), and even deployed a workflow to it, but always times out erroneously.

Specifically, getting ‘cannot resolve host’ in debug panel of the exact GEA I’m interested in (web preview). Weird because original container / machine is running fine as well (no errors on that debug panel), and the command to create these docker containers entails env vars (host name is not hard coded).

Hence curious on whether IP addr (or other vars) need to be updated, as if they aren’t encompassed in the docker container command?

Error:

And oiginal docker command which had worked great on original machine:

docker run -d -e "LOCAL_HOST=$(hostname).local"  \
--restart always --network host --name losant-edge-agent  \
-v /var/lib/losant-edge-agent/data:/data  \
-v /var/lib/losant-edge-agent/config.toml:/etc/losant/losant-edge-agent-config.toml  \
losant/edge-agent

[Dylan_Schuster]

So is it just the SQL Node that is throwing an error? You said the GEA “always times out erroneously” but the screenshot does not appear to be a timeout error.

Can you paste a screenshot of your SQL Node config (taking care to redact any sensitive information) as well as the payload you are resolving any templates against?

You should be able to see the value of that LOCAL_HOST environment variable in the debug log; is its value what you are expecting it to be?

I also see that you are not mapping any ports in your startup command; I would expect that would be necessary but apparently not?

[emcdee]

Hm yea I believe SQL node throwing err, that’s the screenshot (debug panel)

Timeout means the webpage call (to the experience workflow, to the edge workflow (SQL) - so yea figure it’s stopping here). And yea LOCAL_HOST is alright (computer name).

No change to SQL node (the machine was cloned, and the GEA along with it, but workflow stayed the same):

Else dunno on ports, honestly going with ‘simple / default is best’ so not specifying vars unless I have to.

[emcdee]

FYI I have another app (not Losant) accessing the same SQL (just as GEA is) on that same cloned machine; so I don’t think SQL server is the issue (same SQL user/pass used for both GEA and the local app).

[Dylan_Schuster]

I was going to say “are you sure the SQL server is up and running” but it sounds like it is.

This is hard for me to debug as it is likely an issue with the configuration on your cloned machine; does this Stack Overflow post provide any clues as to what may be the issue?

Connect to SQL Server in local machine (host) from docker using host.docker.internal

As in, is the port opened to Docker? Are TCP/IP connections and remote connections enabled in the SQL server?

Does host.docker.internal work as a host name, or localhost, or the machine’s network IP address?

[emcdee]

Hm, not sure where host.docker.internal goes?
Coz it doesn’t echo in Ubuntu…

Anyway I tried this -

But still get this (after restarting Ubuntu)-

Otherwise I do get this on ‘ping localhost’:
(Noting 127.0.0.1 is also the SQL server address, standard address I’m using for other local app)

So feels like some networking thing w/ docker…
And yes same firewall and all open, SQL on port 1433, etc.

[emcdee]

I wonder, can I make this automatic?

[emcdee]

Ok so think we narrowed down to:
Need to change/update hostname of cloned machine

As described -

Change hostname of an existing container

Like I could manually specify in the run command:

--hostname $(hostname)

But how actually update the hostname??

[Dylan_Schuster]

I think it would be much easier to leave the hostname the same and to just change the reference within your workflow node. Assuming it’s an environment variable declared on boot of the agent, and the name of the variable is the same in all cases, that translates very well into reading that from a payload value in one edge workflow that you deploy to your whole fleet.

[emcdee]

Yes that hasn’t changed,
using "LOCAL_HOST=$(hostname).local" \ --network host in docker run command as best practice I believe …

That starting point aside (I did a whole PC reset to avoid any cloning issues), and for some reason I’m getting a different (but similar?) err now -

I think one continued point of curiosity is why aren’t all these commands below working, even in a ‘working’ GEA (directly as Ubuntu cmds)? And forgive if obvious I’ve been staring at this a long time…

• user@LAPTOP:~$ curl http://LAPTOP.local
  → returns blank (nothing)

• user@LAPTOP:~$ ping LAPTOP
  → looks good (below), notice ip addr is local machine 127.0.0.1

PING LAPTOP. (127.0.1.1) 56(84) bytes of data.
64 bytes from LAPTOP. (127.0.1.1): icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from LAPTOP. (127.0.1.1): icmp_seq=3 ttl=64 time=0.075 ms
…
— LAPTOP. ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5190ms

• `user@LAPTOP:~$ ping LAPTOP.local
  → can’t ping … noting 172.30.96.1 is ip addr of virtual (wsl) adapter

PING LAPTOP (172.30.96.1) 56(84) bytes of data.
^C
— LAPTOP ping statistics —
6 packets transmitted, 0 received, 100% packet loss, time 5192ms

[emcdee]

I suspect it was changing PC name after installing SQL

And back to cloning, I suspect it’s the Ubuntu step that adds the ip addr entry in PC registry (coz still blank on wsl install)

[Dylan_Schuster]

We’re trying this on our end - setting up MSSQL on the host, WSL, Docker, and the GEA on a Windows machine and verifying that we can talk to MSSQL using a SQL Node. We’re not attempting anything around cloning the machine at this time. I will follow up when I have more info.

[emcdee]

Ok thanks for looking

[Dylan_Schuster]

So we’ve been able to get this working on our Windows machine by doing the following …

1. Start the container with the --network host flag. While Docker’s documentation says the flag has no effect on Windows, it does appear to work in WSL (which is essentially Linux as you know).
2. Take your computer’s hostname out of the equation and change the SQL Node’s configuration to use host.docker.internal and port 1433. More info.

See attached screenshot.

[Dylan_Schuster]

Couple more bits …

• Apparently the --network host flag is unnecessary and has no effect after all.
• MSSQL must be enabled for remote connections. For us it was by default.
• MSSQL must be enabled for TPC/IP connections. For us this was not enabled by default.
• Windows Firewall must allow connections from WSL. For us this was allowed by default.

[emcdee]

Ok yea got those done (confirmed) too,

Now what version of Docker did you pull down?

curl -fsSL https://get.docker.com -o get-docker.sh

[Dylan_Schuster]

We used Docker Desktop, which is required to use host.docker.internal. Based on your Windows / WSL setup, we recommend you do the same.

[emcdee]

Err no good to use wsl / Ubuntu?

[Brandon_Cannaday]

Docker Desktop for Windows installs into WSL / Ubuntu. Once installed, the docker commands will automatically be available in the WSL / Ubuntu terminal.

Docker Desktop is what adds the helper host.docker.internal hostname, so definitely recommended for this use case.

[emcdee]

Ok interesting,

Any reason why it changed from {{agentEnvironment.LOCAL_HOST}} to host.docker.internal?

And if docker desktop is needed I guess that’ll do, but do you know why? Because doing so (running docker engine + desktop) takes up 2x the space and perhaps double resource use too.
Whereas why not use docker (even target a version) thru Ubuntu and theoretically be done with it? Anyway the docker run cmds are all done in Ubuntu, and still have to do ‘all that’ work to get wsl, Ubuntu running as prerequisites.