Jenkins docker-workflow plugin - docker container killed prematurely while using ".inside"

[Mike Wilkerson]

Hi all—

I'm trying to run steps inside a docker container via *.inside*, but the 
container is killed shortly after running the commands. It appears that the 
docker-workflow plugin is not waiting for the *exec* command behind the 
scenes, and is stopping the container prematurely.

A little context, first:

   - Jenkins slave is running on a CentOS Linux release 7.1.1503 VM.
   - Using the official *debian:7* docker image.
   - Docker version 1.9.1, build a34a1d5
   - Jenkins 1.639
   - *This might be unrelated, but it's probably worth mentioning:*
  - The default CentOS Docker install was running the daemon like 
*/usr/bin/docker 
  daemon -H fd://*
  - I wasn't able to get the docker-workflow plugin to connect to the 
  daemon with that configuration, so I modified the service file to instead 
  run as */usr/bin/docker daemon -H tcp://localhost:2375*
  - I could then successfully use the plugin by running inside a 
*docker.withServer('tcp://localhost:2375', 
  '') { ... }* block.
   

Reproducing the issue

Anything running in an *sh* block that finishes very quickly is fine:

*node('docker') {*
*docker.withServer('tcp://localhost:2375', '') {*
*docker.image('debian:7').inside {*
*sh 'printenv'*
*}*
*}*
*}*


However, a longer-running command will always fail (Jenkins build fails, 
complaining that the script exited with error code -1):

*node('docker') {*
*docker.withServer('tcp://localhost:2375', '') {*
*docker.image('debian:7').inside {*
*sh 'sleep 300'*
*}*
*}*
*}*


Here are some interesting lines from */var/log/messages*:

*Jan 11 15:25:24 jenkins-build-centos7 docker: 
time="2016-01-11T15:25:24.290960195-05:00" level=info msg="POST 
/v1.21/containers/02b6dbc8af81794efe1aeeb43f861e47a803bb3672a9991a63120632127df247/exec"*
*Jan 11 15:25:24 jenkins-build-centos7 docker: 
time="2016-01-11T15:25:24.293203526-05:00" level=info msg="POST 
/v1.21/exec/39fd717f8dd9797e9a967edc995e0f0e29ed19bcd1837e28410dcd0667f56253/start"*
*Jan 11 15:25:25 jenkins-build-centos7 docker: 
time="2016-01-11T15:25:25.350407441-05:00" level=info msg="POST 
/v1.21/containers/02b6dbc8af81794efe1aeeb43f861e47a803bb3672a9991a63120632127df247/stop?t=10"*
*Jan 11 15:25:35 jenkins-build-centos7 docker: 
time="2016-01-11T15:25:35.351254649-05:00" level=info msg="Container 
02b6dbc8af81794efe1aeeb43f861e47a803bb3672a9991a63120632127df247 failed to 
exit within 10 seconds of SIGTERM - using the force"*
*Jan 11 15:25:35 jenkins-build-centos7 docker: 
time="2016-01-11T15:25:35.359447435-05:00" level=info msg="GET 
/v1.21/exec/39fd717f8dd9797e9a967edc995e0f0e29ed19bcd1837e28410dcd0667f56253/json"*


It looks like the docker-workflow plugin is immediately issuing a *stop* 
call to the API, right after the *exec* call.


Attempt at a solution

I noticed that the docker-workflow plugin calls the image by passing the 
*cat* command:

*docker run -t -d -u 1000:1000 -w /home/jenkins/workspace/docker-test -v 
/home/jenkins/workspace/docker-test:/home/jenkins/workspace/docker-test:rw 
-e  -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  debian:7 cat*

...which would cause the container to run *cat* and then immediately exit. 
I created a simple dockerfile, based off of the *debian:7* image, and set 
the *ENTRYPOINT* to *["ping", "localhost"]*, just to have a process that 
would run indefinitely, even if docker-workflow supplied *cat* as the 
command to *docker run*. Unfortunately this changed nothing, and I still 
noticed the same API call to *stop* in */var/log/messages*.

