Using the dummy0 interface for a local-only service to be broadcasted by Avahi

[Till Kamppeter]

On 12/29/2016 09:42 AM, Martin Pitt wrote:
> lxc/lxd used to hardcode an IP range like this, and it had to be dropped
> because it caused conflicts on "real" existing networks. The 10.0.0.0/8 range
> is reserved and very actively being used for local networks, including
> Canonical's own VPN, and thus prone to create conflicts. If you need to do
> something like that, I don't see a way to get away with a static IPv4 address.
> Maybe IPv6 has some clever address schema that makes conflicts improbable.
>

Is there no way to dynamically (with checking what is currently in use) 
select a small free IPv4 address space? For example in the 10.0.0.0/8 
range there are probably only some 10.X.Y.0/24 subranges used. If not, 
which IPv6 range is free for such a dummy0 interface? As it is local 
only and current Linux supports IPv6 by default it would be no problem 
to be IPv6-only. It would also need a host name as IPv6 IP addresses are 
awkward.

>> Does it cause any problems using "dummy0" for a production purpose? Is there
>> any better way? Perhaps even one which would allow me to work with
>> localhost?
>
> Making avahi work on 'lo' certainly sounds even nicer.
>

Would this be very complicated (would need upstream work on Avahi 
probably)? It is said that multicast is needed and "lo" does not support 
multicast. Is that true?

>> How should I implement this? Simply run above commands from maintainer
>> scripts of ippusbxd? Get them run when the first IPP-over-USB printer is
>> detected via UDEV? Or implementation in network-manager or so?
>
> Creating the interface in postinst is a no-go. It won't survive a reboot and it
> can't/must not be done when installing into chroots. It could ship or generate
> an ifupdown/netplan/systemd-networkd configuration file, though.

OK.

Are there packages which I could take as an example?

Another thought is an architecture extension to cups-browsed (which I 
already plan for the phone):

cups-browsed will open a socket (only root can access) to receive commands.

The client which sends the commands will also be cups-browsed.

When cups-browsed is started (as root) and there is already a 
cups-browsed running, it will send its command line options through the 
socket to the already running cups-browsed and exit (so that only one 
daemon instance is running at any time).

When cups-browsed is started (as root) and there is no cups-browsed 
already running it keeps running as the current daemon instance, also 
applying all its command line options.

On the Ubuntu phone this way the print dialog could tell to cups-browsed 
to create a print queue to a given Bonjour service (printer) which the 
user has selected, instead of cups-browsed creating automatically queues 
for all printers and waking up all these printers.

For an IPP-over-USB printer UDEV would not directly call the systemd 
service of ippusbxd and then cups-browsed be informed by a Bonjour 
broadcast from ippusbxd, but instead, UDEV calls the systemd service o 
cups-browsed with the info about the USB printer and cups-browsed calls 
ippusbxd, this way knowing the printer's data and the fact that the 
printer is there and so it also creates the queue. With the socket 
architecture UDEV does not need to take care whether cups-browsed is 
already running.

WDYT?

My favorite is clearly that UDEV creates ippusbxd and ippusbxd does a 
local-only Bonjour broadcast so that we get a complete emulation of a 
network printer. This does not require changes in cups-browsed and it 
allows the use of the printer also without cups-browsed.

So I would very much like to get the local-only Bonjour broadcast 
somehow working.

Best would be to be able to broadcast localhost. If not a dummy0 with a 
reliable way to obtain an IP address (IPv4 or IPv6) would be great.

Thanks in advance for any suggestion.

    Till