Anaconda-devel February 2015

anaconda-devel@lists.stg.fedoraproject.org

20 participants
12 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

github to email
by David Shea 19 Feb '15

19 Feb '15

Github pull request stuff is now forwarded to anaconda-patches, using this thing: https://github.com/dashea/github-email-hook I can move it to rhinstaller if we feel like. The code is running on OpenShift, somewhere in the Red Hat public cloud. The web hook and associated cron job will email the list with: - Patches in new and resynchronized (push --force, or just regular push with new commits) pull requests - comments on pull requests - comments on the diff for a pull request ("Files changed" tab on the web) - comments on the commits in the pull request made in the repo being merged into (the ones listed for the pull request via the API, and hence the ones linked to in the patch emails) - comments on the commits in the pull request made in the repo being merged from (the ones listed on the web, and the ones that need that cron job) - line-based comments on commits (both kinds), though there's no context provided because that turned out to be harder than I wanted to deal with If you find another way to comment on stuff, please let me know, and also I hate you.

3 3

kickstart install keeps asking questions
by Artem Bityutskiy 18 Feb '15

18 Feb '15

Hi, could someone on this list please help me with the following problem. My objective is to deploy Fedora using the PXE boot + KS method in a fully-automated manner. IOW, I do not want Anaconda to ask any questions. Now, I did manage to make it work, but I use a work-around which I would like to get rid of. So, the target machine is a server with multiple NICs. Only one network interface is involved into the installation process, and I want anaconda to completely ignore other interfaces. The problem is: anaconda keeps asking questions about network configuration: ================================================================================ 3) [x] Software selection ...pub/mirrors/fedora/linux/releas (Custom software selected) es/20/Fedora/x86_64/os/) 5) [!] Network configuration 4) [x] Installation Destination (Connecting...) (Warning checking storage confi 7) [x] User creation guration) (No user will be created) 6) [x] Root password (Password is set.) Please make your choice from above ['q' to quit | 'c' to continue | 'r' to refresh]: ================================================================================ So anaconda wants me to help it configuring the network. And the funny thing is that anaconda already knows all the information it needs. I can see it when I press 'c': ================================================================================ Network configuration Wired (enp0s25) connected IPv4 Address: 192.168.100.18 Netmask: 255.255.255.252 Gateway: 192.168.100.17 DNS: 192.168.100.17 Hostname: xyz 1) Set hostname 2) Configure device enp0s25 Please make your choice from above ['q' to quit | 'c' to continue | 'r' to refresh]: r ================================================================================ How do I make anaconda to just stop asking me and continue? Now, here is the WORKING configuration - anaconda does not ask anything with this 1. pxelinux.cfg kernel /path/kernel append initrd=/path/initramfs.img ifname=netif:00:1e:67:ac:44:f5 ip=netif:dhcp inst.ks=http://path/ks.cfg inst.sshd updates=http://path/upgrade.img nogeoloc nomodeset 2. KS network --device=netif --bootproto=static --ip=192.168.100.18 --netmask=255.255.255.252 --gateway=192.168.100.17 --nameserver 192.168.100.17 --hostname=myhost No questions asked, all works as expected. But this is far not ideal because: 1. I do not want to specify mac address in pxelinux.cfg, because I want to have the same config file for many hosts with different MACs 2. I do not want to specify IP addresses in KS file for the same reasons. Besides, DHCP works. How do I make better? I googled a lot, found various hints about using all kinds of ksdvice=bootif IPAPPEND 2 - no help. Keeps asking the question. And I tried really many combinations. What I want is to make Anaconda just use the same interface and network settings as were configured by the PXE boot process, and stop asking questions. Just as an example, I tried something like this with no success: 1. pxelinux.cfg kernel /path/kernel append initrd=/path/initramfs.img ksdevice=bootif inst.ks=http://path/ks.cfg inst.sshd updates=http://path/upgrade.img nogeoloc nomodeset 2. KS network --device=bootif --bootproto=dhcp --hostname=myhost (also tried to remove --bootproto, and --device, no success) Could anyone in this list please help me with this problem? Thank you!

1 0

Pungi on GitHub
by Ed I 16 Feb '15

16 Feb '15

Hi folks, I was just at https://github.com/rhinstaller and I did not see pungi there. Are you planning to work out of GitHub on pungi too?

2 1

os-release missing from the Fedora 22 squashfs?
by Fabian Deutsch 13 Feb '15

13 Feb '15

