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

Re: selinux breaks revisor

Daniel P. Berrange wrote:
On Thu, Jan 24, 2008 at 06:59:47PM -0600, Douglas McClendon wrote:
Daniel P. Berrange wrote:

Plain QEMU is unusably slow for doing any real work - particularly compute
and disk intensive stuff like builds / composes.
Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http install under qemu, followed by mksquashfs of the result. Honestly I do a lot of data shuffling, and think that I could probably halve that time if I wasn't more interested in further functionality at the moment than I am in performance.

A 12 hour compose time fundmanetally limits the quality / speedy delivery
of LiveCDs because the turn around time between compose + QA cycles is being
bottlenecked. You can only do one compose & QA cycle per day. If a chroot
install takes < 1 hour you can get through 5 or more compose & QA cycles
a day.

I mean no offense, but it seems like every time I say anything on this list, people assume it means that I am advocating some change in the core infrastructure that everybody should use. When in reality, I'm merely trying to open the possibility to do something that just couldn't be done before.

My livecd generation system is dog slow, but its something that joe-user could download/install, and then use to create a custom livecd for personal or very limited use, *WITHOUT* requiring them to su to root, then have selinux disabled while livecd-creator runs.

Ok, so 99% of the people on this list can go ahead and think that that new functionality serves no useful purpose. I admit, I don't have a lot of users yet. But hey- I like it.

Getting back to your point- what I'm saying is that I'm not saying my tool is the right tool for everyone's job. If you saw my anti-selinux rant a while back, you may have noticed that I wasn't saying that selinux shouldn't exist, just that maybe it isn't the right tool for *every* job.

A while back on this list, I asked what parts of fedora required root privileges to be rebuilt. I.e. why you couldn't just rpmbuild --rebuild every last thing as a build user, never subjecting the build system to the impact of building as root. The answer seemed to come back that the only things that _really_ required root, were the creation of small filesystem-disk images. My tool qfakeroot provides a solution for that, and given the sizes of the images involved, will add but a few minutes to the rpmbuild--rebuild time.

I'll take that 12 hours over the 1hr for livecd-creator any day of the week, knowing that I'm not running about 1000 rpm post install scripts under the limited protection of a chroot with selinux disabled. Combined with the comfort of knowing that if I do a compose on a different piece of hardware, that those 1000 scripts will have no chance to sneakily incur any host build dependencies based on their access to a random /proc (as opposed to the consistency of always identical qemu /proc).

Do you inspect all these %post scripts ahead of time each time you do
a 'yum update' for your host machine.


Every time you yum update you're
running the same scripts in your host without even the chroot protection.
And if you don't trust the RPMs you're using to build the LiveCD images,
why should any user trust the resulting LiveCD you're about to distribute.

Trust is not absolute. I may want to do all kinds of experimental things with a LiveCD, that I wouldn't want to put on the particular build system. And please, don't be obtuse like everyone seems to be on this list and think that I just argued 180degrees against you. Your point is fine, and one I agree with, and have considered before and already take well into account. I'm _only_ suggesting that _maybe_ there are some people out there that can appreciate the functionality I'm bringing to the table, even with it's relative costs.

If you really don't trust the RPMs you're about to compose, then run the
compose on a throw away host - just re-kickstart it after execution.

You may call 12 hours for a compose unusably slow. I don't. And computers and software get improved all the time, so maybe in 3 years, that 12 hours will just become "order a pizza and wait for the results".

That's a fallacy. History shows that software increases its resource
requirements to easily match increases in hardware speed. Compare total
install time between RHL 5 and Fedora 8 - hardware has increased in performance dramatically, but install time is still effectivelly unchanged.

Yeah yeah, go ahead and be like the rest of the people here with that attitude. Just focus on countering everything I say, instead of maybe, just maybe admitting that the functionality I'm bringing to the table might actually be useful for quite a few scenarios.

"Fallacy". I mean Puhlease... Would it cause the world to end if some of the core fedora developers would try to actually be constructive? Was your comment there _really_ necessary? Yeah!!! you showed me how utterly wrong I was. What a 'fallacy' I uttered. Come on. Give me a break.


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