On Thu, Dec 29, 2016 at 01:02:29PM -0200, Till Kamppeter wrote:
> 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.
There is no way to do so for IPv4 as even if you check your local
interfaces and routing tables, you can't know what subnets are hidden
behind your router.
For IPv6, you can generate a random ULA subnet which is near guaranteed
to be unique and conflict free.
Depending on exactly what you want to do, a link-local IPv6 address may
also be a better fit as it then absolutely cannot conflict with
anything.
>
> > > 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?
I sure wouldn't recommend using "dummy0". Using a differently named
device using the dummy driver would probably be fine though.
The reason to stay away from the "dummy0" name is that it's used in test
suites and other networking tools that simply call to "ip link add
dummy" and then (and that's the problem), call "ip link del dummy"
afterwards.
>
> > > 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
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
