Re: [Fedora-livecd-list] RFC- mayflower flexibility enhancements

[Douglas McClendon <dmc fedora filteredperception org>]

ashok shankar das wrote:
> Douglas McClendon wrote:
>
> > ashok shankar das wrote:
> >
> > > Douglas McClendon wrote:
> > >
> > > > Tim Wood wrote:
> > > >
> > > > > The one comment I'd have is would it be possible to feed some (or 
> > > > > all) of these options in as a config file? 
> > > >
> > > >
> > > >
> > > > Most of my RFC was basically about extending the functionality of 
> > > > the mayflower.conf config file.  But currently, as far as 
> > > > livecd-creator (and presumably revisor) is concerned, a 
> > > > mayflower.conf is hard-coded.
> > > >
> > > > The question is whether or not there is any reason to expose the 
> > > > livecd-creator or revisor user to these sorts of options.
> > > >
> > > > For the selinux enabled on an selinux disabled system, I think this 
> > > > should all happen inside livecd creator, and cause things to 'just 
> > > > work' (versus now, where it detects the situation, and says 'too 
> > > > bad, you can't do this').
> > > >
> > > > For the anaconda rpm build as non-root user, this really has nothing 
> > > > to do with livecd-creator or revisor.
> > > >
> > > > And for the vastly trickier idea of livecd-creator as non-root, 
> > > > again, there is no aspect that the livecd-creator or revisor user 
> > > > should care about, other than having it just work.
> > > >
> > > >
> > > >  Then (I believe) someone could
> > > >
> > > > > have a kickstart and a config file to handle everything.  Then 
> > > > > Revisor would need one additional field to select the path to this 
> > > > > config file.   A couple of advantages:
> > > > > * A sample kickstart and a sample config with lots of comments and 
> > > > > all the options plus a basic tutorial would be all the 
> > > > > documentation many people would need
> > > > > * It would make it much simpler to return to a project months later 
> > > > > and tweak/tune/use it (find 2 files you left in /etc/revisor/... 
> > > > > vs. files there, notes somewhere else and maybe some custom bash 
> > > > > code somewhere else)
> > > >
> > > >
> > > >
> > > >
> > > > What you are getting at here, is really the crux of the debate I had 
> > > > with jeremy over the addsdir/addidir patch, and the ideal of 
> > > > reproducability from a _single_ config file.
> > > >
> > > > The basic problem, which I think you solved with your outline above, 
> > > > is that kickstart is simply not appropriate to be the one _single_ 
> > > > config file for a livecd project.  The two examples that immediately 
> > > > spring to mind are
> > >
> > >
> > > I agree, Kickstart should not be the_ only_ file for configuration.
> >
> >
> > Actually I sort of argued both sides of that coin.  And I ended up 
> > changing my mind.  What sorts of option and configuration do you think 
> > should not be in kickstart, but somewhere else?
> >
> > > > 1) files added to the iso filesystem.  E.g. like ubuntu's inclusion 
> > > > of the windows firefox installer.  Or a generic web page to be 
> > > > viewed under windows when the livecd is inserted in a windows system.
> > >
> > >
> > >
> > > Why only LiveCD, think beyond the liveCD. Eg. Small systems can be 
> > > fit on to a USBstick, Rescue systems, small network servers, small 
> > > streamers etc...
> >
> >
> > usbstick (especially with livecd-iso-to-disk) is really just an 
> > alternate form of livecd.
> >
> > But yes, the changes I proposed to mayflower can also be used to 
> > generate initramfss that are useful as rescue systems, and perhaps 
> > even as entire-system-in-initramfs for small servers/routers.  I never 
> > suggested it was useful for livecd only.
> >
> >
> >
> > > > 2) the persistence feature.
> > >
> > >
> > > It is a must have feature. But again this should be configurable. 
> > > Currently Which I developed is doing a persistence at the time of 
> > > instalation(again a bit hard coded).
> >
> >
> > I'm still curious where this implementation you speak of that you 
> > claim was posted to this list is.  Please repost or give a link to an 
> > archive post.
>
> I have a very vague vison fo what to be separated. I think the target 
> specific things should be on a separate file.
> from which the KS file can read and work acordingly. As an example the 
> drivers which goes into the initrd are hard coded.

%post mayflower invocation

> Suppose i got a weired hardware which needs some special drivers then i 
> am helpless in current scenario.

%post mayflower invocation

> why should be there a ISO-to-USB script? 

because it's so blaringly obviously convenient and useful.  Especially 
for people that downloaded the f7 livecd, want to boot from usb, and 
have no interest in running livecd-creator or something similar on their 
system.

This sort of configuration
> should go into separate config file too.
>
> Try using KS file only for the package instalation and post 
> configuration of the installed system.
> Try to Implement a Config based image creation and target setup.

I'm still not seeing any example where its necessary.


> I can say this much at this time.

So what you're saying, is that you are waving your hands about this 
alleged persistence implementation of yours, which offlist you claim has 
already been posted to the list, but when asked to actually provide a 
link to the post or the implementation, you've got nuthin.

-dmc

> > I'm curious whether your implementation has design aspects that are 
> > better than the implementation I posted a couple weeks ago, and 
> > discussed at length on this list in the couple weeks before that.
> >
> > (as I've told Tim offlist, I'll be posting an updated version of that 
> > implementation within the next couple of days.  I'm just honing my git 
> > skills at the moment)
> >
> > -dmc
> >
> > > > OTOH, here is how I guess I could imagine cramming everything into 
> > > > the kickstart-
> > > >
> > > > 1) have some truly magic livecd kickstart command to add files to 
> > > > the isodir.  This command would be silently ignored in the 
> > > > non-livecd case (or perhaps files copied to /iso or some arbitrary 
> > > > directory in a non-livecd kickstart invocation).
> > > >
> > > > 2) and this is rather key- put the mayflower invocation in the %post 
> > > > of the kickstart.  Perhaps even enclose it in a conditional, based 
> > > > on some variable that only gets defined in the livecd case.  Then 
> > > > perhaps even merge the livecd-creator code back into anaconda, ala 
> > > > the old kadischi anaconda rootpath livecd creation facility.  (yes 
> > > > Jeremy, I'm trying to give you nightmares ;)
> > > >
> > > > 2 as described (with or without remerge with anaconda) also gives 
> > > > you the ability to customize the initramfs (e.g. add persistence and 
> > > > similar mayflower optional features) in the %post of the kickstart.
> > > >
> > > > But I want to emphasize to anyone reading this far, that none of 
> > > > this really has anything to do with the simple modifications and 
> > > > simple functionality enhancements that I was aiming for in the 
> > > > parent RFC. This has been a tangent going down rearchitecting the 
> > > > kickstart/config file and invocation of livecd-creator.
> > > >
> > > > And actually, given what I described, I kind of like the uglier and 
> > > > uglier, but single kickstart solution.  (the other aspects which 
> > > > I've complained about in the past, I think I can see workarounds for 
> > > > as well)
> > > >
> > > >
> > > > -dmc
> > > >
> > > > --
> > > > Fedora-livecd-list mailing list
> > > > Fedora-livecd-list redhat com
> > > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list
> >
> > --
> > Fedora-livecd-list mailing list
> > Fedora-livecd-list redhat com
> > https://www.redhat.com/mailman/listinfo/fedora-livecd-list