allow a distributed set of hostname-aliases for local servers running in a libremesh cloud

[panosnethood]

(my first issue with the help of @nicopace)

What happens

I would like to set a custom URL to a local server attached to a libremesh router; and advertise this URL for users to connect to this server from any libremesh device in the same network.

In the current situation I could do this by changing the hostname of my server device and use this as the readable URL including the default ".local" and ".mesh" extensions. For example, I could advertise the URL "myneighbourhood.local" where "myneighbourhood" is the hostname of my server.

What I expect to happen

I would like to be free to choose any type of simple or complex URL (myneighbourhood.here, my.neighbourhood.here.service, etc.) that resolve to the same server's IP and make this possible through a simple web admin interface.

(the reason I want to do this is that I want to avoid the captive portal approach and invest on marketing custom handmade URLs for accessing local services)

[nicopace]

Great feature, i like it :)

I tried to code something, but I don't have the time now to finish it... it is just a draft.

#! /bin/lua

-- This file needs to be called when
-- 1. file /etc/hosts.aliases gets updated
-- 2. a new host gets in the network

-- We also have to share /etc/hosts.aliases through alfred

-- TODO:
-- * how to remove first column from a line (awk print $2)
-- * how to run a command and get the output
-- * how to read a file line by line

function get_origin_host(line)
  run("awk '{print $1}'", line)
end

function get_alias_list(line)
  run("awk '{print $2..}'", line)
end

function register(alias, origin)
  -- add a line to /tmp/dhcp.hosts.aliases
  origin_ip = run('nslookup '..origin..' | grep Address | grep -v 127 | tail -1 |  awk \'{print $2}\'')
  run('echo '.. origin_ip .. ' ' .. alias .. '>> /tmp/dhcp.hosts.aliases')
end

run('rm /tmp/dhcp.hosts.aliases')
for line in readlines('/tmp/hosts.aliases') do
    origin_host = get_origin_host(line)
    if origin_host then
        alias_list = get_alias_list(line)
        register(alias_list, origin_host)
    end
end

[ilario]

Can't you use dnsmasq-distributed-hosts package included by default in LibreMesh?
That package propagates the content of /etc/hosts
https://github.com/libremesh/lime-packages/tree/develop/packages/dnsmasq-distributed-hosts
The problem is that you should specify a static IP there, and in some cases you'll be affected by #33

[p4u]

Long ago I wrote something like this for the QMP firmware.

https://github.com/routek/qMp/tree/testing/packages/bmx6-mdns

It uses the bmx6-sms plugin to distribute the DNS hosts among all nodes and configures dnsmasq. It has LUCI web integration, so it can be managed on the web interface.

Porting this package to libremesh should be quite easy.

[nicopace]

@ilario the idea in that script is to build on top of the dnsmasq-distributed-hosts
the thing of the aliases is that it is a match between hostname and aliases, so you add them when there is an update on the distributed-hosts table.
I was thinking in a table with:

<host1> <list of host1 aliases>
<host2> <list of host2 aliases>

and with that table and the distributed-hosts table, generate a new hosts table that has the ip of the registered hosts with all the aliases defined. That way you solve the problem of the static IPs.

@p4u is bmx6-sms working now? For what I remembered, @altergui tried it when we were in the Hackathon in Quintana and it didn't worked.

Also, would be nice for the implementation to be based on hosts and not IP addresses.

[panosnethood]

Thanks for the immediate feedback!

I wouldn't put a high priority on this issue and there are perhaps complexities that might arise through naming conflicts? Btw, do you address this issue with the existing hostnames?

[nicopace]

The current implementation is naive in the sense that it doesn't deal with this conflicts, probably because noone hasa reported issues related with this.
If this starts being a problem, maybe engineering something for it makes sense... but don't think it is relevant now.

[ilario]

related: #303 #390

this sounds like a duplicate of #132, am I wrong?

[ilario]

Sorry, it is not a duplicate.
I think I got it better now: instead of just

/etc/hosts
1.2.3.4          pad  pad.lan  pad.thisnode.info  pad.localdomain

which requires a static IP, you want also something new like

/etc/hosts.aliases
LiMe-ddeeff          pad  pad.lan  pad.thisnode.info  pad.localdomain

it is interesting.

I think that the easiest way to do this is to specify a CNAME for dnsmasq into /etc/config/dhcp as described here.

/etc/config/dhcp
config cname
	option target 'LiMe-ddeeff'
	option cname 'pad'
	option cname 'pad.lan'
	option cname 'pad.thisnode.info'
	option cname 'pad.localdomain'

