toolshed/organising
7
1
Fork 0
Code Issues 102 Pull Requests Releases Activity

Support non-TLD resolving / IP HostNames #566

New Issue
Closed
opened 2024-02-06 00:45:11 +00:00 by basebuilder · 8 comments
basebuilder commented 2024-02-06 00:45:11 +00:00
Copy Link
Copy Source

Using an SSH config block where the Host is a local / non-TLD resolving name

Host eotl-sandbox
    HostName 49.12.102.35
    User root
    Port 22
    PubKeyAuthentication yes

Produces the following error

$ abra server add eotl-sandbox
FATA[0007] lookup eotl-sandbox on 127.0.0.53:53: server misbehaving

When I add the following entry to my /etc/hosts file

 49.12.102.35    eotl-sandbox

This allows abra to succeed in connecting to my server

user@computer:~$ abra server add eotl-sandbox
INFO[0000] successfully created /home/user/.abra/servers/eotl-sandbox 
INFO[0000] attempting to create client for eotl-sandbox 
INFO[0008] eotl-sandbox added

I assume this is because abra is doing (or not) something other CLI tools like ssh or git which can handle such non-resolving Host values and just using the IP address.

I think it would be nice for abra to handle such user configurations and not require users to add to their /etc/hosts file. The SSH documentation should reflect this constraint.

