Weird configuration with a clean install of Jenkins

[Karl Davis]

Howdy all,

I am really stumped here. I've got an Ansible role that installs and configures Jenkins using the Debian packages: https://github.com/karlmdavis/ansible-role-jenkins2. It uses the -Djenkins.install.runSetupWizard=false flag, and handles the first-time setup itself.

In my tests using that role, it seems that Jenkins is ending up with this weird config.xml:

<?xml version='1.0' encoding='UTF-8'?>
<hudson>
  <disabledAdministrativeMonitors/>
  <version>1.0</version>
  <numExecutors>2</numExecutors>
  <mode>NORMAL</mode>
  <useSecurity>true</useSecurity>
  <authorizationStrategy class="hudson.security.AuthorizationStrategy$Unsecured"/>
  <securityRealm class="hudson.security.SecurityRealm$None"/>
  <disableRememberMe>false</disableRememberMe>
  <projectNamingStrategy class="jenkins.model.ProjectNamingStrategy$DefaultProjectNamingStrategy"/>
  <workspaceDir>${JENKINS_HOME}/workspace/${ITEM_FULLNAME}</workspaceDir>
  <buildsDir>${ITEM_ROOTDIR}/builds</buildsDir>
  <jdks/>
  <viewsTabBar class="hudson.views.DefaultViewsTabBar"/>
  <myViewsTabBar class="hudson.views.DefaultMyViewsTabBar"/>
  <clouds/>
  <scmCheckoutRetryCount>0</scmCheckoutRetryCount>
  <views>
    <hudson.model.AllView>
      <owner class="hudson" reference="../../.."/>
      <name>all</name>
      <filterExecutors>false</filterExecutors>
      <filterQueue>false</filterQueue>
      <properties class="hudson.model.View$PropertyList"/>
    </hudson.model.AllView>
  </views>
  <primaryView>all</primaryView>
  <slaveAgentPort>0</slaveAgentPort>
  <label></label>
  <nodeProperties/>
  <globalNodeProperties/>
</hudson>

That... doesn't seem right? Shouldn't a clean install of Jenkins end up configured to use hudson.security.HudsonPrivateSecurityRealm? And also, what's up with the <version>1.0</version> in there?

Just to make this even more confusing, when I'm running this role in a different environment (but also a clean install) the config.xml has hudson.security.HudsonPrivateSecurityRealm and -- sometimes (?!) -- ends up with <version>2.whatever</version>.

I'm really confused as to 1) what a clean install's configuration is supposed to be, and 2) why I'm getting different results intermittently. Does anyone have any clues?

Thanks much,
Karl M. Davis


P.S. The two environments that I'm seeing different behavior in are 1) a custom Ubuntu 16.04 Docker container, and 2) an Ubuntu 16.04 EC2 VM. I wouldn't expect there to be any default config.xml differences between those two, but what do I know?

[Daniel Beck]

> On 8. Oct 2017, at 17:20, Karl Davis <ka...@davisonlinehome.name> wrote:
>
> Shouldn't a clean install of Jenkins end up configured to use hudson.security.HudsonPrivateSecurityRealm?

Not if you explicitly disable the setup wizard (then you're expected to set things up yourself from scratch). The behavior is as documented on https://wiki.jenkins.io/display/JENKINS/Features+controlled+by+system+properties

[Daniel Beck]

> On 8. Oct 2017, at 17:20, Karl Davis <ka...@davisonlinehome.name> wrote:
>

> Just to make this even more confusing, when I'm running this role in a different environment (but also a clean install) the config.xml has hudson.security.HudsonPrivateSecurityRealm and -- sometimes (?!) -- ends up with <version>2.whatever</version>.

To clarify, I answered this from Jenkins' perspective. I don't know what the role does, but as it seems to behave inconsistently, perhaps ask over there?

[Karl Davis]

Daniel,

Okay, that makes sense. Unfortunately, that leaves me completely stumped as to why it's ending up configured to use hudson.security.HudsonPrivateSecurityRealm when I run it in EC2. Historically speaking, it's likely that I'm doing something stupid that gets it into that state, except... I can't see what that might be.

Any chance there's some weird race condition, where the initial config transitions from one state to another -- and mine's just getting stuck with the one?

Confusedly yours,
Karl M. Davis

[Karl Davis]

Heh. Unfortunately, I'm the idiot responsible for the role. And I'm stumped.

[Karl Davis]

Daniel,

Actually... maybe it is a race condition. When the role installs Jenkins, it doesn't pre-create the /etc/default/jenkins file, which is where the -Djenkins.install.runSetupWizard=false flag is. So, the order of operations is this:

1. Install the jenkins package from APT.
2. Jenkins is auto-started by systemd.
   
3. Add the flag to disable the setup wizard.
4. Restart Jenkins.
5. Do all the other config needed.
   

The race condition would be: how far does Jenkins get on that first boot, before being restarted without the setup wizard?

Shoot. That makes a lot of sense. I guess I need to pre-create the /etc/default/jenkins file, with the setup wizard disabled and then install Jenkins.

Slightly less confusedly yours,
Karl M. Davis

[Karl Davis]

Confirmed: that was the problem. Pre-creating /etc/default/jenkins resolved it.