Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery
Hi Nick, I'm using the latest revision of mod_dbd.c and I still get a segfault on startup. My setup: CONFIGURE FLAGS: ./configure --enable-so --enable-auth-digest --enable-dbd --enable-authn-dbd --with-mysql=/usr HTTPD.CONF: DBDriver mysql DBDParams "dbname=xxx user=xxx pass=xxx" AuthType Digest AuthName "xxx" AuthDigestProvider dbd Require valid-user AuthDBDUserRealmQuery "SELECT pwhash FROM users WHERE name = %s and realm = %s" GDB BACKTRACE: (gdb) run -X -d .. [Thread debugging using libthread_db enabled] [New Thread -1212180800 (LWP 23469)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212180800 (LWP 23469)] apr_hashfunc_default (char_key=0x0, klen=0xbfc96c38) at tables/apr_hash.c:228 /home/paritosh/limespot/apache2.2/srclib/apr/tables/apr_hash.c:228:7055:beg:0xb7daa3ce (gdb) bt #0 apr_hashfunc_default (char_key=0x0, klen=0xbfc96c38) at tables/apr_hash.c:228 #1 0xb7daa437 in find_entry (ht=0x8128270, key=0x0, klen=-1, val=0x0) at tables/apr_hash.c:260 #2 0xb7daa5f4 in apr_hash_get (ht=0x, key=0xbfc96c38, klen=-1) at tables/apr_hash.c:330 #3 0x08082a96 in ap_dbd_prepare (s=0x80d3ab0, query=0x , label=0x ) at mod_dbd.c:152 #4 0x0807dedb in authn_dbd_prepare (cmd=0xbfc9701c, cfg=0x812d190, query=0x812d198 "SELECT pwhash FROM principals INNER JOIN users ON principals.resource_id = users.principal_id WHERE name = %s and name != %s") at mod_authn_dbd.c:72 #5 0x080747f9 in invoke_cmd (cmd=0x80b3398, parms=0xbfc9701c, mconfig=0x812d190, args=0x810e58e "") at config.c:873 #6 0x080755d2 in ap_walk_config (current=0x810e4f0, parms=0xbfc9701c, section_vector=0x812cba8) at config.c:1141 #7 0x0806bec4 in urlsection (cmd=0xbfc9701c, mconfig=0x810e198, arg=0x812ce28 "") at core.c:1942 #8 0x080747f9 in invoke_cmd (cmd=0x80b0cd8, parms=0xbfc9701c, mconfig=0x810e198, args=0x810e3c8 "/private>") at config.c:873 #9 0x080755d2 in ap_walk_config (current=0x81141f8, parms=0xbfc9701c, section_vector=0x810d228) at config.c:1141 #10 0x080762b6 in ap_process_config_tree (s=0xbfc96c38, conftree=0x, p=0x80cb0a8, ptemp=0x) at config.c:1743 #11 0x08062071 in main (argc=4, argv=0xbfc97174) at main.c:621 On Thu, 2006-08-17 at 15:21 +0100, Nick Kew wrote: > On Thursday 17 August 2006 14:51, paritosh wrote: > > Hi all, > > > > > > I had a working installation of apache 2.2.2 with mod_dbd and > > mod_authn_dbd configured. Recently I upgraded to 2.2.3 and the server > > crashes with the same backtrace. ( it crashes in apr_hashfunc_default at > > tables/apr_hash.c:228 ). > > That is not a backtrace. > > > Have there been any developments towards > > resolving this ? > > http://svn.apache.org/viewvc?view=rev&revision=424798 > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/database/mod_dbd.c?r1=421103&r2=425659 >
CGI Script Source Code Disclosure Vulnerability in Apache for Windows
See http://marc.theaimsgroup.com/?l=bugtraq&m=115527423727441&w=2 which basically reports "if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems" Joe replied: http://marc.theaimsgroup.com/?l=bugtraq&m=115574424402976&w=2 and I submitted that as an "DISPUTED" to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraq&m=115583509231594&w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Mark -- Mark J Cox | www.awe.com/mark
Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery
On Friday 18 August 2006 08:19, paritosh wrote: > Hi Nick, > > I'm using the latest revision of mod_dbd.c and I still get a segfault on > startup. My setup: > > CONFIGURE FLAGS: > ./configure --enable-so --enable-auth-digest --enable-dbd > --enable-authn-dbd --with-mysql=/usr So that's static compilation ... > > HTTPD.CONF: Looks fine, but > AuthDBDUserRealmQuery "SELECT pwhash FROM users WHERE name = %s and > realm = %s" doesn't look much like > #4 0x0807dedb in authn_dbd_prepare (cmd=0xbfc9701c, cfg=0x812d190, > query=0x812d198 "SELECT pwhash FROM principals INNER JOIN users ON > principals.resource_id = users.principal_id WHERE name = %s and name != > %s") at mod_authn_dbd.c:72 > GDB BACKTRACE: OK, here we have a problem at: > #3 0x08082a96 in ap_dbd_prepare (s=0x80d3ab0, query=0x 0x out of bounds>, label=0x bounds>) at mod_dbd.c:152 where the query and label pointers are garbage. That's the kind of thing I'd expect if one or more of your modules was compiled on a slightly different architecture. But I guess we can rule that out since you compiled statically (assuming you compiled on the same machine it's running on?) Can you compile mod_dbd (and perhaps also mod_authn_dbd) with -O0 rather than the default -O2, so we don't get that kind of report as an artifact of compilation optimisation? -- Nick Kew
Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery
On Fri, 2006-08-18 at 10:23 +0100, Nick Kew wrote: > On Friday 18 August 2006 08:19, paritosh wrote: > > Hi Nick, > > > > I'm using the latest revision of mod_dbd.c and I still get a segfault on > > startup. My setup: > > > > CONFIGURE FLAGS: > > ./configure --enable-so --enable-auth-digest --enable-dbd > > --enable-authn-dbd --with-mysql=/usr > > So that's static compilation ... > > > > HTTPD.CONF: > > Looks fine, but > > > AuthDBDUserRealmQuery "SELECT pwhash FROM users WHERE name = %s and > > realm = %s" > > doesn't look much like > > > #4 0x0807dedb in authn_dbd_prepare (cmd=0xbfc9701c, cfg=0x812d190, > > query=0x812d198 "SELECT pwhash FROM principals INNER JOIN users ON > > principals.resource_id = users.principal_id WHERE name = %s and name != > > %s") at mod_authn_dbd.c:72 > > > > GDB BACKTRACE: > > OK, here we have a problem at: > > > #3 0x08082a96 in ap_dbd_prepare (s=0x80d3ab0, query=0x > 0x out of bounds>, label=0x > bounds>) at mod_dbd.c:152 > > where the query and label pointers are garbage. That's the kind of > thing I'd expect if one or more of your modules was compiled on a > slightly different architecture. But I guess we can rule that out > since you compiled statically (assuming you compiled on the same > machine it's running on?) > Yes, it's the same machine. > Can you compile mod_dbd (and perhaps also mod_authn_dbd) with > -O0 rather than the default -O2, so we don't get that kind of report > as an artifact of compilation optimisation? > > recompiled everything with -O0, the new backtrace is: (gdb) run -X -d .. [Thread debugging using libthread_db enabled] [New Thread -1212528960 (LWP 10335)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212528960 (LWP 10335)] 0xb7d55f2d in apr_hashfunc_default (char_key=0x0, klen=0xbf94b1d8) at tables/apr_hash.c:228 /home/paritosh/limespot/apache2.2.3/srclib/apr/tables/apr_hash.c:228:7055:beg:0xb7d55f2d (gdb) bt #0 0xb7d55f2d in apr_hashfunc_default (char_key=0x0, klen=0xbf94b1d8) at tables/apr_hash.c:228 #1 0xb7d55fad in find_entry (ht=0x813f270, key=0x0, klen=-1, val=0x0) at tables/apr_hash.c:260 #2 0xb7d5626f in apr_hash_get (ht=0x813f270, key=0x0, klen=-1) at tables/apr_hash.c:330 #3 0x0808c433 in ap_dbd_prepare (s=0x80eaab0, query=0x8144178 "SELECT pwhash FROM users WHERE name = %s and realm = %s", label=0x81441b8 "authn_dbd_1") at mod_dbd.c:152 #4 0x08086243 in authn_dbd_prepare (cmd=0xbf94b76c, cfg=0x8144170, query=0x8144178 "SELECT pwhash FROM users WHERE name = %s and realm = % s") at mod_authn_dbd.c:72 #5 0x0807a59e in invoke_cmd (cmd=0x80c9218, parms=0xbf94b76c, mconfig=0x8144170, args=0x8125541 "") at config.c:768 #6 0x0807b70a in ap_walk_config_sub (current=0x81254e8, parms=0xbf94b76c, section_vector=0x8143ba8) at config.c:1141 #7 0x0807b7a4 in ap_walk_config (current=0x81254e8, parms=0xbf94b76c, section_vector=0x8143ba8) at config.c:1174 #8 0x0806fbc4 in urlsection (cmd=0xbf94b76c, mconfig=0x8125198, arg=0x8143e28 "") at core.c:1942 #9 0x0807a3f6 in invoke_cmd (cmd=0x80c67f8, parms=0xbf94b76c, mconfig=0x8125198, args=0x81253c8 "/private>") at config.c:735 #10 0x0807b70a in ap_walk_config_sub (current=0x812b1f8, parms=0xbf94b76c, section_vector=0x8124228) at config.c:1141 #11 0x0807b7a4 in ap_walk_config (current=0x812b1f8, parms=0xbf94b76c, section_vector=0x8124228) at config.c:1174 #12 0x0807c7b3 in ap_process_config_tree (s=0x80eaab0, conftree=0x812a308, p=0x80e20a8, ptemp=0x810) at config.c:1743 #13 0x08062507 in main (argc=4, argv=0xbf94b8f4) at main.c:621 The problem is that s->server_hostname is sent as 'key' to apr_hash_get(). But it is NULL if ServerName directive is not set in the httpd.conf. Simply adding following to httpd.conf solved the problem: SeverName 127.0.0.1:80 ( I should mention that 2.2.2 with similar setup did not crash even without the ServerName directive )
Re: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery
On Friday 18 August 2006 12:35, paritosh wrote: > recompiled everything with -O0, the new backtrace is: > #2 0xb7d5626f in apr_hash_get (ht=0x813f270, key=0x0, klen=-1) at > tables/apr_hash.c:330 Aha! NULL key. That should be the server name. > #3 0x0808c433 in ap_dbd_prepare (s=0x80eaab0, query=0x8144178 "SELECT > pwhash FROM users WHERE name = %s and realm = %s", label=0x81441b8 > "authn_dbd_1") at mod_dbd.c:152 whereas that now makes sense. The junk before was indeed optimisation. > #4 0x08086243 in authn_dbd_prepare (cmd=0xbf94b76c, cfg=0x8144170, > query=0x8144178 "SELECT pwhash FROM users WHERE name = %s and realm = % > s") at mod_authn_dbd.c:72 That should be line 70, not 72. Still slightly confusing. Anyway, this traceback iidentifies the problem: we need to make a special case of a null server name. > The problem is that s->server_hostname is sent as 'key' to > apr_hash_get(). But it is NULL if ServerName directive is not set in the > httpd.conf. Simply adding following to httpd.conf solved the problem: > > SeverName 127.0.0.1:80 > > ( I should mention that 2.2.2 with similar setup did not crash even > without the ServerName directive ) Yes, the fix in 2.2.3 over 2.2.2 was for a bug in handling of virtualhosts. Thanks for the report, and for helping to fix it! I'll commit a patch to /trunk/ shortly. -- Nick Kew
Re: svn commit: r432360 [1/8] - in /httpd/httpd/trunk/docs/manual: ./ mod/ programs/
On Aug 17, 2006, at 6:17 PM, André Malo wrote:
That is all strange. Can you try the following patch in the build-
directory:
Index: lib/DocUtil.pm
===
--- lib/DocUtil.pm (revision 432356)
+++ lib/DocUtil.pm (working copy)
@@ -77,6 +77,7 @@
# use HTTP path separators (/)
$docpath = join '/' => ('', File::Spec->splitdir($docpath), '');
+1 while ($docpath =~ s,/\./,/,g);
$docpath =~ y,/,/,s; # squeeze multiple slashes
# compute relative (HTTP-)path from srcfile to docroot
Applying the above and rerunning ./build.sh I see (as an example
for svn diff):
Index: glossary.html.en
===
--- glossary.html.en(revision 432560)
+++ glossary.html.en(working copy)
@@ -6,29 +6,29 @@
X
-->
Glossary - Apache HTTP Server
-type="text/css" title="Main stylesheet" />
-
-media="print" type="text/css" />
-
+type="text/css" title="Main stylesheet" />
+
+media="print" type="text/css" />
+
Index: invoking.xml.meta
===
--- invoking.xml.meta (revision 432560)
+++ invoking.xml.meta (working copy)
@@ -2,8 +2,8 @@
invoking
- /./
- ..
+ /
+ .
de
so I think that fixes it
Re: svn commit: r432360 [1/8] - in /httpd/httpd/trunk/docs/manual: ./ mod/ programs/
* Jim Jagielski wrote: > Index: invoking.xml.meta > === > --- invoking.xml.meta (revision 432560) > +++ invoking.xml.meta (working copy) > @@ -2,8 +2,8 @@ > > invoking > - /./ > - .. > + / > + . > > de > > > so I think that fixes it Looks great. I suspect a bogus File::Spec implementation for Mac OS X and will apply the patch later this day "officially" to the build system. I think, you can re-checkin that now :) Thanks for your help. nd
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: See http://marc.theaimsgroup.com/?l=bugtraq&m=115527423727441&w=2 which basically reports "if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems" Joe replied: http://marc.theaimsgroup.com/?l=bugtraq&m=115574424402976&w=2 and I submitted that as an "DISPUTED" to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraq&m=115583509231594&w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. Something like the following should probably be added to the docs for ScriptAlias (and perhaps in the CGI tutorial): ScriptAlias is used to both map a URL to a directory and mark requests for that URL as pointing to CGI scripts. It should not be used for directories that are already accessible from the web because they are under the DocumentRoot, for example. Instead, you can use:SetHandler cgi-script Options ExecCGI Joshua.
Problem with mod_python and send data with a form
Hi, I'm a beginner with mod_python and Python (also with english langage, sorry). I tried some exemple code and all works fine! Unfortunately, I have a problem to send data with a form (POST ou GET) to a .py script file. When I try to send data to my .py file, with Firefox, I see a blank page, without text or error message. Here is my form (export.php): -- First Name: And here is my python page (toto.py): --- from mod_python import apache from mod_python import util def say(req, firstname="NOTHING"): req.content_type = "text/html" return "I am saying %s" % firstname --- I have found a apache config file, on my server, with these lines: "... SetHandler python-program PythonHandler mod_python.cgihandler "...' Options -Indexes FollowSymLinks MultiViews AllowOverride All AddHandler mod_python .py PythonHandler mod_python.publisher PythonDebug On Thanks for your help! I would like to find an answer shortly to continue my project! Regards, David
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > I think the right response here is to make it more explicit in the > documentation that putting a ScriptAlias cgi-bin inside document root is > bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. I don't complete agree with you... IMHO the basic "problem" is: The "URL-path" in ScriptAlias (like in Alias and Location) is compared case sensitive first, also on Windows. The "normal" URI to path translation (directory-path) not on Windows. That should be better explained in the manual. BTW: ScriptAlias is not complete the same as an "Options ExecCGI". On Windows you can use something like that to avoid the problem: ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/apache/cgi-bin$1" Regards, Carsten
Re: High CPU utilization on using Apache as a reverse proxy
Hi Jon, Sorry if i mislead you into assuming that I am using Solaris. I am using HP-UX 11iv2. Is HP-UX also affected? In this case also SSL is being used. Regards, PradeepOn 8/17/06, Jon Snow <[EMAIL PROTECTED]> wrote: Pradeep,I can't remember if I posted the results of the SSL issue and high CPU usage.We tracked it to a bug in the solaris driver for the Sun daughter card, somemutex issue if my memory serves me correctly. Sun confirmed and issued a patch a while ago. As discussed in the quoted post I did not believe it wasan apache issue for the SSL but I showed dumps for a corresponding writeissue with a forward proxy in an early anticipation it may be related. This forward proxy problem I had sounds similar to your issue where apacheappears not to test a return value for a write but it did not utilise largeCPU. Currently I run 2.2.2 and have observed the same write problem as I did with 2.0.53. One main issue I have with this is the download continues whilethe write fails so effectively the active connection is not in soundcommunication with the passive.I put the huge memory usage down to the byte range bug as these processes were nearly always streaming or FTPing large files. I have not seen this memoryusage with the version I am running even when I see the write problem.To clarify your issue are you running SSL and if so are you using hardware crypto? I assume you are using solaris, is it patched for crypto re: aboveand what version of solaris are you using?Regards,JonOn Tuesday 15 August 2006 00:47, pradeep kumar wrote:> Hi, >> I notice there is a 100% CPU utilization which spikes for sometime and then> goes back to normalcy when Apache is used a reverse proxy. I noticed a mail> thread which seems to be a similar problem > http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox/%3C200510252>[EMAIL PROTECTED]> >> One thread of one of the child processes hangs, calling poll() and writev()> system calls so frequently that it causes 100% CPU util. The thread is> trying to writev() to a socked which is in CLOSE_WAIT The child process > ends after time defined by ndd parameter tcp_keepalive_interval and the> same service time can be seen in access_log. The problem disappears then.>> Regards,>> Pradeep
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: Joshua Slive schrieb: > On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > > I think the right response here is to make it more explicit in the > > documentation that putting a ScriptAlias cgi-bin inside document root is > > bad. > > Yes, this is a relatively common configuration error. Although this > does not make it a bug, it does point out that our documentation could > be clearer. Unfortunately, the basic problem is that people see the > ScriptAlias in the default config file and assume that is the only way > to activate cgi scripts, so regardless of what we put in the docs, it > won't help that much. I don't complete agree with you... IMHO the basic "problem" is: The "URL-path" in ScriptAlias (like in Alias and Location) is compared case sensitive first, also on Windows. The "normal" URI to path translation (directory-path) not on Windows. That should be better explained in the manual. Yes, it should be explained that *Alias* are case-sensitive in their first argument. But your diagnosis is not quite correct. URLs are always case sensitive in httpd (and in the HTTP RFC). The fact that multiple different URLs happen to map to the same filesystem location is an artificat of the filesystem, not of the path translation code. httpd does handle case-insensitivity correctly in its filesystem code (such as the block). BTW: ScriptAlias is not complete the same as an "Options ExecCGI". On Windows you can use something like that to avoid the problem: ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/apache/cgi-bin$1" I don't know why you say that Options/SetHandler isn't the same as ScriptAlias. They are identical in all important respects, as far as I know. Your suggestion is not a good one for this problem, because there are other ways to dodge around that regex on many filesystems (multiple slashes, special characters, etc). Those are all handled properly by . (Your suggestion is fine for the general question "How do I make the cgi-bin alias case-insensitive?" but it is not a safe way to use ScriptAlias to put the cgi-bin inside the DocumentRoot.) Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/18/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: > > I don't complete agree with you... IMHO the basic "problem" is: > The "URL-path" in ScriptAlias (like in Alias and Location) is > compared case sensitive first, also on Windows. The "normal" URI to > path translation (directory-path) not on Windows. That should be > better explained in the manual. Yes, it should be explained that *Alias* are case-sensitive in their first argument. Ok. But your diagnosis is not quite correct. URLs are always case sensitive in httpd (and in the HTTP RFC). That's a good point (IMHO they SHOULD, not MUST). But see below... The fact that multiple different URLs happen to map to the same filesystem location is an artificat of the filesystem, not of the path translation code. httpd does handle case-insensitivity correctly in its filesystem code (such as the block). Now an other point of view ;-) Ok, we can see, that httpd makes exactly what the source code says. URI comparison is made case-sensitive. And the last step, mapping the URI to a file system location, depends on the file system. (And we know: URI's are not file system locations, only resources...) But what happens in real life (all steps together)? On *nix: - with a directory "$DOCUMENT_ROOT/foo", the URI /FOO is not the same as /foo - with an alias /foo for a directory "foo" inside DocumentRoot, the URI /FOO is not the same as /foo - with an alias /bar for a directory "bar" outside DocumentRoot, the URI /BAR is not the same as /bar - with an alias /bar for a directory "bar" and a subdir "sub" outside DocumentRoot, the URI /bar/SUB is not the same as /bar/sub Now the same for e.g. Windows: - with a directory "$DOCUMENT_ROOT/foo", the URI /FOO is the same as /foo - with an alias /foo for a directory "foo" inside DocumentRoot, the URI /FOO is the same as /foo, but sometimes with a different behavior - with an alias /bar for a directory "bar" outside DocumentRoot, the URI /BAR is not the same as /bar - with an alias /bar for a directory "bar" and a subdir "sub" outside DocumentRoot, the URI /bar/SUB is the same as /bar/sub (that's really interesting: only parts of the abs_path are case-sensitive) And you think, that's a consistent behavior and according to the RFC 2616 (3.2.3)? Don't forget. That's not really a problem of the file system. Because NTFS for example is not only case-insensitive, it's also case-preserving. Thus httpd should know the real case. You remember this little sentence in the RFC 2616 (15.2)? | If an HTTP server translates HTTP URIs directly into file system calls, | the server MUST take special care not to serve files | that were not intended to be delivered to HTTP clients. > > On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > > > I think the right response here is to make it more explicit in the > > > documentation that putting a ScriptAlias cgi-bin inside document > > > root is bad. > > > > Yes, this is a relatively common configuration error. > > ... > > Instead, you can use: > > > > > >SetHandler cgi-script > >Options ExecCGI > > > > Why is it really bad to have a ScriptAlias inside the DocumentRoot? It's only another file system location. And it's only one line in the config file instead of four. You have only a problem because of the "unexpected" behavior of httpd with case-insensitive/case-preserved file systems ;-) And on Windows, the simplest way to make a consistent behavior with URI's is to have a alias match case-insensitive. BTW: That's not only a problem with Windows. Don't forget the default file system of OS X. HFS+ is also case-insensitive. Regards, Carsten
