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

Anonymous cvs update doesn't work anymore

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: cvs-plugin
    • Labels:
      None
    • Environment:
      CentOS 5.7, cvs-1.11.22-9.el5, cvs plugin version 2.0
    • Similar Issues:

      Description

      Since the update to the java cvs plugin, I can't do anonymous readonly cvs update anymore. It fails with this message:
      cvs update: Updating .
      cvs update: failed to create lock directory for `/var/cvs' (/var/cvs/#cvs.lock): Permission denied
      cvs update: failed to obtain dir lock in repository `/var/cvs'
      cvs [update aborted]: read lock failed - giving up

      Note: Initial checkout after cleaning workspace works, only updates don't work.

      The is also another problem which may be a side effect: I see hanging around cvs server processes which only terminate after jenkins is shut down.

      We are running cvs pserver from xinetd like this: cvs -f --allow-root=/var/cvs pserver

      CVSROOT is ":pserver:anonymous@cvs:/var/cvs"

      Anonymous readonly updates have always worked with jenkins, as well es they do with Eclipse or Netbeans.

      Did I miss something?

      Regards,
      Simon

        Attachments

          Issue Links

            Activity

            Hide
            mc1arke Michael Clarke added a comment -

            I'm not able to replicate this, and Googling similar error message shows it seems to be a permissions error. Can you check that the user 'anonymous' and the user Jenkins is running under have write permission to the directory specified in your error (i.e. /var/cvs)?

            Show
            mc1arke Michael Clarke added a comment - I'm not able to replicate this, and Googling similar error message shows it seems to be a permissions error. Can you check that the user 'anonymous' and the user Jenkins is running under have write permission to the directory specified in your error (i.e. /var/cvs)?
            Hide
            simix Simon Matter added a comment -

            I've tried quite a lot but just couldn't find what is wrong.

            The jenkins user doesn't matter at all because we are running over the network with pserver, so directory access of the jenkins user has no effect.

            The 'anonymous' user is mapped to unix user 'anoncvs' on the cvs server, which has no password in $CVSROOT/CVSROOT/passwd and is member of the unix group 'cvs', which has write access into the cvs modules directories. Of course 'anonymous' is also listed in $CVSROOT/CVSROOT/readers

            Both, 'cvs' and 'anoncvs' have no write permission on directory $CVSROOT (/var/cvs), which is owned by root. The only access they have is to the subdirectories of /var/cvs. Like this:

            drwxr-xr-x 5 root root 4096 Jan 31 07:18 /var/cvs
            drwxrwxr-x 3 cvs cvs 4096 Feb 3 08:52 /var/cvs/CVSROOT
            drwxrwxr-x 7 cvs cvs 4096 Feb 3 08:07 /var/cvs/invoca

            The main question is, why does the cvs update try to create a lock for `/var/cvs' (/var/cvs/#cvs.lock) which is the repository root? That makes no sense and is not allowed.

            Can it be that the problem is relatd to the new feature that multiple modules can be handled together? To me it seems that the list of directories to update from cvs also includes the repository root, which it should not.

            Thanks for looking into it,
            Simon

            Show
            simix Simon Matter added a comment - I've tried quite a lot but just couldn't find what is wrong. The jenkins user doesn't matter at all because we are running over the network with pserver, so directory access of the jenkins user has no effect. The 'anonymous' user is mapped to unix user 'anoncvs' on the cvs server, which has no password in $CVSROOT/CVSROOT/passwd and is member of the unix group 'cvs', which has write access into the cvs modules directories. Of course 'anonymous' is also listed in $CVSROOT/CVSROOT/readers Both, 'cvs' and 'anoncvs' have no write permission on directory $CVSROOT (/var/cvs), which is owned by root. The only access they have is to the subdirectories of /var/cvs. Like this: drwxr-xr-x 5 root root 4096 Jan 31 07:18 /var/cvs drwxrwxr-x 3 cvs cvs 4096 Feb 3 08:52 /var/cvs/CVSROOT drwxrwxr-x 7 cvs cvs 4096 Feb 3 08:07 /var/cvs/invoca The main question is, why does the cvs update try to create a lock for `/var/cvs' (/var/cvs/#cvs.lock) which is the repository root? That makes no sense and is not allowed. Can it be that the problem is relatd to the new feature that multiple modules can be handled together? To me it seems that the list of directories to update from cvs also includes the repository root, which it should not. Thanks for looking into it, Simon
            Hide
            mc1arke Michael Clarke added a comment -

            #cvs.lock is created in the root of the directory currently being updated on the server side (see the CVS redbook for details). JENKINS-12581 is having an effect here as the name of the module being updated is not being passed to the repository correctly so CVS is trying to create the lock file in the root of the repository rather than within a module.

            Show
            mc1arke Michael Clarke added a comment - #cvs.lock is created in the root of the directory currently being updated on the server side (see the CVS redbook for details). JENKINS-12581 is having an effect here as the name of the module being updated is not being passed to the repository correctly so CVS is trying to create the lock file in the root of the repository rather than within a module.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Michael Clarke
            Path:
            src/main/java/hudson/scm/CVSSCM.java
            src/main/resources/hudson/scm/CVSSCM/config.jelly
            http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915
            Log:
            [FIXED JENKINS-753] Allows performing a clean checkout if update fails
            [FIXED JENKINS-12595] CVS gets passed the module name so creates lock
            files in the correct directory on the remote server
            [FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate
            command to prevent an attempt to checkout all remote modules

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CVSSCM.java src/main/resources/hudson/scm/CVSSCM/config.jelly http://jenkins-ci.org/commit/cvs-plugin/794afd76127191e6a5174647d0c2620f0aadd915 Log: [FIXED JENKINS-753] Allows performing a clean checkout if update fails [FIXED JENKINS-12595] CVS gets passed the module name so creates lock files in the correct directory on the remote server [FIXED JENKINS-12581] CVS plugin now forces a module name in the udpate command to prevent an attempt to checkout all remote modules
            Hide
            mc1arke Michael Clarke added a comment -

            Fixed in 2.1. Caused by the checkout/update command not explicitly specifying which module to checkout which some CVS servers didn't like

            Show
            mc1arke Michael Clarke added a comment - Fixed in 2.1. Caused by the checkout/update command not explicitly specifying which module to checkout which some CVS servers didn't like

              People

              • Assignee:
                mc1arke Michael Clarke
                Reporter:
                simix Simon Matter
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: