Re: MM
On Mon, 23 Apr 2001, Diana Shepard wrote: > decision on shared memory allocation method... 4.4BSD-style mmap() via > MAP_ANON > checking for shared memory maximum segment size... configure: error: Unable > to determine maximum shared memory segment size I've seen this on either Solaris or HP-UX (can't remember) as well--I'm pretty sure it's when I was using the build-in compiler. Try using gcc if you can, and I'll bet it will work. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MM
Cliff, Thanks for the reply, but I am already using the GNU gcc compiler. Diana Shepard -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 24, 2001 8:52 AM To: [EMAIL PROTECTED] Subject: Re: MM On Mon, 23 Apr 2001, Diana Shepard wrote: > decision on shared memory allocation method... 4.4BSD-style mmap() via > MAP_ANON > checking for shared memory maximum segment size... configure: error: Unable > to determine maximum shared memory segment size I've seen this on either Solaris or HP-UX (can't remember) as well--I'm pretty sure it's when I was using the build-in compiler. Try using gcc if you can, and I'll bet it will work. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM
On Mon, Apr 23, 2001 at 05:19:52PM -0600, Diana Shepard wrote: > Well I asked this about a week ago, but I'll ask again > because I can't figure out what the heck MM wants. > I'm trying to install mod_ssl2.8.2-1.3.19 on a Solaris 8 > system. I'm at step 4 of the mod_ssl INSTALLATION instructions, > the MM Shared Memory Library build. Here is the error I keep > getting: > > decision on shared memory allocation method... 4.4BSD-style mmap() via > MAP_ANON > checking for shared memory maximum segment size... configure: error: Unable > to determine maximum shared memory segment size > > Now I've checked via "sysdef -i" that a shared memory maximim > segment size is set and it is, with a value of 1048576. Surely > someone else has seen this error. I sure would appreciate some help. Hi, if you don't want to wait until the author of MM has time to look into that issue (he most probably is busy writing other fine software ;) you could try the following workaround: Edit the "configure" script to pretend that the autoconf-test for MM_SHM_MAXSEGSIZE did not fail. To do that, search for the line MM_SHM_MAXSEGSIZE="`cat conftestval`" and change that to set the size you determined from running sysdef MM_SHM_MAXSEGSIZE="1048576" I don't know for sure whether that will work, as I have't tried it actually -- but it should prevent the script from aborting, by substituting the (hopefully correct) value yourself. And if you are lucky, it's only the autoconf test routine that fails, not the actual lib-code at the time it's being used in the application... Erdmut -- Erdmut Pfeifer science+computing ag -- Bugs come in through open windows. Keep Windows shut! -- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MM
Erdmut, Thanks very much for the taking the time to respond. I tried your suggestion, but unfortunately the same error persists. Think I'll just have to skip MM in the mod_ssl install. Diana Shepard University of Colorado, Boulder -Original Message- From: Erdmut Pfeifer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 24, 2001 12:52 PM To: [EMAIL PROTECTED] Subject: Re: MM On Mon, Apr 23, 2001 at 05:19:52PM -0600, Diana Shepard wrote: > Well I asked this about a week ago, but I'll ask again > because I can't figure out what the heck MM wants. > I'm trying to install mod_ssl2.8.2-1.3.19 on a Solaris 8 > system. I'm at step 4 of the mod_ssl INSTALLATION instructions, > the MM Shared Memory Library build. Here is the error I keep > getting: > > decision on shared memory allocation method... 4.4BSD-style mmap() via > MAP_ANON > checking for shared memory maximum segment size... configure: error: Unable > to determine maximum shared memory segment size > > Now I've checked via "sysdef -i" that a shared memory maximim > segment size is set and it is, with a value of 1048576. Surely > someone else has seen this error. I sure would appreciate some help. Hi, if you don't want to wait until the author of MM has time to look into that issue (he most probably is busy writing other fine software ;) you could try the following workaround: Edit the "configure" script to pretend that the autoconf-test for MM_SHM_MAXSEGSIZE did not fail. To do that, search for the line MM_SHM_MAXSEGSIZE="`cat conftestval`" and change that to set the size you determined from running sysdef MM_SHM_MAXSEGSIZE="1048576" I don't know for sure whether that will work, as I have't tried it actually -- but it should prevent the script from aborting, by substituting the (hopefully correct) value yourself. And if you are lucky, it's only the autoconf test routine that fails, not the actual lib-code at the time it's being used in the application... Erdmut -- Erdmut Pfeifer science+computing ag -- Bugs come in through open windows. Keep Windows shut! -- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MM
Um, as I haven't looked at the source and am unlikely to have a chance to dig into it for you, I'm wary of leaping in with off-the-top-of-my-head suggestions ... *but* ... :-) On Tue, 24 Apr 2001, Diana Shepard wrote: > Thanks very much for the taking the time > to respond. I tried your suggestion, but > unfortunately the same error persists. Think > I'll just have to skip MM in the mod_ssl install. It looks like the line you replaced is not where the error is occuring, it's only a line that retrieves the value of an earlier test - ie. it assumes that an earlier test had succeeded and had deposited the result into the "conftestval" file. In other words, the failure seems to be occuring earlier. Ie. MM_SHM_MAXSEGSIZE="`cat conftestval`" should populate MM_SHM_MAXSEGSIZE with the text inside "conftestval". Try looking a line or two higher up to figure out where "conftestval" is actually created. That seems to be where the configuration process is actually stopping. I suspect if you stop that test from running (so hopefully the configuration scripts should get past that point) *and* follow the original suggestion about hard-coding the value for MM_SHM_MAXSEGSIZE, then you should be OK. Then again, I could be talking utter garbage too. :-) Good luck. Cheers, Geoff PS: Actually, by fishing about in this, you'll probably get an idea for what's going wrong as you make these changes. Once it's all up and running (touch wood), perhaps you could take a look at the offending code and see why it's not working as intended on your host system? It would be good to submit a fix (or at least a clear bug description) to Ralf so it can be fixed permanently. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM
On Tue, Apr 24, 2001 at 01:32:56PM -0600, Diana Shepard wrote:
> Erdmut,
>
> Thanks very much for the taking the time
> to respond. I tried your suggestion, but
> unfortunately the same error persists.
sorry, my fault, didn't look closely enough at what the script is
really doing. You also need to disable the
if { (eval echo configure: ...
line immediately above, by changing it to something like
if test x
So, the script fragment should then read:
(...)
EOF
#if { (eval echo configure:2476: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test
-s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
if test x
then
#MM_SHM_MAXSEGSIZE="`cat conftestval`"
MM_SHM_MAXSEGSIZE="1048576"
msg="$MM_SHM_MAXSEGSIZE"
(...)
Hope it's ok now,
Erdmut
--
Erdmut Pfeifer
science+computing ag
-- Bugs come in through open windows. Keep Windows shut! --
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re: MM
On Mon, Apr 23, 2001, Diana Shepard wrote:
> Well I asked this about a week ago, but I'll ask again
> because I can't figure out what the heck MM wants.
> I'm trying to install mod_ssl2.8.2-1.3.19 on a Solaris 8
> system. I'm at step 4 of the mod_ssl INSTALLATION instructions,
> the MM Shared Memory Library build. Here is the error I keep
> getting:
>
> decision on shared memory allocation method... 4.4BSD-style mmap() via
> MAP_ANON
> checking for shared memory maximum segment size... configure: error: Unable
> to determine maximum shared memory segment size
>
> Now I've checked via "sysdef -i" that a shared memory maximim
> segment size is set and it is, with a value of 1048576. Surely
> someone else has seen this error. I sure would appreciate some help.
First, to workaround your problem is simple. Just execute the
following command before you run the configure script:
$ echo "ac_cv_maxsegsize=${ac_cv_maxsegsize='128000'}" >config.cache
This gives you 128KB for a maximum shared memory segment (which usually
always works).
Second, to find out why the Autoconf test fails for you, I need the
resulting config.log file which Autoconf created on your machine.
Without this I cannot help you. Oh, and can you also show us the output
of "gcc -v" and "uname -a"?
On one of my Solaris 2.8 boxes on SPARC I see a fine "checking for
shared memory maximum segment size... 64MB (soft limit)" so it certainly
is not a problem in general with Solaris 2.8.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re: MM and EAPI
On Fri, Nov 03, 2000, Victor wrote: > Hi, I wanted to find out, if the MM lib is optional for Mod-SSL, Yes, MM is optional. > what > exactly does it add? It adds shared memory support to EAPI. > Is Mod-SSL with MM more stable then the one without > it? Faster? Not really more stable, but faster, yes. It allows you to use a shared memory based SSL session cache - which is faster than the filesystem based DBM variant. > What is the -DEAPI switch. It enables EAPI. Without this a stock Apache is built. > I've compiled Apache with MM and Mod-SSL and > now I get a warning that mod_jserv should be recompiled with -DEAPI > switch. Then compile mod_jserv with -DEAPI, please. If I remember the threads on this list, we already had answers for this multiple times. I think there is a special option for mod_jserv which enables -DEAPI automatically. Consult the modssl-users archives, please. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM and EAPI
Thanks for your help. I will look in the archives (should've done this before though). Victor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mm with mod_ssl
On Mon, May 31, 1999, John Hamlik wrote: > While doing a standard install: > > ./configure --with-apache=../apache_1.3.6 \ > --with-ssleay=../openssl-0.9.3a \ > --with-mm=../mm-1.0.4 \ > --prefix=/usr/local/apache > > I receive this error: > > Configuring for Apache, Version 1.3.6 > + using installation path layout: Apache (config.layout) > configure:Error: invalid option '--with-mm=../mm-1.0.4' > ./configure:Error: APACI failed > > O/S RedHat 6.0 Kernel 2.2.9 > > I must be doing something wrong, haven't figured out what. I have > followed the instructions. No, it's my fault. I've added --with-mm to the INSTALL document but later forgot to implement it in configure. It's already fixed for 2.3.2. In the meantime don't bother yourself about this, MM is still not really required. For 2.3.2 it maybe different, because I'm planning to release my shared memory cache with it. But then --with-mm will work, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM lib 1.08
On Fri, Jun 25, 1999, [EMAIL PROTECTED] wrote: > Hiyas.. Well I seem to have gotten mod_ssl 2.3.5 + mm 1.0.8 + apache + > mod_perl 1.20 compiled fine and running fine without seg faulting or Buss > Erroring on solaris 2.6.. So long has I define SSLSessionCache as shm > instead of dbm.. defining it as dbm would make it segfault on USR1 or HUP > signals.. > > Now, I'm sure this can also be an OS limit but, when I run the > following command : > > while : ; do kill -HUP `cat /var/run/httpd.pid` ; done > > apache stop working and the error log > > [error] mod_ssl: Cannot allocate shared memory: mm:core: failed to attach > shared memory (Too many open files) Wait, above you say it segfaults for DBM and USR1/HUP and here you show an MM related error. So, which variant now works fine and which not? I've tried the restarts myself and they worked fine under FreeBSD. Hmmm... but you're right, on one of my Solaris boxes I see segfaults on HUP signals, too. Seems like it's platform related. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM lib 1.08
On Fri, Jun 25, 1999, [EMAIL PROTECTED] wrote: > Hiyas.. Well I seem to have gotten mod_ssl 2.3.5 + mm 1.0.8 + apache + > mod_perl 1.20 compiled fine and running fine without seg faulting or Buss > Erroring on solaris 2.6.. So long has I define SSLSessionCache as shm > instead of dbm.. defining it as dbm would make it segfault on USR1 or HUP > signals.. > > Now, I'm sure this can also be an OS limit but, when I run the > following command : > > while : ; do kill -HUP `cat /var/run/httpd.pid` ; done > > apache stop working and the error log > > [error] mod_ssl: Cannot allocate shared memory: mm:core: failed to attach > shared memory (Too many open files) > > but besides that, it kicks butt.. atleast it kicked my butt.. > life is good now :).. I think I've now fixed this for mod_ssl 2.3.6. The problem was that the MM object wasn't destroyed on restarts. On my development machine it doesn't require an underlying file, so it never occured. On your platform it seems to use a temporary file, so you lost one fd per restart. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM lib 1.08
I just followed the US instructions in mod_ssl-2.3.5-1.3.6 with the optional mm-1.0.9 instructions. When I try to start the server I get: Ouch! ap_mm_create() failed IOT trap/Abort What /exactly/ does this mean... and where did I go wrong. BTW: I'm running: linux-2.2.9 libc.so.5.4.46 -- Jeffrey Hundstad __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MM and mod_ssl strangeness
Does the directory /path/logs exist? -Dave > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Avery Buffington > Sent: Thursday, November 16, 2000 10:24 AM > To: mod_ssl mailing list > Subject: MM and mod_ssl strangeness > > > > We've got a few sun E250's that I'm in the process of upgrading with > apache 1.3.14, mod_ssl-2.7.1-1.3.14, mm-1.1.3, and openssl-0.9.6. I > built apache on our development box and moved it to the respective > production servers. This worked fine on all of the boxes except one. > On this one particular box I get the following when trying to start: > > bash# /path/bin/httpsd-1.3.14 -f /path/etc/httpsd.portal.conf > Ouch! ap_mm_create(1048576, "/path/logs/httpsd.mm.363") > failed > Error: MM: mm:core: failed to acquire shared memory segment (Invalid > argument): OS: No such file or directory > > My config files are basically identical on all of the boxes. I get this > message even if I tell apache to use the dbm hash for the > SSLSessionCache not the shared memory. > > All boxes are Sun E250's running solaris 7, everything was built with: > > gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) > Solaris linker > > We are not using DSO so everything was compiled into the binary. > > Any ideas...? > > -Avery > -- > > > > Avery Buffington > System Administrator > FundsXpress Financial Network > [EMAIL PROTECTED] > > > "Perl: The only language you can uuencode and not notice." > -found in mod_ssl configure script for win32 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM and mod_ssl strangeness
yeah, the directory exists and I thought maybe it was a permissions issue, so to test it out I tried chmod'ing 777 logs, but still same error. -avery David Rees wrote: > > Does the directory /path/logs exist? > > -Dave > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Avery Buffington > > Sent: Thursday, November 16, 2000 10:24 AM > > To: mod_ssl mailing list > > Subject: MM and mod_ssl strangeness > > > > > > > > We've got a few sun E250's that I'm in the process of upgrading with > > apache 1.3.14, mod_ssl-2.7.1-1.3.14, mm-1.1.3, and openssl-0.9.6. I > > built apache on our development box and moved it to the respective > > production servers. This worked fine on all of the boxes except one. > > On this one particular box I get the following when trying to start: > > > > bash# /path/bin/httpsd-1.3.14 -f /path/etc/httpsd.portal.conf > > Ouch! ap_mm_create(1048576, "/path/logs/httpsd.mm.363") > > failed > > Error: MM: mm:core: failed to acquire shared memory segment (Invalid > > argument): OS: No such file or directory > > > > My config files are basically identical on all of the boxes. I get this > > message even if I tell apache to use the dbm hash for the > > SSLSessionCache not the shared memory. > > > > All boxes are Sun E250's running solaris 7, everything was built with: > > > > gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) > > Solaris linker > > > > We are not using DSO so everything was compiled into the binary. > > > > Any ideas...? > > > > -Avery > > -- > > > > > > > > Avery Buffington > > System Administrator > > FundsXpress Financial Network > > [EMAIL PROTECTED] > > > > > > "Perl: The only language you can uuencode and not notice." > > -found in mod_ssl configure script for win32 > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] -- Avery Buffington System Administrator FundsXpress Financial Network [EMAIL PROTECTED] "Perl: The only language you can uuencode and not notice." -found in mod_ssl configure script for win32 S/MIME Cryptographic Signature
Re: MM and mod_ssl strangeness
In message <[EMAIL PROTECTED]> you write: |> bash# /path/bin/httpsd-1.3.14 -f /path/etc/httpsd.portal.conf |> Ouch! ap_mm_create(1048576, "/path/logs/httpsd.mm.363") failed |> Error: MM: mm:core: failed to acquire shared memory segment (Invalid argument): OS: |No such file or directory Sounds familiar. |> My config files are basically identical on all of the boxes. Check shmsys:shminfo_shmmax in /etc/system. When mm is built, it seems to memorize somehow its value. An apache built on a machine with a very large shmmax installed on a machine with a much smaller shmmax might ask for a shm segment larger than the kernel is configured for, thus the "Invalid argument". Volker __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM and mod_ssl strangeness
Yep, that's what it was. The box it was built on had a huge value for shminfo_shmmax (apparently it was running oracle at one time or another). So for now the simplest solution was to rebuild the mm library on this particular target machine and then rebuild apache on that box. thanks for the help!!! -Avery Volker Borchert wrote: > > In message <[EMAIL PROTECTED]> you write: > > |> bash# /path/bin/httpsd-1.3.14 -f /path/etc/httpsd.portal.conf > |> Ouch! ap_mm_create(1048576, "/path/logs/httpsd.mm.363") failed > |> Error: MM: mm:core: failed to acquire shared memory segment (Invalid argument): >OS: No such file or directory > > Sounds familiar. > > |> My config files are basically identical on all of the boxes. > > Check shmsys:shminfo_shmmax in /etc/system. > > When mm is built, it seems to memorize somehow its value. An apache > built on a machine with a very large shmmax installed on a machine > with a much smaller shmmax might ask for a shm segment larger than > the kernel is configured for, thus the "Invalid argument". > > Volker > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] -- Avery Buffington System Administrator FundsXpress Financial Network [EMAIL PROTECTED] "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn S/MIME Cryptographic Signature
Re: MM build / deploy question
Hi, "Schwartz, Mark" wrote: > When using MM, is the semaphore file location hard-coded at compile time? I > am trying to build a binary of apache which can be distributed across > multiple servers and installed in different directories. When I put it in a > different directory, I get the following error: > > "Ouch! ap_mm_create: failed to open semaphore file (no such file or > directory)" > > how can I build a "distributable" version of apache with MM enabled and not > care where apache is installed? I would prefer not to build mm separately > if possible as it is only being used by apache. I think that it would be better (and more secure) to use the mkstemp(3) function from OpenBSD for generating file names in the MM library. I am going to send a patch to Ralf soon. But I haven't got any response from him reg. my previous patch :-( Regards Alex -- http://home.t-online.de/home/Alexander.Farber/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM problem: ap_mm_create() fails
On Thu, Feb 08, 2001 at 01:19:06PM +0100, Owen Boyle wrote: > Now when I try to start apache on the external machine, I get: > > # ./httpd > Ouch! ap_mm_create(1048576, "/home/apache/logs/httpd.mm.14992") failed > Error: MM: mm:core: failed to acquire shared memory segment (Invalid > argument): OS: No such file or directory > > The directory structure and file permissions are identical on both > machines so I don't know what the problem can be. > > Does anyone have any ideas? > There's a couple of things to try - first try the ipcs command to see the ipc status. Also check that you don't have a different settings between the two machine for ipc related stuff - see your /etc/system vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM problem: ap_mm_create() fails
Mads Toftum wrote: > There's a couple of things to try - first try the ipcs command to > see the ipc status. Er I guess this might have something to do with it: # ipcs IPC status from as of Thu Feb 8 15:18:19 2001 Message Queue facility not in system. T ID KEYMODEOWNERGROUP Shared Memory: Semaphore facility not in system. I did mention that this was reduced system but I didn't realise just how reduced it was... Best regards (with egg on my face), Owen Boyle. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM access via rsync?
On Mon, Aug 30, 1999, [EMAIL PROTECTED] wrote: > Any plans to make the MM CVS archive available via rsync? > > A recent query shows only: > > RSYNC service ready (rsync 2.3.1) > > wml-distrib Website META Language (WML): Distribution Files > wml-cvs Website META Language (WML): CVS Repository > eperl-distrib Embedded Perl 5 Language (ePerl): Distribution Files > sw-distribSoftware Distribution Files > openssl-web OpenSSL: Web site > openssl-ftp OpenSSL: FTP site > openssl-cvs OpenSSL: CVS repository > modssl-webApache Interface to OpenSSL (mod_ssl): Web site > modssl-ftpApache Interface to OpenSSL (mod_ssl): FTP site > modssl-cvsApache Interface to OpenSSL (mod_ssl): CVS repository Hmmm sure, why not. It's now available. But keep in mind that it's not the original one (which is on my development box). Instead it's a manually updated mirror of the original repository. So expect a delay in updates. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM-1.0.11 configuration problems ....
On Tue, Sep 07, 1999, Mehul N. Sanghvi wrote: > I have upgraded my webserver to Apache 1.3.9 and was also in > the process of upgrading my mod_ssl. Of course with the newer mod_ssl > I need to use the MM package. No, you don't _HAVE_ to use MM. It's just recommended. But it's not a requirement. > I am having difficulty in getting the > configurations process itself to complete for MM. Here is the > configuration line I am using: > > prompt% ./configure --prefix=/opt --enable-debug --with-shm=IPCSHM \ > --with-sem=IPCSEM --enable-shared > >Despite haveing --enable-shared it does not want to build > shared libraries. Here is related output > >checking for gcc option to produce PIC... -fPIC >checking if gcc PIC flag -fPIC works... no > > Now I know that I can produce shared libraries with gcc (I have done > that for other packages like LessTif, swig, XmHTML, guile, etc) so I > am not sure why MM thinks it cant produce PIC code. The stuff is based on GNU libtool, so that's a problem with libtool 1.3.3, I think. I cannot do anything here, except to recommend you to use --disable-shared, of course. > The place where the configuration dies is when doing the Virtual > Memory Page Size stuff: > >Virtual Memory Page Size: >checking for unistd.h... (cached) yes >checking for getpagesize... no >checking for sysconf... no >checking for _SC_PAGESIZE in unistd.h... yes >./configure:Error: decision on memory page size determination failed Your problem is that although _SC_PAGESIZE is defined, no sysconf(3) function can be found. So MM cannot make a decision (because getpagesize also does not exists, but one the two has to exist). See in config.log _why_ sysconf is not found and try to fix this. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM-1.0.11 configuration problems ....
> > On Tue, Sep 07, 1999, Mehul N. Sanghvi wrote: > > > I have upgraded my webserver to Apache 1.3.9 and was also in > > the process of upgrading my mod_ssl. Of course with the newer mod_ssl > > I need to use the MM package. > > No, you don't _HAVE_ to use MM. It's just recommended. > But it's not a requirement. > Ahhh, I see. Great, at least I can proceed with my mod_ssl installation. > > The stuff is based on GNU libtool, so that's a problem with libtool 1.3.3, I > think. I cannot do anything here, except to recommend you to use > --disable-shared, of course. > Hmmm... another package I was building yesterday was libmcrypt, which also uses libtool. It uses version "1.3 (1.385.2.117)". This worked correctly. Must be something with the newer libtool. Will have to look in there. > > Your problem is that although _SC_PAGESIZE is defined, no sysconf(3) function > can be found. So MM cannot make a decision (because getpagesize also does not > exists, but one the two has to exist). See in config.log _why_ sysconf is not > found and try to fix this. Will look in that direction and let you know what comes up. Thanks for the pointers. mehul -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi stolen from Ben Laurie on the FSB list. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM doesn't work now with 0.9.6e
> configure mod_ssl --with-apache=../apache_1.3.26 Seems like you need to supply mod_ssl with all of the configure directives you show below for apache, and then when it comes time to compile apache, you just run the auto-generated config.status script. At least that worked for me using the same versions you are using (under Red Hat Linux). Of course, I don't have mod_perl, so that may make a difference... > > install mod_perl (perl Makefile.PL APACHE_SRC=../apache_1.3.26/src > DO_HTTPD=0 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1) > > set SSL_BASE and EAPI_MM variables to ../openssl0.9.6e and ../mm-1.2.1 > > configure and install apache: > > ./configure --enable-module=proxy --enable-module=so > --activate-module=src/modules/perl/libperl.a --enable-module=perl > --enable-rule=SHARED_CORE --enable-module=ssl > > make > > make certificate > > make install David __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: MM doesn't work now with 0.9.6e
I'm an idiot. I set the EAPI_MM variable as MM_EAPI. Dyslexia gets you every time. Thanks Dave Dave Lowenstein Programmer/Analyst Instructional Technology Services San Diego State University (619)594-0270 http://www-rohan.sdsu.edu/dept/its On Wed, 31 Jul 2002, David Wall wrote: > > configure mod_ssl --with-apache=../apache_1.3.26 > > Seems like you need to supply mod_ssl with all of the configure directives > you show below for apache, and then when it comes time to compile apache, > you just run the auto-generated config.status script. At least that worked > for me using the same versions you are using (under Red Hat Linux). Of > course, I don't have mod_perl, so that may make a difference... > > > > > install mod_perl (perl Makefile.PL APACHE_SRC=../apache_1.3.26/src > > DO_HTTPD=0 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1) > > > > set SSL_BASE and EAPI_MM variables to ../openssl0.9.6e and ../mm-1.2.1 > > > > configure and install apache: > > > > ./configure --enable-module=proxy --enable-module=so > > --activate-module=src/modules/perl/libperl.a --enable-module=perl > > --enable-rule=SHARED_CORE --enable-module=ssl > > > > make > > > > make certificate > > > > make install > > > David > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] > __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mm-1.0.6 fails make test on AIX4.2..
Hi Ralf! What I meant with fail to compile mm-1.0.6 was that I succeded to do 'make' but when I tried to run 'make test' I got segmentation fault when testing allocation of MM object. This seems to come out of that the system is unable to determine the shared memory maximum segment size on the system. If I f.e. increase "#define MM_SHM_MAXSEGSIZE 0" in mm_conf.h to 32*1024 I succeed with the test. But I still got problem on both Solaris v.2.7 and AIX 4.2 when I try to start the httpd. I still get an error messages saying something about problems with ap_mm_create(). The screendump before and after changes is added below ! Best Regards, Patrick Harlin, Tech.Consult. Media Communications Eur AB (publ) During ./configure checking for shared memory maximum segment size... unknown IN mm_conf.h default /* Shared Memory Maximum Segment Size */ #define MM_SHM_MAXSEGSIZE 0 *** TESTING GLOBAL LIBRARY API *** Fetching library version version = 0x100206 *** TESTING LOW-LEVEL SHARED MEMORY API *** === Testing Memory Segment Access === Creating 16KB shared memory core area actually allocated core size = 16384 Writing 0xF5 bytes to shared memory core area write to core[016383] Reading back 0xF5 bytes from shared memory core area read from core[016383] Destroying shared memory core area === Testing Memory Locking === Creating small shared memory core area actually allocated core size = 8 count=032769 (parent) Destroying shared memory core area *** TESTING STANDARD MALLOC-STYLE API *** === Testing Allocation === Creating MM object /bin/sh: 15398 Segmentation fault(coredump) make: 1254-004 The error code from the last command is 139. Stop. IN mm_conf.h after changes below /* Shared Memory Maximum Segment Size */ #define MM_SHM_MAXSEGSIZE 32*1024 *** TESTING GLOBAL LIBRARY API *** Fetching library version version = 0x100206 *** TESTING LOW-LEVEL SHARED MEMORY API *** === Testing Memory Segment Access === Creating 16KB shared memory core area actually allocated core size = 16384 Writing 0xF5 bytes to shared memory core area write to core[016383] Reading back 0xF5 bytes from shared memory core area read from core[016383] Destroying shared memory core area === Testing Memory Locking === Creating small shared memory core area actually allocated core size = 8 count=032768 (child ) Destroying shared memory core area *** TESTING STANDARD MALLOC-STYLE API *** === Testing Allocation === Creating MM object Information for MM memory area = 0x3418 - 0x300e0418 memory size = 28672 memory offset = 24 bytes spare = 28648 bytes free = 0 (0 chunks) bytes allocated = 0 List of free chunks: actually available bytes = 28648 Allocating areas inside MM Information for MMlocated=27434 add=001936 memory area = 0x3418 - 0x300e0418 memory size = 28672 memory offset = 28000 bytes spare = 672 bytes free = 0 (0 chunks) bytes allocated = 27976 List of free chunks: === Testing Defragmentation === Fragmenting memory area by freeing some selected areas Information for MM memory area = 0x3418 - 0x300e0418 memory size = 28672 memory offset = 28000 bytes spare = 672 bytes free = 13456 (21 chunks) bytes allocated = 14520 List of free chunks: chunk #001: 0x3440-0x3540 (16 bytes) chunk #002: 0x3468-0x35e8 (24 bytes) chunk #003: 0x34a8-0x37a8 (48 bytes) chunk #004: 0x3518-0x3998 (72 bytes) chunk #005: 0x35c0-0x3cc0 (112 bytes) chunk #006: 0x36b8-0x30001038 (152 bytes) chunk #007: 0x3808-0x30001508 (208 bytes) chunk #008: 0x39c8-0x30001a48 (264 bytes) chunk #009: 0x3c00-0x30002100 (336 bytes) chunk #010: 0x3ec8-0x30002848 (408 bytes) chunk #011: 0x30001228-0x30003128 (496 bytes) chunk #012: 0x30001638-0x30003ab8 (584 bytes) chunk #013: 0x30001b00-0x30004600 (688 bytes) chunk #014: 0x30002098-0x30005218 (792 bytes) chunk #015: 0x30002708-0x30006008 (912 bytes) chunk #016: 0x30002e68-0x30006ee8 (1032 bytes) chunk #017: 0x300036c0-0x30007fc0 (1168 bytes) chunk #018: 0x30004028-0x300091a8 (1304 bytes) chunk #019: 0x30004aa8-0x3000a5a8 (1456 bytes) chunk #020: 0x30005658-0x3000bad8 (1608 bytes) chunk #021: 0x30006340-0x3000d240 (1776 bytes) Freeing all areas Information for MM memory area = 0x3418 - 0x300e0418 memory size = 28672 memory offset = 28000 bytes spare = 672 bytes free = 27976 (1 chunk) bytes allocated = 0 List of free chunks: chunk #001: 0x3430-0x3006d8b0 (27976 bytes) Checking for memory leaks Fine, we've again 28648 bytes available Destroying MM object OK - ALL TESTS SUCCESSFULLY PASSED.
Re: MM lib 1.09 Was: MM lib 1.08
On Wed, Jul 14, 1999, Jeffrey Hundstad wrote: > After creating /usr/local/apachelogs this error went away. > > On 14 Jul, To: [EMAIL PROTECTED] wrote: > > I just followed the US instructions in mod_ssl-2.3.5-1.3.6 with the > > optional mm-1.0.9 instructions. > > > > When I try to start the server I get: > > > > Ouch! ap_mm_create() failed > > IOT trap/Abort > > > > > > What /exactly/ does this mean... and where did I go wrong. > > > > BTW: I'm running: > > linux-2.2.9 > > libc.so.5.4.46 You mean the directory into which MM wants to create the temp files didn't exist, right? Ok, the "Ouch!" message should be more descriptive, of course. I've enhanced it for 2.3.6: it now prints both the exact ap_mm_create() call, the MM error and the errno. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mm library enable or disable shared for modssl as DSO.
On Tue, Jun 10, 2003 at 02:31:28PM -0700, kulkarni veena wrote: > Hello, > > I'm trying to use mm shared library for Apache2.0.45 > with modssl as DSO . My question is should I configure > MM_shared library --enable-shared or --disable-shared. > There's no need for MM with apache2 - it has its own shared memory handling built in if your os supports it. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mm library enable or disable shared for modssl as DSO.
Hi, Thanks. To use the shared library from apache should something be set while configuring apache? I'm using SunOS 5.9 , does this OS support it? I was trying to do this hoping this would make my https server work for Internet explorer. -veena --- Mads Toftum <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2003 at 02:31:28PM -0700, kulkarni > veena wrote: > > Hello, > > > > I'm trying to use mm shared library for > Apache2.0.45 > > with modssl as DSO . My question is should I > configure > > MM_shared library --enable-shared or > --disable-shared. > > > There's no need for MM with apache2 - it has its own > shared > memory handling built in if your os supports it. > > vh > > Mads Toftum > -- > `Darn it, who spiked my coffee with water?!' - lwall > > __ > Apache Interface to OpenSSL (mod_ssl) >www.modssl.org > User Support Mailing List > [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: mm library enable or disable shared for modssl as DSO.
On Tue, Jun 10, 2003 at 02:53:38PM -0700, kulkarni veena wrote: > Hi, > > Thanks. To use the shared library from apache should > something be set while configuring apache? I'm using > SunOS 5.9 , does this OS support it? > It shouldn't be a problem on your os - at least I've used shared memory session caching on solaris 7 & 8 many times. The thing to configure is SSLSessionCache which should be set to something like: SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslsessioncache vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MM doesn't work now with 0.9.6e - Security related Bug in mm < mm-1.2.1
Hi there, did you notice that there is a security bug in mm < version 1.2.1 as well which was announced on Jul 30 2002? Have a look here: Advisory: http://www.openpkg.org/security/OpenPKG-SA-2002.007-mm.html (CERT ID "2002-453dcert"). You can get the latest version of mm here: http://www.ossp.org/pkg/lib/mm/ Kind regards, B. Courtin -Original Message- From: David Lowenstein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 10:33 PM To: [EMAIL PROTECTED] Subject: MM doesn't work now with 0.9.6e I just installed the newest version of openssl and recompiled mm, mod_ssl, mod_perl, and apache. Now when I start apache I get an error from my httpd.conf file about the SSLSessionCache option. The error is: SSLSessionCache: shared memory cache not useable on this platform Well, it was with openssl 0.9.6c. I didn't do anything different in my installation steps which were: install openssl configure mm with disable-shared make configure mod_ssl --with-apache=../apache_1.3.26 install mod_perl (perl Makefile.PL APACHE_SRC=../apache_1.3.26/src DO_HTTPD=0 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1) set SSL_BASE and EAPI_MM variables to ../openssl0.9.6e and ../mm-1.2.1 configure and install apache: ./configure --enable-module=proxy --enable-module=so --activate-module=src/modules/perl/libperl.a --enable-module=perl --enable-rule=SHARED_CORE --enable-module=ssl make make certificate make install Without the shared option in the config file, apache starts just fine, but it won't work with: SSLSessionCacheshm:/usr/local/apache/logs/ssl/ssl_scache(512000) It worked before. What did I break? Dave Lowenstein Programmer/Analyst Instructional Technology Services San Diego State University (619)594-0270 http://www-rohan.sdsu.edu/dept/its On Wed, 31 Jul 2002, Matt Nelson wrote: > At 06:02 PM 7/31/2002 +0200, you wrote: > >See comments, > > Ditto, > > >Rgds, > > > >Owen Boyle > > > > >-Original Message- > > >From: Matt Nelson [mailto:[EMAIL PROTECTED]] > > >Sent: Mittwoch, 31. Juli 2002 17:01 > > >To: [EMAIL PROTECTED] > > >Subject: RE: Error message help > > > > > > > > >Well I may have figured this out, https is now running, cert > > >was in the wrong place, > > > >..or your SSLCertificateFile directive was pointing to the wrong place :-) > > Yup, but dang I was confused on where it went. Everything I've read said > put it somewhere different. Error logs are you friends. > > > > > ...but https returns the default web page for the apache > > >installation, instead of the real site, which does come up with just > > >http. I think I can figure that out, but if anyone has pointer > > >thanks, and thanks for suffering my dumb questions. > > > >Check out your DocumentRoot directive in the SSL virtual host - there > >should only be one. If there is more than one, apache will use the last > >one... It is this directive which tells apache where to fetch the content. > > Yeah I found that right after I wrote that. > > > > > > >-- > > >Matt > > > > > > > > >At 09:36 AM 7/31/2002 -0500, you wrote: > > >>At 03:56 PM 7/31/2002 +0200, you wrote: > > >>> >From: Matt Nelson [mailto:[EMAIL PROTECTED]] > > >>> > > > >>> >Now, the error I'm getting now that I can't seem to find any > > >>> >help on, in > > >>> >the error_log is: > > >>> > > > >>> >OpenSSL: error:0D06B078:asn1 encoding > > >routines:ASN1_get_object:header > > >>> too long > > >>> > > > >>> > > >>>Unusual.. Do you see anything in the browser? Also: > > >>> > > >>>- What versions of apache, mod_ssl, openssl? > > >> > > >> > > >>Apache 1.3.22 > > >>OpenSSL 0.9.6 > > >>mod_ssl 1.4 > > > >Um... If I were you, I'd get apache 1.3.26, OpenSSL 0.9.6e and mod_ssl > >2.8.10. That's teh latest mix, also pay attention to the security advisory > >that was posted to the list today. > > I'll do that. > > > > >> > > >>>- Static or DSO? > > > >When you compiled apache, did you statically compile in mod_ssl (i.e. > >--enable-module=ssl) so that the mod_ssl binary gets munged in with the > >apache binary to produce a big binary *or* did you compile mod_ssl as a > >shared object which would be loaded dynamically at runtime (DSO = Dynamic > >Shared Object), i.e. --enable-shared=ssl? Usually, it doesn't make much > >difference when they're working, but since yours was not working, I > >thought I'd ask. > > I didn't compile, I used everything stock from the Caldera 3.11 server > install. A bad idea now I know, if I'd done it on my own or recompiled, I'd > know which it was, among other things. > > > >> > > >> > > >>I'll be honest and say I don't quite understand that > > >question. I'm way > > >>more new at this what I wished. I could probably answer that > > >question, if > > >>asked in different terms. > > >> > > >>>- What browser? > > >> > > >>IE, Mozilla, you name it. > > > >Just in case it was a funny browser - SSL is as much to do with the client > >as it is to do with the server so it is essential to verify a