I'm at a loss here. Anyone seen anything like this before?

Thanks,
Mike Wilkerson

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/d6e2b48e-7639-403a-bdd9-9f48f87e4e2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins with Git plugin always failed to clone webkit project

[Mengwei Ding]

Hi,

My local jenkins instance failed to clone the origin webkit project (
https://github.com/WebKit/webkit) all the time (> 10) with the following 
exception:

Receiving objects:  49% (1432424/2885707), 3.89 GiB | 11.22 MiB/s   
Receiving objects:  49% (1440225/2885707), 3.90 GiB | 11.26 MiB/s   
Receiving objects:  50% (1442854/2885707), 3.91 GiB | 11.40 MiB/s   
Receiving objects:  50% (1447858/2885707), 3.92 GiB | 11.42 MiB/s   
Receiving objects:  50% (1450535/2885707), 3.93 GiB | 11.69 MiB/s   
Receiving objects:  50% (1450794/2885707), 3.94 GiB | 11.52 MiB/s   
Receiving objects:  50% (1451224/2885707), 3.95 GiB | 11.61 MiB/s   
Receiving objects:  50% (1453556/2885707), 3.96 GiB | 11.62 MiB/s   
Receiving objects:  50% (1455445/2885707), 3.97 GiB | 11.24 MiB/s   
Receiving objects:  50% (1462298/2885707), 3.98 GiB | 11.04 MiB/s   
Receiving objects:  51% (1471711/2885707), 3.99 GiB | 11.27 MiB/s   
Receiving objects:  51% (1474722/2885707), 4.00 GiB | 11.39 MiB/s   
Receiving objects:  51% (1475986/2885707), 4.00 GiB | 11.20 MiB/s   
Receiving objects:  51% (1476655/2885707), 4.02 GiB | 10.92 MiB/s   
Receiving objects:  51% (1477407/2885707), 4.03 GiB | 10.77 MiB/s   
Receiving objects:  51% (1478535/2885707), 4.04 GiB | 10.58 MiB/s   
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:505)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1003)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
ERROR: null


Since the webkit project source is huge ( > 4 GB), I am expecting some 
errors, but do you guys know how to fix this for my case? It this a natural 
bug of git plugin? or the size is beyond git plugin's ability?

My jenkins version is Jenkins ver. 1.634 
My jenkins git plugin version is 2.4.0

Thanks,
Mengwei

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/18771289-eb2f-4aaf-9b66-eaccb498b95e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sending multiline text with new the release of Hipchat Plugin via Workflow

[Pablo Ramirez]

Is this possible?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/dd513324-0146-4d8b-9279-fc37ad9ce7f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TFS plugin mapping conflict

[Stefan Drissen]

I had issues when the workspaces already existed in 3.2.0 - 
see https://issues.jenkins-ci.org/browse/JENKINS-30355

Not sure if this is the same as your issue - in my case deleting the old 
workspaces first solved the issue. After that I ran into a number of other 
issues with the 4.0.0 plug-in and downgraded back to 3.2.0

Regards,

Stefan

