Bert, Master had KeepAlive on, replica - KeepAlive Off
On Tue, Jul 2, 2013 at 3:32 PM, Bert Huijben <b...@qqmail.nl> wrote: > Hi Vadym,**** > > ** ** > > We found a related issue while testing the serf http code, which might be > related to your issue.**** > > ** ** > > Can you somehow check if your repository has the ‘KeepAlive’ option > configured to off? In this case the digest code in serf performs every > request without authentication, because it would only try to use > authentication on later requests on the same connection**** > > ** ** > > If that is the case, it looks like this issue will be resolved with the > next serf release. (Which should happen with or before Subversion 1.8.1).* > *** > > ** ** > > Bert**** > > ** ** > > [Added CC to one of the serf developers, who isn’t subscribed to this list] > **** > > ** ** > > *From:* Vadym Chepkov [mailto:vchep...@gmail.com] > *Sent:* maandag 1 juli 2013 18:32 > *To:* Bert Huijben > *Cc:* users@subversion.apache.org; Ryan Schmidt > > *Subject:* Re: svnsync 1.8.0 fails if htdigest authentication is used**** > > ** ** > > Bert,**** > > ** ** > > I would be happy to provide debugging information, but as I said, I had to > rollback to 1.7.10.**** > > ** ** > > If I ran it interactively, authentication just didn't go through, so it > looked like the username or password is incorrect.**** > > After I reverted back to 1.7.10 everything works as expected.**** > > ** ** > > svnsync is called from a hook on the master server :**** > > ** ** > > #!/bin/ksh**** > > REPOS=`basename $1`**** > > TMPFILE=/var/tmp/svnsync.$$**** > > /usr/bin/svnsync sync --non-interactive --quiet \**** > > --sync-username svnsync http://example.com/reposync/${REPOS} > $TMPFILE > 2>&1**** > > if [[ $? -ne 0 && -s $TMPFILE ]] ; then**** > > mail -s "svnsync failed" root < $TMPFILE**** > > fi**** > > rm -f $TMPFILE**** > > exit 0**** > > ** ** > > Slave server is properly initialized:**** > > ** ** > > sudo -u apache svn pg svn:sync-from-url --revprop -r 0 --username > svnsync http://example.com/reposync/repo1**** > > ** ** > > http://example.com/svn/repo1**** > > ** ** > > ** ** > > I was receiving errors like this in e-mail:**** > > ** ** > > svnsync: E175002: Unable to connect to a repository at URL ' > http://example.com/reposync/repo1' > svnsync: E175002: OPTIONS of 'http://example.com/reposync/repo1': could > not connect to server (http://example.com)**** > > ** ** > > or this**** > > ** ** > > svnsync: E175002: PROPFIND of '/reposync/repo2/!svn/rev/0': could not > connect to server (http://example.com)**** > > ** ** > > ** ** > > Regards,**** > > Vadym**** > > ** ** > > ** ** > > On Mon, Jul 1, 2013 at 12:07 PM, Bert Huijben <b...@qqmail.nl> wrote:**** > > > > > -----Original Message----- > > From: Vadym Chepkov [mailto:vchep...@gmail.com] > > Sent: zondag 30 juni 2013 22:58 > > To: Ryan Schmidt > > Cc: users@subversion.apache.org > > Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used > > > > > > On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote: > > > > > > > > On Jun 30, 2013, at 07:06, Vadym Chepkov wrote: > > > > > >> After I upgraded to 1.8.0, svnsync process started to fail. I am using > > apache 2.2.3. I suspect it's really serf's problem (1.2.1), but > nevertheless I had > > to revert back to 1.7.10. Is this a known limitation? > > > > > > You said you upgraded to 1.8.0. Was that the computer running svnsync, > or > > the server serving the original repository, or both? > > > > > > What error message did you get? > > > > > > Both source and destination run under Linux. Authentication fails, I see > 401 in > > the apache's access log. > >**** > > Hi, > > I expected a problem related to some recent fixes in serf that should be > available in the next release, but one of the serf developers ensured me > that it was not this problem. > > <@lgo> Bert: serf 1.2.1 fixed an issue with htdigest, no server > authentication issues are known. > <@lgo> I have no problem syncing a repository on a server using digest > either > <@lgo> that is, from a repository over ra_serf with digest authn to > ra_local. > <@lgo> The thread on users doesn't contain a lot of info, and I'm not > subscribed to users. So if you can get some more info about his setup, > exact > error message, whether that's directly or after a while ... I will look > into > it further. > > So I would repeat Ryan's request. Can you show us what goes wrong (with > what > error) and how we can reproduce this problem? > > It is quite interesting to know if this happens directly at the start or > after a huge chunk of work was completed. > > Bert**** > > ** ** >