<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What kind of information do you gather?  How do you store it to make it<br>
accessible for the rest of the install?  Is it in some sort of format?<br>
<span><br></span></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> - %pre script to do sophisticated partitioning and generated an %include<br>
> file(weeding out usb thumbdrives for instance)<br>
<br>
</span>What other sorts of things are you doing here?  I feel like we could be<br>
doing a lot better at either providing more high level partitioning<br>
commands, or tools that use blivet to inspect the system and generate<br>
kickstart chunks, or something.  Weeding out classes of devices is<br>
definitely something we can look at.<br></blockquote><div> </div><div>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:</div><div>- check if the system is EFI, and if an EFI partition already exists</div><div>- check if there's a windows install already present by presence of ntfs partition(this ties into the bootloader magic later)</div><div>- delete existing linuxNative, PARTITION_LVM and PARTITION_SWAP partitions</div><div>- attempt to ignore everything that's removable, readonly, or USB  </div><div>- Choose the most appropriate of the remaining disks to install to by largest available space</div><div>- write part/logvol lines to a file in /tmp that's an %include in the kickstart</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why do you need to remove packages in %post?  Is it stuff that's dragged<br>
in as dependencies that you then want to force-remove later? </blockquote><div> </div><div> 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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Also, what kind of bootloader magic is required?<br></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Along with this, a secured install is very important to us. we have the<br>
> unenviable position of loading workstations in buildings that are open to<br>
> the public.  We do a lot of work to verify the hardware and user are<br>
> allowed to get our load, and want to be able to control what can be changed<br>
> via a kickstart.  For instance, if it's an admin loading the machine, allow<br>
> them to change whatever,  if it's a employee from a different department,<br>
> allow only custom partitioning, and so on.  We'd be happy to configure that<br>
> via %pre scripts, but having the directives available is necessary for<br>
> that.<br>
<br>
</span>Basically, some sort of ACL for commands in the kickstart file?  That<br>
could get pretty complex in a hurry.  This does remind me that people<br>
have wanted a way of not allowing the user to interact with the UI at<br>
all during a kickstart install.  We could probably at least do that<br>
pretty easily.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> More built-in support for templating.<br>
<br>
</span>I've considered adding a template language step around kickstart.<br>
There's a ton of options here.  I just don't want to make a bigger mess<br>
of things given how a lot of people are already generating kickstarts<br>
using templates, or cobbler, etc.  So I just need to do a lot of<br>
research here before deciding what I can do.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> A minor thing is an improved logging command.  we log via udp on port 515<br>
> for installs.  This keeps it all separate from our production logs, but we<br>
> can't just tell kickstart that right now.  I've definitely been lazy, and<br>
> haven't gotten that bug put in or a patch posted.<br>
<br>
</span>I'd definitely be interested in any bug reports or patches around the<br>
logging command.  It hasn't seen any activity in a long time.  It does<br>
already support --host and --port, so I'd be curious what's going wrong.<br></blockquote><div><br></div><div>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. <br></div><div><br></div><div>-Ross</div></div></div></div>