Re: Process lifetime and hooks to use
why don't you create global variables and put there the configuration data? From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Wed, April 21, 2010 1:44:06 AM Subject: Re: Process lifetime and hooks to use Thanks for your comments. Is a possible solution to the configuration problem to keep a global reference to a pool that I create (w/o a parent)? I can then use that pool to duplicate some of the string data I need from the configuration and store those in my globals as well. I'll need to think of a way to document the code so people know what the heck I'm doing too. People who aren't familiar with apache modules are going to think I'm on crack. SB On Mon, Apr 19, 2010 at 5:00 PM, alin vasile alinachegal...@yahoo.comwrote: comments inline From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Mon, April 19, 2010 3:04:02 PM Subject: Re: Process lifetime and hooks to use I think my understanding of the monitor hook is fine. I can just use the passed in pool as my context and use the userdata_set/get APIs as I periodically fetch / update a file. [alin vasile] the pool is used to allocate the memory from. You'll need global variables to store the pointers. See Nick.s response What I'll need to play with is to see how I can set this up as a configuration parameter. If the post_config hook gets called in the parent process with the apr_pool_t* passed in also being the same one that monitor gets, then that would work. [alin vasile] I'm not sure of that. The child hooks I think are the issue when dealing with the various MPMs, but it might not be a problem anymore since I can just use the pool passed into child_init as the store for my lock and cache. Is the same pool passed in child_init accessible in the request handler via request-server-process-pool ? I see a lot of modules using these static variables and globals all over - is this safe? Aren't the modules existing in multiple process spaces? How does the author know which static variables are going to be safe to access in each hook? I guess any statics assigned in the child_init are safe to use in the request handlers and other threads spawned in the child_init. And for the parent process it's probably best to just use the pool? [alin vasile] You can't init static variables in child_init. don't declare them static and, if needed, protect their read/write with locks Thanks, SB On Mon, Apr 19, 2010 at 1:41 AM, alin vasile alinachegal...@yahoo.com wrote: It depends what you want to do in this hook. --- On Sun, 4/18/10, Some Guy teknos...@gmail.com wrote: From: Some Guy teknos...@gmail.com Subject: Re: Process lifetime and hooks to use To: modules-dev@httpd.apache.org Date: Sunday, April 18, 2010, 5:51 PM Ah great. I know what I should do with that. Any insight on the differences in MPMs and what to watch out for? On Sun, Apr 18, 2010 at 12:22 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 4/18/2010 2:34 AM, alin vasile wrote: the monitor hook gets only a pointer to an apr_pool_t structure. Take a look at apr_pool_data_* API's, that should provide you all of the context and persistence you need. You will never see anything about servers, connections or requests because this is running in the *parent*, it is blissfully unaware of specific requests and is therefore immune from being hijaaked by remote code execution and less severe but destabilizing attacks on the request processing code itself.
Re: Process lifetime and hooks to use
I need to get it from the configuration file. If the post config hook runs prior to the ap monitor hook, then that would work. But what memory is all of that data allocated from? I don't want them disappearing on me. On Wed, Apr 21, 2010 at 4:22 AM, alin vasile alinachegal...@yahoo.comwrote: why don't you create global variables and put there the configuration data? From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Wed, April 21, 2010 1:44:06 AM Subject: Re: Process lifetime and hooks to use Thanks for your comments. Is a possible solution to the configuration problem to keep a global reference to a pool that I create (w/o a parent)? I can then use that pool to duplicate some of the string data I need from the configuration and store those in my globals as well. I'll need to think of a way to document the code so people know what the heck I'm doing too. People who aren't familiar with apache modules are going to think I'm on crack. SB On Mon, Apr 19, 2010 at 5:00 PM, alin vasile alinachegal...@yahoo.com wrote: comments inline From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Mon, April 19, 2010 3:04:02 PM Subject: Re: Process lifetime and hooks to use I think my understanding of the monitor hook is fine. I can just use the passed in pool as my context and use the userdata_set/get APIs as I periodically fetch / update a file. [alin vasile] the pool is used to allocate the memory from. You'll need global variables to store the pointers. See Nick.s response What I'll need to play with is to see how I can set this up as a configuration parameter. If the post_config hook gets called in the parent process with the apr_pool_t* passed in also being the same one that monitor gets, then that would work. [alin vasile] I'm not sure of that. The child hooks I think are the issue when dealing with the various MPMs, but it might not be a problem anymore since I can just use the pool passed into child_init as the store for my lock and cache. Is the same pool passed in child_init accessible in the request handler via request-server-process-pool ? I see a lot of modules using these static variables and globals all over - is this safe? Aren't the modules existing in multiple process spaces? How does the author know which static variables are going to be safe to access in each hook? I guess any statics assigned in the child_init are safe to use in the request handlers and other threads spawned in the child_init. And for the parent process it's probably best to just use the pool? [alin vasile] You can't init static variables in child_init. don't declare them static and, if needed, protect their read/write with locks Thanks, SB On Mon, Apr 19, 2010 at 1:41 AM, alin vasile alinachegal...@yahoo.com wrote: It depends what you want to do in this hook. --- On Sun, 4/18/10, Some Guy teknos...@gmail.com wrote: From: Some Guy teknos...@gmail.com Subject: Re: Process lifetime and hooks to use To: modules-dev@httpd.apache.org Date: Sunday, April 18, 2010, 5:51 PM Ah great. I know what I should do with that. Any insight on the differences in MPMs and what to watch out for? On Sun, Apr 18, 2010 at 12:22 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 4/18/2010 2:34 AM, alin vasile wrote: the monitor hook gets only a pointer to an apr_pool_t structure. Take a look at apr_pool_data_* API's, that should provide you all of the context and persistence you need. You will never see anything about servers, connections or requests because this is running in the *parent*, it is blissfully unaware of specific requests and is therefore immune from being hijaaked by remote code execution and less severe but destabilizing attacks on the request processing code itself.
Re: Process lifetime and hooks to use
Alin, Thank you for your time, patience, and help. I guess I'm still a little confused on the mechanism used to move the data from the configuration to a place that the monitor hook could use. I can only access the config in the parent process via the post_config hook (or am I wrong?). If that's the case, then I need to store the variables in some static global field. However, the data that the post config hook gives me might come from a pool that gets cleaned, so I need a way to make sure the global fields aren't dangling. That's why I was considering making my own independent pool and duplicating the variables so I can store it into global variables without worrying about their lifetime. Their life would be based on the independent global pool that I create in the post config hook / monitor hook (whichever comes first). SB On Wed, Apr 21, 2010 at 9:25 AM, alin vasile alinachegal...@yahoo.comwrote: you can use the memory pool passed to the monitor, but that pool never gets cleaned, so you'll have to make sure that there are no memory leaks. the docs don't say anything if the monitor hook runs after post_config... From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Wed, April 21, 2010 3:37:47 PM Subject: Re: Process lifetime and hooks to use I need to get it from the configuration file. If the post config hook runs prior to the ap monitor hook, then that would work. But what memory is all of that data allocated from? I don't want them disappearing on me. On Wed, Apr 21, 2010 at 4:22 AM, alin vasile alinachegal...@yahoo.com wrote: why don't you create global variables and put there the configuration data? From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Wed, April 21, 2010 1:44:06 AM Subject: Re: Process lifetime and hooks to use Thanks for your comments. Is a possible solution to the configuration problem to keep a global reference to a pool that I create (w/o a parent)? I can then use that pool to duplicate some of the string data I need from the configuration and store those in my globals as well. I'll need to think of a way to document the code so people know what the heck I'm doing too. People who aren't familiar with apache modules are going to think I'm on crack. SB On Mon, Apr 19, 2010 at 5:00 PM, alin vasile alinachegal...@yahoo.com wrote: comments inline From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Mon, April 19, 2010 3:04:02 PM Subject: Re: Process lifetime and hooks to use I think my understanding of the monitor hook is fine. I can just use the passed in pool as my context and use the userdata_set/get APIs as I periodically fetch / update a file. [alin vasile] the pool is used to allocate the memory from. You'll need global variables to store the pointers. See Nick.s response What I'll need to play with is to see how I can set this up as a configuration parameter. If the post_config hook gets called in the parent process with the apr_pool_t* passed in also being the same one that monitor gets, then that would work. [alin vasile] I'm not sure of that. The child hooks I think are the issue when dealing with the various MPMs, but it might not be a problem anymore since I can just use the pool passed into child_init as the store for my lock and cache. Is the same pool passed in child_init accessible in the request handler via request-server-process-pool ? I see a lot of modules using these static variables and globals all over - is this safe? Aren't the modules existing in multiple process spaces? How does the author know which static variables are going to be safe to access in each hook? I guess any statics assigned in the child_init are safe to use in the request handlers and other threads spawned in the child_init. And for the parent process it's probably best to just use the pool? [alin vasile] You can't init static variables in child_init. don't declare them static and, if needed, protect their read/write with locks Thanks, SB On Mon, Apr 19, 2010 at 1:41 AM, alin vasile alinachegal...@yahoo.com wrote: It depends what you want to do in this hook. --- On Sun, 4/18/10, Some Guy teknos...@gmail.com wrote: From: Some Guy teknos...@gmail.com Subject: Re: Process lifetime and hooks to use To: modules-dev@httpd.apache.org Date: Sunday, April 18, 2010, 5:51 PM Ah great. I know what I should do with that. Any insight on the differences in MPMs and what to watch out for? On Sun, Apr 18, 2010 at 12:22 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 4/18/2010 2:34 AM, alin vasile wrote: the monitor
Re: Process lifetime and hooks to use
Also this is how I configured the structure in the post_config handler:
sample_config.sample_time = 60;
sample_config.sample_log_file_name =
/home/alin/webserver_node1/logs/sampler.log;
apr_file_open(sample_config.sample_log_file_handler,
sample_config.sample_log_file_name, REWRITELOG_FLAGS,
REWRITELOG_MODE, p);
From: alin vasile alinachegal...@yahoo.com
To: modules-dev@httpd.apache.org
Sent: Wed, April 21, 2010 5:22:32 PM
Subject: Re: Process lifetime and hooks to use
you can access the config in the child process too, but not in the monitor hook.
Below is a sample of global variables with the monitor hook:
typedef struct data_config_t {
const char *sample_log_file_name;
apr_file_t *sample_log_file_handler;
int sample_time;
} data_config_t;
static data_config_t sample_config;
static int process_sampler (apr_pool_t* p)
{
// do some work
// note that you have access to the sample_config variable
return OK;
}
//in the register_hooks handler put :
ap_hook_monitor(process_sampler, NULL, NULL, APR_HOOK_LAST);
From: Some Guy teknos...@gmail.com
To: modules-dev@httpd.apache.org
Sent: Wed, April 21, 2010 5:02:11 PM
Subject: Re: Process lifetime and hooks to use
Alin,
Thank you for your time, patience, and help. I guess I'm still a little
confused on the mechanism used to move the data from the configuration to a
place that the monitor hook could use. I can only access the config in the
parent process via the post_config hook (or am I wrong?).
If that's the case, then I need to store the variables in some static global
field. However, the data that the post config hook gives me might come from
a pool that gets cleaned, so I need a way to make sure the global fields
aren't dangling. That's why I was considering making my own independent
pool and duplicating the variables so I can store it into global variables
without worrying about their lifetime. Their life would be based on the
independent global pool that I create in the post config hook / monitor
hook (whichever comes first).
SB
On Wed, Apr 21, 2010 at 9:25 AM, alin vasile alinachegal...@yahoo.comwrote:
you can use the memory pool passed to the monitor, but that pool never gets
cleaned, so you'll have to make sure that there are no memory leaks.
the docs don't say anything if the monitor hook runs after post_config...
From: Some Guy teknos...@gmail.com
To: modules-dev@httpd.apache.org
Sent: Wed, April 21, 2010 3:37:47 PM
Subject: Re: Process lifetime and hooks to use
I need to get it from the configuration file. If the post config hook runs
prior to the ap monitor hook, then that would work. But what memory is all
of that data allocated from? I don't want them disappearing on me.
On Wed, Apr 21, 2010 at 4:22 AM, alin vasile alinachegal...@yahoo.com
wrote:
why don't you create global variables and put there the configuration
data?
From: Some Guy teknos...@gmail.com
To: modules-dev@httpd.apache.org
Sent: Wed, April 21, 2010 1:44:06 AM
Subject: Re: Process lifetime and hooks to use
Thanks for your comments. Is a possible solution to the configuration
problem to keep a global reference to a pool that I create (w/o a
parent)?
I can then use that pool to duplicate some of the string data I need from
the configuration and store those in my globals as well.
I'll need to think of a way to document the code so people know what the
heck I'm doing too. People who aren't familiar with apache modules are
going to think I'm on crack.
SB
On Mon, Apr 19, 2010 at 5:00 PM, alin vasile alinachegal...@yahoo.com
wrote:
comments inline
From: Some Guy teknos...@gmail.com
To: modules-dev@httpd.apache.org
Sent: Mon, April 19, 2010 3:04:02 PM
Subject: Re: Process lifetime and hooks to use
I think my understanding of the monitor hook is fine. I can just use
the
passed in pool as my context and use the userdata_set/get APIs as I
periodically fetch / update a file.
[alin vasile] the pool is used to allocate the memory from. You'll
need
global variables to store the pointers. See Nick.s response
What I'll need to play with is to see
how I can set this up as a configuration parameter. If the post_config
hook
gets called in the parent process with the apr_pool_t* passed in also
being
the same one that monitor gets, then that would work.
[alin vasile] I'm not sure of that.
The child hooks I think are the issue when dealing with the various
MPMs,
but it might not be a problem anymore since I can just use the pool
passed
into child_init as the store for my lock and cache. Is the same pool
passed
in child_init accessible in the request handler via
Re: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [AuthType Certificate]
On Wed, Apr 21, 2010 at 12:49 PM, Thomas, Peter ptho...@hpti.com wrote: When the user's certificate subject is also the DN of the LDAP object, one can optimize search and compare operations by doing a LDAP_SCOPE_BASE search for the object based on the subject DN. I was able to substitute a search for the exact LDAP object in the authentication code. For authorization, I ran into a problem. The LDAP search cache entries for a URL are unique by filter expression. If ANY user was cached for a specific ldap-filter, the search cache has no way of knowing that I'm applying that search to a different search base. I could create a separate cache for every user encountered [i.e. by changing the base component of the LDAP URL before calling any uldap_cache_* function]. That seems painful. Thoughts? How important is this optimization to either Apache or the LDAP server? -- Eric Covener cove...@gmail.com
Re: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [AuthType Certificate]
On Wed, Apr 21, 2010 at 12:49 PM, Thomas, Peter ptho...@hpti.com wrote: When the user's certificate subject is also the DN of the LDAP object, one can optimize search and compare operations by doing a LDAP_SCOPE_BASE search for the object based on the subject DN. I was able to substitute a search for the exact LDAP object in the authentication code. I thought your goal was for the certificate itself to be the source of authn? Does the roundtrip to LDAP during authn add much? For authorization, I ran into a problem. The LDAP search cache entries for a URL are unique by filter expression. user was cached for a specific ldap-filter, the search cache has no way of knowing that I'm applying that search to a different search base. I could create a separate cache for every user encountered [i.e. by changing the base component of the LDAP URL before calling any uldap_cache_* function]. That seems painful. Thoughts? I guess this applies to ldap-user and ldap-filter but not the other ldap-* -- attributes already use the user DN as the base and groups use the group as a base -- although if your schema uses the CN as the group member value you'd have to extract it from the DN. It does seem like either the cache structure, or the ldap-user/ldap-filter logic would need an overhaul. 1-cache-per-user is probably the wrong direction though. -- Eric Covener cove...@gmail.com
Issuing a client side HTTP request from a module
Hi all, Is there any facility in the Apache libs that allows module developers to act as a client? If not, I'll just use something like curl (or raw sockets), but wanted to know if there was an Apache way to do this. Thanks, SB
Re: Issuing a client side HTTP request from a module
do you want to make an http request from a module? From: Some Guy teknos...@gmail.com To: modules-dev@httpd.apache.org Sent: Wed, April 21, 2010 10:42:50 PM Subject: Issuing a client side HTTP request from a module Hi all, Is there any facility in the Apache libs that allows module developers to act as a client? If not, I'll just use something like curl (or raw sockets), but wanted to know if there was an Apache way to do this. Thanks, SB
*** glibc detected *** double free or corruption (!prev) in cleanup function
Hi,
I have a question about apr_pool_cleanup_register for a child's pool.
I register a cleanup function that is called when the pool is
destroyed. In the cleanup function, I join a background thread that
first writes some log to a database:
static void mbrace_child_init(apr_pool_t *pool, server_rec *s)
{
apr_pool_cleanup_register(pool, 0, mbrace_bgthread_cleanup,
apr_pool_cleanup_null);
}
static apr_status_t mbrace_bgthread_cleanup(void*)
{
req_log_mngr-stop()
}
But, when it connects to the database in the background thread, it
sometimes ends up in the error below. I do not fully understand why,
but are there any restrictions to what I can do in the cleanup
function?
When running gdb on the generated core-dump, you can see that it
happens on line 134.
125 APR_DECLARE(void) apr_allocator_destroy(apr_allocator_t *allocator)
126 {
127 apr_uint32_t index;
128 apr_memnode_t *node, **ref;
129
130 for (index = 0; index MAX_INDEX; index++) {
131 ref = allocator-free[index];
132 while ((node = *ref) != NULL) {
133 *ref = node-next;
134 free(node); here it happens!!
135 }
136 }
137
138 free(allocator);
139 }
Hopefully somebody can push me in the right direction.
Thank you,
Andrej
*** glibc detected *** /usr/local/httpd-2.2.15/bin/httpd: double free
or corruption (!prev): 0x09461298 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6[0xb7d5d454]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7d5f4b6]
/usr/local/httpd-2.2.15/lib/libapr-1.so.0(apr_allocator_destroy+0x2e)[0xb7f3d2ce]
/usr/local/httpd-2.2.15/lib/libapr-1.so.0(apr_pool_destroy+0x235)[0xb7f3dfa5]
/usr/local/httpd-2.2.15/bin/httpd[0x80aa4c4]
/usr/local/httpd-2.2.15/bin/httpd[0x80aa986]
/usr/local/httpd-2.2.15/bin/httpd[0x80aabe3]
/usr/local/httpd-2.2.15/bin/httpd(ap_mpm_run+0x5fa)[0x80ab26a]
/usr/local/httpd-2.2.15/bin/httpd(main+0xac8)[0x80696d8]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d04685]
/usr/local/httpd-2.2.15/bin/httpd[0x8068601]
=== Memory map:
08048000-080c7000 r-xp fe:00 1171716
/usr/local/httpd-2.2.15/bin/httpd
080c7000-080c8000 r--p 0007e000 fe:00 1171716
/usr/local/httpd-2.2.15/bin/httpd
080c8000-080cb000 rw-p 0007f000 fe:00 1171716
/usr/local/httpd-2.2.15/bin/httpd
080cb000-080ce000 rw-p 080cb000 00:00 0
09254000-09479000 rw-p 09254000 00:00 0 [heap]
b6465000-b6466000 ---p b6465000 00:00 0
Oxygen icons for Apache
Hello, Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ The package apache2-icons-oxygen is already part of the openSUSE Apache subproject rpm and src.rpm packages for CentOS, Fedora, RHEL, SLE and openSUSE can be found at http://download.opensuse.org/repositories/Apache/ The source files are located on the Build Service: https://build.opensuse.org/package/show?package=apache2-icons- oxygenproject=Apache Comments and suggestions are welcome! Greetings, -- Javier Llorente signature.asc Description: This is a digitally signed message part.
Re: Oxygen icons for Apache
On Wed, Apr 21, 2010 at 4:44 PM, Javier Llorente jav...@opensuse.org wrote: Hello, Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ The package apache2-icons-oxygen is already part of the openSUSE Apache subproject rpm and src.rpm packages for CentOS, Fedora, RHEL, SLE and openSUSE can be found at http://download.opensuse.org/repositories/Apache/ The source files are located on the Build Service: https://build.opensuse.org/package/show?package=apache2-icons- oxygenproject=Apache Comments and suggestions are welcome! Greetings, -- Javier Llorente Oooh, pretty - what license are you releasing them under? Cheers Tom
Re: Oxygen icons for Apache
On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? -- Rich Bowen rbo...@rcbowen.com
Re: Oxygen icons for Apache
Hi! I would definetly like to see them in the official release. Yours, Aron Szabo pointless.hu On 04/21/2010 05:44 PM, Javier Llorente wrote: Hello, Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ The package apache2-icons-oxygen is already part of the openSUSE Apache subproject rpm and src.rpm packages for CentOS, Fedora, RHEL, SLE and openSUSE can be found at http://download.opensuse.org/repositories/Apache/ The source files are located on the Build Service: https://build.opensuse.org/package/show?package=apache2-icons- oxygenproject=Apache Comments and suggestions are welcome! Greetings,
Re: Oxygen icons for Apache
On Wednesday 21 April 2010 17:50:41 Rich Bowen wrote: On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Greetings, -- Javier Llorente signature.asc Description: This is a digitally signed message part.
Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [AuthType Certificate]
When the user's certificate subject is also the DN of the LDAP object, one can optimize search and compare operations by doing a LDAP_SCOPE_BASE search for the object based on the subject DN. I was able to substitute a search for the exact LDAP object in the authentication code. For authorization, I ran into a problem. The LDAP search cache entries for a URL are unique by filter expression. If ANY user was cached for a specific ldap-filter, the search cache has no way of knowing that I'm applying that search to a different search base. I could create a separate cache for every user encountered [i.e. by changing the base component of the LDAP URL before calling any uldap_cache_* function]. That seems painful. Thoughts?
Re: Oxygen icons for Apache
On 4/21/2010 11:37 AM, Javier Llorente wrote: On Wednesday 21 April 2010 17:50:41 Rich Bowen wrote: On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) Bill
RE: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [AuthType Certificate]
It's mandatory IFF: 1) The certificate subject is the LDAP DN, AND 2) There isn't an LDAP object attribute that can be uniquely mapped to a specific certificate subject DN component When it isn't mandatory--but the certificate subject is the LDAP object's DN--then an LDAP_SCOPE_BASE search improves performance for LDAP servers--and thus for relying Apache servers. I can't speak to importance--it's important to me, or I would have dropped it by now instead of pressing forward. I keep running in to people who have solved this or similar problems at the application (or application server layer) [in PHP, RAILS, J2EE, Joomla, c.] It's always seemed like this cries out for handling right where we do SSL termination initial AAA--in httpd. This is never going to be something that the whole world wants; this capability applies only to situations where X.509 certificates are distributed to users AND LDAP is used to make AA decisions based upon users' certificates presented to web servers. --Pete -- -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, April 21, 2010 1:39 PM To: modules-...@httpd.apache.org Subject: Re: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [AuthType Certificate] On Wed, Apr 21, 2010 at 12:49 PM, Thomas, Peter ptho...@hpti.com wrote: When the user's certificate subject is also the DN of the LDAP object, one can optimize search and compare operations by doing a LDAP_SCOPE_BASE search for the object based on the subject DN. I was able to substitute a search for the exact LDAP object in the authentication code. For authorization, I ran into a problem. The LDAP search cache entries for a URL are unique by filter expression. If ANY user was cached for a specific ldap-filter, the search cache has no way of knowing that I'm applying that search to a different search base. I could create a separate cache for every user encountered [i.e. by changing the base component of the LDAP URL before calling any uldap_cache_* function]. That seems painful. Thoughts? How important is this optimization to either Apache or the LDAP server? -- Eric Covener cove...@gmail.com
Re: Oxygen icons for Apache
On Wednesday 21 April 2010 20:12:00 William A. Rowe Jr. wrote: On 4/21/2010 11:37 AM, Javier Llorente wrote: On Wednesday 21 April 2010 17:50:41 Rich Bowen wrote: On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) I have used some LGPL'ed icons. However, from my understanding of the LGPL, I could change the license of my collection to make it compatible; Quoting from http://www.gnu.org/copyleft/lesser.html 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. * b) Accompany the Combined Work with a copy of the GNU GPL and this license document. [...] Greetings, -- Javier Llorente signature.asc Description: This is a digitally signed message part.
Re: Oxygen icons for Apache
On Apr 21, 2010, at 3:13 PM, Javier Llorente wrote: Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) I have used some LGPL'ed icons. However, from my understanding of the LGPL, I could change the license of my collection to make it compatible; If it's your work, you're welcome to relicense it under whatever license you like, including ASL2. -- Rich Bowen rbo...@rcbowen.com
Re: Oxygen icons for Apache
On 4/21/2010 2:13 PM, Javier Llorente wrote: On Wednesday 21 April 2010 20:12:00 William A. Rowe Jr. wrote: On 4/21/2010 11:37 AM, Javier Llorente wrote: On Wednesday 21 April 2010 17:50:41 Rich Bowen wrote: On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) I have used some LGPL'ed icons. However, from my understanding of the LGPL, I could change the license of my collection to make it compatible; Quoting from http://www.gnu.org/copyleft/lesser.html 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. * b) Accompany the Combined Work with a copy of the GNU GPL and this license document. [...] First; works won't be accepted with a[ny] GPL license [AGPL, LGPL, GPL etc]. The existence of two license files in the source repository would be confusing and misleading to the user, where the ASF has chosen to distribute the code strictly under one (non-copyleft) election among multiple licenses offered. Second; the ASF will not combine source code works. The combination you quote above that can and do inevitably happen with the use of ASF works when used in combination with copyleft works is left to the user's discretion and for the user to decipher and comply with (in terms of their net responsibilities under the combined licenses). This paragraph deals with, for example, SuSE's choice to combine Apache httpd with your icon collection. Now, the ASF is happy to consider contributions under the Apache License, or any license which does not add additional restrictions (e.g. copyleft clauses) or subtract any rights (e.g. non-commercial use only clauses) when added into the Apache License of the combined work. For example, the BSD license, sans advertising requirement, satisfies this consideration. The choice of license here is interesting; because your work should necessarily always be conveyed in source code (e.g. an image representation) that is transmitted to all end users (e.g. as broadly as the AGPL would require) there is really no difference between licensing these icons in BSD, AL, or LGPL. Licensing in GPL or AGPL would of course add further requirements with respect to the source code of the entire work. The only right you lose in offering a more flexible BSD or AL, rather than LGPL, is the redistribution with reuse license requirement of any modified icons if someone based a set of icons on your original art. So if these are your own originala works, and you have not conveyed all copyright to another party (e.g. the FSF) - but retain the right to convey licenses yourself, and you would like to offer these under an Apache License to the ASF, we would be glad to continue the discussion of accepting such an offer.
Re: Issuing a client side HTTP request from a module
On 21 Apr 2010, at 20:42, Some Guy wrote: Hi all, Is there any facility in the Apache libs that allows module developers to act as a client? The usual way would be to harness mod_proxy, commonly in a subrequest. You don't have to do anything special, just request something configured to proxy. -- Nick Kew
Re: Oxygen icons for Apache
On Wednesday 21 April 2010 22:38:06 you wrote: On 4/21/2010 2:13 PM, Javier Llorente wrote: On Wednesday 21 April 2010 20:12:00 William A. Rowe Jr. wrote: On 4/21/2010 11:37 AM, Javier Llorente wrote: On Wednesday 21 April 2010 17:50:41 Rich Bowen wrote: On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) I have used some LGPL'ed icons. However, from my understanding of the LGPL, I could change the license of my collection to make it compatible; Quoting from http://www.gnu.org/copyleft/lesser.html 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. * b) Accompany the Combined Work with a copy of the GNU GPL and this license document. [...] First; works won't be accepted with a[ny] GPL license [AGPL, LGPL, GPL etc]. The existence of two license files in the source repository would be confusing and misleading to the user, where the ASF has chosen to distribute the code strictly under one (non-copyleft) election among multiple licenses offered. Second; the ASF will not combine source code works. The combination you quote above that can and do inevitably happen with the use of ASF works when used in combination with copyleft works is left to the user's discretion and for the user to decipher and comply with (in terms of their net responsibilities under the combined licenses). This paragraph deals with, for example, SuSE's choice to combine Apache httpd with your icon collection. Now, the ASF is happy to consider contributions under the Apache License, or any license which does not add additional restrictions (e.g. copyleft clauses) or subtract any rights (e.g. non-commercial use only clauses) when added into the Apache License of the combined work. For example, the BSD license, sans advertising requirement, satisfies this consideration. The choice of license here is interesting; because your work should necessarily always be conveyed in source code (e.g. an image representation) that is transmitted to all end users (e.g. as broadly as the AGPL would require) there is really no difference between licensing these icons in BSD, AL, or LGPL. Licensing in GPL or AGPL would of course add further requirements with respect to the source code of the entire work. The only right you lose in offering a more flexible BSD or AL, rather than LGPL, is the redistribution with reuse license requirement of any modified icons if someone based a set of icons on your original art. So if these are your own originala works, and you have not conveyed all copyright to another party (e.g. the FSF) - but retain the right to convey licenses yourself, and you would like to offer these under an Apache License to the ASF, we would be glad to continue the discussion of accepting such an offer. Here's a more detailed explanation of my situation: I have hand picked some Oxygen icons, adapted (modified) some Oxygen and Crystal icons, and created the configuration README. The Oxygen icons are under both LGPL and CC-by-SA Quoting http://creativecommons.org/licenses/by-sa/3.0/ [...] Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. It seems to me that the cc-by-sa is ok in this case. I could re-license my collection to have it under the Apache license. The Crystal icons are under the LGPL (only, no dual licensing from what I've read). So I understand that here lies the problem. I could look for a solution like replacing them (they're just a few). Another possibility could be having distributions (if they choose to do so) shipping Apache with this collection of icons enabled by default. But I prefer contributing my grain of salt upstream so that anyone can use it, regardless of the distribution. BTW, thanks a lot for you explanation on
