Amazon EC2 plugin issues with Windows agents

[alok kumar]

Hi All,
I have been trying to get windows agents spun up in Amazon EC2 via Jenkins
using the Amazon EC2 plugin.
The agents are getting launched fine, but, Jenkins is not able to connect
to them at all.
No matter whatever settings I try, like, I have this in my userdata section:












*$Script:ErrorActionPreference =
[System.Management.Automation.ActionPreference]::Stopmkdir
'C:\Jenkins'Enable-PSRemoting -Forcewinrm set winrm/config/service/Auth
'@{Basic="true"}'winrm set winrm/config/service
'@{AllowUnencrypted="true"}'winrm set winrm/config/winrs
'@{MaxMemoryPerShellMB="1024"}'Set-NetFirewallRule -Name
'WINRM-HTTP-In-TCP-PUBLIC' -RemoteAddress AnyNew-NetFirewallRule -Name
jenkins -DisplayName jenkins -Direction Inbound -Action Allow -Protocol TCP
-LocalPort Any -Profile AnyRestart-Service WinRMSet-ExecutionPolicy
-ExecutionPolicy Bypass -Scope LocalMachine*

This is based on all the suggestions that I could gather online, but, it
doesnt work.
I keep getting:

Waiting for WinRM to come up. Sleeping 10s.

Connecting to (xx.xx.xx.xx) with WinRM as Administrator


Can anyone please help me with some suggestion on how to get this working?

I see that F Manfred Furuholen, Julien Duchesne, *Matt Sicker *are the
maintainers of this plugin. Can you guys suggest something, please?

*I have tried with even the latest version 1.45 of the plugin and my master
is on version 2.176.3 *

Thanks
Alok

-- 
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/CAOqqq4SEQ1x1Y%2B5mRH0TCwzgqffJzj9FthSf55fJ3iU_357jmA%40mail.gmail.com.

Re: Restrict credential retrieval to a specific slave

[Mark Waite]

On Thu, Sep 19, 2019 at 8:41 AM Jhonny Oliveira 
wrote:

> Dear Mark,
>
> I agree with you, I'm relying on long-lived agents. I read your answer,
> but I'm not understanding your suggestion to use folders, I do not
> comprehend how they can help. I mean, with folders I can avoid cross
> application credential usage and that is great, but I can't prevent cross
> environment credential leakage within the same application.
>
>
My suggestion is

   - Dev-Folder defines a credential (scoped to Dev-Folder) with ID
   'weblogic-deploy-credential-2019-09-19'
  - Job inside Dev-Folder refers to credential
  'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to dev
   - Test-Folder defines a credential (scoped to Test-Folder) with ID '
   weblogic-deploy-credential-2019-09-19'
  -   Job inside Test-Folder refers to credential
  'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to test

The same source code can be used for the job inside Dev-Folder and the job
inside Test-Folder if the other things that vary between dev and test are
also parameterized in that job.  In the case you provided, rather than
URL_TST and URL_DEV, you would define a parameter DESTINATION_URL and would
pass in the test value.  The "folder properties" plugin looks like it may
be needed in that case so that each folder can have its own value for the
DESTINATION_URL without requiring that developers pass the parameter to the
job.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to deploy
to test, it will be rejected because the credentials in the Dev-Folder
don't have permission to deploy to test.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to
display the values of the credentials, only the credentials from the
Dev-Folder will be exposed.


> Please have a look at the code snippet below. As you will be able to see,
> with this implementation nothing prevents anyone with access to the source
> code from flipping the IDs around and getting the credentials in the wrong
> environment (mistake or malicious action). Furthermore, and to give a
> little extra context, the Pipeline is completely autonomous and will be
> triggered automatically on every (almost) pull request. It is also smart
> enough to detect a release and proceed towards production (with some
> approvals - of course - to adhere to release management).
>
> In such scenario, and considering that the agents only have access to
> their own environment, the only way to prevent a credential to be used or
> exposed in the wrong one would be to deliberately restrict it to that
> specific agent.
>
> Maybe I'm taking this idea of automation and complete SDLC from source to
> far! :-)
>
> I appreciate your answers, thanks you!
> J. Oliveira
>
> def WLS_CRED_DEV=’111aaa11-a3a1-4aab-9a20-a1166a80’
> def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a1166a80 ‘
> (…)
> stage ('Deploy to DEV') {
> agent { label "${agent_dev}"}
> steps {
> script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_DEV",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
> sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_DEV}'"
> }
> }
> }
> }
> stage ('Deploy to TST) {
> agent { label "${agent_tst}"}
> steps {
> script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_TST",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
> sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_TST}'"
> }
> }
> }
> }
>
>
> --
> 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/ac762c3b-3488-4a4f-a8f5-2408aac38284%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

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

