post_install_script options/interactivity

[Toshio Kuratomi]

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.  Additionally, just because I've scripted a portion of
anaconda's installer doesn't mean I don't want to configure the
remaining pieces by hand.  (anaconda itself allows for setting some
things within a kickstart while prompting for missing values.)

I think we want to copy the idea of cmdline, text, and graphical that
anaconda has into kadischi.  When kadischi is run in cmdline mode it
attempts to execute with only the values given on the cmdline.  When in
text/graphical it will preset and run with any options given to it on
the commandline but prompt for interactive use when something is
missing.

Does anyone have any thoughts or do I need to hack out a proof of
concept so we have something to tear apart?

-Toshio

[J. Hartline]

Toshio Kuratomi 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).

>  Additionally, just because I've scripted a portion of
> anaconda's installer doesn't mean I don't want to configure the
> remaining pieces by hand.  (anaconda itself allows for setting some
> things within a kickstart while prompting for missing values.)
>   
>  
Yes, but this isn't using cmdline method. An incomplete kickstart file 
will halt
Anaconda when using an incomplete kickstart file and cmdline method at 
the same time.

> I think we want to copy the idea of cmdline, text, and graphical that
> anaconda has into kadischi.  When kadischi is run in cmdline mode it
> attempts to execute with only the values given on the cmdline.
>  
This isn't absolutely correct.. cmdline method of Anaconda doesn't bring 
up any curses or GTK+ UI of any kind.

>   When in
> text/graphical it will preset and run with any options given to it on
> the commandline but prompt for interactive use when something is
> missing.
>   
>  
Without kickstart anything from timezone to root password is prompted for.

> Does anyone have any thoughts or do I need to hack out a proof of
> concept so we have something to tear apart?
>
>   
>  
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.

For example, Chitlesh asked me why we set the UID explicitly, and I have 
decided to change that.
Fedora Core's useradd will start at 500 UID regardless, as this is a 
default. Incrementing to the next UID.

J. Hartline

[Toshio Kuratomi]

On Wed, 2006-04-19 at 13:23 -0500, Jasper O'neal Hartline wrote:
>  Toshio Kuratomi 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?

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.)

>  > Additionally, just because I've scripted a portion of
>  >anaconda's installer doesn't mean I don't want to configure the
>  >remaining pieces by hand.  (anaconda itself allows for setting some
>  >things within a kickstart while prompting for missing values.)
>  >  
>  >
>  Yes, but this isn't using cmdline method. An incomplete kickstart file 
>  will halt
>  Anaconda when using an incomplete kickstart file and cmdline method at 
>  the same time.
>  
>  >I think we want to copy the idea of cmdline, text, and graphical that
>  >anaconda has into kadischi.  When kadischi is run in cmdline mode it
>  >attempts to execute with only the values given on the cmdline.
>  >
>  This isn't absolutely correct.. cmdline method of Anaconda doesn't bring 
>  up any curses or GTK+ UI of any kind. 
Err.. I think that's what I said. 
* The --cmdline method needs to take all options from the
commandline/config files and error if any information is missing.
* using --kickstart=[file] (alone or paired with --text/--graphical)
should set things up according to commandline/config but go interactive
if information is missing.

>  >
>  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.

* Do we need to coordinate with someone to get the changes merged in?
pykickstart for livecds?
* Does it make any sense to generalize the section for readonly root or
stateless type applications?  firstboot?
* What options do we want embedded in there?  Usernames and passwords;
selinux and firewall configuration; services to start....

-Toshio

[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