On Tuesday, 1 December 2015 00:59:14 UTC+1, Andy Falanga wrote:
>
> Hello all,
>
> I recently updated my TFS plugin to version 4.0.0 to take advantage of the 
> Java client instead of having to install a tf client on all my Linux 
> hosts.  I have two Linux build agents and the Jenkins server runs on 
> Windows.  I occasionally see problems like this:
>
> FATAL: 
> com.microsoft.tfs.core.clients.versioncontrol.exceptions.MappingConflictException:
> The path /home/builder/jenkins/workspace/LinuxBuildCompileOnly is already 
> mapped in workspace Hudson-LinuxBuildCompileOnly-devlnx64-04.
>
>
> This occurred on host devlnx64-03.  What is causing this?  A review of the 
> log shows the following:
>
> Deleting workspaces named 'Hudson-LinuxBuildCompileOnly-devlnx64-03' from 
> computer 'devlnx64-03'...
> Deleted 1 workspace(s) named 'Hudson-LinuxBuildCompileOnly-devlnx64-03'.
> Creating workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03' owned by 
> 'WINNTDOM\umtfsservice'...
> Created workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03'.
> Mapping '$/Project/Main' to local folder 
> '/home/builder/jenkins/workspace/LinuxBuildCompileOnly' in
>  workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03'...
>
>
>
> The process removes the old workspace and remakes it.  Why is TFS 
> complaining about this mapping?  Shouldn't it be content to allow the TFS 
> location to be mapped to more than one location on different systems and in 
> different workspaces?  I'm quite curious about this and would appreciate 
> any insights those here might have.
>
> Thanks,
> Andy
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e64bc18e-a903-48d9-951c-522edecf7431%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content-Security-Policy in Jenkins

[Boris Serdiuk]

Well, I read release notes and reasoning behind it but I don't get why that 
breaking change wasn't made as opt-in. 

As I got it affects only build servers for open-source projects. But a lot 
of users with private Jenkins installation just got this update suddenly 
and had got broken workflow. I guess that usually maintainers of 
open-source projects are more advanced users and can enable extra 
protection for its server rather than other users had to do weird actions 
to make some Jenkins extensions back to work.

reede, 8. jaanuar 2016 17:24.04 UTC+3 kirjutas Daniel Beck:
>
> On 08.01.2016, at 11:49, Boris Serdiuk  wrote: 
>
> > Do you have any announcement or migration guide where I can redirect my 
> users? 
>
> Choose any of these, the full documentation is at most two clicks away: 
>
> Security advisory announcement: 
>
> https://groups.google.com/d/msg/jenkinsci-advisories/Zy8yMkQfld4/a8lkB_DUDQAJ 
>
> Announcement blog post: 
> https://jenkins-ci.org/blog/2015/12/09/security-updates-released-today/ 
>
> Regular changelog links to advisory: 
> https://jenkins-ci.org/changelog/#v1.641 
>
> LTS changelog links to advisory: 
> https://jenkins-ci.org/changelog-stable/#v1.625.3 
>
> Security advisory with giant notice on compatibility: 
>
> https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-12-09
>  
>
> Documentation: 
>
> https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy
>  
>
> If you have suggestions how to make this more noticeable without doing 
> giant banners everywhere, or repeating the same information in a dozen 
> places, please let me know. 
>
> > Also, I looking for a better way to relax content security via UI rather 
> than change configuration properties in the file. 
>
> I'm planning to make setting the system property a regular part of the 
> Jenkins global security config UI. It is tracked here: 
> https://issues.jenkins-ci.org/browse/JENKINS-32296 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/4c358304-8db8-45ee-8046-3a8e506d6697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Workflow (pipeline) visual editor

[Craig Rodrigues]

This is good stuff.  I had fun with this plugin:
https://twitter.com/rodrigc6/status/685371839007305728

Some comments:

(1)  It would be nice to somehow be able to see the underlying groovy code
generated by the pipeline-editor.

(2)  It is nice to see "modern" UI design based on "modern" Javascript
components
  becoming more integrated with the Jenkins ecosystem!

--
Craig

On Mon, Dec 21, 2015 at 2:18 AM, Michael Neale 
wrote:

> (I posted this to jenkins-dev last week, but thought some users here may
> be interested).
>
> An experimental graphical editor for Jenkins Workflow is here:
> https://github.com/jenkinsci/pipeline-editor-plugin (details in the
> README.md). Note very "experimental".
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAG%3DrPVfCN%2BO8hasF4UXUCP66LeKMN-ie65OTECdime%3Digy%3DukQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

Stephen,