Re: Jenkins Docker Image and extended Linux executables

[Mark Waite]

On Thu, Sep 19, 2019 at 8:10 AM 'Carsten' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Hi,
> we are running Jenkins in a docker environment.
> Jenkins Version 2.192
> running in a docker container version 19.03.2, build 6a30dfc
> Running on an Ubuntu Xenial 16.04
> We are deploying by Linux shell scripts using multiple extended Linux
> commands like "netcat" or "nslookup".
>
> Unfortunately the Jenkins image seems to deny such commands.
> In a first attempt it cannot find the commands, because they are out of
> the running environment (even setting "PATH" does NOT help):
>
> /var/jenkins_home/workspace/[branchpath]/Pipeline/accesstest.sh: line 19:
> nslookup: No such file or directory
>
> and in a second attempt copying the files into the home path of Jenkins,
> it misses the libraries:
>
> "../var/jenkins_home/nslookup: error while loading shared libraries:
> libdns.so.162: cannot open shared object file: No such file or directory.."
>
> How can I solve this problem?
>
>
It is more generally preferred to limit the amount of work and the number
of programs installed on the Jenkins master.  Usually it is better to
specify agents which include the desired programs rather than placing those
programs on the master.

If you find that there are cases where you absolutely must install the
programs on the master, then you can create your own Dockerfile which is
based on the Jenkins Dockerfile and adds the programs you need using the
appropriate operating system commands (like `apt-get install`).

Mark Waite


> br
> Carsten
>
>
>
>
> --
> 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/b9156977-a8a4-4f21-8f25-9325defffde3%40googlegroups.com
> 
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEt_MoSrmcNNmy5JW053hMxbJN-%2BjH2w%2BcEHV%2BHrSuCAQ%40mail.gmail.com.

Re: Restrict credential retrieval to a specific slave

[Jhonny Oliveira]

Dear Mark,

I agree with you, I'm relying on long-lived agents. I read your answer, but I'm 
not understanding your suggestion to use folders, I do not comprehend how they 
can help. I mean, with folders I can avoid cross application credential usage 
and that is great, but I can't prevent cross environment credential leakage 
within the same application.

Please have a look at the code snippet below. As you will be able to see, with 
this implementation nothing prevents anyone with access to the source code from 
flipping the IDs around and getting the credentials in the wrong environment 
(mistake or malicious action). Furthermore, and to give a little extra context, 
the Pipeline is completely autonomous and will be triggered automatically on 
every (almost) pull request. It is also smart enough to detect a release and 
proceed towards production (with some approvals - of course - to adhere to 
release management).

In such scenario, and considering that the agents only have access to their own 
environment, the only way to prevent a credential to be used or exposed in the 
wrong one would be to deliberately restrict it to that specific agent.

Maybe I'm taking this idea of automation and complete SDLC from source to far! 
:-)

I appreciate your answers, thanks you!
J. Oliveira

