Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20083

SVN revision check failed because executed on master in a DMZ

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • None
    • Jenkins version: 1.534
      Subversion plugin version: 1.51
      Config: JNLP: No connection tunneling set up

      Hello everybody,

      hopefully somebody can help me with this problem.

      Let me explain the environment:

      Jenkins master node runs in a DMZ. To build projects it connects to Linux/Windows slaves within internal network. When slaves build, they get the sources from an SVN server that again resides in the internal network. As for security reasons no one within the DMZ can access someone in the internal network. Which means only the slaves have access to SVN but not the master.

      So the frustrating situation is the following:

      A Windows slave (internal) is connected to the master (DMZ) via JNLP (slave initiates the connection; only way it works). The job is tight to the Windows slave in the internal network and is set up to poll for SVN changes, which works fine, because polling runs also on the slave. When a job gets started because of a SVN change than it triggers the slave. The slave cleans its workspace, checks out the newest source and than it does a "revision check", to see what has been changed.
      This is where the build fails: The revision check is actually done on the Jenkins master (DMZ), from which it cannot access SVN server (internal). I am sure this is the problem, because the logs from the gateway tell me exactly that the master tried to access SVN server.

      The following log appears in the build log:
      -------------------------------------------
      At revision 1234
      hudson.util.IOException2: revision check failed on svn://svnserver.internal.net/svn/PROJECT
      at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:178)
      at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:113)
      at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:656)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:817)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562)
      at hudson.model.Run.execute(Run.java:1665)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:246)
      Caused by: org.tmatesoft.svn.core.SVNException: svn: E210003: connection refused by the server
      at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:85)
      at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:69)
      at org.tmatesoft.svn.core.internal.io.svn.SVNPlainConnector.open(SVNPlainConnector.java:62)
      at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77)
      at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1252)
      at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168)
      at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
      at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
      at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
      at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
      at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
      at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:166)
      ... 11 more
      Caused by: java.net.ConnectException: Connection timed out
      at java.net.PlainSocketImpl.socketConnect(Native Method)
      at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
      at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
      at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
      at java.net.Socket.connect(Socket.java:546)
      at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.connect(SVNSocketFactory.java:146)
      at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:73)
      at org.tmatesoft.svn.core.internal.io.svn.SVNPlainConnector.open(SVNPlainConnector.java:53)
      ... 25 more
      -------------------------------------------

      As you see the log contains:

      • E210003: connection refused by the server
      • Connection timed out

      This is because the gateway refuses the connection from the DMZ to internal network.

      This is not the case when nothing has changed since the last build. I guess it doesn't need to run a revision check.

      So my question is the following:

      Is there a way to tell Jenkins to run the revision check on the slave where the repository is checked out?

      If this is a feature, so that the revision check is run on master because it is faster. Than my situation should be covered as it is a common environment in a company.

      Thanks in advance!

      Florin Hillebrand

          [JENKINS-20083] SVN revision check failed because executed on master in a DMZ

          Daniel Beck added a comment - - edited

          Not a bug: This is not a supported configuration to the best of my knowledge. There is no solution (e.g. configuration) for this in Jenkins.

          Not critical: The workaround is trivial and practiced by thousands of installs: Don't put the Jenkins master in a DMZ. If this were common, you wouldn't be the first one to need this.

          Daniel Beck added a comment - - edited Not a bug: This is not a supported configuration to the best of my knowledge. There is no solution (e.g. configuration) for this in Jenkins. Not critical: The workaround is trivial and practiced by thousands of installs: Don't put the Jenkins master in a DMZ. If this were common, you wouldn't be the first one to need this.

            huybrechts huybrechts
            flozzone Florin Hillebrand
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: