RE: Code update to handle apache dynamic configuration updates to httpd.conf.
On Wed, 2005-12-21 at 11:02 +0530, [EMAIL PROTECTED] wrote: But the requirement for my project itself is to be able to update the configuration (update SSL certificates/key of a virtual host) dynamically without apache restart. Then you need to fix requirements for your project and not apache. 24/7 HTTP uptime can be achieved by high-availability projects like LVS (Linux Virtual Server) or other load balancer systems. You can also use some load-balanced hardware SSL accelerator where it would be possible to upload new certificates without restart (just guessing). Trying to push square block through round hole simply doesn't work, use KISS principle (Keep It Simple, Stupid). Ondrej. -- Ondrej Sury [EMAIL PROTECTED]
RFC: mod_epp module for EPP protocol processing
Hi, quickly about EPP. EPP is protocol used by registry-registrar communication and is used for ccTLD (.cz,.eu) and some gTLD (.org,.info). It's XML based and defined by several RFCs. It's has mechanism to support extensions (f.e. .eu has implemented some extensions over RFCs). I would like to write mod_epp module which would implement EPP protocol (similar to mod_smtp). It will still need system which will keep evidence of contacts/subjects/domain names behind and this module would just create layer between central registry and EPP enabled registrars. I think that apache provides excelent framework for creating network enabled applications with safe arbitrary string processing and memory allocations. What do other people think about this? Ondrej. -- Ondrej Sury [EMAIL PROTECTED]
Support for Server Name Indication (Was: NameVirtualHosts SSL)
On Tue, 2005-11-08 at 11:24 -0600, William A. Rowe, Jr. wrote: Ondrej Sury wrote: Just a thought... Wouldn't it be possible to solve this by extending HTTP to support something similar to STARTTLS from IMAP/SMTP? Dudes, it's already published in http://rfc.net/rfc2818.html - yet it seems my mailbox fills with another 100k of this discussion every month (mostly on [EMAIL PROTECTED]). It's not worth reinventing twice. Read the RFC, and take it to your favorite browser vendor/author/project. If open source - offer a patch already to them. Go solve it - quit writing here about it :) In three years after widely distributed, we could quit deploying 1:1 IP's per host. There is already bug in mozilla bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=276813 Alternate approach is to use Server Name Indication TLS extension as specified by: http://rfc.net/rfc3546.html and covered by https://bugzilla.mozilla.org/show_bug.cgi?id=116168 and it will be implemented in upcomming IE7 http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: NameVirtualHosts SSL
On Tue, 2005-10-25 at 20:25 +0200, Joost de Heer wrote: The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing to do with the webserver. nitpick one-virtual-host-per-ip-and-port /nitpick Just a thought... Wouldn't it be possible to solve this by extending HTTP to support something similar to STARTTLS from IMAP/SMTP? Ie. instead of submitting: GET / HTTP/1.0 Host: foobar.tld browser would do: STARTTLS foobar.tld encrypted comm Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [pre-release] 2.0.55 *candidate* available for testing
On Wed, 2005-10-12 at 12:10 +0200, Graham Leggett wrote: William A. Rowe, Jr. said: So... is it unreasonable in README.RPM to point the user to obtain the current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz which would be grabbed from svn httpd/package/rpm/, and drop it into the unpacked httpd-2.0.55 source tarball, in order to package? Secondly the httpd.spec file contains version specific information (the version number, the MMN, etc) that would be both a serious pain to maintain separately by a packager and a serious pain to tie up with the required source by a person building an RPM. Sorry, but in DEB world, this is pretty normal to have separate upstream source and debian/ subdirectory and it's not serious pain at all. Upstream and packagers work in clearly separated and in my view it's good. But my view can be twisted since there are propably a bit different *standards* how is package provided in DEB and RPM world, ie. debianers are not used to compile packages themselves a lot, they use packages provided by their distribution. O. P.S.: Please, keep it cool and don't flame. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Should exist: mod_log_dbus?
On Wed, 2005-10-12 at 09:54 -0400, Brian Akins wrote: Andy Armstrong wrote: I'm prepared to do some work on such a module but I don't want to do it if there's some obvious alternative I'm missing. Is this something that might be useful? Is there something out there already that I've missed? This may not be the most appropriate place to discuss it, but I am willing to help do some work as well. From the quick overview of dbus I just read, it doesn't look too complicated to do. Hi Brian, I think this is another good example where one could use of your mod_log_config with providers patch. It should be fairy easy to write provider for something like dbus. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [pre-release] 2.0.55 *candidate* available for testing
On Thu, 2005-10-13 at 14:44 +0200, Graham Leggett wrote: [...] Sounds reasonable... Sometimes however, someone might need a bleeding edge feature not offered by a distro, but they might not want to clutter up their system with custom install trees. The ASF packages serve the needs of this group of people. Then I would suggest to provide _clean_ .tar.gz not including any .spec or whatever and *also* provide .src.rpm package for bleeding edge testers. How does it sound to you? Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH] Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 23:28 +0100, Colm MacCarthaigh wrote: And after all of this, what if any, are the compelling reasons to implement this in httpd at all? Why can't all of this be moved into piped loggers? Why can't they just parse the logs as they get them and do whatever whoever wants with it after that? After all, many people use logger to log to syslog. The whole mod_log_spread architecture with two netcat commands, and that can even be done with privilege seperation, which an in-httpd module never could. No, it cannot be implemented with two netcat commands (just tried it). Purpose of mod_log_spread is to unify several balanced frontends logging to one common log server. With netcat you can only do one to one. Second problem that restart of backend server listener cannot cause piped loggers to fail (and thus force you to restart all frontends). Which is f.e. true for netcat. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH] Re: Pluggable mod_log_config
On Tue, 2005-10-04 at 13:55 +0100, Colm MacCarthaigh wrote:
On Tue, Oct 04, 2005 at 08:37:08AM -0400, Brian Akins wrote:
In this case, from my patches:
LogFormat INSERT INTO foo VALUES ('%h', '%l'); foo-sql
CustomLog mysql://user:[EMAIL PROTECTED]/database foo-sql
and the mysql module would get the arrays of strings and lengths. at
init time, it would have prepared the format sql. At log time, it would
bind and execute.
No, I don't think it's so simple at all. Although it would have to parse
the SQL at init time (how does LogFormat know to ask the MySQL provider
to do this?) that can't be simply untied from the actions at log-time;
in the case of SQL for example you have to be very pedantic about the
escaping, so that a request for /foo\'; nasty sql; doesn't kill us.
Well, I think you can do something like this:
LogFormat %h %l foo
MySQLFormat INSERT INTO bar SET hostname = '$1', logname = '$2' bar
MySQLHost mysql0 localhost
CustomLog mysql://mysql0/bar foo
Then ap_mysql_log_writer would do it's own processing of strs/strl
combo.
And we still need additional per-provider directives to provide the
database, hostname, username and so on information.
That's true.
If such directives are required anyway, what effort are we saving?
Why not just replace mod_log_config rather than plug into it.
Because there is a lot more stuff which needs to be reimplemented in
mod_log_config and which can be reused in other modules.
Ondrej.
--
Ondrej Sury [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Re: Pluggable mod_log_config
On Tue, 2005-10-04 at 14:06 +0100, Colm MacCarthaigh wrote: On Tue, Oct 04, 2005 at 02:59:40PM +0200, Ondrej Sury wrote: No, it cannot be implemented with two netcat commands (just tried it). Sure, it can, use my Multicast Netcat; Didn't know that anything like that exists. My comment about restarting frontends was based on fact, that I didn't realized that apache2 restarts piped logger automaticaly. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 07:58 -0400, Brian Akins wrote: mod_log_config is pluggable. You can replace the normal logging functions quite easily. The word here is _replace_. If you replace ap_log_writer and ap_log_writer_init you need to implement all types of logging inside ap_log_writer. Imagine this type of config: --cut here-- VirtualHost 1.2.3.4 [...] CustomLog mysql://blah/data common /VirtualHost VirtualHost 1.2.3.5 [...] CustomLog $apache#1 combined # mod_log_spread syntax /VirtualHost VirtualHost 1.2.3.6 [...] CustomLog /var/log/apache2/access.log /VirtualHost --cut here-- Then your replacement function would have to implement all those types of log backends (ie. logging to mysql, spread, and files). So you cannot just easily add support for just another log backend. Even now when you want to make some log files buffered and some not you are out of luck and this could also be solved by making plugging more general. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 09:19 -0400, Brian Akins wrote: Ondrej Sury wrote: Even now when you want to make some log files buffered and some not you are out of luck and this could also be solved by making plugging more general. Ok I see what you mean and I agree. Maybe something stupid like a SetLogHandler similar to SetHandler? or as an argument to CustomLog? I think that argument to CustomLog is ok... you just need to check if logger was already initialized or not (ie. return NULL or data structure from ap_*_logger_init). Each ap_*_logger_init function will be run in some order (AP_HOOK_FIRST, etc.) and it will stop after logger will get initialized. Should not be that hard to implement. Hmmm... Maybe custom loggers could be providers that have an init and a writer function. Yep, something like that. You also need to store which writer to use in each config_log_state. I'll think about it more and came with some proposal (or patch :-). Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 09:35 -0400, Brian Akins wrote:
Ondrej Sury wrote:
You also need to store which writer to use in each config_log_state.
This is already done.
Nope, (void *)cls-log_writer is pointer to log file descriptor.
Also, init is called for each CustomLog config entry.
Yep, but only ap_log_writer_init is called. You need to do something
like that:
foreach provider in ap_log_writer_providers {
cls-log_writer = provider-init(, cls-log_data);
if (cls-log_writer) {
break;
}
}
Then later when writing log you need to call
cls-log_writer(..., cls-log_data, ...)
instead of just
log_writer(...)
Ondrej.
--
Ondrej Sury [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 10:26 -0400, Brian Akins wrote:
Ondrej Sury wrote:
Nope, (void *)cls-log_writer is pointer to log file descriptor.
this can be anything. (it's a void). In some modules I have written,
it's a wrapper around a socket. See, open_config_log
cls-log_writer = log_writer_init(p, s, cls-fname);
log_writer_init retures whatever you function returns. In
mod_log_config, it's an apr_file_t *.
Sorry for not being accurate. My point was that cls-log_writer hold
logger *data/configuration* and not logging *function*.
Also, init is called for each CustomLog config entry.
Yep, but only ap_log_writer_init is called. You need to do something
like that:
foreach provider in ap_log_writer_providers {
cls-log_writer = provider-init(, cls-log_data);
if (cls-log_writer) {
break;
}
}
Then later when writing log you need to call
cls-log_writer(..., cls-log_data, ...)
instead of just
log_writer(...)
yes. basically.
I figure you could change cls to:
typedef struct {
const char *fname;
const char *format_string;
apr_array_header_t *format;
void *log_writer;
void *log_init; /*added*/
char *condition_var;
} config_log_state;
What about:
typedef struct {
const char *fname;
const char *format_string;
apr_array_header_t *format;
ap_log_writer *log_writer; /* changed */
ap_log_writer_init *log_writer_init; /* added */
void *log_writer_config; /* changed from log_writer */
char *condition_var;
} config_log_state;
If you set log writing function to log_writer then you are missing
config for this writer (ie. socket or apr_file_t * or mysql connection
or whatever else).
and log_init and log_writer would be set at config time. log_init would
get ran in open_logs.
Agree.
Ondrej.
--
Ondrej Sury [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Re: Pluggable mod_log_config
On Mon, 2005-10-03 at 11:40 -0400, Brian Akins wrote: Akins, Brian wrote: CustomLog mysql://something common env=images CustomLog file:///logs/my.log combined CustomLog spread://somegroup refere CustomLog buffer:///logs/other.log common This patch implements the above. Within mod_log_config two providers are provided: file and buffer. If no scheme is given, file is assumed. I have tested and preliminarily it works for both file and buffer. I had to rearrange some of the buffer code to get it to work non-globally. It should be just as easy to write custom log handles. With this patch, different custom loggers could handle different log files. Comments? Wow, you're fast :-). Just quick thought, maybe we should add: ap_log_writer_close *close; to struct log_provider_t. It's not absolutely necessary, because you can use apr_pool_cleanup_register(...), but it will make writing addon modules much cleaner. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Pluggable mod_log_config
Hi, I am working on mod_log_spread for apache 2.0. Old mod_log_spread for apache 1.3 was based on some older version of mod_log_config and so it is my new version based on (recent) mod_log_config from apache 2.0.54. Right now any module which wants to implement custom logging has to reimplement or reuse some parts of mod_log_config (at least log_*). Maybe I am beating dead horse, but have you been thinking about pluggable mod_log_config? It should not be that hard, moving ap_log_writer *log_writer and ap_log_writer_init *log_writer_init to config_log_state structure and some modifications to code should do the trick. Then there will be hook for open_config_log, which will either fill in config_log_state or DECLINE, and config_log_transaction will call cls-write_log(r, cls-log_writer, ...); Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[PATCH 36410] Backport: mod_cgid segfaults when module other than mod_suexec is providing uid/gid
Hi, could I raise your attention to following backported patch? I would be nice to have it in 2.0.55 (from STATUS) *) mod_cgid: Fix PR 36410. Invoke the set_suexec_identity hook from the non-cgid side of the handler, where the full per-server/dir/etc configuration is available instead of using two mod_suexec and mod_userdir specific hacks. See mod_vhost_ldap[1] for an example third-party get_suexec_identity implementation. http://people.apache.org/~colm/2.0.x-suexec-cgid.patch +1: colm mod_vhost_ldap is not only module setting suexec uid/gid. There is a plenty other vhost modules doing more or less same thing. Problem is on Debian where mod_cgid is selected instead mod_cgi when MPM worker is used. Ondrej 1. http://modvhostldap.alioth.debian.org/ P.S.: This together with mod_ldap caching fix backport patch are problems found when I wrote mod_vhost_ldap. Thanks goes to Fabian Fagerholm who discovered what exactly problem is and to Colm for fixing it. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[PATCH 36563] Backported patch invalid handling of NULL values in mod_ldap caching
Hello,
attached is backported patch from 2.1-BETA7 which fixes invalid handling
of NULL values in mod_ldap caching code.
There is an open bug in bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36563
And this is just updated patch against today SVN checkouted 2.0.x (patch
from bugzilla applies ok with offset of 20 lines).
Hopefully this gets accepted before 2.0.55 is out, since this bug can
cause memory leaks in util_ldap_search_node_free (not all items are
freed only those before first item with NULL value).
Ondrej.
--
Ondrej Sury [EMAIL PROTECTED]
Index: modules/experimental/util_ldap_cache.c
===
--- modules/experimental/util_ldap_cache.c (revision 290104)
+++ modules/experimental/util_ldap_cache.c (working copy)
@@ -158,18 +158,22 @@
/* copy vals */
if (node-vals) {
-int k = 0;
+int k = node-numvals;
int i = 0;
-while (node-vals[k++]);
if (!(newnode-vals = util_ald_alloc(cache, sizeof(char *) * (k+1 {
util_ldap_search_node_free(cache, newnode);
return NULL;
}
-while (node-vals[i]) {
-if (!(newnode-vals[i] = util_ald_strdup(cache, node-vals[i]))) {
-util_ldap_search_node_free(cache, newnode);
-return NULL;
+newnode-numvals = node-numvals;
+for (;k;k--) {
+if (node-vals[i]) {
+if (!(newnode-vals[i] = util_ald_strdup(cache, node-vals[i]))) {
+util_ldap_search_node_free(cache, newnode);
+return NULL;
+}
}
+else
+newnode-vals[i] = NULL;
i++;
}
}
@@ -199,9 +203,13 @@
{
int i = 0;
util_search_node_t *node = (util_search_node_t *)n;
+int k = node-numvals;
+
if (node-vals) {
-while (node-vals[i]) {
-util_ald_free(cache, node-vals[i++]);
+for (;k;k--,i++) {
+if (node-vals[i]) {
+util_ald_free(cache, node-vals[i]);
+}
}
util_ald_free(cache, node-vals);
}
Index: modules/experimental/util_ldap_cache.h
===
--- modules/experimental/util_ldap_cache.h (revision 290104)
+++ modules/experimental/util_ldap_cache.h (working copy)
@@ -110,6 +110,7 @@
NULL if the bind failed */
apr_time_t lastbind; /* Time of last successful bind */
const char **vals; /* Values of queried attributes */
+intnumvals; /* Number of queried attributes */
} util_search_node_t;
/*
Index: modules/experimental/util_ldap.c
===
--- modules/experimental/util_ldap.c (revision 290104)
+++ modules/experimental/util_ldap.c (working copy)
@@ -769,6 +769,7 @@
const char ***retvals)
{
const char **vals = NULL;
+int numvals = 0;
int result = 0;
LDAPMessage *res, *entry;
char *dn;
@@ -932,6 +933,7 @@
int i = 0;
while (attrs[k++]);
vals = apr_pcalloc(r-pool, sizeof(char *) * (k+1));
+numvals = k;
while (attrs[i]) {
char **values;
int j = 0;
@@ -959,6 +961,7 @@
the_search_node.bindpw = bindpw;
the_search_node.lastbind = apr_time_now();
the_search_node.vals = vals;
+the_search_node.numvals = numvals;
/* Search again to make sure that another thread didn't ready insert this node
into the cache before we got here. If it does exist then update the lastbind */
@@ -1001,6 +1004,7 @@
const char ***retvals)
{
const char **vals = NULL;
+int numvals = 0;
int result = 0;
LDAPMessage *res, *entry;
char *dn;
@@ -1115,6 +1119,7 @@
int i = 0;
while (attrs[k++]);
vals = apr_pcalloc(r-pool, sizeof(char *) * (k+1));
+numvals = k;
while (attrs[i]) {
char **values;
int j = 0;
@@ -1142,6 +1147,7 @@
the_search_node.bindpw = NULL;
the_search_node.lastbind = apr_time_now();
the_search_node.vals = vals;
+the_search_node.numvals = numvals;
/* Search again to make sure that another thread didn't ready insert this node
into the cache before we got here. If it does exist then update the lastbind */
signature.asc
Description: This is a digitally signed message part
