Re: EAPI_MM support for apache
At 16:06 Uhr +0100 01.03.2003, Domenico Andreoli wrote:
[ may i bring this discussion on debian-apache@ ml? maybe they can help ]
sure. I'm already including them in my reply now, as well as Ralf S.
Engelschall.
To recap:
Domenico aka cavok asked me about my patches(1) to debian's apache
package that I informed the debian-apache mailing list last june(2):
(1) http://pflanze.mine.nu/~chris/debian/apache/
(still from last june!
checkcreatemmdir.patch contains the changes to the apache sources
*after* having applied the original eapi
patch by Ralf.
debianfolder-p3.patch contains the changes to the debian/ subfolder
(package configuration)
eapi-2.8.8.cjmodified.patch contains a new eapi patch including my
changes; since I didn't manage to find out
how Ralf is building his eapi patch, I could
not change his in a clean way, thus a clean
diff between his and my diff will not be
possible.
)
(2)
http://lists.debian.org/debian-apache/2002/debian-apache-200206/msg00006.html
Up to now, debian's apache packages ship without eapi_mm support. We
were not sure about how to make this happen. Below I've now made a
suggestion for improving my patch.
On Sat, Mar 01, 2003 at 11:46:22AM +0100, Christian Jaeger wrote:
Ah, by looking at my patches I realize that I extended it to be able
to start as non-root user. You probably mean this?
yes, i meant this. anyway, after some thinking at it, i realized that
the problem is elsewhere.
And yes the main reason for this was that the former patch by David
Kilzer was not accepted because it broke startability as non-root
user. (Since server-root might not have been read at the time eapi
creates the mm files.)
this matter of the non-root is only a manifestation of what i think is
the real problem. read below.
> The problem with debian is that logs/ does not reside under the
serverroot (except when you make /var or / the server root). Usually
it's even /var/log/apache and nothing "logs", but even patching the
EAPI_MM_CORE_PATH path to "log/apache/mm" instead of "logs/mm" would
be clunky since a user would then have to override serverroot when
starting apache (/usr/sbin/apache -C "serverroot ...") to something
like "/home/user/" and create "/home/user/log/apache/".
Thus yes, checkcreatemmdir has probably some charme.
IMHO, the real problem i see is that one cannot override the
EAPI_MM_CORE_PATH which is built into the binary, whether it is run by
root or not.
But, well, might be that an even cleaner solution would be to have a
commandline argument (are -C directives executed before initializing
eapi_mm?). And that solution would probably one that Ralf would like
as well.
(i don't know. which directive would you use?) if it worked it would
look clean enough.
hmm... wait.. and if i run apache -C "ServerRoot /something" and i leave
EAPI_MM_CORE_PATH relative? what happens?
Someone will have to check whether the -C directive takes effect
before eapi_mm initialization. As Ralf says in the mod_ssl faq (which
is mentioned below) the -d commandline option should do the same but
I remember that one time I tried it (not libmm related), it didn't
work whereas -C "serverroot ..." did.
And as mentioned above it's still rather ugly to have a hard coded
relative path, it's "logs/" in upstream, whereas debian uses "log"
without "s" and since debian splits files across the whole filesystem
they do not have a common serverroot anymore (I believe the default
serverroot compiled into the debian binaries is "/"), so it's still
ugly.
> - looking at current debian apache sources I see that eapi_mm is
still not included. I don't know why. Maybe one should prod the
> maintainer again.
as i understood, mm support is not compiled because it creates its files
before configuration file is parsed. so location (EAPI_MM_CORE_PATH)
cannot be ServerRoot relative (how it could? does apache express
any relative path as if it was referred to ServerRoot?
yes (at least generally, and IIRC eapi uses the same behaviour, which
means it does *not* look at cwd when resolving relative paths)
), it must be
absolute. but if it is absolute non-root users _may_ not be able to
start apache (well, this depends on whether builtin path is owned by
who runs apache or not
exactly
). since there is no perfect solution, mm support
is left out.
exactly. And thus I went on and made this checkcreatemmdir patch
which does solve the problem without bothering the user much.
It's evenly questionable whether a solution with having to
explicitely set the path (-C "directive value" or other commandline
flag) is the right thing, either, since it's really about temporary
files and users should not have to worry about those too much. You
could peek at the "$TMPDIR" environment var, but this is usually set
to /tmp and there's where problems begin.
The problem is that unix (AFAIK) does not really define the handling
of different kinds of temporary files sufficiently.
There are (at least) three kinds of temporary files(/items):
1. items that are used only for a short time. This is what /tmp was
primarily invented for. Since such items might be left behind because
of software bugs (and kill -9 etc), some people run tempfolder
cleaners (such as "tmpreaper") that remove those files when they have
become old.
2. items that are used for a long time (maybe as long as the server
is running). This is the kind of files that libmm needs. If a folder
is used that is vacuum cleaned, it will break the application (i.e.
apache will probably misbehave somehow).
3. items that are not only used for a long time, but require a
predefined name (because they must be used by independantly running
processes). Worldwritable (but sticky) folders like they can be used
in cases 1 and 2 cannot be reliably used for 3, since that would
allow an easy denial of service by other users (nonetheless, /tmp is
still frequently used for this purpose, because of lack of good
alternatives). AFAIK there is no standard solution for those. Root
can use /var/run, /var/lock, and others. Normal users *might* use
their home folder, but this could also be on NFS and thus unsuitable,
and some users do not have a writable home.
Long story short, lacking any standard answer, I decided that
apache's "type 2" (see above) files should go to /var/tmp, or, if an
administrator decides so, he can create /var/run/apache/mm.users,
then that will be used. If for some reason both do not exist, /tmp is
used instead (of course in the hope that there's no vacuum cleaner).
Since all those folders are worldwritable(+sticky), I've also added
code to first create a non-worldwritable subfolder belonging to the
user, which is necessary for security purposes since libmm does not
create the files with the O_EXCL flag set.
I believe this solution suits debian fine (but then I don't know why
my patch has not been added until now). It might even be a good
solution for other distributions and thus maybe Ralf should include
it. Distributon makers would just have to change
EAPI_MM_CORE_USERFOLDERS to the list of preferred tmp folder
locations for "type 2" items if they don't like the debian (=
filesystem hierachy standard) locations. Making that a config time
option instead of requiring to patch httpd.h would maybe even better.
In fact, I think if I change my patch a bit, it could also suit
everyones requirements:
- If EAPI_MM_CORE_PATH is defined when compiling, it should be used.
This makes it backwards compatible during compilation process.
- If EAPI_MM_CORE_USERFOLDERS (which could maybe renamed to
EAPI_MM_CORE_TMPFOLDERS) is set when compiling, EAPI_MM_CORE_PATH is
not used, and only the new behaviour using tmp folders is compiled in.
- If none is defined when compiling, both mechanisms are compiled in,
EAPI_MM_CORE_PATH if it exists and is writable by the current user,
otherwise the EAPI_MM_CORE_TMPFOLDERS approach.
(it looks as if both of us are saying the same thing without
understanding each other, doesn't it?)
- Looking at current mod_ssl, I see that EAPI_MM_CORE_PATH still is
the same. Of course one could prod Ralf Engelschall as well (or
first) and see what he thinks about something like the automatic
folder selection ? la checkcreatemmdir.
ralf says something in mod_ssl faq [1]. he seems to know the problem but,
until now, has never thought to solve it perfectly.
What do you think, do you have something to add? Should I write to Ralf?
i'd like this stuff went into debian apache. it may be critical for
heavy loaded servers. i don't like that debian can be left out of these
fields of employment.
cheers
cavok
[1] http://www.modssl.org/docs/2.8/ssl_faq.html#mmpath
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Cheers,
Christian.
--
Christian Jaeger Programmer & System Engineer
ETHLife CMS Project - www.ethlife.ethz.ch/newcms - www.ethlife.ethz.ch
Reply to: