[JIRA] (JENKINS-51294) Docker Commons/Pipeline upgrade breaks build jobs
Title: Message Title
larsskj updated an issue
Jenkins / JENKINS-51294
Docker Commons/Pipeline upgrade breaks build jobs
Change By:
larsskj
Two days ago, we upgraded docker-commons from 1.11 to 1.12 and docker-workflow from 1.15.1 to 1.16 - and our jobs stopped working. Reverting the two plugins makes jobs build again.The setup is a bit complicated: The Jenkins master is running on a Debian Stretch machine, but the build nodes are running on the same machine as Docker containers using the plugin simply named Docker.As the Docker daemon is running outside the Docker container with the build node, I use a construct like the following to handle Docker commands:{code:java}withEnv(["DOCKER_HOST=$\{DOCKER_HOST}"]) { docker.withRegistry("https://${DOCKER_REPO}", 'artifactory-api-key') {dockerImage.push("${currentBuild.number}")dockerImage.push('latest') }}{code}This has worked fine for a long time, but with the above mentioned upgrade, it started failing with error messages like {code:java}[Pipeline] withEnv[Pipeline] {[Pipeline] withDockerRegistry$ docker login -u jenkins -p https://${DOCKER_REPO}WARNING! Using --password via the CLI is insecure. Use --password-stdin.Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?[Pipeline] // withDockerRegistry[Pipeline] }[Pipeline] // withEnv[Pipeline] }{code}Reverting the two plugins to the previous versions solves the problem.Regards,Lars
Add Comment
[JIRA] (JENKINS-51294) Docker Commons/Pipeline upgrade breaks build jobs
Title: Message Title
larsskj updated an issue
Jenkins / JENKINS-51294
Docker Commons/Pipeline upgrade breaks build jobs
Change By:
larsskj
Labels:
pipeline plugin
Two days ago, we upgraded docker-commons from 1.11 to 1.12 and docker-workflow from 1.15.1 to 1.16 - and our jobs stopped working. Reverting the two plugins makes jobs build again.The setup is a bit complicated: The Jenkins master is running on a Debian Stretch machine, but the build nodes are running on the same machine as Docker containers using the plugin simply named Docker.As the Docker daemon is running outside the Docker container with the build node, I use a construct like the following to handle Docker commands: {code:java} withEnv(["DOCKER_HOST=$\{DOCKER_HOST}"]) \ { docker.withRegistry("https://$ \ {DOCKER_REPO}", 'artifactory-api-key') \ {dockerImage.push("$ \ {currentBuild.number}") dockerImage.push('latest') } } {code} This has worked fine for a long time, but with the above mentioned upgrade, it started failing with error messages like {code:java} [Pipeline] withEnv [Pipeline] \ { [Pipeline] withDockerRegistry$ docker login -u jenkins -p [ https:// docker-dscrum.dbc.dk|https://docker-dscrum.dbc.dk/] ${DOCKER_REPO} WARNING! Using --password via the CLI is insecure. Use --password-stdin.Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: [ https://index.docker.io/v1/ ] Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? [Pipeline] // withDockerRegistry [Pipeline] } [Pipeline] // withEnv [Pipeline] } {code}Reverting the two plugins to the previous versions solves the problem.Regards,Lars
Add Comment
[JIRA] (JENKINS-51294) Docker Commons/Pipeline upgrade breaks build jobs
Title: Message Title
larsskj created an issue
Jenkins / JENKINS-51294
Docker Commons/Pipeline upgrade breaks build jobs
Issue Type:
Bug
Assignee:
Unassigned
Components:
docker-workflow-plugin
Created:
2018-05-14 12:43
Environment:
Debian Stretch / Docker 1.17.1
Priority:
Major
Reporter:
larsskj
Two days ago, we upgraded docker-commons from 1.11 to 1.12 and docker-workflow from 1.15.1 to 1.16 - and our jobs stopped working. Reverting the two plugins makes jobs build again. The setup is a bit complicated: The Jenkins master is running on a Debian Stretch machine, but the build nodes are running on the same machine as Docker containers using the plugin simply named Docker. As the Docker daemon is running outside the Docker container with the build node, I use a construct like the following to handle Docker commands: withEnv(["DOCKER_HOST=$\{DOCKER_HOST}"]) { docker.withRegistry("https://${DOCKER_REPO}", 'artifactory-api-key') { dockerImage.push("${currentBuild.number}") dockerImage.push('latest') } } This has worked fine for a long time, but with the above mentioned upgrade, it started failing with error messages like [Pipeline] withEnv[Pipeline] {[Pipeline] withDockerRegistry$ docker login -u jenkins -p https://docker-dscrum.dbc.dk WARNING! Using --password via the CLI is insecure. Use --password-stdin. Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/ Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?[Pipeline] // withDockerRegistry[Pipeline] }[Pipeline] // withEnv[Pipeline] }
[JIRA] (JENKINS-41476) Jenkinsfile fails with BOM
Title: Message Title larsskj created an issue Jenkins / JENKINS-41476 Jenkinsfile fails with BOM Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2017/Jan/26 12:20 PM Environment: Tested with a fresh, default install of Jenkins 2.42 Priority: Minor Reporter: larsskj A Multibranch Pipeline fails reading a Jenkinsfile if the file is encoded in UTF-8 and includes a BOM (Byte order mark). The error depends on the content of the file, but often shows as a variant of 'No such DSL method XX found'. If the BOM is removed, the file works fine. Add Comment
[JIRA] [authorize-project-plugin] (JENKINS-34279) Fails with Active Directory
Title: Message Title larsskj commented on JENKINS-34279 Re: Fails with Active Directory Hi, Your observations are pretty correct - but I might enlighten you a little on my comment about "other security concerns": When authenticating using AD or any other LDAP directory - or any other directory at large, for that sake - it's considered best practice always to authenticate as the user in case, not by using an overall login. The reason for this is that when you're authenticating as the real user in all cases, you minimize the risk of the using getting access to information from the directory that you did not intend the user to be allowed to. If the authenticator is authenticating as something else than the current user, you risk exposing sensitive information to the user in case, as the authenticator user will almost certainly have access to much more information than the actual user. Regards, Lars Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [authorize-project-plugin] (JENKINS-34279) Fails with Active Directory
Title: Message Title larsskj commented on JENKINS-34279 Re: Fails with Active Directory Yep - like this: Timer task hudson.model.Queue$MaintainTask@71f0f426 failed org.acegisecurity.userdetails.UsernameNotFoundException: Authentication was successful but cannot locate the user information for las at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider$1.call(ActiveDirectoryUnixAuthenticationProvider.java:284) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider$1.call(ActiveDirectoryUnixAuthenticationProvider.java:232) at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4767) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228) at com.google.common.cache.LocalCache.get(LocalCache.java:3965) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4764) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:232) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:199) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:141) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:54) at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32) at hudson.model.User.impersonate(User.java:310) at org.jenkinsci.plugins.authorizeproject.strategy.TriggeringUsersAuthorizationStrategy.authenticate(TriggeringUsersAuthorizationStrategy.java:68) at org.jenkinsci.plugins.authorizeproject.AuthorizeProjectProperty.authenticate(AuthorizeProjectProperty.java:120) at org.jenkinsci.plugins.authorizeproject.ProjectQueueItemAuthenticator.authenticate(ProjectQueueItemAuthenticator.java:96) at hudson.model.Queue$Item.authenticate(Queue.java:2174) at hudson.model.Node.canTake(Node.java:388) at hudson.model.Queue$JobOffer.canTake(Queue.java:256) at hudson.model.Queue.maintain(Queue.java:1529) at hudson.model.Queue$MaintainTask.doRun(Queue.java:2719) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) I've found a workaround as well: The AD plugin is implemented to authenticate by default using the users ID and password. This is "the right way" (TM) of doing it. However, it appears that this plugin - and others - tries to lookup group membership in AD and cannot do it, not knowing the user's credentials. Configuring
[JIRA] [authorize-project-plugin] (JENKINS-34279) Fails with Active Directory
Title: Message Title
larsskj edited a comment on JENKINS-34279
Re: Fails with Active Directory
Yep - like this:{code:java}Timer task hudson.model.Queue$MaintainTask@71f0f426 failedorg.acegisecurity.userdetails.UsernameNotFoundException: Authentication was successful but cannot locate the user information for las at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider$1.call(ActiveDirectoryUnixAuthenticationProvider.java:284) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider$1.call(ActiveDirectoryUnixAuthenticationProvider.java:232) at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4767) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228) at com.google.common.cache.LocalCache.get(LocalCache.java:3965) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4764) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:232) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:199) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:141) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:54) at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32) at hudson.model.User.impersonate(User.java:310) at org.jenkinsci.plugins.authorizeproject.strategy.TriggeringUsersAuthorizationStrategy.authenticate(TriggeringUsersAuthorizationStrategy.java:68) at org.jenkinsci.plugins.authorizeproject.AuthorizeProjectProperty.authenticate(AuthorizeProjectProperty.java:120) at org.jenkinsci.plugins.authorizeproject.ProjectQueueItemAuthenticator.authenticate(ProjectQueueItemAuthenticator.java:96) at hudson.model.Queue$Item.authenticate(Queue.java:2174) at hudson.model.Node.canTake(Node.java:388) at hudson.model.Queue$JobOffer.canTake(Queue.java:256) at hudson.model.Queue.maintain(Queue.java:1529) at hudson.model.Queue$MaintainTask.doRun(Queue.java:2719) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745){code}I've found a workaround as well: The AD plugin is implemented to authenticate by default using the users user's ID and password. This is "the right way" (TM) of doing it.However, it appears that this plugin - and others - tries to lookup group membership in AD and cannot do it, not knowing the user's credentials.Configuring the AD plugin to use a specific user ID for AD lookups solves the problem. It does, however, give rise to other security concerns - you solve one problem but creates another.Regards,Lars
[JIRA] [authorize-project-plugin] (JENKINS-34279) Fails with Active Directory
Title: Message Title larsskj created an issue Jenkins / JENKINS-34279 Fails with Active Directory Issue Type: Bug Assignee: Unassigned Components: authorize-project-plugin Created: 2016/Apr/15 1:43 PM Environment: Freshly installed 1.656 with only Authorize Project and Active Directory plugins installed. Priority: Major Reporter: larsskj When authentication is set to use the Active Directory plugin, Authorize Plugin fails if job authorization is set to anything but SYSTEM. Setting a job to "Run as user who triggered the build", the job just hangs in the job queue indefinitely waiting for access to an executor - when triggered by a logged-in user. Add Comment
