<div dir="ltr"><div>> ---------- Forwarded message ----------</div><div>> From: Chris Lumens <<a href="mailto:clumens@redhat.com">clumens@redhat.com</a>></div><div>> To: <a href="mailto:kickstart-list@redhat.com">kickstart-list@redhat.com</a></div><div>> Cc:</div><div>> Date: Wed, 2 Mar 2016 11:54:24 -0500</div><div>> Subject: moving kickstart forward</div><div>> Hey everyone, I've been maintaining pykickstart and kickstart support in</div><div>> anaconda in general for a very long time now, though I've not been very</div><div>> active on this list.</div><div>></div><div>> I'm going to be looking at kickstart exclusively for the forseeable</div><div>> future.  Specifically, my focus is going to be on widening its adoption</div><div>> and making it more useful to everyone.  The first step in this process</div><div>> is information gathering.</div><div>></div><div>> Here's what I would like to know from you guys:</div><div>></div><div>> * How do you use kickstart right now?  What work flows do you have</div><div>> around it?  Do you generate kickstart files from some process?  Do you</div><div>> store them in version control?</div><div>></div><div>> * What do you do in your kickstart files?  Do you have extensive %pre</div><div>> and %post sections?  If so, what kinds of things are you doing in them?</div><div>> Are you doing anything that would be generally useful that I should be</div><div>> doing for you?  Do you ever use %traceback?  Do you have unusual stuff</div><div>> going on in %packages?</div><div>></div><div>> * What can I do to make your life easier?  What annoys you about</div><div>> kickstart right now?  What do you wish it did?  What do you wish it</div><div>> didn't do?  Would making it more like a language be helpful?  Would</div><div>> making it easier to define site-specific commands be helpful?</div><div>></div><div>> I know this is all really vague stuff, but I am just starting out on</div><div>> this project.  I don't even really know where this is going to take me</div><div>> yet.</div><div>></div><div>> I'd also like to emphasize that whatever I end up doing, I want to keep</div><div>> compatibility with kickstart as it exists today.  That's something I</div><div>> take seriously in pykickstart.</div><div>></div><div>> - Chris</div><div>></div><div><div><br></div><div>Chris,</div><div><br></div><div>I have beaucoup gripes about the new anaconda introduced in RHEL7.</div><div><br></div><div>I realize that programmatically the old anaconda was held together with spit</div><div>and bailing wire.  So I realize the developer's motivation for rewriting</div><div>it.  But in so doing they took away considerable end user functionality.</div><div><br></div><div>Most of this is not ks.cfg related.  But some of it can be fixed via</div><div>improved ks.cfg syntax.</div><div><br></div><div>Let me preface this.  95% of what we do is static builds.  I've developed</div><div>the framework + PXE servers to do either static builds, DHCP builds or</div><div>PXE builds.  But the server provisioning teams chooses to do static builds</div><div>almost exclusively.</div><div><br></div><div>Formerly, if you didn't supply a device for your network ks.cfg line, it</div><div>would prompt you for a network device.  It's be a pop-up that listed</div><div>the available interfaces and you'd select your interface.</div><div><br></div><div>This was great, because depending on server model, your public interface</div><div>would be different.  Also, if one of your public NICs didn't work,</div><div>you could try your other public interface easily.  Reboot, choose the</div><div>other public NIC.</div><div><br></div><div>However, starting with the new anaconda this is now considered an error</div><div>for static builds.  You have to pre-declare your device as so:</div><div><br></div><div>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=<a href="http://austgcore05.us.example.com">austgcore05.us.example.com</a></div><div><br></div><div>I realize that you can specify --device=link, which specifies the first</div><div>interface with link up.  But that's usually our cluster interconnect and</div><div>not our public interface.</div><div><br></div><div>I realize for PXE builds you can specify --device=bootif, which means</div><div>use the interface you PXE booted from.  (This works great -- for PXE</div><div>builds).</div><div><br></div><div>I realize that this is all unnecessary for DHCP builds. You set up the</div><div>initrd=..... boot options to DHCP up the network, then your network line</div><div>is simple:</div><div><br></div><div>   network --bootproto=dhcp --noipv6</div><div><br></div><div>But for static builds, something like --device=ask would be great.</div><div>It'd provide a list of network interfaces, like the old anaconda did.</div><div>Text-based list would be fine.</div><div><br></div><div>Spike</div></div><div>PS I realize it was never ks.cfg that was showing this popup.  Instead, the</div><div>old anaconda was "pre-peeking" inside your ks.cfg for the network line only.</div><div>And taking this action, based on what it found therein.  So now it would</div><div>be the kickstart parser that would be taking this action.</div><div><br></div><div><br></div></div>