thanks for the suggestions. I'm sure that with the two methods you 
described it's possible to divide roles into those who can control a docker 
host, and those who can't, and the second method is even safe against 
privilege escalation. The organization I work for is a Cloudbees customer, 
but unfortunately both methods you suggested don't support use cases where 
both groups in your "lock down" scenario must be allowed to configure 
Workflow scripts with `docker.image().inside{}` (and that's what I have in 
mind).

FYI: I did some tests with the "setuid docker proxy" method I proposed. 
Writing a docker shim that filters commands and parameters to prevent 
privilege escalation seems to be feasible (i.e. one that only passes on 
commands, flags, and arguments in compliance with the intended use case in 
Jenkins Workflow). 

/Thomas

On Monday, January 11, 2016 at 11:34:34 PM UTC+1, Stephen Connolly wrote:
>
> You can use a feature such as 
> http://documentation.cloudbees.com/docs/cje-user-guide/foldersplus-sect-controlledslaves.html
>  
> so that only jobs in a specific folder can use the build slave... then you 
> can use an authorization strategy (
> http://documentation.cloudbees.com/docs/cje-user-guide/rbac.html pairs 
> well but there are others) so that only trusted users can configure jobs in 
> that folder... yes there are still ways to hack around if you don't use 
> script security or let untrusted users run jobs on the Jenkins master... 
> but a locked down Jenkins is still possible...
>
> If you want something even more secure you can have multiple Jenkins 
> instances connected together and trigger the jobs on the locked down ones 
> from slightly lesser locked down ones: 
> http://documentation.cloudbees.com/docs/cjoc-user-guide/cluster-triggers.html
>
> All the above is possible (i.e. I wrote a good chunk of that 
> functionality) so even if you didn't want to purchase from CloudBees it is 
> possible to implement the same in plugins (though the CJOC stuff would be a 
> bigger chunk of work)
>
> On 11 January 2016 at 20:01, Thomas Goeppel  > wrote:
>
>> Stephen,
>>
>> thanks for your reply. You're right, nobody would run Jenkins as root in 
>> a production environment, but  through the Cloudbees Docker Workflow plugin 
>> Jenkins is in control of the docker client, and hence it's root on some 
>> machine (e.g. a build slave). 
>>
>> I don't really understand what you mean with "running a build slave as 
>> the trusted account". Maybe I'm missing something here, but from a security 
>> point of view, as soon as untrusted users control a docker host on a build 
>> slave (e.g. through Jenkins job definitions) that build slave is all but 
>> trusted, and an untrusted machine has no place in a corporate network. If 
>> one builds a firewall around an untrusted build slave as mitigation, I 
>> would expect practical problems accessing SCM or artifact repositories 
>> inside the corporate network from that slave.
>>
>> Calling the docker client through Jenkins can be considered safe if 
>> Jenkins runs in a locked down environment (where only trusted users can 
>> define jobs), or if the docker host (build slave) is short lived (e.g. an 
>> ephemeral VM like Boot2Docker). Unfortunately, non of these options would 
>> work for me.
>>
>> /Thomas
>>
>>
>> On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote:
>>>
>>> FYI you do not run *Jenkins* as root... rather you run a build slave as 
>>> the trusted account and then you lock down access to that build slave... 
>>> e.g. if that build slave deploys into production you can use it as a kind 
>>> of bastion host whereby it is off-line until you want to deploy into 
>>> production.
>>>
>>> On 10 January 2016 at 11:17, Thomas Goeppel  
>>> wrote:
>>>


 On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>
> > One option would be to write a shim for the docker command, that 
> only 
> > allows a subset of commands, and sanitizes the options and 
> parameters. 
>
> Even if you do that, the jenkins user, as part of the docker group, 
> will 
> still have direct access to the unix socket that the Docker daemon 
> uses. 
>
>
 As is quite often the case with a CI server, you most likely need to 
