Re: [PATCH] allow implicit ServerRoot via apxs
The easiest way I've found to do this in Apache::Test is attached. It extracts the PREFIX from apxs and uses that as the default inherited ServerRoot value. If a value is hard-coded into the global httpd.conf, it supercedes the apxs value and everything works just like before. hmm. it looks like PREFIX is only related to the installation, whereas ServerRoot, if not specified, is hard-coded to /usr/local/apache (according to include/httpd.h in 2.0). so, PREFIX isn't much help if one installs then moves the binaries to a new location. but I suppose that a guess is better than nothing if we don't have a ServerRoot to pull from the default httpd.conf, and PREFIX and ServerRoot match for me :) The patch is against 1.05 and I tested it with Apache 1.3.29 and 1.3.28. cool. I'll give it a whirl next week under a few different conditions. thanks! --Geoff btw, doesn't it seem strange that prefix defaults to /usr/local/apache2 in config.layout but ServerRoot defaults to /usr/local/apache? hmm...
Re: [PATCH] allow implicit ServerRoot via apxs
Mike Cramer wrote: Currently, if your local httpd.conf doesn't contain a ServerRoot directive but has relative-paths to things like DSO modules, Apache::Test fails. Obviously, a ServerRoot is necessary for Apache to function properly, but the ServerRoot directive is only one of several ways to set it. Once nice trick for making a config file that will run on several versions of Apache (or even different server architectures) is to make all architecture-specific paths (mainly to DSO modules) relative to ServerRoot, while generic, architecture-agnositic paths are absolute. You then rely on the path compiled into httpd (via the --prefix configuration option) to find your DSOs. Mike, can you should us an example of what is picked wrong? Full paths will stay full paths, and relative paths will be rerouted to the new ServerRoot defined by Apache-Test. Is that where the failure coming from? So if you had: LoadModule foo modules/bar.so it won't be able to expand it to a full path to modules/bar.so because ServerRoot is not set? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] allow implicit ServerRoot via apxs
Geoffrey Young wrote:
The easiest way I've found to do this in Apache::Test is attached. It
extracts the PREFIX from apxs and uses that as the default inherited
ServerRoot value. If a value is hard-coded into the global httpd.conf,
it supercedes the apxs value and everything works just like before.
hmm. it looks like PREFIX is only related to the installation, whereas
ServerRoot, if not specified, is hard-coded to /usr/local/apache
(according to include/httpd.h in 2.0). so, PREFIX isn't much help if
one installs then moves the binaries to a new location.
If they move .so modules to a different location without defining ServerRoot
things won't work.
but I suppose that a guess is better than nothing if we don't have a
ServerRoot to pull from the default httpd.conf, and PREFIX and
ServerRoot match for me :)
-1 on adding any new guesswork. So far it was causing more damage than it was
adding value. But this is not a guesswork. If ServerRoot is not specified
PREFIX should be the one, since this is what Apache is doing. So use that and
verify that the files can be found. If not, complain that ServerRoot can't be
determined and die.
I'm not sure it's a good idea to just:
+$self-{inherit_config}-{ServerRoot} ||= $self-apxs('PREFIX');
may be better to use PREFIX if ServerRoot is not defined in the code where
it's needed, so it'll be clear that we don't have ServerRoot defined. And if
we fail to expand paths we can tell a user the reason. If we have
ServerRoot=PREFIX we can't tell the real reason to the user.
btw, doesn't it seem strange that prefix defaults to /usr/local/apache2
in config.layout but ServerRoot defaults to /usr/local/apache? hmm...
Sounds like a porting to httpd 2.0 bug. But since the majority specifies
ServerRoot nobody has noticed it. Report to httdp-dev?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/t/modules include.t
* Stas Bekman [EMAIL PROTECTED] wrote: BTW, there is a much simpler way to turn tests into todos without touching the sub-test's code: http://perl.apache.org/docs/general/testing/testing.html#Todo_Sub_tests Oh well, I knew there was something ... :-) I'll fix it. nd
Re: cvs commit: httpd-test/perl-framework/t/modules include.t
[EMAIL PROTECTED] wrote:
nd 2003/11/01 09:28:48
Modified:perl-framework/t/modules include.t
Log:
disable the fsize/flastmod-test for now, until there's a better solution
BTW, there is a much simpler way to turn tests into todos without touching the
sub-test's code:
http://perl.apache.org/docs/general/testing/testing.html#Todo_Sub_tests
[...]
my $tests = scalar(keys %test) + scalar(keys %t_test) + @patterns + 2;
-plan tests = $tests + 31, have_module 'include';
+plan tests = $tests + 30, have_module 'include';
Apache::TestRequest::scheme('http'); #ssl not listening on this vhost
Apache::TestRequest::module('mod_include'); #use this module's port
@@ -158,6 +158,8 @@
);
### FLASTMOD/FSIZE TESTS
+### disabled for now, until there's a better solution.
+my $todo = sub {
unless(eval{require POSIX}) {
skip POSIX module not found, 1;
}
@@ -203,6 +205,7 @@
GET ${dir}file.shtml
);
}
+}; # /todo
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
sctp related compile errors
I get this when compiling 2.0.48 via gentoo's ebuild: /bin/sh /portage/apache-2.0.48/work/httpd-2.0.48/srclib/apr/libtool \ --silent --mode=compile gcc -pthread -march=pentium3 -O2 -pipe -DHAVE_CONFIG_H \ -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE \ -I../../include -I../../include/arch/unix -I../../include/arch/unix \ -c sockopt.c touch sockopt.lo sockopt.c: In function `apr_socket_opt_set': sockopt.c:257: error: `SCTP_NODELAY' undeclared (first use in this function) sockopt.c:257: error: (Each undeclared identifier is reported only once sockopt.c:257: error: for each function it appears in.) make[4]: *** [sockopt.lo] Error 1 make[4]: Leaving directory `/portage/apache-2.0.48/work/httpd-2.0.48/srclib/apr/network_io/unix' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/portage/apache-2.0.48/work/httpd-2.0.48/srclib/apr/network_io/unix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/portage/apache-2.0.48/work/httpd-2.0.48/srclib/apr' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/portage/apache-2.0.48/work/httpd-2.0.48/srclib' make: *** [all-recursive] Error 1 I'm using gcc 3.3.2, glibc 2.3.2, 2.6 kernel. sockopt.c includes apr_arch_networkio.h from srclib/apr/include/arch/unix, which does: #if APR_HAVE_NETINET_SCTP_UIO_H #include netinet/sctp_uio.h #endif #if APR_HAVE_NETINET_SCTP_H #include netinet/sctp.h #endif but APR_HAVE_NETINET_SCTP_H is getting set to 0 even if I cp the files from /usr/src/linux/include/net/sctp into the /usr/include tree. Any ideas/suggestions on how to get around this? -JimC
piped log files
Hi, Piped log files still dont work with apache 2.0.48 piped log program '/usr/local/apache2/bin/logresolve /home/accounts/x//logs/access_log' failed unexpectedly So i am using a script as suggested before , called it apacheresolve : #!/bin/sh exec /usr/local/apache2/bin/logresolve /tmp/lr.out When stopping apache I also get : piped log program '/usr/local/apache2/bin/apacheresolve /home/accounts/x/x/logs/access_log' failed unexpectedly running on linux Greetings, Bas
Re: piped log files
Bastiaan van der Put wrote: Piped log files still dont work with apache 2.0.48 piped log program '/usr/local/apache2/bin/logresolve /home/accounts/x//logs/access_log' failed unexpectedly So i am using a script as suggested before , called it apacheresolve : #!/bin/sh exec /usr/local/apache2/bin/logresolve /tmp/lr.out I still have this patch in my tree for this feature. ISTR wondering what other people thought about it, and forgetting about the issue until you just brought it up again. Any concerns out there? Index: server/log.c === RCS file: /home/cvs/httpd-2.0/server/log.c,v retrieving revision 1.135 diff -u -r1.135 log.c --- server/log.c14 Jul 2003 14:48:40 - 1.135 +++ server/log.c1 Nov 2003 15:13:35 - @@ -743,6 +743,8 @@ apr_status_t status; if (((status = apr_procattr_create(procattr, pl-p)) != APR_SUCCESS) || +((status = apr_procattr_cmdtype_set(procattr, APR_SHELLCMD)) + != APR_SUCCESS) || ((status = apr_procattr_child_in_set(procattr, ap_piped_log_read_fd(pl), ap_piped_log_write_fd(pl))) Any comments from the audience? When stopping apache I also get : piped log program '/usr/local/apache2/bin/apacheresolve /home/accounts/x/x/logs/access_log' failed unexpectedly There is a PR for this issue. It is perhaps timing related, as it does not affect everybody.
Re: cvs commit: httpd-2.0/include http_config.h
Greg Stein wrote: On Fri, Oct 31, 2003 at 10:12:56PM +0100, Sander Striker wrote: From: Brad Nicholes [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 9:53 PM So what is the best way to resolve this? Currently NetWare won't build. It throws a compiler error in Metrowerks. I can #ifdef it based on the compiler or is there a better way? Revert. I'll live with the warning. Hm. That isn't ideal either. The problem is that we jam a bunch of different types of functions into that one slot. The ideal is probably a union of function pointer types. That doesn't really work either, except with gcc. See the command stuff for Apache modules for that one made as good as we can. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
[DRAFT] configure documentation
Hi guys, at http://cvs.apache.org/~kess/programs/ you'll find a draft for a configure script documentation. There are still some open ends - mostly commented within the xml file - and there might be a lot of typos and spelling mistakes, but it is ready for a review now... It would be fine, if someone could also go through the text and improve it. I do not trust my english skills ;) Kess
Re: [DRAFT] configure documentation
at http://cvs.apache.org/~kess/programs/ you'll find a draft for a configure script documentation. There are still some open ends - mostly commented within the xml file - and there might be a lot of typos and spelling mistakes, but it is ready for a review now... It would be fine, if someone could also go through the text and improve it. I do not trust my english skills ;) It looks great -- go ahead and commit it. If there are any typos they won't get fixed until after you commit. I suggest adding some mention of config.nice as well, but that can wait. Roy
[PATCH] find_apu.m4
Hi. The attached patch corrects the description of the --with-apr-util configure option. The argument can be a directory path as well as the filename to the apu-config script. Could someone please commit this and backport this patch to APU_0_9_BRANCH? Since I'm not subscribed at [EMAIL PROTECTED] please send all answers to [EMAIL PROTECTED], too. Thank you Kess find_apu.m4.patch Description: Binary data
Re: [DRAFT] configure documentation
On Sun, 2 Nov 2003, [ISO-8859-15] Astrid Keßler wrote: Hi guys, at http://cvs.apache.org/~kess/programs/ you'll find a draft for a configure script documentation. There are still some open ends - mostly commented within the xml file - and there might be a lot of typos and spelling mistakes, but it is ready for a review now... It would be fine, if someone could also go through the text and improve it. I do not trust my english skills ;) Looks very good. Here are some comments: - How are we planning to integrate this with install.xml? I assume we'll just rip out most of the Configuring the source tree section and replace it with a link to this new doc? - Since this program is unlike any of the other documented programs (apachectl/dbmmanage/etc), it should be made very clear at the top that configure is used only in the *source* tree, and that it is not part of an installed apache. - under --no-create, running should be just run. - extra . at the end of --srcdir - Under system types, cross-compile should have a dash. - You can probably steal the docs for --enable-layout from install.xml. - Perhaps warn under the general syntax section that configure will not complain about --enable-foo even if foo doesn't exist, so you need to type carefully. - Under enable or disable discrete modules, therefore is missing an e. - We should mark those modules that are really only for developers (bucketeer, case-filter, fn-export, etc). Probably they should be listed together. - I would split the modules into two sections introduced with: The following modules are enabled by default. Use these options to remove them. The following modules are disabled by default. Use these options to enable them. (And perhaps The following modules are useful only for developers and are disabled by default.) - Under --with-module, I would replace bigger modules with more complex modules - It looks like your link to mpm.html needs a .. at the front. - enable-vhost-alias seems way out of place. - with-program-name needs a little more detail. (For example, default: httpd). - I would drop the suexec section and simply reference the suexec docs. We don't really want people enabling this until they have read the docs. - You're missing --with-gdbm/ndbm/berkely-db (see install.xml).
Re: sctp related compile errors (resolved, but see last paragraph)
I figured this out shortly after posting ... :( What is happening is that something in the latest glibc or kernel headers (not linked into /usr/include, but glibc was built against the 2.6 kernel and probably grabbed some headers then) convinces apr that sctp is supported, even when the lksctp library is not installed. So I grabbed the latest release from lksctp.sf.net and installed that; then apache compiled w/o further complaint. So apr's configure needs to do a better job of detecting sctp support and turn it off if the necessary defines are not available. -JimC
mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
I have an Intel S875WP1-E with FreeBSD 4.8-STABLE running Apache 2.0.48 prefork with mod_ldap enabled, built against OpenLDAP 2.1.23. I'm getting a SEGV when I have ldap caching enabled. It seems the contents of the global util_ldap_cache is being corrupted. If I set a breakpoint at util_ald_cache_insert, I see this right before the SEGV: #0 util_ald_cache_insert (cache=0x30048018, payload=0x80c3540) at util_ldap_cache_mgr.c:390 #1 0x2841260d in util_ald_create_caches (st=0x80dad98, url=0x8153600 [AuthLDAPUrl argument]) at util_ldap_cache_mgr.c:275 #2 0x28410952 in util_ldap_cache_checkuserid (r=0x814d050, ldc=0x80c3248, url=0x8153600 [AuthLDAPUrl argument], basedn=0x81536b0 [LDAP BASE DN], scope=1, attrs=0x81536d8, filter=0xbfbfd768 [LDAP QUERY STRING], bindpw=0x8153b56 [PASSWORD], binddn=0xbfbfd754, retvals=0xbfbff768) at util_ldap.c:765 #3 0x28417bf5 in mod_auth_ldap_check_user_id (r=0x814d050) at mod_auth_ldap.c:366 ... gdb print util_ldap_cache $37 = (util_ald_cache_t *) 0x30048018 gdb print util_ldap_cache-maxentries $38 = 675356296 The 675356296 should be 50 (from util_ldap_cache_init in util_ldap_cache.c). The SEGV comes from: gdb print util_ldap_cache-hash $39 = (long unsigned int (*)()) 0 What can I do to track this down? -- albert chin ([EMAIL PROTECTED])
