[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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...


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)



Fedora-livecd-list mailing list
Fedora-livecd-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]