Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Andrew, I think it's a problem in the 1.8 client. I tested doing the merge with the same branch using a 1.6 SVN client for the checkout and the merge and it did not encounter any issues or complain about missing revisions. This leads me to believe that it is a bug and not just a presentation issue. It is preventing the merge from working in the way described in the manual and we have both encountered the same issue so I think I will raise this issue in the bug tracker. I checked to see is there anything in there already but I could not find anything relevant. Thanks, Stefan On 13/09/2013 21:16, Andrew Reedick andrew.reed...@cbeyond.net wrote: -Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 3:53 PM To: Andrew Reedick; users@subversion.apache.org Subject: Re: SVN merge attempting to reintegrate on a merge to a branch Hi Andrew, Thanks for your response. You are right, I hadn't noticed but on the first line about the missing ranges the last letter of the project name is missing and I had just pasted over it when I sanitized the path names. I got around this as you suggested by using the -r 4401:HEAD option but this is becoming a recurring problem for us lately. We prefer to merge the trunk project to the branch in preparation of reintegrating the branch to trunk but we seem to hit this issue quite a bit lately. Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml It's either a harmless presentation error, or the missing char implies a malformed pathname that is possibly mucking up the merge analysis?
Re: SVN merge attempting to reintegrate on a merge to a branch
On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote: -Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml It's either a harmless presentation error, or the missing char implies a malformed pathname that is possibly mucking up the merge analysis? Hi Andrew, did you have time to answer Ivan's questions from this post? http://svn.haxx.se/users/archive-2013-09/0142.shtml Knowing where the mergeinfo corruption starts occurring would help us greatly with hunting down the issue. Does the corruption happen also if you use file:// URLs on the server during checkout/merge, instead of http:// ?
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan, I just saw your message so I won't post to the dev list just yet. These are the details I was going to post: --START-- We are using Apache 1.8.0 clients, CollabNet Subversion native binaries 1.8.1 (and CollabNet Subversion Edge 4.0.1). I am working on OSX 10.8.4 and I am using the apache source compiled with the following instructions: http://samoldak.com/updating-to-svn-1-8-for-mac-os-x-10-8/ (this uses serf). We have found the same issue on a packaged version of the svn 1.8 client from Wandisco. The issue we encountered is that SVN is trying to do a reintegrate when attempting to merge a trunk project to a branch of that same project and it (incorrectly) complains about missing revisions and some paths in the error message are truncated. Our setup is a fairly straightforward configuration, we have trunk projects in $SVNROOT/svn/trunk/projectname and branches in $SVNROOT/svn/branches/projectname/features/branchname so for example if we have a project called my_project and branch of this project called my_project_branch, they would be in the repository in the following paths $SVNROOT/trunk/my_project and $SVNROOT/branches/my_project/features/my_project_branch. The $SVNROOT is just a variable we use that corresponds the repository URL e.g. https://our.svn.servername/svn. Recently when we attempted to merge a trunk project to a branch (in preparation of doing a merge of the branch back to trunk) we are got errors like the following: $ svn merge ^/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4579 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_bran ch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_projec:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 I was not expecting this error because we had previously merged the trunk project to the branch and merged the branch back down to trunk successfully so as far as I'm aware there should be no missing revisions. Also I am surprised that a reintegrate merge is being attempted when trying to merge from the trunk project to the branch project because, as I understand it, the reintegrate should only happen when merging content from a branch to a project that the branch was created from. As if you looking at the first line missing ranges section it has truncated the last letter of the path. I have run the svn merginfo command which gave the following output: $ svn mergeinfo ^/trunk/my_project . youngest common ancestor | last full merge | |tip of branch | || repository path 4400 4579 | | ---| | trunk/my_project \ / \/ --| | branches/my_project/features/my_project_branch || 4531 4579 And when I do the svn merge info on trunk I get the following: $ svn mergeinfo ^/branches/my_project/features/my_project_branch ^/trunk/my_project youngest common ancestor | last full merge | |tip of branch | || repository path 4400 4531 4579 | || --| | branches/my_project/features/my_project_branch /\ / \ ---| | trunk/my_project | 4579 I tried to do the same merge using an SVN 1.6 client (to checkout and merge) and the merge worked as expected so I suspect that this a client bug. Could you please help to diagnose this issue? Please let me know if any further information is required? Unfortunately I have not be able to come with a deterministic set of steps to reproduce the issue. I have had to work around the issue by using the r option to svn merge e.g. svn r4400:HEAD ^/trunk/my_project . --END-- I'm not sure I understand what you mean by Does the corruption happen also if you use file:// URLs on the server during checkout/merge, instead of http:// ?. Our SVN server is remote to our development machine so the only way I do the merge is using a URL with http:// into a local working copy (WC) so that I can resolve in the WC any conflicts before committing. Could explain a bit more what you mean by this so I can send on some more information? Many Thanks, Stefan On 16/09/2013 10:34, Stefan Sperling s...@elego.de wrote: On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote: -Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago:
Re: SVN merge attempting to reintegrate on a merge to a branch
On Mon, Sep 16, 2013 at 10:03:36AM +, Goor, Stefan wrote: I'm not sure I understand what you mean by Does the corruption happen also if you use file:// URLs on the server during checkout/merge, instead of http:// ?. Our SVN server is remote to our development machine so the only way I do the merge is using a URL with http:// into a local working copy (WC) so that I can resolve in the WC any conflicts before committing. Could explain a bit more what you mean by this so I can send on some more information? We want to know why you are seeing: Missing ranges: /trunk/my_projec:4485 which lacks a trailing 't' in the path name. That's the only obviously wrong thing in your problem report. Now, to figure out where this 't' is snipped off, we want you to give us information that narrows down the circumstances of the problem. We'd like to see: - Output of 'svn propget svn:mergeinfo ^/trunk/my_project' - Output of 'svn propget svn:mergeinfo ^/branches/my_project' The above two commands are using URLs, they return server-side information. - Output of 'svn propget svn:mergeinfo working_copy_of_trunk_my_project' - Output of 'svn propget svn:mergeinfo working_copy_of_branches_my_project' The above two commands are using working copy paths, they return client-side information. Any difference (or non-difference) between these outputs will help us narrow down which layer of the system is introducing mergeinfo which lacks the trailing character of the pathname. Based on that information we can determine further diagnostics. If you could try the merge on the server itself, using a file:// URL to access the repository, we can tell whether the issue happens only if HTTP is involved. This is an important test since the HTTP layer in Subversion 1.8 is very from Subversion 1.7, see http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted For information about what file:// URLs are and how to use them, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls If you don't have command shell access to the Subversion server, performing this test requires help from your server administrators.
Re: SVN merge attempting to reintegrate on a merge to a branch
On Mon, Sep 16, 2013 at 11:31:09AM +, Goor, Stefan wrote: Hi Stefan, Thanks for your email. The out put of those commands is below: [...] Assuming the output was sanitised correctly, it looks ok. I tried to run the checkout on the server using the file:// protocol but it won't allow me to use it as I got the following error: C:\Users\Administrator C:\csvn\bin\svn co file://C:/csvn/data/repositories/REPO svn: E180001: Unable to connect to a repository at URL 'file://C:/csvn/data/repositories/REPO You need 3 leading slashes. Two for the protocol prefix, plus one for the root directory to create an absolute path in the URL. So try this: file:///C:/csvn/data/repositories/REPO
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan, On 16/09/2013 12:41, Stefan Sperling s...@elego.de wrote: On Mon, Sep 16, 2013 at 11:31:09AM +, Goor, Stefan wrote: Hi Stefan, Thanks for your email. The out put of those commands is below: [...] Assuming the output was sanitised correctly, it looks ok. Yes I sanitised the project names but I diffed the output and the local and remote command responses were identical. I tried to run the checkout on the server using the file:// protocol but it won't allow me to use it as I got the following error: C:\Users\Administrator C:\csvn\bin\svn co file://C:/csvn/data/repositories/REPO svn: E180001: Unable to connect to a repository at URL 'file://C:/csvn/data/repositories/REPO You need 3 leading slashes. Two for the protocol prefix, plus one for the root directory to create an absolute path in the URL. So try this: file:///C:/csvn/data/repositories/REPO Sorry for that, I should have spotted the missing slash! The local merge gave the same result: C:\Users\Administrator\my_project_branchC:\csvn\bin\svn merge file:///C:/csvn/data/r epositories/REPO/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4587 were p reviously merged from file:///C:/csvn/data/repositories/REPO/branches/my_project/f eatures/my_project_branch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_projec:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-453 3 Please let me know if I can post any further information to help identify the issue. Many Thanks, Stefan
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan, In your earlier email you mentioned: We want to know why you are seeing: Missing ranges: /trunk/my_projec:4485 which lacks a trailing 't' in the path name. That's the only obviously wrong thing in your problem report. I think the fact the error related to doing a reintegrate merge is also wrong. Given that the merge was from a trunk project (that the branch was created from) to the the branch, should it not have been attempting a regular merge? It is my understanding that a reintegrate merge is done (automatically since 1.8) when bringing a branch back into the project it was created from. Many Thanks, Stefan
the question of create a version of the library that contains chinese
Hi，I want to know if SVN (be installed on Redhat linux 5.3) support to create a version of the library that contains chinese ? I have installed ths svn via the order below, yum install httpd httpd-devel subversion mod_dav_svn. Finally I have try to visit the library address via IE, and displayed below: m:human-readable errcode=2 Could not open the requested SVN filesystem /m:human-readable And I am sure the englise version library is absolutely correct. I'm looking forward to your early reply. Thanks a lot. lsl6631
Re: the question of create a version of the library that contains chinese
On Mon, Sep 16, 2013 at 9:38 AM, lsl6631 lsl6...@163.com wrote: Hi，I want to know if SVN (be installed on Redhat linux 5.3) support to create a version of the library that contains chinese ? I have installed ths svn via the order below, yum install httpd httpd-devel subversion mod_dav_svn. Finally I have try to visit the library address via IE, and displayed below: m:human-readable errcode=2 Could not open the requested SVN filesystem /m:human-readable And I am sure the englise version library is absolutely correct. I'm looking forward to your early reply. Thanks a lot. What does your Apache error log indicate? Are you certain that you've configured Apache to point to the correct directory for your repository (taking into account SVNPath/SVNParentPath)?
Re: SVN merge attempting to reintegrate on a merge to a branch
On Mon, Sep 16, 2013 at 11:51:30AM +, Goor, Stefan wrote:
Sorry for that, I should have spotted the missing slash! The local merge
gave the same result:
C:\Users\Administrator\my_project_branchC:\csvn\bin\svn merge
file:///C:/csvn/data/r
epositories/REPO/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4587
were p
reviously merged from
file:///C:/csvn/data/repositories/REPO/branches/my_project/f
eatures/my_project_branch to the reintegrate source, but this is not the
case:
trunk/my_project
Missing ranges: /trunk/my_projec:4485
Missing ranges:
/trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-453
3
Please let me know if I can post any further information to help identify
the issue.
Thanks!
Bert Huijben pointed out to me a way to reproduce this problem
with the svn.apache.org repository. Using his reproduction recipe
I could spot the problem and fix it: http://svn.apache.org/r1523666
This wasn't a cosmetic issue, but caused actual mis-detection of
missing ranges. Whether or not that patch fixes your merge problem
remains to be seen -- it all depends on your merge history. However,
with the above fix (patch below) the obvious corrupted path issue
should disappear.
Can you try this patch?
Index: subversion/libsvn_client/merge.c
===
--- subversion/libsvn_client/merge.c(revision 1523568)
+++ subversion/libsvn_client/merge.c(working copy)
@@ -10715,7 +10715,7 @@ log_find_operative_revs(void *baton,
suffix = svn_relpath_skip_ancestor(subtree_missing_this_rev,
source_rel_path);
- if (suffix)
+ if (suffix suffix[0] != '\0')
{
missing_path = apr_pstrmemdup(pool, path,
strlen(path) - strlen(suffix) - 1);
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan, That makes sense, my understand of the process was a bit off but I see what you mean. I'm currently looking to test the fix you sent for the client. I will respond as soon as I have tested it. Many Thanks for your help, Stefan On 16/09/2013 15:33, Stefan Sperling s...@elego.de wrote: On Mon, Sep 16, 2013 at 12:06:46PM +, Goor, Stefan wrote: I think the fact the error related to doing a reintegrate merge is also wrong. Given that the merge was from a trunk project (that the branch was created from) to the the branch, should it not have been attempting a regular merge? It is my understanding that a reintegrate merge is done (automatically since 1.8) when bringing a branch back into the project it was created from. It's a little more complex than that. There is no reason to be surprised if the new 'complete merge' in Subversion 1.8 attempts to reintegrate the trunk into a branch. Whether a sync or reintegrate merge is performed depends on prior merge history. A reintegrate merge is performed whenever a merge's direction differs from the direction of the previous merge. A sync merge is performed whenever the merge direction stays the same. A simple example: Create branch B from trunk. Merges performed, in sequence: Merge type selected by SVN: Merge from trunk to B sync merge Merge from B to trunk reintegrate merge Merge from B to trunk sync merge Merge from B to trunk sync merge Merge from B to trunk sync merge Merge from trunk to B reintegrate merge Merge from trunk to B sync merge Merge from trunk to B sync merge Merge from B to trunk reintegrate merge Merge from B to trunk sync merge Can you see the pattern?
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan,
I tried the fix below and it solved the issue of the truncated path in the
missing ranges section:
$ svn merge ^/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4598
were previously merged from
https://our.svn.servername/REPO/branches/my_project/features/my_project_bra
nch to the reintegrate source, but this is not the case:
trunk/my_project
Missing ranges:
/trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4534,4538,4582
However, I still don't understand why the branch thinks it's missing these
revisions. I tried to manually merge these revisions into the trunk
project but none of the revisions had any effect on the working copy of
the trunk project. There were no changes or svn:mergeinfo property
changes because these revision were previously seen in a merge we did a
little while ago:
$ svn merge -r4407:4408 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4408 into '.':
U .
$ svn merge -c4431 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4431 into '.':
U .
$ svn merge -r4442: ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4443 through r into '.':
U .
$ svn merge -c4485 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4485 into '.':
U .
$ svn merge -c4524 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4524 into '.':
U .
$ svn merge -r4532:4534 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4533 through r4534 into '.':
U .
$ svn merge -c4538 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4538 into '.':
U .
$ svn merge -c4582 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4582 into '.':
U .
$ svn stat
$
$ svn pg svn:mergeinfo . | grep my_project_branch
/branches/my_project/features/my_project_branch:4401-4590
$ cd $BRANCH_PROJECT_PATH
$ svn pg svn:mergeinfo . | grep \/trunk\/my_project
/trunk/my_project:4401-4587
Is there anyway for us to identify what is wrong? We have seen this issue
on a few branch recently and we would like to avoid / correct the issue if
possible. Would the above truncated path issue have caused this issues
also? If we patch our SVN client and recreate a new branch for this
feature do you think that would avoid these problems in the future?
Could we have done something wrong with a merge to produce this? We tend
to use a simple enough merging and branching proceedure and it had worked
fine until recently so I'd like to figure out if we need to change the way
we are doing things.
Many Thanks for all your help,
Stefan
On 16/09/2013 15:26, Stefan Sperling s...@elego.de wrote:
On Mon, Sep 16, 2013 at 11:51:30AM +, Goor, Stefan wrote:
Sorry for that, I should have spotted the missing slash! The local
merge
gave the same result:
C:\Users\Administrator\my_project_branchC:\csvn\bin\svn merge
file:///C:/csvn/data/r
epositories/REPO/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through
4587
were p
reviously merged from
file:///C:/csvn/data/repositories/REPO/branches/my_project/f
eatures/my_project_branch to the reintegrate source, but this is not the
case:
trunk/my_project
Missing ranges: /trunk/my_projec:4485
Missing ranges:
/trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-453
3
Please let me know if I can post any further information to help
identify
the issue.
Thanks!
Bert Huijben pointed out to me a way to reproduce this problem
with the svn.apache.org repository. Using his reproduction recipe
I could spot the problem and fix it: http://svn.apache.org/r1523666
This wasn't a cosmetic issue, but caused actual mis-detection of
missing ranges. Whether or not that patch fixes your merge problem
remains to be seen -- it all depends on your merge history. However,
with the above fix (patch below) the obvious corrupted path issue
should disappear.
Can you try this patch?
Index: subversion/libsvn_client/merge.c
===
--- subversion/libsvn_client/merge.c (revision 1523568)
+++ subversion/libsvn_client/merge.c (working copy)
@@ -10715,7 +10715,7 @@ log_find_operative_revs(void *baton,
suffix = svn_relpath_skip_ancestor(subtree_missing_this_rev,
source_rel_path);
- if (suffix)
+ if (suffix suffix[0] != '\0')
{
missing_path = apr_pstrmemdup(pool, path,
strlen(path) -
strlen(suffix) - 1);
RE: Push ?
Guten Tag Dan White, am Sonntag, 15. September 2013 um 17:32 schrieben Sie: Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination. How is rsync more secure than accessing the client using SSH and use svn update? SSH has some options to limit access and possibilities. For example ForceCommand sounds interesting: http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for- port-forwarding I was hoping to find a one-step solution rather than a two step. How about polling on the client? Issueing a svn update every some seconds shouldn't hurt client and server much. This is what CI servers do... Cruise Control, Team City, Jenkins, etc. BOb
Re:Re: the question of create a version of the library that contains chinese
Thanks very much for your early reply. The infomations of The Apahce error log(/var/log/httpd/error_log) is as follows, [Mon Sep 16 08:21:26 2013] [error] [client 192.168.232.1] (20014)Internal error: Can't convert string from 'UTF-8' to native encoding: [Mon Sep 16 08:21:26 2013] [error] [client 192.168.232.1] Could not fetch resource information. [500, #0] [Mon Sep 16 08:21:26 2013] [error] [client 192.168.232.1] Could not open the requested SVN filesystem [500, #22] [Mon Sep 16 08:21:26 2013] [error] [client 192.168.232.1] Could not open the requested SVN filesystem [500, #22] Detailed Configuration as follow， /etc/httpd/conf/httpd.conf: lt;Location /svn/gt; DAV svn SVNListParentPath on SVNParentPath /opt/svn/repo/ AuthzSVNAccessFile /opt/svn/repo/authz.conf AuthType Basic AuthName Subversion.zoneyump AuthUserFile /opt/svn/repo/authfile Require valid-user lt;/Locationgt; the directory/opt/svn/repo/ contains 2 Repositories as follows: [root@localhost repo]# cd /opt/svn/repo [root@localhost repo]# ls -l total 40 drwxrwxrwx 6 apache apache 4096 Sep 13 04:30 520项目 -rwxrwxrwx 1 apache apache 39 Sep 15 09:13 authfile -rwxrwxrwx 1 apache apache 249 Sep 15 09:21 authz.conf drwxrwxrwx 6 apache apache 4096 Sep 15 08:34 test01 the one that the name contains chinese Characters(520项目) can't work, another one that the name does not contain Chinese characters(test01) is correct， I want to make sure whether it supports the creation of a repository with the Chinese characters? 在 2013-09-16 21:57:54，Andy Levy andy.l...@gmail.com 写道： On Mon, Sep 16, 2013 at 9:38 AM, lsl6631 lsl6...@163.com wrote: Hi，I want to know if SVN (be installed on Redhat linux 5.3) support to create a version of the library that contains chinese ? I have installed ths svn via the order below, yum install httpd httpd-devel subversion mod_dav_svn. Finally I have try to visit the library address via IE, and displayed below: m:human-readable errcode=2 Could not open the requested SVN filesystem /m:human-readable And I am sure the englise version library is absolutely correct. I'm looking forward to your early reply. Thanks a lot. What does your Apache error log indicate? Are you certain that you've configured Apache to point to the correct directory for your repository (taking into account SVNPath/SVNParentPath)?
Re: Push ?
On 9/15/2013 11:32 AM, Dan White wrote: The issue is that the client end of the transaction is in a DMZ A connection from a DMZ to one’s internal network is a very high security risk. What I was hoping for was a way to define a very specific connection from the Subversion server to the DMZ client (push). This is considered to be a much lower security risk. One way to handle this is to use SSH to access the specific SVN repository. 1. Use no-password SSH public-key pair that the DMZ host can punch through to the SSH port on the internal SVN server. (Naturally, SSH should be set to dis-allow root login, and only allow public-key authentication.) - If you can't change everyone over to using public keys and disabling password based authentication for SSH, then you should run a 2nd SSHD process on a different port and have that only allow specific accounts to login and require public-key authentication. Then you can setup your DMZ - SVN server firewall to only allow access to the SVN SSH alternate port from the DMZ. 2. Give the SSH account read-only access to the SVN repo that it needs 3. Lock down what the SSH account can do to just: command=/usr/bin/svnserve -t -r /var/svn,no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa ... Since the account will have very limited permissions on the SVN machine (read-only access), there's not a whole lot that someone could do with the account. Plus the use of the command= line means they'd have to figure out a way to escape the svnserve program in order to get a command-line on the SVN machine.
svn-crash-log
svn-crash-log20130916120142.log Description: Binary data
Re: Push ?
The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server.It violates the whole purpose of having a DMZ in the first place.“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin Hobbes)On Sep 16, 2013, at 12:19 PM, Thomas Harold thomas-li...@nybeta.com wrote:On 9/15/2013 11:32 AM, Dan White wrote:The issue is that the client end of the transaction is in a DMZA connection from a DMZ to one’s internal network is a very highsecurity risk. What I was hoping for was a way to define a veryspecific connection from the Subversion server to the DMZ client(push). This is considered to be a much lower security risk. One way to handle this is to use SSH to access the specific SVN repository. 1. Use no-password SSH public-key pair that the DMZ host can punch through to the SSH port on the internal SVN server. (Naturally, SSH should be set to dis-allow root login, and only allow public-key authentication.) - If you can't change everyone over to using public keys and disabling password based authentication for SSH, then you should run a 2nd SSHD process on a different port and have that only allow specific accounts to login and require public-key authentication. Then you can setup your DMZ - SVN server firewall to only allow access to the SVN SSH alternate port from the DMZ. 2. Give the SSH account read-only access to the SVN repo that it needs 3. Lock down what the SSH account can do to just: command="/usr/bin/svnserve -t -r /var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa ... Since the account will have very limited permissions on the SVN machine (read-only access), there's not a whole lot that someone could do with the account. Plus the use of the command= line means they'd have to figure out a way to escape the svnserve program in order to get a command-line on the SVN machine.
Re: Push ?
On Mon, Sep 16, 2013 at 2:53 PM, Dan White d_e_wh...@icloud.com wrote: The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server. It violates the whole purpose of having a DMZ in the first place. There is always the trick of ssh-ing a command from inside the firewall to the DMZ box that (a) sets up port-forwarding and (b) runs the svn command as though the repo is on localhost. Technically, and from the firewall's point of view, the connection is established outbound. -- Les Mikesell lesmikes...@gmail.com
Problem committing 1.8 client to 1.8 server
I'm having problems committing from my 1.8.X client to a 1.8.3 server. When I try to commit, I get the following error: svn: E175013: Commit failed (details follow): svn: E175013: POST of '/svn/!svn/me': 403 Forbidden (url) I've checked with both 1.8.1 and 1.8.3. The Apache logs show the following: [Mon Sep 16 16:08:17 2013] [error] [client ipaddr] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file /opt/mod_security/10_asl_rules.conf] [line 64] [id 390616] [rev 2] [msg POST request must have a Content-Length header] [severity WARNING] [hostname hostname] [uri /svn/!svn/me] [unique_id id] I am able to commit perfectly fine with 1.6.17, so it doesn't seem that there is a configuration issue, but I don't know for certain. Is this a configuration issue or a bug? -Robert Middleton
Re: Problem committing 1.8 client to 1.8 server
On Mon Sep 16 14:19:54 2013, Robert Middleton wrote: [Mon Sep 16 16:08:17 2013] [error] [client ipaddr] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file /opt/mod_security/10_asl_rules.conf] [line 64] [id 390616] [rev 2] [msg POST request must have a Content-Length header] [severity WARNING] [hostname hostname] [uri /svn/!svn/me] [unique_id id] This looks like your mod_security configuration doesn't know about chunked encoding for requests. 1.8.x now prefers to use chunked encoding in requests. I'm not sure what you need to change to configure mod_security to allow chunked requests but that's what you'll probably want to do. 1.8.1 also added an option to change this behavior on the client side if changing the above isn't an option. Setting the http-chunked-requests setting to no should disable chunked requests and restore the behavior that pre-1.8.x clients had with their requests. However, I would recommend that you fix the server since there are advantages to using chunked requests (e.g. we don't have to buffer requests to calculate the size before starting to send the request). This section in our Release Notes should be helpful to you: http://subversion.apache.org/docs/release-notes/1.8.html#411-length-required
Re: Problem committing 1.8 client to 1.8 server
On Mon Sep 16 17:37:20 2013, Ben Reser wrote: This looks like your mod_security configuration doesn't know about chunked encoding for requests. 1.8.x now prefers to use chunked encoding in requests. I'm not sure what you need to change to configure mod_security to allow chunked requests but that's what you'll probably want to do. Based on this it looks like you're running an out of date version of mod_security: http://serverfault.com/questions/65733/why-does-modsecurity-require-content-length-in-post-requests
