Anaconda-devel January 2015

anaconda-devel@lists.stg.fedoraproject.org

25 participants
19 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

We should make blivet.size.py a separate package
by Anne Mulhern 20 Feb '15

20 Feb '15

Hi all, It turns out that anaconda uses Size() objects for a number of things that are only tangentially related to storage. There's a bunch of stuff in packaging, for instance, which does not seem that nearly related to storage but which does use Size(). It seems cruel to make anaconda restrict its usage of this handy Size class to only storage related stuff, but inconsistent, if it is a storage package, not to. Clearly, a separate package is the solution and might prove to be generally useful. Other changes that should be made at the same time are: 1) Disentangle parsing user input from Size() construction. This would change the interface, so that: * Size("10 MiB") would have to be changed to Size(10, size.MiB) * Size("%d KiB" % int(val[i])) would have to be changed to Size(int(val[i]), size.KiB) Note: All other things being equal, the above changes would result in a speed up of about 4x, when the argument is changed from a string to a tuple. * Size(user_input) would have to be changed to Size(parseSpec(user_input)) 2) Use int instead of Decimal for underlying representation and use delegation, not extension. int is unbounded, and appropriate as Size() stores exact number of bytes. The implementation will still use Decimal within humanReadable() and convertTo(), where Decimal proves its worth. This would make (1) a bit easier, for it would be possible to override object.__init__() instead of overriding Decimal.__new__() which is awkward because of the context parameter which Decimal.__new__ requires. Benefits to the change would be a 5 to 10x reduction in size of Size() objects and a 10 to 15x speedup in constructing Size() objects and in arithmetic operations. The only arithmetic operation I profiled was addition; I'm generalizing here. There would be no change to the interface, and the changes in the class are actually very simple. 3) Make arithmetic operations more type-sensible. Currently, our code does a bunch of not so good things, like: >>> divmod(Size("3 MiB"), Size("2 MiB")) (Decimal('1'), Decimal('1048576')) The semantics of divmod should agree with the, in this situation, correct semantics of mod, which gives the type of the remainder as a Size. >>> Size("3 MiB") % Size("2 MiB") Size('1 MiB') 2 multiplied by itself 3 bytes times should raise an exception or something, but it doesn't: >>> 2 ** Size("3 B") Decimal('8') The number of times 2 MiB can be subtracted from 3 MiB is not 1 bytes times, it's 1 times, but: >>> Size("3 MiB") / Size("2 MiB") Size('1 B') and so forth. In theory, our code should not be asking for really nonsensical operations like 2 ** Size("1 MiB"), and I think it is not. It can be made configurable how extreme the reaction is to a requested operation that makes no sense. There are certain operations that are mathematically sensible, but which the implementation would not, because it could not, support. One such operation is 2 MiB * 2 KiB which yields 4096 KiB^^2. We have no ability to represent that, so it would be better to raise a TypeError when called upon to calculate it rather than return, as now, Size('4 GiB'). I believe that computations in this category are not ones that we actually do in Blivet or Anaconda or should expect to. The context in which they could arise is in, e.g., statistics, where in order to calculate the standard deviation, one has to square the values. But if we start doing statistics on some MiB's we should not be using Size class at all, we can use pint, which is good for that, but bad for our regular purposes. NOTE: Most of the _implementation_ is already done, leaving just packaging and a few places in anaconda where it will require a little thought to decide if parseSpec is called for. Please give me your opinions. Maybe we can discuss this in installer meeting. - mulhern

8 12

How does anaconda handle the biosboot partition ?
by Alexander Todorov 02 Feb '15

02 Feb '15

Hi guys, RHEL QE has been doing some testing using customized partitioning in our kickstart and we've always explicitly defined the use of a biosboot partition if RHEL >= 7. I don't recall seeing any problems related to the biosboot partition. Now Dan Callaghan from Beaker devel has a question related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1108393#c15 > > Alexander Todorov mentioned that his team unconditionally defines the biosboot partition on RHELs which support it, and that works (even on BIOS systems with disks <2TB). Need to investigate further. Is Anaconda ignoring the defined biosboot partition when it's not applicable (MBR)? If so can Beaker also just unconditionally define it on distros that support it? > > > (In reply to Dan Callaghan from comment #14) > > Or another possibility... the presence of the biosboot partition triggers Anaconda to use GPT where it would otherwise have used MBR (in which case, adding it unconditionally would be bad, since it has an unintended influence on the test scenario)... Can you provide more insight into this? It may be the difference between one line or a thousand lines patch for Beaker. Thanks, Alex

2 1

connecting github to the email lists
by David Shea 31 Jan '15

31 Jan '15

