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

Initial Access Regression in 2.80?

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Fixed
    • core
    • Fresh build:
      Jenkins 2.80
      CentOS 7.4.1708

    Description

      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).

      Attachments

        Issue Links

          Activity

            oleg_nenashev Oleg Nenashev added a comment -

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

             

            oleg_nenashev Oleg Nenashev added a comment - It would be great to get the System logs at least.  
            ferricoxide 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).

            ferricoxide 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).
            danielbeck 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

            danielbeck 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
            jglick 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.

            jglick 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.
            jglick Jesse Glick added a comment -

            Seems this code is responsible.

            jglick Jesse Glick added a comment - Seems this code is responsible.
            jglick 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
            
            jglick 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_issue_link 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.
            jglick Jesse Glick added a comment -

            Fixed toward 2.81, whenever that gets released.

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: