On Wed, 2007-01-10 at 14:26 -0500, Bill Nottingham wrote: > What we *want* to be able to customize is: > - default set of services to start > rPath has sent a patch for chkconfig that allows for this; it works > by writing override files for any service you want to change, > and then running chkconfig. Either this approach or we could move the kickstart service config to be doable from an installclass. > - sysctl settings > Allow for different sets of defaults depending on app/workload. > Server/desktop/router/etc. > A simple implementation would just be to allow for /etc/sysctl.d/, > and lay down files there, although there are integration issues > there (see below.) The same could apply here. /etc/sysctl.d is definitely going to make anything along these lines simpler, though > So, there are three issues that need solved: > > 1) What other parameters do we want modifiable? > > I'm open to ideas. > > The one that hits me is 'anything that can be specified in kickstart'; > reasonably, anything done there (well, excluding %post) should be able > to be 1) made a default 2) made required. > > Potential implementations of this: > > a) Ship a kickstart file in the spin that's used by default. > > Pros: Easily expandable to do anything we want, through the use > of %post > Allows for future expansion and automatic support of > any new anaconda features. > Cons: If we want the concept of 'setting defaults' that the > user of the spin can change, will need some reinterpretation > of how kickstart is used inside of anaconda. Unless I've > missed something. Ultimately, this kind of feels like its more and more the right thing to do. There's a fair bit of anaconda heavy lifting, though, so that kickstart isn't an install class and is instead just a data source. It _is_, though, a) doable and b) something we eventually want to do anyway. I guess the big question is "is it doable in time for F7" if we want to use it there... > b) Embed this information in the install class > > Pros: Doesn't use kickstart > Allows you change anaconda's UI, add/remove screens, etc. > Cons: Deeply ties you to anaconda versions. More likely to break ... although, this definitely works today and we could have this as a fallback for F7 if the first isn't doable in the timeframe. Has the con of needing to change how things are done for the second time around, but it would at least be the change to move things in the right direction. Doing this as a one-off would have the advantage of we could see what people actually _want_ to do and then be able to better make sure that the first meets people's needs. > 2) How do we package these modifications? If we go the kickstart route, then it's just a metadata/config file for the spin and doesn't necessarily need to be packaged. Jeremy
