|author||Joey Hess||2017-10-04 13:10:59 -0400|
|committer||Joey Hess||2017-10-04 13:10:59 -0400|
avoid propagating non-alias DNS info from container to host
* When the ipv4 and ipv6 properties are used with a container, avoid propagating the address out to the host. * DnsInfo has been replaced with DnsInfoPropagated and DnsInfoUnpropagated. (API change) * Code that used fromDnsInfo . fromInfo changes to use getDnsInfo. * addDNS takes an additional Bool parameter to control whether the DNS info should propagate out of containers. (API change) This commit was sponsored by Trenton Cronholm on Patreon.
Diffstat (limited to 'doc/forum/Using_ip_address_in_a_container')
1 files changed, 32 insertions, 0 deletions
diff --git a/doc/forum/Using_ip_address_in_a_container/comment_1_f14578affbfdb771a74a30f535b9e9a0._comment b/doc/forum/Using_ip_address_in_a_container/comment_1_f14578affbfdb771a74a30f535b9e9a0._comment
new file mode 100644
@@ -0,0 +1,32 @@
+ subject="""comment 1"""
+I'd also like to use systemd-nspawn with its own network in the container.
+Have not worked through all the necessary config, which seems fairly
+complicated on the systemd side. Examples of how to do that with propellor
+would be great to have!
+(There's a partial example in the haddock for
+Systemd.publish, which uses networkd to auto-configure a private network,
+but IIRC that is missing some routing/masqerading to let the
+container access the internet.)
+As for `alias` and `ipv4` properties, when used in a container, their info
+does get propagated out to the info of the host as of propellor 4.8.1.
+That was done because it's sometimes useful to have an `alias` be part
+of a container's configuration and get the DNS server automatically
+configured with that alias pointing at the host(s) that have the container.
+I agree it does not make sense for `ipv4`/`ipv6` used in a container
+to propagate out. I've changed propellor to not do that any longer,
+and allow controlling whether any given DNS info should propagate or not.
+As for the hostname, it's not currently part of the Info system,
+and so there's no risk of a container overriding its Host's name.
+Things like Hostname.sane that look at the hostname will see the parent
+host's name. Hostname.setTo should work in a container to give it
+its own name. (At some point it would probably be worth moving hostnames
+into Info to avoid the extra complication..)