Hello,
I am using propellor mostly with Systemd containers. I have a problem when
trying to use Ssh.knownHost
, as the host to be known is not a host, but a
container.
Is this supposed to work? Are containers accessible like the other hosts with the info system?
Also, I used short names for my containers, like:
vzWeb2 :: Systemd.Container
vzWeb2 = Systemd.debContainer "vz-web2" $ props
but now I realize that I should have used a fqdn so that properties like
Hostname.sane
could find the domain name. But changing this implies that the
container will be rebuilt, right?
Info can propagate out of containers, but then it becomes Info of the Host that the container is part of. The IsInfo type class has a propagateInfo that controls whether a value of that type propagates from container to host.
The ssh HostKeyInfo has a propagateInfo that prevents propagation. This makes sense with the current data structure because the ssh host key inside the container does not replace the host key used outside. The data structures would need to be changed in some way to support propagation. I guess HostKeyInfo could be changed to a map from hostname to what it contains now.
There would be follow-on changes needed, eg Dns.genSSHFP adds the ssh host key to a dns record, and I think it would only make sense for that to add the host's ssh key, not one for each container.
WRT the name of a systemd container, it's not a hostname, but a systemd machine name. Propellor does not currently track the hostname of a container as Info (and the Info system is actually not used for hostnames since the hostname is part of each Host). The closest thing available currently is Propellor.Info.alias which can be used in a container to add an CNAME to the Host that contains it.
Anyway, changing the name of a systemd container would indeed build a new container. I'd probably revert the current property (so it deletes the current container) and add a new property with the new name.
Would it be possible to add a
containerToHost
wrapper that takes a container and returns a host?It would be something like this:
Sure, look at how
Container
is defined:Getting a Host out of that is easy.
(Has to be put inside the Systemd module as it does not export the Container constructor.)
That's specific to systemd containers, other container systems have different data types. Here's the one from the Docker module:
If you wanted to you could even make a type class that these and other containers are part of, with a method to extract the Host. I would be happy to merge such a patch.
And yeah, this seems like a good way around wanting to get otherwise unpropigated info out of containers. It's worth noting that the Host inside a systemd Container has as its hostname the MachineName used for the container.
After thinking about it, it would be nicer if an Host could give information about several of its children, that would be a larger change, but having the wrapper would then be useless and propellor would be able to find containers automatically.
As a container is created by a property, a container Host could be included in Info of a Host. If an entry is to be propagated, then it is added as an entry of the host, else it is kept as an entry of the container.
When looking up a host, we have to search for one Host of a [Host] list, but also for any Host listed in the containersInfo of all the listed Host.
Not sure this is clear, here is a example to try to make it clearer:
This seems like a reasonable change to make, although I am not sure I understand how you'd practially use it.
But as far as how to implement it, you merely need to make an IsInfo instance for Host (or for [Host]) and then each of the container properties can add the Host of their container to the Info.
Hmm, actually, this info is already provided in another way. In Propellor.Types.Chroot there is a ChrootInfo that builds up a map from chroot location to Host, and that gets added to the Info of the host where the chroot is used.
As well as being used for regular chroots, the systemd containers are based on a chroot and so also use and provide it. Docker does not currently use it though. It has a separate DockerInfo that also happens to include the Host corresponding to the docker container.
Anyway, I guess I'm a little bit unclear on what your original problem was, it might help if you could restate it in more detail to see if this would really help with it.