moving kickstart forward

[Ross Smith]

>
> 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: <http://listman.redhat.com/archives/kickstart-list/attachments/20160307/556ad608/attachment.htm>