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

[Douglas McClendon]

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