I deployed this app to another org
it looks like nothing is happening… doesn’t work
@nickolay.loshkarev Did the app deployment to the new org work successfully? If you’re having trouble during a Docker build it’s usually easier to do fly deploy --local-only to make sure everything works correctly.
Once a clean deployment has happened it’s easier to work from there. You’ll need to see a fully successful deployment before you can try sshing into the machine.
Used the OSX wireguard app, can’t get past this step after connecting to the VPN:
~/D/G/concordia ❯❯❯ dig concordia-production-web.internal AAAA
; <<>> DiG 9.10.6 <<>> concordia-production-web.internal AAAA
;; global options: +cmd
;; connection timed out; no servers could be reached
Ok, disabling my vpn which I suspect was conflicting with wireguard, I can now run dig, however it looks like the app is missing an IP?
dig concordia-production-web.internal AAAA ✘ 127
; <<>> DiG 9.10.6 <<>> concordia-production-web.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9064
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;concordia-production-web.internal. IN AAAA
;; Query time: 65 msec
;; SERVER: fdaa:0:3572::3#53(fdaa:0:3572::3)
;; WHEN: Fri Nov 26 00:30:48 CET 2021
;; MSG SIZE rcvd: 62
Could you try specifying the DNS server using dig aaaa <app>.internal @fdaa:<xxx> ? That should force dig to use the internal org-specific Fly DNS server.
I get the same result:
dig aaaa concordia-production-web.internal @fdaa:0:3572::3
; <<>> DiG 9.10.6 <<>> aaaa concordia-production-web.internal @fdaa:0:3572::3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54789
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;concordia-production-web.internal. IN AAAA
;; Query time: 46 msec
;; SERVER: fdaa:0:3572::3#53(fdaa:0:3572::3)
;; WHEN: Fri Nov 26 13:23:51 CET 2021
;; MSG SIZE rcvd: 62
Hi all,
This is still a problem with another org of ours, I can’t connect via the fly cli (fly ssh console -a fly-foodbank-production-web).
Thanks,
Matt
Do you have any updates?
We haven’t figured anything out yet. As best we can tell, connecting to our wireguard gateways sometimes fails due to firewalls or other VPN services running on peoples’ machines.
I will give more detailed information:
- We have 11 apps in trusselltrust company.
- When we try to connect ANY app:
- We tried to connect from more than 3 computers from 3 countries. The same results
Error look up <app name>: list instances failed: reading length: EOF
We also use NordLayer teams (which I think also uses wireguard) but when it is disabled we still can’t connect to any of the apps
Any idea?
Can you run the same command prefixed with LOG_LEVEL=debug?
It sounds like either the agent is EOFing or the DNS request is.
Hmm, do you have many log files in ~/.fly/agent-logs/? If you can look into a few of them, there could be an error somewhere.
Usually the agent should’ve already been started when you run your command (if you’ve ran the same command before).
You can try fly agent daemon-start and then in a different terminal run your command and see what kind of output results.
Ok, that helps a lot. We should be able to resolve this in a timely fashion.
I’ve created an issue: Agent's `fetchInstance` panic · Issue #663 · superfly/flyctl · GitHub
not only with trusselltrust
with concordia too