Re: Stuck on DBD DSO Lock
On 5 Feb 2013, at 18:03, Reyad Attiyat wrote: The apr_dbd_get_driver call blocks in the child process I should also note this doesn't block when I'm running apache in debug (-X) and that I'm using apache 2.4 with the event mpm. Hmm. #4 0x7f59a03578fc in apu_dso_mutex_lock () at misc/apu_dso.c:46 #5 0x7f59a034e036 in apr_dbd_get_driver (pool=pool@entry=0x21c2138, name=0x7f599b1ea21c mysql, driver=0x230ee40) at dbd/apr_dbd.c:167 Looks like something else has that mutex when your function runs. The mutex was changed in r659293, which shares the same mutex between dbd and ldap, and makes it available to other modules. Do you have ldap loaded, or anything else using apu_dso_mutex_lock that you're aware of? I don't like the logic of it. A mutex should only be required if the driver is not yet loaded. Perhaps file a bug against APR? #6 0x7f599b1e4e8b in connect_database (db_pool=0x21c2138, error_messages=0x7f599a7c7000, dbd_config=dbd_config@entry=0x2273940) at database/dbd.c:35 Would it not make sense for your module to use mod_dbd to manage a database connection pool? -- Nick Kew
Re: Apache 2.4 adoption
How many Linux distros ship httpd 2.4? Fedora 18 is their first release to include httpd 2.4. Since Fedora is often an early adopter of new releases, I expect 2.4 hasn't trickled down to other distributions yet, e.g. RHEL, CentOS. It looks like 2.4 has only got as for as Debian experimental: http://packages.debian.org/search?keywords=apache Ubuntu haven't adopted it yet: http://packages.ubuntu.com/search?keywords=apache Of course the next question could be why have distros not adopted 2.4, is it just a matter of time or are there other factors? From: Kevin A. McGrail kmcgr...@pccc.com To: dev@httpd.apache.org; William A. Rowe Jr. wr...@rowe-clan.net Sent: Wednesday, 6 February 2013, 0:47 Subject: Re: Apache 2.4 adoption I won't be able to make the session but would add that because of a lack of mod perl support with 2.4, we have not fully embraced it. Might be others in a similar boat! Regards, KAM William A. Rowe Jr. wr...@rowe-clan.net wrote: I've found the following data summary very useful in terms of drill-down capability; http://w3techs.com/technologies/details/ws-apache/2.2/all http://w3techs.com/technologies/details/ws-apache/2.4/all while their breakdown/segmentation tabulations provide some interesting data such as; http://w3techs.com/technologies/breakdown/ws-apache/operating_system The very limited 'free' tabulation remaining from SecuritySpace seems to back up this assessment; http://www.securityspace.com/s_survey/data/201301/servers.html There seems to be a worthwhile discussion about the challenges presented by 2.4 which have adversely affected its adoption, during the ApacheCon Hackathon Mon 2/25 in Portland. I'd like to set aside time about 11am for that discussion for anyone who wants to participate. Once we take away some good information from that roundtable, it would be worthwhile to hold a BoF later in the week especially for end users who are looking at or challenged by adopting 2.4.
Re: Apache 2.4 adoption
On 06 Feb 2013, at 12:22 PM, p...@talk21.com wrote: How many Linux distros ship httpd 2.4? Fedora 18 is their first release to include httpd 2.4. Since Fedora is often an early adopter of new releases, I expect 2.4 hasn't trickled down to other distributions yet, e.g. RHEL, CentOS. It looks like 2.4 has only got as for as Debian experimental: http://packages.debian.org/search?keywords=apache Ubuntu haven't adopted it yet: http://packages.ubuntu.com/search?keywords=apache Of course the next question could be why have distros not adopted 2.4, is it just a matter of time or are there other factors? Speaking for myself, the major barrier to adoption for me is support by third party modules. What I mean by support is that the third party module has completed httpd v2.4 support, and has made a formal release of code with this support in place, and that code is stable. Further to that, the dependent modules must also be available as OS packages. It has been many years since I deployed naked make install code onto a box, formal packaging and the ability to roll forward and roll back is mandatory for me, and it has taken a while for these packages to appear. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
STATUS vote! (Was: Re: Time for 2.4.4)
Just a handful of backports in STATUS which appear viable for 2.4.4... look, review and vote if possible! :) On Feb 1, 2013, at 9:15 AM, Jim Jagielski j...@jagunet.com wrote: I think it's about time for 2.4.4... just a handful of proposed backports are still open. I propose we do a TR the end of next week with a release the week after that. I'll be RM. Comments?
Re: Building binaries and 3rd party dependencies
On Tue, 05 Feb 2013 16:43:13 -0800 Gregg Smith g...@gknw.net wrote: On 2/5/2013 2:12 PM, William A. Rowe Jr. wrote: In catching up with building 2.2.23 and getting somewhere with 2.4.3 (soon to be .24 and .4 from today's email notes), I'm left with one quandary. The 2.2 builds all used OpenSSL 0.9.8 and that's where I would leave it, while 2.4 builds aught to use 1.0.1. That, and libxml2 and lua are the packages we don't bundle. Since chances are from responses previously posted here on the subject, any binary distribution coming from a.o is not going to be able to load mod_php (PHP 5.4's php5apache2_4.dll currently) so it forces the use of mod_fcgid. That being the case, I see no reason not to use openssl 1.0.1. That may or may not be an issue. On Windows we can load both the PHP and mod_ssl flavors of OpenSSL at the same time if their dll names are unique. Unless msvc resources opened in httpd are closed by mod_php or visa versa, two flavors of msvc can also coexist. So mod_php aught to load and function although mod_fcgid is still more optimal. But for the expat and pcre dependencies, the versions we shipped in 2.2.23 and 2.4.3-deps sources are falling out of date. And I doubt a bundle of 2.4.4-deps is going to be updated either. expat's still in APR, I know libxml2 can be used, not sure how to build with it though. I plan to give libxml2 a spin in apr for httpd 2.4, given that mod_proxy_html requires that lib anyways.
Re: Documentation on mod_slotmem_shm
Hi Rainer, On 02/05/2013 08:04 PM CEST +02:00, Rainer Jung wrote: Example code using it: modules/cluster/mod_heartmonitor.c should be simplest, look for slotmem and SLOTMEM in there. That should at least show how to bootstrap and use slotmem. Okay, the longer I am reading anything related to mod_slotmem_shm, the more I get the impression that it is the wrong tool for my task. If I understood it correctly, mod_slotmem_shm organizes data in slots. This appears to make it unnecessarily limited to the number of slots I initialize it with. What I need is a way to transfer information from one long living request to another entirely independent request some time later. The first request contains a cookie (i.e. a random string), which is also contained in the second request. I would like to use this cookie as a handle to store some data (fixed size, if needed) generated during processing of the first request somewhere (at least for the life time of the first request). The second request then needs to be able to use the cookie to access the data the first request already generated. Moreover, an arbitrary number of such request pairs can happen at the same time. Given the requirements above, is the mod_slotmem_shm API still the right tool for this purpose? I just started looking at mod_socache_shmcb -- is this maybe better suited for the purpose described above? I could also go for a custom shared memory usage implementation, but I thought making use of any already existing API might be a better idea (trying avoid implementing things twice). So, any hint is appreciated... Regards, Micha
Re: Documentation on mod_slotmem_shm
On 06.02.2013 17:28, Micha Lenk wrote: On 02/05/2013 08:04 PM CEST +02:00, Rainer Jung wrote: Example code using it: modules/cluster/mod_heartmonitor.c should be simplest, look for slotmem and SLOTMEM in there. That should at least show how to bootstrap and use slotmem. Okay, the longer I am reading anything related to mod_slotmem_shm, the more I get the impression that it is the wrong tool for my task. If I understood it correctly, mod_slotmem_shm organizes data in slots. This appears to make it unnecessarily limited to the number of slots I initialize it with. What I need is a way to transfer information from one long living request to another entirely independent request some time later. The first request contains a cookie (i.e. a random string), which is also contained in the second request. I would like to use this cookie as a handle to store some data (fixed size, if needed) generated during processing of the first request somewhere (at least for the life time of the first request). The second request then needs to be able to use the cookie to access the data the first request already generated. Moreover, an arbitrary number of such request pairs can happen at the same time. Given the requirements above, is the mod_slotmem_shm API still the right tool for this purpose? I just started looking at mod_socache_shmcb -- is this maybe better suited for the purpose described above? I could also go for a custom shared memory usage implementation, but I thought making use of any already existing API might be a better idea (trying avoid implementing things twice). So, any hint is appreciated... It seems socache is a better choice in your case. slotmem is based on a fixed max. number of cache entries, each of fixed size and accessed by an integer key. For socache you can find some info in include/ap_socache.h and a probably not to complex example is modules/aaa/mod_authn_socache.c It comes with four different implementations (providers), the shmcb one is probably the one you'd use (or the memcached based one if sharing in a farm of hosts is needed). Regards, Rainer
Re: Building binaries and 3rd party dependencies
On 2/6/2013 8:14 AM, William A. Rowe Jr. wrote: That may or may not be an issue. On Windows we can load both the PHP and mod_ssl flavors of OpenSSL at the same time if their dll names are unique. Unless msvc resources opened in httpd are closed by mod_php or visa versa, two flavors of msvc can also coexist. So mod_php aught to load and function although mod_fcgid is still more optimal. In a perfect world, but the realities today seem to be different. Then again, only VC9 Apache binaries are able to run mod_php anyway. mod_fcgid alleviates both compiler/OpenSSL problems since it's running php in it's own process true, but at the cost of speed. I'm not sure I would consider that optimal, but it works! Gregg
New module added: mod_authn_yubikey
Hello, A new module has been created and is awaiting approval. If you are a modules.apache.org administrator, please check whether this module passes the requirements of an httpd module and approve it if so. Author: jens.frey Module name: mod_authn_yubikey Tags:security License: Apache License 2.0 Homepage: http://datapile.coffeecrew.org/mod_authn_yubikey-yubikey-apache-module/ Caption: The mod_authn_yubikey module leverages the yubikey for authentication.
Re: Apache 2.4 adoption
On Wed, 6 Feb 2013 10:22:45 + (GMT) p...@talk21.com wrote: How many Linux distros ship httpd 2.4? Fedora 18 is their first release to include httpd 2.4. Since Fedora is often an early adopter of new releases, I expect 2.4 hasn't trickled down to other distributions yet, e.g. RHEL, CentOS. It looks like 2.4 has only got as for as Debian experimental: http://packages.debian.org/search?keywords=apache Ubuntu haven't adopted it yet: http://packages.ubuntu.com/search?keywords=apache Of course the next question could be why have distros not adopted 2.4, is it just a matter of time or are there other factors? That is part of what I'd like to learn Monday if any active distro or packaging people are at the ApacheCon Hackathon. I also wonder if this would have been different if the httpd project had offered an rpm or apt-get packages, for example? It seems like there will always be a significant lag between a new major.minor release and seeing it injected into the major distributions.
