peterldowns / localias

custom local domain aliases for local dev servers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

subdomains not redirecting

drewAdorno opened this issue · comments

Hi,
I was able to configure and successfully use localias in was wsl env (ubuntu 22.04). Everything works fine when i use my SLD (xxxx.test) but if I add my subdomain to my yaml file (admin.xxxx.test), it doesn't redirect properly

If you have any recommendations to get subdomains working, I'd greatly appreciate it

Drew

Interesting, sorry for the trouble. I'll attempt to reproduce the problem in my WSL setup and see if I can figure out what's going on. I haven't heard of this issue before and I don't have any idea why this would be broken. I cannot reproduce this issue on my macOS machine.

In case it helps me figure out the issue, can you tell me:

  • What version of localias you're using (localias version) and ideally how you installed it (brew, downloaded a binary, etc.)
  • The output from localias debug config --print
  • Any logs shown on startup when you run localias run and then attempt to visit the domain in question
  • What exactly you mean by "it doesn't redirect properly" — what behavior do you see? Does the request time out? Does it redirect somewhere else? If possible, please let me know if this behavior is the same when making requests from within WSL and from within Windows. You can run curl -v -I https://admin.xxx.test inside WSL, not sure what you'd do from within Windows — maybe just the browser network inspector?

Localias version: 2.1.0+commit.46b0a47 (brew installed it)

#
#       alias: port
#
# for example,
#
#   bareTLD: 9003 # serves over https and http
#   implicitly_secure.test: 9002 # serves over https and http
#   https://explicit_secure.test: 9000 # serves over https and http
#   http://explicit_insecure.test: 9001 # serves over http only
#
admin.woventeams.test: 3000
replacing existing daemon on pid 241780
2024/05/28 14:24:06.427 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2024/05/28 14:24:06.427 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000730e80"}
2024/05/28 14:24:06.431 INFO    http.auto_https server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv1", "https_port": 443}
2024/05/28 14:24:06.431 INFO    http.auto_https enabling automatic HTTP->HTTPS redirects        {"server_name": "srv1"}
2024/05/28 14:24:06.440 INFO    pki.ca.local    root certificate is already trusted by system   {"path": "storage:pki/authorities/local/root.crt"}
2024/05/28 14:24:06.440 WARN    tls     unable to get instance ID; storage clean stamps will be incomplete      {"error": "open /home/drew/.local/share/caddy/instance.uuid: no such file or directory"}
2024/05/28 14:24:06.440 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2024/05/28 14:24:06.440 INFO    failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
2024/05/28 14:24:06.440 INFO    http.log        server running  {"name": "srv1", "protocols": ["h1", "h2", "h3"]}
2024/05/28 14:24:06.440 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2024/05/28 14:24:06.440 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2024/05/28 14:24:06.440 INFO    http    enabling automatic TLS certificate management   {"domains": ["admin.woventeams.test"]}
2024/05/28 14:24:06.442 WARN    tls     storage cleaning happened too recently; skipping for now        {"storage": "FileStorage:/home/drew/.local/state/localias/caddy", "instance": "15f532af-2653-4368-8a17-2081e6ae9a52", "try_again": "2024/05/29 14:24:06.442", "try_again_in": 86399.99999977}
2024/05/28 14:24:06.442 INFO    tls     finished cleaning storage units

I'm adding an image of me running the curl command on both the wsl side and windows (wsl in purple)
image

When I dont include the subdomain to localias and run my server, I'm able to go to that domain in my browser and see it open my dev server correctly, but when i do include my subdomain and try to go to that route on my browser I just get site cannot be reached and see no indiciation of it doing anything in the logs of localias run. If I use my port it does redirect properly however. (admin.*****.com:3000)

Appreciate your help on this issue!

Thank you so much for the details! I have a few clarifying questions but this is definitely enough that I should be able to more easily reproduce. I will look at this problem this week and follow up when I've done that.

Some clarifying questions:

When I dont include the subdomain to localias and run my server, I'm able to go to that domain in my browser and see it open my dev server correctly, but when i do include my subdomain and try to go to that route on my browser I just get site cannot be reached and see no indiciation of it doing anything in the logs of localias run. If I use my port it does redirect properly however. (admin.*****.com:3000)

Can you please explicitly type out which domains work in your browser (including the explicit port, if any) and which don't? Here is what I think the result is based on what you wrote, but please confirm/correct for me: when making requests from your browser in Windows,

  • https://admin.woventeams.test results in "site cannot be reached" error
  • http://admin.woventeams.test:3000 results in successful response from your dev server running in wsl on port 3000

Second, can you share the contents of your /etc/hosts files from both Ubuntu and Windows? I want to make sure there aren't other hosts rules interfering with the rules that Localias is adding, and I want to confirm that Localias is adding those rules for you correctly. Based on the config file you shared, we should expect to see a single rule (in windows the IP will be different):

127.0.0.1	admin.woventeams.test	#{"controller":"localias"}
  • C:\System32\drivers\etc\hosts in Windows — you can open this with notepad
  • /etc/hosts in Ubuntu — you can cat this

Finally, can you confirm that you've installed the certs into Windows with localias debug cert --install, and that when you run localias status you see a daemon running?

You are correct in that admin.woventeams.test:3000 results in a successful response from my dev server while admin.woventeams.test does not.

cat /etc/hosts

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1       localhost
127.0.1.1       Drew-PC.        Drew-PC

10.0.0.162      host.docker.internal
10.0.0.162      gateway.docker.internal
127.0.0.1       admin.woventeams.dev

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1       admin.woventeams.test   #{"controller":"localias"}

** Windows host file**

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
# Added by Docker Desktop
10.0.0.162 host.docker.internal
10.0.0.162 gateway.docker.internal
# Woven
127.0.0.1 admin.woventeams.test
# End of section
172.29.225.92	admin.woventeams.test	#{"controller":"localias"}

Note: I manually added in the 127.0.0.1 admin.woventeams.test prior to discovering localias and not sure if its doing anything

I did install the certs into windows successfully based on the documentation and do note that before doing so I got certificate errors and after I did not, this was before I initially reached out. However when running your steps, I do get back a directory for the cert
/home/drew/.local/state/localias/caddy/pki/authorities/local/root.crt

But when I run localias status I get daemon is not running

Innnnnnnnnnteresting, two things to try:

Note: I manually added in the 127.0.0.1 admin.woventeams.test prior to discovering localias and not sure if its doing anything

Please try removing this entry; it may direct requests to your windows-side network instead of your WSL network, intermittently, potentially causing the bugs we're seeing (because there is nothing on the windows side to respond, or something to respond with the wrong information.)

But when I run localias status I get daemon is not running

Can you try localias run instead of localias start and see if your requests work while it's running that way? What logs does it print, and does the program keep running or does it quit? My guess is that since localias start followed by localias status shows that the daemon is not running, it's probably crashing for some reason, and I would expect you to see that crash when you do localias run.

Apologies for the super late response here, it seems that the extra line in the windows host file was the problem the entire time. Thanks again for the debugging help, using this tool saved me from having to buy a mac!

@drewAdorno I'm so glad that was the issue and you were able to get it resolved! Thank you again for your patience and helpful responses while we debugged together. I hope you keep enjoying localias, if you ever have any thoughts or suggestions or bugs please let me know.