> either trust the users who can configure jobs (or edit Workflow 
> scripts 
> (if in source control)), or lock down the Jenkins configuration to 
> allow 
> only specific users. 
>
>

> The Docker security guide also says "only trusted users should be 
> allowed to control your Docker daemon": 
> https://docs.docker.com/engine/articles/security/ 
>
> I feel that you're mixing up two areas of trust here, Jenkins (and CI 
 users), and Docker (and system administrators). In an organization of any 
 size or complexity, the roles allowed to control 

Re: console parsing with master/slave architecture

[iostrym]

thanks, I use also warning plugin but this parser can't be used to see 
warning with respect of the duration time... There is only alphetical order 
:(

So I would like to have a colored view of the console with respect of 
error/warning/note. exactly like 

Console Parser Plugin 
 and log 
parser plugin


Le lundi 11 janvier 2016 13:46:30 UTC+1, Ullrich Hafner a écrit :
>
> You can check the warnings plug-in: here you can define your own parser 
> using Groovy…
>
> Am 11.01.2016 um 13:06 schrieb iostrym :
>
> Hi all,
>
> I'm looking for a console parsing that don't need a file in the jenkins 
> server. Because I have no physical access to the linux server.
>
> But if the parser could be configurer using a test field inside jenkins, 
> it could be great.
>
> two parser that I have look for that : 
> Console Parser Plugin 
>  and 
> log parser plugin
> need a parser file on the jenkins server to work.
>
> Any idea ?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-use...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/a7f3e464-a1e5-4830-b701-212c764ae409%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9db67c7d-35d2-40a0-a67c-05de0028266b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: testng's emailable-report.html loses its skin when view at Jenkins after upgrading to STS 1.625.3

[Mark Waite]

I think you're seeing the content security policy change in 1.625.  Refer
to
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy
for
more information on the policy and ways you can relax the policy as needed
for your use case.

Mark Waite

On Sun, Jan 10, 2016 at 10:58 PM Dan Tran  wrote:

>
> Hi
>
> After upgrading from STS 1.609 to 1.625, my testng's emailable-report.html
> is fine when view as standalone Html file ( ie send the file to user).
> However when viewing under Jenkins, the html's content loses its skin/css
>
> I am sure the same issue happens to any generated html content.
>
> Do you see the same issue?
>
> Thanks
>
> -D
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/49196dfb-207d-4ec5-85bf-95a69a7def1d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGPMXgS%2Bwbdd_YMW5Jz0zF0498t%3DZ4Uo4SArxG1t2mYAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security best practice for Cloudbees Docker Workflow?

[Stephen Connolly]

FYI you do not run *Jenkins* as root... rather you run a build slave as the
trusted account and then you lock down access to that build slave... e.g.
if that build slave deploys into production you can use it as a kind of
bastion host whereby it is off-line until you want to deploy into
production.

On 10 January 2016 at 11:17, Thomas Goeppel 
wrote:

>
>
> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>>
>> > One option would be to write a shim for the docker command, that only
>> > allows a subset of commands, and sanitizes the options and parameters.
>>
>> Even if you do that, the jenkins user, as part of the docker group, will
>> still have direct access to the unix socket that the Docker daemon uses.
>>
>>
> As is quite often the case with a CI server, you most likely need to
>> either trust the users who can configure jobs (or edit Workflow scripts
>> (if in source control)), or lock down the Jenkins configuration to allow
>> only specific users.
>>
>>
>
>> The Docker security guide also says "only trusted users should be
>> allowed to control your Docker daemon":
>> https://docs.docker.com/engine/articles/security/
>>
>> I feel that you're mixing up two areas of trust here, Jenkins (and CI
> users), and Docker (and system administrators). In an organization of any
> size or complexity, the roles allowed to control Jenkins won't be held by
> the same people that have the roles with root access. Even if it were so,
> just how much would one have to lock down a Jenkins production environment
> to mitigate the risks associated with running Jenkins as root, i.e. user
> "jenkins" in the group "docker"?
>
> We could give up on provisioning containerized toolchains through Jenkins
> in a Non-Root-Jenkins production environment, but there is a lot of value
> in running and controlling Docker containers through Jenkins. Fortunately,
> full control of Docker isn't required for this use case: Jesse Glick
> demonstrated that nicely with the implementation of docker.image().inside
> {} that passes reasonably safe parameters through the Docker CLI (e.g. -u
> non-root).
>
> Obviously, delegation of watching over safe use of the Docker CLI to
> Jenkins isn't possible in any environment where we can't run Jenkins as
> "root" ("docker"), and hence we need a trusted proxy. Technically that
> proxy might run with "setuid docker" (and have access to the Unix socket),
> or use a web service, but I think that the docker counterpart to a "restricted
> shell " would be best.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMzzUaSbkC7C3DxQ8KOtYDh3vGpe1Cnzw3v-%2B4snAxtZ8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

