[Fedora-livecd-list] post_install_script options/interactivity

[Jeremy Katz]

On Wed, 2006-04-19 at 12:32 -0700, Toshio Kuratomi wrote:
> On Wed, 2006-04-19 at 13:23 -0500, Jasper O'neal Hartline wrote:
> > >04userconfig and 07accounts are different than the other
> > >post_install_scripts in that they both start interactive processes.
> > >Currently, if the user has selected to use kickstart or cmdline mode for
> > >anaconda, the functionality of these scripts are skipped.  This is okay
> > >to beat them into shape but we're eventually going to want to architect
> > >things so we can access the functionality when we're running anaconda
> > >noninteractively. 
> > >
> > Absolutely. See the http://fedoraproject.org/wiki/Kadischi/Schedule item
> > * make Anaconda ignore %livecd section, have Kadischi read this section
> > (This is a kickstart cfg file item).
> > 
> This sounds good if everyone agrees that kadischi and anaconda should be
> moving closer together.  Are we working towards the day when Kadischi is
> a special case within anaconda, Jeremy?

Fundamentally, I don't think all of the live CD functionality will be
subsumed into anaconda.  Much like with Xen guest installs where there
is a script which interacts nicely with the installation environment,
we're going to want the same for live CDs.  Some things will be handled
more directly within anaconda (eg, the boot loader stuff) but some
things make more sense to be handled without anaconda's interference

> Is this started yet?  Or are we going to have to wait for FC6's anaconda
> to deploy these changes?  (Hmmm... a rather ugly kludge: since kadischi
> parses the file first, kadischi can pull out the livecd section and
> write a temporary kickstart file that is passed on to anaconda.)

I think for things to be widespread useful, we're going to have to work
on them within the devel tree -- that means within the context of FC6.
Otherwise, we're going to always be a step behind on integration.  Doing
some prototyping with the FC5 bits is okay, but working with the devel
tree really isn't that painful.  Especially right now, things are slow.

> > Maybe a bit more clarification, I am very open to ideas and of course 
> > any additional items
> > or changes to scripts must be thought of as a starting point, the 
> > userconfig and accounts scripts
> > are nothing more than skeletons. It brings the idea into play, rather 
> > than a finished concept.
> 
> If the way forward is a special kickstart file section then I think I'll
> do some work there.  It looks like pykickstart holds the kickstart
> parser.  So we'd want to modify that to recognize the %livecd header.

This seems in line with what I'm currently thinking for handling Xen
guest bits as well via the addition of a %xen section.  It may end up
being that the right thing to do here is to change pykickstart to be
able to just ignore %foo sections that it doesn't know about.

> * Do we need to coordinate with someone to get the changes merged in?
> pykickstart for livecds?

Chris Lumens (clumens AT redhat DOT com) is the maintainer of
pykickstart.  anaconda-devel-list is probably the most appropriate list
for patches.  And I can throw things at him across the hallway ;)

> * Does it make any sense to generalize the section for readonly root or
> stateless type applications?  firstboot?

I'd rather start with specific bits and if some make sense to be more
general, then we can do so.

> * What options do we want embedded in there?  Usernames and passwords;
> selinux and firewall configuration; services to start....

Well, selinux and firewall can be handled already within kickstart.
We've avoided adding syntax to the ks.cfg for users/passwords and
service configs in the past just because they're so easily achievable in
%post. I could see trying to expand out some things that are currently
just %post actions into being more structured, although Chris may
disagree.

Jeremy