Hey, I'm booting the F22 squashfs using: -kernel vmlinuz \ -initrd initrd.img \ -append "console=ttyS0 inst.ks=http://10.0.2.2:51738/kickstarts/rootfs.ks inst.stage2=http://10.0.2.2:51738/ quiet cmdline inst.virtiolog " kernel, initrd, and squashfs are from the F22 dirs: https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-22&arch=x86_64 and when I boot, I get: ================================================== Starting Switch Root... [FAILED] Failed to start Switch Root. See "systemctl status initrd-switch-root.service" for details. Warning: /dev/root does not exist Generating "/run/initramfs/rdsosreport.txt" [ 20.420170] blk_update_request: I/O error, dev fd0, sector 0 [ 20.492165] blk_update_request: I/O error, dev fd0, sector 0 Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report. :/# systemctl status initrd-switch-root.service -l ● initrd-switch-root.service - Switch Root Loaded: loaded (/usr/lib/systemd/system/initrd-switch-root.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2015-02-12 18:22:18 UTC; 32s ago Process: 1108 ExecStart=/usr/bin/systemctl --no-block --force switch-root /sysroot (code=exited, status=1/FAILURE) Main PID: 1108 (code=exited, status=1/FAILURE) Feb 12 18:22:18 localhost systemctl[1108]: Failed to switch root: Specified switch root path /sysroot does not seem to be an OS tree. os-release file is missing. Feb 12 18:22:18 localhost systemd[1]: initrd-switch-root.service: main process exited, code=exited, status=1/FAILURE Feb 12 18:22:18 localhost systemd[1]: Failed to start Switch Root. Feb 12 18:22:18 localhost systemd[1]: Unit initrd-switch-root.service entered failed state. Feb 12 18:22:18 localhost systemd[1]: initrd-switch-root.service failed. ================================================== I also see that os-release is not in the squashfs and I can not make much of the "new?" initrd: $ lsinitrd data/images/initrd.img Image: data/images/initrd.img: 43M ======================================================================== with dracut modules: ======================================================================== drwxr-xr-x 3 root root 0 Feb 11 17:51 . -rw-r--r-- 1 root root 2 Feb 11 17:51 early_cpio drwxr-xr-x 3 root root 0 Feb 11 17:51 kernel drwxr-xr-x 3 root root 0 Feb 11 17:51 kernel/x86 drwxr-xr-x 2 root root 0 Feb 11 17:51 kernel/x86/microcode -rw-r--r-- 1 root root 25506 Feb 11 17:51 kernel/x86/microcode/AuthenticAMD.bin ======================================================================== My question is now: Are the images intended to boot anaconda? Or am I doing something wrong? Is something broken? Greetings fabian

2 2

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
by David Cantrell 12 Feb '15

12 Feb '15

On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote: > On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote: > > On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote: > > > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote: > > > > > > > I think the main point is the one nirik made; I don't think the devs > > > > agree with your assessment of how significant this is. It's a minor > > > > inconvenience; you just have to come up with a password that passes > > > > the check, or use a kickstart. So I don't think they agree that it > > > > needs a full-blown security audit and FESCo review or whatever, > > > > because they don't think it's really that huge of a change in > > > > behaviour. > > > > > > Having to come up with a password that passes the check is not 'a minor > > > inconvenience'. Given how capricious libpwquality is about scoring > > > (there have been some examples in this thread, there are more in > > > gnome-initial-setup bugs), it is next to impossible. > > > > > > This discussion has been pretty heated, but I agree with there being > > > some aspect of 'collective punishment' here: just because _some_ systems > > > get installed with sshd enabled, all users who install the Workstation > > > have to spend a couple of frustrating minutes trying to find a password > > > that gets them past this hurdle. > > > > > > If this change stays, I anticipate the Workstation WG asking for a way > > > to the workstation installer not enforce this. I know the anaconda folks > > > are not eager to add variations like this, but that is exactly what we > > > need: If you want to enforce product-specific policy in the installer, > > > it needs to be a product-specific installer. > > > > You're assuming before asking. With the structure of the installer now, we > > can look at changes like taking the password aspect and making it > > product-specific controllable by a number of different methods. Our > > historic aim to end variant specifics in the installer was because the old > > code (and variants) lacked a way to assign owners to those product > > specifics, which meant that requests of the installer to be product specific > > meant we were asked to be the owners of those specifics. > > Let me ask now, then: can we make the change to reject 'weak' passwords > specific to only those products that enable sshd by default, please ? [adding anaconda-devel-list to CC] >From a technical standpoint, I see this being possible. Conditionalize it on sshd being enabled or not. That's not really variant-specific and just a system condition we could work around. I'm putting this on anaconda-devel-list for further discussion. bcl, others? What are your thoughts on this request? -- David Cantrell <dcantrell(a)redhat.com> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT

