Due to mpm-itk needing apache to run as root, and have capability to drop privileges after-the-fact-itself, any tests that use apache require apache to run as root if mpm-itk is installed.
Combine this with the test suites themselves refusing to run as root ( mod-perl does this ), and we basically have an impossible combination.
For now, plan of action is:
1. Find affected packages
2. Open bugs blocking this tracker
3. Block mpm-itk in DEPEND="test? ( )"
There may be other ways around this than this, and hence this tracker
is in place for any brave people to go digging if a better solution is found.
Or alternatively, this ticket serves as a reason for removing mpm-itk, which atm is only used by app-backup/backuppc ( not sure why yet )
I'm not sure about mod_perl, but the other packages do the right thing and bring their own httpd.conf. Hypothetically that httpd.conf could be modified in the ebuild to load something other than mpm_itk if another MPM was *also* installed. But alas, there's bug 511658 blocking that solution.
Once apache-2.4 in Gentoo supports multiple MPMs, those perl packages could depend on at least one non-itk MPM. Then before the test suite kicks off, you would e.g. "echo LoadModule prefork.so >> httpd.conf".
(In reply to Michael Orlitzky from comment #1)
> I'm not sure about mod_perl, but the other packages do the right thing and
> bring their own httpd.conf. Hypothetically that httpd.conf could be modified
> in the ebuild to load something other than mpm_itk if another MPM was *also*
> installed. But alas, there's bug 511658 blocking that solution.
> Once apache-2.4 in Gentoo supports multiple MPMs, those perl packages could
> depend on at least one non-itk MPM. Then before the test suite kicks off,
> you would e.g. "echo LoadModule prefork.so >> httpd.conf".
As I understand it, those packages don't actually bring their own httpd.conf, they *generate* one from dev-perl/Apache-Test
And my expertise at understanding that sausage factory leaves me at a loss for how to direct it to generate a more minimal config.
For instance, Apache-AuthCookie *would* have an httpd.conf in this directory...
But it doesn't have one until this is run: https://metacpan.org/source/MSCHOUT/Apache-AuthCookie-3.26/t/TEST.PL
Ah, OK. I can at least explain the BackupPC thing, because I'm the one who added it. BackupPC was doing something ridiculous and shipping its own apache instance (config files and init script). Naturally that meant that it was years out-of-date with security updates, but it was because BackupPC relies on apache being run as the "BackupPC" user.
How to run apache as the BackupPC user while still using the system's regular apache instance? Sounds like a job for mpm_itk =)
I was able to drop the separate apache instance from BackupPC, but at the expense of requiring mpm_itk to be used. Now the vhost config for BackupPC runs as a separate user from all of the other vhosts, and there's no dumb security problem and BackupPC itself is happy because the website user is what it expects.
BackupPC was maintainer-needed when I did that, and the changes were made only to get it ready for apache-2.4. I would not mind anything that you decide to do to BackupPC.
Is there anything left to do here, or should I close this?
I think we can close this now. Though there are probably other instances of this problem in the wild that simply haven't been picked up by test runs.
Ideally it would be nice if there was a way so mpm-itk being installed didn't poison everything, but getting that working nice is too hard.
Ok, we can always revive the tracker when new problems pop up.