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