moving kickstart forward

[Chris Lumens]

> 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