Anaconda-devel May 2015

anaconda-devel@lists.stg.fedoraproject.org

8 participants
8 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

libblockdev reaches the 1.0 milestone!
by Vratislav Podzimek 16 Jun '15

16 Jun '15

A year ago, I started working on a new storage library for low-level operations with various types of block devices -- *libblockdev*. Today, I'm happy to announce that the library reached the **1.0** milestone which means that it covers all the functionality that has been stated in the initial goals and it's going to keep the API stable. Read the blog post I wrote for more information: http://blog-vpodzime.rhcloud.com/?p=61 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

2 2

Use the return of findActiveDevicesOnActionDisks() properly #119
by Murilo Opsfelder Araújo 04 Jun '15

04 Jun '15

Hello, everyone. Is this list supposed to receive fixes or pull requests for blivet as well? I just did a pull request via github: https://github.com/rhinstaller/blivet/pull/119 I verified master branch and it seems to be fixed there. I can send the fix via git-send-email if you prefer, just let me know. Thanks! -- Murilo

2 2

Anaconda code signing key
by Marek Marczykowski-Górecki 30 May '15

30 May '15

Hi all, Release tags seems to be signed with 0x0CAB491D key, by Samantha N. Bueno <sbueno+anaconda(a)redhat.com>. Where can I get public part of this key (it isn't available on key servers, nor anaconda website)? Also I can't find any confirmation that this is really key used to sign official releases. Am I missing something, or there is no such information anywhere? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

1 0

Questions about blivet tests
by Alexander Todorov 27 May '15

27 May '15

Hi guys, I'm looking into how blivet tests actually work and so far have noticed a few things which are not clear to me. Can you please provide more info: * tests/lib/testlib.sh looks like it is not used anywhere. If so maybe it can be removed ? * tests.loopbackedtestcase.LoopBackedTestCase.__init__() says > DevicelibsTestCase manages loop devices. but I don't see a class with that name. Should it be removed/updated ? * What is the StorageTestCase class ? In particular StorageTestCase is used only in action_test.py and although it claims to be a base class for storage test cases I don't see it used anywhere. Maybe we can refactor action_test.py and get rid of it? * What is the difference between LoopBackedTestCase and ImageBackedTestCase ? These two appear to be what pretty much everything else inherits from. Thanks, Alex

2 1

Kickstart install - get missing packages (when using ignoremissing)
by Harald Heigl 21 May '15

21 May '15

Hi, When I was using kickstart with fc18, I got a file /root/install.log afterwards. It seems that this has vanished, looking in anaconda sources this should be a /var/log/anaconda/packaging.log now. So far so good ... I'm using a ignoremissing flag in my package section, I could not find out where (and if) there is some indication in any log file, which packages are mssing (and therefore stepped over). In Packaging.log I didn't get this information (or at least could not find it) Can someone provide the information.. thanks, regards, Harald

1 1

Anaconda goes Python 3
by Vratislav Podzimek 18 May '15

18 May '15

Hello everybody, as many of you probably know, Anaconda has been slowly moving to Python 3 in recent months. Originally targeting Fedora 22 we postponed the switch to Fedora 23 [1], but we would like to start as soon as possible. Actually, even before Fedora 22 is released, because from our previous experience we know that it's never early enough to start with testing big changes. For these reasons, we are using a separate development branch [2] and a Copr repository [3] to create Rawhide and F22 composes that use Python 3 Anaconda and all its dependencies. Of course, the Rawhide composes suffer from the fact, that the majority of revealed issues are because of instability of Rawhide instead of Python 3 related issues so we use Fedora 22 images, to search for issues lurking somewhere in the dark waiting for Fedora 23 to be declared "GO" and then revealing themselves. To our surprise, we have troubles finding new issues in the Python 3 version of the Fedora 22 composes, so we would be really grateful if any of you guys could help us narrowing down the rest. The F22 composes are at https://m4rtink.fedorapeople.org/anaconda/images/python3/f22/ so feel free to download and test them. Please report the issues to our GH project pages [4] and if you have a patch, please submit a PR against our development branch [2]. If you want to read some more about the background and details of the Anaconda's switch to Python 3, read the blog post. [1] Thanks a lot in advance to all the early testers! We really appreciate your "test early" instead of "complain later" approach! [1] https://blog-vpodzime.rhcloud.com/?p=55 [2] https://github.com/M4rtinK/anaconda/tree/master-python3 [3] https://copr.fedoraproject.org/coprs/bkabrda/py3anaconda/ -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

1 0

unicode encoding issues
by Adam Williamson 30 Apr '15

30 Apr '15

So at the time we turned anaconda translations into unicodes I guessed we'd just be swapping one set of UnicodeDecodeErrors for another on the live images; unfortunately it seems like that's what's happening. We've already found two new UnicodeDecodeErrors in 21 Final TC1 that have been caused by turning translations into unicodes: https://bugzilla.redhat.com/show_bug.cgi?id=1217504 https://bugzilla.redhat.com/show_bug.cgi?id=1217610 and I suspect this bug is somehow caused by the same thing, though it's not as clear cut: https://bugzilla.redhat.com/show_bug.cgi?id=1217411 Looking at the first two bugs, I checked through anaconda for instances of str(e) (on the basis that 'e' is conventionally used for exceptions): there are 30. I also used a somewhat dumb grep to try and find cases where we do a %s substitution into a translation: grep -R "_(.*%" * and that gives 244 cases. One strand of this whole nightmare that we kinda lost track of is that *this doesn't always go wrong*. Sometimes, python does somehow know to use utf-8 rather than ascii. sgallagh and I got some way towards investigating this back in the F21 timeframe, but eventually we moved on to other angles. I thought it might have something to do with the setup_locale() call in welcome.py , but the anaconda script itself already calls that much earlier, so now I'm not so sure. We still have the option of the big hammer to force the 'default' encoding to be utf-8 on the lives as well as non-lives. I am (with extreme regret) reading http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=800861;… again, which I think is where we get the objections to doing that. And it sure sounds bad: =================== "If you change these, you are on your own and strange things will start to happen. The default encoding does not only affect the translation between Python and the outside world, but also all internal conversions between 8-bit strings and Unicode. Hacks like [this] are just downright wrong and will cause serious problems since Unicode objects cache their default encoded representation." "The key problem is that objects that compare equal should also hash equal. String and Unicode hashing has been constructed so that byte strings hash the same as if interpreted as latin-1. If, say, utf-8 would be the system encoding, then, for some values of S, S == unicode(S) and hash(S) != hash(unicode(S)) That, in turn, *will* break dictionaries." ==================== But then - none of this seems unique to the live image case. On non-lives, we *already use exactly the hack they say is so terrible* - it's the whole reason we have pyanaconda/sitecustomize.py: import sys # pylint: disable=no-member sys.setdefaultencoding('utf-8') I may be missing something, but so far as I can see, while we would have to implement the hack slightly differently in the live case, the different implementation isn't any *more* dangerous than the one we're already using in the non-live case. The only thing different about the live case is the use of reload(sys) vs. using the site-customize trick, and so far as I can see, none of the objections to this hack are about the use of reload(sys), they're about the use of sys.setdefaultencoding(). If I'm wrong about that, do enlighten me :) Otherwise, though, what exactly do we have to lose? I'm happy with the idea that it's the wrong thing to do. We do lots of wrong things. Some days I do 30 wrong things before breakfast. If the only other alternative is poking through the entire installer trying to trigger every goddamn translated string to find all the broken cases, let's do something wrong. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

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 May 2015