The one comment I'd have is would it be possible to feed some (or
all) of these options in as a config file? 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)
Tim Wood
On Aug 12, 2007, at 10:13 PM, Douglas McClendon wrote:
I have a few changes I'd like to request to mayflower. I'd
like to
get some feedback before actually laying down the effort of
producing patches.
#1 - mayflower.conf - add PROGRAMS and FILES
I'd like it if mayflower, in addition to supporting MODULES+=
lines, would also support PROGRAMS+= and FILES+=
PROGRAMS+= would be used for example, in my prior persistence
patch, to add things like ntfsmount.
FILES+= would differ from PROGRAMS, in that the auto shared library
dependency check would not apply to them. Maybe that doesn't
matter, and you could just have FILES.
#2 - support user specified mayflower.conf location
(i.e. not just /etc/mayflower.conf)
#3 - optional program, sort of like existing shell cmdline arg
Have a cmdline argument of program= and eprogram= which would cause
the specified program to be executed. program= would happen right
after the current shell, and eprogram would happen right after the
current eshell.
You would of course supply your own custom program via #1 above.
Now, you are no doubt asking, what would this be used for...
Answers:
1) support SELinux enabled livecd creation from an SELinux disabled
build system.
2) support building of anaconda rpm as a non root user
3) support livecd-creator as a non root user
Now you are no doubt asking, how do #1 #2 & #3 get you 1) 2) and 3)?
The answer is by implementing the qmkfs program I alluded to a long
time ago on fedora-devel, and it's more general incarnation, qrr
(qemu root run)
The idea is this- qrr is a script. qrr reads it's input, a config
file, describing a program and some data. qrr then invokes
mayflower (as a user, not root, with #2) to generate an initramfs,
that is basically the same as the livecd initramfs, but with extra
programs, specified by the config file, and added with #1. Then,
qemu is invoked with #3, somewhat like this-
mkdir ./my_input_output_dir
cp -av <user supplied input data> ./my_input_output_dir
qemu-img create scratch.img 10G
qemu -kernel /boot/vmlinuz-$(uname -r) \
-initrd ./my_mayflower_generated_initrd.img \
-append "program=/my_custom_qrr_program" \
-hda ./scratch.img \
-hdb fat:rw:./my_input_output_dir
Thus, the mayflower initramfs boots, runs the user supplied
my_custom_qrr_program, which mounts the my_input_output_dir, and
proceeds to process it with root privs (i.e. it can do loopback
mounts, selinux relabeling, etc...), and then leaves its output
(e.g. a filesystem image) in my_input_output_dir.
I think that the changes involved with #1 #2 and #3 are fairly
minor, elegant, and safe. Actually implementing 1) and 2) are a
bit tricky. 3) is probably a lot tricky, but arguably worth the
effort.
Mainly I want this feature (qrr) for my own currently private
project, though I would definitely go ahead and implement 1) as
part of the patchset to be submitted for merging, which I think is
justification enough for #1 #2 and #3.
In general, the ability to use mayflower to construct arbitrarily
useful custom purpose initramfs-s, seems quite useful. I imagine
that when people really start to think about this, and what it
allows, they will come up with many uses that I would probably
never imagine.
Personally I am hoping for a koji/pungi/livecd-creator/revisor that
does not require root privileges at all. It seems to me like there
should be no reason why a non-root user cannot take the fedora cvs/
git trees, and output (customized) F9 media sets.
I realize this may sound like a lot of stuff, but please focus on
how small and safe the patches to support #1 #2 and #3 really are.
Also, I have basically done this somewhat manually. (tweaked
mayflower, generated initramfs as user, booted qemu to get
arbitrary program to run)
questions/comments/criticisms?
-dmc
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list