security based project behavior jenkins v1.504

[iostrym]

Hi, 

I'm using project matrix security on jenkins v1.504 (arround 2013)

So I configure user access in Jenkins Configure Global Security and also 
 inside jobs (project).

As I read documentation, the project matrix should be cumulative with 
matrix in global security.

Does it says that if a user has job modification rights in global security 
he could do job modification on all jobs. even on jobs that are protected 
using project based security ? If yes, it is strange because I don't notice 
this behavior everytime but sometimes I meet case where a user can do 
modification in a job whereas the job has project based security.

What would be the correct configuration for users in global configuration 
if we want them to be able to see all jobs but be able to do modification 
only on their jobs (is it always the case ?) and on jobs that has a project 
based security that allow this.

I don't want to use cloudbee plugin, and i'm trying to understand how 
jenkins works without any specific plugin for security.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e9c9ef2d-327c-4f05-b7bb-25aa82d07726%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

console parsing with master/slave architecture

[iostrym]

Hi all,

I'm looking for a console parsing that don't need a file in the jenkins 
server. Because I have no physical access to the linux server.

But if the parser could be configurer using a test field inside jenkins, it 
could be great.

two parser that I have look for that : 
Console Parser Plugin 
 and log 
parser plugin
need a parser file on the jenkins server to work.

Any idea ?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a7f3e464-a1e5-4830-b701-212c764ae409%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: console parsing with master/slave architecture

[Ullrich Hafner]

You can check the warnings plug-in: here you can define your own parser using 
Groovy…

> Am 11.01.2016 um 13:06 schrieb iostrym :
> 
> Hi all,
> 
> I'm looking for a console parsing that don't need a file in the jenkins 
> server. Because I have no physical access to the linux server.
> 
> But if the parser could be configurer using a test field inside jenkins, it 
> could be great.
> 
> two parser that I have look for that :
> Console Parser Plugin 
>  and log 
> parser plugin
> need a parser file on the jenkins server to work.
> 
> Any idea ?
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/a7f3e464-a1e5-4830-b701-212c764ae409%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/BFDD2B4F-36C0-492D-B12B-C002B3E25347%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Auto Job Creation When new Git Repo is Created

[dane]

Can anyone recommend a Jenkins plugin (or config setup) that automatically 
create Jenkins jobs from templates when a new gitlab repo is created?  I'm 
looking at Jenkins-autojobs plugin now but it looks like it's limited to 
creating new jobs only when a new branch is created.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0a38ab27-b69b-4055-bfbc-796c45405af7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Opening Html files failed

[techie24by7]

Hello all,


i am currently using Jenkins ver. 1.643  .  I tried 
work around of adding below highlighted to jenkins.xml suggested in the 
internet but didnt work for me. Could someone please suggest me on this 
error.


In windows based Jenkins we have service for stop/start .

