required packages for mod_uio.so for Windows Environment
Hi I downloaded apache_2.2.8-win32-x86-no_ssl and installed apache http server 2.2.8 in windows 32 bit env. After modifying httpd.conf file I am not able to start apache server. When I checked the syntax of httpd.conf file by issuing the command httpd.exe –t it says Cannot load mod_uio.so into server. The specified module could not be found. Please reply which dll/package is required to download in windows env. -- View this message in context: http://old.nabble.com/required-packages-for-mod_uio.so-for-Windows-Environment-tp32906672p32906672.html Sent from the Apache HTTP Server - Module Writers mailing list archive at Nabble.com.
Re: required packages for mod_uio.so for Windows Environment
When I checked the syntax of httpd.conf file by issuing the command httpd.exe –t it says Cannot load mod_uio.so into server. The specified module could not be found. Please reply which dll/package is required to download in windows env. Ask the vendor of mod_uio.so, not a list about developing modules.
Re: required packages for mod_uio.so for Windows Environment
On 12/2/2011 10:23 PM, KESTAR wrote: Hi I downloaded apache_2.2.8-win32-x86-no_ssl and installed apache http server 2.2.8 in windows 32 bit env. After modifying httpd.conf file I am not able to start apache server. When I checked the syntax of httpd.conf file by issuing the command httpd.exe –t it says Cannot load mod_uio.so into server. The specified module could not be found. Please reply which dll/package is required to download in windows env. Note that the installer does not replace your existing httpd.conf file if it already exists. This facilitates uninstalling and reinstalling httpd without losing your config or content. So this is probably a leftover you had in your own config. You can compare your current conf/httpd.conf with conf/default/httpd.conf, which is what the installer would have written if you didn't have a config file already. Alternately, you added mod_uio but we don't ship such a module. Finally, 2.2.8 is very, very stale, and has a number of security defects that are resolved in the current, 2.2.21 release. I would encourage you to install the current release rather than such an old flavor.
Re: mod_status scoreboard showing wrong slot quantity
If you count all those chars, you'll get 1920. Anybody knows what's going on? yep. ServerLimit * ThreadLimit (defaulted) = 30 * 64 = 1920 Hmm, that's indeed the case. I was perplexed by wording there. Those ServerLimits and ThreadLimits could be set automatically, based on user's impression of maximum amount of connections he wants the server to handle. Thanks for help. -- Best regards, Yuri Arabadji -- Systems Engineer
Re: svn commit: r1203859 [2/2] - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c ...
While googling why one of my compilers would error out on this, it revealed that the __FUNCTION__ macro is C99 and not ANSI nor C89, and for now westillwant to support C89 AFAIK. I do not remember a go-ahead with C99 code. Did I miss that? Unfortunately, you didn't miss it. Cheers, Gregg -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: mod_status scoreboard showing wrong slot quantity
- Original Message - If you count all those chars, you'll get 1920. Anybody knows what's going on? yep. ServerLimit * ThreadLimit (defaulted) = 30 * 64 = 1920 Hmm, that's indeed the case. I was perplexed by wording there. Those ServerLimits and ThreadLimits could be set automatically, based on user's impression of maximum amount of connections he wants the server to handle. That's sort of what MaxRequestWorkers (the artist formerly know as MaxClients) is for: http://httpd.apache.org/docs/trunk/mod/mpm_common.html#maxrequestworkers The only problem is that you still have to scale those other two to get there. I am still of the opinion it would make sense to scale those automagickally: We define (an arbitrary, perhaps sane) default for MaxRequestWorkers. Using a library such as hwloc to determine the CPU topology (and the amount of available memory) we then auto-scale ServerLimit and ThreadLimit and ThreadsPerChild. Thanks for help. -- Best regards, Yuri Arabadji -- Systems Engineer So long, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: mod_status scoreboard showing wrong slot quantity
fuck off and delete my email from your list...I have tried many times..You are bullshit !! On Thu, Dec 1, 2011 at 11:52 AM, Yuri Arabadji y...@fused.com wrote: Hi. It appears that someone messed up scoreboard in httpd 2.2. We've got mpm worker with the following config: http://stage.fused.net/huy#worker.c MaxSpareThreads 250 MinSpareThreads 25 ThreadsPerChild 25 ServerLimit 30 MaxClients 750 It's pretty obvious the total number of child threads should be max. 750, but scoreboard shows a different picture: http://stage.fused.net/server-status?auto Total Accesses: 16 Total kBytes: 12 CPULoad: .0909091 Uptime: 11 ReqPerSec: 1.45455 BytesPerSec: 1117.09 BytesPerReq: 768 BusyWorkers: 1 IdleWorkers: 74 Scoreboard: _..._...___W_... If you count all those chars, you'll get 1920. Anybody knows what's going on? Thanks. -- Best regards, Yuri Arabadji -- Systems Engineer -- Thanks regards, Sagar Chanana Mobile;- +91 9031958808
Re: svn commit: r1203859 [2/2] - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c ...
fuck off and delete my email from your list...I have tried many times..You are bullshit !! 2011/12/2 Igor Galić i.ga...@brainsware.org While googling why one of my compilers would error out on this, it revealed that the __FUNCTION__ macro is C99 and not ANSI nor C89, and for now westillwant to support C89 AFAIK. I do not remember a go-ahead with C99 code. Did I miss that? Unfortunately, you didn't miss it. Cheers, Gregg -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE -- Thanks regards, Sagar Chanana Mobile;- +91 9031958808
Virtual host and DNS record
Thanks Tom for your answer, But it's not working for the IP-based part, what is the default vhost for IP-based vhost? Also i am using IP-based because of SSL on one Name-based vhost and SSL the Ip-based vhost. Regards, Tom Evans-3 wrote: On Thu, Dec 1, 2011 at 9:34 AM, ipmanux ipma...@gmail.com wrote: Dear all, I am using RHEL with HTTPD+TOMCAT, I configured 4 VHOSTs on the same server -3 VHOST (named-based) 1st vhost: www.abc.com 2nd vhost: www.def.com 3rd vhost: www.ghi.com -1 VHOST(IP-based) www.klm.com My DNS record are for the 3 VHOST (named-based) pointing to 192.168.1.2 and for the VHOST(IP-based) pointing to an alias 192.168.1.3 In case someone create a DNS entry pointing to one of my 2 IP address for example: www.someone.com - 192.168.1.2 How to config Apache to not respond or redirect to a error page when an end user browse this URL:www.someone.com ? The first vhost for a particular vhost spec (eg, the first VirtualHost *:80 or the first VirtualHost 1.2.3.4:80, depending on what you have for NameVirtualHost) is the default vhost. When a request comes in for a domain name that is not served by any of your vhosts, it will be served from the default vhost. Hence, if you want unknown domains to error, your first vhost should handle this. Eg: VirtualHost *:80 # The default/error vhost, no ServerName required DocumentRoot /var/www/sites/error /VirtualHost VirtualHost *:80 ServerName foo.com /VirtualHost Cheers Tom -- View this message in context: http://old.nabble.com/Virtual-host-and-DNS-record-tp32890382p32902970.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
htcacheclean and expired cache entries
Greetings, I noticed that htcacheclean won't clean expired entries unless the specified size limit is reached. Is there any specific reason for this ? I'm looking into freeing up some inodes on some of my servers where the total cache size hasn't reached my specified limit. Would it be worthwhile to add a switch to enable cleaning of expired entries even if the size limit isn't reached ?
Re: htcacheclean and expired cache entries
On 02 Dec 2011, at 8:52 PM, Rob Landrito wrote: I noticed that htcacheclean won't clean expired entries unless the specified size limit is reached. That's by design. Is there any specific reason for this ? I'm looking into freeing up some inodes on some of my servers where the total cache size hasn't reached my specified limit. Would it be worthwhile to add a switch to enable cleaning of expired entries even if the size limit isn't reached ? The short answer is that you're probably looking for the -L option in the (soon to be released) httpd v2.4 to limit to the given number of inodes, as described here: http://httpd.apache.org/docs/trunk/programs/htcacheclean.html#options You probably want to use both the -l and -L options together to keep files safely within limits on disk. To answer your question, creating content has a cost associated with it, you want to keep content around for as long as humanly possible. Unlike typical caching systems that have a dual state it's cached / it's deleted, HTTP caching offers a three state system: it's fresh / it's stale / it's deleted. Initially, when cached, content is typically fresh for a freshness lifetime, and when it gets old enough, the content goes into the second state, that of being stale. Using the conditional request mechanism, the backend server is given the opportunity to confirm whether the stale content is actually still fresh, and in many cases this is so. The stale content is then updated to be fresh again. Eventually, the cache becomes full, so htcacheclean kicks in and reduces the cache size until it fits inside the given limits, but no more. Apart from the obvious benefit of not having to regenerate content from scratch when it goes stale, having stale content available allows you to do some useful things, like serve stale content to a thundering herd while the stale content is being freshened, or returning stale content when the backend returned an error. None of this is possible if you strip the cache of stale data. Regards, Graham --
Re: svn commit: r1209754 - in /httpd/httpd/trunk/modules/proxy: ./ balancers/
On 03 Dec 2011, at 12:42 AM, minf...@apache.org wrote: Author: minfrin Date: Fri Dec 2 22:42:39 2011 New Revision: 1209754 URL: http://svn.apache.org/viewvc?rev=1209754view=rev Log: mod_proxy: Make ap_proxy_retry_worker() into an optional function. Allows mod_lbmethod_bybusyness, mod_lbmethod_byrequests, mod_lbmethod_bytraffic and mod_lbmethod_heartbeat to be loaded without mod_proxy yet being present, which happens when modules are loaded in alphabetical order. The proxy modules need a bunch more refactoring like this so that the modules can be loaded cleanly in any order. Right now, we've gotten away with this due to the alphabetical naming of the proxy modules, sorted alphabetically mod_proxy comes before mod_proxy_http, and it just so happens mod_proxy_http depends on a lot of symbols provided by mod_proxy, so we work by accident. The above change solves the problem for the mod_lbmethod_* modules, which sort alphabetically before mod_proxy and so cause a problem for people. While I want to backport this change to v2.4, we don't have to backport the rest of the changes if doing so will delay httpd v2.4 for any length of time. Right now I have a bit of time, so am keen to do it. There are also functions in mod_proxy that are only used by a single mod_proxy_* module which ideally should be moved to the module that needs it. The full picture of the functions affected when mod_proxy is not loaded but everything else is looks like below. Seems like there is a lot of stuff that ideally should be moved from mod_proxy to mod_proxy_balancer. Undefined symbols: _ap_proxy_canon_netloc, referenced from: _proxy_ftp_canon in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_balancer_canon in libmod_proxy_balancer.a(mod_proxy_balancer.o) _proxy_http_canon in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_initialize_balancer, referenced from: _balancer_child_init in libmod_proxy_balancer.a(mod_proxy_balancer.o) _ap_proxy_acquire_connection, referenced from: _proxy_ftp_handler in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_http_handler in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_pre_http_request, referenced from: _ap_proxy_http_process_response in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_location_reverse_map, referenced from: _transform_hdrs.13192 in libmod_proxy_http.a(mod_proxy_http.o) _transform_hdrs.13192 in libmod_proxy_http.a(mod_proxy_http.o) _transform_hdrs.13192 in libmod_proxy_http.a(mod_proxy_http.o) _transform_hdrs.13192 in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_string_read, referenced from: _ftp_getrc_msg in libmod_proxy_ftp.a(mod_proxy_ftp.o) _ftp_getrc_msg in libmod_proxy_ftp.a(mod_proxy_ftp.o) _ap_proxy_canonenc, referenced from: _proxy_ftp_canon in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_ftp_canon in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_ftp_canon in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_ftp_canon in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_balancer_canon in libmod_proxy_balancer.a(mod_proxy_balancer.o) _proxy_http_canon in libmod_proxy_http.a(mod_proxy_http.o) _proxy_hook_post_request, referenced from: _ap_proxy_balancer_register_hook in libmod_proxy_balancer.a(mod_proxy_balancer.o) _ap_proxy_initialize_worker, referenced from: _init_balancer_members in libmod_proxy_balancer.a(mod_proxy_balancer.o) _balancer_handler in libmod_proxy_balancer.a(mod_proxy_balancer.o) _ap_proxy_liststr, referenced from: _ap_proxy_http_process_response in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_parse_wstatus, referenced from: _balancer_handler in libmod_proxy_balancer.a(mod_proxy_balancer.o) _ap_proxy_ssl_enable, referenced from: _proxy_http_handler in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_ssl_connection_cleanup, referenced from: _proxy_http_handler in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_get_balancer, referenced from: _proxy_balancer_pre_request in libmod_proxy_balancer.a(mod_proxy_balancer.o) _balancer_handler in libmod_proxy_balancer.a(mod_proxy_balancer.o) _ap_proxy_connect_backend, referenced from: _proxy_ftp_handler in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_http_handler in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_date_canon, referenced from: _process_proxy_header in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_release_connection, referenced from: _proxy_ftp_cleanup in libmod_proxy_ftp.a(mod_proxy_ftp.o) _proxy_ftp_handler in libmod_proxy_ftp.a(mod_proxy_ftp.o) _ap_proxy_http_process_response in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_http_process_response in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_http_cleanup in libmod_proxy_http.a(mod_proxy_http.o) _ap_proxy_ssl_disable, referenced from: _proxy_ftp_handler in
Re: svn commit: r1209754 - in /httpd/httpd/trunk/modules/proxy: ./ balancers/
On Friday 02 December 2011, Graham Leggett wrote: On 03 Dec 2011, at 12:42 AM, minf...@apache.org wrote: Author: minfrin Date: Fri Dec 2 22:42:39 2011 New Revision: 1209754 URL: http://svn.apache.org/viewvc?rev=1209754view=rev Log: mod_proxy: Make ap_proxy_retry_worker() into an optional function. Allows mod_lbmethod_bybusyness, mod_lbmethod_byrequests, mod_lbmethod_bytraffic and mod_lbmethod_heartbeat to be loaded without mod_proxy yet being present, which happens when modules are loaded in alphabetical order. The proxy modules need a bunch more refactoring like this so that the modules can be loaded cleanly in any order. Right now, we've gotten away with this due to the alphabetical naming of the proxy modules, sorted alphabetically mod_proxy comes before mod_proxy_http, and it just so happens mod_proxy_http depends on a lot of symbols provided by mod_proxy, so we work by accident. The above change solves the problem for the mod_lbmethod_* modules, which sort alphabetically before mod_proxy and so cause a problem for people. While I want to backport this change to v2.4, we don't have to backport the rest of the changes if doing so will delay httpd v2.4 for any length of time. Right now I have a bit of time, so am keen to do it. There are also functions in mod_proxy that are only used by a single mod_proxy_* module which ideally should be moved to the module that needs it. There are also a bunch of utility functions that take a function name as argument for logging. I think this should actually be replaced by a module_index argument, which should then be passed to ap_log_*. This way the utility functions would write log messages in the name of the calling module, and be subject of the log config of the calling module. But that's a bit late for 2.4, too.
Re: Error codes
On Thursday 01 December 2011, Stefan Fritsch wrote: Any more comments/thoughts? As nobody disagreed, this is now in trunk. I intend to commit it to 2.4 tomorrow. It's already a big step forward and the finishing touches can be done in 2.4.1.
Are we there yet?
Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? The unique tags for log messages change is waiting for backport to 2.4. But if people would want to let it sit in trunk a bit and wait for 2.4.1, that would be fine with me, too. Anything else? Jim, do you consider your mod_proxy* changes finished? Do you think they are well enough tested for an instant 2.4.0? Graham has suggested some more refactoring for mod_proxy*. Would certainly be nice but not a blocker. Do we need another beta? Or just roll an release candidate tarball, have people test a bit, and if it's good, tag 2.4.0? Cheers, Stefan
Re: Are we there yet?
On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? IMHO this must be fixed before we call it GA. Whether that happens before a 2.4.0 beta doesn't bother me.
Re: Are we there yet?
On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote: On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? IMHO this must be fixed before we call it GA. Whether that happens before a 2.4.0 beta doesn't bother me. [It also is a dev doc. There's nothing here for a user/administrator to understand why this module exists.]
Re: Are we there yet?
On 12/2/2011 6:10 PM, William A. Rowe Jr. wrote: On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote: On 12/2/2011 5:48 PM, Stefan Fritsch wrote: Hi, where are we WRT 2.4? Blockers: mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy) The only blocker left in STATUS is this: * Modules that are not ready for production use must be removed. The same for modules without documentation. I think we have already removed the obvious candidates WRT maturity. About documentation, docs/STATUS has this: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Do we want to remove any of these modules? I suspect a single doc for mod_socache would probably be appropriate. I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html and am rather fluxored that the authors apparently don't know the definition of the word anonymous shared memory. And there is a brand new syntax if users want log-root-relative paths? Why would slotmem throw away 15 years of filename argument conventions? On the subject of logs-relative vs absolute, / should prevail, the colon prefix is unacceptable. On the subject of anonymous, Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems. - http://en.wikipedia.org/wiki/Mmap It's pretty obvious why that shm anonymous implementation is laughable, as well as unacceptable. But in fact, the none implementation appearsto suggest anonymous, already.
Re: Are we there yet?
On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask. - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. Cheers, Gregg
