Kurt wore me down, and you should now be able to use _local_ip.internal to get your local IP address, in addition to /etc/hosts or ip a or whatever.
6 Likes
I FIND THIS BAFFLING BUT OK.
2 Likes
I don’t really understand how you fetch the IP address?
Let’s take an example, I’ve myapp as an application name.
So for fetching the local IP I’ve to do a DNS lookup on _local_ip.myapp.internal?
I tried but it didn’t work.
It’d be _local_ip.internal
1 Like
I found the correct DNS server, it’s fdaa::3.
Previous message:
Summary
From the fly VM that I need to do that DNS request?
It doesn’t seem like it’s returning something:
/ # dig AAAA _local_ip.internal
; <<>> DiG 9.16.6 <<>> AAAA _local_ip.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5054
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_local_ip.internal. IN AAAA
;; AUTHORITY SECTION:
. 86357 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021021301 1800 900 604800 86400
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Feb 13 20:48:46 UTC 2021
;; MSG SIZE rcvd: 122
EDIT: I tried with the DNS server specified in the docs but no success:
/ # dig @fdaa:0:33::3 AAAA _local_ip.internal +tcp
;; Connection to fdaa:0:33::3#53(fdaa:0:33::3) for _local_ip.internal failed: timed out.
;; Connection to fdaa:0:33::3#53(fdaa:0:33::3) for _local_ip.internal failed: timed out.
; <<>> DiG 9.16.6 <<>> @fdaa:0:33::3 AAAA _local_ip.internal +tcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to fdaa:0:33::3#53(fdaa:0:33::3) for _local_ip.internal failed: timed out.
/ # dig @fdaa:0:33::3 AAAA _local_ip.internal
; <<>> DiG 9.16.6 <<>> @fdaa:0:33::3 AAAA _local_ip.internal
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Yeah, it looked like before you were trying to do the lookup over a WireGuard gateway, to the DNS server we give WireGuard connections. _local_ip only gives the addresses for Fly app instances. It is a weird special name, and I added it begrudgingly.
Let me say this right now: we do the minimal DNS required to make private networking work, but we’re not committed to ungainly minimalism, and if there’s DNS stuff y’all would like us to do, just ask.
thankfully I found this post, I was previously using Alpine for my Elixir application, but switched to Debian, however /etc/hosts is mounted as 700 by fly.io so grepping that to get my local ip no longer worked (as it was grepping it as nobody), luckily I was able to get my local ip by resolving this host
getent hosts _local_ip.internal | cut -d' ' -f1
Is there a reason that /etc/hosts is only mounted as 700 instead of 744?
Sounds like it can / should be 744, will discuss with the team why it’s this way.
@Jerome any thoughts on this?
@flyio3 It looks like it’s created with 644 as its permissions. Should be readable by every user, only writable by root.
Does your image change these permissions at some point? We leave the permissions as-is.
Possibly if there was no /etc/hosts, it might create the file with stricter permissions. I’m looking into it.
1 Like
@flyio3 We’re updating our code to create resolv.conf as 644, so nobody should now be able to resolve .internal addresses.
1 Like
I was using bullseye slim built with podman, no changes made anywhere (i.e: I copied the app build to a folder), possibly a podman issue?
Possibly. The more the process deviates from just using standard Docker the harder it becomes to debug. Podman should be fine, I think it guarantees compatibility (there are a couple of small interoperability bugs with I think are being addressed). But yeah, if something isn’t working, trying it once in the standard flow is a good signal as to where the issue might be.
It’s likely more an issue with the “slim” nature of the image. It probably removed /etc/hosts entirely and we had to create it from scratch. Something that doesn’t happen too often.
This was a bug on our end, we weren’t setting the correct permissions if we had to create the file.
1 Like
I’m experiencing this issue again, /etc/hosts are being mounted as 700.
-rwx------ 1 root root 271 Jan 18 02:36 /etc/hosts
This is with /etc/hosts existing previously also