[JIRA] (JENKINS-58858) Configuration as Code value for securityRealm reset after rebot

1 view
Skip to first unread message

bittebrown@gmail.com (JIRA)

unread,
Aug 8, 2019, 5:41:03 AM8/8/19
to jenkinsc...@googlegroups.com
Tim Brown created an issue
 
Jenkins / Bug JENKINS-58858
Configuration as Code value for securityRealm reset after rebot
Issue Type: Bug Bug
Assignee: Ewelina Wilkosz
Components: configuration-as-code-plugin
Created: 2019-08-08 09:40
Environment: Ubuntu: 18.04
Docker: 18.09.7, build 2d0083d
Jenkins: 2.176.2
Config as Code Plugin: 1.27
Priority: Minor Minor
Reporter: Tim Brown

We are trying to use the https://wiki.jenkins.io/display/JENKINS/Reverse+Proxy+Auth+Plugin to handle our authentication. We can get the plugin configured correctly and after that export the config as code .yaml and save it on the filesystem. The problem is when we reboot jenkins it revertes to Internal Jenkins DB users, instead of using the reverse proxy.

Here is the snippet of JCasC yaml we get from exporting the config from Jenkins:
```
securityRealm:
reverseProxy:
disableLdapEmailResolver: false
forwardedUser: "X-Forwarded-User"
headerGroups: "X-Forwarded-Groups"
headerGroupsDelimiter: "|"
inhibitInferRootDN: false
updateInterval: 15
userSearch: "uid=

{0}

"
```

Marking as minor as there is a workaround (reset the value after each reset), but it would be really nice not to have to work around it .

Not 100% is this is a bug with this or the reverse auth proxy, but raising here first seemed to make sense.
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

bittebrown@gmail.com (JIRA)

unread,
Aug 8, 2019, 5:46:02 AM8/8/19
to jenkinsc...@googlegroups.com
Tim Brown commented on Bug JENKINS-58858
 
Re: Configuration as Code value for securityRealm reset after rebot

Sorry forgot to mention. We are running jenkins inside a container and the config files are shared through a volume mounted into the container. When I say we ose credentials on restart, I mean when we stop and start the container. I just tested doing a UI restart and got this stacktrace:

java.lang.IllegalStateException: Expected 1 instance of hudson.model.User$AllUsers but got 0
	at hudson.ExtensionList.lookupSingleton(ExtensionList.java:451)
	at hudson.model.User$AllUsers.getInstance(User.java:1080)
	at hudson.model.User$AllUsers.get(User.java:1098)
	at hudson.model.User$AllUsers.access$100(User.java:1061)
	at hudson.model.User.getOrCreateById(User.java:517)
	at hudson.model.User.getById(User.java:615)
	at hudson.security.HttpSessionContextIntegrationFilter2.hasInvalidSessionSeed(HttpSessionContextIntegrationFilter2.java:87)
	at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:60)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90)
	at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1701)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1668)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.Server.handle(Server.java:502)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:748)

bittebrown@gmail.com (JIRA)

unread,
Aug 8, 2019, 5:47:02 AM8/8/19
to jenkinsc...@googlegroups.com
Tim Brown updated an issue
 
Change By: Tim Brown
We are trying to use the https://wiki.jenkins.io/display/JENKINS/Reverse+Proxy+Auth+Plugin to handle our authentication. We can get the plugin configured correctly and after that export the config as code .yaml and save it on the filesystem. The problem is when we reboot jenkins it revertes to Internal Jenkins DB users, instead of using the reverse proxy.

Here is the snippet of JCasC yaml we get from exporting the config from Jenkins:
 ```
{code:yaml}
  securityRealm:
    reverseProxy:
      disableLdapEmailResolver: false
      forwardedUser: "X-Forwarded-User"
      headerGroups: "X-Forwarded-Groups"
      headerGroupsDelimiter: "|"
      inhibitInferRootDN: false
      updateInterval: 15
      userSearch: "uid={0}"
``` {code}


Marking as minor as there is a workaround (reset the value after each reset), but it would be really nice not to have to work around it :).


Not 100% is this is a bug with this or the reverse auth proxy, but raising here first seemed to make sense.

bittebrown@gmail.com (JIRA)

unread,
Aug 8, 2019, 6:28:01 AM8/8/19
to jenkinsc...@googlegroups.com
Tim Brown edited a comment on Bug JENKINS-58858
Sorry forgot to mention. We are running jenkins inside a container and the config files are shared through a volume mounted into the container. When I say we ose credentials on restart, I mean when we stop and start the container. I just tested doing a UI restart and got this stacktrace:


{noformat}
{noformat}

 h3. Update
Looking at the above error it seems to be due to https://issues.jenkins-ci.org/browse/JENKINS-55945.
I have updated my Jenkins image to track latest (2.189) and the exception on restart has disappeared. I am still getting the issue with securityRealm resetting, and even get it when rebooting through the UI.

bittebrown@gmail.com (JIRA)

unread,
Aug 8, 2019, 7:21:02 AM8/8/19
to jenkinsc...@googlegroups.com
Tim Brown closed an issue as Not A Defect
 

Sorry after much searching it looks like we had a script in $JENKINS_HOME which was setting the securityRealm back to HudsonPrivateSecurityRealm

This was derived from http://tdongsi.github.io/blog/2017/12/30/groovy-hook-script-and-jenkins-configuration-as-code/ and used to set the admin password. Deleting this file stop this behaviour, so closing the issue.
Change By: Tim Brown
Status: Open Closed
Resolution: Not A Defect
Reply all
Reply to author
Forward
0 new messages