I assumed below is the place where it is taking the arguments i have added 
those to Jenkins.xml.  here is complete xml.  please let me know if i am 
adding at wrong place.


  jenkins
  Jenkins
  This service runs Jenkins continuous integration 
system.
  
  
  %BASE%\jre\bin\java
  -Xrs -Xmx256m *-Dhudson.model.DirectoryBrowserSupport.CSP=* 
-Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle 
-jar "%BASE%\jenkins.war" --httpPort=8080
  
  rotate

  




*Errors:*

Opening Robot Framework report failed

   - Verify that you have *JavaScript enabled* in your browser.
   - Make sure you are using a *modern enough browser*. Firefox 3.5, IE 8, 
   or equivalent is required, newer browsers are recommended.
   - Check are there messages in your browser's *JavaScript error log*. 
   Please report the problem if you suspect you have encountered a bug.

- show quoted text -

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/70e74d95-e609-4471-abd4-626e0d76a4a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Master/Slave configurations

[techie24by7]

Hello All,

In jenkins can we have master/slave configurations in windows and linux 
vice versa.

Appreciate your inputs

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/bba3b08d-b1e7-48ae-a6c0-3bd6a1af0a93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins-events] Clarification on CIA program

[Alyssa Tong]

+1 - IMO JAM organizers are technically Jenkins ambassadors.

On Sun, Jan 10, 2016 at 11:43 AM, Oleg Nenashev 
wrote:

> Added the developers ML to Cc.
>
> Maybe my question is out of the track...
> Do we really need the "Jenkins CIA" program now? I've never seen it to be
> used actively during last 4 years.
>
>- "CIA" term is really outdated, because we try to shift the focus
>from Continuous Integration
>- JAMs have organizers, who are supposed to do the "ambassador"'s work
>if I understand correctly
>- Big Jenkins-related conferences also have organizers, who blog about
>it
>
> So the only problem is the events not focused on Jenkins (e.g. FOSDEM or
> whatever generic conference). BTW people on such conferences can
> self-organize.
>
> BR, Oleg
>
> 2016-01-10 21:28 GMT+03:00 Alyssa Tong :
>
>> Hi Jonathan,
>>
>> Do you mean Jenkins meetups? If so, existing Jenkins meetup groups are
>> HERE .
>> Currently there is no meetup group in Washington DC we'd love to have you
>> as organizer if you're up for it.
>>
>> If your question is pertaining to CIA
>> , we
>> currently have a couple ambassadors out there - one in France and 2 in Peru
>> that i'm aware of.
>>
>> thanks,
>> alyssa
>>
>> On Sun, Jan 10, 2016 at 4:49 AM, Jonathan Jenkins <
>> jonathan.jenk...@clearlyagile.com> wrote:
>>
>>> Where do we see a list of these groups?  I ask as I would like to start
>>> or participate in one in the Washington DC area.
>>>
>>>
>>>
>>> Jonathan Jenkins
>>>
>>> CEO/Chief Methodologist
>>>
>>> Certified SAFe Program Consultant (SAFe SPC), Certified Scrum
>>> Professional /Master (CSP/CSM)
>>>
>>> Mobile +1 240-271-0463
>>> jonathan.jenk...@clearlyagile.com | www.ClearlyAgile.com
>>> 
>>>
>>> LinkedIn 
>>>
>>>
>>>
>>> *From:* Jenkins-events [mailto:
>>> jenkins-events-boun...@lists.jenkins-ci.org] *On Behalf Of *Alyssa Tong
>>> *Sent:* Monday, November 2, 2015 6:39 PM
>>> *To:* eve...@lists.jenkins-ci.org; jenkinsci-users <
>>> jenkinsci-users@googlegroups.com>
>>> *Subject:* [Jenkins-events] Clarification on CIA program
>>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> Recently there was an inquiry on the CIA
>>> 
>>> program which resulted in questions for qualifications to be a CIA. We
>>> should update this page
>>>  so
>>> that requirements are clearer for those interested in the program .
>>>
>>>
>>>
>>> thanks
>>>
>>> alyssa
>>>
>>
>>
>> ___
>> Jenkins-events mailing list
>> jenkins-eve...@lists.jenkins-ci.org
>> http://lists.jenkins-ci.org/mailman/listinfo/jenkins-events
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAC9wNayJAL57z4Ci1p5W%3DuXF6h6jhXdmaeVOQ28KLFvvZBLa5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

