Re: mod_authn_mysql
Personally, I'd support creating an httpd-auth subproject or something like that which could house a bunch of (more, less?) obscure authn/authz modules. I like that idea! It seems like we should be able to give mod_authn_mysql a proper home somewhere under our purview. -- justin
Re: mod_authn_mysql
--On Wednesday, February 19, 2003 5:35 PM -0800 Aaron Bannert [EMAIL PROTECTED] wrote: Yeah, I'd rather see fewer core modules rather than more. -0 for inclusion. Personally, I'd support creating an httpd-auth subproject or something like that which could house a bunch of (more, less?) obscure authn/authz modules. It seems like we should be able to give mod_authn_mysql a proper home somewhere under our purview. -- justin
Fw: Re: libmysqlclient Re: mod_authn_mysql
-- Forwarded Message --- From: David Axmark [EMAIL PROTECTED] To: Paul Querna [EMAIL PROTECTED] Sent: 20 Feb 2003 01:01:03 +0100 Subject: Re: libmysqlclient Re: mod_authn_mysql Sorry about the late answer. Got a cold and a bad email back log :-( We are willing to state in our license that we allow distributing with the apache license (or basically any OSI compatible license). I just need to find the right wording. We are going to do the same for the IBM Eclipse project that also have a GPL incompatible license. But we are trying to come up with a wording there to. /David --- End of Forwarded Message --- I think this will basicly resolve the licensing question of including mod_authn_mysql. -chip
Re: mod_authn_mysql
--On Wednesday, February 19, 2003 6:39 PM +0100 Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: +1 for including 0.0.6 from http://open.cyanworlds.com/ into the tree ? I prefer to see a definitive statement regarding the licensing first (which I don't believe we have yet received). We also need a way to ensure at configure-time that the MySQL libraries were compiled to be thread-safe. IIRC, it's an explicit configure-time option when you build MySQL. I don't think most distributions include that option by default. -- justin
Re: mod_authn_mysql
On Wed, 19 Feb 2003 09:47:27 -0800, Justin Erenkrantz wrote --On Wednesday, February 19, 2003 6:39 PM +0100 Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: +1 for including 0.0.6 from http://open.cyanworlds.com/ into the tree ? I will be putting 0.0.7 out later today that has Gunter's win32 netware patch and a few small tweaks. I prefer to see a definitive statement regarding the licensing first (which I don't believe we have yet received). I have e-mailed [EMAIL PROTECTED] regarding this, and have not received any reply. We also need a way to ensure at configure-time that the MySQL libraries were compiled to be thread-safe. IIRC, it's an explicit configure-time option when you build MySQL. I don't think most distributions include that option by default. -- justin The default lib mysqlclient is *only* not thread safe in the mysql_connect (hence the mutex locking around those areas), but everything else is thread safe. The specialy compiled thread safe library is thread safe in all functions. -chip
Re: mod_authn_mysql
On Wed, 19 Feb 2003, Paul Querna wrote: The default lib mysqlclient is *only* not thread safe in the mysql_connect (hence the mutex locking around those areas), but everything else is thread safe. The specialy compiled thread safe library is thread safe in all functions. In the specially compiled thread safe library version; is there an #define we can detect to 'know' that ? Dw.
Re: mod_authn_mysql
--On Wednesday, February 19, 2003 10:31 AM -0800 Paul Querna [EMAIL PROTECTED] wrote: The default lib mysqlclient is *only* not thread safe in the mysql_connect (hence the mutex locking around those areas), but everything else is thread safe. The specialy compiled thread safe library is thread safe in all functions. Is there a way to detect this at compile-time such that we don't need to obtain the mutex when we have the good version? -- justin
RE: mod_authn_mysql
For 2.1 and beyond, I'd rather see something more generic. Like a mod_authn_odbc or a mod_authn_soap. Otherwise expect to have to maintain special versions for all of the database flavors... -Original Message- From: Dirk-Willem van Gulik [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 11:39 AM To: [EMAIL PROTECTED] Subject: mod_authn_mysql Any one any objections to me adding that into the 2.0 tree as soon as we have a few +1's. I can kind of use it in the regressing builds I am doing. And it would be a nice place for some folks (hi Sterling!) to think of how you would allow any SQL backend to plug in. +1 for including 0.0.6 from http://open.cyanworlds.com/ into the tree ? Dw
Re: mod_authn_mysql
On Wed, 19 Feb 2003 10:40:12 -0800, Justin Erenkrantz wrote --On Wednesday, February 19, 2003 10:31 AM -0800 Paul Querna [EMAIL PROTECTED] wrote: The default lib mysqlclient is *only* not thread safe in the mysql_connect (hence the mutex locking around those areas), but everything else is thread safe. The specialy compiled thread safe library is thread safe in all functions. Is there a way to detect this at compile-time such that we don't need to obtain the mutex when we have the good version? -- justin Acording to the MySQL documentation... http://www.mysql.com/doc/en/Threaded_clients.html The thread safe lib is called mysqlclient_r Therefore, we should be able to detect it at build time which one we are being linked to -chip
RE: mod_authn_mysql
-- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Wed, 19 Feb 2003 18:39:05 +0100 (CET) From: Dirk-Willem van Gulik [EMAIL PROTECTED] Subject: mod_authn_mysql Any one any objections to me adding that into the 2.0 tree as soon as we have a few +1's. I can kind of use it in the regressing builds I am doing. And it would be a nice place for some folks (hi Sterling!) to think of how you would allow any SQL backend to plug in. Yeah - I'm still not sure what the cleanest way to genericize this stuff. Perhaps a module that just registers a bunch of optional functions and directives to support variuos sql authentication needs... lots of ways to solve this - Maybe i'll mock up some ideas. sterling
RE: mod_authn_mysql
On Wed, 19 Feb 2003, Dietz, Phil E. wrote: For 2.1 and beyond, I'd rather see something more generic. Like a mod_authn_odbc or a mod_authn_soap. Ironic, since I was just about to say I'm not so keen on adding more modules to 2.0, and that if it's going in I'd rather have it in 2.1. --Cliff
RE: mod_authn_mysql
At 01:32 PM 2/19/2003, Cliff Woolley wrote: On Wed, 19 Feb 2003, Dietz, Phil E. wrote: For 2.1 and beyond, I'd rather see something more generic. Like a mod_authn_odbc or a mod_authn_soap. Ironic, since I was just about to say I'm not so keen on adding more modules to 2.0, and that if it's going in I'd rather have it in 2.1. I was sorta thinking the same... we seem to be saying that bits of this aren't altogether that flexible, we want different backends, et al, and yet rather than invest the time in structuring 2.1 so that all the auth overhaul is really successful and complete, we want to start maintaining another auth under the old schema? Seems like that would waste more project cycles than really benefiting the direction that auth is taking. I'm sorta -0 on seeing this go into 2.0. I won't scream and yell and flail my arms, and will go where the list takes this, but I wouldn't support introducing it until 2.1. Dropping it in 2.0 would actually be a disincentive (at least for me) to really contributing to the shape up of our own authn/authz logic by the first 2.2 release. BTW - yes I realize the reorganization and new hooks are already done for 2.1. What isn't finished is some mechanism for query and linked lists of credentials; what Dirk has advocated for some time. This module is a perfect back end to illustrate that. So is _hostname, actually, because it's more than just an IP. It's a machine identity, with the root value of an absolute IP address, with sometimes a reverse-dns-validated hostname, and an agent token of the dns server that validated that hostname-IP relation. What Dirk proposes is to layer all of those nuggets to later unwind the chain of authority, or log it. My goal is to simply check the list of machine-token identifiers and compare 'em all to the Allow or Deny patterns, so that one flavor or another doesn't escape from our scrutiny. But they all benefit from rethinking this logic already. The current 2.0 is goodness, the module is available from and maintained by others, and we are happy to adopt it into our new 'authn/authz' family. But that family won't be born till 2.2. My longwinded 2c, but that's all it's worth. Bill
RE: mod_authn_mysql
On Wed, 19 Feb 2003, William A. Rowe, Jr. wrote: support introducing it until 2.1. Dropping it in 2.0 would actually be a disincentive (at least for me) to really contributing to the shape up Very good point. I'll hold my fire for a while. My longwinded 2c, but that's all it's worth. But it was a -worthy- 2cents; and one which I think is better from a long term strategy/direction point of view. Dw
Re: mod_authn_mysql
On Wednesday, February 19, 2003, at 11:32 AM, Cliff Woolley wrote: On Wed, 19 Feb 2003, Dietz, Phil E. wrote: For 2.1 and beyond, I'd rather see something more generic. Like a mod_authn_odbc or a mod_authn_soap. Ironic, since I was just about to say I'm not so keen on adding more modules to 2.0, and that if it's going in I'd rather have it in 2.1. Yeah, I'd rather see fewer core modules rather than more. -0 for inclusion. -aaron
Re: mod_authn_mysql
Since there seems to be some interest in including a mysql auth module into the tree, here's a postgres module which I've coded and have been using for the past month or so. As for a connection pool... I haven't figured out a way to have postres use a connection opened by another process... it likes spiking the cpu and sitting in some pqbytes function or some shit like that when doing a query on it. https://dpejesh.dnsalias.net/repos/mod_auth_pgsql/trunk/ Shane
RE: mod_authn_mysql
Wouldnt it be nice, if Apache came with a database connection pool service. This standalone process would manage database queries for Apache modules and as well as CGI apps. Much like every Java App server comes with now-a-days http://www.phworks-online.com/cache.html -Original Message- From: David Shane Holden [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 3:52 PM To: [EMAIL PROTECTED] Subject: Re: mod_authn_mysql Since there seems to be some interest in including a mysql auth module into the tree, here's a postgres module which I've coded and have been using for the past month or so. As for a connection pool... I haven't figured out a way to have postres use a connection opened by another process... it likes spiking the cpu and sitting in some pqbytes function or some shit like that when doing a query on it. https://dpejesh.dnsalias.net/repos/mod_auth_pgsql/trunk/ Shane
Re: mod_authn_mysql
On Fri, 14 Feb 2003 14:52:07 -0700, David Shane Holden wrote Since there seems to be some interest in including a mysql auth module into the tree, here's a postgres module which I've coded and have been using for the past month or so. As for a connection pool... I haven't figured out a way to have postres use a connection opened by another process... it likes spiking the cpu and sitting in some pqbytes function or some shit like that when doing a query on it. https://dpejesh.dnsalias.net/repos/mod_auth_pgsql/trunk/ Shane I am using apr_reslist to implment pooling of Database connections.
Re: mod_authn_mysql
--On Friday, February 14, 2003 4:26 PM -0700 David Shane Holden [EMAIL PROTECTED] wrote: My problem isn't managing a pool of connections... it's if process A creates the connection, process B can use it with no problem, but if process C tries to use it, it barfs and spikes in a function in libpq, i think it was pgbytes. You can't really share connections across processes. Across threads, perhaps. But, sharing them across processes is asking for trouble. You'd usually be relying upon shmem which is tricky and not really meant for sharing shm-able data structures. (Some custom OS techniques might be available, but they wouldn't be portable.) -- justin
Re: mod_authn_mysql
Justin Erenkrantz wrote: --On Friday, February 14, 2003 4:26 PM -0700 David Shane Holden [EMAIL PROTECTED] wrote: My problem isn't managing a pool of connections... it's if process A creates the connection, process B can use it with no problem, but if process C tries to use it, it barfs and spikes in a function in libpq, i think it was pgbytes. You can't really share connections across processes. Across threads, perhaps. But, sharing them across processes is asking for trouble. You'd usually be relying upon shmem which is tricky and not really meant for sharing shm-able data structures. (Some custom OS techniques might be available, but they wouldn't be portable.) -- justin It's starting to look that way, but I'm not done with it yet. I can share a connection across threads in the worker mpm with no problem, I've had ab thrash the hell out of it without any problems. But, as you say, the cross process shm stuff is tricky and extremely frustrating. Shane
Re: mod_authn_mysql
Looking at existing 1,3 modules for sybase, postgress, msql and mysql I see that we essentially just use: - connect - disconnect - select/query SQL string - get back a table - escape a SQL string (i.e. \ etc, protect against illegal entry) - decode an error Would it be worth our while to do something so that we can deal with all 4 or 5 with a simple lib_sql_* behind a generic mod_authn_sql. (Note - I do not want to re-invent ODBC :-). Dw
Re: mod_authn_mysql
Date: Thu, 13 Feb 2003 10:48:42 +0100 (CET) To: [EMAIL PROTECTED] From: Dirk-Willem van Gulik [EMAIL PROTECTED] Looking at existing 1,3 modules for sybase, postgress, msql and mysql I see that we essentially just use: [snip] Would it be worth our while to do something so that we can deal with all 4 or 5 with a simple lib_sql_* behind a generic mod_authn_sql. Don't think it's worth the hassle as it's just a few lines (more or less) duplicated. The error checking would be driver specific anyway. It would be different if the proposed mod_authn_sql (or mod_authn_rdbm) would implement a generic connection pooling. I do not want to re-invent ODBC :-) Some folks tried to: http://libdbi.sourceforge.net/ Masi
Re: mod_authn_mysql
-- Original Message -- Reply-To: [EMAIL PROTECTED] From: Martin Kutschker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: mod_authn_mysql Date: Thu, 13 Feb 2003 12:08:02 +0100 (MET) Looking at existing 1,3 modules for sybase, postgress, msql and mysql I see that we essentially just use: Would it be worth our while to do something so that we can deal with all 4 or 5 with a simple lib_sql_* behind a generic mod_authn_sql. Don't think it's worth the hassle as it's just a few lines (more or less) duplicated. The error checking would be driver specific anyway. hmmm, I actually like the idea. It would allow us to create a very feature rich auth module, supporting all sorts of different kinds of schemas for group membership and what not. - I disagree that the sql re-use would just be a few lines, I think it would be quite a bit more if features were added. It would be different if the proposed mod_authn_sql (or mod_authn_rdbm) would implement a generic connection pooling. this, IMO, doesn't belong in an auth module itself. if you implement connection pooling it should be independent of who is using the connections. sterling
Re: mod_authn_mysql
hmmm, I actually like the idea. It would allow us to create a very feature rich auth module, supporting all sorts of different kinds of schemas for group membership and what not. - I disagree that the sql re-use would just be a few lines, I think it would be quite a bit more if features were added. It would be different if the proposed mod_authn_sql (or mod_authn_rdbm) would implement a generic connection pooling. this, IMO, doesn't belong in an auth module itself. if you implement connection pooling it should be independent of who is using the connections. okay, so why not just put libdbi(somthing like it/based off of it) into APR-Util? http://libdbi.sourceforge.net/features.php I wonder if the libdbi people would be willing to re-license.. They are currently using LGPL. -chip
