From fxb7-ox9n at dea.spamcon.org Wed Mar 2 09:45:30 2016 From: fxb7-ox9n at dea.spamcon.org (therbur) Date: Wed, 02 Mar 2016 01:45:30 -0800 Subject: Kickstart: How log and view %post? Method works in CentOS 5 but not CentOS 7 References: Message-ID: <7adddbp91omr981ad1ti0htk2kbv2pu4h6@4ax.com> Since nobody responded, I spent days looking around on this and experimenting. It makes no sense to me that the ability to both log and display output is not intrinsic to kickstart. Note that the %pre --log parameter does not work, it always results in a 0-length log file. Also, the example of that option in: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html#sect-kickstart-preinstall is completely wrong anyway because it's logging %pre output to the non-existent built image. Summary of the solution that works for me for CentOS 7 kickstart: %pre --erroronfail exec < /dev/tty3 > /dev/tty3 chvt 3 ( echo ... ) 2>&1 | /usr/bin/tee /tmp/pre.log %end %post --nochroot --erroronfail cp /tmp/pre.log /mnt/sysimage/root/ %end %post --erroronfail exec < /dev/tty3 > /dev/tty3 chvt 3 ( echo ... ) 2>&1 | /usr/bin/tee /root/ks-post.log therbur wrote: >The following method has worked for years with CentOS 5, to allow >live viewing of %post output and also logging it. It doesn't >work in CentOS 7. What is the recommended method now? > ># from kickstart text mode install > >%post --erroronfail > >chvt 3 >exec < /dev/tty3 > /dev/tty3 2> /dev/tty3 > >tail -F /root/ks-post.log & >( > >echo "Starting post-kickstart ..." > ># ... various commands > >echo "Done." >echo >echo "Do Alt-F1 and press Enter to reboot" > >) >> /root/ks-post.log 2>&1 > >%end From rjsm at umich.edu Wed Mar 2 13:07:44 2016 From: rjsm at umich.edu (Ross Smith) Date: Wed, 2 Mar 2016 08:07:44 -0500 Subject: Kickstart: How log and view %post? Method works in CentOS 5 but not CentOS 7 In-Reply-To: <7adddbp91omr981ad1ti0htk2kbv2pu4h6@4ax.com> References: <7adddbp91omr981ad1ti0htk2kbv2pu4h6@4ax.com> Message-ID: I missed your first email, but we do this in our installs. The el7 anaconda uses tmux underneath, which can be exploited to display whatever you want or even interact with a user. The first thing we do, is change the provided rsyslog.conf to log to our central server, which serves most of our needs. something like the following in a %pre script will get you most of the logs from the installer: # wget https://your.server/rsyslog.conf -O /etc/rsyslog.conf # systemctl restart rsyslog This can be further used to display logs using some tmux commands. e.g: # tmux new-window -a -n logging 'tail -F /path/to/log/file.log' We take this a step further, and use tmux to run our %pre and %post scripts directly. # tmux new-window -a -n prescript 'python /tmp/pre.py' # while [ ! -f /tmp/predone ] # do # sleep 1 # done # tmux kill-window -t prescript This sort of setup can also be used with xloadimage to launch a non-blocking script to paste an image to the screen while the text mode installer is running. I hope this helps. Ross Smith College of Engineering - CAEN - Linux Support On Wed, Mar 2, 2016 at 4:45 AM, therbur wrote: > Since nobody responded, I spent days looking around on this and > experimenting. > > It makes no sense to me that the ability to both log and display > output is not intrinsic to kickstart. > > Note that the %pre --log parameter does not work, it always > results in a 0-length log file. > > Also, the example of that option in: > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html#sect-kickstart-preinstall > > is completely wrong anyway because it's logging %pre output to > the non-existent built image. > > > Summary of the solution that works for me for CentOS 7 kickstart: > > > %pre --erroronfail > > exec < /dev/tty3 > /dev/tty3 > chvt 3 > > ( > > echo ... > > ) 2>&1 | /usr/bin/tee /tmp/pre.log > > %end > > > > %post --nochroot --erroronfail > > cp /tmp/pre.log /mnt/sysimage/root/ > > %end > > > > %post --erroronfail > > exec < /dev/tty3 > /dev/tty3 > chvt 3 > > ( > > echo ... > > ) 2>&1 | /usr/bin/tee /root/ks-post.log > > > > therbur wrote: > > >The following method has worked for years with CentOS 5, to allow > >live viewing of %post output and also logging it. It doesn't > >work in CentOS 7. What is the recommended method now? > > > ># from kickstart text mode install > > > >%post --erroronfail > > > >chvt 3 > >exec < /dev/tty3 > /dev/tty3 2> /dev/tty3 > > > >tail -F /root/ks-post.log & > >( > > > >echo "Starting post-kickstart ..." > > > ># ... various commands > > > >echo "Done." > >echo > >echo "Do Alt-F1 and press Enter to reboot" > > > >) >> /root/ks-post.log 2>&1 > > > >%end > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clumens at redhat.com Wed Mar 2 16:54:24 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 2 Mar 2016 11:54:24 -0500 Subject: moving kickstart forward Message-ID: <20160302165424.GZ24235@exeter.usersys.redhat.com> Hey everyone, I've been maintaining pykickstart and kickstart support in anaconda in general for a very long time now, though I've not been very active on this list. I'm going to be looking at kickstart exclusively for the forseeable future. Specifically, my focus is going to be on widening its adoption and making it more useful to everyone. The first step in this process is information gathering. Here's what I would like to know from you guys: * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? * What can I do to make your life easier? What annoys you about kickstart right now? What do you wish it did? What do you wish it didn't do? Would making it more like a language be helpful? Would making it easier to define site-specific commands be helpful? I know this is all really vague stuff, but I am just starting out on this project. I don't even really know where this is going to take me yet. I'd also like to emphasize that whatever I end up doing, I want to keep compatibility with kickstart as it exists today. That's something I take seriously in pykickstart. - Chris From spikewhitetx at gmail.com Thu Mar 3 23:55:00 2016 From: spikewhitetx at gmail.com (Spike White) Date: Thu, 3 Mar 2016 17:55:00 -0600 Subject: moving kickstart forward Message-ID: > ---------- Forwarded message ---------- > From: Chris Lumens > To: kickstart-list at redhat.com > Cc: > Date: Wed, 2 Mar 2016 11:54:24 -0500 > Subject: moving kickstart forward > Hey everyone, I've been maintaining pykickstart and kickstart support in > anaconda in general for a very long time now, though I've not been very > active on this list. > > I'm going to be looking at kickstart exclusively for the forseeable > future. Specifically, my focus is going to be on widening its adoption > and making it more useful to everyone. The first step in this process > is information gathering. > > Here's what I would like to know from you guys: > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > > I'd also like to emphasize that whatever I end up doing, I want to keep > compatibility with kickstart as it exists today. That's something I > take seriously in pykickstart. > > - Chris > Chris, I have beaucoup gripes about the new anaconda introduced in RHEL7. I realize that programmatically the old anaconda was held together with spit and bailing wire. So I realize the developer's motivation for rewriting it. But in so doing they took away considerable end user functionality. Most of this is not ks.cfg related. But some of it can be fixed via improved ks.cfg syntax. Let me preface this. 95% of what we do is static builds. I've developed the framework + PXE servers to do either static builds, DHCP builds or PXE builds. But the server provisioning teams chooses to do static builds almost exclusively. Formerly, if you didn't supply a device for your network ks.cfg line, it would prompt you for a network device. It's be a pop-up that listed the available interfaces and you'd select your interface. This was great, because depending on server model, your public interface would be different. Also, if one of your public NICs didn't work, you could try your other public interface easily. Reboot, choose the other public NIC. However, starting with the new anaconda this is now considered an error for static builds. You have to pre-declare your device as so: network --bootproto static --ip 10.194.36.65 --netmask 255.255.252.0 --gateway 10.194.36.1 --nameserver 143.166.33.44 --device=p1p2 --hostname= austgcore05.us.example.com I realize that you can specify --device=link, which specifies the first interface with link up. But that's usually our cluster interconnect and not our public interface. I realize for PXE builds you can specify --device=bootif, which means use the interface you PXE booted from. (This works great -- for PXE builds). I realize that this is all unnecessary for DHCP builds. You set up the initrd=..... boot options to DHCP up the network, then your network line is simple: network --bootproto=dhcp --noipv6 But for static builds, something like --device=ask would be great. It'd provide a list of network interfaces, like the old anaconda did. Text-based list would be fine. Spike PS I realize it was never ks.cfg that was showing this popup. Instead, the old anaconda was "pre-peeking" inside your ks.cfg for the network line only. And taking this action, based on what it found therein. So now it would be the kickstart parser that would be taking this action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simpsonar77 at gmail.com Sun Mar 6 17:12:02 2016 From: simpsonar77 at gmail.com (Andrew Simpson) Date: Sun, 6 Mar 2016 12:12:02 -0500 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? -use ks to generate developer and production installs in a consistent and flexible manner - we have a large script that assembles all the components from a version control repository into a disc image, then build an ISO, and also burn or publish to a PXE boot server - We are using Jinja to generate the final kickstart from what amounts to kickstart snippets. - our system allows us to have a common set of components and then have individual "projects" that override certain snippets to customize aspects of the build, including partitioning, users, security, etc... * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? - Our kickstarts are quite extensive in the pre and post sections. - We have MANY %post sections - in the pre, we're doing all kinds of stuff to automagically determine what drives are available, flexible partitioning, determining usb/removable drives, as well as setting up your basic installation sources. - In the post, we do everything. we tweak bashrc files, setup kiosk environments in gnome (which sucks by the way), tweak our environments based on project needs, set up security items (firewalls, selinux, pam, etc...) Basically, everything you would normally do on a system after install, we do in the post. - I would love to see the following available in the PRE: -- built in function to identify all removable USB type drives. I currently put these into an array for use later -- built in function to identify all drives in available in the system. I currently have a function for this. -- built in function to identify the PRIMARY boot drive, since sda is not always the first drive. (this is a common issue). I have a function for this as well. -- built in command for excluding drives from install/format/clearpart. I have a function to do this as well. it's messy though at times. -- needs to be a bit easier to determine install source and deal with it accordingly. Lots of issues have been had when trying to install from various sources, like usb cdroms, usb drives, cdrom, etc... Would be nice if ks/anaconda just recognized where the source is an adjusted accordingly. -- I've see other users overwrite their own install media. Should be built in protection for this. -- we often have to go through annoying scripting to get the installation media to be properly available in the post. Should be a built in feature. We do this because often in the post we are adding stuff that wasn't available. Has never made much sense to me that the install media wasn't already just "available" in the post. * other stuff: - making logging easier. I see a lot of questions about how to log everything that's going on. I know how to do this, but it seems that logging everything should be a standard ks/anaconda directive somewhere. - Partitioning is sometimes troublesome with errors being very cryptic as to why or what ran out of space. i.e. is it the logvol, pv, or vg that wasn't defined with enough space? - would be nice if when you use options in the partitioning sections that if they are incompatible with each other, the dev was informed of the exact error. - Some errors that state that there's an issue at line no: xyz are not exactly right. If a dev doesn't know that he has to look at each ks-xyz.log file and that the line number is referencing that particular %post ks part, the line number is misleading. In other words, more detail in error reporting. - would be nice if there was a better ks GUI tool than system-config-kickstart, but I don't know how many would use it. I like KS a lot, but there are always just some cryptic stuff to deal with. Thanks for whatever you might do with this! -Andrew On Wed, Mar 2, 2016 at 11:54 AM, Chris Lumens > wrote: > Hey everyone, I've been maintaining pykickstart and kickstart support in > anaconda in general for a very long time now, though I've not been very > active on this list. > > I'm going to be looking at kickstart exclusively for the forseeable > future. Specifically, my focus is going to be on widening its adoption > and making it more useful to everyone. The first step in this process > is information gathering. > > Here's what I would like to know from you guys: > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > > I'd also like to emphasize that whatever I end up doing, I want to keep > compatibility with kickstart as it exists today. That's something I > take seriously in pykickstart. > > - Chris > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjsm at umich.edu Sun Mar 6 17:47:58 2016 From: rjsm at umich.edu (Ross Smith) Date: Sun, 6 Mar 2016 12:47:58 -0500 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: > > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > We use kickstart now for deploying several classes of systems. Right now we have a static file for each class, but are moving towards generating them on the fly. These systems range from workstations to servers, to virtual machines. > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > Our kickstart files generally follow the following pattern: - all the static directives we can or have to place in the file - %pre script to gather information for the rest of the install - %pre script to authenticate the user or process that initiated the install - %pre script to do sophisticated partitioning and generated an %include file(weeding out usb thumbdrives for instance) - (optional) %pre script to put a splash screen up on the display, also keeps users from interfering with the load process. - %packages contains @base plus a few packages for our tooling to work - %post script that sets a few things for our enivironment (remove packages, set UID/GID limits) then runs our centralized management tool several times to bring a system into configuration, and some magic for setting up the bootloader. We do some magic with fetching the actual %pre scripts from a remote system and using tmux in EL7 to run them. this allows us the flexibility to run a non-blocking script (e.g. splash screen) and allows us to see the output on the console as a tmux screen. We currently don't use %traceback, although it's on our roadmap. > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > More documentation around lesser used options. it may have changed since I last looked, but %traceback wasn't very well documented. We'd really love to see some more built in error handling so we wouldn't even have to rely on %traceback. maybe a way to run a cleanup block when an individual %post or %pre script fails, or a way to define fatal/non-fatal blocks. Along with this, a secured install is very important to us. we have the unenviable position of loading workstations in buildings that are open to the public. We do a lot of work to verify the hardware and user are allowed to get our load, and want to be able to control what can be changed via a kickstart. For instance, if it's an admin loading the machine, allow them to change whatever, if it's a employee from a different department, allow only custom partitioning, and so on. We'd be happy to configure that via %pre scripts, but having the directives available is necessary for that. An officially supported way of interacting with users, or posting things to the screen. Imagine a user needed to login to generate a keytab, or allowing a statusbar for user-defined parts of the install. Improvements around partitioning would be great. I'm imagining something more along the lines of being able to say "ignore everything read-only or on USB" or "these partitions go anywhere on any ssd or md.0" These things also might just be better suited to improvements in blivet than kickstart. improved support for image based installs. We'd like to be able to easily generate a template filesystem image and throw that down over our partitions in non-livecd environments. That process was a bit cumbersome, or required large imagefiles along the simpler path. We're often chaining this install after an automated windows install, so simplicity whenever we can get it is beneficial. More built-in support for templating. Anaconda can send the mac address of the system along in the initial get for a kickstart, but options to send user defined data or other discovered data (e.g. hostname ) in any request anaconda makes would be useful. like %pre --url= http://myserver/path/to/pre.py could send machine data. A minor thing is an improved logging command. we log via udp on port 515 for installs. This keeps it all separate from our production logs, but we can't just tell kickstart that right now. I've definitely been lazy, and haven't gotten that bug put in or a patch posted. > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > Thanks for focusing on it. I'm happy to lend a hand where I can, or provide more feedback. Ross Smith College of Engineering - CAEN - Linux Support -------------- next part -------------- An HTML attachment was scrubbed... URL: From jscott at cpinternet.com Sun Mar 6 18:33:28 2016 From: jscott at cpinternet.com (JJ) Date: Sun, 6 Mar 2016 12:33:28 -0600 Subject: moving kickstart forward In-Reply-To: Message-ID: <1457289169_518@mail.cpinternet.com> * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? For our test / dev sandbox, PXE boot menu options that specify build parameters via the ks=URI to a php script i.e. MACHINE_TYPE=vm,phy_hp,phy_ucs DISK_TYPE=flat,lvm DISK_SIZE=sm,med,large... sometimes one-off's for specific builds based on hostname via dhcp reserved ip address to be able to rebuild the same box over and over again for testing. * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? Use %post to wget mgmt stuff - sudoers, ssh-keys, repo setup & security validation & the like * What can I do to make your life easier? What annoys you about kickstart right now? What do you wish it did? What do you wish it didn't do? Would making it more like a language be helpful? Would making it easier to define site-specific commands be helpful? I know this is all really vague stuff, but I am just starting out on this project. I don't even really know where this is going to take me yet. I'd also like to emphasize that whatever I end up doing, I want to keep compatibility with kickstart as it exists today. That's something I take seriously in pykickstart. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Mon Mar 7 01:17:11 2016 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 06 Mar 2016 19:17:11 -0600 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> (Chris Lumens's message of "Wed, 2 Mar 2016 11:54:24 -0500") References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: >>>>> "CL" == Chris Lumens writes: CL> * How do you use kickstart right now? For the last very, very many years (since RHL7 or so) I've generated my kickstart files on demand, but have been moving more and more functionality into either %pre (for working out disk partitioning and such based on EFI and what's installed in the system), scripts in %post, or scripts that run after the system initially boots. I've been moving towards doing these automatically when dracut tries to grab the kickstart file, but wish dracut supplied more information when it does this. CL> * What do you do in your kickstart files? Do you have extensive CL> %pre and %post sections? %pre and %post are rather large. I first moved to using %pre for disk partitioning when some functionally for setting up RAID was dropped from the installer some time ago, and now always generate my disk layout and bootloader configuration in %pre. %post does a bunch of site-specific setup, plus drops a script in place which runs as the machine boots, to pull in he full package set by installing a bunch of groups defined in a local comps file. CL> Do you ever use %traceback? Didn't even know it existed. I suppose if you're asking, you'd like to be able to get rid of it and so I probably shouldn't go looking into it. CL> Do you have unusual stuff going on in %packages? We used to use %packages -nobase and occasionally use "-package" to make sure something is not installed. CL> * What can I do to make your life easier? At this point I'm not sure it's reasonable to have kickstart do the amount of stuff I've come to do in custom code, but here are some things: Not really kickstart itself, but have dracut pass as much information as possible about the machine. It would be super great if it could post some json or something. Back before I did all of the disk setup in %pre, I found myself wishing I had some sort of conditional statement. If this much disk, then use this layout. I also wish it were simpler to set up a filesystem setup without worrying so much about the actual partitioning, Just being able to say "give me a VG that's RAID1 across these disks" would be much simpler than generating a partitioning scheme. Having some simple ways to indicate the services I want to have enabled, and which selinux booleans I'd like set might be handy, I suppose, to get rid of some things in %post. But for all I know, those might exist these days and I just need to read the docs. - J< From clumens at redhat.com Mon Mar 7 15:39:24 2016 From: clumens at redhat.com (Chris Lumens) Date: Mon, 7 Mar 2016 10:39:24 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160307153923.GB416@exeter.usersys.redhat.com> > %pre and %post are rather large. I first moved to using %pre for disk > partitioning when some functionally for setting up RAID was dropped from > the installer some time ago, and now always generate my disk layout and > bootloader configuration in %pre. What could we add that would allow you to ditch your %pre-based disk partitioning? I'm wondering if higher level commands (like you mention later) would help, or perhaps some tools in either blivet or kickstart that could query the system and generate kickstart commands for you? Perhaps simply a couple tweaks to existing options would help? Maybe we can't actually completely replace what you're doing, but maybe we could provide stuff that would let you get rid of a lot of it. > %post does a bunch of site-specific setup, plus drops a script in place > which runs as the machine boots, to pull in he full package set by > installing a bunch of groups defined in a local comps file. What are you doing here that can't be done with a combination of the repo command and more stuff in the %packages section? > CL> Do you ever use %traceback? > > Didn't even know it existed. I suppose if you're asking, you'd like to > be able to get rid of it and so I probably shouldn't go looking into it. Nah, I'm not going to get rid of it. It can be very useful for testing. I'm curious as to what other people may be using it for. In general, I'm not looking to get rid of anything - just trying to understand what people are doing and where we can make things easier. > Not really kickstart itself, but have dracut pass as much information as > possible about the machine. It would be super great if it could post > some json or something. So, information about the machine being passed into the process that runs kickstart? That would be doable. We'd just have to decide what that information is and then consider that part of an API that doesn't change. Or alternately, more information being supplied to the server when the kickstart file is fetched? That would also be doable. > Back before I did all of the disk setup in %pre, I found myself wishing > I had some sort of conditional statement. If this much disk, then use > this layout. I've been thinking about adding more language features - variables, conditionals, etc. It's a little complicated by the fact that a lot of people use some sort of templating language with their kickstarts already. I don't want to make a bigger mess of this situation. > I also wish it were simpler to set up a filesystem setup without > worrying so much about the actual partitioning, Just being able to say > "give me a VG that's RAID1 across these disks" would be much simpler > than generating a partitioning scheme. This is really interesting. It sounds like you want a kickstart version of what we've got in custom partitioning right now. We can definitely look into this. I know the current partitioning commands are really low level, and people do seem to like that, but we've not really gotten around to providing anything on top of them. > Having some simple ways to indicate the services I want to have enabled, > and which selinux booleans I'd like set might be handy, I suppose, to > get rid of some things in %post. But for all I know, those might exist > these days and I just need to read the docs. Yeah, there's already a services command. That came out of another round of email like this I did many years ago. Something for selinux booleans does not already exist, but it could be added. - Chris From clumens at redhat.com Mon Mar 7 16:17:28 2016 From: clumens at redhat.com (Chris Lumens) Date: Mon, 7 Mar 2016 11:17:28 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160307161728.GC416@exeter.usersys.redhat.com> > Our kickstart files generally follow the following pattern: > - all the static directives we can or have to place in the file > - %pre script to gather information for the rest of the install What kind of information do you gather? How do you store it to make it accessible for the rest of the install? Is it in some sort of format? > - %pre script to do sophisticated partitioning and generated an %include > file(weeding out usb thumbdrives for instance) What other sorts of things are you doing here? I feel like we could be doing a lot better at either providing more high level partitioning commands, or tools that use blivet to inspect the system and generate kickstart chunks, or something. Weeding out classes of devices is definitely something we can look at. > - %post script that sets a few things for our enivironment (remove > packages, set UID/GID limits) then runs our centralized management tool > several times to bring a system into configuration, and some magic for > setting up the bootloader. Why do you need to remove packages in %post? Is it stuff that's dragged in as dependencies that you then want to force-remove later? Also, what kind of bootloader magic is required? > We do some magic with fetching the actual %pre scripts from a remote system > and using tmux in EL7 to run them. this allows us the flexibility to run a > non-blocking script (e.g. splash screen) and allows us to see the output on > the console as a tmux screen. Ugh, yeah, people are always wanting ways of keeping track of kickstart or doing logging or running something interatively. This tends to be pretty tough stuff to do, but we'll continue to look into it. > More documentation around lesser used options. it may have changed since I > last looked, but %traceback wasn't very well documented. We'd really love > to see some more built in error handling so we wouldn't even have to rely > on %traceback. maybe a way to run a cleanup block when an individual %post > or %pre script fails, or a way to define fatal/non-fatal blocks. Documentation is on my list, as well as adding lots of examples too. %traceback is still not really documented, no. Cleanup after a script fails is interesting. I'm not sure how to extend the syntax to allow for that, but I can think about it. You can already give scripts --erroronfail to cause them to display an error message and halt the installation. Scripts without this would not cause the installation to fail. > Along with this, a secured install is very important to us. we have the > unenviable position of loading workstations in buildings that are open to > the public. We do a lot of work to verify the hardware and user are > allowed to get our load, and want to be able to control what can be changed > via a kickstart. For instance, if it's an admin loading the machine, allow > them to change whatever, if it's a employee from a different department, > allow only custom partitioning, and so on. We'd be happy to configure that > via %pre scripts, but having the directives available is necessary for > that. Basically, some sort of ACL for commands in the kickstart file? That could get pretty complex in a hurry. This does remind me that people have wanted a way of not allowing the user to interact with the UI at all during a kickstart install. We could probably at least do that pretty easily. > An officially supported way of interacting with users, or posting things to > the screen. Imagine a user needed to login to generate a keytab, or > allowing a statusbar for user-defined parts of the install. We probably should have taken this into account when working on newui. This is a long-standing request and we should take a look at how feasible it is. > Improvements around partitioning would be great. I'm imagining something > more along the lines of being able to say "ignore everything read-only or > on USB" or "these partitions go anywhere on any ssd or md.0" These things > also might just be better suited to improvements in blivet than kickstart. I'm definitely seeing a trend here - everyone wants more and better partitioning. I'm imagining tools either in blivet or kickstart that can help out. The more information and examples you can give, the better. > improved support for image based installs. We'd like to be able to easily > generate a template filesystem image and throw that down over our > partitions in non-livecd environments. That process was a bit cumbersome, > or required large imagefiles along the simpler path. We're often chaining > this install after an automated windows install, so simplicity whenever we > can get it is beneficial. I'll have to read up on this. Live and non-live installs are pretty separate in anaconda right now. > More built-in support for templating. I've considered adding a template language step around kickstart. There's a ton of options here. I just don't want to make a bigger mess of things given how a lot of people are already generating kickstarts using templates, or cobbler, etc. So I just need to do a lot of research here before deciding what I can do. > Anaconda can send the mac address of > the system along in the initial get for a kickstart, but options to send > user defined data or other discovered data (e.g. hostname ) in any request > anaconda makes would be useful. like %pre --url= > http://myserver/path/to/pre.py could send machine data. This came up in another email. So you'd also like to see more around inspecting the system and making that data available either to the server where the kickstart file lives, or to the environment where the kickstart file is processed. > A minor thing is an improved logging command. we log via udp on port 515 > for installs. This keeps it all separate from our production logs, but we > can't just tell kickstart that right now. I've definitely been lazy, and > haven't gotten that bug put in or a patch posted. I'd definitely be interested in any bug reports or patches around the logging command. It hasn't seen any activity in a long time. It does already support --host and --port, so I'd be curious what's going wrong. - Chris From clumens at redhat.com Mon Mar 7 17:03:31 2016 From: clumens at redhat.com (Chris Lumens) Date: Mon, 7 Mar 2016 12:03:31 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160307170330.GD416@exeter.usersys.redhat.com> > - We are using Jinja to generate the final kickstart from what amounts to > kickstart snippets. How did you decide on this template system? If I wanted to add an "official" template system that pykickstart runs the input file through, should I use this one? Would I make your job harder if I used a different one? Should I just stay away from this entirely and let everyone do what they think is best? > - in the pre, we're doing all kinds of stuff to automagically determine > what drives are available, flexible partitioning, determining usb/removable > drives, as well as setting up your basic installation sources. I feel like we could take over a lot of this by providing tools for you to use. Can you give me more information on what you're doing here? > - In the post, we do everything. we tweak bashrc files, setup kiosk > environments in gnome (which sucks by the way), tweak our environments > based on project needs, set up security items (firewalls, selinux, pam, > etc...) Basically, everything you would normally do on a system after > install, we do in the post. A lot of this sounds like it's pretty site-specific. However the security stuff we should be able to handle. What are you doing with firewalls and selinux that we don't already have options to do? There's likely a lot here we don't have options for. I'd just like to take over some of this stuff if possible. > - I would love to see the following available in the PRE: > -- built in function to identify all removable USB type drives. I > currently put these into an array for use later > -- built in function to identify all drives in available in the system. I > currently have a function for this. > -- built in function to identify the PRIMARY boot drive, since sda is not > always the first drive. (this is a common issue). I have a function for > this as well. > -- built in command for excluding drives from install/format/clearpart. I > have a function to do this as well. it's messy though at times. I think we could definitely do this kind of stuff. I imagine a "built-in function" taking the form of a command line tool we provide, though. We might also be able to extend the current kickstart commands to provide some of this. What else would you like to see here? > -- needs to be a bit easier to determine install source and deal with it > accordingly. Lots of issues have been had when trying to install from > various sources, like usb cdroms, usb drives, cdrom, etc... Would be nice > if ks/anaconda just recognized where the source is an adjusted accordingly. What kind of issues are you seeing? Where would you like it to be easier to determine the installation source? In scripts? When writing the kickstart file to begin with? > -- I've see other users overwrite their own install media. Should be built > in protection for this. As long as you are using the kickstart commands, anaconda will refuse to partition the device containing the installation source. If you've seen this happen, it's a bug in anaconda. Of course, we can't really stop you from doing anything in a script. > -- we often have to go through annoying scripting to get the installation > media to be properly available in the post. Should be a built in feature. > We do this because often in the post we are adding stuff that wasn't > available. Has never made much sense to me that the install media wasn't > already just "available" in the post. I don't know the status of this in anaconda, but you're right - it should be available if it's not. Do you also need a way of knowing what kind of installation source (DVD, NFS, etc.) you are using, or do you just care about where it's mounted? > - making logging easier. I see a lot of questions about how to log > everything that's going on. I know how to do this, but it seems that > logging everything should be a standard ks/anaconda directive somewhere. anaconda does an awful lot of logging already. I tend to think we do too much - we err on the side of logging just about everything which makes what's there harder to understand. What could we do to make logging easier? > - Partitioning is sometimes troublesome with errors being very cryptic as > to why or what ran out of space. i.e. is it the logvol, pv, or vg that > wasn't defined with enough space? The blame for this can be shared among anaconda, pykickstart, and blivet. We should probably sit down and review all our error messages and try to make sense of them. Also with so many layers, it can be hard to provide really useful and accurate error messages that aren't also cryptic. > - would be nice if when you use options in the partitioning sections that > if they are incompatible with each other, the dev was informed of the exact > error. Sadly, only some of this can be done in pykickstart ahead of time so it can be caught by ksvalidator before you try to do an installation. The rest gets done by anaconda at install-time. We should definitely go through and take a look at this, though. Do you have some examples of where we're providing some pretty crappy error messages? > - Some errors that state that there's an issue at line no: xyz are not > exactly right. If a dev doesn't know that he has to look at each > ks-xyz.log file and that the line number is referencing that particular > %post ks part, the line number is misleading. In other words, more detail > in error reporting. This could definitely use a re-think, you're right. A lot of the confusion probably comes from (1) each script getting its own log file with a funny temporary name, and (2) line numbers of the kickstart file vs. line numbers of each script. I'll see if I can't make better sense of this. > - would be nice if there was a better ks GUI tool than > system-config-kickstart, but I don't know how many would use it. Yeah, that's on my todo list. This is my fault, too - I've just let it rot while I focused on newui in anaconda and then afterwards I've not been very excited to dive back into UI stuff in another program. But it desperately needs work. > I like KS a lot, but there are always just some cryptic stuff to deal with. > > Thanks for whatever you might do with this! Sure, there's always something that could be improved. - Chris From r.w.askew at boeing.com Mon Mar 7 18:16:33 2016 From: r.w.askew at boeing.com (EXT-Askew, R W) Date: Mon, 7 Mar 2016 18:16:33 +0000 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: Chris I am currently using a downstream distro of RHEL 6.2 Per requirements our application is installed standalone via DVD. %pre : we only do --log= . No custom stuff done here. %post : we use --log= and this is where we do the custom software installation and configuration. I have tried using a USB stick but, KS or anaconda get lost on where the files are when going to %post. It would be nice if this work like the DVD install. Cheers Bill Askew PCS Technical Lead 281-226-6920 -----Original Message----- From: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Chris Lumens Sent: Wednesday, March 02, 2016 10:54 AM To: kickstart-list at redhat.com Subject: moving kickstart forward Hey everyone, I've been maintaining pykickstart and kickstart support in anaconda in general for a very long time now, though I've not been very active on this list. I'm going to be looking at kickstart exclusively for the forseeable future. Specifically, my focus is going to be on widening its adoption and making it more useful to everyone. The first step in this process is information gathering. Here's what I would like to know from you guys: * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? * What can I do to make your life easier? What annoys you about kickstart right now? What do you wish it did? What do you wish it didn't do? Would making it more like a language be helpful? Would making it easier to define site-specific commands be helpful? I know this is all really vague stuff, but I am just starting out on this project. I don't even really know where this is going to take me yet. I'd also like to emphasize that whatever I end up doing, I want to keep compatibility with kickstart as it exists today. That's something I take seriously in pykickstart. - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list at redhat.com https://www.redhat.com/mailman/listinfo/kickstart-list From clumens at redhat.com Mon Mar 7 18:32:42 2016 From: clumens at redhat.com (Chris Lumens) Date: Mon, 7 Mar 2016 13:32:42 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160307183242.GE416@exeter.usersys.redhat.com> > Per requirements our application is installed standalone via DVD. > %pre : we only do --log= . No custom stuff done here. > %post : we use --log= and this is where we do the custom software installation and configuration. What kind of custom installation are you doing that prevents using the repo command with extra stuff in the %packages section? Is there anything we could do to let this work for you? > I have tried using a USB stick but, KS or anaconda get lost on where the files are when going to %post. It would be nice if this work like the DVD install. Hm, could you give me more information on what's happening here? Thanks! - Chris From drlogix at gmail.com Mon Mar 7 20:20:01 2016 From: drlogix at gmail.com (Thomas Sanders) Date: Mon, 7 Mar 2016 12:20:01 -0800 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: I currently build my kickstart files in sections based on OS and then put them together with a script. An example: preamble.centos, preamble.centos7, preamble.fedora, preamble.ubuntu Everything gets concatenated together like this cat header preamble.centos partitions.centos pre post repos.centos packages packages.centos packages.gui packages.centosgui packages.end > ks-centos6-gui.cfg We use %pre to obtain info about the system like: Which NIC to configure Hostname IP MASK Primary user Admin user What OU the host should be added And the original proc/cmdline (so I can get some info like what kickstart file was originally used in the PXE boot) These are all placed in /tmp/installVars as key=value That file (and other logs) are moved in %post --nochroot Then it is made available to the regular %post via the following: ## get installVars from /root/install_logs/installVars while IFS="=" read -r key value; do case "$key" in '#'*) # do nothing for comments ;; *) eval "$key=\"$value\"" ;; esac done < /root/install_logs/installVars It would be GREAT if we could get user input a little easier than using our own scripts in %pre I would like to +1 on the getting "%pre --log /tmp/ks-pre.log" working, currently my work around is exec < /dev/tty3 > /dev/tty3 2>&1 chvt 3 ( ... ) 2>&1 | /usr/bin/tee -a /tmp/ks-pre.log -Thomas On Wed, Mar 2, 2016 at 8:54 AM, Chris Lumens wrote: > Hey everyone, I've been maintaining pykickstart and kickstart support in > anaconda in general for a very long time now, though I've not been very > active on this list. > > I'm going to be looking at kickstart exclusively for the forseeable > future. Specifically, my focus is going to be on widening its adoption > and making it more useful to everyone. The first step in this process > is information gathering. > > Here's what I would like to know from you guys: > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > > I'd also like to emphasize that whatever I end up doing, I want to keep > compatibility with kickstart as it exists today. That's something I > take seriously in pykickstart. > > - Chris > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Mon Mar 7 20:30:52 2016 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 07 Mar 2016 14:30:52 -0600 Subject: moving kickstart forward In-Reply-To: <20160307153923.GB416@exeter.usersys.redhat.com> (Chris Lumens's message of "Mon, 7 Mar 2016 10:39:24 -0500") References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307153923.GB416@exeter.usersys.redhat.com> Message-ID: >>>>> "CL" == Chris Lumens writes: CL> What could we add that would allow you to ditch your %pre-based disk CL> partitioning? At this point, I don't know. Basically I switched because the Anaconda folks told me that I had to use %pre instead of relying on some RAID behavior which worked for many releases but caused an error after a particular point. (I know that's not useful, but there's a bugzilla ticket about it I could dig up.) And once you're free of the constraints of static config, it's easy to go wild. Right now, here's the kind of thing I do: For a desktop: Set the swap VG size to to 4GB <= RAM <= 16GB. Only set up an EFI system partition if the machine was booted via UEFI. Set the size of /scratch to leave me no less than 20GB of unallocated space in the main VG. For a server, which often has a number of SSDs and a number of disks: Find the set of smallest, identically sized non-removable disks (the SSDs). Set up EFI system partitions on each under different mountpoints, then RAID1 the remainder of the space for a VG holding the OS. On the other disks in the machine, RAID them with parameters given when the kickstart file was generated. CL> I'm wondering if higher level commands (like you mention later) CL> would help, or perhaps some tools in either blivet or kickstart that CL> could query the system and generate kickstart commands for you? I'm thinking that at this time, there's not much of a chance that anything can help the server case as its just become too complex. The magic is in dynamically finding the "OS disks" and setting them up separately. Doing anything with the "data disks" is just convenience that could be done after boot. Doing it statically (i.e. generating this stuff ahead of time) isn't really possible because I have no idea which device names the kernel will assign for all of the disks; sometimes hey aren't even stable. The desktop case, where things are sized based on disk and RAM size and conditionally on EFI, might be doable with the addition of a few extra bits of kickstart syntax. CL> What are you doing here that can't be done with a combination of the CL> repo command and more stuff in the %packages section? Well, basically I have to install so much crap that I'd prefer to do it while the system is actually up and running. That's not really in the realm of something you'd want to do in kickstart, though. Basically, things like Matlab and Mathematica are huge. CL> Or alternately, more information being supplied to the server when CL> the kickstart file is fetched? That would also be doable. Yes, that's what I'm talking about. I know I can hack the dracut component of anaconda to pass more HTTP headers, but I really wish it could just POST some JSON or something with as much info as possible. Detected devices, DMI information, that kind of thing. CL> It sounds like you want a kickstart version of what we've got in CL> custom partitioning right now. Pretty much. The installer already has code for making things "easy" for people actually clicking on buttons in the interface, but none of those bits are exposed to people doing kickstart installs. There are a couple of other things I'd like to throw out there, which are more anaconda things but which would really only be relevant First, let me specify what happens on the machine while its installing. I do almost all of my installs to user desktops remotely. If they walk into their office at the wrong time, they see the generic anaconda instructions and can get a passwordless shell. I'd really like to be able to specify what they can see ("Touch this machine and I break your hands" | cowsay), and at least protect that shell somehow. Secondly, I really wish we had some sort of installation console. Currently, dracut boots, DHCPs and tries to fetch a kickstart file once. There's no way that I know of to have it wait there until a kickstart file is ready. If there were, an application could show an admin information about the machines waiting to be installed and allow parameters to be set and such. If you've ever seen how the old school Scyld Beowulf cluster stuff worked, you'd see what I'm talking about. And going along with that, having some specified way to get progress information out of the installing system would allow a pretty complete system for doing a whole pile of installations (which is something I do twice a year). - J< From r.w.askew at boeing.com Mon Mar 7 20:31:23 2016 From: r.w.askew at boeing.com (EXT-Askew, R W) Date: Mon, 7 Mar 2016 20:31:23 +0000 Subject: moving kickstart forward In-Reply-To: <20160307183242.GE416@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307183242.GE416@exeter.usersys.redhat.com> Message-ID: Bill Askew PCS Technical Lead 281-226-6920 -----Original Message----- From: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Chris Lumens Sent: Monday, March 07, 2016 12:33 PM To: kickstart-list at redhat.com Subject: Re: moving kickstart forward > Per requirements our application is installed standalone via DVD. > %pre : we only do --log= . No custom stuff done here. > %post : we use --log= and this is where we do the custom software installation and configuration. What kind of custom installation are you doing that prevents using the repo command with extra stuff in the %packages section? Is there anything we could do to let this work for you? [[rwa]] much of what we are doing is not in packages. Nor in a repo. We copy files; change permissions things like that. I am not sure if we could do it all in the packages section. It would require quite a bit of work to change our build process if we can. Are you proposing that the %pre and %post sections be done away with? > I have tried using a USB stick but, KS or anaconda get lost on where the files are when going to %post. It would be nice if this work like the DVD install. Hm, could you give me more information on what's happening here? Thanks! - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list at redhat.com https://www.redhat.com/mailman/listinfo/kickstart-list From rjsm at umich.edu Mon Mar 7 20:33:06 2016 From: rjsm at umich.edu (Ross Smith) Date: Mon, 7 Mar 2016 15:33:06 -0500 Subject: moving kickstart forward In-Reply-To: <20160307161728.GC416@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307161728.GC416@exeter.usersys.redhat.com> Message-ID: > > What kind of information do you gather? How do you store it to make it > accessible for the rest of the install? Is it in some sort of format? > > We gather mac address, and some basic hardware stats, we will be collecting more network information in the future. We get the uuid from our asset database, along with recording who initiated the load. We put this into a file in /tmp that can be sourced by bash scripts. It's easy enough to parse with python in that format too. > - %pre script to do sophisticated partitioning and generated an %include > > file(weeding out usb thumbdrives for instance) > > What other sorts of things are you doing here? I feel like we could be > doing a lot better at either providing more high level partitioning > commands, or tools that use blivet to inspect the system and generate > kickstart chunks, or something. Weeding out classes of devices is > definitely something we can look at. > This is in python, and we make use of blivet for inspecting the disks. We used to parse the output of parted, and dig around in the system directly. Things we do currently: - check if the system is EFI, and if an EFI partition already exists - check if there's a windows install already present by presence of ntfs partition(this ties into the bootloader magic later) - delete existing linuxNative, PARTITION_LVM and PARTITION_SWAP partitions - attempt to ignore everything that's removable, readonly, or USB - Choose the most appropriate of the remaining disks to install to by largest available space - write part/logvol lines to a file in /tmp that's an %include in the kickstart Why do you need to remove packages in %post? Is it stuff that's dragged > in as dependencies that you then want to force-remove later? It's stuff that seems to be ignored if put a -package line in and we wish to remove. We don't use the force flag with yum. Notably it's rhn/subscription manager stuff that we don't want in place on the finished system. Also, what kind of bootloader magic is required? > Partly this is because we want a dualboot setup with EFI and windows 7, which doesn't really support EFI. The magic is more to work around the windows limitations than EL's. We install refind, and move some files around. Also, we create an efi entry ourselves because the --leavebootloader option doesn't always work. Again, something I've been lazy about looking into. Even if it did, we'd need to put some files in place to get a sane dualboot setup working. > > > Along with this, a secured install is very important to us. we have the > > unenviable position of loading workstations in buildings that are open to > > the public. We do a lot of work to verify the hardware and user are > > allowed to get our load, and want to be able to control what can be > changed > > via a kickstart. For instance, if it's an admin loading the machine, > allow > > them to change whatever, if it's a employee from a different department, > > allow only custom partitioning, and so on. We'd be happy to configure > that > > via %pre scripts, but having the directives available is necessary for > > that. > > Basically, some sort of ACL for commands in the kickstart file? That > could get pretty complex in a hurry. This does remind me that people > have wanted a way of not allowing the user to interact with the UI at > all during a kickstart install. We could probably at least do that > pretty easily. > Yea. I've definitely been one person pushing for that since our installs happen around untrusted users. I was thinking something along the lines of a "AllowSpokeInteract --spoke SpokeName " directive or it's negative counterpart. Having an all or nothing option would probably be sufficient for us. > > > More built-in support for templating. > > I've considered adding a template language step around kickstart. > There's a ton of options here. I just don't want to make a bigger mess > of things given how a lot of people are already generating kickstarts > using templates, or cobbler, etc. So I just need to do a lot of > research here before deciding what I can do. > Even some basic things would be welcome. For instance being able to reference the release it was booted with or the hostname would help de-duplicate our kickstart files. > > > A minor thing is an improved logging command. we log via udp on port 515 > > for installs. This keeps it all separate from our production logs, but > we > > can't just tell kickstart that right now. I've definitely been lazy, and > > haven't gotten that bug put in or a patch posted. > > I'd definitely be interested in any bug reports or patches around the > logging command. It hasn't seen any activity in a long time. It does > already support --host and --port, so I'd be curious what's going wrong. > I looked back at my notes about this. It switches to tcp when you change the port to something other than 514. Either a --protocol or --udp/--tcp flags would probably give the added flexibility. -Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Mon Mar 7 21:54:47 2016 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 07 Mar 2016 15:54:47 -0600 Subject: moving kickstart forward In-Reply-To: <20160307170330.GD416@exeter.usersys.redhat.com> (Chris Lumens's message of "Mon, 7 Mar 2016 12:03:31 -0500") References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307170330.GD416@exeter.usersys.redhat.com> Message-ID: >>>>> "CL" == Chris Lumens writes: CL> How did you decide on this template system? I'd imagine that anyone who has done a reasonable amount of python work (especially web-related things) would have some familiarity with jinja, It's probably I would use if I were to modernize my setup. CL> If I wanted to add an "official" template system that pykickstart CL> runs the input file through, should I use this one? You could certainly do a whole lot worse, I think. But I'd think that providing tools which expect jinja, if you wanted to do so, wouldn't rule out the possibility of people doing their own things. - J< From simpsonar77 at gmail.com Mon Mar 7 22:30:49 2016 From: simpsonar77 at gmail.com (Andrew Simpson) Date: Mon, 7 Mar 2016 17:30:49 -0500 Subject: moving kickstart forward In-Reply-To: <20160307183242.GE416@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307183242.GE416@exeter.usersys.redhat.com> Message-ID: On this one, reference back to what I posted to Chris just a minute ago. USB is tricky. 1. using USB to install everything? this requires setting up the usb drive properly. 2. using USB to only host the kickstart file, with the ISO on dvd or a network share is pretty easy though. How to install from USB: 1. First thing to note is that you MUST make the iso bootable by usb. #make sure the iso is bootable on USB devices isohybrid ${filename}.iso implantisomd5 ${filename}.iso 2. I'm attaching a script to push an iso to a usb drive. Sorry, I had to do this on a windows machine. probably has been window-ized. 3. See my %pre section provided to Chris L a few posts back. > Andrew Simpson On Mon, Mar 7, 2016 at 1:32 PM, Chris Lumens wrote: > > Per requirements our application is installed standalone via DVD. > > %pre : we only do --log= . No custom stuff done here. > > %post : we use --log= and this is where we do the custom software > installation and configuration. > > What kind of custom installation are you doing that prevents using the > repo command with extra stuff in the %packages section? Is there > anything we could do to let this work for you? > > > I have tried using a USB stick but, KS or anaconda get lost on where the > files are when going to %post. It would be nice if this work like the DVD > install. > > Hm, could you give me more information on what's happening here? > Thanks! > > - Chris > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: do_make_usb.sh Type: application/x-sh Size: 5595 bytes Desc: not available URL: From r.w.askew at boeing.com Tue Mar 8 15:12:58 2016 From: r.w.askew at boeing.com (EXT-Askew, R W) Date: Tue, 8 Mar 2016 15:12:58 +0000 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307183242.GE416@exeter.usersys.redhat.com> Message-ID: Thanks Andrew Bill Askew PCS Technical Lead 281-226-6920 From: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Andrew Simpson Sent: Monday, March 07, 2016 4:31 PM To: Discussion list about Kickstart Subject: Re: moving kickstart forward On this one, reference back to what I posted to Chris just a minute ago. USB is tricky. 1. using USB to install everything? this requires setting up the usb drive properly. 2. using USB to only host the kickstart file, with the ISO on dvd or a network share is pretty easy though. How to install from USB: 1. First thing to note is that you MUST make the iso bootable by usb. #make sure the iso is bootable on USB devices isohybrid ${filename}.iso implantisomd5 ${filename}.iso 2. I'm attaching a script to push an iso to a usb drive. Sorry, I had to do this on a windows machine. probably has been window-ized. 3. See my %pre section provided to Chris L a few posts back. Andrew Simpson On Mon, Mar 7, 2016 at 1:32 PM, Chris Lumens > wrote: > Per requirements our application is installed standalone via DVD. > %pre : we only do --log= . No custom stuff done here. > %post : we use --log= and this is where we do the custom software installation and configuration. What kind of custom installation are you doing that prevents using the repo command with extra stuff in the %packages section? Is there anything we could do to let this work for you? > I have tried using a USB stick but, KS or anaconda get lost on where the files are when going to %post. It would be nice if this work like the DVD install. Hm, could you give me more information on what's happening here? Thanks! - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list at redhat.com https://www.redhat.com/mailman/listinfo/kickstart-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon.messmer at gmail.com Tue Mar 8 18:37:37 2016 From: gordon.messmer at gmail.com (Gordon Messmer) Date: Tue, 8 Mar 2016 10:37:37 -0800 Subject: moving kickstart forward In-Reply-To: <20160307153923.GB416@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307153923.GB416@exeter.usersys.redhat.com> Message-ID: <56DF1BF1.3070701@gmail.com> On 03/07/2016 07:39 AM, Chris Lumens wrote: > What could we add that would allow you to ditch your %pre-based disk > partitioning? The ability to evaluate a line or lines based on whether a word appears in the kernel cmdline would go a long way. In Jinja2 style (assuming cmdline is an array of words from /proc/cmdline): {% if "softraid" in cmdline %} ... whatever software raid args {% endif %} The other thing I'd really like to see is the ability to set chunk size for software RAID arrays. It defaults to 512K in mdadm and there's no way to specify a size in kickstart. That default performs terribly in all of the workloads where I've tested it. From gordon.messmer at gmail.com Tue Mar 8 18:39:01 2016 From: gordon.messmer at gmail.com (Gordon Messmer) Date: Tue, 8 Mar 2016 10:39:01 -0800 Subject: moving kickstart forward In-Reply-To: <20160307170330.GD416@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307170330.GD416@exeter.usersys.redhat.com> Message-ID: <56DF1C45.9030802@gmail.com> On 03/07/2016 09:03 AM, Chris Lumens wrote: >> - We are using Jinja to generate the final kickstart from what amounts to >> >kickstart snippets. > How did you decide on this template system? If I wanted to add an > "official" template system that pykickstart runs the input file through, > should I use this one? Although I also like Jinja2 and mentioned it in my last email, quoting '{' and '}' characters is ugly, and I suspect they're common in %pre and %post shell scripts. If you used it, you'd have to parse shell sections out first and run the remainder through the template engine. From Steven_Hajducko at intuit.com Tue Mar 8 19:31:08 2016 From: Steven_Hajducko at intuit.com (Hajducko, Steven) Date: Tue, 8 Mar 2016 19:31:08 +0000 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? We use it for our baremetal installations as part of our orchestration process, which is run via Salt Stack. We use Cobbler to generate the kickstart files for us ( which uses the Cheetah templating engine ) and handle the PXE booting. We store the snippets and main KS ( which is really just including the relevant snippets ) in revision control. We build our systems on a dedicated provisioning network before we flip them over to a run network ( after the installation is finished ). * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? Never knew %traceback existed. Because of our use of Cobbler, it comes prebuilt with some rather lengthy %post and %pre sections. We actually have two main classes of kickstarts - our RAID kickstart and our OS kickstart. In our OS kickstart, some of these things include: In %pre: - Sending logs off the system ( Cobbler accomplishes this via a python script called anamon ). This allows us for remote monitoring of the logs. - We call out to specific webhooks in both %pre and %post, as part of our orchestration triggers/process - We do a bunch of a disk detection. I have a recent thread on here about what we're trying to accomplish - but trying to find the first disk in the BIOS boot order is a *pain* In %packages: - We use -nobase occasionally. - We use -packagename sometimes, although it doesn't always work, because of requirements from other packages ( like back in RHEL5 when wireless-tools always got installed ) In %post: - Adding custom yum repos that we want for the installation only - We yum install Chef from a custom repo, along with a cookbook, and use that for most of the post configuration. There are issues we've encountered doing this. Some services don't like to be started in %post ( iptables, kdump ), so we just enable those services w/out starting them. - Configuring the run time network ( since we're on a provisioning network, we want the network to be configured for when the system reboots ) - Configuring any bonded interfaces - Continuing to send off logs to some out of band logging mechanism - Calling certain webhooks/triggers at the start and the end of %post In our RAID kickstart, we use it as a quick/dirty way of having an OS available to configure the hardware RAID on our different hardware classes. We do it this way because it's difficult to rescan the disks after you configure the RAID and making sure you get the right ordering. So instead, we kickstart, configure the RAID, reboot, and then go into the OS kickstart. In the RAID kickstart, we never go past %pre. But basically, we PXE boot into the KS, download the RAID utilities and the configuration for the specific hardware class from a remote host, configure the hardware RAID, then reboot. There are other steps but they deal mostly with our orchestration process. One of the hangups we've had is that there are no ipmi tools available ( or installable ) in this pseudo-OS environment, so we can't tell the host to PXE boot itself again ( in case the network isn't first in the boot order ). Because of this, we're looking to move away from this configuration and using a real OS ( like alpine, tinylinux or something along the lines of the project hanlon microkernel ) * What can I do to make your life easier? What annoys you about kickstart right now? What do you wish it did? What do you wish it didn't do? Would making it more like a language be helpful? Would making it easier to define site-specific commands be helpful? #1 - Better/consistent documentation about the lesser known features. #2 - Probably the thing that has caused the most headaches is the difficulty in using/starting utilities/services that require kernel modules, such as iptables or ipmi. That and disk detection/boot ordering has proven rather flaky. There's the --onbiosdisk option, but it doesn't always work. I'm not if making it more like a language would be helpful - that would probably depend on entirely how useful the language was. #3 - We probably don't need it because of our use of Cobbler/Cheetah, but perhaps some way of providing an attribute file to download on the kickstart command line, and then being able to use the key=values in that attribute file to templatize/fill in values in the kickstart file. On 3/2/16, 8:54 AM, "kickstart-list-bounces at redhat.com on behalf of Chris Lumens" wrote: >Hey everyone, I've been maintaining pykickstart and kickstart support in >anaconda in general for a very long time now, though I've not been very >active on this list. > >I'm going to be looking at kickstart exclusively for the forseeable >future. Specifically, my focus is going to be on widening its adoption >and making it more useful to everyone. The first step in this process >is information gathering. > >Here's what I would like to know from you guys: > >* How do you use kickstart right now? What work flows do you have >around it? Do you generate kickstart files from some process? Do you >store them in version control? > >* What do you do in your kickstart files? Do you have extensive %pre >and %post sections? If so, what kinds of things are you doing in them? >Are you doing anything that would be generally useful that I should be >doing for you? Do you ever use %traceback? Do you have unusual stuff >going on in %packages? > >* What can I do to make your life easier? What annoys you about >kickstart right now? What do you wish it did? What do you wish it >didn't do? Would making it more like a language be helpful? Would >making it easier to define site-specific commands be helpful? > >I know this is all really vague stuff, but I am just starting out on >this project. I don't even really know where this is going to take me >yet. > >I'd also like to emphasize that whatever I end up doing, I want to keep >compatibility with kickstart as it exists today. That's something I >take seriously in pykickstart. > >- Chris > >_______________________________________________ >Kickstart-list mailing list >Kickstart-list at redhat.com >https://www.redhat.com/mailman/listinfo/kickstart-list From clumens at redhat.com Tue Mar 8 19:48:27 2016 From: clumens at redhat.com (Chris Lumens) Date: Tue, 8 Mar 2016 14:48:27 -0500 Subject: moving kickstart forward In-Reply-To: <56DF1C45.9030802@gmail.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307170330.GD416@exeter.usersys.redhat.com> <56DF1C45.9030802@gmail.com> Message-ID: <20160308194826.GA16965@exeter.usersys.redhat.com> > Although I also like Jinja2 and mentioned it in my last email, quoting '{' > and '}' characters is ugly, and I suspect they're common in %pre and %post > shell scripts. If you used it, you'd have to parse shell sections out first > and run the remainder through the template engine. %pre and %post (and all the other sections besides %packages, for that matter) can be anything. You can specify the interpreter, so I have to treat those as black boxes. So yeah I would need to be careful to not run them through any template engine. The exact details of the processing would have to be really well documented. - Chris From Tim.Mooney at ndsu.edu Tue Mar 8 20:22:02 2016 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Tue, 8 Mar 2016 14:22:02 -0600 (CST) Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: In regard to: moving kickstart forward, Chris Lumens said (at 11:54am on...: Thanks for the opportunity to provide feedback and be part of the improvement process. > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? We've been using kickstart a long time -- pre "Enterprise" in Red Hat Linux. Our original kickstart files were created manually, and we've just updated them for the slight syntax changes over the years. We have Red Hat Satellite, but we've never used its kickstart functionality. We're comfortable with hand-editing the kickstart files to get what we need. We have separate "template" files for RHEL 5 (32 & 64), RHEL 6 (32 & 64), and RHEL 7 on physical servers, and separate templates for those variants on VMware. The only real differences between the physical & virtual templates is the default NIC names and how we do partitioning. Those are also about the only two areas of our kickstart files that ever change from system to system. When I say "template", I really just mean a master copy that we make minor edits to (season to taste) for a particular system build. Like the environment that Spike mentioned in his post, we generally do static installs. We never use DHCP for servers and some of our admin team is uncomfortable with PXE being enabled for our server subnets, so kickstarting a box involves an admin using either a physical or a virtual console and feeding in the kickstart file via http. > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? Not so much %pre, but definitely %post. I'm very impressed with some of the %pre scripts I've seen posted here over the years, especially the ones that do smart things with partitioning (like avoiding SAN-attached devices, etc.), but we've kept our partitioning (mostly) fixed, manually selected, and just been careful to detach existing SAN devices during kickstart, etc. Our %post, which uses --log=/root/post-install.log --interpreter perl is lengthy, but does the exact same thing on all our hosts: 1) minimal fixups to what authconfig did for proper authentication (including fixups to Kerberos config & PAM for things that 'authconfig' doesn't allow us to configure), group, and user setup so that a sysadmin could get logged in to the system immediately after kickstart, in the event that something went wrong. 2) register with our Satellite and pull down updates. 3) set up a local repo, install puppet and get set up for puppet to manage the system for the remainder of its life. We used to do a lot more in our %post, but in general managing the state of our systems has moved into our configuration management system (currently puppet). Our %post is now minimal setup to get just the basics in place so that configuration management can take over. > If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? I knew about %traceback, but it hasn't been well-documented enough for me to invest in ever using it. If it were well documented, there's a good chance we would make use of it, as necessary. > Do you have unusual stuff > going on in %packages? We install our systems as minimally as possible (%packages --nobase). Configuration management then layers on just the appropriate packages for whatever the role the system is going to play. If you remove the comments, our packages section (at least for RHEL 7.x) never changes, and looks like: %packages --nobase -ivtv-firmware -atmel-firmware -zd1211-firmware perl wget authconfig openldap-clients pam_krb5 ntpdate %end > * What can I do to make your life easier? The suggestion that others have had, about automatically providing more of the system details, either as environment variables or a JSON data structure or something similar is something I would echo. Having all of that automatically, without having to write a lot of code in %pre or %post to gather it, would be very useful. > What annoys you about > kickstart right now? I understand why upstream & Red Hat thought it was a good idea to move to "consistent NIC name", but that's actually been a major pain to deal with when kickstarting. Our templates now generally predict what the NIC name is going to be, but there's still plenty of times when I have to re-start a kickstart because the converged network adapter is e.g. p2p1 instead of p1p1, etc. Not kickstart's fault, but the move definitely impacts system management. We use software RAID extensively on our physical systems, so being able to pass more parameters to mdadm would be really handy. As it is, if I need to do anything esoteric, I have to skip using the kickstart primitives for partitioning and raid and do it all in a %pre. As far as I can tell, there's still no support for doing a network kickstart in a pure IPv6 environment. Having that would be nice, but I wouldn't call it high priority. > What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? The fact that we can choose the interpreter and write our %post script in a full-blown language of our choice gives us a lot of power & flexibility. The only place where I find myself wishing the kickstart DSL had more functionality is conditionals for the partitioning primitives. I'll agree with others that having more system details available automatically would be handy, but beyond that I don't know that I personally would get much value from additional domain-specific primitives. Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From clumens at redhat.com Tue Mar 8 20:49:39 2016 From: clumens at redhat.com (Chris Lumens) Date: Tue, 8 Mar 2016 15:49:39 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307161728.GC416@exeter.usersys.redhat.com> Message-ID: <20160308204939.GB16965@exeter.usersys.redhat.com> > We gather mac address, and some basic hardware stats, we will be > collecting more network information in the future. We get the uuid from > our asset database, along with recording who initiated the load. We put > this into a file in /tmp that can be sourced by bash scripts. It's easy > enough to parse with python in that format too. I think we could gather and provide a lot of this for you - probably both to the environment running the kickstart file (in the form of something you can source in, or a config file, etc.) and to the server where the kickstart file lives. > This is in python, and we make use of blivet for inspecting the disks. We > used to parse the output of parted, and dig around in the system directly. > Things we do currently: > - check if the system is EFI, and if an EFI partition already exists > - check if there's a windows install already present by presence of ntfs > partition(this ties into the bootloader magic later) > - delete existing linuxNative, PARTITION_LVM and PARTITION_SWAP partitions > - attempt to ignore everything that's removable, readonly, or USB > - Choose the most appropriate of the remaining disks to install to by > largest available space > - write part/logvol lines to a file in /tmp that's an %include in the > kickstart I feel like something in here is a prime candidate for being provided as a blivet or kickstart tool, but I can't yet put my finger on exactly what. Finding all the removable/read-only/USB stuff and generating an ignoredisk line sounds like it would be useful. I think that's come up several times now. > Partly this is because we want a dualboot setup with EFI and windows 7, > which doesn't really support EFI. The magic is more to work around the > windows limitations than EL's. We install refind, and move some files > around. Also, we create an efi entry ourselves because the > --leavebootloader option doesn't always work. Again, something I've been > lazy about looking into. Even if it did, we'd need to put some files in > place to get a sane dualboot setup working. I think problems with --leavebootloader not working would also be worth a bug report. The rest of it does sound pretty site-specific, but if there's anything you think other people are interested in, it would be worth me looking into adding it. > Yea. I've definitely been one person pushing for that since our installs > happen around untrusted users. I was thinking something along the lines of > a "AllowSpokeInteract --spoke SpokeName " directive or it's negative > counterpart. Having an all or nothing option would probably be sufficient > for us. I wonder about leaving this completely up to the installation program to define. There's two things we've got in anaconda right now that could be used to accomplish this, and pykickstart doesn't have to know about either of them. (1) There's the %anaconda section which handles the pwpolicy command. It could be extended to provide this. (2) There's now the user interaction spec (https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction-config-file-spec.rst) and the part of anaconda that processes the kickstart could possibly write out a file that would lock things down. The reason I'm going back and forth on leaving it up to the installation program to handle this is because I'm trying to work on getting kickstart more useful outside of Fedora/RHEL, so I don't know whether adding this as part of core kickstart is helpful or not. But it's definitely an idea to consider. > Even some basic things would be welcome. For instance being able to > reference the release it was booted with or the hostname would help > de-duplicate our kickstart files. Yeah, definitely. I'll add this to my todo list and start thinking about what useful information could be provided and what format it could be provided in. > I looked back at my notes about this. It switches to tcp when you change > the port to something other than 514. Either a --protocol or --udp/--tcp > flags would probably give the added flexibility. There's nothing in pykickstart right how that would prevent you from doing something like this: logging --port=1234:udp Do you have a bugzilla account? If so, you should open a bug against anaconda for this. It should be easy to fix. If not, I could open a bug for you I guess. - Chris From clumens at redhat.com Tue Mar 8 21:05:09 2016 From: clumens at redhat.com (Chris Lumens) Date: Tue, 8 Mar 2016 16:05:09 -0500 Subject: moving kickstart forward In-Reply-To: <56DF1BF1.3070701@gmail.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307153923.GB416@exeter.usersys.redhat.com> <56DF1BF1.3070701@gmail.com> Message-ID: <20160308210509.GC16965@exeter.usersys.redhat.com> > The ability to evaluate a line or lines based on whether a word appears in > the kernel cmdline would go a long way. In Jinja2 style (assuming cmdline > is an array of words from /proc/cmdline): > > {% if "softraid" in cmdline %} > ... whatever software raid args > {% endif %} Ah, that is a pretty clever idea. You'd probably want them to be namespaced somehow ("ks.softraid", for instance) but that's just a boring implementation detail. > The other thing I'd really like to see is the ability to set chunk size for > software RAID arrays. It defaults to 512K in mdadm and there's no way to > specify a size in kickstart. That default performs terribly in all of the > workloads where I've tested it. Our ability to specify options to partitioning tools at various levels (mkfs.whatever, mount, etc.) is pretty haphazard. This is basically because we have only ever added these as-needed, basically for each single bug that comes in. It would be worth rethinking everything in this area - providing ways to set options at all levels, giving these options obvious names, and perhaps getting rid of kickstart options that are just pass-throughs to some underlying tool option. In this particular case, I'd suggest that if 512K is a bad default for all workloads, it's a bug in mdadm (or wherever sets it) and should be fixed there. But your larger point is well taken. - Chris From clumens at redhat.com Tue Mar 8 21:33:44 2016 From: clumens at redhat.com (Chris Lumens) Date: Tue, 8 Mar 2016 16:33:44 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160308213344.GE16965@exeter.usersys.redhat.com> > We use %pre to obtain info about the system like: > Which NIC to configure > Hostname > IP > MASK > Primary user > Admin user > What OU the host should be added > And the original proc/cmdline (so I can get some info like what kickstart > file was originally used in the PXE boot) > > These are all placed in /tmp/installVars as key=value This is yet another vote for doing this in kickstart. It seems like probably the #1 thing everyone wants, and then maybe #2 is either user interaction/logging or better partitioning. I'll put this on my todo list accordingly. > It would be GREAT if we could get user input a little easier than using our > own scripts in %pre > > I would like to +1 on the getting "%pre --log /tmp/ks-pre.log" working, > currently my work around is > exec < /dev/tty3 > /dev/tty3 2>&1 > chvt 3 > ( > ... > ) 2>&1 | /usr/bin/tee -a /tmp/ks-pre.log Every time I see this exec/chvt/tty stuff my eyes just glaze over. But yes, it does seem like everyone's built their own method for either prompting for bits of data or for doing progress reporting. I think we were initially hesitant to do this because we saw kickstart as entirely non-interactive and also because anaconda wasn't really much of a library. It is probably time for us to define a real API here. So, I'll ask some followup questions just for this. What kinds of user interactions do people want to do? Do you want this to happen in the graphical interface or the text interface? Both? When do you want to do them? In pre or post? During the installer proper? Could whatever you are doing be turned into an anaconda addon? Do you want results going to the log file? To the console? To whatever the interface is? - Chris From swellnit at cisco.com Tue Mar 8 21:58:30 2016 From: swellnit at cisco.com (Scott Wellnitz (swellnit)) Date: Tue, 8 Mar 2016 21:58:30 +0000 Subject: moving kickstart forward In-Reply-To: <20160308213344.GE16965@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160308213344.GE16965@exeter.usersys.redhat.com> Message-ID: <9311A5CC-9ED3-4864-8F9F-B9F228164CBC@cisco.com> +1 for partitioning work and better boot disk selection/configuration. The majority of our %pre is taken up with device-mapper/python code to determine what the OS disk should be across different HW models. Internal raid JBOD Boot from SAN Boot from FLASH/SD I will add, and possibly just us not doing our homework, that networking with rhel7 kickstart is a bit of learning curve. We are having trouble getting kickstart to only plumb and configure the nic that the PXE/DHCP request came over. It kickstarts, installs, reboots and now eth0 is configured but the nic with the public interface is now eth2 or eth3 . On 3/8/16, 4:33 PM, "kickstart-list-bounces at redhat.com on behalf of Chris Lumens" wrote: >> We use %pre to obtain info about the system like: >> Which NIC to configure >> Hostname >> IP >> MASK >> Primary user >> Admin user >> What OU the host should be added >> And the original proc/cmdline (so I can get some info like what kickstart >> file was originally used in the PXE boot) >> >> These are all placed in /tmp/installVars as key=value > >This is yet another vote for doing this in kickstart. It seems like >probably the #1 thing everyone wants, and then maybe #2 is either user >interaction/logging or better partitioning. I'll put this on my todo >list accordingly. > >> It would be GREAT if we could get user input a little easier than using our >> own scripts in %pre >> >> I would like to +1 on the getting "%pre --log /tmp/ks-pre.log" working, >> currently my work around is >> exec < /dev/tty3 > /dev/tty3 2>&1 >> chvt 3 >> ( >> ... >> ) 2>&1 | /usr/bin/tee -a /tmp/ks-pre.log > >Every time I see this exec/chvt/tty stuff my eyes just glaze over. > >But yes, it does seem like everyone's built their own method for either >prompting for bits of data or for doing progress reporting. I think we >were initially hesitant to do this because we saw kickstart as entirely >non-interactive and also because anaconda wasn't really much of a >library. It is probably time for us to define a real API here. > >So, I'll ask some followup questions just for this. > >What kinds of user interactions do people want to do? Do you want this >to happen in the graphical interface or the text interface? Both? > >When do you want to do them? In pre or post? During the installer >proper? Could whatever you are doing be turned into an anaconda addon? > >Do you want results going to the log file? To the console? To whatever >the interface is? > >- Chris > >_______________________________________________ >Kickstart-list mailing list >Kickstart-list at redhat.com >https://www.redhat.com/mailman/listinfo/kickstart-list From clumens at redhat.com Tue Mar 8 22:04:39 2016 From: clumens at redhat.com (Chris Lumens) Date: Tue, 8 Mar 2016 17:04:39 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160308220439.GF16965@exeter.usersys.redhat.com> > Never knew %traceback existed. Someone else mentioned it was not documented. I'll take care of that in pykickstart github which means it will eventually filter down into the other Fedora and RHEL guides. The summary is it's just like any other kickstart script, except it runs if anaconda hits a traceback. It's useful for reporting problems with the installation process, writing tests, that sort of thing. It's probably less useful for end users but you never know. > Because of our use of Cobbler, it comes prebuilt with some rather > lengthy %post and %pre sections. We actually have two main classes of > kickstarts - our RAID kickstart and our OS kickstart. Talking to the cobbler guys is on my list, after I sort through some more of this kickstart-list email. > In our OS kickstart, some of these things include: > In %pre: > - Sending logs off the system ( Cobbler accomplishes this via a > python script called anamon ). This allows us for remote monitoring > of the logs. Hah, anamon. Oh, that brings up memories. > - We call out to specific webhooks in both %pre and %post, as part of > our orchestration triggers/process Is this something we could do for you, or is it so very specific that there'd be no point? > - We do a bunch of a disk detection. I have a recent thread on here > about what we're trying to accomplish - but trying to find the first > disk in the BIOS boot order is a *pain* I will go back in the archives and take a look. > In %post: > - Adding custom yum repos that we want for the installation only This behavior changes all the time. On master at least, what should be happening is that your repo is only used for installation unless you use repo --install. So you should be able to use the repo command for this (depending on what release you are targeting). > - Continuing to send off logs to some out of band logging mechanism Are you able to use the logging command here? If not, is there something we could add to it to make it more useful? > - Calling certain webhooks/triggers at the start and the end of %post Same question as for %pre - could we do this for you? > One of the hangups we've had > is that there are no ipmi tools available ( or installable ) in this > pseudo-OS environment, so we can't tell the host to PXE boot itself > again ( in case the network isn't first in the boot order ). Because > of this, we're looking to move away from this configuration and using > a real OS ( like alpine, tinylinux or something along the lines of the > project hanlon microkernel ) I don't know if this will help you, but at least in RHEL 7.2 and recent Fedoras, ipmitool is present. > #1 - Better/consistent documentation about the lesser known features. Yep, this is definitely high up on my list of things to do. > #2 - Probably the thing that has caused the most headaches is the > difficulty in using/starting utilities/services that require kernel > modules, such as iptables or ipmi. I don't know if we can do anything about this. > That and disk detection/boot > ordering has proven rather flaky. There's the --onbiosdisk option, > but it doesn't always work. I'm not if making it more like a language > would be helpful - that would probably depend on entirely how useful > the language was. We've taken steps across several releases (going back into RHEL6 at least) to let you specify disks in other formats besides simply /dev/sda. You can use /dev/disk/by-id/whatever, for instance. Basically you can use anything that udev sets up. Has any of this been useful in dealing with disk ordering problems? > #3 - We probably don't need it because of our use of Cobbler/Cheetah, > but perhaps some way of providing an attribute file to download on the > kickstart command line, and then being able to use the key=values in > that attribute file to templatize/fill in values in the kickstart > file. Yep, this is a variation on the theme of providing system information to both the installer and to the server with the kickstart file. I'll make a note of it. - Chris From Steven_Hajducko at intuit.com Tue Mar 8 22:42:19 2016 From: Steven_Hajducko at intuit.com (Hajducko, Steven) Date: Tue, 8 Mar 2016 22:42:19 +0000 Subject: moving kickstart forward In-Reply-To: <20160308220439.GF16965@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160308220439.GF16965@exeter.usersys.redhat.com> Message-ID: >Hah, anamon. Oh, that brings up memories. :) It's not fantastic but cobbler had it and the benefit over the logging command is that it was easy to add our own custom log files that we generate. > >> - We call out to specific webhooks in both %pre and %post, as part of >> our orchestration triggers/process > >Is this something we could do for you, or is it so very specific that >there'd be no point? I don't think there'd be much point. These are really just curl commands out to specific URLs that then trigger further actions in our orchestration. There could be something to specify URLs to call at certain stages, but it's nothing that's needed, since curl does the job just fine. >> In %post: >> - Adding custom yum repos that we want for the installation only > >This behavior changes all the time. On master at least, what should be >happening is that your repo is only used for installation unless you use >repo --install. So you should be able to use the repo command for this >(depending on what release you are targeting). I believe we do use the repo command. > >> - Continuing to send off logs to some out of band logging mechanism > >Are you able to use the logging command here? If not, is there >something we could add to it to make it more useful? We send off custom logs that are generated via things like our chef-solo run. If the logging command supported this, it'd be more useful. > >> One of the hangups we've had >> is that there are no ipmi tools available ( or installable ) in this >> pseudo-OS environment, so we can't tell the host to PXE boot itself >> again ( in case the network isn't first in the boot order ). Because >> of this, we're looking to move away from this configuration and using >> a real OS ( like alpine, tinylinux or something along the lines of the >> project hanlon microkernel ) > >I don't know if this will help you, but at least in RHEL 7.2 and recent >Fedoras, ipmitool is present. Yeah, it's useful for 7.2, unfortunately we're still stuck on older OS releases for some of our builds ( all the way back to 5.10 ). > >We've taken steps across several releases (going back into RHEL6 at >least) to let you specify disks in other formats besides simply >/dev/sda. You can use /dev/disk/by-id/whatever, for instance. >Basically you can use anything that udev sets up. Has any of this been >useful in dealing with disk ordering problems? Not really. Our issue is that we have various different hardware configs and a generic kickstart, so there's no way to really say that the by-id is going to be the same across all those systems. We were using --onbiosdisk=80, but this failed because on certain hardware platforms, anaconda fails to discover the right edd info. One of the biggest issues we've had with disk ordering is when using Dell systems w/ their PERC HW controller - in certain setups, we have a few logical drives, and the rest of the drives are configured as JBOD (just bunch of disks). We get random results with this - the logical drive ends up being anything from /dev/sda to /dev/sdi. From gnetravali at sonusnet.com Wed Mar 9 07:13:34 2016 From: gnetravali at sonusnet.com (Netravali, Ganesh) Date: Wed, 9 Mar 2016 07:13:34 +0000 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: Hi Chris. I am glad to receive this email from you. I have been working on Linux OS (especially on RH Linux) side from quite some time. I am happy to say it is very flexible. One of the challenge I always face is remote installation in specific scenario. General practice at the big players like Data center, Carrier network operators etc is. Hardware vendor will deliver the hardware at the operator premises, racks it up, and do the cabling as per the network design/diagram and leave the premises. Because of the security reasons and other obvious reasons, it is always hard to get the physical access in those live environment. Customer will provide only the access to BMC, iLO, iLOM type of access to get the remote console to install the customized OS. This is very common practice in the industry. If person is sitting geographically remote location it is hard to mount the ISO remotely and perform installation. Some time back we tried to create the Kickstart with below option. 1. New hardware will be pre-installed with standard RHEL OS while delivering the hardware to customer from hardware vendor. 2. Configure the IP address to one of the Ethernet interface from remote console and ask customer to FTP the customized ISO to the new server. 3. We will have very small custom ISO created which we use only to boot the system, push the Kickstart and create the ramdisk from pre install step and copy the existing ISO from server hard disk partition and copy it to ramdisk and ask Kickstart installer to use the ISO from ramdisk. Step explained in #3 is works well with debian precede installer but not with Redhat Kickstart installer. Is it possible to provide the flexibility to read the ISO from ramdisk from Kickstart installer? Thanks Ganesh -----Original Message----- From: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Chris Lumens Sent: Wednesday, March 02, 2016 10:24 PM To: kickstart-list at redhat.com Subject: moving kickstart forward Hey everyone, I've been maintaining pykickstart and kickstart support in anaconda in general for a very long time now, though I've not been very active on this list. I'm going to be looking at kickstart exclusively for the forseeable future. Specifically, my focus is going to be on widening its adoption and making it more useful to everyone. The first step in this process is information gathering. Here's what I would like to know from you guys: * How do you use kickstart right now? What work flows do you have around it? Do you generate kickstart files from some process? Do you store them in version control? * What do you do in your kickstart files? Do you have extensive %pre and %post sections? If so, what kinds of things are you doing in them? Are you doing anything that would be generally useful that I should be doing for you? Do you ever use %traceback? Do you have unusual stuff going on in %packages? * What can I do to make your life easier? What annoys you about kickstart right now? What do you wish it did? What do you wish it didn't do? Would making it more like a language be helpful? Would making it easier to define site-specific commands be helpful? I know this is all really vague stuff, but I am just starting out on this project. I don't even really know where this is going to take me yet. I'd also like to emphasize that whatever I end up doing, I want to keep compatibility with kickstart as it exists today. That's something I take seriously in pykickstart. - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list at redhat.com https://www.redhat.com/mailman/listinfo/kickstart-list From jbacik at fb.com Wed Mar 9 15:15:22 2016 From: jbacik at fb.com (Josef Bacik) Date: Wed, 9 Mar 2016 10:15:22 -0500 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <56E03E0A.7070909@fb.com> On 03/02/2016 11:54 AM, Chris Lumens wrote: > Hey everyone, I've been maintaining pykickstart and kickstart support in > anaconda in general for a very long time now, though I've not been very > active on this list. > > I'm going to be looking at kickstart exclusively for the forseeable > future. Specifically, my focus is going to be on widening its adoption > and making it more useful to everyone. The first step in this process > is information gathering. > > Here's what I would like to know from you guys: > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > > I'd also like to emphasize that whatever I end up doing, I want to keep > compatibility with kickstart as it exists today. That's something I > take seriously in pykickstart. > Ran this by our provisioning team inside Facebook and our main guy in charge of anaconda had a few things, I've quoted them here """ - Actually document %traceback like it's a real thing. While it was mentioned on a list long ago that it was intended mainly for debugging and not really mentioned anywhere else I think it's potentially quite useful for recording tracebacks and sending them to a logging/build server. - Better high-level logging of the overall kickstart process somewhere, maybe to a separate log file (then we could tail/scribe_cat it). Examples "starting pre, partitioning X,Y,Z, installing package X, packages finished, installing bootloader" Syslog is too verbose and you'd have to regex out the interesting bits. (this is exactly what cobbler's anamon does) - Timing metrics would be handy, we fake this roughly in pre/post scripts. e.g. "took X to install Y package" or "took Y to install all packages" Also as a data point for them, we use a ton of %pre scripts to setup hardware RAIDs for various vendors, e.g. HP, LSI/MegaRaid, or Fusion IO cards. Ideally I'd like to make all of that somebody else's problem so we just say "give me X devices with Y config" without writing lots of copypasta bash, but I don't have any ideas how to make this better. They probably don't want to write a lot of vendor-specific tools. """ And then I'll add onto that with just one thing - Better testing. We recently transitioned off of centos6 to centos7's anaconda and it took us a good 6 months to get everything working again. We're in the process of moving to the latest version of anaconda altogether. A lot of those where anaconda specific issues, but some of them where problems with kickstart. The most specific example I can think of was this https://github.com/josefbacik/pykickstart/commit/0736fbc111a40b95fde59039829c7cdb50bcabde We have ipv6 everywhere internally and probably half of our clusters are ipv6 only. It's not hard to setup ipv6 only environments with VM's, it would be nice to see this stuff better tested between releases to make sure the basic functionality is working, it would save us lots of time running down regressions. By and large the kickstart part of our provisioning has been probably the most stable part of our whole provisioning workflow. Sure we have huge %pre and %post scripts but I don't think there's a lot you can add that would be generic. I know there are storage management projects at Red Hat around making the different RAID vendors able to be configured through one tool, it would be nice to see that integrated whenever it becomes usable. Thanks, Josef From clumens at redhat.com Wed Mar 9 15:48:00 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 10:48:00 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160309154800.GG16965@exeter.usersys.redhat.com> > We have Red Hat Satellite, but we've never used its kickstart > functionality. We're comfortable with hand-editing the kickstart files > to get what we need. I've added the Satellite people to my list of people to email. > We have separate "template" files for RHEL 5 (32 & 64), RHEL 6 (32 & 64), > and RHEL 7 on physical servers, and separate templates for those > variants on VMware. The only real differences between the physical & > virtual templates is the default NIC names and how we do partitioning. > Those are also about the only two areas of our kickstart files that ever > change from system to system. Could default NIC names be abstracted out somehow, perhaps by kickstart providing data about the system or by exposing options passed on the boot command line? That might be one way we can allow you to reduce your number of files. Partitioning is always going to be different, I suppose. > Not so much %pre, but definitely %post. I'm very impressed with some of > the %pre scripts I've seen posted here over the years, especially the > ones that do smart things with partitioning (like avoiding SAN-attached > devices, etc.), We've talked a little bit in IRC here about defining classes of devices. I think we could use that concept to make it easier to avoid devices. > 2) register with our Satellite and pull down updates. It's sad we don't more closely integrate with satellite. I'll take a look at that. > 3) set up a local repo, install puppet and get set up for puppet to > manage the system for the remainder of its life. > > We used to do a lot more in our %post, but in general managing the state > of our systems has moved into our configuration management system > (currently puppet). Our %post is now minimal setup to get just the basics > in place so that configuration management can take over. I'm also going to talk to the puppet people and see if there's anything we can do to work better with them. > I understand why upstream & Red Hat thought it was a good idea to move > to "consistent NIC name", but that's actually been a major pain to deal > with when kickstarting. Our templates now generally predict what the NIC > name is going to be, but there's still plenty of times when I have to > re-start a kickstart because the converged network adapter is e.g. p2p1 > instead of p1p1, etc. Not kickstart's fault, but the move definitely > impacts system management. You can specify network devices a couple other ways, for instance "link" if it's the only one that has a cable plugged into it. You can also specify device by MAC address. When disk names started moving around all the time, we allowed people to specify disks in a lot of other forms (by UUID, by label, using globs, etc.) Would something similar for NICs make it easier? > We use software RAID extensively on our physical systems, so being > able to pass more parameters to mdadm would be really handy. As it is, > if I need to do anything esoteric, I have to skip using the kickstart > primitives for partitioning and raid and do it all in a %pre. I think I responded to someone else about fs option stuff. We will be taking a look at what we can do here both from the kickstart side and from the blivet side. Because you're right, it's not very useful a lot of the times and it's kind of a mess in general. > As far as I can tell, there's still no support for doing a network > kickstart in a pure IPv6 environment. Having that would be nice, but > I wouldn't call it high priority. I know we don't test this on the installer team. I don't know if QA tests in an ipv6-only environment. Any bug reports you have here would be welcome. > The only place where I find myself wishing the kickstart DSL had > more functionality is conditionals for the partitioning primitives. This has come up once or twice already. We'll definitely be taking a look at what we can do for this. - Chris From clumens at redhat.com Wed Mar 9 15:51:47 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 10:51:47 -0500 Subject: moving kickstart forward In-Reply-To: <9311A5CC-9ED3-4864-8F9F-B9F228164CBC@cisco.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160308213344.GE16965@exeter.usersys.redhat.com> <9311A5CC-9ED3-4864-8F9F-B9F228164CBC@cisco.com> Message-ID: <20160309155146.GH16965@exeter.usersys.redhat.com> > +1 for partitioning work and better boot disk selection/configuration. > The majority of our %pre is taken up with device-mapper/python code to determine what the OS disk should be across different HW models. What would better boot disk selection/config look like to you? - Chris From clumens at redhat.com Wed Mar 9 16:28:50 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 11:28:50 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160308220439.GF16965@exeter.usersys.redhat.com> Message-ID: <20160309162850.GI16965@exeter.usersys.redhat.com> > Yeah, it's useful for 7.2, unfortunately we're still stuck on older OS > releases for some of our builds ( all the way back to 5.10 ). More unfortunately, I don't think much of what I'm doing here will make it into previous releases. Small tweaks and bug fixes can probably be backported, but I am planning on being much more ambitious and that kind of stuff is probably only bound for future releases. - Chris From clumens at redhat.com Wed Mar 9 19:00:54 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 14:00:54 -0500 Subject: moving kickstart forward In-Reply-To: <56E03E0A.7070909@fb.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <56E03E0A.7070909@fb.com> Message-ID: <20160309190054.GL16965@exeter.usersys.redhat.com> > - Actually document %traceback like it's a real thing. While it was > mentioned on a list long ago that it was intended mainly for debugging and > not really mentioned anywhere else I think it's potentially quite useful for > recording tracebacks and sending them to a logging/build server. Yep, better documentation in general is on the list and %traceback in particular will be documented. There are other sections supported by kickstart, too, that aren't really documented. > - Better high-level logging of the overall kickstart process somewhere, > maybe to a separate log file (then we could tail/scribe_cat it). > Examples "starting pre, partitioning X,Y,Z, installing package X, packages > finished, installing bootloader" Syslog is too verbose and you'd have to > regex out the interesting bits. (this is exactly what cobbler's anamon does) I think this is entirely an anaconda thing, but sure. Logging improvements are always needed and seldom looked at. I think we do entirely too much logging of pointless stuff, and then the useful stuff is not very discoverable. > - Timing metrics would be handy, we fake this roughly in pre/post scripts. > e.g. "took X to install Y package" or "took Y to install all packages" If we were more formal with our logging and wrote out markers at specific points, you could at least calculate this by looking at the timestamps on those lines in the log. > Also as a data point for them, we use a ton of %pre scripts to setup > hardware RAIDs for various vendors, e.g. HP, LSI/MegaRaid, or Fusion IO > cards. > > Ideally I'd like to make all of that somebody else's problem so we just say > "give me X devices with Y config" without writing lots of copypasta bash, > but I don't have any ideas how to make this better. They probably don't want > to write a lot of vendor-specific tools. It's true we don't want to write a lot of vendor-specific stuff. But there's probably still a lot we could do for you. I think there's going to need to be a followup thread asking specifically what kinds of storage things people are doing. We're going to need examples to be able to spot patterns. > We have ipv6 everywhere internally and probably half of our clusters are > ipv6 only. It's not hard to setup ipv6 only environments with VM's, it > would be nice to see this stuff better tested between releases to make sure > the basic functionality is working, it would save us lots of time running > down regressions. This example did come up elsewhere too - briefly, I know we don't test ipv6-only on the installer team. The QA team might, but I do not know for sure. Any bug reports here would be helpful. Testing has been a major focus lately and has certainly improved, but any test system is only as good as its test cases. I know we do not have an ipv6-only one here. We probably don't have a lot of others that we could use. Suggestions welcome! - Chris From clumens at redhat.com Wed Mar 9 19:08:48 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 14:08:48 -0500 Subject: moving kickstart forward In-Reply-To: <1457289169_518@mail.cpinternet.com> References: <1457289169_518@mail.cpinternet.com> Message-ID: <20160309190848.GM16965@exeter.usersys.redhat.com> > For our test / dev sandbox, PXE boot menu options that specify build > parameters via the ks=URI to a php script i.e. > MACHINE_TYPE=vm,phy_hp,phy_ucs DISK_TYPE=flat,lvm DISK_SIZE=sm,med,large... > sometimes one-off's for specific builds based on hostname via dhcp reserved > ip address to be able to rebuild the same box over and over again for > testing. Would your setup be simplified by the suggestion that's come up several times in this thread - that we collect information from the target system and both provide it to the server where the kickstart file lives, and to the environment where the kickstart file runs? > Use %post to wget mgmt stuff - sudoers, ssh-keys, repo setup & security > validation & the like I'd be interested in more specifics here. I think probably a lot of people are doing similar sorts of stuff and I'm happy to make kickstart commands for common things. That's where the group, user, and services commands came from years ago. - Chris From clumens at redhat.com Wed Mar 9 20:25:28 2016 From: clumens at redhat.com (Chris Lumens) Date: Wed, 9 Mar 2016 15:25:28 -0500 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160307153923.GB416@exeter.usersys.redhat.com> Message-ID: <20160309202528.GN16965@exeter.usersys.redhat.com> > The desktop case, where things are sized based on disk and RAM size and > conditionally on EFI, might be doable with the addition of a few extra > bits of kickstart syntax. Do you have any ideas what you might like to see here? > Well, basically I have to install so much crap that I'd prefer to do it > while the system is actually up and running. That's not really in the > realm of something you'd want to do in kickstart, though. Basically, > things like Matlab and Mathematica are huge. Yeah, understood. I figured it would be stuff like this but it never hurts to ask. > Yes, that's what I'm talking about. I know I can hack the dracut > component of anaconda to pass more HTTP headers, but I really wish it > could just POST some JSON or something with as much info as possible. > Detected devices, DMI information, that kind of thing. It's high up on the todo list now after reading so many responses. > First, let me specify what happens on the machine while its installing. > I do almost all of my installs to user desktops remotely. If they walk > into their office at the wrong time, they see the generic anaconda > instructions and can get a passwordless shell. I'd really like to be > able to specify what they can see ("Touch this machine and I break your > hands" | cowsay), and at least protect that shell somehow. Some sort of locking or ACL came up elsewhere in this thread. I'd suggested it could be part of the %anaconda section we have now - we could further extend that to lock down the console. Seems reasonable. > Secondly, I really wish we had some sort of installation console. Currently, > dracut boots, DHCPs and tries to fetch a kickstart file once. There's > no way that I know of to have it wait there until a kickstart file is > ready. If there were, an application could show an admin information > about the machines waiting to be installed and allow parameters to be > set and such. If you've ever seen how the old school Scyld Beowulf > cluster stuff worked, you'd see what I'm talking about. I'm not familiar with it, no. I'll take a look and see if I can't find some screenshots. I wonder if such a thing would be better provided by another tool, though - cobbler or satellite or something. > And going along with that, having some specified way to get progress > information out of the installing system would allow a pretty complete > system for doing a whole pile of installations (which is something I do > twice a year). This would fit in with much improved logging. - Chris From hellstrom.mattias at gmail.com Fri Mar 18 08:40:01 2016 From: hellstrom.mattias at gmail.com (=?UTF-8?Q?Mattias_Hellstr=C3=B6m?=) Date: Fri, 18 Mar 2016 09:40:01 +0100 Subject: moving kickstart forward In-Reply-To: <20160302165424.GZ24235@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: I use one kickstart file with minor modifications for all installs Fedora/Centos. All my hardware is different, raid/no raid, different number of disks etc. so I get to set up disks in Anaconda. What I value most when it works, and irritates med most when it fails is resiliency to minor errors (I do understand that for a different application fail and reboot is a better way) for me, I'd rather get more spokes to do in Anaconda. Wish list: * Ability to modify parameters to the auto partitioning. Things like increasing default root partition size to 100GB or that default filesystem should be ext4 since xfs is too slow for my application. * Even better resiliency to minor errors. On Wed, Mar 2, 2016 at 5:54 PM, Chris Lumens wrote: > Hey everyone, I've been maintaining pykickstart and kickstart support in > anaconda in general for a very long time now, though I've not been very > active on this list. > > I'm going to be looking at kickstart exclusively for the forseeable > future. Specifically, my focus is going to be on widening its adoption > and making it more useful to everyone. The first step in this process > is information gathering. > > Here's what I would like to know from you guys: > > * How do you use kickstart right now? What work flows do you have > around it? Do you generate kickstart files from some process? Do you > store them in version control? > > * What do you do in your kickstart files? Do you have extensive %pre > and %post sections? If so, what kinds of things are you doing in them? > Are you doing anything that would be generally useful that I should be > doing for you? Do you ever use %traceback? Do you have unusual stuff > going on in %packages? > > * What can I do to make your life easier? What annoys you about > kickstart right now? What do you wish it did? What do you wish it > didn't do? Would making it more like a language be helpful? Would > making it easier to define site-specific commands be helpful? > > I know this is all really vague stuff, but I am just starting out on > this project. I don't even really know where this is going to take me > yet. > > I'd also like to emphasize that whatever I end up doing, I want to keep > compatibility with kickstart as it exists today. That's something I > take seriously in pykickstart. > > - Chris > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clumens at redhat.com Fri Mar 18 18:13:56 2016 From: clumens at redhat.com (Chris Lumens) Date: Fri, 18 Mar 2016 14:13:56 -0400 Subject: moving kickstart forward In-Reply-To: References: <20160302165424.GZ24235@exeter.usersys.redhat.com> Message-ID: <20160318181355.GC3166@exeter.usersys.redhat.com> > Wish list: > * Ability to modify parameters to the auto partitioning. Things like > increasing default root partition size to 100GB or that default filesystem > should be ext4 since xfs is too slow for my application. On master at least, you can change the filesystem type with --fstype=. There's also the reqpart command if you want to have the required arch-specific partitions created and then make the real filesystems yourself. In general, I'm hesitant to continue adding options to autopart because I don't want it to grow into a whole second parallel partitioning method. Either you get autopart, or you don't. > * Even better resiliency to minor errors. What kinds of errors are you having problems with? There's loads of places where things can go wrong, so if you can narrow it down a bit I can start looking into them. - Chris From mdrafi123 at gmail.com Sat Mar 19 22:07:31 2016 From: mdrafi123 at gmail.com (Mohammed .rafiullah) Date: Sat, 19 Mar 2016 17:07:31 -0500 Subject: moving kickstart forward In-Reply-To: <20160318181355.GC3166@exeter.usersys.redhat.com> References: <20160302165424.GZ24235@exeter.usersys.redhat.com> <20160318181355.GC3166@exeter.usersys.redhat.com> Message-ID: <3D6398CA-69D3-4EE5-8F60-AB0C7B9A3161@gmail.com> Thanks for your reply . I am getting TXE Mohammed.Rafiullah Mob.219 4278124 On Mar 18, 2016, at 1:13 PM, Chris Lumens wrote: >> Wish list: >> * Ability to modify parameters to the auto partitioning. Things like >> increasing default root partition size to 100GB or that default filesystem >> should be ext4 since xfs is too slow for my application. > > On master at least, you can change the filesystem type with --fstype=. > There's also the reqpart command if you want to have the required > arch-specific partitions created and then make the real filesystems > yourself. In general, I'm hesitant to continue adding options to > autopart because I don't want it to grow into a whole second parallel > partitioning method. Either you get autopart, or you don't. > >> * Even better resiliency to minor errors. > > What kinds of errors are you having problems with? There's loads of > places where things can go wrong, so if you can narrow it down a bit I > can start looking into them. > > - Chris > > From bwann at wann.net Wed Mar 30 19:04:31 2016 From: bwann at wann.net (bwann at wann.net) Date: Wed, 30 Mar 2016 12:04:31 -0700 (PDT) Subject: moving kickstart forward Message-ID: (I just joined this list so this isn't going to thread properly, sorry) Chris Lumens wrote: > This example did come up elsewhere too - briefly, I know we don't test > ipv6-only on the installer team. The QA team might, but I do not know > for sure. Any bug reports here would be helpful. > > Testing has been a major focus lately and has certainly improved, but > any test system is only as good as its test cases. I know we do not > have an ipv6-only one here. We probably don't have a lot of others that > we could use. Suggestions welcome! Hi, I was the main person at FB that was getting us onto CentOS 7 anaconda and helping with v6-only kickstart installs so I thought I'd chime in here. For v6 testing I would suggest having a router on the LAN so you get the full v6 router advertisement experience in addition to statically configuring things (even radvd on a box/VM should be fine). There were basically four bugs that tripped us up doing v6-only installs, and three of them were related to race conditions with v6 RA or kernel accept_ra problems. One was in dracut, one was NM/kickstart (that Josef mentioned), one in Anaconda and one in NetworkManager. I opened bug reports on these and reported my workarounds, so they're in the process of getting fixed up. I typed up a lengthy post that gives some background on these problems (with relevant bug ids) and my fixes in order to do v6-only kickstart installs. This may be helpful to other people who are in the same boat: https://binaryfury.wann.net/2016/03/installing-centos-7-on-an-ipv6-only-system/ --bwann