Re: How to determine the right vhost in name based vhosting
Hello list, Hello Sorin, I tested several different Apaches (2.4.x and 2.2.x) and they never did the wanted or expected. If I configure more than one VHost only the first one is returned by the server-server_hostname structure. The one of the second vhost that is configured as a ServerName seems to be impossible to determine? Is there any other way to find the hostname? Greetings -- Sitepark Gesellschaft für Informationsmanagement mbH Rothenburg 14-16, 48143 Münster Telefon: +49 251 482655-0, Telefax: +49 251 482655-55 http://www.sitepark.com http://www.facebook.com/sitepark Geschäftsführer: Thorsten Liebold Amtsgericht Münster, HRB 5017
Re: How to determine the right vhost in name based vhosting
On 2013-09-24 11:38, Christoph Gröver wrote: Hello list, Hello Sorin, I tested several different Apaches (2.4.x and 2.2.x) and they never did the wanted or expected. If I configure more than one VHost only the first one is returned by the server-server_hostname structure. The one of the second vhost that is configured as a ServerName seems to be impossible to determine? Is there any other way to find the hostname? I suppose you use the server field of the request_rec structure and not some stored server_rec that was passed to you in post_config or somewhere else. Apache keeps a linked list of server_rec structures. The head of the list is the server_rec of the whole apache server. The rest of the list contains one server_rec structure per vhost. For each request apache picks the right server_rec from the list according to the Host header and sets r-server to point to the picked object. Also make sure that your request really arrives in the vhost you intended. Typically I check this by logging to different files (see the CustomLog directive) in each vhost. Regards, Sorin
Re: How to determine the right vhost in name based vhosting
On Sep 24, 2013 5:40 AM, Christoph Gröver gro...@sitepark.com wrote: Hello list, Hello Sorin, I tested several different Apaches (2.4.x and 2.2.x) and they never did the wanted or expected. If I configure more than one VHost only the first one is returned by the server-server_hostname structure. The one of the second vhost that is configured as a ServerName seems to be impossible to determine? Is there any other way to find the hostname? When you check, are you in the middle of a request that's mapped to the 2nd virtual host? In what phase do you inspect the value? If you define a logfile in your 2nd vhost, does it accumulate entries?
Re: How to determine the right vhost in name based vhosting
Hello Sorin, I suppose you use the server field of the request_rec structure and not some stored server_rec that was passed to you in post_config or somewhere else. Definitely. I have adopted this from some other module and didn't know there was another way to obtain a server_rec structure. So I should be looking for a better way to find the right structure. Thank you very much. This sounds as if it will be the right way. Apache keeps a linked list of server_rec structures. The head of the list is the server_rec of the whole apache server. The rest of the list contains one server_rec structure per vhost. For each request apache picks the right server_rec from the list according to the Host header and sets r-server to point to the picked object. This information will also help. Thank you. Also make sure that your request really arrives in the vhost you intended. Typically I check this by logging to different files (see the CustomLog directive) in each vhost. This is actually the case. I receive the requests in the right vhost. I have separate logfiles for each vhost. Thanks for your answers. I guess I will be able to solve the issue with these informations. With kind regards, -- Sitepark Gesellschaft für Informationsmanagement mbH Rothenburg 14-16, 48143 Münster Telefon: +49 251 482655-0, Telefax: +49 251 482655-55 http://www.sitepark.com http://www.facebook.com/sitepark Geschäftsführer: Thorsten Liebold Amtsgericht Münster, HRB 5017
Re: How to determine the right vhost in name based vhosting
On 2013-09-24 13:04, Christoph Gröver wrote: Hello Sorin, I suppose you use the server field of the request_rec structure and not some stored server_rec that was passed to you in post_config or somewhere else. Definitely. I have adopted this from some other module and didn't know there was another way to obtain a server_rec structure. So I should be looking for a better way to find the right structure. Thank you very much. This sounds as if it will be the right way. I fear there's a misunderstanding here: The right way to get the server_rec is, in my opinion, from the request_rec structure, i.e. I think you should use req-server-server_hostname. So, given that you already do this, it is puzzling for me why you don't get the result that you want. Apache sets the req-server pointer to the right server_rec structure after it has parsed the request headers. (It cannot guess correctly before it parses the Host header.) So make sure you check req-server _after_ apache has initialised it to the right server_rec. Apache sets it in the ap_read_request method. Almost all of the callbacks provided to the module developers are called _after_ ap_read_request, so you should be ok. I think only the create_connection callback is run before ap_read_request. As a poor man's debugger technique you could write a post_config callback. The last argument of the post_config callback is the head of the list of server_recs. You could traverse the list and log to a file the server_hostname of all server_recs in the list. Just to check that you have the right number of server_recs and that they are correctly initialised. Sorin Apache keeps a linked list of server_rec structures. The head of the list is the server_rec of the whole apache server. The rest of the list contains one server_rec structure per vhost. For each request apache picks the right server_rec from the list according to the Host header and sets r-server to point to the picked object. This information will also help. Thank you. Also make sure that your request really arrives in the vhost you intended. Typically I check this by logging to different files (see the CustomLog directive) in each vhost. This is actually the case. I receive the requests in the right vhost. I have separate logfiles for each vhost. Thanks for your answers. I guess I will be able to solve the issue with these informations. With kind regards,
Re: How to determine the right vhost in name based vhosting
Hello Sorin, Thank you very much. I finally found out the course of the strange results I am getting. I used the request_rec to get the conn_rec. In this connection record there's a field called base_server, which I used as the source for the server_hostname. request_rec *r; conn_rec *c; server_rec *server; c = r-connection; server = c-base_server; My misunderstanding was that this leads to the main vhost I am using. But it actually leads to the default server of the current ip:port combination. Now I use: server = r-server; This gives the expected result. Everything is fine now ;-). I can't tell you why I used the more complicated way to retrieve a server_rec. Probably just used some example code from somewhere. In the beginning everything seemed alright since we always had just one vhost under one IP. The problem showed up when we had a second vhost running. Another misunderstanding solved now. Thank you for your time (and patience). With kind regards .. -- Sitepark Gesellschaft für Informationsmanagement mbH Rothenburg 14-16, 48143 Münster Telefon: +49 251 482655-0, Telefax: +49 251 482655-55 http://www.sitepark.com http://www.facebook.com/sitepark Geschäftsführer: Thorsten Liebold Amtsgericht Münster, HRB 5017
Re: svn commit: r1525597 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/http_core.h include/httpd.h server/core.c server/log.c
On 09/23/2013 08:39 PM, Jeff Trawick wrote:
On Mon, Sep 23, 2013 at 10:02 AM, jkal...@apache.org
mailto:jkal...@apache.org wrote:
Author: jkaluza
Date: Mon Sep 23 14:02:27 2013
New Revision: 1525597
URL: http://svn.apache.org/r1525597
Log:
Add ap_errorlog_provider to make ErrorLog logging modular. Move
syslog support from core to new mod_syslog.
Since new fields were added to the middle of existing structures, you
need a major bump to MMN so that existing modules won't load without
recompile.
Thanks for reviewing my patches. I've fixed the problems you have found
in r1525845.
Regards,
Jan Kaluza
Here's an example of a major bump:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?r1=1496709r2=1498880diff_format=h
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/docs/manual/mod/core.xml
httpd/httpd/trunk/include/http_core.h
httpd/httpd/trunk/include/httpd.h
httpd/httpd/trunk/server/core.c
httpd/httpd/trunk/server/log.c
Modified: httpd/httpd/trunk/CHANGES
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1525597r1=1525596r2=1525597view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Mon Sep 23 14:02:27 2013
@@ -1,6 +1,9 @@
-*-
coding: utf-8 -*-
Changes with Apache 2.5.0
+ *) core: Add ap_errorlog_provider to make ErrorLog logging
modular. Move
+ syslog support from core to new mod_syslog. [Jan Kaluza]
+
*) mod_proxy_fcgi: Handle reading protocol data that is split
between
packets. [Jeff Trawick]
Modified: httpd/httpd/trunk/docs/manual/mod/core.xml
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml?rev=1525597r1=1525596r2=1525597view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/core.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/core.xml Mon Sep 23 14:02:27 2013
@@ -1298,16 +1298,19 @@ ErrorDocument 404 /cgi-bin/bad_urls.pl
http://bad_urls.pl
more information./p
pUsing codesyslog/code instead of a filename enables logging
-via syslogd(8) if the system supports it. The default is to use
-syslog facility codelocal7/code, but you can override this by
-using the codesyslog:varfacility/var/code syntax where
-varfacility/var can be one of the names usually documented in
+via syslogd(8) if the system supports it and if
modulemod_syslog/module
+is loaded. The default is to use syslog facility
codelocal7/code,
+but you can override this by using the
codesyslog:varfacility/var/code
+syntax where varfacility/var can be one of the names
usually documented in
syslog(1). The facility is effectively global, and if it is
changed
in individual virtual hosts, the final facility specified
affects the
entire server./p
highlight language=configErrorLog syslog:user/highlight
+pAdditional modules can provide their own ErrorLog providers.
The syntax
+is similar to codesyslog/code example above./p
+
pSECURITY: See the a
href=../misc/security_tips.html#serverrootsecurity tips/a
document for details on why your security could be compromised
Modified: httpd/httpd/trunk/include/http_core.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=1525597r1=1525596r2=1525597view=diff
==
--- httpd/httpd/trunk/include/http_core.h (original)
+++ httpd/httpd/trunk/include/http_core.h Mon Sep 23 14:02:27 2013
@@ -833,8 +833,8 @@ typedef struct ap_errorlog_info {
/** apr error status related to the log message, 0 if no error */
apr_status_t status;
-/** 1 if logging to syslog, 0 otherwise */
-int using_syslog;
+/** 1 if logging using provider, 0 otherwise */
+int using_provider;
/** 1 if APLOG_STARTUP was set for the log message, 0 otherwise */
int startup;
@@ -842,6 +842,30 @@ typedef struct ap_errorlog_info {
const char *format;
} ap_errorlog_info;
+#define AP_ERRORLOG_PROVIDER_GROUP error_log_writer
+#define AP_ERRORLOG_PROVIDER_VERSION 0
+#define AP_ERRORLOG_DEFAULT_PROVIDER file
+
+typedef struct ap_errorlog_provider ap_errorlog_provider;
+
+struct ap_errorlog_provider {
+/** Initializes the error log writer.
+ * @param p The pool to create any storage from
+ * @param s Server for which the logger is initialized
+ *
Re: any interest in massaging the new error log provider to fit into 2.4.x?
On Tue, Sep 24, 2013 at 2:25 AM, Jan Kaluža jkal...@redhat.com wrote: On 09/23/2013 09:13 PM, Jeff Trawick wrote: On Mon, Sep 23, 2013 at 2:54 PM, Ivan Zhakov i...@visualsvn.com mailto:i...@visualsvn.com wrote: On 23 September 2013 22:35, Jeff Trawick traw...@gmail.com mailto:traw...@gmail.com wrote: In 2.4 the syslog logging wouldn't be implemented as a provider, the ErrorLog directive parser would be different, new structure fields would be at the end, but otherwise it shouldn't be hard :) It could be theoretical backward compatibility issue if someone uses log named the same as some provider. Why not add new directive LogProvider? I've never seen a log file within the ServerRoot directory. The risk of such a configuration and it matching a provider actually loaded seems low enough (and with an easy enough workaround) to forgo having a different configuration directives between 2.4/next-major-release. But maybe ErrorLogProvider provider-name arg1-n would be nicer anyway (same in all applicable branches). I used ErrorLog directive to stay compatible with current syslog configuration, but if you don't see problems with breaking ErrorLog syslog in trunk, it should be OK to use different directive for providers. I'm not sure I see some new compatibility problems with use of ErrorLog directive (except the problem when admin tries to name his log file the same name as already used by some provider, but this problem is here already with syslog). Btw, what would be the semantic of ErrorLog when ErrorLogProvider gets implemented? Will it be just alias for ErrorLogProvider file logs/error_log? In this case, if we don't mind so much about backward compatibility in trunk, I still think just ErrorLog directive for setting both provider and arguments is cleaner solution. That's fine. Note that when using a separate ErrorLogProvider, a directive like ErrorLog (belonging to a particular provider) would just be ignored if ErrorLogProvider was set to something non-default, just as DbmErrorLogParams might be ignored by the implementing module if ErrorLogProvider was set to the default. -- Ivan Zhakov -- Born in Roswell... married an alien... http://emptyhammock.com/ Regards, Jan Kaluza -- Born in Roswell... married an alien... http://emptyhammock.com/
[PATCH 55593] Add SSLServerInfoFile directive
Hi Apache folks, I've been working with Ben Laurie on a ServerInfoFile feature for OpenSSL 1.0.2. Using a call to OpenSSL's SSL_CTX_use_serverinfo_file() the user can specify a file of PEM blocks containing TLS ServerHello extension data. The extensions will be returned if the client sends a corresponding ClientHello. This allows support of Certificate Transparency (RFC 6962), TACK (draft-perrin-tls-tack), and similar things. The feature is checked in to the 1.0.2 branch [1], so we'd like to expose it through Apache. The patch is pretty simple. I suppose more tests or docs might be needed (?), which I'm happy to write. Anyways, is this something Apache is interested it? Does the patch look correct? [2] Trevor [1] https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=55593
Increasing mod_ssl's minimum required OpenSSL version for trunk/2.4.x to 0.9.8a
On 23.09.2013 11:17, Joe Orton wrote: On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote: Feedback on this approach is again very welcome. Increasing the minimum required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in October 2005 already. I'd guess this is uncontroversial for trunk, but might be worth flagging up in a separate thread since people did care about 0.9.7 last time we had a poll. Or you could just slip it in and anybody who is not paying attention to dev@ can suffer the consequences ;) Ok, let's do that then. For the sake of completeness: these are the threads started in May 2010 and July 2011, respectively: https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3c20100525124551.ga11...@redhat.com%3E https://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3c4e35065d.30...@velox.ch%3E In the first thread, Joe asked about going straight to 1.0[.0], and people were mostly concerned about 0.9.8 (not 0.9.7) at that time. See e.g. https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3ca40a83c6-5030-4226-a09a-a6393cb6e...@apache.org%3E https://mail-archives.apache.org/mod_mbox/httpd-dev/201006.mbox/%3c4c0535a9.10...@kippdata.de%3E What I put together about two years ago is still true: Some more data points: - the last OpenSSL 0.9.6 release (0.9.6m) is from March 2004 - OpenSSL 0.9.8 was released in July 2005 - the last OpenSSL 0.9.7 release (0.9.7m) is from February 2007 - OpenSSL 1.0.0 was released in March 2010 I.e., no one should try to compile trunk against OpenSSL 0.9.6 these days, IMO (and even 0.9.7 isn't really a good idea, as the official releases are no longer maintained). Speaking of mod_ssl in 2.4.x, I can hardly imagine that OS vendors which consider shipping 2.4 (as opposed to 2.2) would still want to compile this against OpenSSL 0.9.7 (even Solaris is now at 1.0.0, FYI). So, QUESTION: is there anyone who still thinks that going to OpenSSL 0.9.8a for trunk (and very likely for 2.4.x, when backporting) is a bad idea? If so, please raise your voice. Kaspar
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Thanks Joe and Rüdiger for your feedback. I'm going to finish and commit part1 of the patch next (which seems uncontroversial), and wait a few more days for opinions re: OpenSSL 0.9.8a, see also the separate thread. Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways, is this something Apache is interested it? Does the patch
look correct? [2]
I'd very much prefer to see this supported via SSLOpenSSLConfCmd
(http://svn.apache.org/r1421323), and not code this into mod_ssl by
adding yet another directive. For the authz_file / RFC 5878 stuff, I did
some experiments at the time, and am attaching a[n untested] patch for
SSL_CTX_use_serverinfo_file - could you give it a try?
Depending on when exactly you need the SSL_CTX_use_serverinfo_file to
happen in ssl_engine_init.c, we might have to move around the #ifdef
HAVE_SSL_CONF_CMD block somewhat, but this shouldn't be a real issue
(for authz_file, it was necessary/doable).
Kaspar
diff --git a/ssl/ssl_conf.c b/ssl/ssl_conf.c
index 1f4c4dd..2c0e356 100644
--- a/ssl/ssl_conf.c
+++ b/ssl/ssl_conf.c
@@ -365,6 +365,14 @@ static int cmd_options(SSL_CONF_CTX *cctx, const char
*value)
return CONF_parse_list(value, ',', 1, ssl_set_option_list, cctx);
}
+static int cmd_serverinfo_file(SSL_CONF_CTX *cctx, const char *value)
+ {
+ int rv = 1;
+ if (cctx-ctx)
+ rv = SSL_CTX_use_serverinfo_file(cctx-ctx, value);
+ return rv 0;
+ }
+
typedef struct
{
int (*cmd)(SSL_CONF_CTX *cctx, const char *value);
@@ -372,7 +380,7 @@ typedef struct
const char *str_cmdline;
} ssl_conf_cmd_tbl;
-/* Table of supported patameters */
+/* Table of supported parameters */
static ssl_conf_cmd_tbl ssl_conf_cmds[] = {
{cmd_sigalgs, SignatureAlgorithms, sigalgs},
@@ -384,6 +392,7 @@ static ssl_conf_cmd_tbl ssl_conf_cmds[] = {
{cmd_cipher_list, CipherString, cipher},
{cmd_protocol, Protocol, NULL},
{cmd_options, Options, NULL},
+ {cmd_serverinfo_file, ServerInfoFile, NULL},
};
int SSL_CONF_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value)