6 6

2015-02-12 (TOMORROW): Anaconda / DNF Test Day!
by Adam Williamson 11 Feb '15

11 Feb '15

We're having the first #fedora Test Day of the #fedora22 cycle tomorrow, 2015-02-12! The anaconda (installer) team wants to get some testing on the switch from yum to DNF for repository and package handling. There are several ways you can join in, from running planned test cases to coming up with kickstarts to aid in automated testing. If you've got a bit of time tomorrow, please come to Freenode #fedora- test-day and join us! More details on the Test Day page: https://fedoraproject.org/wiki/Test_Day:2015-02-12_Anaconda_DNF and in my blog post: https://www.happyassassin.net/2015/02/10/fedora-22-anacondadnf-test-day-com… Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Heads up - Anaconda 22.17 will enforce 'good' passwords
by Chris Murphy 10 Feb '15

10 Feb '15

On Thu, Feb 5, 2015 at 2:03 PM, Máirín Duffy <duffy(a)redhat.com> wrote: > > > On 02/05/2015 12:36 PM, Brian C. Lane wrote: >> >> Next to impossible? Really? I've find it easy to come up with passwords >> that work. We even report libpwquality's reason for any failures. > > > 'my name is' (good) (10 chars) > 'bacon4eva!' (strong) (10 chars) > 'hamncheese.' (strong) (10 chars) > 'GoPatriots!' (strong) (11 chars) > 'hey, you!' (good) (8 chars) > '8crayons.' (good) (9 chars) > 'latte2015' (good) (9 chars) > > > I tried making up some passwords in Anaconda in F21, which uses the same > library. I had a difficult time making a password rated less than good when > I made passwords that were 10 characters with only lowercase letters and no > spaces or special characters. Add spaces, a punctuation mark, or caps and it > is instantly easier. I had a much harder time making a new acceptable > password for my Twitter account. I don't see how that's possible. Twitter has a clear guideline enabling the building of a minimum acceptable password such that I can do it in a single attempt. Anaconda doesn't define anything at all. It just complaints "too weak" but doesn't state what I need to do to fix it. Make it not weak? Duh, but that's not helpful. I enter in a 6 character password, I'm told it's too weak and that it doesn't contain at least 7 characters. I enter in 7 characters, and I'm told merely that it's too weak. OK the minimum is apparently 7 characters yet I can't find a single 7 character combination to appease the weak rating. Is it 8? I've already spent more time creating passwords in this single build of Anaconda, than the total cumulative time I've spent creating, modifying, resetting, and using my Twitter password. In any case, it's reasonable for online services to require minimum password quality. It's not reasonable for Fedora to do this for my devices. There is no service in this context. > Is the concern that 10 chars is too long? The concern is that it's not Fedora's hardware. It's my device, I get to decide what the password quality and the password are. Even proprietary products respect this long standing practice. This has the feel of Fedora usurping a kind of control over my hardware that doesn't even exist on proprietary OS's (let alone other Linux distributions). Yes, 10 characters is too long, I think this requirement will make users mad. I'm disinclined to do any further installer testing because of this change, and the manner in which it was done. I'm also concerned about CoC warnings and sanction on test@. This is the list were users volunteer to be abused by software, as such I think they're more tolerant. And yet this misfeature hasn't been well received at all here, overwhelmingly. I'd expect the reception in the rest of the community would be quite a bit less docile. -- Chris Murphy -- Chris Murphy

5 4

installing to raw whole disk device
by Chuck Anderson 06 Feb '15

06 Feb '15

All the bits are there to be able to online resize a live KVM guest [1] [2] [3] [4], except for one piece. You can't resize the root partition table entry without rebooting so the kernel picks up the new partition size. By using LVM on a partition table, you can kinda hack around this by using --setphysicalvolumesize to the pvresize command so it ignores the old partition size that the kernel tells it, but this is error prone. All this could be solved by getting rid of the partition table completely. If only Anaconda supported installing this way: clearpart --all --initlabel volgroup vg00 --pesize=32768 sda logvol / --fstype ext4 --name=root --vgname=vg00 --size=1024 --grow Is there anyone working on support this feature? [1] http://unix-heaven.org/node/84 [2] http://unix-heaven.org/node/85 [3] http://eioki.eu/2013/07/02/live-resize-libvirt-disk-lvm-multipath [4] http://serverfault.com/questions/604876/online-resizing-of-kvm-guest-root-f…

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel February 2015