should we document this solution somewhere?

[ilario]

How could we propagate these CNAME records using shared-state @G10h4ck?

[nicopace]

We could tie the aliases to the mac addresses of the devices, so we don't step onto each other.
we have been talking with @luandro and @hiurequeiroz about the importance of being able to name devices in the network.
With Luandro, it was about identifying them in the Captive Portal space.
With Hiure, was in relation to be able to give meaningful names.
Hiure mentioned that for them it would be important to use FQDNs instead of '.lan' domains, even if this could break the experience with the internet.

[ilario]

We could tie the aliases to the mac addresses of the devices, so we don't step onto each other.

I don't understand this, could you elaborate, is this for?
Is there a way to do it?
We could try: each node has an automatic alias from LiMe-ddeeff (the default hostname includes the second part of the MAC address) to the actual hostname set by the user. Then the user can point the new alias to the LiMe-ddeeff one.
But maybe I miss the scope of this.

it would be important to use FQDNs instead of '.lan' domains

Yes it is!
There's an issue asking that here: #133 (and a small and probably unrelated PR replacing .lan by .thisnode.info on #540).

[nicopace]

.thisnode.info is as annoying as .lan (actually, .lan is not annoying).
The issue is that communities don't recognize .lan or .thisnode.info (and don't remember them either), so it would be good for them to just be able to register something.com locally (breaking the relation to the internet, but making it easier for them).
It is not for the nodes themselves, but for services that could be connected on a node.

Imagine you have a raspberry pi with wikipedia in it, and that node's hostname is "internetinabox". When it gets connected to the network, it gets assigned the domain 'internetinabox.lan', and within the network it is accesible using that domain.
The idea would be to be able from the lime-app, to say "This internetinabox (you could have multiple with the same hostname, as the hostname is defined in the SD card that you might not have created) can also be called localwiki.com", and from that moment on, if you call it localwiki.com, it would be an alias to that other device.
as IP addresses change, but mac addresses are bound to the device, we could use the aliases bounded to the mac, and when it connects to the network, add the entry.
It is actually pretty easy, just keep a table with mac->names, make sure names don't exist or overlap, and when that device connects to the network, add it to the dns entries with the ip that it has been assigned, that's it!

[ilario]

.thisnode.info is as annoying as .lan (actually, .lan is not annoying).

See #540 and #541 regarding connection from mobile browsers and Chrome/Chromium.

something.com

Rather than breaking online websites, I would suggest to just use internetinabox/ or http://hostname (both of these already work on current LibreMesh code!).

Additionally to this, as suggested in lime-example here and on the website here, hostname.mesh.thewebsiteofmycommunity.org which will be a step towards #133.

a table with mac->names

The proposal I wrote above, adding an automatic alias LiMe-ddeeff -> hostname and a custom alias localwiki -> LiMe-ddeeff would do it, no?
Both of the mentioned aliases will have to be propagated via shared-state.
Do you have an alternative method to obtain this mac->names resolution?

[nicopace]

Writing http:// or the slash at the end is couter intuitive, users don't make sense of it.
If the network wants to 'break' the online experience, it is on their right to do so... maybe we can check that that domain doesn't exist in a regular basis (like a secondary use of the domain), to make sure we are not breaking it without knowing it.

the lime-xxx is for nodes, i am talking about hosts.

I explained the proposed heuristics in my previous comment:

The idea would be to be able from the lime-app, to say "This internetinabox (you could have multiple with the same hostname, as the hostname is defined in the SD card that you might not have created) can also be called localwiki.com", and from that moment on, if you call it localwiki.com, it would be an alias to that other device.
as IP addresses change, but mac addresses are bound to the device, we could use the aliases bounded to the mac, and when it connects to the network, add the entry.
It is actually pretty easy, just keep a table with mac->names, make sure names don't exist or overlap, and when that device connects to the network, add it to the dns entries with the ip that it has been assigned, that's it!

[ilario]

the lime-xxx is for nodes, i am talking about hosts.

Ah, sorry, I did not understand this.

Ok, so I have no idea about how to do this mac->names thing.

[nicopace]

Using dnsmasq-dhcp that assigns IP to a MAC:

• we keep a table of MAC-EXTRADOMAINS and when that MAC connects, we add IP-EXTRADOMAINS to a /tmp/hosts.aliases table
• we point dnsmasq to that /tmp.aliases
• we sync it using shared-state