Re: BSD XXI Manifesto [mDNS proposal]

From: Matthew Rezny <matthew_at_reztek.cz>
Date: Thu, 27 Feb 2014 21:20:04 +0100
> On 21 February 2014 20:59, Allan Jude <freebsd at allanjude.com> wrote:
> > I can see the remote controlled installer being especially useful for
> > 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc.
> > 
> > How would your phone find the address of the machine once it boots off
> > the USB, so you could access the web server?
> 
> "what apple does."
> 
> 
> 
> -a

The solution used by Apple is mDNS and it does work rather well. When 
installing in unstructured environments, I find it quite handy to install 
Apple's mDNSresponder as part of the basic FreeBSD configuration for no reason 
other than the ability to "ssh [hostname]" from any box to access any other 
box on the network. For completely ad-hoc networks, IPv4LL is also useful in 
conjunction with mDNS.

I think it is time that FreeBSD gains support in base for these ZeroConf 
technologies. Thus, I propose a simple plan to do so.

IPv4LL is supported by dhcpcd in NetBSD. We could use this code in our 
dhclient, or we could simply import their dhcpcd either as replacement for or 
alternate to our dhclient. The choice of approach I leave open to those more 
familiar with our dhclient. The import part is the configuration.

By default, the DHCP client should fallback to IPv4LL if no DHCP server is 
found. This should be the behavior for any interface configured for DHCP i.e. 
ifconfig_[ethif]="DHCP". There also must be a way to disable IPv4LL to enforce 
use of DHCP in environments where it should be present, for which I propose 
the notation ifconfig_[ethif]="DHCP-NOLL". If IPv4LL is in active use, the DHCP 
client should continue to periodically look for a DHCP server and obtain a 
lease without manual user intervention (which is unfortunately required on 
both OS X and Windows, leading to sub-optimal experience in cases of temporary 
unavailability of the DHCP server). When obtaining a lease later, the IPv4LL 
assigned address should still remain as an alias to prevent closure of active 
connections when DHCP becomes available.

Apple's mDNSresponder is currently available in ports. Their implementation 
uses the Apache license so I believe we should be able to import this into 
base without any license issues. The more feature-full Avahi, commonly used on 
Linux system, is also in ports but is LGPL so is not a good choice for base 
due to both size and license.

Use of mDNS should be based on the addressing scheme in use. If there are any 
static addresses, we should assume the admin knows how to reach the box, in 
which case they may enable mDNS. If the box is using purely dynamic addressing 
then we should assume the addresses may be unknown and mDNS will be useful, 
perhaps essential, for locating and accessing the machine. The admin should 
always be able to force mDNS either on or off. Therefore I suggest the rc.conf 
variable MDNS_ENABLE with possible values AUTO, YES, NO. MDNS_ENABLE="AUTO" 
should be the default and should implement the above logic; iff all interfaces 
mentioned in rc.conf are not using static addresses then equivalent to YES, 
otherwise NO. The YES and NO settings turn it on and off as expected.

The result is a fresh install that is configured for automatic addressing 
should always have some valid network address and be findable by a known name. 
For headless installation, the installer should have a timeout on the network 
configuration, after which all interfaces attempt DHCP with IPv4LL fallback and 
hostname defaults to "FreeBSD-Install". For the case of several machines all 
being installed at once, mDNS resolution should be used to check if that name 
is already in use and if so append a "-nnn" where nnn is a number to make the 
names unique. On first boot after installation, the configured hostname will be 
used if mDNS in enabled according to the above rules.

Comments?
Received on Thu Feb 27 2014 - 19:20:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:47 UTC