On Thu, Dec 10, 2009 at 7:03 AM, Carsten Wiedmann <[email protected]> wrote: > Jeff Trawick schrieb: >>>> /usr/local/build/config_vars.mk includes /usr/local/include/apr-1 in >>>> EXTRA_INCLUDES >>>> (if not, what is EXTRA_INCLUDES set to?) >>> No, the apr include dir is not part of EXTRA_INCLUDES. The apr inlude dir is >>> defined in APR_INCLUDEDIR. >> >> The APR include dir should appear within both APR_INCLUDEDIR and >> EXTRA_INCLUDES. Report that to your httpd provider, or open a bug at >> https://issues.apache.org/bugzilla/ if you built it yourself. > > This only happens, if you build httpd with a preinstalled APR, but not with > the bundled APR (With a preinstalled APR httpd is also using apr-1-config to > get the values, like apxs -c). With the bundled APR the APR_INCLUDEDIR dir > is not added to EXTRA_INCLUDES. > > With the bundled APR, that's only working for (most) people, because > apr/apr-util doesn't (normally) respect it's own config.layout (if > --enable-layout is used), and so the httpd and APR headers are going to the > same directory, which is the directory defined in "includedir" in > condig_vars.mk.
I'm confused... What is the condition where EXTRA_INCLUDES doesn't find APR include files? When the bundled APR is used with certain non-default layouts, or something else? >>> And and least I have to set e.g.: >>> | FcgidIPCDir /var/run/ >>> | FcgidProcessTableFile /var/run/fcgid_shm >>> Or Apache can't start: No access/exists to the default values of these two >>> directives. >> >> the enclosing directories exist but you can't write to it? > > Correct, and my example above is also wrong (sorry, a problem with my copy > 'n paste). It must be e.g.: > | FcgidIPCDir /var/run/fcgidsock Is it true that ServerRoot wasn't writable in general? What else had to be changed? ErrorLog, Pidfile, etc.? > > It's just that people must know, that > a) FcgidProcessTableFile is created by the startup process (uid: root) > b) the files in FcgidIPCDir are created by a worker process (e.g. uid: www) > > and for b) and if the configured FcgidIPCDir already exists, this user must > have privs to create something in this directory. > If only the last part of FcgidIPCDir does not exists, the startup process is > creating this directory with the correct owner. > > >>> Maybe e.g. TMPDIR should be used as default? >> >> The defaults are "logs/fcgidsock" and "logs/fcgid_shm" under >> ServerRoot. I think DEFAULT_REL_RUNTIMEDIR is a better choice than >> hard-coded "logs", but that wouldn't help you since your ServerRoot >> has no "logs" directory or you have no write access anyway. I don't >> think a system-wide directory is an appropriate default. (mod_fcgid >> currently creates lock files there :( ). > > TMPDIR is just an example, because: > - there is always a way to get a valid TMPDIR path > - on my system it has the sticky bit, so others can't e.g. delete my > FcgidProcessTableFile > - if we assume there is no fcgidsock subdir at this time, the startup > process is creating this dir with exclusive privs for e.g. the www user. > > (- well, and a log dir is for logfiles and not for e.g. sockets ;-) ) Note that DEFAULT_REL_RUNTIMEDIR isn't necessarily "logs". Some of the entries in config.layout have a separate "run" directory under ServerRoot; others use /var/run. A packager should pick something appropriate. But yes with a default httpd build you may find various run-time files or sockets in ServerRoot/logs, depending on exactly which modules are in use. Individual modules shouldn't be decide the appropriate place for run-time files, even if they could determine that TMPDIR or some other common system directory has no security implications. I'll fix mod_fcgid to respect DEFAULT_REL_RUNTIMEDIR.
