[Fedora-livecd-list] Support for custom configuration using python templates
davidz at redhat.com
Fri Apr 27 01:44:27 UTC 2007
On Thu, 2007-04-26 at 16:51 -0400, John (J5) Palmieri wrote:
> > I think munging configuration files might be outside the scope of the
> > livecd-tools project; sure, granted it's something people want to do but
> > often it's used as a hack; for example on my system
> > $ rpm -qf /etc/issue
> > fedora-release-6.93-1
> And I'm going to package that up for every daily release? And what
> about countries? Too heavy and engineered for an image based
> > so I think what you *could* do instead is to have olpc-release or
> > similar on OLPC provide that file (would be based on fedora-release). Of
> > course, since /etc/issue is marked as %config(noreplace) in the
> > fedora-release it's still sane for you to edit it in %post. I guess it
> > all depends on the configuration file in question.
I think I said that both approaches works. Just make sure all files
being changed are tagged with %config(noreplace) if you care about RPM
upgrade paths (which you probably don't need to for OLPC but it's nice
nonetheless if someone wants to pick this up for hardware that can cope
with yum/rpm etc.).
> > So I think my point of view right now is that it's good enough to do
> > this in %post for most cases; I mean, if downstreams (like OLPC) need to
> > change a ton of configuration files/defaults perhaps there is something
> > broken with the apps you try to include?
> No just that apps can be configured for different purposes. For
> instance gedit can be made into a development environment but requires
> me to write out a bunch of gconf files. We have Sabyon for a reason.
> It basically does what I want to do in the case of gconf and some other
> settings. It is a dump of configuration files.
Sure, or you can use gconftool-2 or Puppet as Mark mentioned or
basically anything that gets the job done. My point really was that I
don't think configuration file munging belongs in livecd-tools proper.
Do you think that's wrong?
> > Perhaps you can come up with concrete examples of what configuration
> > files / defaults you need to edit /change? I think that would be useful.
> > Thanks.
> /etc/sysconfig/modules/olpc-1.modules for the module lists to load
> /etc/rwtab for stateless tmpfs mounted stuff
> /etc/asound.state to put the correct default sound levels
> /etc/modprobe.d/olpc.conf.dist so we get the correct module parameters
> /boot/olpc_build for build info that the bootloader uses
> /etc/issue for build info the user can read
> /etc/securetty for adding the serial console
> /etc/inittab for removing unneeded memory waisting VT's
> /usr/share/fonts/dejavu-lgc/fonts.dir for mapping legacy fonts
> /usr/share/fonts/dejavu-lgc/fonts.scale same as above
> /usr/share/fonts/dejavu-lgc/fonts.alias same
> /etc/X11/xorg.conf and its variants for booting on any device and
> getting the correct xorg config file with the correct keyboard laysouts
> /home/olpc/.xinitrc for launching sugar
> /boot/grub/grub.conf for the occasional qemu boot
> /etc/init.d/olpc-configure init script for boot time configuration
> /usr/share/X11/xkb/symbols/* for keyboard configuration that is not yet
> upstream (note that these must be added to an already existing file)
> /boot/olpc.fth - for booting from openfirmware
> Note that we can't move a lot of these to an RPM because RPM conflict
> rules would prevent them from being installed. Some files need input
> such as BUILD number and some files change so rapidly during the testing
> phase that taking the time to build an rpm and place it in the right
> spot and rebuild the repo would be a unneeded bottleneck.
So perhaps one maintainable way for you is to have a single script
(packaged up in a OLPC specific RPM) that does all the munging and your
%post simple invokes this? That script would know about per-country
things and what kind of "image" (e.g. jffs2, livecd, disk_ext3 etc.)
you're building by having the %post pass it as options? Wouldn't that
Of course, the question I raised in an earlier mail of how we pass items
to the %post script in the Kickstart file still stands. Jeremy? Perhaps
just setting environment variables works out of the box. I'd be
surprised if this is not the case.
Also, external variables used by higher level constructs that does batch
builds in a structured way (e.g. pilgrim-autobuild) needs to pass
(OLPC-specific) variables too such as BUILD_NUMBER, TARGET_COUNTRY etc.
to %post. I think the way I'd like this to work is that such variables
are transparently passed by livecd-tools and then the %post takes care
of it. Perhaps it would look like this
olpc-configure-system --image-type $LIVECD_TOOLS_IMAGE_TYPE \
--olpc-build-number $OLPC_IMAGE_NUMBER \
Would that work for you?
More information about the Fedora-livecd-list