toolshed/organising
7
1
Fork 0
Code Issues 100 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

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
enhancement
documentation
 labels 2024-02-06 00:45:11 +00:00
decentral1se commented 2024-02-06 08:54:10 +00:00
Owner
Copy Link

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

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

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

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

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

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

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

@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
abra-gandi
Abra Gandi plugin
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
democracy
Democratic decision making
design
Design thinking required
documentation
Let's write things together
duplicate
This issue or pull request already exists
enhancement
New feature
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
kadabra
performance
Performance related
proposal
Large change which requires feedback & decisin making
question
More information is needed
recipes.coopcloud.tech
Our recipes catalogue
security
Securing our shit
test
Unit or integration test suite
wontfix
This won't be fixed
No Label
abra
enhancement
good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant aadil abra-bot ammaratef45 Apfelwurm carla cas coopcloud cyrnel decentral1se fauno iexos jade jmakdah2 joe-irving kawaiipunk knoflook kolaente lambdabundesverband linnealovespie moritz notplants p4u1 pharaohgraphy renovate-bot ripclap simon sixsmith trav val yksflip
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/organising#566
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?