• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • Fresh build:
      Jenkins 2.80
      CentOS 7.4.1708

      Yesterday, was doing a test-launch of a new Jenkins stack in preparation for upgrading our production Jenkins maser from 2.76. Used the RPM-based install. Yum pulled down 2.80 - even though our production instance had indicated that only the 2.79 update was latest available (presumably a cached value).

      Upon initial startup, no  secrets/initialAdminPassword file was generated. We discovered this when your deployment automation got hung on waiting for this file to exist.

      Also found that the Jenkins master service had started up and the web GUI was up and available. Upon connection to the web page, there was no request for any form of admin-credentials - not the usual secret from the secrets/initialAdminPassword file nor a prompt for any kind of user/password pair.

      Doing a targeted-installation of 2.79 resulted in the expected first-start behavior.

      Checked through the release notes and installation guides to make sure there were no unexpected/unaccounted-for changes. Found none.

      We delayed our production Jenkins master's upgrade for obvious reasons (pending resolution of the apparent first-start authentication issues in 2.80).

          [JENKINS-47139] Initial Access Regression in 2.80?

          Oleg Nenashev added a comment -

          It would be great to get the System logs at least.

           

          Oleg Nenashev added a comment - It would be great to get the System logs at least.  

          Thomas Jones added a comment - - edited

          Sure thing: which logs? We typically build and destroy instances, so, the ones from last night are gone ...but it's trivial to redeploy.

           

          At any rate, I was called to see why the deployment was failing after the three consecutive launch-failures. I was only looking at what was missing - the secrets file - and noticed that the initial login-page was not prompting for the first-start secret nor any other credentials (just openin straight to the privileged management interface).

          Thomas Jones added a comment - - edited Sure thing: which logs? We typically build and destroy instances, so, the ones from last night are gone ...but it's trivial to redeploy.   At any rate, I was called to see why the deployment was failing after the three consecutive launch-failures. I was only looking at what was missing - the secrets file - and noticed that the initial login-page was not prompting for the first-start secret nor any other credentials (just openin straight to the privileged management interface).

          Daniel Beck added a comment - - edited

          The second report of this, in addition to that on the users list: https://groups.google.com/d/msg/jenkinsci-users/e2TFX4W5oI0/XWgOGDeoAgAJ

           

          My guess is JENKINS-42577

          Daniel Beck added a comment - - edited The second report of this, in addition to that on the users list: https://groups.google.com/d/msg/jenkinsci-users/e2TFX4W5oI0/XWgOGDeoAgAJ   My guess is JENKINS-42577

          Jesse Glick added a comment -

          Confirmed that JENKINS-42577 was the cause of the regression: when https://github.com/jenkinsci/jenkins/pull/3010/files#diff-9e24c3bccc9e921f1a5cc216abc25d03 is reverted in master, the problem goes away.

          Jesse Glick added a comment - Confirmed that  JENKINS-42577 was the cause of the regression: when https://github.com/jenkinsci/jenkins/pull/3010/files#diff-9e24c3bccc9e921f1a5cc216abc25d03  is reverted in master , the problem goes away.

          Jesse Glick added a comment -

          Seems this code is responsible.

          Jesse Glick added a comment - Seems this code is responsible.

          Jesse Glick added a comment -

          FTR:

          mvn -DskipTests -am -pl war install
          JENKINS_WAR=war/target/jenkins.war mvn -f ../acceptance-test-harness -Dtest=core.InstallWizardTest\#wizardInstallSugestedTest test
          

          Jesse Glick added a comment - FTR: mvn -DskipTests -am -pl war install JENKINS_WAR=war/target/jenkins.war mvn -f ../acceptance-test-harness -Dtest=core.InstallWizardTest\#wizardInstallSugestedTest test

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/jenkins/install/InstallUtil.java
          core/src/main/java/jenkins/model/Jenkins.java
          http://jenkins-ci.org/commit/jenkins/07923429f0ee80284f98d9a59d7691794bbfb5bc
          Log:
          [FIXED JENKINS-47139] Do not set Jenkins.version too early in startup, lest InstallUtil.getLastExecVersion get confused.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/jenkins/install/InstallUtil.java core/src/main/java/jenkins/model/Jenkins.java http://jenkins-ci.org/commit/jenkins/07923429f0ee80284f98d9a59d7691794bbfb5bc Log: [FIXED JENKINS-47139] Do not set Jenkins.version too early in startup, lest InstallUtil.getLastExecVersion get confused.

          Jesse Glick added a comment -

          Fixed toward 2.81, whenever that gets released.

          Jesse Glick added a comment - Fixed toward 2.81, whenever that gets released.

            jglick Jesse Glick
            ferricoxide Thomas Jones
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: