Re: [virt-tools-list] [virt-manager PATCH][v2][RFC] Introduction of cloud-init configuration in virt-install
On 6/25/19 6:17 AM, Daniel P. Berrangé wrote:
> On Mon, Jun 24, 2019 at 01:53:38PM -0400, Cole Robinson wrote:
>> On 6/24/19 12:40 PM, Daniel P. Berrangé wrote:
>>> On Mon, Jun 24, 2019 at 12:12:16PM -0400, Cole Robinson wrote:
On 6/21/19 1:18 PM, Athina Plaskasoviti wrote:
> I am sending a v2 of the patch for cloud init basic configuration during
> cloud image installation, applying previous suggestions.
>
> Fixed:
>
> -the way the installation is triggered (no_install is no longer required):
> --install is_cloud=yes ... --import
>
> -added tmpfile for the files that are being generated in the installation
> process
> (meta-data, user-data, config.iso)
>
> -changed condition in installerinject.py from label='cloud' to
> cloudinit=True
>
I did some digging into cloud-init behavior to try and get a better idea
of what the minimal viable config is, and get ideas for future work.
cloud-init behavior
===
The patch generates an .iso with volume label 'cidata' which is the
magic to make cloud-init search it for config data. cloud-init must find
a 'meta-data' and 'user-data' file in order to consider the iso a valid
data source. There isn't any requirements on the contents though. They
can both basically be empty AFAICT.
This patch is setting meta-data 'instance-id' and 'hostname' fields but
neither are required: instance-id seems to only be needed on real cloud
providers (and cloud-init fills in a 'nocloud' value for us by default).
hostname will predictably set the VM hostname but that's not something
we need to set by default. So in fact meta-data is fine to leave empty
and I think that should be our default behavior.
Every distro cloud image has some default config in
/etc/cloud/cloud.cfg. This is generated from cloud-init.git
tools/render-cloudcfg which generates cloud.cfg from
config/cloud.cfg.tmpl. Basically the only input to the template is the
distro name. For example fedora generates in in the RPM spec with simply:
python3 tools/render-cloudcfg --variant fedora >
$RPM_BUILD_ROOT/%{_sysconfdir}/cloud/cloud.cfg
cloud images seem to have this default behavior:
- ssh is enabled and running
- root account is locked
- cloud.cfg will explicitly disallow ssh to the root account, via
disable_root. Attempts to ssh to root will print an error message
pointing to the default account
- cloud.cfg will create a default account, locked, with full sudo access.
The name of the default account depends on the value passed to the
tools/render-cloudcfg script. For Fedora it's 'fedora', Ubuntu is
'ubuntu'. The openstack page here documents the common ones:
https://docs.openstack.org/image-guide/obtain-images.html
An extra note: I was wrong when I said in other threads that fedora
images have a default password, they just have a default account name
which is locked by default.
>>>
>>> That good, so I was in fact right in remembering that.
>>>
>>
>> Yeah, sorry for the confusion.
>>
virt-install cli
I think the virt-install entry point for requesting cloud-init stuff
should actually be its own top level option, like --unattended, because
we may want to add suboptions and I don't want to mix those in with
--install. So I'm thinking:
# does whatever we choose for default behavior, like --install is_cloud
virt-install --cloud-init ...
# User provides their own user-data file. Maybe for meta-data too?
virt-install --cloud-init user-data=/path/to/user-data
# Specify password for the default user. Yeah I know this isn't
# a good pattern to put a password on the cli but we could combine it
# with immediate password expiration so the user has to change it
# on first log in
virt-install --cloud-init password=FOOBAR
# Something like this to inject an ssh key? But honestly I'm not
# convinced we should go down that route and instead just make users
# manually set this themselves like they would for any other VM
virt-install --cloud-init sshkey=/path/to/key
>>>
>>> I think ssh keys is the preferred way to setup cloud images in many
>>> cases as no one sane should ever be using passwords for ssh auth these
>>> days given the continual brute force attacks they face.
>>>
>>> Saying users must set a password and then manually copy their ssh key
>>> in afterwards is crazy when cloud init supports getting the ssh key
>>> in straight away without needing passwords.
>>>
>>> I would not be surprised to even find cloud images which have
>>> explicitly disabled SSH passwords entirely leaving SSH keys as the
>>> only option. Some organizations will have a complete ban on use of
>>> passwords for
Re: [virt-tools-list] [virt-manager PATCH][v2][RFC] Introduction of cloud-init configuration in virt-install
On Mon, Jun 24, 2019 at 01:53:38PM -0400, Cole Robinson wrote:
> On 6/24/19 12:40 PM, Daniel P. Berrangé wrote:
> > On Mon, Jun 24, 2019 at 12:12:16PM -0400, Cole Robinson wrote:
> >> On 6/21/19 1:18 PM, Athina Plaskasoviti wrote:
> >>> I am sending a v2 of the patch for cloud init basic configuration during
> >>> cloud image installation, applying previous suggestions.
> >>>
> >>> Fixed:
> >>>
> >>> -the way the installation is triggered (no_install is no longer required):
> >>> --install is_cloud=yes ... --import
> >>>
> >>> -added tmpfile for the files that are being generated in the installation
> >>> process
> >>> (meta-data, user-data, config.iso)
> >>>
> >>> -changed condition in installerinject.py from label='cloud' to
> >>> cloudinit=True
> >>>
> >>
> >>
> >> I did some digging into cloud-init behavior to try and get a better idea
> >> of what the minimal viable config is, and get ideas for future work.
> >>
> >>
> >> cloud-init behavior
> >> ===
> >>
> >> The patch generates an .iso with volume label 'cidata' which is the
> >> magic to make cloud-init search it for config data. cloud-init must find
> >> a 'meta-data' and 'user-data' file in order to consider the iso a valid
> >> data source. There isn't any requirements on the contents though. They
> >> can both basically be empty AFAICT.
> >>
> >> This patch is setting meta-data 'instance-id' and 'hostname' fields but
> >> neither are required: instance-id seems to only be needed on real cloud
> >> providers (and cloud-init fills in a 'nocloud' value for us by default).
> >> hostname will predictably set the VM hostname but that's not something
> >> we need to set by default. So in fact meta-data is fine to leave empty
> >> and I think that should be our default behavior.
> >>
> >> Every distro cloud image has some default config in
> >> /etc/cloud/cloud.cfg. This is generated from cloud-init.git
> >> tools/render-cloudcfg which generates cloud.cfg from
> >> config/cloud.cfg.tmpl. Basically the only input to the template is the
> >> distro name. For example fedora generates in in the RPM spec with simply:
> >>
> >> python3 tools/render-cloudcfg --variant fedora >
> >> $RPM_BUILD_ROOT/%{_sysconfdir}/cloud/cloud.cfg
> >>
> >> cloud images seem to have this default behavior:
> >> - ssh is enabled and running
> >> - root account is locked
> >> - cloud.cfg will explicitly disallow ssh to the root account, via
> >> disable_root. Attempts to ssh to root will print an error message
> >> pointing to the default account
> >> - cloud.cfg will create a default account, locked, with full sudo access.
> >>
> >> The name of the default account depends on the value passed to the
> >> tools/render-cloudcfg script. For Fedora it's 'fedora', Ubuntu is
> >> 'ubuntu'. The openstack page here documents the common ones:
> >> https://docs.openstack.org/image-guide/obtain-images.html
> >>
> >> An extra note: I was wrong when I said in other threads that fedora
> >> images have a default password, they just have a default account name
> >> which is locked by default.
> >
> > That good, so I was in fact right in remembering that.
> >
>
> Yeah, sorry for the confusion.
>
> >> virt-install cli
> >>
> >>
> >> I think the virt-install entry point for requesting cloud-init stuff
> >> should actually be its own top level option, like --unattended, because
> >> we may want to add suboptions and I don't want to mix those in with
> >> --install. So I'm thinking:
> >>
> >> # does whatever we choose for default behavior, like --install is_cloud
> >> virt-install --cloud-init ...
> >>
> >> # User provides their own user-data file. Maybe for meta-data too?
> >> virt-install --cloud-init user-data=/path/to/user-data
> >>
> >> # Specify password for the default user. Yeah I know this isn't
> >> # a good pattern to put a password on the cli but we could combine it
> >> # with immediate password expiration so the user has to change it
> >> # on first log in
> >> virt-install --cloud-init password=FOOBAR
> >>
> >> # Something like this to inject an ssh key? But honestly I'm not
> >> # convinced we should go down that route and instead just make users
> >> # manually set this themselves like they would for any other VM
> >> virt-install --cloud-init sshkey=/path/to/key
> >
> > I think ssh keys is the preferred way to setup cloud images in many
> > cases as no one sane should ever be using passwords for ssh auth these
> > days given the continual brute force attacks they face.
> >
> > Saying users must set a password and then manually copy their ssh key
> > in afterwards is crazy when cloud init supports getting the ssh key
> > in straight away without needing passwords.
> >
> > I would not be surprised to even find cloud images which have
> > explicitly disabled SSH passwords entirely leaving SSH keys as the
> > only option. Some organizations will have a complete ban on use of
> > passwords for login purposes too.
> >
>
> My impression is
