Re: AuthUserFile not specified in the configuration
Justin Mrkva wrote on Thu, Apr 03, 2014 at 00:53:41 -0400: > [error] [client ::1] AuthUserFile not specified in the configuration > > Apache runs as _www:_www, and the directory containing the repository as well > as the repos themselves are all _www:_www 755. The htdigest file is _www:_www > 644. The realm for the user matches the httpd.conf AuthName. The password is > correct. Both SVNParentPath and AuthUserFile are the correct paths. > > Here are relevant lines from httpd.conf: > > LoadModule auth_digest_module libexec/apache2/mod_auth_digest.so > LoadModule dav_svn_module /usr/local/libexec/mod_dav_svn.so > LoadModule authz_svn_module /usr/local/libexec/mod_authz_svn.so > > > DAV svn > SVNParentPath /Library/Subversion/Repositories > SVNListParentPath on > > AuthName "Subversion" > AuthType Digest > AuthDigestProvider file > AuthUserFile /private/etc/svnauth.htdigest Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work? (I'm suspecting /private might be unreadable by _www.) Another possibility is that httpd treats GET and OPTIONS requests differently, i.e., that some other part of the config kicks in for the latter but not for the former. > > Require valid-user > Allow from all >
Re: AuthUserFile not specified in the configuration
On Apr 4, 2014, at 04:24, Daniel Shahaf wrote: > Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work? > > (I'm suspecting /private might be unreadable by _www.) On a normal OS X system, /private and /private/etc have rwxr-xr-x permissions.
Re: AuthUserFile not specified in the configuration
Yes, it is readable. I also confirmed the command works.
In the meantime, I’ve tried a few additional things. I found a preinstalled
(but unactivated) module called mod_auth_digest_apple, so I deactivated
mod_auth_digest in favor of the Apple-specific one. There’s one important
difference: the Apple version does _not_ need the AuthUserFile. Instead, it
uses the OS X user database. Oddly, Apache still complains about AuthUserFile,
but it succeeds. I expect it masquerades as mod_auth_digest for compatibility,
so Apache still expects the file to be specified even though it’s not needed.
Before, authentication succeeded in the browser but gave the error and returned
500 for the client. Now, authentication seems to succeed on _both_ the browser
and the client, which is a step in the right direction I guess.
However, there’s a new error on the client instead of a 500:
svn: E175013: Access to 'https://server.example.com/svn/repo' forbidden
This error again only occurs for the client, the browser is still able to
browse repos with no trouble. I confirmed again that all files (such as
/Library/Subversion/svnaccess) are properly readable. Additionally I modified
svnaccess to remove rw permissions, refreshed the browser, and the repos
disappeared from the listing. Reenabling rw for my user or for all users caused
it to appear again, so it is definitely obeying the svnaccess file.
As for the OPTIONS request being treated differently somehow, that is… actually
very possible. I set LogLevel in httpd.conf to debug and watched the error
messages, but I never saw anything that looked suspicious. I’ve pasted the
httpd.conf file at https://gist.github.com/anonymous/d84e4e9721a49789f846 if
someone wants to take a look.
I did try using curl to send GET and OPTIONS requests to the /svn/ path of the
server. GET responded with 200, OPTIONS responded with a 403. So that looks
like the problem. I have no idea how to fix it, though.
A small excerpt of just the SVN relevant sections of httpd.conf:
LoadModule auth_digest_apple_module
${SERVER_INSTALL_PATH_PREFIX}/usr/libexec/apache2/mod_auth_digest_apple.so
LoadModule dav_svn_module /usr/local/libexec/mod_dav_svn.so
LoadModule authz_svn_module /usr/local/libexec/mod_authz_svn.so
Location /svn/>
DAV svn
SVNParentPath /Library/Subversion/Repositories
SVNListParentPath on
AuthName "UserWebDAV Gateway"
AuthType Digest
AuthzSVNAccessFile /Library/Subversion/svnaccess
Require valid-user
Order allow,deny
Allow from all
On Apr 4, 2014, at 6:06 AM, Ryan Schmidt wrote:
>
> On Apr 4, 2014, at 04:24, Daniel Shahaf wrote:
>
>> Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work?
>>
>> (I'm suspecting /private might be unreadable by _www.)
>
> On a normal OS X system, /private and /private/etc have rwxr-xr-x permissions.
>
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
On 03.04.2014 12:47, Philip Martin wrote: > Guido Wischrop writes: > >> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this: >> >> svn checkout https://user:pass@server/svn/p1/trunk >> >> I get the following error immediately: >> >> svn: E17: 'https://user:pass@server/svn/p1/trunk' isn't in the same >> repository as 'https://user:@server/svn/p1/trunk' >> >> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5) >> X64) with the same result. >> >> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command >> works as expected. Is the user:pass@server scheme no longer supported? > I get the same problem with trunk on Linux. I can fix it with this > patch but I'm not sure I understand all the consequences. Is there any > reason we should be hiding the password here? > > Index: subversion/libsvn_ra_serf/options.c > === > --- subversion/libsvn_ra_serf/options.c (revision 1584323) > +++ subversion/libsvn_ra_serf/options.c (working copy) > @@ -245,7 +245,8 @@ > (char *)svn_fspath__canonicalize(val, session->pool); >session->repos_root_str = > svn_urlpath__canonicalize( > -apr_uri_unparse(session->pool, &session->repos_root, 0), > +apr_uri_unparse(session->pool, &session->repos_root, > +APR_URI_UNP_REVEALPASSWORD), > session->pool); > } >else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0) > > So is this considered to be a bug? Is there another workaround as using --user --password? Thanks, Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
> -Original Message- > From: Guido Wischrop [mailto:guido.wisch...@mgm-tp.com] > Sent: vrijdag 4 april 2014 15:07 > To: users@subversion.apache.org; d...@subversion.apache.org > Subject: Re: svn: E17: 'https://user:pass@x' isn't in the same repository > as 'https://user:@x' > > > On 03.04.2014 12:47, Philip Martin wrote: > > Guido Wischrop writes: > > > >> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this: > >> > >> svn checkout https://user:pass@server/svn/p1/trunk > >> > >> I get the following error immediately: > >> > >> svn: E17: 'https://user:pass@server/svn/p1/trunk' isn't in the same > >> repository as 'https://user:@server/svn/p1/trunk' > >> > >> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5) > >> X64) with the same result. > >> > >> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command > >> works as expected. Is the user:pass@server scheme no longer > supported? > > I get the same problem with trunk on Linux. I can fix it with this > > patch but I'm not sure I understand all the consequences. Is there any > > reason we should be hiding the password here? > > > > Index: subversion/libsvn_ra_serf/options.c > > > == > = > > --- subversion/libsvn_ra_serf/options.c (revision 1584323) > > +++ subversion/libsvn_ra_serf/options.c (working copy) > > @@ -245,7 +245,8 @@ > > (char *)svn_fspath__canonicalize(val, session->pool); > >session->repos_root_str = > > svn_urlpath__canonicalize( > > -apr_uri_unparse(session->pool, &session->repos_root, 0), > > +apr_uri_unparse(session->pool, &session->repos_root, > > +APR_URI_UNP_REVEALPASSWORD), > > session->pool); > > } > >else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) > == 0) > > > > > > So is this considered to be a bug? Is there another workaround as using > --user --password? As far as I can tell we only really support a username in the url for svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to the lower layers and the neon library (our <= 1.7 default) completely ignored this, while serf (which we use as default since 1.8) tried to use it as the hostname. I would really recommend not using a username in the url this way... You just store the password unencrypted on your disk in a place where it isn't even really used. It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly different authentication id. And as Subversion doesn't actually use the username and password from the url, they won't be updated if you ever want to change your password (or use the working copy as a different user) Bert > > Thanks, > Guido
Working copy blocking
We are all running the latest TortoiseSVN which is build with svn 1.8.8. Attempting to add files, I got this message (retrying it, the add worked) Command: Add Error: sqlite[S5]: database is locked Error: Additional errors: Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Completed!: This is on a Windows 7 system. The working copy is on the local drive. I'm thinking it is because perhaps we use both Tortoise and Ankhsvn? What can I look at?
Re: Working copy blocking
Hi, On 04/04/14 18:13, Bob Archer wrote: > [TVSN + AnkhSVN on Win7] > Error: sqlite[S5]: database is locked > > Error: Another process is blocking the working copy database, or the > underlying filesystem does not support file locking; if the working copy > is on a network filesystem, make sure file locking has been enabled on > the file server. Check if either client has exclusive locking configured: > https://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking Andreas
RE: Working copy blocking
> On 04/04/14 18:13, Bob Archer wrote: > > [TVSN + AnkhSVN on Win7] > > Error: sqlite[S5]: database is locked > > > > Error: Another process is blocking the working copy database, or the > > underlying filesystem does not support file locking; if the working > > copy is on a network filesystem, make sure file locking has been > > enabled on the file server. > > Check if either client has exclusive locking configured: > > https://subversion.apache.org/docs/release-notes/1.8.html#exclusiveloc > > king > > Andreas Can you remind me where the svn config file is on windows? Tortoise doesn't seem to want to open the file.
Re: Working copy blocking
On Fri, Apr 4, 2014 at 1:51 PM, Bob Archer wrote: > > On 04/04/14 18:13, Bob Archer wrote: > > > [TVSN + AnkhSVN on Win7] > > > Error: sqlite[S5]: database is locked > > > > > > Error: Another process is blocking the working copy database, or the > > > underlying filesystem does not support file locking; if the working > > > copy is on a network filesystem, make sure file locking has been > > > enabled on the file server. > > > > Check if either client has exclusive locking configured: > > > https://subversion.apache.org/docs/release-notes/1.8.html#exclusiveloc > > > king > > > > Andreas > > Can you remind me where the svn config file is on windows? Tortoise > doesn't seem to want to open the file. > Open the Run dialog or the Explorer and type in %APPDATA%\Subversion Windows will resolve that variable to the right location. -- Thanks Mark Phippard http://markphip.blogspot.com/
Subversion 1.8.8 externals error
Hi, Subversion 1.8.8 returns an error when checking out or updating a working copy with the following externals. $ svn proplist -v Properties on '.': svn:externals https://github.com/SenH/sinatra-formkeeper/trunk/lib/sinatra lib/sinatra https://github.com/SenH/formkeeper/trunk/lib/ lib/formkeeper svn:ignore .bundle Gemfile.lock $ svn up Fetching external item into 'lib/sinatra': External at revision 45. Fetching external item into 'lib/formkeeper': External at revision 37. Removed external 'lib': '/var/www/thais-sander/thais-sander.be/lib' is already locked via '/var/www/thais-sander/thais-sander.be'. svn: warning: W20: Error handling externals definition for 'lib': svn: warning: W155004: '/var/www/thais-sander/thais-sander.be/lib' is already locked via '/var/www/thais-sander/thais-sander.be'. Updated to revision 122. svn: E205011: Failure occurred processing one or more externals definitions The working copy doesn't have the 'lib' folder but according to the book: "The relative target subdirectories of externals definitions must not already exist on your or other users' systems Subversion will create them when it checks out the external working copy." This has always worked in 1.6.17. Any pointers?
