Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
writes:
> The status line is not blocked. The debugging message means that we
> have got an header with a null key and with the status line as value:
> in this case the header is not added to the request sent back to the
> client. This seems to be common that some HTTP Implementations return
> such a null key header in the list of headers of a request.
I've never seen Apache send a second status line. Perhaps the message
about null key applies to this mysterious line in the trace:
ch.nevis.session.secroles: auth.strong,idma_Benutzer,infplat_user,esclienttest_r
oleBC,esclienttest_roleA,esclienttest_roleB,depo_Admin,itam_Leser,itam_Administr
ator,itsms_asset_viewer,itsms_svc_req_usr,testsaml_admin,global.allow,acc.idma,a
cc.infplat,acc.esclienttest,acc.depo,acc.itam,acc.itsms,acc.testsaml
I see that every response also has:
Connection: close
This looks as if you do not have KeepAlive enabled on the server, or
perhaps the proxy does not support pipelining. That is going to result
in poor performance for clients that use serf.
All the above is probably irrelevant to the problem.
I've converted your trace into a Python script to implement a server
that behaves like yours. The first, larger, OPTIONS response is a
typical response from a server that supports Subversion's v2 protocol.
The second, smaller, OPTIONS response is the client probing to see if
chunked transfer encoding is upported. All the subsequent PROPFINDS are
v1 protocol and this is where it gets tricky.
Using a standard 1.8 client against this dummy server gives:
$ svn ls http://127.0.0.1:/svn/t_sponis_testrepo
svn: E175009: XML Parsing failed: Unexpected root element 'multistatus'
That's because the client sends v2 requests and the v1 responses do not
match. Now I have a debug client and I can force v1 using
$ SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes svn ls
http://127.0.0.1:/svn/t_sponis_testrepo
branches/
tags/
trunk/
Your client will not have the debug code to do that. How is your client
switching to the v1 protocol? Either your proxy is not forwarding the
SVN-Me-Resource header or your client is patched to ignore v2, which
ever it is your environment is non-standard. How does your client
respond when run against this dummy server? (You must restart the dummy
server after a client fail so that responses match the requests.)
#!/usr/bin/python
import SocketServer
import re
class MyTCPHandler(SocketServer.StreamRequestHandler):
responses = [
('HTTP/1.1 200 OK\r\n'
'SVN-Repository-MergeInfo: yes\r\n'
'SVN-Allow-Bulk-Updates: On\r\n'
'SVN-Rev-Root-Stub: /svn/t_sponis_testrepo/!svn/rvr\r\n'
'Content-Length: 201\r\n'
'SVN-Txn-Root-Stub: /svn/t_sponis_testrepo/!svn/txr\r\n'
'SVN-VTxn-Root-Stub: /svn/t_sponis_testrepo/!svn/vtxr\r\n'
'SVN-Repository-UUID: 0926ec5e-c495-11e3-b81a-bb1aca739395\r\n'
'Connection: close\r\n'
'Server: Apache\r\n'
'DAV: 1,2, version-control,checkout,working-resource, merge,baseline,activity,version-controlled-collection, http://subversion.tigris.org/xmlns/dav/svn/depth, http://subversion.tigris.org/xmlns/dav/svn/log-revprops, http://subversion.tigris.org/xmlns/dav/svn/atomic-revprops, http://subversion.tigris.org/xmlns/dav/svn/partial-replay, http://subversion.tigris.org/xmlns/dav/svn/inherited-props, http://subversion.tigris.org/xmlns/dav/svn/inline-props, http://subversion.tigris.org/xmlns/dav/svn/reverse-file-revs, http://subversion.tigris.org/xmlns/dav/svn/mergeinfo, http://subversion.tigris.org/xmlns/dav/svn/ephemeral-txnprops, http://subversion.tigris.org/xmlns/dav/svn/replay-rev-resource\r\n'
'SVN-VTxn-Stub: /svn/t_sponis_testrepo/!svn/vtxn\r\n'
'SVN-Rev-Stub: /svn/t_sponis_testrepo/!svn/rev\r\n'
'MS-Author-Via: DAV\r\n'
'SVN-Me-Resource: /svn/t_sponis_testrepo/!svn/me\r\n'
'Date: Tue, 06 Jan 2015 14:43:25 GMT\r\n'
'SVN-Txn-Stub: /svn/t_sponis_testrepo/!svn/txn\r\n'
'Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,LOCK,UNLOCK,CHECKOUT\r\n'
'SVN-Repository-Root: /svn/t_sponis_testrepo\r\n'
'SVN-Supported-Posts: create-txn, create-txn-with-props\r\n'
'Content-Type: text/xml; charset="utf-8\r\n'
'SVN-Youngest-Rev: 16\r\n'
'\r\n'
'\n'
'\n'
'/svn/t_sponis_testrepo/!svn/act/\n'
),
('HTTP/1.1 200 OK\r\n'
'DAV: 1,2, version-control,checkout,working-resource, merge,baseline,activity,version-controlled-collection, http://subversion.tigris.org/xmlns/dav/svn/depth, http://subversion.tigris.org/xmlns/dav/svn/log-revprops, http://subversion.tigris.org/xmlns/dav/svn/atomic-revprops, http://subversion.tigris.org/xmlns/dav/svn/partial-replay, http://subversion.tigris.org/xmlns/dav/svn/inherited-props, http://subversion.tigris.org/xmlns/dav/svn/inline-props, http://subversion.tigris.org/xmlns/dav/svn/reverse-file-revs, http://subversion.tigris.org/xmlns/dav/svn/mergeinfo\r\n'
'MS-Author-Via: DAV\r\n'
'Date: Tue, 06 Jan 2015 14:43:
Re: Authentication Questions
jt.mil...@l-3com.com writes: > I guess there's no caching of credentials since the path-based > authentication file can change at any time? I'm not clear what you mean by "caching of credentials". Subversion typically sends multiple HTTP requests over a single connection. Each HTTP request has its own authn credentials and caching those would not make sense, although Apache may cache any data used to validate the credentials. Subversion's authz file is parsed when first needed and cached for use by any subsequent HTTP requests on the same connection. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Roadmap update
> Any chance the Roadmap can be updated since Q2 2014 has come and gone? > I'm sure there's been some functions completed, or nearly complete, > even if 1.9.0 is not ready for production. I would also be interested to know the status of the roadmap. David
RE: Authentication Questions
Thanks Philip, what you explained for the authz/authn caching makes sense. We recently performed a major upgrade of our IT infrastructure and I took the opportunity to upgrade our very old Subversion configuration (old physical server with Apache 2.2/SVN 1.4 to virtual server with 2.4/1.8). We have had some pretty significant latency issues (due to my ignorance of a proper configuration). I was searching for performance bottlenecks and was (unduly) concerned by what I saw in the logs with debug enabled. Mostly I wanted to verify that the traffic pattern I showed was typical, and it doesn't sound like it's anything out of the ordinary. I think the culprit for us was the default AcceptFilter directive. Changing this to AcceptFilter http none seems to have cleared up all the latency issues. Thanks again for your explanation. -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: Thursday, January 08, 2015 9:17 AM To: Miller, JT @ SSG - PE - MT Cc: users@subversion.apache.org Subject: Re: Authentication Questions jt.mil...@l-3com.com writes: > I guess there's no caching of credentials since the path-based > authentication file can change at any time? I'm not clear what you mean by "caching of credentials". Subversion typically sends multiple HTTP requests over a single connection. Each HTTP request has its own authn credentials and caching those would not make sense, although Apache may cache any data used to validate the credentials. Subversion's authz file is parsed when first needed and cached for use by any subsequent HTTP requests on the same connection. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
Philip Martin writes: > I've converted your trace into a Python script to implement a server > that behaves like yours. I may have reproduced the problem. If I remove the 'Connection: close' headers and continue to force v1 I can get the client to crash using the dummy server. I suppose that means the proxy is keeping the connection to the client open and not forwarding the 'Connection: close'. (There may still a performance hit if the proxy needs to keep reopening a connection to the server.) A socat/netcat/wireshark trace between the client and proxy would help as it would show exactly what the proxy is sending to the client. valgrind shows memory use after free: ==9909== Invalid read of size 4 ==9909==at 0x6509DA5: serf_bucket_mem_alloc (allocator.c:172) ==9909==by 0x650A048: serf_bucket_barrier_create (barrier_buckets.c:33) ==9909==by 0x5239857: accept_response (util.c:574) ==9909==by 0x6507DBA: read_from_connection (outgoing.c:1120) ==9909==by 0x650800C: serf__process_connection (outgoing.c:1247) ==9909==by 0x6505B0A: serf_event_trigger (context.c:226) ==9909==by 0x6505C8D: serf_context_run (context.c:300) ==9909==by 0x5239F78: svn_ra_serf__context_run (util.c:859) ==9909==by 0x523A1D5: svn_ra_serf__context_run_wait (util.c:930) ==9909==by 0x523A297: svn_ra_serf__context_run_one (util.c:954) ==9909==by 0x522AC8E: svn_ra_serf__wait_for_props (property.c:653) ==9909==by 0x522AD92: svn_ra_serf__retrieve_props (property.c:681) ==9909== Address 0x8e8ea38 is 40 bytes inside a block of size 72 free'd ==9909==at 0x402AF4C: free (vg_replace_malloc.c:468) ==9909==by 0x4BB51F9: pool_clear_debug (apr_pools.c:1576) ==9909==by 0x4BB534D: pool_destroy_debug (apr_pools.c:1638) ==9909==by 0x4BB5436: apr_pool_destroy_debug (apr_pools.c:1680) ==9909==by 0x6506E4B: destroy_request (outgoing.c:502) ==9909==by 0x6507EE0: read_from_connection (outgoing.c:1186) ==9909==by 0x650800C: serf__process_connection (outgoing.c:1247) ==9909==by 0x6505B0A: serf_event_trigger (context.c:226) ==9909==by 0x6505C8D: serf_context_run (context.c:300) ==9909==by 0x5239F78: svn_ra_serf__context_run (util.c:859) ==9909==by 0x523A1D5: svn_ra_serf__context_run_wait (util.c:930) ==9909==by 0x523A297: svn_ra_serf__context_run_one (util.c:954) I can't reproduce this against a standard server. And I still don't know how your client is switching to v1, perhaps the proxy is also stripping the SVN-Me-Resource. Do you know exactly which version of Subversion is running on the server? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
Philip Martin writes: > I can't reproduce this against a standard server. I think I have worked it out. There was an error in my script: one of the XML response lines was missing a '\n' and this originally caused the client to report the HTTP response as too short, so I "fixed" it by added a trailing '\n'. When creating the next response in the script I copied the trailing '\n' but I didn't omit the earlier '\n'. The result is an HTTP response that is one byte too long. The dummy server was first sending 'Content-Length: 425' and then sending 426 bytes. This spurious extra byte causes serf to crash when it reads the extra data without a proper handler in place. What we need is an exact trace of every byte sent by your proxy to the client so we can check whether it is also sending an extra byte. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: mod_dav_svn.so does no more support lock functions
Thank you Dave, I have tried with the binaries compiled from Apache Haus and it works fine. I'm also using the mod_authnz_sspi.so extension from my friend Ennio. First I tried the 64bits binaries but it failed, said it was not a valid win32 application ! Finally I decided to use the 32bits binaries that are working fine. I hope my case will help. My configuration : Windows server 2012 + httpd-2.4.10-x86-vc11-r2.zip + mod_authnz_sspi-0.1.0a1-2.4.x-x86-r2.zip + mod_svn-1.8.10-ap24-x86.zip >> Not the official for sure but the most common download site >> >> http://sourceforge.net/projects/wampserver/ >> >> http://sourceforge.net/projects/win32svn/ > >http://www.wampserver.com/en/ says "Once WampServer is installed, you >can manually add aditionals Apache, Php or MySql (only VC9, VC10 and >VC11 compiled) versions." I think that means addon modules must be >compiled with VC9, 10, or 11. http://sourceforge.net/projects/win32svn/ >says that the SVN modules are build with VC++ 6.0. > >I think you need to get binaries of Apache and SVN that have been >compiled with compatible compilers. I'm using the >http://www.apachehaus.com/ binaries, and they're working well. > > >Name: Dave Huang | Mammal, mammal / their names are called / >INet: k...@azeotrope.org | they raise a paw / the bat, the cat / >FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG >Dahan: Hani G Y+C 39 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
svn forbidden error
Hey all, I've configured subversion 1.8.10 from source with the serf configuration option. Everything seemed to go smoothly. But when I try to do a checkout from my repository I get this error: [root@aozmpwslp004la ~]# svn co http://$(hostname -i)/svn/localmedia/applications/elections svn: E175013: Unable to connect to a repository at URL ' http://xx.xx.xx.xx/svn/localmedia/applications/elections' svn: E175013: Access to '/svn/localmedia/applications/elections' forbidden In my apache configuration I have the following entry: Options +Indexes AllowOverride All Order allow,deny Allow From all AuthType Basic AuthName "Web SVN Browser" AuthUserFile /var/www/svn/svn-auth-file AuthzSVNAccessFile /var/www/svn/accessfile Require valid-user Alias /svn /var/www/svn And this is what I'm seeing in the apache error logs: [Thu Jan 08 15:47:27 2015] [error] [client xx.xx.xx.xx] client denied by server configuration: /var/www/svn/localmedia/applications Can I get some advice on how I can get past this error? Thanks Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
Re: svn forbidden error
On 08.01.2015 21:50, Tim Dunphy wrote: > Hey all, > > I've configured subversion 1.8.10 from source with the serf > configuration option. > > Everything seemed to go smoothly. But when I try to do a checkout > from my repository I get this error: > > [root@aozmpwslp004la ~]# svn co http://$(hostname > -i)/svn/localmedia/applications/elections > svn: E175013: Unable to connect to a repository at URL > 'http://xx.xx.xx.xx/svn/localmedia/applications/elections' > svn: E175013: Access to '/svn/localmedia/applications/elections' forbidden > > > In my apache configuration I have the following entry: > > >Options +Indexes >AllowOverride All >Order allow,deny >Allow From all >AuthType Basic >AuthName "Web SVN Browser" >AuthUserFile /var/www/svn/svn-auth-file >AuthzSVNAccessFile /var/www/svn/accessfile >Require valid-user > > > Alias /svn /var/www/svn > > And this is what I'm seeing in the apache error logs: > > [Thu Jan 08 15:47:27 2015] [error] [client xx.xx.xx.xx] client denied > by server configuration: /var/www/svn/localmedia/applications > > Can I get some advice on how I can get past this error? The user as which the httpd process is running must have read and write access to the physical files and directories in the repository. -- Brane
Re: svn forbidden error
It was actually a Location directive I. Apache. I had to do an Allow from IP address in that block in order to solve the problem. Thanks for you reply Tim Sent from my iPhone > On Jan 8, 2015, at 7:45 PM, Branko Čibej wrote: > >> On 08.01.2015 21:50, Tim Dunphy wrote: >> Hey all, >> >> I've configured subversion 1.8.10 from source with the serf >> configuration option. >> >> Everything seemed to go smoothly. But when I try to do a checkout >> from my repository I get this error: >> >> [root@aozmpwslp004la ~]# svn co http://$(hostname >> -i)/svn/localmedia/applications/elections >> svn: E175013: Unable to connect to a repository at URL >> 'http://xx.xx.xx.xx/svn/localmedia/applications/elections' >> svn: E175013: Access to '/svn/localmedia/applications/elections' forbidden >> >> >> In my apache configuration I have the following entry: >> >> >> Options +Indexes >> AllowOverride All >> Order allow,deny >> Allow From all >> AuthType Basic >> AuthName "Web SVN Browser" >> AuthUserFile /var/www/svn/svn-auth-file >> AuthzSVNAccessFile /var/www/svn/accessfile >> Require valid-user >> >> >> Alias /svn /var/www/svn >> >> And this is what I'm seeing in the apache error logs: >> >> [Thu Jan 08 15:47:27 2015] [error] [client xx.xx.xx.xx] client denied >> by server configuration: /var/www/svn/localmedia/applications >> >> Can I get some advice on how I can get past this error? > > The user as which the httpd process is running must have read and write > access to the physical files and directories in the repository. > > -- Brane >
AW: AW: AW: AW: Segmentation Fault with SVN Client related to serf
> -Ursprüngliche Nachricht- > Von: Philip Martin [mailto:philip.mar...@wandisco.com] > Gesendet: Donnerstag, 8. Januar 2015 14:34 > An: Viret Pierre, PF54 > Cc: users@subversion.apache.org > Betreff: Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf > [...] > > I've never seen Apache send a second status line. Perhaps the message about > null > key applies to this mysterious line in the trace: > I suppose that this is some specifical java implementation. I simply get a header with key null and value = status line when I get the list of headers from the HttpsURLConnection from java, and I do not include it in the headers sent back to the client. See ... > ch.nevis.session.secroles: > auth.strong,idma_Benutzer,infplat_user,esclienttest_r > oleBC,esclienttest_roleA,esclienttest_roleB,depo_Admin,itam_Leser,itam_Administ > r > ator,itsms_asset_viewer,itsms_svc_req_usr,testsaml_admin,global.allow,acc.idma, > a > cc.infplat,acc.esclienttest,acc.depo,acc.itam,acc.itsms,acc.testsaml > This header is added by the EntryServer and contains the set of roles of the user, but our HttpProxy does not use it. > I see that every response also has: > > Connection: close > > This looks as if you do not have KeepAlive enabled on the server, or perhaps > the > proxy does not support pipelining. That is going to result in poor > performance for > clients that use serf. > I'm not sure what you mean with "pipelining". I would expect that we have KeepAlive enabled but I should check this. > Using a standard 1.8 client against this dummy server gives: > > $ svn ls http://127.0.0.1:/svn/t_sponis_testrepo > svn: E175009: XML Parsing failed: Unexpected root element 'multistatus' > [...] > Your client will not have the debug code to do that. How is your client > switching to > the v1 protocol? Either your proxy is not forwarding the SVN-Me-Resource > header > or your client is patched to ignore v2, which ever it is your environment is > non- > standard. How does your client respond when run against this dummy server? > (You must restart the dummy server after a client fail so that responses > match the > requests.) I got exactly the same result using your dummy server with my client. I have captured the http traffic, you will find it in the attachment crash_http_capture.pcap. The debugging output of the HttpProxy is in the attachment crash_http.txt, it differs from the output when using https. I had to switch from https to http for this. Please note that the crash occurs not exactly at the same time with http, and that we get the segmentation fault each time we run "ls" and not 30% of the time like with https: this could be an interesting point for the analyze. The subversion server version we use is 1.8.10. Regards, Pierre Remarque concernant la sécurité: Ce courriel provenant de PostFinance est signé. Vous trouverez d'autres informations à ce sujet sous: https://www.postfinance.ch/e-signature. Ne divulguez jamais vos éléments de sécurité à des tiers.2015-01-09 07:18:59,922 DEBUG HttpProxy - Listening on http://127.0.0.1:7771 2015-01-09 07:19:12,155 DEBUG ProxyHttpHandler - >OPTIONS /svn/t_sponis_testrepo HTTP/1.1 2015-01-09 07:19:12,155 DEBUG ProxyHttpHandler - Opening connection to URL: https://tpfesa101.pnet.ch:443/svn/t_sponis_t estrepo 2015-01-09 07:19:12,157 TRACE DAVHttpsURLConnection - Creating for https://tpfesa101.pnet.ch:443/svn/t_sponis_testrepo 2015-01-09 07:19:12,157 DEBUG DAVHttpsURLConnection - setRequestMethod(OPTIONS) 2015-01-09 07:19:12,160 TRACE DAVHttpsURLConnection - getRequestMethod() returning GET 2015-01-09 07:19:12,160 DEBUG DAVHttpsURLConnection - replace method value 'GET' in internal delegate with new value 'OP TIONS' 2015-01-09 07:19:12,160 TRACE DAVHttpsURLConnection - getRequestMethod() returning OPTIONS 2015-01-09 07:19:12,162 DEBUG ProxyHttpHandler - Size of request headers: 7 2015-01-09 07:19:12,162 DEBUG ProxyHttpHandler - >Content-type: text/xml 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >Host: 127.0.0.1:7771 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >Accept-encoding: gzip 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >Content-length: 131 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >Dav: http://subversion.tigris.org/xmlns/dav/svn/depth,http://subve rsion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >Connection: keep-alive 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - >User-agent: SVN/1.8.11-SlikSvn-1.8.11-X64 (x64-microsoft-windows) serf/1.3.8 2015-01-09 07:19:12,165 DEBUG ProxyHttpHandler - Connecting to server... 2015-01-09 07:19:12,165 TRACE DAVHttpsURLConnection - connect() 2015-01-09 07:19:12,165 DEBUG SslSocketFactory - Creating an unconnected SSLSocket() 2015-01-09 07:19:12,225 TRACE DAVHttpsURLConnection - getRequestMethod() returning OPTIONS 2015-01-09 07:19
