# set a reasonable MM_CORE_PATH location.. sed -i 's:logs/mm:/var/cache/apache-mm/mm:' \ src/include/httpd.h ^^ is a sniplet from the ebuild. hardcoded paths prevent multiple unprivileged apache instances. I can't see what's wrong with logs/mm. However if someone insists on this path, then sed -i 's:logs/mm:logs/mm/mm:' src/include/httpd.h and symlink "logs/mm/ -> /var/cache/apache-mm/" for the system-wide apache in it's config space (that'd be /var/log/apache/mm -> /var/cache/apache-mm). So system-wide stuff goes into /var/cache/apache-mm and users can remove this link so user-daemon stuff goes into the user config space. But, what the heck, just remove the sed line. No use.
Can you explain this a bit better thanks. chuck
Not sure why the reporter doesn't use some sort of virutal hosting to accomplish their goals. Since this is probably a fairly unique request overall, it's better to let the user remove the sed line in their portage overlay. But I do see the concern.
Chuck, can you please explain what is unclear about my statement? I have the same kind of troubles answering "please explain better" as I have when someone tells me something is broken. Roninds VirtualHosting does not give me the adequate security, since VirtualHosting does not allow certain virtual hosts to use their own user id when for instance executing PHP stuff. Therefor I use user-owned apache instances.
Fair enough. Security is a good thing...what about the other part of my statement? Why not have a portage overlay that contains your version of the ebuild?
Robbat, Can you comment on this? Thanks chuck
ronids, a portage overlay is exactly what I'm having. If the problem is so special then it's ok to shift responsibility to the user. But I think running a httpd in user mode isn't that uncommon. It's unlike a DNS server, TFTP server, or SMB server where switching ports to an unprivileged is really ackward. It's quite a common thing to run http on unprivileged ports, and therefor I argue, that running http servers as user should be possible too. As shown, the hardcoded paths prevent gentoo apache installations to run as unprivileged user (one which has no access to /var/cache/apache-mm/.). My proposed solution allows the system-wide http to continue to use /var/cache/apache-mm, while allowing users to supply their one mm cache directory. I don't think that's a bad deal. It even removes a source patch command from the ebuild simplifing the build process.
Please supply a patch.
why not just set correct permissions on /var/cache/apache-mm ? chmod 1777 /var/cache/apache-mm yes? it's been a while since i've used apache1 so YMMV. have a server start up from root then drop it's privileges yes. but I certainly wouldn't let my users run an apache server themselves.
I'm sorry. I can't provide a patch which is compatible with Gentoo's way of handling contributions. I was not able to complete the copyright assignment agreement procedure because of highly dubious reason brought forward by seemant@gentoo.org. Fix the process, or drop the C.A., otherwise I won't contribute any immaterial good but bug reports. No offence.
Clemens: we only require the copyright agreement for ebuilds in the tree, and that is explictly so that we can defend our copyright if needed. An entirely valid way to work around it is to attach a different copyright to your patch, which can then be fetched.
The patch would be for the ebuild of course. I'd drop the patch and add code to a symlink to /var/log/apache/mm->/var/cache/apache-mm.. admitted, this is trivial. However, as I said, I was disturbed by the fact that recruiters@gentoo.org told me, I don't need to complete the C.A. process, and that I should just contribute with "Copyright Gentoo Inc." in my ebuilds, which is something I'm containly not willing to do. I know this is off topic here, but my experience is, that people only start to listen when they recognize you've got something valuable for them, in this case a _tested_ ebuild patch.
Probably my last comment where a little bit ambiguous with "drop the patch". This should mean, drop "sed -i -e 's:logs/mm:/var/cache/apache-mm/mm:' src/include/httpd.h" from apache-1.*ebuild (around Line 59 in 1.3.31-r3.ebuild). As logs/mm points to /var/log/apache/mm, the symlink /var/log/apache/mm->/var/cache/apache-mm is necessary to restore the old directory layout.
Hollow the question is, do we really want to not fix it? beu well, gentoo -> as upstream as possible.. beu i'd say it's justified to leave as-is
I'm not sure what you're talking about and why you're asking the question to ignore this bug, while actually setting it's state to WONTFIX. I'm also not sure why you're talking about upstream. This bug is, 1. gentoo-specific, 2. introduced intentionally by gentoo. Look at the ebuild, there is a nonsensical hard coding of absolute paths into httpd.h and with httpd.h of course into /usr/sbin/apache. Line 71 of apache-1.3.33-r1.ebuild: sed -i -e 's:logs/mm:/var/cache/apache-mm/mm:' src/include/httpd.h But leave it as WONTFIX. I'm not intrested in this bug anymore, 1. I've find my own systematic to deal with it, 2. everything neccessary has been said, 3. nobody is interesting in understanding the root of the problem, but that's ok. I'm just sorry for the rest of the gentoo user base.
