coop-cloud/organising
coop-cloud
/
organising
7
0
Fork 0
Code Issues 156 Pull Requests Projects 2 Releases Activity

Support non-TLD resolving / IP HostNames #566

New Issue
Open
opened 2024-02-06 00:45:11 +00:00 by basebuilder · 6 comments
basebuilder commented 2024-02-06 00:45:11 +00:00
Member
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
Member
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
Member
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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
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
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#566
No description provided.
Delete Branch "%!s(<nil>)"

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?