[systemd-devel] systemd-nspawn --template: should it delete /etc/hostname?

2015-05-01 Thread Kai Krakow
Hello!

If I create a new machine by cloning using systemd-nspawn --template, should 
it remove etc/hostname? It already creates a new machine-id etc, and the 
hostname should probably not be set for a new container in this case, 
regardless of whether the template is a real template or a cloned machine.

Thoughts?

I suppose something similar should be possible for statically configured IP 
addresses as an option, tho I wouldn't know how to implement that because 
systemd-networkd doesn't expect that information at well defined location.

-- 
Replies to list only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-nspawn --template: should it delete /etc/hostname?

2015-05-03 Thread Lennart Poettering
On Fri, 01.05.15 19:38, Kai Krakow (hurikha...@gmail.com) wrote:

> Hello!
> 
> If I create a new machine by cloning using systemd-nspawn --template, should 
> it remove etc/hostname? It already creates a new machine-id etc, and the 
> hostname should probably not be set for a new container in this case, 
> regardless of whether the template is a real template or a cloned machine.

Well, we don't touch the images really at all, we also leave
/etc/machine-id in place and everything else that could identify the
machine (such as MAC or IP configuration, ...)

People should not misunderstand --template (or --ephemeral or
machinectl clone) as something that would change identity of a system
really, and I think it might be problematic if we started to do so
since we could never implement this fully, because there will always
be more and more to patch and we shouldnt have that much app-specific
patching code in nspawn.

> Thoughts?
> 
> I suppose something similar should be possible for statically configured IP 
> addresses as an option, tho I wouldn't know how to implement that because 
> systemd-networkd doesn't expect that information at well defined location.

For the case of the hostname things are relatively easy: if you do not
set the hostname from inside the container, then the hostname will be
inherited from the container manager, and be the same as the container
name you pick with "-M" (or whatever is derived automatically from -D
if you do not use -M). Hence, if you simply remove /etc/hostname from
your container, then using --template/--ephemeral/"machinectl clone"
will work the best possible way: the image you create with that will
always use the new container name you use as host name...

Now for MAC addresses things are similar automatic: the MAC addresses
are hashed from the container name, hence should change automatically
when you run the container under a new name. 

IP addresses assigned via DHCP networkd's dhcp server should probably
pick the address using a hash of the client's MAC address or so, so
that the IP address stays normally stable, but changes when the
instance is cloned under a new name. (currently the dhcp server
assigns the client addresses randomly though). 

And the machine ID should support a mode that works similar. i.e. a
way how we can boot with a stable id that changes automatically when
cloned. Maybe generate it from the container manager as hash of the
host's machine id and the container name, or so.

I added TODO list items for the latter two.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel