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
Show replies by thread