Using an SSH config block where the `Host` is a local / non-TLD resolving name ``` Host eotl-sandbox HostName 49.12.102.35 User root Port 22 PubKeyAuthentication yes ``` Produces the following error ``` $ abra server add eotl-sandbox FATA[0007] lookup eotl-sandbox on 127.0.0.53:53: server misbehaving ``` When I add the following entry to my `/etc/hosts` file ``` 49.12.102.35 eotl-sandbox ``` This allows `abra` to succeed in connecting to my server ``` user@computer:~$ abra server add eotl-sandbox INFO[0000] successfully created /home/user/.abra/servers/eotl-sandbox INFO[0000] attempting to create client for eotl-sandbox INFO[0008] eotl-sandbox added ``` I assume this is because `abra` is doing (or not) something other CLI tools like `ssh` or `git` which *can* handle such non-resolving `Host` values and just using the IP address. I think it would be nice for abra to handle such user configurations and not require users to add to their `/etc/hosts` file. The [SSH documentation](https://docs.coopcloud.tech/abra/trouble/#ssh-connection-issues) should reflect this constraint.
basebuilder added the enhancementdocumentation labels 2024-02-06 00:45:11 +00:00
decentral1se commented 2024-02-06 08:54:10 +00:00
Owner
Copy Link
Copy Source

abra runs ssh -G <hostname> under the hood and parses the output to grab the SSH details. It should have resolved this succesfully, --debug should tell you more. I think it's an issue in the server add implementation, it demands that the domain it is passed be publicly reachable: 0643df6d73/cli/server/add.go (L125-L179) It's trying to resolve eotl-sandbox. Should server add also perform a ssh -G ... trick to resolve the underlying SSH config Hostname <...> entry for eotl-sandbox?

`abra` runs `ssh -G <hostname>` under the hood and parses the output to grab the SSH details. It should have resolved this succesfully, `--debug` should tell you more. I think it's an issue in the `server add` implementation, it demands that the domain it is passed be publicly reachable: https://git.coopcloud.tech/coop-cloud/abra/src/commit/0643df6d73ae5464fa1c29e52c2c5fbb5ae97e30/cli/server/add.go#L125-L179 It's trying to resolve `eotl-sandbox`. Should `server add` also perform a `ssh -G ...` trick to resolve the underlying SSH config `Hostname <...>` entry for `eotl-sandbox`?
decentral1se added the abra label 2024-02-06 08:54:51 +00:00
basebuilder commented 2024-02-06 10:52:26 +00:00
Author
Copy Link
Copy Source

Upon running abra --debug on another server with the same SSH config block, it produces a bit more verbose feedback for debugging.

$ abra server add eotl-sites --debug
DEBU[0000] validated eotl-sites as domain argument  caller="/home/decentral1se/work/coop-cloud/abra/cli/internal/validate.go:116 ValidateDomain"
FATA[0007] lookup eotl-sites on 127.0.0.53:53: server misbehaving  caller="/home/decentral1se/work/coop-cloud/abra/cli/server/add.go:154 glob..func1" stack="/home/decentral1se/work/coop-cloud/abra/cli/server/add.go:154              glob..func1
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:524     HandleAction
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:173 Command.Run
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:405     (*App).RunAsSubcommand
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:378 Command.startApp
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:102 Command.Run
/home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:277     (*App).Run
/home/decentral1se/work/coop-cloud/abra/cli/cli.go:203                     RunApp
/home/decentral1se/work/coop-cloud/abra/cmd/abra/main.go:22                main
/usr/local/go/src/runtime/internal/atomic/types.go:194                     (*Uint32).Load
/usr/local/go/src/runtime/asm_amd64.s:1650                                 goexit"

Note: the stacktrace printed numerous \n which failed to properly render as line breaks, but i'll open a separate issue for that.

Should server add also perform a ssh -G ... trick to resolve the underlying SSH config Hostname <...> entry for eotl-sandbox?

I'm not sure what you mean here!

Upon running `abra --debug` on another server with the same SSH config block, it produces a bit more verbose feedback for debugging. ``` $ abra server add eotl-sites --debug DEBU[0000] validated eotl-sites as domain argument caller="/home/decentral1se/work/coop-cloud/abra/cli/internal/validate.go:116 ValidateDomain" FATA[0007] lookup eotl-sites on 127.0.0.53:53: server misbehaving caller="/home/decentral1se/work/coop-cloud/abra/cli/server/add.go:154 glob..func1" stack="/home/decentral1se/work/coop-cloud/abra/cli/server/add.go:154 glob..func1 /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:524 HandleAction /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:173 Command.Run /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:405 (*App).RunAsSubcommand /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:378 Command.startApp /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/command.go:102 Command.Run /home/decentral1se/go/pkg/mod/github.com/urfave/cli@v1.22.9/app.go:277 (*App).Run /home/decentral1se/work/coop-cloud/abra/cli/cli.go:203 RunApp /home/decentral1se/work/coop-cloud/abra/cmd/abra/main.go:22 main /usr/local/go/src/runtime/internal/atomic/types.go:194 (*Uint32).Load /usr/local/go/src/runtime/asm_amd64.s:1650 goexit" ``` *Note: the stacktrace printed numerous `\n` which failed to properly render as line breaks, but i'll open a separate issue for that.* > Should server add also perform a ssh -G ... trick to resolve the underlying SSH config Hostname <...> entry for eotl-sandbox? I'm not sure what you mean here!
decentral1se commented 2024-02-06 14:05:58 +00:00
Owner
Copy Link
Copy Source

Should server add also perform a ssh -G ... trick to resolve the underlying SSH config Hostname <...> entry for eotl-sandbox?

I'm not sure what you mean here!

abra server add receives eotl-sites and checks, does eotl-sites correspond to an ipv4 address? Then it fails. i'm proposing we adjust this functionality to check if eotl-sites matches a SSH config Host entry and pull the Hostname field to get the thing that does have a ipv4 address.

I think this should work seamlessly and fix this issue.

> > Should server add also perform a ssh -G ... trick to resolve the underlying SSH config Hostname <...> entry for eotl-sandbox? > > I'm not sure what you mean here! `abra server add` receives `eotl-sites` and checks, does `eotl-sites` correspond to an ipv4 address? Then it fails. i'm proposing we adjust this functionality to check if `eotl-sites` matches a SSH config `Host` entry and pull the `Hostname` field to get the thing that does have a ipv4 address. I think this should work seamlessly and fix this issue.
👍 2
decentral1se added good first issue and removed documentation labels 2024-02-06 14:06:30 +00:00
basebuilder commented 2024-02-07 14:21:45 +00:00
Author
Copy Link
Copy Source

An issue with allowing Host values like i'm using is when setting up apps like traefik the non-TLD hostname is shown, which is not ideal from DX (developer experience) perspective.

$ abra app new traefik
? Select app server: eotl-sandbox
? Specify app domain traefik.eotl-sandbox
A new traefik app has been created! Here is an overview:

+--------------+---------+----------------------+
|    SERVER    | RECIPE  |        DOMAIN        |
+--------------+---------+----------------------+
| eotl-sandbox | traefik | traefik.eotl-sandbox |
+--------------+---------+----------------------+

You can configure this app by running the following:

    abra app config traefik.eotl-sandbox

You can deploy this app by running the following:

    abra app deploy traefik.eotl-sandbox

Looking at the data added to ~/.abra/servers/eotl-sandbox/traefik.eotl-sandbox I see this:

TYPE=traefik
TIMEOUT=300
ENABLE_AUTO_UPDATE=true

DOMAIN=traefik.eotl-sandbox
....

Which i'm assuming that will cause other problems once deployed. But maybe not? So we should probably make abra save the Hostname field, which then MUST be a resolvable domain name, if I understand your comment above @decentral1se

An issue with allowing `Host` values like i'm using is when setting up apps like `traefik` the non-TLD hostname is shown, which is not ideal from DX (developer experience) perspective. ``` $ abra app new traefik ? Select app server: eotl-sandbox ? Specify app domain traefik.eotl-sandbox A new traefik app has been created! Here is an overview: +--------------+---------+----------------------+ | SERVER | RECIPE | DOMAIN | +--------------+---------+----------------------+ | eotl-sandbox | traefik | traefik.eotl-sandbox | +--------------+---------+----------------------+ You can configure this app by running the following: abra app config traefik.eotl-sandbox You can deploy this app by running the following: abra app deploy traefik.eotl-sandbox ``` Looking at the data added to `~/.abra/servers/eotl-sandbox/traefik.eotl-sandbox` I see this: ``` TYPE=traefik TIMEOUT=300 ENABLE_AUTO_UPDATE=true DOMAIN=traefik.eotl-sandbox .... ``` Which i'm assuming that will cause other problems once deployed. But maybe not? So we should probably make abra save the `Hostname` field, which then MUST be a resolvable domain name, if I understand your comment above @decentral1se
👍 2
3wordchant commented 2024-02-10 20:26:19 +00:00
Owner
Copy Link
Copy Source

Which i'm assuming that will cause other problems once deployed.

Yes, Traefik would try to generate a certificate for traefik.eotl-sandbox, will fail, so routing won't work.

Is 49.12.102.35 internet-accessible? If so then either using that as the server name, or adding a DNS record for it, would work.

If not, we're in slightly uncharted territory with LAN/VPN-only apps; supporting them (e.g. using self-signed or manually-provided certs) is possible, but I think that a lot of Co-op Cloud implementation bakes in the assumption that apps are deployed on an internet-facing server, the changing of which might be a bit of an involved project.

> Which i'm assuming that will cause other problems once deployed. Yes, Traefik would try to generate a certificate for `traefik.eotl-sandbox`, will fail, so routing won't work. Is `49.12.102.35` internet-accessible? If so then either using that as the server name, or adding a DNS record for it, would work. If not, we're in slightly uncharted territory with LAN/VPN-only apps; supporting them (e.g. using self-signed or manually-provided certs) is possible, but I think that a lot of Co-op Cloud implementation bakes in the assumption that apps are deployed on an internet-facing server, the changing of which might be a bit of an involved project.
3wordchant commented 2024-02-10 21:37:50 +00:00
Owner
Copy Link
Copy Source

Ah looks like this might be coming already in coop-cloud/abra#398?

Ah looks like this might be coming already in coop-cloud/abra#398?
decentral1se changed title from Abra: support non-TLD resolving / IP HostNames to Support non-TLD resolving / IP HostNames 2024-03-27 06:18:00 +00:00
decentral1se commented 2024-06-22 12:38:24 +00:00
Owner
Copy Link
Copy Source

coop-cloud/abra#415 allows you to abra server add foo if you have Host foo in your ~/.ssh/config. Lemme know if that's going in the right direction for this ticket for now.

https://git.coopcloud.tech/coop-cloud/abra/pulls/415 allows you to `abra server add foo` if you have `Host foo` in your `~/.ssh/config`. Lemme know if that's going in the right direction for this ticket for now.
basebuilder commented 2024-06-26 09:29:32 +00:00
Author
Copy Link
Copy Source

@decentral1se oh, I see you addressed this issue here, which is what led me to filing #570 hrm... 🤔 I think need to go through the Tutorial and test various bespoke / failure states.

I'm leaving a note here that the docs need to updated as per #537

@decentral1se oh, I see you addressed this issue here, which is what led me to filing #570 hrm... 🤔 I think need to go through the Tutorial and test various bespoke / failure states. I'm leaving a note here that the docs need to updated as per #537
❤️ 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abra
Everything to do with abra
 awaiting-feedback
Ping/pong on comms
 backups
bug
Something is not working
 build
Go build related issues
 ci/cd
Getting the robots into the mix
 community organising
Opening this thing up
 contributing
Contributors stuff
 coopcloud.tech
Our main website
 design
Design thinking required
 documentation
Let's write things together
 duplicate
This issue or pull request already exists
 enhancement
New feature
 fedi
Democratic decision making
 fedi-infra
finance
Money things
 funding
Anything related to grant funding
 good first issue
Easy start with development
 help wanted
Need some help
 installer
Installation related issues
 legal
performance
Performance related
 proposal
Large change which requires feedback & decisin making
 question
More information is needed
 security
Securing our shit
 test
Unit or integration test suite
 wontfix
This won't be fixed
No labels abra enhancement good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
3wordchant aadil (Aadil Ayub) abra-bot (Abra Bot) ammaratef45 amras (Sarma) Apfelwurm BornDeleuze Brooke carla cas (Cassowary) coopcloud cyrnel decentral1se (d1) dede devydave fauno (fauno) iexos jade (Jade Ambrose) jjsfunhouse jmakdah2 (Jackie Makdah) joe-irving (Joe Irving) kawaiipunk (KawaiiPunk) knoflook kolaente lambdabundesverband linnealovespie (April) moosemower moritz notplants oxaliq (sorrel) p4u1 pharaohgraphy (Andrew 🐦‍🔥❤️‍🔥✴️) renovate-bot (Comrade Renovate Bot) ripclap simon sixsmith (Sixsmith) stevensting trav (Trav Fryer) val (val (he/him)) yksflip
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/organising#566