Anaconda-devel April 2015

anaconda-devel@lists.stg.fedoraproject.org

2 participants
2 discussions

Anaconda and cloud-init
by Colin Walters 21 Jul '15

21 Jul '15

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-u… 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.

9 21

Re: Anaconda detect RHEL when reinstall a new OS
by Jack Ngo 01 Apr '15

01 Apr '15

Thanks Chris !!! And could you tell me which Anaconda files have functions to read /etc/os-release file?

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel April 2015