> ---------- Forwarded message ----------
> From: Chris Lumens <clumens@xxxxxxxxxx>
> 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.
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
