Re: [systemd-devel] sibling DNS lookup of nspawn containers
I am solving this by using libvir's network, which uses dnsmasq for network resolution. That dnsmasq should be able to resolve names of containers, because they were registered by DHCP requests. Because they share dns cache at host, there is single place where they can register to. Not directly related to systemd however. On 6/18/21 5:26 AM, Johannes Ernst wrote: > I’d like to be able to DNS lookup container b from within container a, if > both were started with systemd-nspawn as siblings of each other, and shown as > a and b in machinectl list. > > man nss-mymachines specifically notes it won’t do that. > > What’s the proper way of doing this? > > Thanks, > > > > > Johannes. > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
> On Jun 18, 2021, at 16:02, Silvio Knizek wrote: > > Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst: >> >> Thanks, Silvio, but no luck: >> >> I have host, container a and container b. >> >> In both containers, .network for host0 has LLMNR=yes in the [Network] >> section >> >> The host has LLMNR=yes in the [Resolve] section of >> /etc/systemd/resolved.conf >> >> On the host: “resolvectl query a” and “…b” works. >> >> In the containers “resolvectl query a” works only in container a, not >> in b, and vice versa. So no sibling lookup. >> >> iptables and ip6tables show default rules for all three. >> >> What am I missing? >> >> Thanks, >> >> Johannes. >> > > Are both machines in the same network zone or attached to the same > bridge interface on the host machine? Else the default NAT rules won't > allow for multicast traffic as it is done by LLMNR. > sd-nspawn uses nftables, not iptables. You should see some rules with > »nft list table ip io.systemd.nat«. > So add »--network-zone=some-fancy-name« to your systemd-nspawn > commands. Almost! With —network-zone=foo, I get sibling IPv6 addresses, but I don’t get sibling IPv4 addresses. iptables are empty, nftables seem to have nothing IP-version specific in them. I know basically nothing about LLMNR. This is supposed to apply to both v4 and v6, right? On the other hand, I may not need IPv4 for my use case. Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst: > > Thanks, Silvio, but no luck: > > I have host, container a and container b. > > In both containers, .network for host0 has LLMNR=yes in the [Network] > section > > The host has LLMNR=yes in the [Resolve] section of > /etc/systemd/resolved.conf > > On the host: “resolvectl query a” and “…b” works. > > In the containers “resolvectl query a” works only in container a, not > in b, and vice versa. So no sibling lookup. > > iptables and ip6tables show default rules for all three. > > What am I missing? > > Thanks, > > Johannes. > Hi Johannes, Are both machines in the same network zone or attached to the same bridge interface on the host machine? Else the default NAT rules won't allow for multicast traffic as it is done by LLMNR. sd-nspawn uses nftables, not iptables. You should see some rules with »nft list table ip io.systemd.nat«. So add »--network-zone=some-fancy-name« to your systemd-nspawn commands. === man: systemd.nspawn === Using --network-zone= is hence in most cases fully automatic and sufficient to connect multiple local containers in a joined broadcast domain to the host, with further connectivity to the external network. === === BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
> On Jun 18, 2021, at 2:02, Silvio Knizek wrote: > > Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst: >> I’d like to be able to DNS lookup container b from within container a, if >> both were started with systemd-nspawn as siblings of each other, and shown >> as a and b in machinectl list. >> >> man nss-mymachines specifically notes it won’t do that. >> >> What’s the proper way of doing this? >> >> Thanks, > Hi Johannes, > > you would enable LinkLocalMulticastNameResolution (LLMNR) in the > containers systemd-networkd. > See man:networkd.conf for further information. Thanks, Silvio, but no luck: I have host, container a and container b. In both containers, .network for host0 has LLMNR=yes in the [Network] section The host has LLMNR=yes in the [Resolve] section of /etc/systemd/resolved.conf On the host: “resolvectl query a” and “…b” works. In the containers “resolvectl query a” works only in container a, not in b, and vice versa. So no sibling lookup. iptables and ip6tables show default rules for all three. What am I missing? Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst: > I’d like to be able to DNS lookup container b from within container a, if > both were started with systemd-nspawn as siblings of each other, and shown as > a and b in machinectl list. > > man nss-mymachines specifically notes it won’t do that. > > What’s the proper way of doing this? > > Thanks, Hi Johannes, you would enable LinkLocalMulticastNameResolution (LLMNR) in the containers systemd-networkd. See man:networkd.conf for further information. BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