Stephen,

thanks for your reply. You're right, nobody would run Jenkins as root in a 
production environment, but  through the Cloudbees Docker Workflow plugin 
Jenkins is in control of the docker client, and hence it's root on some 
machine (e.g. a build slave). 

I don't really understand what you mean with "running a build slave as the 
trusted account". Maybe I'm missing something here, but from a security 
point of view, as soon as untrusted users control a docker host on a build 
slave (e.g. through Jenkins job definitions) that build slave is all but 
trusted, and an untrusted machine has no place in a corporate network. If 
one builds a firewall around an untrusted build slave as mitigation, I 
would expect practical problems accessing SCM or artifact repositories 
inside the corporate network from that slave.

Calling the docker client through Jenkins can be considered safe if Jenkins 
runs in a locked down environment (where only trusted users can define 
jobs), or if the docker host (build slave) is short lived (e.g. an 
ephemeral VM like Boot2Docker). Unfortunately, non of these options would 
work for me.

/Thomas


On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote:
>
> FYI you do not run *Jenkins* as root... rather you run a build slave as 
> the trusted account and then you lock down access to that build slave... 
> e.g. if that build slave deploys into production you can use it as a kind 
> of bastion host whereby it is off-line until you want to deploy into 
> production.
>
> On 10 January 2016 at 11:17, Thomas Goeppel  > wrote:
>
>>
>>
>> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>>>
>>> > One option would be to write a shim for the docker command, that only 
>>> > allows a subset of commands, and sanitizes the options and parameters. 
>>>
>>> Even if you do that, the jenkins user, as part of the docker group, will 
>>> still have direct access to the unix socket that the Docker daemon uses. 
>>>
>>>
>> As is quite often the case with a CI server, you most likely need to 
>>> either trust the users who can configure jobs (or edit Workflow scripts 
>>> (if in source control)), or lock down the Jenkins configuration to allow 
>>> only specific users. 
>>>
>>>
>>
>>> The Docker security guide also says "only trusted users should be 
>>> allowed to control your Docker daemon": 
>>> https://docs.docker.com/engine/articles/security/ 
>>>
>>> I feel that you're mixing up two areas of trust here, Jenkins (and CI 
>> users), and Docker (and system administrators). In an organization of any 
>> size or complexity, the roles allowed to control Jenkins won't be held by 
>> the same people that have the roles with root access. Even if it were so, 
>> just how much would one have to lock down a Jenkins production environment 
>> to mitigate the risks associated with running Jenkins as root, i.e. user 
>> "jenkins" in the group "docker"? 
>>
>> We could give up on provisioning containerized toolchains through Jenkins 
>> in a Non-Root-Jenkins production environment, but there is a lot of value 
>> in running and controlling Docker containers through Jenkins. Fortunately, 
>> full control of Docker isn't required for this use case: Jesse Glick 
>> demonstrated that nicely with the implementation of docker.image().inside 
>> {} that passes reasonably safe parameters through the Docker CLI (e.g. -u 
>> non-root).
>>
>> Obviously, delegation of watching over safe use of the Docker CLI to 
>> Jenkins isn't possible in any environment where we can't run Jenkins as 
>> "root" ("docker"), and hence we need a trusted proxy. Technically that 
>> proxy might run with "setuid docker" (and have access to the Unix socket), 
>> or use a web service, but I think that the docker counterpart to a 
>> "restricted 
>> shell " would be best.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e20cbe1a-6da3-4e39-86cc-7055b5109995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.