def WLS_CRED_DEV=’111aaa11-a3a1-4aab-9a20-a1166a80’
def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a1166a80 ‘
(…)
stage ('Deploy to DEV') {
agent { label "${agent_dev}"}
steps {
script {

withCredentials([usernamePassword(credentialsId: "$WLS_CRED_DEV", 
usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
sh "mvn -U weblogic:redeploy 
-DskipTests=true -Dfailonerror=true -Duser='${WL_USER}' -Dpassword='${WL_PASS}' 
-Dname=${ARTIFACTID} -Dupload=true -Dsource=target/${ARTIFACTID}-${VERSION}.war 
-Dtargets=${ARTIFACTID} -Dadminurl='${URL_DEV}'"
}
}
}
}
stage ('Deploy to TST) {
agent { label "${agent_tst}"}
steps {
script {

withCredentials([usernamePassword(credentialsId: "$WLS_CRED_TST", 
usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
sh "mvn -U weblogic:redeploy 
-DskipTests=true -Dfailonerror=true -Duser='${WL_USER}' -Dpassword='${WL_PASS}' 
-Dname=${ARTIFACTID} -Dupload=true -Dsource=target/${ARTIFACTID}-${VERSION}.war 
-Dtargets=${ARTIFACTID} -Dadminurl='${URL_TST}'"
}
}
}
}


-- 
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/ac762c3b-3488-4a4f-a8f5-2408aac38284%40googlegroups.com.

Jenkins Docker Image and extended Linux executables

['Carsten' via Jenkins Users]

Hi,
we are running Jenkins in a docker environment.
Jenkins Version 2.192
running in a docker container version 19.03.2, build 6a30dfc
Running on an Ubuntu Xenial 16.04 
We are deploying by Linux shell scripts using multiple extended Linux 
commands like "netcat" or "nslookup".

Unfortunately the Jenkins image seems to deny such commands.
In a first attempt it cannot find the commands, because they are out of the 
running environment (even setting "PATH" does NOT help):

/var/jenkins_home/workspace/[branchpath]/Pipeline/accesstest.sh: line 19: 
nslookup: No such file or directory

and in a second attempt copying the files into the home path of Jenkins, it 
misses the libraries:

"../var/jenkins_home/nslookup: error while loading shared libraries: 
libdns.so.162: cannot open shared object file: No such file or directory.."

How can I solve this problem?

br
Carsten




-- 
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/b9156977-a8a4-4f21-8f25-9325defffde3%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

[Mark Waite]

On Thu, Sep 19, 2019 at 6:30 AM Jhonny Oliveira 
wrote:

> The idea is to have a self contained application (as in source repo),
> where you have everything you need to maintain its SDLC: source, build,
> tests (unit, regression, ...), continuous integration/automation
> (Jenkinsfile).
>
> The Jenkinsfile should be part of the source code and cover the entire
> process (end to end). Breaking it into pieces kind of defeats our main
> purpose of having everyone working together in the same source (developers,
> testers, operations, ...).
>
>
Yes, that's the right way to do it.  You've described the storage of the
definition of the application very well.  Keep it all in source code and
run it from source.

Place the limited use credential on a folder in Jenkins, then control who
is allowed to access that folder.  The jobs inside the folder will be able
to use the credential.  Jobs outside the folder won't have access to the
credential.


> Is there any chance such feature could be included in future releases? To
> whom can I address this question?
>
>
This is the right place to address the question.

I'm not aware of anyone working to add credentials to agents.  Since agents
are treated more and more as ephemeral workers that are exist only long
enough to perform their task and are then discarded, it seems unlikely that
anyone would add credential storage to agents.

There are still plenty of cases where agents live a long time (as in your
case), but Jenkins work now needs to consider both long-lived agents and
ephemeral agents.  Most capabilities that are being added are done so that
they can be used with all types of agents.


> --
> 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/fca0f38f-1b9a-4843-8572-fb77dc716aa7%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFWwo4vp2sHhF5Og-N%2Bt4FoH6QaGNF%3DoCGuZsCE_0QUYg%40mail.gmail.com.

Match multiple branches with Git plugin

[Technical Lead]

Hi, I'm trying to use the Git plugin (with the GitHub plugin) to trigger 
builds on multiple branches with a single branch specifier rule.  However, 
the job only appears to trigger when there are changes to on the "first" 
matching branch.  I've tried wildcards (i.e. origin/dev/*) and regexes 
(i.e. :^origin/dev/.*), to no avail.  The limited documentation sort of 
indicates that the wildcard method would only use the first matching 
branch, but it's unclear for a regex.  I'd rather not reconfigure the job 
every time a new branch is added to list it explicitly in a branch 
specifier.

-- 
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/76d496e6-edea-4ff9-b317-bdc69481f955%40googlegroups.com.

Match multiple branches with Git plugin

[Technical Lead]

Hi, I'm trying to use the Git plugin (with the GitHub plugin) to trigger 
builds on multiple branches with a single branch specifier rule.  However, 
the job only appears to trigger when there are changes to on the "first" 
matching branch.  I've tried wildcards (i.e. origin/dev/*) and regexes 
(i.e. :^origin/dev/.*), to no avail.  The limited documentation sort of 
indicates that the wildcard method would only use the first matching 
branch, but it's unclear for a regex.  I'd rather not reconfigure the job 
every time a new branch is added to list it explicitly in a branch 
specifier.

-- 
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/1285a257-8108-464f-b692-3d18d8ea1aa1%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

[Dirk Heinrichs]

Am Donnerstag, den 19.09.2019, 05:26 -0700 schrieb Jhonny Oliveira:

What do you mean with agents?

Jenkins people have stopped using the word "slave" some time ago.

Bye...

Dirk

--

Dirk Heinrichs
Senior Systems Engineer, Delivery Pipeline
OpenText ™ Discovery | Recommind
Phone: +49 2226 15966 18
Email: dhein...@opentext.com
Website: www.recommind.de
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan, 
Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet.

-- 
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/935083deb1d09f9bca2fb321c9a9e5be49b341c6.camel%40opentext.com.

Re: Restrict credential retrieval to a specific slave

[Jhonny Oliveira]

The idea is to have a self contained application (as in source repo), where you 
have everything you need to maintain its SDLC: source, build, tests (unit, 
regression, ...), continuous integration/automation (Jenkinsfile).

The Jenkinsfile should be part of the source code and cover the entire process 
(end to end). Breaking it into pieces kind of defeats our main purpose of 
having everyone working together in the same source (developers, testers, 
operations, ...).

Is there any chance such feature could be included in future releases? To whom 
can I address this question?

-- 
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/fca0f38f-1b9a-4843-8572-fb77dc716aa7%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

[Jhonny Oliveira]

What do you mean with agents?

The idea is to have a self contained application (as in source repo), where you 
have everything you need to maintain its SDLC: source, build, tests (unit, 
regression, ...), continuous integration/automation (Jenkinsfile). The 
Jenkinsfile should be part of the source code and cover the entire process (end 
to end). Breaking it into pieces kind of defeats our main purpose of having 
everyone working together in the same source (developers, testers, operations).

-- 
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/8f589383-dfca-40d5-b5ef-1296997bf006%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

[Mark Waite]

On Thu, Sep 19, 2019 at 4:21 AM Jhonny Oliveira 
wrote:

> Hi!
>
> is it possible to limit the usage of a credential to a specific slave?
>

Not with Jenkins as far as I know.  Credentials can be defined on the
Jenkins master, on folders, and on multibranch Pipelines.  They can't be
defined on Freestyle jobs or on agents.


> With this restriction, I could fully empower developers to create their
> own Pipelines (Jenkinsfile) while avoiding passwords to be leaked in the
> wrong slaves/environments.
>

Could you attach the credentials to a folder and then limit access to the
folders instead?  Those with access to the folder can use the credential
attached to that folder.  Those without access to the folder could not use
that credential.


>
> Just for further context, in my scenario and at infrastructure level, only
> specific slaves are allowed to deploy to specific environments. E.g.:
> dev_slave -> deploy to DEV; tst_slave -> deploy to TST and so on.
>
> Cheers,
> Jhonny Oliveira
>
> --
> 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/2540cf8f-0413-4ec1-ae4a-136f2eeaf894%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFCvn4k-DW%2BY5ew30bLAhaNBc-UHgaFx6dDTn17qAoyRQ%40mail.gmail.com.

Re: Enable "Post Build Action" in Jenkins

[Kheng How Tan]

Hi,

You may refer to here:
https://jenkins.io/doc/book/pipeline/syntax/#post

In general, you will code all the post build in pipeline post() block, such
as email-ext, archive-artifacts, etc.

Hope this helps.

Best regards,
KH

On Thu, Sep 19, 2019 at 12:04 AM Binay Jena  wrote:

> Thank you Vijay for the call out...
>
> The only way to implement post-build action is through additional scripts
> in the pipeline job? Does it also mean, this has to be done individually
> for all the pipeline jobs.
> Is there a code snippet/link that you can direct to?
>
>
>
> On Tuesday, September 17, 2019 at 6:48:03 PM UTC-7, Vijay Gongle wrote:
>>
>> Looks like this is a pipeline job and you wouldn’t have the post build
>> action unlike a freestyle job.
>>
>> Thanks,
>> Vijay
>>
>>
>>
>> On Sep 17, 2019, at 7:00 PM, Binay Jena  wrote:
>>
>> We're missing the "Post Build Actions" tab in Jenkins (attached
>> screengrab FYR). I've tried installing plugins for enabling this, but none
>> of it has worked so far.
>>
>> Would appreciate any direction/thoughts with respect to resolving this.
>>
>> *Jenkins version: 2.164.3*
>>
>> What other details for the environment would be required to identify what
>> is missing in our environment.. please let me know.
>>
>> --
>> 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 jenkins...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/1da2e39b-c6ff-404c-8b00-e305e78a90a5%40googlegroups.com
>> 
>> .
>>
>> 
>>
>> --
> 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/6833d463-55b4-4f9d-823f-29e658e398e5%40googlegroups.com
> 
> .
>

-- 
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/CAMagqRbpDgLK6b3MjJh03P9LeYnrYWVj7ZQ%3DTJSriyS6y2MbhQ%40mail.gmail.com.

Restrict credential retrieval to a specific slave

[Jhonny Oliveira]

Hi!

is it possible to limit the usage of a credential to a specific slave?

With this restriction, I could fully empower developers to create their own 
Pipelines (Jenkinsfile) while avoiding passwords to be leaked in the wrong 
slaves/environments.

Just for further context, in my scenario and at infrastructure level, only 
specific slaves are allowed to deploy to specific environments. E.g.: dev_slave 
-> deploy to DEV; tst_slave -> deploy to TST and so on.

Cheers,
Jhonny Oliveira

-- 
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/2540cf8f-0413-4ec1-ae4a-136f2eeaf894%40googlegroups.com.

Re: SSH agent uses username 'jenkins' instead of the one configured in the credential

[DexterMagnific]

Thank you for your response.

I'm afraid I'm using the latest Git client plugin: 2.8.6, and also the 
right protocol (ssh): the SCM checkout went well when running the pipeline 
on the parent repo. Out test database is a submodule of the repository and 
we only clone it if the build is OK, hence the stage "download test db":

jenkins@192.168.20.23: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'ssh://192.168.20.23:29418/testDB' into submodule path 
'/var/lib/jenkins/workspace/MyProject/testDB' failed
Failed to clone 'testDB'. Retry scheduled

You see that I did not include an URL in the git command because I only 
want to checkout the submodules.

Regarding openSSH, I think I'm up to date, I'm using the latest Ubuntu 
18.04 packages.


On Thursday, September 19, 2019 at 2:19:55 AM UTC+2, Mark Waite wrote:
>
> If you're running an outdated version of the git client plugin and a newer 
> version of OpenSSH (7.7 and later), then you might be encountering 
> https://issues.jenkins-ci.org/browse/JENKINS-50573 .  Git plugin versions 
> prior to 
>
> If you're running the current git client plugin (2.8.6) or running an 
> OpenSSH older than 7.7, then you might be mistakenly using an http or https 
> protocol URL.  The ssh protocol is either ssh://hostname/dir/path or 
> username@hostname:dir/path.  `git remote -v` will report the URL of the 
> remote in that repository.
>
> On Tue, Sep 17, 2019 at 4:27 AM DexterMagnific  > wrote:
>
>> Hi all,
>>
>> I have big troubles making 'git' commands inside a pipeline file.
>>
>> I have the following command:
>>
>>  stage('Download test database') {
>>   steps {
>> sshagent(credentials: ['----']) 
>> {*/
>>   sh 'git submodule update --init --recursive'
>> }
>>   }
>> }
>>
>> The problem is that git is called with the user 'jenkins' instead of the 
>> one that is specified inside the credential (which is 'jenkins-serv') I get 
>> a "permission denied" from the git server.
>>
>> [Pipeline] // stage
>> [Pipeline] stage
>> [Pipeline] { (Download test database)
>> [Pipeline] sh
>> + git submodule update --init --recursive
>> Cloning into '/var/lib/jenkins/workspace/MyProject/testDB'...
>> jenkins@192.168.20.23: Permission denied (publickey).
>> fatal: Could not read from remote repository.
>>
>>
>> Did I miss something on the pipeline setup ?
>>
>> 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 jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/b5f85d92-adfd-496c-b7c8-2d7a34ad4b21%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Thanks!
> Mark Waite
>

-- 
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/8a34fbbe-80e3-41f5-b501-10e0582079d8%40googlegroups.com.