For commits: do what this page says. https://help.github.com/articles/receiving-email-notifications-for-pushes-t… In the Approved header, put the list password, which will (in theory) tell mailman to approve the email. This may depend on the mailman configuration. For patches/pull requests, I don't see a way to do it without a github account. We can create a github account with anaconda-patches set as the notification address, and on the mailing list side we need to accept messages from notifications(a)github.com. Here are some things I found that will be annoying: - github sets the reply-to address to something that will reply into the pull request thread, but it will use the original recipient as the message author. In other words, all replies to notifications sent to anaconda-patches will appear as being written by anaconda-patches, and since anaconda-patches is the sender these messages won't be forwarded back to the list. - There is more than one way to comment on a commit or lines of a commit, and not all of them generate notifications. If, in the pull request, you go to the commits tab and comment on some stuff there, those comments are part of the repository being pulled from, not the main repo being watched, so no notification is sent. If you go to "Files changed" and comment on stuff there, notifications are sent. - You can edit comments via the web interface. Edits do not create notification emails.

4 7

Upstream project repository changes: lorax, isomd5sum, livecd-tools
by Brian C. Lane 30 Jan '15

30 Jan '15

I have just completed moving these projects over to github, all new commits should go through there. https://github.com/rhinstaller/lorax https://github.com/rhinstaller/isomd5sum https://github.com/rhinstaller/livecd-tools -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

3 3

Updating the Anaconda "how to contribute" and "review process documents"
by Martin Kolman 29 Jan '15

29 Jan '15

We have recently started to update and extend our documentation for Anaconda contributors - not only for those sending patches, but for people who want to help with testing, translations, etc. The main "how to contribute" guide has been created here: https://fedoraproject.org/wiki/Anaconda/Contribute We have also updated the review process article, which explains how the patch review for proposed Anaconda changes looks like. Also due to the impending move of the Anaconda source code repository to Github a new section about sending pull requests has been added: https://fedoraproject.org/wiki/Anaconda/ReviewProcess Also the article about how to use the updates image mechanism for debugging Anaconda changes has been updated and more content was added, especially concerning the advanced options of the makeupdates script: https://fedoraproject.org/wiki/Anaconda/Updates Please note that we are not yet done with the updates and additions, so the best you can do is to bookmark these pages and look for new content from time to time (or use the "watch page" wiki functionality ;-) ). Kind Regards Martin Kolman

1 0

Disable SELinux by default.
by Đặng Thanh Phúc 28 Jan '15

28 Jan '15

Hi everyone, I'm starting to develop anaconda. I'd like to disable SElinux by default. According to my understanding, anaconda defined SELINUX_DEFAULT = 1. It is "enforcing" mode. If it right, what value i can change to disable selinux ? SELINUX_DEFAULT = 0 or -1. I tried to change SELINUX_DEFAULT to 0 and -1 to test. I used PXE and NFS to test. But it's failed. It's still enforcing mode. Could everyone please give me an idea to do that ? Thanks everyone. Best Regards, Bruce Dang -- Bruce Dang Gmail : dtphuc1302(a)gmail.com

1 0

About sshd(8) remote root login feature & Anaconda UI support
by P J P 27 Jan '15

27 Jan '15

Hello all, Please see: -> https://www.piratepad.ca/p/ssh-remoterootloigin -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no -> https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html This is a F22 feature that proposes to restrict remote 'root' access via ssh, by setting the "PermitRootLogin=without-password" option in default sshd(8) configuration. - As result, one would require at least one non-root user account to be created at install time. - And if a user does not want to create non-root account, a provision needs to be made to enable remote root access by setting 'PermitRootLogin=Yes' in the sshd(8) configuration. - Additionally, one might wish to add the ssh keys at installation time. It seems similar function is provided by cloud-init tool. Though many agree that it is a useful change and usage of ssh keys for authentication offers more long term benefits, major contention is that this change would break user experience and should have support in Anaconda UI to enable remote root access. Could a CheckBox be added to the Anaconda installation workflow, which would be used to enable remote root access, by setting PermitRootLogin='Yes'. Something like: === sshd(8) server has restricted remote 'root' access via ssh keys authentication only. This could potentially lock you out of the system, unless you have created a non-root account or have configured ssh keys for authentication. Would you like to enable remote 'root' access via password authentication? [] Enable remote root access via password. === This is one of the suggestion, the feature page lists few more workflow changes that are deemed necessary. I'm not sure how easy or difficult it is to implement these changes. Could someone please help us with the implementation of these changes? If so, should RFE bugs be filed for these changes?? I'm willing to help in any way I could. If you have any comments or suggestions about the proposed feature and/or accompanying workflow changes, they are most welcome. Thank you. --- Regards -Prasad http://feedmug.com

10 21

Initial Setup and python-meh moved to GitHub
by Martin Kolman 26 Jan '15

26 Jan '15

Hi, the source code repositories for the Initial Setup and python-meh projects have been moved to GitHub: https://github.com/rhinstaller/initial-setup https://github.com/rhinstaller/python-meh The legacy Firstboot tool, which is no longer in active development, has not been moved and its source code repository remains on fedorahosted: https://git.fedorahosted.org/git/firstboot.git Best Wishes Martin Kolman

1 0

About sshd(8) remote root login feature & Anaconda UI support
by P J P 15 Jan '15

15 Jan '15

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel January 2015