Re: What is test.o?
On Wed, 12 Sep 2001, Doug MacEachern wrote: On Wed, 12 Sep 2001, Gary Benson wrote: The makefile itself makes the directory, and puts a .exists file in it, but I don't know what it is trying to to do it or why. I've attached my makefile if you want to compare, or if you send me yours then I'll compare it instead... looks like there's a mod_random_chunk.c in your perl-framework/ directory? Yes, it's the one I made the other day. I moved it out of its own directory so it didn't get nailed when I ran cvs update. Well, I moved it and it works properly now. I hope that you didn't spend too much time on it :-/ Cheers, Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: Error from mod_cgi test
On Thu, 13 Sep 2001, john sachs wrote: On Thu, Sep 13, 2001 at 09:16:38AM -0700, Ian Holsman wrote: + error: cgi log not created! + not ok 2 + # Failed test 2 in modules/cgi.t at line 85 + error: cgi log does not exist! + not ok 4 + # Failed test 4 in modules/cgi.t at line 97 + dubious + Test returned status 2 (wstat 512, 0x200) + DIED. FAILED tests 2, 4, 10-36 + Failed 29/36 tests, 19.44% okay ok, all these errors deal with the cgi log. at first i thought the script was using relative paths to find the log, but thats not the case. so the only thing i can think of is permissions? the test is dying because its trying to do a stat on a non-existant file. i will fix this, but it still doesnt tell us why the log file is not getting created. any ideas anyone? What user is the cronjob running as? It may be that the cronjob is running as a different user... Gary [ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
Re: Error from mod_cgi test
Gary Benson wrote:
On Thu, 13 Sep 2001, john sachs wrote:
On Thu, Sep 13, 2001 at 09:16:38AM -0700, Ian Holsman wrote:
+ error: cgi log not created!
+ not ok 2
+ # Failed test 2 in modules/cgi.t at line 85
+ error: cgi log does not exist!
+ not ok 4
+ # Failed test 4 in modules/cgi.t at line 97
+ dubious
+ Test returned status 2 (wstat 512, 0x200)
+ DIED. FAILED tests 2, 4, 10-36
+ Failed 29/36 tests, 19.44% okay
ok, all these errors deal with the cgi log. at first i thought the
script was using relative paths to find the log, but thats not the
case. so the only thing i can think of is permissions? the test is
dying because its trying to do a stat on a non-existant file. i will
fix this, but it still doesnt tell us why the log file is not getting
created. any ideas anyone?
What user is the cronjob running as? It may be that the cronjob is running
as a different user...
the cronjob first pulls the CVS Head from httpd-2, apr, apr-util, proxy
test.
it then builds installs HTTP.
it then builds/runs the test program.
I've attached the script here.
..Ian
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ]
#!/bin/sh
#
# nightly2 - build httpd-2.0 complete and log everything
#
# uses pwd for everything
# mails errorlog iff errors occur
# can be extended to read script fragments to add modules for
# rollup builds
#
# canonical date for naming things
date=`date +%C%y%m%d%H%M%S`
# OS for logging
opsys=`uname -sr`
# where were we now? everything builds here
origdir=/usr/local/src/nightly
# CVS checkout dir
indir=$origdir/src
# build dir
outdir=httpd-2.0-nightly
# test dir
testdir=httpd-2.0-test
# install dir
installdir=/usr/local/src/nightly/httpd-2.0-install
# logs go here
destdir=/usr/local/src/nightly/logs
# error log
errfile=$origdir/$date.errlog
# output log
outfile=$origdir/$date.outlog
# testerr log
testerrfile=$origdir/$date.test_errlog
# testout log
testoutfile=$origdir/$date.test_outlog
# last symlink
last_testoutfile=$origdir/last.test_outlog
# serverout log
serveroutfile=$origdir/$date.server_outlog
# base packages
basepkgs=httpd-2.0
# additional packages to check out and merge
addpkgs=apr apr_util httpd_proxy httpd_test
addpkgs_name=apr apr-util httpd-proxy httpd-test
# packages to check out
pkgs=$basepkgs $addpkgs_name
# where to get them
psvr=:pserver:[EMAIL PROTECTED]:/home/cvspublic
# server config
cfgopts=--enable-so --enable-shared --enable-maintainer-mode
--enable-auth-anon --enable-auth-dbm --enable-auth-db --enable-auth-digest
--enable-file-cache --enable-echo --enable-cache --enable-mime-magic
--enable-cern-meta --enable-expires --enable-headers --enable-usertrack
--enable-unique-id --enable-proxy --enable-proxy-connect --enable-proxy-ftp
--enable-proxy-http --enable-dav --enable-info --enable-suexec --enable-cgi
--enable-cgid --enable-dav-fs --enable-vhost-alias --enable-rewrite
--enable-case-filter --enable-case-filter-in -prefix=$installdir
#--with-tls=/usr --with-ssl=/usr --enable-ssl --enable-tls
# what we don't turn on
nocfgopts=--enable-charset-lite --enable-disk-cache --with-tls=/usr
--with-ssl=/usr --enable-ssl --enable-tls
# who to bother (CHANGE FOR TESTING)
#mailto=[EMAIL PROTECTED]
mailto=[EMAIL PROTECTED]
#mail to send test messages to
testmailto=[EMAIL PROTECTED]
# link to logs
thelink=http://cvs.apache.org/builds/httpd-proxy/logs/;
# number of lines of fixed output
fixlines=10
# number of additional (merged) modules
addlines=`echo $addpkgs | wc -w`
# number of lines in errorless output
msglines=`expr $fixlines + $addlines`
# vars for building releases later
tarname=$outdir_$date
compressext=.tar.Z
gzipext=.tar.gz
zipext=.zip
emitmsg () {
#local msg; local errfile; local outfile
#echo $msg;
echo $msg $errfile;
echo $msg $outfile
return $?
}
build2main () {
#local indir; local outdir
cp -R $indir/httpd-2.0 .
mv httpd-2.0 $outdir
return $?
}
build_apr () {
#local indir; local outdir; local repdir
cp -R $indir/$repdir $outdir/srclib/
return $?
}
build_apr_util () {
cp -R $indir/apr-util $outdir/srclib/
return $?
}
build_httpd_proxy () {
mkdir $outdir/modules/proxy
cp -R $indir/httpd-proxy/module-2.0/* $outdir/modules/proxy
cp -R $indir/httpd-proxy/module-2.0/.[a-z]* $outdir/modules/proxy
cp $indir/httpd-proxy/docs/mod_proxy.html $outdir/docs/manual/mod
return $?
}
build_httpd_test() {
mkdir $testdir
cp -R $indir/httpd-test/perl-framework/* $testdir
return $?
}
datenow=`date`
msg=Build started $datenow on $opsys; emitmsg
msg=Checking out $pkgs; emitmsg
mkdir $indir
cd $indir
cvs -q -d $psvr co $pkgs 2 $errfile $outfile
cd $origdir
msg=Building $outdir; emitmsg
build2main 2 $errfile $outfile
# this loop should eventually execute a script fragment in each additional
# module's repository merging it into the big build automagically
for repdir in $addpkgs; do
msg=Merging package $repdir; emitmsg
build_$repdir 2
Re: Hard coded HTTPD_ROOT in httpd.h...
On Wed, Sep 12, 2001 at 10:34:03PM -0400, Rodent of Unusual Size wrote: * On 2001-09-12 at 21:11, Ryan Bloom [EMAIL PROTECTED] excited the electrons to say: This is why we have config.layout. It is not just -f, it is -d as well. I think most installations use either one of these or the default location set by the layout. Not a problem, I think. If the hard-coded default is never used, then why don't we just toss it, and require people to pass/use a root? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: so modules, libtool and position independent code
On Wed, Sep 12, 2001 at 05:27:07PM +0200, Sascha Schumann wrote: First - I don't understand why it works, since libpython is not PIC (-fpic is not used when compiling). From reading what I could find on the subject, it's supposed to crash miserably. You can use non-PIC code in shared libraries with the disadvantage that pages cannot be shared between unrelated processes, because each process needs to maintain its own relocated copy (they should be shared between parent/children though). Depends on the platform. You cannot link non-PIC code with PIC code on HP-UX. Second - is libtool's refusal to link with non-libtool libraries an issue for other module writers, and what is the recommended way to go around it? The only solution I could think of was not using apxs. Libtool is capable of linking shared libraries against static code since version 1.3d. Prior to that, there were patches available to add this feature to libtool. I think it issues a warning and does so only on platforms that allow it. -- albert chin ([EMAIL PROTECTED])
RE: Optimizing dir_merge() AND RE: [BUG] mod_ssl broken
Hi, I can reproduce the problem easily now with openssl s_client. If anyone is interested to hunt this bug down (I am personally not familiar enough with the location_walk code to find it (without spending more time on it than I have at the moment)), I can give an account on my box to observe the problem first hand. Once again, it is not in the optimization code, I reverted to request.c 1.47 (with patch 1.49 applied). If someone has time, please help hunt this down so I can focus on working on the ssl side of subversion ;) Sander
Re: so modules, libtool and position independent code
Depends on the platform. You cannot link non-PIC code with PIC code on HP-UX. Yes, I was speaking in the context of FreeBSD where the person I was replying to had specific problems. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg
Re: Hard coded HTTPD_ROOT in httpd.h...
Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. 2) Unlike the Unix world, and I wish this were not the case for us, NetWare does not have an open development environment. Our tools such as Code Warrior cost money and are not widely available. Due to this fact we can not expect the average user to download, build and install Apache from source. Our users depend on prebuilt binaries that will work in all NetWare configurations. To my knowledge, and I hope I am wrong, there are only a hand full of developers that have actually downloaded the source and built it for NetWare in comparison to a relatively large number of NetWare users that have downloaded the binaries and are either playing with it or deploying it. BTW, Apache 1.3.20 will be shipping with NetWare 6 so this relatively large number will grow even larger soon. 3) Bill suggested that we look at the Win32 hooks. I'm not quite sure what you mean by that. Unless they are some type of Apache hook, it won't do us any good either. NetWare does not have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time. When the Apache binary is envoked, the first thing we hit is main(). According to the code, def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified, a hard coded path will be used and we will fail. The only possible workaround that I can see at the moment is #define'ing HTTP_ROOT as getcwd() which will at least get us in the ball park. I would greatly appreciate any other suggestions from those who know this code much better than I do (which could be just about anybody :) ) thanks, Brad [EMAIL PROTECTED] Thursday, September 13, 2001 12:49:55 AM On Wed, 12 Sep 2001, Greg Stein wrote: On Wed, Sep 12, 2001 at 10:34:03PM -0400, Rodent of Unusual Size wrote: * On 2001-09-12 at 21:11, Ryan Bloom [EMAIL PROTECTED] excited the electrons to say: This is why we have config.layout. It is not just -f, it is -d as well. I think most installations use either one of these or the default location set by the layout. Not a problem, I think. If the hard-coded default is never used, then why don't we just toss it, and require people to pass/use a root? It is used. By default. A default configure --prefix=/under/my/hat make make install will result in the default defines being used. We need some way to know where to look for config files. This can be done at compile time or at run time. Right now we support it being done at compile time with these defines. Lots of people do use it. Note that it is designed so that it can be easily overridden from the #defined path at compile time, and it often is. It can be overridden at run time with command line options. The original suggestion that started this thread was to base it off the current working directory. I just don't see that offering any real advantage, since command line options are directly associated with the execution of the program, as opposed to the working directory which is a OS maintained bit of information.
Re: Hard coded HTTPD_ROOT in httpd.h...
On Thu, 13 Sep 2001, Brad Nicholes wrote: Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. Then put it in httpd.h, where it already is: #elif defined(NETWARE) #define HTTPD_ROOT sys:/apache #else Then if it is installed in the default location, no flags are necessary. 3) Bill suggested that we look at the Win32 hooks. I'm not quite sure what you mean by that. Unless they are some type of Apache hook, it won't do us any good either. NetWare does not have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time. When the Apache binary is envoked, the first thing we hit is main(). According to the code, def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified, a hard coded path will be used and we will fail. Why will you fail if it is installed in the hardcoded location? If not, then... Why can't users use command line parameters? Netware supports them, right? Netware supports some type of scripting language doesn't it? Why can't you have a control script (much like apachectl) that passes the appropriate command line options? I don't see why using command line options is so undesirable or why relying on a particular working directory when starting the server is better. And I don't see any differences between Unix binary builds and netware; although a much higher percent of people can be expected to compile from source on unix, there are still a whole lot of binary builds used, and the current mechanisms work for them. What am I missing?
Re: Hard coded HTTPD_ROOT in httpd.h...
You are right, we can use command line parameters and everything will work correctly. The only concern I have is that with Apache 1.3.x we can install it, make some minor changes to the HTTPD.conf and invoker APACHE at the console. Which means that the default configuration will work. With Apache 2.0 we will now be saying that the default configuration will no longer work. You must use the command line or you must install to sys:\apache or it will fail. Basically what I am saying is that we don't have that restriction now. Why should we introduce this restriction for Apache 2.0? Brad Marc Slemko [EMAIL PROTECTED] Thursday, September 13, 2001 9:23:24 AM On Thu, 13 Sep 2001, Brad Nicholes wrote: Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. Then put it in httpd.h, where it already is: #elif defined(NETWARE) #define HTTPD_ROOT sys:/apache #else Then if it is installed in the default location, no flags are necessary. 3) Bill suggested that we look at the Win32 hooks. I'm not quite sure what you mean by that. Unless they are some type of Apache hook, it won't do us any good either. NetWare does not have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time. When the Apache binary is envoked, the first thing we hit is main(). According to the code, def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified, a hard coded path will be used and we will fail. Why will you fail if it is installed in the hardcoded location? If not, then... Why can't users use command line parameters? Netware supports them, right? Netware supports some type of scripting language doesn't it? Why can't you have a control script (much like apachectl) that passes the appropriate command line options? I don't see why using command line options is so undesirable or why relying on a particular working directory when starting the server is better. And I don't see any differences between Unix binary builds and netware; although a much higher percent of people can be expected to compile from source on unix, there are still a whole lot of binary builds used, and the current mechanisms work for them. What am I missing?
Re: Hard coded HTTPD_ROOT in httpd.h...
Brad, you gave the solution to your problem in this e-mail. Since you basically have control over the build environment, just define a CFLAG at build time that assigns HTTPD_ROOT to whatever makes sense as a default on Netware. As for what to do when Apache is installed to a non-standard path, just create a small scripte (modeled after apachectl), which starts Apache with the -d flag. This is what Covalent does, since we have to deliver a pre-built Apache binary. Ryan On Thursday 13 September 2001 08:08 am, Brad Nicholes wrote: Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. 2) Unlike the Unix world, and I wish this were not the case for us, NetWare does not have an open development environment. Our tools such as Code Warrior cost money and are not widely available. Due to this fact we can not expect the average user to download, build and install Apache from source. Our users depend on prebuilt binaries that will work in all NetWare configurations. To my knowledge, and I hope I am wrong, there are only a hand full of developers that have actually downloaded the source and built it for NetWare in comparison to a relatively large number of NetWare users that have downloaded the binaries and are either playing with it or deploying it. BTW, Apache 1.3.20 will be shipping with NetWare 6 so this relatively large number will grow even larger soon. 3) Bill suggested that we look at the Win32 hooks. I'm not quite sure what you mean by that. Unless they are some type of Apache hook, it won't do us any good either. NetWare does not have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time. When the Apache binary is envoked, the first thing we hit is main(). According to the code, def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified, a hard coded path will be used and we will fail. The only possible workaround that I can see at the moment is #define'ing HTTP_ROOT as getcwd() which will at least get us in the ball park. I would greatly appreciate any other suggestions from those who know this code much better than I do (which could be just about anybody :) ) thanks, Brad [EMAIL PROTECTED] Thursday, September 13, 2001 12:49:55 AM On Wed, 12 Sep 2001, Greg Stein wrote: On Wed, Sep 12, 2001 at 10:34:03PM -0400, Rodent of Unusual Size wrote: * On 2001-09-12 at 21:11, Ryan Bloom [EMAIL PROTECTED] excited the electrons to say: This is why we have config.layout. It is not just -f, it is -d as well. I think most installations use either one of these or the default location set by the layout. Not a problem, I think. If the hard-coded default is never used, then why don't we just toss it, and require people to pass/use a root? It is used. By default. A default configure --prefix=/under/my/hat make make install will result in the default defines being used. We need some way to know where to look for config files. This can be done at compile time or at run time. Right now we support it being done at compile time with these defines. Lots of people do use it. Note that it is designed so that it can be easily overridden from the #defined path at compile time, and it often is. It can be overridden at run time with command line options. The original suggestion that started this thread was to base it off the current working directory. I just don't see that offering any real advantage, since command line options are directly associated with the execution of the program, as opposed to the working directory which is a OS maintained bit of information. -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: module is not compatible with this version of apache ......!
Hi, I'm tring to build apache 2.0.24 with a module that i written. I configured and build apache with this mopdule and i got no errors but when i tried to check if that module was actually included in the build I got the following : ./httpd -l httpd: module mod_nullservice.c is not compatible with this version of apache . Please contact the vendor for the correct verion (although i followed the mod_example structure) Any ideas ! Thanks Hany
Re: Hard coded HTTPD_ROOT in httpd.h...
On Thursday 13 September 2001 08:35 am, Brad Nicholes wrote: I don't understand. Nothing changed about this logic between 1.3 and 2.0. What makes you think that the solution you are currently using for 1.3 won't work in 2.0? Ryan You are right, we can use command line parameters and everything will work correctly. The only concern I have is that with Apache 1.3.x we can install it, make some minor changes to the HTTPD.conf and invoker APACHE at the console. Which means that the default configuration will work. With Apache 2.0 we will now be saying that the default configuration will no longer work. You must use the command line or you must install to sys:\apache or it will fail. Basically what I am saying is that we don't have that restriction now. Why should we introduce this restriction for Apache 2.0? Brad Marc Slemko [EMAIL PROTECTED] Thursday, September 13, 2001 9:23:24 AM On Thu, 13 Sep 2001, Brad Nicholes wrote: Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. Then put it in httpd.h, where it already is: #elif defined(NETWARE) #define HTTPD_ROOT sys:/apache #else Then if it is installed in the default location, no flags are necessary. 3) Bill suggested that we look at the Win32 hooks. I'm not quite sure what you mean by that. Unless they are some type of Apache hook, it won't do us any good either. NetWare does not have a hooking mechanism that will allow us to alter something like HTTP_ROOT at run-time. When the Apache binary is envoked, the first thing we hit is main(). According to the code, def_server_root is initialized to HTTPD_ROOT and unless there is a -f or -d parameter specified, a hard coded path will be used and we will fail. Why will you fail if it is installed in the hardcoded location? If not, then... Why can't users use command line parameters? Netware supports them, right? Netware supports some type of scripting language doesn't it? Why can't you have a control script (much like apachectl) that passes the appropriate command line options? I don't see why using command line options is so undesirable or why relying on a particular working directory when starting the server is better. And I don't see any differences between Unix binary builds and netware; although a much higher percent of people can be expected to compile from source on unix, there are still a whole lot of binary builds used, and the current mechanisms work for them. What am I missing? -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Hard coded HTTPD_ROOT in httpd.h...
On Thu, 13 Sep 2001 09:08:53 -0600, Brad Nicholes wrote: Thank you for the feedback but I am still concerned about how this is going to work on NetWare. Here are the reasons why: 1) NetWare like Win32 and OS2, does not have a configure utility therefore config.layout will do us no good at all. In fact 99% of the compile time configuration is meaningless to us mostly due to the next reason. Just for the record, I DO use configure on OS/2. (and yes, that's how it should be written. The / only gets left out because it can't be included in a file name :) This is possible because most common unix utilities have been ported to OS/2, including autoconf. However, few end users have them all installed so most will run the binary package I build, putting them in the same situation as Netware users in that they must either install in the same place I did or specify the location with a switch. There's also no file system standard so anything I pick isn't going to suit many people. Wouldn't it make sense on most (all?) non unix platforms for the server root config files' default location to be relative to either the httpd executable or the CWD at start-up? -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: another map_to_storage gotcha.
On 12 Sep 2001, Ian Holsman wrote: What I am suggesting is to move some of these configurations to Location / where they belong. +1. -dean
Re: Apache-1.3: question about mod_unique_id
On Tue, 11 Sep 2001, Greg Stein wrote: On Tue, Sep 11, 2001 at 12:06:13AM -0500, William A. Rowe, Jr. wrote: ... where the code uses a pid (getpid()) you need to use a concatenation of pid and thread id. otherwise you violate some of the uniqueness guarantees. i just didn't bother trying to figure out how to get a thread id in any sort of portable way and left that to folks who actually wanted the module on those platforms. (this is actually mentioned in the comments near the top of the file describing how it works and the assumptions made.) As I've read. IIRC there are some other subtle issues with the size of the unique key. Be careful that we keep everyone in sync. there shouldn't be any subtle issues with size of the key -- the format was designed to make size differences unimportant. Seems that we now have 64 bit cpu's with potentially 64 bit pids. This adds to the equation, it looks like we need to cut over to those extra four bytes across all platforms. Oh, screw all that mess :-) Just use a UUID for the unique id. It has lots of bits, and it is already unique (by definition and without work). i'm not convinced the UUID implementation in 2.0 is unique, or is as robust as the technique mod_unique_id uses ... i started digging into this months ago and never quite finished. hopefully i'll get back to it and see if i'm right or wrong. 64-bit pids don't seem likely at all. -dean
Re: Apache-1.3: question about mod_unique_id
On Wed, 12 Sep 2001, Günter Knauf wrote: For NetWare I found this definition in ./netware/os.h: #define getpid GetThreadID and in the NetWare header nwthread.h GetThreadID() is defined as: int GetThreadID( void ); for Win32 platform getpid() is defined in process.h: _CRTIMP int __cdecl _getpid(void); #define getpid _getpid I didnt find more information about these functions yet nor of other functions which I could use to concatenate with. Do you think that they are insufficient for use with mod_unique_id? On NetWare I assume that the ThreadID is always unique on the same machine, on Win32 I dont know. The patch to get mod_unique_id compiled is only the #error ifdef: - #ifdef MULTITHREAD + #if defined(MULTITHREAD) !(defined(NETWARE) || defined(WIN32)) if the netware thread id is truly globally unique then you can use it alone. but on windows you'll need to use both getpid() and GetThreadID... i think it's called something similar to that. it may be Get Thread Handle ... what you really want is the thread * that create_thread returns, or you could use the scoreboard slot, but i don't see an obvious way to get at either. also -- add an extra field to unique_id_rec for the thread id. -dean
RE: module is not compatible with this version of apache ......!
On Thu, 2001-09-13 at 09:16, Farag, Hany M (Hany) wrote: Hi, I'm tring to build apache 2.0.24 with a module that i written. I configured and build apache with this mopdule and i got no errors but when i tried to check if that module was actually included in the build I got the following : try recompling the module or doing a make clean and then make. ..ian ./httpd -l httpd: module mod_nullservice.c is not compatible with this version of apache . Please contact the vendor for the correct verion (although i followed the mod_example structure) Any ideas ! Thanks Hany -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: another map_to_storage gotcha.
- I keep on pointing out problems with map_to_storage because I keep on running into them when I am handling reverse proxying (a major component in our web design) Test cases are great :) It's good to see a module (mod_proxy) immediately reap the benefits of this patch. BTW - since Josh (?) isolated the optimization patch out of the potential ssl/php (?) problem - it might be worthwhile for a mod_proxy hacker to go back and reap that code for mod_proxy, as well. Dunno if it has a real benefit, since it doesn't have the subrequests and redirects as frequently as file-based modules. The behavior you observe is neither a bug nor a misconfiguration. Global Options should have (always) been set on Location /. Filesystem Global Options should have (always) have been set on Directory / (at least since the patch for win32 and relatives to allow even d:/ to be affected by Directory /). the problem is that in the standard httpd-std.conf the configuration is done in @@Serveroot@@/htdoc directory instead of Location / the way the current configuration 'out of the box' would not work properly for people serving pages off non-filebased systems. What I am suggesting is to move some of these configurations to Location / where they belong. Agreed - as you look at the two (both Directory and Location /) you might through your proposal at both this list and apache-docs for sanity review :) +1 Bill
Re: [Fwd: video/vnd.mpegurl at ftp.isi.edu and default mime.types file.]
According to Rodent of Unusual Size: Roundabout, rather. I am not sure what his point is, but FWIW. He would like to have audio/mpegurl and audio/x-mpegurl added to mime.types by default. IMHO this makes sense. +1 from me. P.S.: Greetings from sunny Egypt. ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
RE: module is not compatible with this version of apache .... ..!
nope, still getting the same thing... any other thoughts.. Hany -Original Message- From: Ian Holsman [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 1:05 PM To: [EMAIL PROTECTED] Subject: RE: module is not compatible with this version of apache ..! On Thu, 2001-09-13 at 09:16, Farag, Hany M (Hany) wrote: Hi, I'm tring to build apache 2.0.24 with a module that i written. I configured and build apache with this mopdule and i got no errors but when i tried to check if that module was actually included in the build I got the following : try recompling the module or doing a make clean and then make. ..ian ./httpd -l httpd: module mod_nullservice.c is not compatible with this version of apache . Please contact the vendor for the correct verion (although i followed the mod_example structure) Any ideas ! Thanks Hany -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: Apache-1.3: question about mod_unique_id
From: dean gaudet [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 11:45 AM but on windows you'll need to use both getpid() and GetThreadID... i think it's called something similar to that. it may be Get Thread Handle ... what you really want is the thread * that create_thread returns, or you could use the scoreboard slot, but i don't see an obvious way to get at either. also -- add an extra field to unique_id_rec for the thread id. I suggest we add a gettid() if one does not exist, via the os.h/os.c for MULTITHREAD platforms. Anyone who wants to hack on this, just assume it's available, and where it isn't, someone needs to implement (I'm happy to do so for Win32.)
Re: Hard coded HTTPD_ROOT in httpd.h...
Hi, 2) Unlike the Unix world, and I wish this were not the case for us, NetWare does not have an open development environment. Our tools such as This is the official statement of Novell; but Pavel has done very good work; and the gcc compiled Apache seems to be as stable as the CodeWarrior build; so we can look forward that we will get soon a stable open development for NetWare; and I am working on it to get more support from Novell; I got some positive replies; and first signs are there: preludes for gcc... Code Warrior cost money and are not widely available. Due to this fact we can not expect the average user to download, build and install Apache from source. Our users depend on prebuilt binaries that will work in all NetWare configurations. To my knowledge, and I hope I am wrong, there are only a hand full of developers that have actually downloaded the source and built it for NetWare in comparison to a relatively large number of NetWare users that have downloaded the binaries and are either playing with it or deploying it. BTW, Apache 1.3.20 will be shipping with NetWare 6 so this relatively large number will grow even larger soon. Unfortunately Brad is absolutely right with this; and all he mentioned was the reason why I made my page with the binaries, and the downloads show that many are interested in getting the latest development versions... This is also the reason why Pavel tried to make the binaries compatible: Novell does not release the sources of their own Apache modules; so we have no chance to use module binaries build by Novell; and we cannot expect that Novell build them twice, one with CW and one with gcc. Also I speak here explicitly about Novell, and not about Brad!! I'm now fighting about 1,5 years with Novell that they push back their Perl ports to CPAN!! In addition to what Brad said we should explain for the others that NetWare development is always done on other platforms; no compiler runs on NetWare os yet; so most development is done on Win32 platform; a bit on DOS with older compilers; and since Pavel's success also now with gcc on Win32 and Linux. Guenter.
[PATCH] Relative server root...
I would like to propose the following code changes for main.c. These changes will
allow a platform to use a relative server root that is based on argv[0] rather than a
hard coded server root. If these changes seem fair, I would like to check them in.
thanks,
Brad
--- \tempapache\httpd-2.0\server\main.c Fri Aug 31 16:52:43 2001
+++ main.c Thu Sep 13 14:14:03 2001
@@ -230,6 +230,31 @@
return process;
}
+#ifdef USE_RELATIVE_SERVER_ROOT
+static char *get_def_server_root(apr_pool_t *pool, int argc, const char * const *argv)
+{
+char *s = HTTPD_ROOT;
+
+if (argc 0) {
+
+s = apr_pstrdup (pool, argv[0]);
+if (s) {
+int i, len = strlen(s);
+
+for (i=len; i; i--) {
+if (s[i] == '\\' || s[i] == '/') {
+s[i] = NULL;
+break;
+}
+}
+}
+}
+
+return s;
+}
+#endif
+
+
static void usage(process_rec *process)
{
const char *bin = process-argv[0];
@@ -304,6 +329,10 @@
pglobal = process-pool;
pconf = process-pconf;
ap_server_argv0 = process-short_name;
+
+#ifdef USE_RELATIVE_SERVER_ROOT
+def_server_root = get_def_server_root(pglobal, argc, argv);
+#endif
#if APR_CHARSET_EBCDIC
if (ap_init_ebcdic(pglobal) != APR_SUCCESS) {
RE: Optimizing dir_merge() AND RE: [BUG] mod_ssl broken
On Thu, 13 Sep 2001, Sander Striker wrote: can also reproduce with less in the mix: Listen 8999 VirtualHost _default_:8999 Location /manual #this can be any module with per-directory create+merge functions RequestHeader add Foo bar /Location /VirtualHost Location /manual Order deny,allow Deny from all Allow from 127.0.0.1 /Location 0x40246225 in merge_headers_config (p=0x8230334, basev=0x0, ^^^ overridesv=0x8220b54) at mod_headers.c:216 216 newconf-fixup_in = apr_array_append(p, base-fixup_in, overrides-fixup_in); producable with any module that has a per-directory create and merge function. seems there needs to be merging with r-server-lookup_defaults, that is not currently happening. if you remove the Location /manual from outside the vhost and put its contents into the Location /manual inside the vhost, all is well.
RE: [PATCH] shmem.c - again
Hi, I was wondering if anybody got a chance to look at the patch. If this looks okay, I was thinking of sending out a patch for the SSL Session Caching using SHMHT SHMCB. Any feedback / suggestion is welcome. Thanks -Madhu -Original Message- From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 2:22 PM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: [PATCH] shmem.c - again Hi, I've modified the shmem.c to have a another shared memory segment for storing the allocation details. I've also tried to ensure that all the computation is based on offsets (stored in the shared memory again) - so that if different processes map the shared memory at different addresses, the memory mgmt should still work. As regards testing, I've done some minimal testing (testshmem, shmcb, shmht) - but there may be lots of problems.. Also, the code may require perf. tuning - I haven't yet looked into those aspects.. Pl. let me know for any clarifications.. 'waiting for your feedback / suggestions.. Thanks -Madhu -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 09, 2001 5:39 PM To: [EMAIL PROTECTED]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1); '[EMAIL PROTECTED]' Subject: Re: FW: [PATCH] shmem.c On Sunday 09 September 2001 17:23, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: Hi Ian, Thanks for the suggestion.. I certainly like the first idea (infact, that was also one of the idea I'd proposed earlier). But, I'm not sure how *open* are others to create a seperate shared memory just for maintaining the allocation table.. The only problem is going to be ensuring that the platform has enough shared memory to handle both segments. I think we can just return an error if we run out of shared memory though. IOW, +1 for having a second shared memory segment for the control data. Ryan As regards your second idea, I'm not comfortable with it - it'd introduce a lot of performance overhead - especially with IPC's around.. Thanks for your suggestions.. -Madhu -Original Message- From: Ian Holsman [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 09, 2001 3:54 PM To: [EMAIL PROTECTED] Subject: Re: FW: [PATCH] shmem.c Hi Madhu. the only way I can think of handling this is to store the memory block list in another piece of shared memory/mmap (allocated seperatly) The other method I can think of is to spawn a seperate process which would hold all the memory list information, and it would do all the memory management and the other processes would communicate it via some IPC. the problem is that shared memory is NOT guarnteed to be in the same space for each process. ..Ian
[PATCH] apache-1.3/src/support/apachectl
Ever been bitten by this? I just had an overnight benchmark run go nowhere because I believed apachectl's output and assumed httpd was running correctly. The following patch makes apachectl at least look back to see if httpd is running. It checks the presence of the PID file which should be enough under normal circumstances, like in case there already is a httpd deamon running. Enjoy, S. --- src/support/apachectl~ Thu Sep 13 13:54:40 2001 +++ src/support/apachectl Thu Sep 13 17:09:26 2001 @@ -69,7 +69,19 @@ continue fi if $HTTPD ; then - echo $0 $ARG: httpd started + sleep 1 + if [ -f $PIDFILE ] ; then + PID=`cat $PIDFILE` + if [ x$PID != x ] kill -0 $PID 2/dev/null ; then + echo $0 $ARG: httpd started + else + echo $0 $ARG: httpd (pid $PID?) not running + ERROR=3 + fi + else + echo $0 $ARG: httpd not running: no pid file + ERROR=3 + fi else echo $0 $ARG: httpd could not be started ERROR=3 @@ -91,7 +103,19 @@ if [ $RUNNING -eq 0 ]; then echo $0 $ARG: httpd not running, trying to start if $HTTPD ; then - echo $0 $ARG: httpd started + sleep 1 + if [ -f $PIDFILE ] ; then + PID=`cat $PIDFILE` + if [ x$PID != x ] kill -0 $PID 2/dev/null ; then + echo $0 $ARG: httpd started + else + echo $0 $ARG: httpd (pid $PID?) not running + ERROR=3 + fi + else + echo $0 $ARG: httpd not running: no pid file + ERROR=3 + fi else echo $0 $ARG: httpd could not be started ERROR=5 @@ -115,7 +139,20 @@ if [ $RUNNING -eq 0 ]; then echo $0 $ARG: httpd not running, trying to start if $HTTPD ; then - echo $0 $ARG: httpd started + sleep 1 + if [ -f $PIDFILE ] ; then + PID=`cat $PIDFILE` + if [ x$PID != x ] kill -0 $PID 2/dev/null ; then + echo $0 $ARG: httpd started + else + echo $0 $ARG: httpd (pid $PID?) not running + ERROR=3 + fi + else + echo $0 $ARG: httpd not running: no pid file + ERROR=3 + fi + else else echo $0 $ARG: httpd could not be started ERROR=5 -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 536 5214 645 Howard St. Fax: (415) 536 5210 San Francisco CA 94105 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
Re: another map_to_storage gotcha.
On Thu, Sep 13, 2001 at 12:24:03PM -0400, Joshua Slive wrote: -Original Message- From: Ian Holsman [mailto:[EMAIL PROTECTED]] What I am suggesting is to move some of these configurations to Location / where they belong. I don't see any config directives that belong in Location /. Please be more specific before you do anything. Options Indexes AllowOverride None Order allow,deny Allow from all AddHandler type-map var DirectoryIndex index.html index.html.var The only thing that is filesystem specific are: Options FollowSymLinks (BTW.. there are NO 'location' directives installed in the httpd-std.conf) There are commented out location directives for /server-status and /server-info In general, I think this is proper. Most people serve content from the filesystem. When serving content from the filesystem, directory should be used in preference to location for the reasons I mentioned a couple days ago in another thread. We should not be encouraging people to use location except in specific circumstances. Location / is different. It is setting global configuration for the whole server. It ensures that you don't miss some critical bits. And your cut/dry Directory good. Location bad. does not hold. All of my configurations are Location based. That is because accessing the content through one location gives you DAV capabilities, and the other location gives your PHP- or SSI-processed content. With Subversion, we *only* have Location directives. There is absolutely nothing on the disk to serve. Location is an important directive and needs to be used in many, many cases. In this particular case, the problem arose because the attempt to set global options broke down. It was set only for one directory, not the whole server URL space. Using Location / fixes that. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Apache-1.3: question about mod_unique_id
On Thu, Sep 13, 2001 at 09:35:43AM -0700, dean gaudet wrote: On Tue, 11 Sep 2001, Greg Stein wrote: ... Seems that we now have 64 bit cpu's with potentially 64 bit pids. This adds to the equation, it looks like we need to cut over to those extra four bytes across all platforms. Oh, screw all that mess :-) Just use a UUID for the unique id. It has lots of bits, and it is already unique (by definition and without work). i'm not convinced the UUID implementation in 2.0 is unique, or is as robust as the technique mod_unique_id uses ... i started digging into this months ago and never quite finished. hopefully i'll get back to it and see if i'm right or wrong. Well, for Apache 1.3, you definitely can't use the APR UUID stuff :-) On Windows, for 1.3, you can simply call CoCreateGuid() and be done with it. And the Windows guids are unique. [ I seem to recall this thread started as a result of a Windows problem; UUIDs would solve it for that platform. maybe it was Netware? ] Regarding APR's UUID solution: if you think it isn't good enough, then I'd be interested in knowing. It collects a decent amount of see and then hashes it to get a random result. If there is more seed data that we could use, then we should. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Apache-1.3: question about mod_unique_id
Does Netware have UUIDs or a similar thing? Cheers, -g On Thu, Sep 13, 2001 at 03:06:21PM -0600, Brad Nicholes wrote: I checked with our CLIB people and they tell me that GetThreadID is *not* unique. In other words, if a thread is created, it is assigned an ID. If that thread is terminated and a new thread is created, the new thread may reuse the ID from the terminated thread. Brad [EMAIL PROTECTED] Thursday, September 13, 2001 2:57:08 PM Hi Bill, From: dean gaudet [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 11:45 AM but on windows you'll need to use both getpid() and GetThreadID... i think it's called something similar to that. it may be Get Thread Handle ... what you really want is the thread * that create_thread returns, or you could use the scoreboard slot, but i don't see an obvious way to get at either. also -- add an extra field to unique_id_rec for the thread id. I suggest we add a gettid() if one does not exist, via the os.h/os.c for MULTITHREAD platforms. Anyone who wants to hack on this, just assume it's available, and where it isn't, someone needs to implement (I'm happy to do so for Win32.) ok, sounds good. Then based on Dean's post and when Brad confirms that GetThreadID is always unique for NetWare we have only to add: #define gettid GetThreadID and in mod_unique_id.c we can remove the error warning and then change: pid = getpid(); to: #ifdef MULTITHREAD pid = gettid(); #else pid = getpid(); #endif On the other side I saw that some other sources inside Apache use getpid(), is this not a problem there too? And if only Win32 has an insufficient getpid() definition, it may be enough to redefine this only there and leave all other as is...?? Guenter. -- Greg Stein, http://www.lyra.org/
Re: another map_to_storage gotcha.
Slive, Joshua wrote: 1. (Important) As OtherBill has been trying to point out, Location is applied after Directory. Therefore, if you put these things in Location /, lots of things in Directory will fail to work. People won't understand why this doesn't deny access to anything: Location / Order allow,deny allow from all /Location Directory /path/to/really/secret/stuff deny from all /Directory And, IMO, this is just plain wrong, and needs to be fixed. It should never be possible for Location to override Directory with looser access restrictions, just as it should not be possible for Directory to override Location with looser permissions. In both cases, access should be determined by the most restrictive specification for a given resource. Doing anything else opens up lots of opportunities for accidental security holes and is just bad design. -alex
Re: Apache-1.3: question about mod_unique_id
On Thu, 13 Sep 2001, Brad Nicholes wrote: I checked with our CLIB people and they tell me that GetThreadID is *not* unique. In other words, if a thread is created, it is assigned an ID. If that thread is terminated and a new thread is created, the new thread may reuse the ID from the terminated thread. sorry -- i meant unique across multiple processes ... that is process 1 and process 2 couldn't both have a thread 57. (istr netware has processes and has a global shared memory space...) tid re-use is in principle a problem, but it requires a single thread to serve thousands of requests per second (too lazy to do the math right now). but also i don't think we kill/restart threads in the 1.3 multithreaded server, so it's in practice not a problem at all. ok, sounds good. Then based on Dean's post and when Brad confirms that GetThreadID is always unique for NetWare we have only to add: #define gettid GetThreadID and in mod_unique_id.c we can remove the error warning and then change: pid = getpid(); to: #ifdef MULTITHREAD pid = gettid(); #else pid = getpid(); #endif no -- 'cause the tid is not unique in general in the way i was describing. on unix it's possible to have pid 50 and pid 60 both with tid 1. you need the pid as well. (we start multiple processes and multiple threads within each in the 1.3 threaded server.) On the other side I saw that some other sources inside Apache use getpid(), is this not a problem there too? And if only Win32 has an insufficient getpid() definition, it may be enough to redefine this only there and leave all other as is...?? it's sufficient for most other uses... the insufficiency is that there's a thread-local counter in mod_unique_id (to avoid the need for a mutex) and it needs the tid to distinguish its counts from other threads. -dean
