Open holmanb opened 1 week ago
Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.
Why would that be considered buggy? If somebody drops in 01-mything.conf
, they want that to take highest priority and should be able to override anything provided by cloud-init.
Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.
Why would that be considered buggy?
As written, the behavior doesn't match the docs.
If somebody drops in
01-mything.conf
, they want that to take highest priority and should be able to override anything provided by cloud-init.
It just depends on how you think about it. There are tradeoffs both ways.
Cloud-init is a first-boot configuration tool. Would you rather expect the user to know what is provided on their filesystem before running cloud-init? If so, this puts more responsibility on the user to know and understand both 1) what is in their image and 2) how sshd_config works - recall that the referenced bug exists because users don't.
What if some other tool like packer decided that theirs should be 01-packer.conf
, then cloud-init would be broken for a user that tries to use cloud-init to configure an image that was built with packer.
Either the docs should be updated to match the behavior, or the behavior should be updated to match the docs.
Bug report
This was not reported as an issue in the wild, but as a hypothetical when discussion the impacts of drop in files on Launchpad.
Cloud-init uses a hard-coded drop-in file at
/etc/ssh/sshd_config.d/50-cloud-init.conf
to update the sshd configuration. Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.