Fedora right now has three products, and I'm going to ignore Workstation for this post. Server: Download boot.iso, configure via kickstart Cloud: Download qcow2 image, configure via cloud-init Anaconda is used in generating the Cloud image (see my previous post about ImageFactory), with the resulting issues there. But note the kickstart functionality is not accessible to the Cloud user. Instead, cloud-init is the pervasive way to configure cloud images. But if you look at this, cloud-init actually has a lot of great features that *also* make sense on bare metal. A good example is ssh key provisioning. Look at the "ssh-authorized-keys" entry in the YAML here: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#including-users-and-groups Kickstart has no declarative syntax to update the ssh keys for a user. And this lack of support is actually reflected in the Anaconda UI/framework logic - it won't let you proceed unless you have a root password or an administrative user (with a password) But ssh keys are *more* secure than passwords, and we should strongly encourage their use. In the RHEL6 era, people of course did it in %post, but there was a common trap around SELinux labeling: https://www.redhat.com/archives/rhelv6-beta-list/2010-November/msg00005.html Basically I'd like to discuss pulling in cloud-init into the installation environment. Ideally, I could chain kickstart -> cloud-config. Say a new toplevel verb like this in %kickstart: %cloud-config users: - name: walters ssh-authorized-keys: ssh-rsa ... %end The simplest way to implement this would be to simply dump the file into /var/tmp on the target system, and then have the cloud-init program execute it on boot. But to fix the issue of anaconda being unaware of ssh keys as a valid way to log in would require parsing it in the install environment and looking at the users stanza. At a high level, I think this is a good architectural match; both programs are Python 2, etc. (cloud-init is GPLv3 though...hmm) cloud-init also has a lot of popularity due to its cross-distribution nature. Finally, the reason I bring this up is because I work on Project Atomic, and as part of that one of the features we're investigating is a PXE-to-Live scenario. For that, cloud-init is a perfect match, because it's designed to configure an already existing system (versus kickstart which is designed to be processed for an installation). Laying the foundation with regular bare metal support for cloud-init would help this as well. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
