Re: Deploy Website in Jenkins to Tomcat

[eric....@gmail.com]

I think I figured out what I'm going to do.  Just ssh to the server and rm 
-rf , explode the new tarball into my working 
directory, then scp it over to the site.  Do I need to reload at the site 
or will it recognize the change and implement it?

On Tuesday, March 12, 2024 at 11:45:34 AM UTC-6 eric@gmail.com wrote:

> Hi All,
>
> Deploying a war file via Jenkins pipeline is pretty easy.  That said, I'm 
> not finding any information about deploying an html website using Jenkins.  
> I have a tarball containing a website in it that needs to go to a server, 
> context /myWebSite.  Any advise or pointers to "how to's" on this?
>
> Thanks,
> Eric
>

-- 
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/124786ce-7cd6-4d30-a743-b37478945b08n%40googlegroups.com.

Deploy Website in Jenkins to Tomcat

[eric....@gmail.com]

Hi All,

Deploying a war file via Jenkins pipeline is pretty easy.  That said, I'm 
not finding any information about deploying an html website using Jenkins.  
I have a tarball containing a website in it that needs to go to a server, 
context /myWebSite.  Any advise or pointers to "how to's" on this?

Thanks,
Eric

-- 
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/f97726d7-115a-43df-910a-00720c6c5ca9n%40googlegroups.com.

Re: Unable to Save Project

[eric....@gmail.com]

Thanks so much Mark, that fixed it!!!

On Monday, December 4, 2023 at 2:59:27 PM UTC-7 eric@gmail.com wrote:

> OK, well I have 1.4.2.  That said, I have 82 updates so I'll do as you say 
> and update everything.  Hopefully this covers it.  Thanks Mark!!!
>
> On Monday, December 4, 2023 at 2:44:29 PM UTC-7 Mark Waite wrote:
>
>> On Monday, December 4, 2023 at 2:29:11 PM UTC-7 Eric wrote:
>>
>> I've started going through the plugins that have issues and pretty 
>> quickly ran into the "conditional buildstep" plugin.  I can't disable this 
>> plugin because I use it.  Do you have any suggestions?
>>
>> Thanks,
>> Eric
>>
>>
>> The conditional build step plugin was fixed in 1.4.0 
>> <https://plugins.jenkins.io/conditional-buildstep/releases/#version_1.4.0> 
>> for configuration form modernization.  The most recent release is 1.4.3.
>>
>> If you haven't updated to latest releases of the plugins, that's 
>> certainly the first step.
>>
>> 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/53dbfc0a-ecb0-4949-ae28-09b9f7558872n%40googlegroups.com.

Re: Unable to Save Project

[eric....@gmail.com]

OK, well I have 1.4.2.  That said, I have 82 updates so I'll do as you say 
and update everything.  Hopefully this covers it.  Thanks Mark!!!

On Monday, December 4, 2023 at 2:44:29 PM UTC-7 Mark Waite wrote:

> On Monday, December 4, 2023 at 2:29:11 PM UTC-7 Eric wrote:
>
> I've started going through the plugins that have issues and pretty quickly 
> ran into the "conditional buildstep" plugin.  I can't disable this plugin 
> because I use it.  Do you have any suggestions?
>
> Thanks,
> Eric
>
>
> The conditional build step plugin was fixed in 1.4.0 
>  
> for configuration form modernization.  The most recent release is 1.4.3.
>
> If you haven't updated to latest releases of the plugins, that's certainly 
> the first step.
>
> 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/8b8c479e-bae7-43a4-86d1-10798d646ca5n%40googlegroups.com.

Re: Unable to Save Project

[eric....@gmail.com]

I've started going through the plugins that have issues and pretty quickly 
ran into the "conditional buildstep" plugin.  I can't disable this plugin 
because I use it.  Do you have any suggestions?

Thanks,
Eric

On Monday, December 4, 2023 at 1:50:41 PM UTC-7 Mark Waite wrote:

> On Monday, December 4, 2023 at 1:40:26 PM UTC-7 Eric wrote:
>
> Hi All!  I have a project that I am unable to make changes to.  I can't 
> even make a comment in a field then save it down.  I can't even save it 
> down without a comment.  It throws up a screen saying "Oops!  A problem 
> occurred while processing a request."  Not sure where the physical log is, 
> it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
> Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
> I'll paste it below.  Any idea what my issue is?  Thanks!
>
> Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
> java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
> classes 
>
>
> That almost always means that one or more of the plugins that are active 
> on your system has not been updated for the configuration form 
> modernization that happened in Jenkins 2.277.1.
>
> You'll need to find and remove the plugins that have not been updated.  A 
> detailed guide is available at 
> https://community.jenkins.io/t/migrating-jenkins/894/5 
>
> 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/2ae14c25-cace-4bf1-a097-206a320e6a4an%40googlegroups.com.

Re: Unable to Save Project

[eric....@gmail.com]

Note that the project works fine to perform builds...

On Monday, December 4, 2023 at 1:40:26 PM UTC-7 eric@gmail.com wrote:

> Hi All!  I have a project that I am unable to make changes to.  I can't 
> even make a comment in a field then save it down.  I can't even save it 
> down without a comment.  It throws up a screen saying "Oops!  A problem 
> occurred while processing a request."  Not sure where the physical log is, 
> it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
> Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
> I'll paste it below.  Any idea what my issue is?  Thanks!
>
> Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
> java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
> classes 
> (["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"])
>  
> rather than an expected single class. See 
> https://www.jenkins.io/doc/developer/views/table-to-div-migration/ for 
> more information. at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:750) 
> Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
> jenkins.mvn.SettingsProvider from 
> {"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]}
>  
> at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
> at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
> org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:877) Caused: 
> java.lang.IllegalArgumentException: Failed to convert the settings 
> parameter of the constructor public 
> hudson.tasks.Maven(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,boolean,jenkins.mvn.SettingsProvider,jenkins.mvn.GlobalSettingsProvider,boolean)
>  
> at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:879) at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:768) 
> Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
> hudson.tasks.Maven from 
> {"stapler-class":"hudson.tasks.Maven","$class":"hudson.tasks.Maven","name":"Maven-3.0","targets":"-e
>  
> clean install 
> -DskipTests=true","pom":"","properties":"","jvmOptions":"","injectBuildVariables":true,"usePrivateRepository":false,"":["0","0"],"settings":{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]},"globalSettings":{"stapler-class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"],"$class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"]}}
>  
> at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
> at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
> org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:546) at 
> hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:489) at 
> hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:428) at 
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1095) at 
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1057) at 
> hudson.util.DescribableList.rebuildHetero(DescribableList.java:214) at 
> hudson.model.Project.submit(Project.java:233) at 
> hudson.model.Job.doConfigSubmit(Job.java:1345) at 
> hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:775) at 
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
>  
> at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:397) 
> Caused: java.lang.reflect.InvocationTargetException at 
> org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:401) at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:409) at 
> org.kohsuke.stapler.Function.bindAndInvoke(Function.java:207) at 
> org.kohsuke.stapler.SelectionInterceptedFunction$Adapter.invoke(SelectionInterceptedFunction.java:36)
>  
> at 
> org.kohsuke.stapler.verb.HttpVerbInterceptor.invoke(HttpVerbInterceptor.java:48)
>  
> at 
> org.kohsuke.stapler.SelectionInterceptedFunction.bindAndInvoke(

Unable to Save Project

[eric....@gmail.com]

Hi All!  I have a project that I am unable to make changes to.  I can't 
even make a comment in a field then save it down.  I can't even save it 
down without a comment.  It throws up a screen saying "Oops!  A problem 
occurred while processing a request."  Not sure where the physical log is, 
it's not in /var/log/jenkins/jenkins.log.  So I go to Manage Jenkins/System 
Log/All Jenkins Logs.  It has a big stack trace for the attempted save, 
I'll paste it below.  Any idea what my issue is?  Thanks!

Error while serving http://ipAddress:8080/job/ProjectName/configSubmit 
java.lang.IllegalArgumentException: The frontend sent an unexpected list of 
classes 
(["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"])
 
rather than an expected single class. See 
https://www.jenkins.io/doc/developer/views/table-to-div-migration/ for more 
information. at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:750) 
Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
jenkins.mvn.SettingsProvider from 
{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]}
 
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:877) Caused: 
java.lang.IllegalArgumentException: Failed to convert the settings 
parameter of the constructor public 
hudson.tasks.Maven(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,boolean,jenkins.mvn.SettingsProvider,jenkins.mvn.GlobalSettingsProvider,boolean)
 
at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:879) at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:768) 
Caused: java.lang.IllegalArgumentException: Failed to instantiate class 
hudson.tasks.Maven from 
{"stapler-class":"hudson.tasks.Maven","$class":"hudson.tasks.Maven","name":"Maven-3.0","targets":"-e
 
clean install 
-DskipTests=true","pom":"","properties":"","jvmOptions":"","injectBuildVariables":true,"usePrivateRepository":false,"":["0","0"],"settings":{"stapler-class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"],"$class":["jenkins.mvn.DefaultSettingsProvider","jenkins.mvn.FilePathSettingsProvider"]},"globalSettings":{"stapler-class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"],"$class":["jenkins.mvn.DefaultGlobalSettingsProvider","jenkins.mvn.FilePathGlobalSettingsProvider"]}}
 
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:771) 
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:551) at 
org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:546) at 
hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:489) at 
hudson.tasks.Maven$DescriptorImpl.newInstance(Maven.java:428) at 
hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1095) at 
hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:1057) at 
hudson.util.DescribableList.rebuildHetero(DescribableList.java:214) at 
hudson.model.Project.submit(Project.java:233) at 
hudson.model.Job.doConfigSubmit(Job.java:1345) at 
hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:775) at 
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
 
at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:397) 
Caused: java.lang.reflect.InvocationTargetException at 
org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:401) at 
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:409) at 
org.kohsuke.stapler.Function.bindAndInvoke(Function.java:207) at 
org.kohsuke.stapler.SelectionInterceptedFunction$Adapter.invoke(SelectionInterceptedFunction.java:36)
 
at 
org.kohsuke.stapler.verb.HttpVerbInterceptor.invoke(HttpVerbInterceptor.java:48)
 
at 
org.kohsuke.stapler.SelectionInterceptedFunction.bindAndInvoke(SelectionInterceptedFunction.java:26)
 
at 
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:140) 
at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:558) at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:59) 
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:770) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:900) at 
org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:289) at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:59) 
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:770) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:900) at 
org.kohsuke.stapler.Stapler.invoke(Stapler.java:698) at 
org.kohsuke.stapler.Stapler.service(Stapler.java:248) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at 

Re: Groovy Script

[eric....@gmail.com]

I pass them in the properties of the Builder.  That said, I just figured 
out a way to make it work.  For some reason or another, I needed on this 
server to instantiate the property.  So I set it up top as build_result 
with a default value of fail.  Then when it hits the groovy script, it sets 
it correctly.  Since it sets it correctly, I'm guessing I didn't have to 
set a default value, just instantiate it.  Either way, it's working so I'm 
good.  Thanks for trying to help!
On Tuesday, December 13, 2022 at 3:08:10 AM UTC-7 opay...@chsc.de wrote:

> How exactly do you pass the properties to ant?
>
>
> On 12 December 2022 22:16:36 CET, "eric@gmail.com"  
> wrote:
>>
>> Can someone please give me some println's I can put in there to figure 
>> out why it's not setting the build_result variable?  It doesn't make any 
>> sense to me that it works on one server but not another.  Thanks!
>>
>> On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com 
>> wrote:
>>
>>> That's interesting.  The println looks like it should be correct:
>>>
>>> upstream result: success
>>>
>>> Later when I try to use the variable in an ant call, it just shows the 
>>> variable instead of the value of it:
>>>
>>> -Dbuild_result=${build_result}
>>>
>>> I put it in the properties of the ant call:
>>>
>>> full.buildnumber=${full.buildnumber}
>>> build.time=${build.time}
>>> pk_build=${pk_build}
>>> build_result=${build_result}
>>>
>>> This has always worked in the past, just not since this latest upgrade 
>>> of jenkins.  I'm now on 2.375.1.
>>>
>>> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>>>
>>>> Hi,
>>>>
>>>> you mean upstreamResult/build_result?
>>>>
>>>> What does the println for upstreamResult say?
>>>> Which Jenkins version are you on?
>>>>
>>>> BR :)
>>>>
>>>>
>>>> On 9 December 2022 22:56:29 CET, "eric@gmail.com" <
>>>> eric@gmail.com> wrote:
>>>>>
>>>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>>>> setting the variable build_status for ages but it stopped working.  
>>>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>>>
>>>>> import hudson.model.*
>>>>>
>>>>> import jenkins.model.*
>>>>>
>>>>>   
>>>>>
>>>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>>>
>>>>> def parent_job = resolver.resolve("upstream_job")
>>>>>
>>>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>>>
>>>>>  
>>>>>
>>>>> def upstreamResult = 
>>>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>>>
>>>>>  
>>>>>
>>>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>>>
>>>>>   upstreamResult = "fail"
>>>>>
>>>>> } else {
>>>>>
>>>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>>>
>>>>> }
>>>>>
>>>>> println "upstream result: ${upstreamResult}"
>>>>>
>>>>>  
>>>>>
>>>>> def newParams = null
>>>>>
>>>>> def pl = new ArrayList()
>>>>>
>>>>>  
>>>>>
>>>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>>>
>>>>>  
>>>>>
>>>>> def oldParams = build.getAction(ParametersAction.class)
>>>>>
>>>>> if(oldParams != null) {
>>>>>
>>>>>   newParams = oldParams.createUpdated(pl)
>>>>>
>>>>>   build.actions.remove(oldParams)
>>>>>
>>>>> } else {
>>>>>
>>>>>   newParams = new ParametersAction(pl)
>>>>>
>>>>> }
>>>>>
>>>>>  
>>>>>
>>>>> build.addAction(newParams)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>>

-- 
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/17539d32-6fd6-497e-8a0a-8f91499acb52n%40googlegroups.com.

Re: Groovy Script

[eric....@gmail.com]

Can someone please give me some println's I can put in there to figure out 
why it's not setting the build_result variable?  It doesn't make any sense 
to me that it works on one server but not another.  Thanks!

On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com wrote:

> That's interesting.  The println looks like it should be correct:
>
> upstream result: success
>
> Later when I try to use the variable in an ant call, it just shows the 
> variable instead of the value of it:
>
> -Dbuild_result=${build_result}
>
> I put it in the properties of the ant call:
>
> full.buildnumber=${full.buildnumber}
> build.time=${build.time}
> pk_build=${pk_build}
> build_result=${build_result}
>
> This has always worked in the past, just not since this latest upgrade of 
> jenkins.  I'm now on 2.375.1.
>
> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>
>> Hi,
>>
>> you mean upstreamResult/build_result?
>>
>> What does the println for upstreamResult say?
>> Which Jenkins version are you on?
>>
>> BR :)
>>
>>
>> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
>> wrote:
>>>
>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>> setting the variable build_status for ages but it stopped working.  
>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>
>>> import hudson.model.*
>>>
>>> import jenkins.model.*
>>>
>>>   
>>>
>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>
>>> def parent_job = resolver.resolve("upstream_job")
>>>
>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>
>>>  
>>>
>>> def upstreamResult = 
>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>
>>>  
>>>
>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>
>>>   upstreamResult = "fail"
>>>
>>> } else {
>>>
>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>
>>> }
>>>
>>> println "upstream result: ${upstreamResult}"
>>>
>>>  
>>>
>>> def newParams = null
>>>
>>> def pl = new ArrayList()
>>>
>>>  
>>>
>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>
>>>  
>>>
>>> def oldParams = build.getAction(ParametersAction.class)
>>>
>>> if(oldParams != null) {
>>>
>>>   newParams = oldParams.createUpdated(pl)
>>>
>>>   build.actions.remove(oldParams)
>>>
>>> } else {
>>>
>>>   newParams = new ParametersAction(pl)
>>>
>>> }
>>>
>>>  
>>>
>>> build.addAction(newParams)
>>>
>>>
>>> Thanks,
>>> Eric
>>>
>>>

-- 
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/d32ec4bf-dd3f-416f-820a-c6eb8296f40fn%40googlegroups.com.

Re: Groovy Script

[eric....@gmail.com]

So I'm getting a different result on 2 different Jenkins servers.  I've 
upgraded on both.  The only difference between the 2 servers is that one is 
RHEL 7 and the other RHEL 8.  The RHEL 8 isn't working.  I have no clue why 
that is though.  It doesn't make sense that the same groovy script would 
behave differently in the 2 places.

On Monday, December 12, 2022 at 8:46:27 AM UTC-7 eric@gmail.com wrote:

> That's interesting.  The println looks like it should be correct:
>
> upstream result: success
>
> Later when I try to use the variable in an ant call, it just shows the 
> variable instead of the value of it:
>
> -Dbuild_result=${build_result}
>
> I put it in the properties of the ant call:
>
> full.buildnumber=${full.buildnumber}
> build.time=${build.time}
> pk_build=${pk_build}
> build_result=${build_result}
>
> This has always worked in the past, just not since this latest upgrade of 
> jenkins.  I'm now on 2.375.1.
>
> On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:
>
>> Hi,
>>
>> you mean upstreamResult/build_result?
>>
>> What does the println for upstreamResult say?
>> Which Jenkins version are you on?
>>
>> BR :)
>>
>>
>> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
>> wrote:
>>>
>>> Hi!  Not sure what's going on but I have a groovy script that has been 
>>> setting the variable build_status for ages but it stopped working.  
>>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>>
>>> import hudson.model.*
>>>
>>> import jenkins.model.*
>>>
>>>   
>>>
>>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>>
>>> def parent_job = resolver.resolve("upstream_job")
>>>
>>> def parent_build_number = resolver.resolve("upstream_bn")
>>>
>>>  
>>>
>>> def upstreamResult = 
>>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>>
>>>  
>>>
>>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>>
>>>   upstreamResult = "fail"
>>>
>>> } else {
>>>
>>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>>
>>> }
>>>
>>> println "upstream result: ${upstreamResult}"
>>>
>>>  
>>>
>>> def newParams = null
>>>
>>> def pl = new ArrayList()
>>>
>>>  
>>>
>>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>>
>>>  
>>>
>>> def oldParams = build.getAction(ParametersAction.class)
>>>
>>> if(oldParams != null) {
>>>
>>>   newParams = oldParams.createUpdated(pl)
>>>
>>>   build.actions.remove(oldParams)
>>>
>>> } else {
>>>
>>>   newParams = new ParametersAction(pl)
>>>
>>> }
>>>
>>>  
>>>
>>> build.addAction(newParams)
>>>
>>>
>>> Thanks,
>>> Eric
>>>
>>>

-- 
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/da0cd1af-d8a9-42c6-8d85-806c3c743d51n%40googlegroups.com.

Re: Groovy Script

[eric....@gmail.com]

That's interesting.  The println looks like it should be correct:

upstream result: success

Later when I try to use the variable in an ant call, it just shows the 
variable instead of the value of it:

-Dbuild_result=${build_result}

I put it in the properties of the ant call:

full.buildnumber=${full.buildnumber}
build.time=${build.time}
pk_build=${pk_build}
build_result=${build_result}

This has always worked in the past, just not since this latest upgrade of 
jenkins.  I'm now on 2.375.1.

On Friday, December 9, 2022 at 9:50:34 PM UTC-7 opay...@chsc.de wrote:

> Hi,
>
> you mean upstreamResult/build_result?
>
> What does the println for upstreamResult say?
> Which Jenkins version are you on?
>
> BR :)
>
>
> On 9 December 2022 22:56:29 CET, "eric@gmail.com"  
> wrote:
>>
>> Hi!  Not sure what's going on but I have a groovy script that has been 
>> setting the variable build_status for ages but it stopped working.  
>>  Doesn't set the variable any longer.  Any ideas?  Here's the script:
>>
>> import hudson.model.*
>>
>> import jenkins.model.*
>>
>>   
>>
>> def resolver = Thread.currentThread().executable.buildVariableResolver
>>
>> def parent_job = resolver.resolve("upstream_job")
>>
>> def parent_build_number = resolver.resolve("upstream_bn")
>>
>>  
>>
>> def upstreamResult = 
>> Hudson.instance.getJob("${parent_job}").getLastBuild().result
>>
>>  
>>
>> if(upstreamResult.equals(hudson.model.Result.FAILURE)) {
>>
>>   upstreamResult = "fail"
>>
>> } else {
>>
>>   upstreamResult = "${upstreamResult}".toLowerCase()  
>>
>> }
>>
>> println "upstream result: ${upstreamResult}"
>>
>>  
>>
>> def newParams = null
>>
>> def pl = new ArrayList()
>>
>>  
>>
>> pl.add(new StringParameterValue('build_result', upstreamResult))
>>
>>  
>>
>> def oldParams = build.getAction(ParametersAction.class)
>>
>> if(oldParams != null) {
>>
>>   newParams = oldParams.createUpdated(pl)
>>
>>   build.actions.remove(oldParams)
>>
>> } else {
>>
>>   newParams = new ParametersAction(pl)
>>
>> }
>>
>>  
>>
>> build.addAction(newParams)
>>
>>
>> Thanks,
>> Eric
>>
>>

-- 
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/bb278fff-5dad-4b05-b695-49ffaf21d89fn%40googlegroups.com.

Groovy Script

[eric....@gmail.com]

Hi!  Not sure what's going on but I have a groovy script that has been 
setting the variable build_status for ages but it stopped working.  
 Doesn't set the variable any longer.  Any ideas?  Here's the script:

import hudson.model.*

import jenkins.model.*

  

def resolver = Thread.currentThread().executable.buildVariableResolver

def parent_job = resolver.resolve("upstream_job")

def parent_build_number = resolver.resolve("upstream_bn")

 

def upstreamResult = 
Hudson.instance.getJob("${parent_job}").getLastBuild().result

 

if(upstreamResult.equals(hudson.model.Result.FAILURE)) {

  upstreamResult = "fail"

} else {

  upstreamResult = "${upstreamResult}".toLowerCase()  

}

println "upstream result: ${upstreamResult}"

 

def newParams = null

def pl = new ArrayList()

 

pl.add(new StringParameterValue('build_result', upstreamResult))

 

def oldParams = build.getAction(ParametersAction.class)

if(oldParams != null) {

  newParams = oldParams.createUpdated(pl)

  build.actions.remove(oldParams)

} else {

  newParams = new ParametersAction(pl)

}

 

build.addAction(newParams)


Thanks,
Eric

-- 
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/696cf40d-52da-40db-b7da-0bd974551104n%40googlegroups.com.

Re: Running Jenkins as a Service in RHEL 8

[eric....@gmail.com]

Requesting this conversation to be deleted because I accidentally let a 
machine name in without scrubbing it.  Thanks!

On Monday, December 5, 2022 at 8:54:21 AM UTC-7 eric@gmail.com wrote:

> Not sure changing the home directory is the answer.  I think the true 
> answer resides in how to allow the jenkins service to run in SELINUX...
>
> On Monday, December 5, 2022 at 8:45:42 AM UTC-7 slide wrote:
>
>> Jenkins switched to systemd "recently" check this page for how to change 
>> env variables and such 
>> https://www.jenkins.io/doc/book/system-administration/systemd-services/ 
>>
>> On Mon, Dec 5, 2022 at 8:40 AM eric@gmail.com  
>> wrote:
>>
>>> Changing the JENKINS_HOME directory in that config file didn't work.  I 
>>> got the same error some it's using that link somewhere else...
>>>
>>> Thanks,
>>> Eric
>>>
>>> On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm running into an issue running Jenkins as a service in RHEL 8 with 
>>>> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
>>>> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
>>>> the service from there.  Would it be acceptable to just change the value 
>>>> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>>>>
>>>>
>>>> ]# journalctl -xe
>>>>
>>>>You can generate a 
>>>> local policy module to allow this access.
>>>>
>>>>Do
>>>>
>>>>allow this access 
>>>> for now by executing:
>>>>
>>>># ausearch -c 
>>>> '(jenkins)' --raw | audit2allow -M my-jenkins
>>>>
>>>># semodule -X 300 -i 
>>>> my-jenkins.pp
>>>>
>>>>
>>>>
>>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>>> Set alarm timeout to 10
>>>>
>>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>>> Cancel pending alarm
>>>>
>>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is 
>>>> preventing /usr/lib/systemd/systemd from read access on the lnk_file 
>>>> /var/lib/jenkins. For com>
>>>>
>>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is 
>>>> preventing /usr/lib/systemd/systemd from read access on the lnk_file 
>>>> /var/lib/jenkins.
>>>>
>>>>
>>>>
>>>>*  Plugin 
>>>> catchall_labels (83.8 confidence) suggests   ***
>>>>
>>>>
>>>>
>>>>If you want to allow 
>>>> systemd to have read access on the jenkins lnk_file
>>>>
>>>>Then you need to 
>>>> change the label on /var/lib/jenkins
>>>>
>>>>Do
>>>>
>>>># semanage fcontext 
>>>> -a -t FILE_TYPE '/var/lib/jenkins'
>>>>
>>>>where FILE_TYPE is 
>>>> one of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
>>>> NetworkManager_un>
>>>>
>>>>Then execute:
>>>>
>>>>restorecon -v 
>>>> '/var/lib/jenkins'
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>*  Plugin 
>>>> catchall (17.1 confidence) suggests   **
>>>>
>>>>

Re: Running Jenkins as a Service in RHEL 8

[eric....@gmail.com]

Not sure changing the home directory is the answer.  I think the true 
answer resides in how to allow the jenkins service to run in SELINUX...

On Monday, December 5, 2022 at 8:45:42 AM UTC-7 slide wrote:

> Jenkins switched to systemd "recently" check this page for how to change 
> env variables and such 
> https://www.jenkins.io/doc/book/system-administration/systemd-services/ 
>
> On Mon, Dec 5, 2022 at 8:40 AM eric@gmail.com  
> wrote:
>
>> Changing the JENKINS_HOME directory in that config file didn't work.  I 
>> got the same error some it's using that link somewhere else...
>>
>> Thanks,
>> Eric
>>
>> On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com wrote:
>>
>>> Hi All,
>>>
>>> I'm running into an issue running Jenkins as a service in RHEL 8 with 
>>> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
>>> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
>>> the service from there.  Would it be acceptable to just change the value 
>>> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>>>
>>>
>>> ]# journalctl -xe
>>>
>>>You can generate a 
>>> local policy module to allow this access.
>>>
>>>Do
>>>
>>>allow this access for 
>>> now by executing:
>>>
>>># ausearch -c 
>>> '(jenkins)' --raw | audit2allow -M my-jenkins
>>>
>>># semodule -X 300 -i 
>>> my-jenkins.pp
>>>
>>>
>>>
>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>> Set alarm timeout to 10
>>>
>>> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
>>> Cancel pending alarm
>>>
>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
>>> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
>>> For com>
>>>
>>> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
>>> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.
>>>
>>>
>>>
>>>*  Plugin 
>>> catchall_labels (83.8 confidence) suggests   ***
>>>
>>>
>>>
>>>If you want to allow 
>>> systemd to have read access on the jenkins lnk_file
>>>
>>>Then you need to 
>>> change the label on /var/lib/jenkins
>>>
>>>Do
>>>
>>># semanage fcontext 
>>> -a -t FILE_TYPE '/var/lib/jenkins'
>>>
>>>where FILE_TYPE is 
>>> one of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
>>> NetworkManager_un>
>>>
>>>Then execute:
>>>
>>>restorecon -v 
>>> '/var/lib/jenkins'
>>>
>>>
>>>
>>>
>>>
>>>*  Plugin 
>>> catchall (17.1 confidence) suggests   **
>>>
>>>
>>>
>>>If you believe that 
>>> systemd should be allowed read access on the jenkins lnk_file by default.
>>>
>>>Then you should 
>>> report this as a bug.
>>>
>>>You can generate a 
>>> local policy module to allow this access.
>>>
>>>Do
>>>
>>>  

Re: Running Jenkins as a Service in RHEL 8

[eric....@gmail.com]

Changing the JENKINS_HOME directory in that config file didn't work.  I got 
the same error some it's using that link somewhere else...

Thanks,
Eric

On Monday, December 5, 2022 at 8:09:31 AM UTC-7 eric@gmail.com wrote:

> Hi All,
>
> I'm running into an issue running Jenkins as a service in RHEL 8 with 
> SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
> is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
> the service from there.  Would it be acceptable to just change the value 
> for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!
>
>
> ]# journalctl -xe
>
>You can generate a 
> local policy module to allow this access.
>
>Do
>
>allow this access for 
> now by executing:
>
># ausearch -c 
> '(jenkins)' --raw | audit2allow -M my-jenkins
>
># semodule -X 300 -i 
> my-jenkins.pp
>
>
>
> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Set alarm timeout to 10
>
> Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Cancel pending alarm
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
> For com>
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
> /usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.
>
>
>
>*  Plugin 
> catchall_labels (83.8 confidence) suggests   ***
>
>
>
>If you want to allow 
> systemd to have read access on the jenkins lnk_file
>
>Then you need to change 
> the label on /var/lib/jenkins
>
>Do
>
># semanage fcontext -a 
> -t FILE_TYPE '/var/lib/jenkins'
>
>where FILE_TYPE is one 
> of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
> NetworkManager_un>
>
>Then execute:
>
>restorecon -v 
> '/var/lib/jenkins'
>
>
>
>
>
>*  Plugin catchall 
> (17.1 confidence) suggests   **
>
>
>
>If you believe that 
> systemd should be allowed read access on the jenkins lnk_file by default.
>
>Then you should report 
> this as a bug.
>
>You can generate a 
> local policy module to allow this access.
>
>Do
>
>allow this access for 
> now by executing:
>
># ausearch -c 
> '(jenkins)' --raw | audit2allow -M my-jenkins
>
># semodule -X 300 -i 
> my-jenkins.pp
>
>
>
> Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
> Set alarm timeout to 10
>
> Dec 02 10:45:18 nd655bd001 systemd[1]: setroubleshootd.service: Succeeded.
>
> -- Subject: Unit succeeded
>
> -- Defined-By: systemd
>
> -- Support: https://access.redhat.com/support 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsupport=05%7C01%7Ceric.fetzer%40dynamo.works%7Cf073214ec53d487bba8c08dad4b081f9%7C20011f20d2a44579a5cc40c8d987672b%7C0%7C0%7C638056151829928292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=WMisNWM7KMmRGWY7k0n4euY6NIyCo74ECMq42lMC64Q%3D=0>
>
> -- 
>
> -- The unit setroubleshootd.service has successfully entered the 'dead' 
> state.
>
> lines 5338-5376/5376 (END)
>

-- 
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/0c57cbc8-8b60-4f6b-852a-bc892b97af38n%40googlegroups.com.

Running Jenkins as a Service in RHEL 8

[eric....@gmail.com]

Hi All,

I'm running into an issue running Jenkins as a service in RHEL 8 with 
SELINUX running (I don't have a choice).  It seems since /var/lib/jenkins 
is a symbolic link to /opt/jenkins, SELINUX doesn't want to allow running 
the service from there.  Would it be acceptable to just change the value 
for JENKINS_HOME to /opt/jenkins in /etc/sysconfig/jenkins?  Thanks!


]# journalctl -xe

   You can generate a local 
policy module to allow this access.

   Do

   allow this access for 
now by executing:

   # ausearch -c 
'(jenkins)' --raw | audit2allow -M my-jenkins

   # semodule -X 300 -i 
my-jenkins.pp

   

Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): Set 
alarm timeout to 10

Dec 02 10:45:03 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): 
Cancel pending alarm

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
/usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins. 
For com>

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: SELinux is preventing 
/usr/lib/systemd/systemd from read access on the lnk_file /var/lib/jenkins.

   

   *  Plugin 
catchall_labels (83.8 confidence) suggests   ***

   

   If you want to allow 
systemd to have read access on the jenkins lnk_file

   Then you need to change 
the label on /var/lib/jenkins

   Do

   # semanage fcontext -a 
-t FILE_TYPE '/var/lib/jenkins'

   where FILE_TYPE is one 
of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, 
NetworkManager_un>

   Then execute:

   restorecon -v 
'/var/lib/jenkins'

   

   

   *  Plugin catchall 
(17.1 confidence) suggests   **

   

   If you believe that 
systemd should be allowed read access on the jenkins lnk_file by default.

   Then you should report 
this as a bug.

   You can generate a local 
policy module to allow this access.

   Do

   allow this access for 
now by executing:

   # ausearch -c 
'(jenkins)' --raw | audit2allow -M my-jenkins

   # semodule -X 300 -i 
my-jenkins.pp

   

Dec 02 10:45:07 nd655bd001 setroubleshoot[144816]: AnalyzeThread.run(): Set 
alarm timeout to 10

Dec 02 10:45:18 nd655bd001 systemd[1]: setroubleshootd.service: Succeeded.

-- Subject: Unit succeeded

-- Defined-By: systemd

-- Support: https://access.redhat.com/support 


-- 

-- The unit setroubleshootd.service has successfully entered the 'dead' 
state.

lines 5338-5376/5376 (END)

-- 
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/8ce021ab-d787-4fe3-96d5-d5476a4aac75n%40googlegroups.com.

Jenkins Won't start after latest ugrade

[eric....@gmail.com]

Here's what I did:

yum update jenkins

Here's what's happening trying to get version info after upgrade.  Also 
won't start with systemctl start jenkins.

[root@nd645bd001 ~]# /bin/jenkins -version
Sep 14, 2022 10:56:24 AM executable.Main verifyJavaVersion
SEVERE: Running with Java class version 52, which is older than the Minimum 
required version 55. See https://jenkins.io/redirect/java-support/
java.lang.UnsupportedClassVersionError: 52.0
at executable.Main.verifyJavaVersion(Main.java:145)
at executable.Main.main(Main.java:109)

Jenkins requires Java versions [17, 11] but you are running with Java 1.8 
from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.el7_9.x86_64/jre
java.lang.UnsupportedClassVersionError: 52.0
at executable.Main.verifyJavaVersion(Main.java:145)
at executable.Main.main(Main.java:109)

Seems I need to upgrade java, but jenkins doesn't control java.  Please 
advise.  Should I just yum update java?

Thanks,
Eric

-- 
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/63ddfcc2-b01e-4f44-8c6e-9ee40f923905n%40googlegroups.com.

Re: Git Source Code Management Oddity

[eric....@gmail.com]

Also note that I AM using the "with credentials" from the plugin.

On Thursday, May 19, 2022 at 8:56:30 AM UTC-6 Mark Waite wrote:

> On Thursday, May 19, 2022 at 8:42:29 AM UTC-6 Eric Fetzer wrote:
>
>> OK, I've been having some major issues with Git source code management in 
>> Jenkins.  So I have several repositories I pull from to do builds.  I use 
>> my same credentials to pull from each.  If the pull succeeds, I push a tag 
>> at it.  I was noticing certain tags were failing saying it already existed 
>> even though it didn't exist.  Well, it didn't exist in THAT repository.  
>> But it did exist in one of the other repositories.  I tested by creating 
>> these tags in git command line and pushing them and it worked fine.  Anyone 
>> have a clue what could be happening here?  The jenkins task goes to my 
>> repository's url with my credentials selecting from the branch I tell it.  
>> It's set to clean before check out.  It does all of this fine.  It has a 
>> Git Publisher post build step to push my tag only if the checkout succeeds 
>> with the box checked to create new tag.  This works UNLESS that same tags 
>> exists in any of the projects I run this checkout task against.  Can anyone 
>> think of a reason for this odd behavior?  Thanks!!!
>
>
> I don't know if the git publisher in the git plugin is able to handle 
> checkout from multiple repositories.  It may not be that sophisticated.
>
> You may need to switch to use the "with credentials" feature that was 
> added in Google Summer of Code 2021 to allow you to perform the push of the 
> tag yourself rather than using the git publisher.  Docs on the "with 
> credentials" feature are available at 
> https://plugins.jenkins.io/git/#plugin-content-credential-binding 
> (Pipeline) and https://plugins.jenkins.io/git/#plugin-content-git-bindings 
> (freestyle) 
>
> 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/3978fa1d-ca63-44f3-9966-123ce7fc7ccbn%40googlegroups.com.

Re: Git Source Code Management Oddity

[eric....@gmail.com]

It handles checkout from multiple repositories and pushes tags to each.  
The only issue is that it seems to see tags in other repositories when it 
should only see the tags in the repository in question.  If the tag exists 
in ANY of the repositories I build for, this will be the error:

using credential e9cc840b-9e32-416c-94e7-7b23c1afbd5e 
 > git tag -l 2.3.0.1.1 
# timeout=10 ERROR: Step ‘Git Publisher’ failed: Tag 2.3.0.1.1 already 
exists and Create Tag is specified, so failing.

Any clue how I would trouble shoot such a thing?

Thanks,
Eric

On Thursday, May 19, 2022 at 8:56:30 AM UTC-6 Mark Waite wrote:

> On Thursday, May 19, 2022 at 8:42:29 AM UTC-6 Eric Fetzer wrote:
>
>> OK, I've been having some major issues with Git source code management in 
>> Jenkins.  So I have several repositories I pull from to do builds.  I use 
>> my same credentials to pull from each.  If the pull succeeds, I push a tag 
>> at it.  I was noticing certain tags were failing saying it already existed 
>> even though it didn't exist.  Well, it didn't exist in THAT repository.  
>> But it did exist in one of the other repositories.  I tested by creating 
>> these tags in git command line and pushing them and it worked fine.  Anyone 
>> have a clue what could be happening here?  The jenkins task goes to my 
>> repository's url with my credentials selecting from the branch I tell it.  
>> It's set to clean before check out.  It does all of this fine.  It has a 
>> Git Publisher post build step to push my tag only if the checkout succeeds 
>> with the box checked to create new tag.  This works UNLESS that same tags 
>> exists in any of the projects I run this checkout task against.  Can anyone 
>> think of a reason for this odd behavior?  Thanks!!!
>
>
> I don't know if the git publisher in the git plugin is able to handle 
> checkout from multiple repositories.  It may not be that sophisticated.
>
> You may need to switch to use the "with credentials" feature that was 
> added in Google Summer of Code 2021 to allow you to perform the push of the 
> tag yourself rather than using the git publisher.  Docs on the "with 
> credentials" feature are available at 
> https://plugins.jenkins.io/git/#plugin-content-credential-binding 
> (Pipeline) and https://plugins.jenkins.io/git/#plugin-content-git-bindings 
> (freestyle) 
>
> 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/7623d7a2-3618-4f9f-aeaf-65179b601cd5n%40googlegroups.com.

Git Source Code Management Oddity

[eric....@gmail.com]

OK, I've been having some major issues with Git source code management in 
Jenkins.  So I have several repositories I pull from to do builds.  I use 
my same credentials to pull from each.  If the pull succeeds, I push a tag 
at it.  I was noticing certain tags were failing saying it already existed 
even though it didn't exist.  Well, it didn't exist in THAT repository.  
But it did exist in one of the other repositories.  I tested by creating 
these tags in git command line and pushing them and it worked fine.  Anyone 
have a clue what could be happening here?  The jenkins task goes to my 
repository's url with my credentials selecting from the branch I tell it.  
It's set to clean before check out.  It does all of this fine.  It has a 
Git Publisher post build step to push my tag only if the checkout succeeds 
with the box checked to create new tag.  This works UNLESS that same tags 
exists in any of the projects I run this checkout task against.  Can anyone 
think of a reason for this odd behavior?  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/f0fcd019-bb4a-4126-96a1-8f912c6e7adan%40googlegroups.com.

Re: Unable to Launch Node

[eric....@gmail.com]

SSH Build Agent is 1.31.2.  Trilead-api is 1.0.13.  It only happens once 
the server gets reboot.  It'll be chugging along for a few weeks fine, then 
as soon as the server gets reboot after the latest OS patches have been 
applied, I'll have to delete the remoting.jar file again.  A bit 
frustrating.

On Wednesday, March 30, 2022 at 4:07:35 PM UTC-6 kuisat...@gmail.com wrote:

> I do not really have too much data to know what exactly is going on, which 
> version of the SSH build Agents and the trilead-api plugins are you using? 
> Are you using the latest versions? Do the issue happen only in that agent? 
> Which SSH server do you use and what version? Do you have any kind of 
> transfer limit on that agent? my theory is that the sftp read operation 
> fail because something cut it.
>
> El miércoles, 30 de marzo de 2022 a las 21:50:52 UTC+2, eric@gmail.com 
> escribió:
>
>> Just did it again on me.  Deleting the file again to fix it but would be 
>> great if I could fix it.  Any advise?
>>
>> On Friday, March 18, 2022 at 11:17:56 AM UTC-6 kuisat...@gmail.com wrote:
>>
>>> The SSH Build Agents plugin make an sftp or scp (if one fail try the 
>>> other) with the user configured in the Jenkins Agent to copy a file in the 
>>> "Remote root directory" folder configured in the Agent config, nothing 
>>> special, if the user configured in the Agent can make scp/sftp to copy a 
>>> file in that folder it should not fail. 
>>>
>>> The point where the Agent fails to copy the file is interesting, it 
>>> checks the value of the read bytes and fails if is <0 or >32768, I will 
>>> bet the value is `-1` and it is related to read the remoting.jar from the 
>>> Agent to check the md5, for some reason is returning an EOF
>>>
>>>
>>> https://github.com/jenkinsci/trilead-ssh2/blob/master/src/com/trilead/ssh2/SFTPv3Client.java#L1231
>>>
>>> https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L706
>>> El viernes, 18 de marzo de 2022 a las 16:10:56 UTC+1, eric@gmail.com 
>>> escribió:
>>>
>>>> Hmmm, I deleted the remoting.jar file and was able to restart Jenkins 
>>>> and the node came up.  Wonder if this is going to happen every we patch 
>>>> and 
>>>> boot this machine?
>>>>
>>>> On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:
>>>>
>>>>> Hi!  I have a node that is unable to launch.  On the log it shows:
>>>>>
>>>>> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
>>>>> java.io.IOException: Could not copy remoting.jar into 
>>>>> '/home/myuser/checkout' on agent at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) 
>>>>> at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
>>>>> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>  
>>>>> at 
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>  
>>>>> at java.lang.Thread.run(Thread.java:750) Caused by: 
>>>>> java.lang.IllegalArgumentException: invalid len argument at 
>>>>> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
>>>>> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172)
>>>>>  
>>>>> at 
>>>>> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184)
>>>>>  
>>>>> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>>>>>  
>>>>> at 
>>>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
>>>>> ... 7 more
>>>>>
>>>>> I've set my perms on the checkout dir to 777, so it's not that it 
>>>>> doesn't have permission to write over the current remoting.jar that lives 
>>>>> there. Anyone have any clues or further trouble shooting advise? 
>>>>> Running Jenkins 2.232.1 on RHEL 7.9.
>>>>>
>>>>> Thanks - Eric 
>>>>>
>>>>

-- 
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/47eafb75-de8e-4b98-86fb-fffbf058fff0n%40googlegroups.com.

Re: How to know when plugins were installed

[eric....@gmail.com]

If you're in Unix, Go to $JENKINS_HOME/plugins:

ls -ltr *.hpi *.jpi 

The most recently installed will be at the bottom and you'll see the date.

On Friday, April 15, 2022 at 10:59:10 AM UTC-6 jf.la...@gmail.com wrote:

> Hello,
>
> The Jenkins Plugin Manager gives us a long list of about 100 installed 
> plugins on our system.
> Yet I'm sure that we've not installed more than a dozen beyond the default 
> ones suggested in the beginning.
> Most of the plugins listed are probably just dependencies of the initial 
> ones, or of the ones we explicitly installed.
>
> To prepare a disaster recovery plan, I need to list exactly what plugins 
> we installed.
> We've recorded some of then, but unfortunately not all. How to find the 
> others?
>
> Is there a way to list just the plugins requested, NOT the dependencies 
> installed automatically?
>
> Is there a way to list the plugins installations by date?
> (This would allow us to recognize which one we installed in each burst of 
> installations!)
>
> Jean-François
>

-- 
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/a81a77f2-3948-46ca-89f8-cb01c2791a75n%40googlegroups.com.

Re: Jenkins Scripting Console

[eric....@gmail.com]

Well my bad, it works fine.  I was thinking the plugins were disabled if 
they were subdued in color.  No, that just means they can't be disabled.  I 
didn't have any disabled.  I disabled subversion and it shows Disabled.  
Maybe this will help someone down the road, though, who wants to do the 
same.

On Friday, April 15, 2022 at 10:19:10 AM UTC-6 eric@gmail.com wrote:

> Hi all!  I'm trying to display a few simple things from the console for 
> our security team.  I'm getting the correct answers for all except whether 
> the plugin is enabled or not.  They are all returning enabled for me.  Can 
> someone tell me what I'm doing wrong in my groovy code?
>
> Jenkins.instance.pluginManager.plugins.each{
>   plugin -> 
>   boolean active = ( plugin.isActive() )
>   String enabled = ( active == true ? "Enabled" : "Disabled"  )
>   println ("${plugin.getDisplayName()} (${plugin.getShortName()}): 
> ${plugin.getVersion()} ${enabled}")
> }
>
> Thanks,
> Eric
>

-- 
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/4ede952c-7702-405c-b97f-c4db34cb24f4n%40googlegroups.com.

Jenkins Scripting Console

[eric....@gmail.com]

Hi all!  I'm trying to display a few simple things from the console for our 
security team.  I'm getting the correct answers for all except whether the 
plugin is enabled or not.  They are all returning enabled for me.  Can 
someone tell me what I'm doing wrong in my groovy code?

Jenkins.instance.pluginManager.plugins.each{
  plugin -> 
  boolean active = ( plugin.isActive() )
  String enabled = ( active == true ? "Enabled" : "Disabled"  )
  println ("${plugin.getDisplayName()} (${plugin.getShortName()}): 
${plugin.getVersion()} ${enabled}")
}

Thanks,
Eric

-- 
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/a60f5a9d-138f-4a43-b508-fd81a096da34n%40googlegroups.com.

Re: Unable to Launch Node

[eric....@gmail.com]

Just did it again on me.  Deleting the file again to fix it but would be 
great if I could fix it.  Any advise?

On Friday, March 18, 2022 at 11:17:56 AM UTC-6 kuisat...@gmail.com wrote:

> The SSH Build Agents plugin make an sftp or scp (if one fail try the 
> other) with the user configured in the Jenkins Agent to copy a file in the 
> "Remote root directory" folder configured in the Agent config, nothing 
> special, if the user configured in the Agent can make scp/sftp to copy a 
> file in that folder it should not fail. 
>
> The point where the Agent fails to copy the file is interesting, it checks 
> the value of the read bytes and fails if is <0 or >32768, I will bet the 
> value is `-1` and it is related to read the remoting.jar from the Agent to 
> check the md5, for some reason is returning an EOF
>
>
> https://github.com/jenkinsci/trilead-ssh2/blob/master/src/com/trilead/ssh2/SFTPv3Client.java#L1231
>
> https://github.com/jenkinsci/ssh-slaves-plugin/blob/main/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L706
> El viernes, 18 de marzo de 2022 a las 16:10:56 UTC+1, eric@gmail.com 
> escribió:
>
>> Hmmm, I deleted the remoting.jar file and was able to restart Jenkins and 
>> the node came up.  Wonder if this is going to happen every we patch and 
>> boot this machine?
>>
>> On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:
>>
>>> Hi!  I have a node that is unable to launch.  On the log it shows:
>>>
>>> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
>>> java.io.IOException: Could not copy remoting.jar into 
>>> '/home/myuser/checkout' on agent at 
>>> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
>>> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
>>> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
>>> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>  
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>  
>>> at java.lang.Thread.run(Thread.java:750) Caused by: 
>>> java.lang.IllegalArgumentException: invalid len argument at 
>>> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
>>> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172)
>>>  
>>> at 
>>> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
>>> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
>>> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>>>  
>>> at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
>>> ... 7 more
>>>
>>> I've set my perms on the checkout dir to 777, so it's not that it 
>>> doesn't have permission to write over the current remoting.jar that lives 
>>> there. Anyone have any clues or further trouble shooting advise? 
>>> Running Jenkins 2.232.1 on RHEL 7.9.
>>>
>>> Thanks - Eric 
>>>
>>

-- 
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/b182927d-e91d-4353-834a-6ed573288a1bn%40googlegroups.com.

Re: Unable to Launch Node

[eric....@gmail.com]

Hmmm, I deleted the remoting.jar file and was able to restart Jenkins and 
the node came up.  Wonder if this is going to happen every we patch and 
boot this machine?

On Friday, March 18, 2022 at 8:43:55 AM UTC-6 eric@gmail.com wrote:

> Hi!  I have a node that is unable to launch.  On the log it shows:
>
> [03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
> java.io.IOException: Could not copy remoting.jar into 
> '/home/myuser/checkout' on agent at 
> hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
> hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
> hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  
> at java.lang.Thread.run(Thread.java:750) Caused by: 
> java.lang.IllegalArgumentException: invalid len argument at 
> com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
> com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172) 
> at 
> com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
> at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
> hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
>  
> at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
> ... 7 more
>
> I've set my perms on the checkout dir to 777, so it's not that it doesn't 
> have permission to write over the current remoting.jar that lives there. 
> Anyone have any clues or further trouble shooting advise? 
> Running Jenkins 2.232.1 on RHEL 7.9.
>
> Thanks - Eric 
>

-- 
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/134d8093-61e0-45af-9ccd-1d0c855cd327n%40googlegroups.com.

Unable to Launch Node

[eric....@gmail.com]

Hi!  I have a node that is unable to launch.  On the log it shows:

[03/18/22 09:39:01] [SSH] Copying latest remoting.jar... 
java.io.IOException: Could not copy remoting.jar into 
'/home/myuser/checkout' on agent at 
hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:715) at 
hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:112) at 
hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:455) at 
hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422) at 
java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:750) Caused by: 
java.lang.IllegalArgumentException: invalid len argument at 
com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232) at 
com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172) 
at 
com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184) 
at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224) at 
hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:773)
 
at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:684) 
... 7 more

I've set my perms on the checkout dir to 777, so it's not that it doesn't 
have permission to write over the current remoting.jar that lives there. 
Anyone have any clues or further trouble shooting advise? 
Running Jenkins 2.232.1 on RHEL 7.9.

Thanks - Eric 

-- 
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/61a1558f-20c7-4dad-b45e-783b375163efn%40googlegroups.com.

Re: Log4j CVE-2021-44228

[eric....@gmail.com]

OK, so this isn't going so hot.  There is no .m2/settings.xml file.  There 
are settings.xml for each of the Maven versions under 
~/tools/hudson.tasks.Maven_MavenInstallation/Maven-X.X/conf.  This has the 
"localRepository" node but it's commented out.  Should I set the value 
"/var/lib/jenkins/.m2/repositories/${env.JOB_NAME}/repository" 
in there for each version? Alternative would be to create a settings.xml 
file in the .m2 directory. Sounds like it goes to that one first regardless 
of version... The concept seems simplest. Chron job or just clear the repo 
at the end of the build?

Thanks,
Eric

On Friday, December 17, 2021 at 4:12:50 AM UTC-7 bma...@gmail.com wrote:

> Yeah you can definitely wipe out this whole tree.
>
> I wrote an eternity ago about this:
>
>  
> https://batmat.net/2009/10/09/hudson-how-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them/
>
> Some of it is a bit old but the principles remain true today: you _should_ 
> even do it on a regular basis. Ideally after and before each job (the 
> modern way to do this kinda automatically is to use things like containers 
> that will by definition start fresh [if some shared maven repository isn't 
> mounted, don't do this]).
>
> Cheers
>
> Le jeu. 16 déc. 2021 à 23:01, eric@gmail.com  a 
> écrit :
>
>> Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
>> it's been deprecated.  Guessing I can just delete that log4j directory and 
>> be done with it.
>>
>> On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
>> wrote:
>>
>>> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
>>> mentioned that is the local maven cache.
>>> Also if you don't maintain that, it will grow and grow.
>>> Personally I update build jobs so they each have their own maven cache 
>>> using -Dmaven.repo.local=mvn-repo then delete that after your job 
>>> completes. You might need to tweak some of your process if they depending 
>>> upon one job installing and another job consuming. But the problem with 
>>> that is if you do builds pre branch they could conflict if using the same 
>>> version number.
>>>
>>> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
>>> rebuild all your projects. As maven will download it again if it still 
>>> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
>>> jobs still has an older version as a dependency.
>>>
>>>
>>>
>>> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>>>
>>>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>>>> also called 'local repository'.
>>>>
>>>> My theory is that you have a job or more that uses maven with default 
>>>> values. I suspect you even run these on the controller itself...
>>>>
>>>> Some of your job(s) build(s) a software of yours that depends on a 
>>>> vulnerable version of log4j.
>>>>
>>>>
>>>>
>>>>
>>>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  
>>>> a écrit :
>>>>
>>>>> Hi all.  Getting popped by our security team for an old version of 
>>>>> log4j.  I've checked and we don't have any of the plugins installed 
>>>>> identified by the following issue:
>>>>>
>>>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>>>
>>>>> Here's the info from the scan:
>>>>>
>>>>> Plugin Output: 
>>>>>   Path  : 
>>>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>>>   Installed version : 2.14.1
>>>>>   Fixed version : 2.15.0
>>>>>
>>>>> Anyone have a clue on how I go about upgrading this?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>> -- 
>>>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenki

Re: Log4j CVE-2021-44228

[eric....@gmail.com]

Thanks, deleted it for short term solution and looking into the "Even 
Better" solution at your link.  Much appreciated!

On Friday, December 17, 2021 at 4:12:50 AM UTC-7 bma...@gmail.com wrote:

> Yeah you can definitely wipe out this whole tree.
>
> I wrote an eternity ago about this:
>
>  
> https://batmat.net/2009/10/09/hudson-how-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them/
>
> Some of it is a bit old but the principles remain true today: you _should_ 
> even do it on a regular basis. Ideally after and before each job (the 
> modern way to do this kinda automatically is to use things like containers 
> that will by definition start fresh [if some shared maven repository isn't 
> mounted, don't do this]).
>
> Cheers
>
> Le jeu. 16 déc. 2021 à 23:01, eric@gmail.com  a 
> écrit :
>
>> Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
>> it's been deprecated.  Guessing I can just delete that log4j directory and 
>> be done with it.
>>
>> On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
>> wrote:
>>
>>> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
>>> mentioned that is the local maven cache.
>>> Also if you don't maintain that, it will grow and grow.
>>> Personally I update build jobs so they each have their own maven cache 
>>> using -Dmaven.repo.local=mvn-repo then delete that after your job 
>>> completes. You might need to tweak some of your process if they depending 
>>> upon one job installing and another job consuming. But the problem with 
>>> that is if you do builds pre branch they could conflict if using the same 
>>> version number.
>>>
>>> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
>>> rebuild all your projects. As maven will download it again if it still 
>>> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
>>> jobs still has an older version as a dependency.
>>>
>>>
>>>
>>> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>>>
>>>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>>>> also called 'local repository'.
>>>>
>>>> My theory is that you have a job or more that uses maven with default 
>>>> values. I suspect you even run these on the controller itself...
>>>>
>>>> Some of your job(s) build(s) a software of yours that depends on a 
>>>> vulnerable version of log4j.
>>>>
>>>>
>>>>
>>>>
>>>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  
>>>> a écrit :
>>>>
>>>>> Hi all.  Getting popped by our security team for an old version of 
>>>>> log4j.  I've checked and we don't have any of the plugins installed 
>>>>> identified by the following issue:
>>>>>
>>>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>>>
>>>>> Here's the info from the scan:
>>>>>
>>>>> Plugin Output: 
>>>>>   Path  : 
>>>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>>>   Installed version : 2.14.1
>>>>>   Fixed version : 2.15.0
>>>>>
>>>>> Anyone have a clue on how I go about upgrading this?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>> -- 
>>>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>>> 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 vie

Re: Log4j CVE-2021-44228

[eric....@gmail.com]

Thanks a ton, great cud to chew on!  Now I think I know the culprit and 
it's been deprecated.  Guessing I can just delete that log4j directory and 
be done with it.

On Thursday, December 16, 2021 at 1:12:28 PM UTC-7 nhoj.p...@gmail.com 
wrote:

> I would exclude /opt/jenkins/.m2/repository from any scans, as already 
> mentioned that is the local maven cache.
> Also if you don't maintain that, it will grow and grow.
> Personally I update build jobs so they each have their own maven cache 
> using -Dmaven.repo.local=mvn-repo then delete that after your job 
> completes. You might need to tweak some of your process if they depending 
> upon one job installing and another job consuming. But the problem with 
> that is if you do builds pre branch they could conflict if using the same 
> version number.
>
> Or, delete /opt/jenkins/.m2/repository/org/apache/logging/log4j/ and 
> rebuild all your projects. As maven will download it again if it still 
> needs it. If a pre 2.15.0/2.16.0 version appears, then it means one of your 
> jobs still has an older version as a dependency.
>
>
>
> On Thu, 16 Dec 2021 at 18:59, Baptiste Mathus  wrote:
>
>> That's unrelated to Jenkins per se. This directory is the maven cache, 
>> also called 'local repository'.
>>
>> My theory is that you have a job or more that uses maven with default 
>> values. I suspect you even run these on the controller itself...
>>
>> Some of your job(s) build(s) a software of yours that depends on a 
>> vulnerable version of log4j.
>>
>>
>>
>>
>> Le jeu. 16 déc. 2021 à 19:15, eric@gmail.com  a 
>> écrit :
>>
>>> Hi all.  Getting popped by our security team for an old version of 
>>> log4j.  I've checked and we don't have any of the plugins installed 
>>> identified by the following issue:
>>>
>>> https://issues.jenkins.io/browse/JENKINS-67353
>>>
>>> Here's the info from the scan:
>>>
>>> Plugin Output: 
>>>   Path  : 
>>> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>>>   Installed version : 2.14.1
>>>   Fixed version : 2.15.0
>>>
>>> Anyone have a clue on how I go about upgrading this?
>>>
>>> Thanks,
>>> Eric
>>>
>>> -- 
>>> 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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> -- 
>> 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/CANWgJS7PpCx6a9J__vv7G-oYC0ssUbZbW%2Ba8_bWsS0_Na-6dyw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS7PpCx6a9J__vv7G-oYC0ssUbZbW%2Ba8_bWsS0_Na-6dyw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/6147a143-256b-4f71-9b42-081744fc6bb8n%40googlegroups.com.

Re: Log4j CVE-2021-44228

[eric....@gmail.com]

Hmmm, found this page:

https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/

So I ran the script in the script console and got the error indicating that 
log4j is not included in any installed and enabled plugin.  Anyone have a 
clue?

Thanks,
Eric

On Thursday, December 16, 2021 at 11:15:25 AM UTC-7 eric@gmail.com 
wrote:

> Hi all.  Getting popped by our security team for an old version of log4j.  
> I've checked and we don't have any of the plugins installed identified by 
> the following issue:
>
> https://issues.jenkins.io/browse/JENKINS-67353
>
> Here's the info from the scan:
>
> Plugin Output: 
>   Path  : 
> /opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
>   Installed version : 2.14.1
>   Fixed version : 2.15.0
>
> Anyone have a clue on how I go about upgrading this?
>
> Thanks,
> Eric
>

-- 
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/c7c21022-d446-451f-939c-adb4eb4eebden%40googlegroups.com.

Log4j CVE-2021-44228

[eric....@gmail.com]

Hi all.  Getting popped by our security team for an old version of log4j.  
I've checked and we don't have any of the plugins installed identified by 
the following issue:

https://issues.jenkins.io/browse/JENKINS-67353

Here's the info from the scan:

Plugin Output: 
  Path  : 
/opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.pom.sha1
  Installed version : 2.14.1
  Fixed version : 2.15.0

Anyone have a clue on how I go about upgrading this?

Thanks,
Eric

-- 
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/0e0194bf-3090-43e1-92d2-be3789365ae5n%40googlegroups.com.

GitHub Plugin Checkout Specific Folder

[eric....@gmail.com]

Hi!  In a nutshell, I'm cloning for builds, not doing any polling or such.  
I clear my workspace then check out my repository.  I'd like to do the same 
but just grab a specific folder.  I'm guessing this would be done in my 
branch specifier.  As it stands now, for this particular checkout 
operation, it's always going to be the master branch, so that's all I'm 
passing for this attribute is master.  Is there a way to change that to say 
master/FolderName to just get that specific folder?  If so, what's the 
format to do so?  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/ed896779-670d-46d1-8fb1-a2ddbf6f2ae3n%40googlegroups.com.

Re: Jenkins 2.277.1 Issue?

[eric....@gmail.com]

Thanks xJom, finally put in the time, figured out the necessary upgrades 
and did it.  Worked like a charm!!!

On Tuesday, April 6, 2021 at 6:54:31 AM UTC-6 xJom wrote:

> So, the https://github.com/jenkinsci/plugin-installation-manager-tool 
> really saved my day. I went through the plugins directory and checked 
> against the compatibility list, and upgraded all of the plugins with the 
> Plugin Installation Manager Tool. And finally we are up-and-running again!
>
> fredag 2 april 2021 kl. 14:37:53 UTC+2 skrev xJom:
>
>> I have the same problem on one of my instances, but I also have the 
>> problem that I cannot go back to previous version, because it destroys the 
>> other instances. I think there is a compatibility issue for plugins, and if 
>> you could go back, then update all your plugins according to the 
>> compatility matrix here. 
>> https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc
>> For me, I think I need to try to upgrade the plugins manually...
>>
>> måndag 22 mars 2021 kl. 16:15:15 UTC+1 skrev eric@gmail.com:
>>
>>> Hi!  Last week we took 2.277.1 when patching.  I didn't see any issues 
>>> until this morning when I tried to log on and got 403 No valid crumb was 
>>> included in the request.  I restarted the server a few times trying to fix 
>>> it but never could get logged in.  I did some research and found a thread 
>>> telling me to make a global security setting change to proxy compatibility 
>>> (even though I'm not proxied), but couldn't get to global security to try 
>>> that.  So I backed it out to 2.263.4, where we were before.  It's working 
>>> again, but I'm guessing the same thing will happen next time we apply 
>>> patches.  Is there a change with 277 that will make me have to change some 
>>> setting or another?  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/4f26ed8c-a839-4ca4-8732-04b0157bf2a0n%40googlegroups.com.

Git Plugin Checkout From Branch With Tag

[eric....@gmail.com]

OK, I think I've tried everything in this OLD conversation, but none of 
them work.  I have no issues checking out from a branch using branch 
specifier.  I've tried adding on to the specifier:  ${my_branch} 
tags/${my_tag}.  Have also added another branch and used this sort of thing 
(as well as every other way they said to do it in that thread).  Every way 
seems to just get the tip revision of all the files in that branch.  Does 
anyone have guidance of how to get this done?  Thanks!  Eric

-- 
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/c045a834-8d68-46fe-8b72-860e89416209n%40googlegroups.com.

Re: Node no longer working

[eric....@gmail.com]

OK, further proof that I'm fried this week.  I needed to put the key in for 
the jenkins user, not the  user.  The jenkins user public key is 
in the authorized_hosts file for  so that he can authenticate as 
that user.  This is fixed...

On Monday, April 12, 2021 at 10:36:46 AM UTC-6 eric@gmail.com wrote:

> So I had a node up to run as a user other than Jenkins.  It stopped 
> working and I have no idea why.  My trouble-shooting ability has just 
> reached its limit.  Anyone have any ideas for me to try?  Here are my steps 
> to set it up (the RSA Key seems to be what is failing):
>
>
>1. Go to Credentials / System (shows up under Credentials) / Global 
>credentials
>2. Click Add Credentials 
>3. Kind:  SSH Username with private key 
>4. ID:  RSAKey
>Description:  RSA Key
>Username:  
>Private Key:  Select Enter directly and paste it in from results of 
>cat ~/.ssh/id_rsa (RSA should have been created without passphrase, but if 
>you created a passphrase, enter it in the Passphrase text box)
>
>5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node 
>6. Name:  Node
>Description: Run as 
># of executors: 1
>Remote root directory: /home/
>Labels: Checkout
>Usage: Only build jobs with label expressions matching this node
>Launch method: Launch agents via SSH
>Host: localhost
>Credentials:  (username RSA Key)
>Host Key Verification Strategy: Non verifying Verification Strategy
>Availability: Keep this agent online as much as possible
>
> So, when I try to start the node, I get:
>
>
>
> [04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22. 
> [04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified. 
> Man-in-the-middle attacks may be possible against this connection. ERROR: 
> Server rejected the 1 private key(s) for  
> (credentialId:RSAKey/method:publickey)
> [04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed. 
> [04/12/21 11:34:47] Launch failed - cleaning up connection 
> [04/12/21 11:34:47] [SSH] Connection closed.
>
> Thanks much!
> Eric
>

-- 
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/0a42daa4-1072-4995-a698-33ea0968fbc4n%40googlegroups.com.

Re: Node no longer working

[eric....@gmail.com]

Note that I have no problem ssh'ing from the jenkins user to the  
user passwordless.  The jenkins user key is in the authorized_keys file of 
the  user.  Really kind of blown away why this all of a sudden 
stopped working.  It was working fine...

On Monday, April 12, 2021 at 10:36:46 AM UTC-6 eric@gmail.com wrote:

> So I had a node up to run as a user other than Jenkins.  It stopped 
> working and I have no idea why.  My trouble-shooting ability has just 
> reached its limit.  Anyone have any ideas for me to try?  Here are my steps 
> to set it up (the RSA Key seems to be what is failing):
>
>
>1. Go to Credentials / System (shows up under Credentials) / Global 
>credentials
>2. Click Add Credentials 
>3. Kind:  SSH Username with private key 
>4. ID:  RSAKey
>Description:  RSA Key
>Username:  
>Private Key:  Select Enter directly and paste it in from results of 
>cat ~/.ssh/id_rsa (RSA should have been created without passphrase, but if 
>you created a passphrase, enter it in the Passphrase text box)
>
>5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node 
>6. Name:  Node
>Description: Run as 
># of executors: 1
>Remote root directory: /home/
>Labels: Checkout
>Usage: Only build jobs with label expressions matching this node
>Launch method: Launch agents via SSH
>Host: localhost
>Credentials:  (username RSA Key)
>Host Key Verification Strategy: Non verifying Verification Strategy
>Availability: Keep this agent online as much as possible
>
> So, when I try to start the node, I get:
>
>
>
> [04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22. 
> [04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified. 
> Man-in-the-middle attacks may be possible against this connection. ERROR: 
> Server rejected the 1 private key(s) for  
> (credentialId:RSAKey/method:publickey)
> [04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed. 
> [04/12/21 11:34:47] Launch failed - cleaning up connection 
> [04/12/21 11:34:47] [SSH] Connection closed.
>
> Thanks much!
> Eric
>

-- 
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/fd08eb85-0b55-427d-bc65-bd3ec57b4811n%40googlegroups.com.

Node no longer working

[eric....@gmail.com]

So I had a node up to run as a user other than Jenkins.  It stopped working 
and I have no idea why.  My trouble-shooting ability has just reached its 
limit.  Anyone have any ideas for me to try?  Here are my steps to set it 
up (the RSA Key seems to be what is failing):


   1. Go to Credentials / System (shows up under Credentials) / Global 
   credentials
   2. Click Add Credentials 
   3. Kind:  SSH Username with private key 
   4. ID:  RSAKey
   Description:  RSA Key
   Username:  
   Private Key:  Select Enter directly and paste it in from results of cat 
   ~/.ssh/id_rsa (RSA should have been created without passphrase, but if you 
   created a passphrase, enter it in the Passphrase text box)
   
   5. Go to Manage Jenkins / Manage Nodes and Clouds / New Node 
   6. Name:  Node
   Description: Run as 
   # of executors: 1
   Remote root directory: /home/
   Labels: Checkout
   Usage: Only build jobs with label expressions matching this node
   Launch method: Launch agents via SSH
   Host: localhost
   Credentials:  (username RSA Key)
   Host Key Verification Strategy: Non verifying Verification Strategy
   Availability: Keep this agent online as much as possible

So, when I try to start the node, I get:

   

[04/12/21 11:34:47] [SSH] Opening SSH connection to localhost:22. 
[04/12/21 11:34:47] [SSH] WARNING: SSH Host Keys are not being verified. 
Man-in-the-middle attacks may be possible against this connection. ERROR: 
Server rejected the 1 private key(s) for  
(credentialId:RSAKey/method:publickey)
[04/12/21 11:34:47] [SSH] Authentication failed. Authentication failed. 
[04/12/21 11:34:47] Launch failed - cleaning up connection 
[04/12/21 11:34:47] [SSH] Connection closed.

Thanks much!
Eric

-- 
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/1b82bf53-b379-4342-9df8-45e904df6a1bn%40googlegroups.com.

Re: GitHub Clone to Different Local Directory

[eric....@gmail.com]

The only thing I can guess is that ssh is getting a question when he 
attempts to connect wanting to be added to the known_hosts file.  Wondering 
if maybe there's a way to establish this if this is indeed the issue?

On Monday, March 29, 2021 at 12:07:01 PM UTC-6 eric@gmail.com wrote:

> Thanks Mark!  I believe I'm one step closer but it's still not working.  
> I'm now getting:
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress git@myURLRepo:myUser/myProject.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: 
> stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal: 
> Could not read from remote repository. Please make sure you have the 
> correct access rights and the repository exists.
>
>
>
> On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:
>
>> You can't use ssh authentication with an https repository URL.  When 
>> using ssh authentication, you need to use an ssh repository URL.  When 
>> using username / password or username / token, you must use an HTTPS (or 
>> HTTP) URL.
>>
>> Mark Waite
>>
>> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>>
>>> Hmmm, thought that was going to work but it didn't.  I followed 
>>> everything to a T at:  
>>> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>>> The output shows:
>>>
>>> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>>> using credential JenkinsSSHKey
>>>  > git rev-parse --is-inside-work-tree # timeout=10
>>> Fetching changes from the remote Git repository
>>>  > git config remote.origin.url https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git # timeout=10
>>> Cleaning workspace
>>>  > git rev-parse --verify HEAD # timeout=10
>>> No valid HEAD. Skipping the resetting
>>>  > git clean -fdx # timeout=10
>>> Fetching upstream changes from https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>>  > git --version # timeout=10
>>> using GIT_SSH to set credentials 
>>>
>>>
>>> So I see it's using the creds.  Then when it tries to do the fetch, it 
>>> says:
>>>
>>>  > git fetch --tags --progress https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> hudson.plugins.git.GitException: Failed to fetch from https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git
>>> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
>>> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
>>> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
>>> at hudson.scm.SCM.checkout(SCM.java:505)
>>> at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
>>> at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
>>> at hudson.model.Run.execute(Run.java:1907)
>>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>> at hudson.model.ResourceController.execute(ResourceController.java:97)
>>> at hudson.model.Executor.run(Executor.java:429)
>>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>>> --progress https://m 
>>> <https://code.fs.usda.gov/ericfetzer/iNAP.git>yGitRepo.git 
>>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>>> stdout: 
>>> stderr: remote: Password authentication is not available for Git operations.
>>> remote: You must use a personal access token or SSH key.
>>>
>>>
>>>
>>> On Mon, Mar 29, 2021 at 8:09 AM Eric Fetzer  wrote:
>>>
>>>> O, duh, I get it now.  I create the key with the jenkins user and 
>>>> add id_rsa.pub to the GitHub account for access.  I was somehow thinking I 
>>>> would need a key on the GitHub side.  Feeling kind of foolish now, lol.  
>>>> Thanks Dirk!
>>>>
>>>> On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
>>>> jenkins...@googlegroups.com> wrote:
>>>>
>>>>&

Re: GitHub Clone to Different Local Directory

[eric....@gmail.com]

Thanks Mark!  I believe I'm one step closer but it's still not working.  
I'm now getting:

Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress git@myURLRepo:myUser/myProject.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: 
stderr: ssh: connect to host myURLRepo port 22: Connection timed out fatal: 
Could not read from remote repository. Please make sure you have the 
correct access rights and the repository exists.



On Monday, March 29, 2021 at 11:23:28 AM UTC-6 Mark Waite wrote:

> You can't use ssh authentication with an https repository URL.  When using 
> ssh authentication, you need to use an ssh repository URL.  When using 
> username / password or username / token, you must use an HTTPS (or HTTP) 
> URL.
>
> Mark Waite
>
> On Mon, Mar 29, 2021 at 10:38 AM Eric Fetzer  wrote:
>
>> Hmmm, thought that was going to work but it didn't.  I followed 
>> everything to a T at:  
>> https://mohitgoyal.co/2017/02/27/configuring-ssh-authentication-between-github-and-jenkins/
>> The output shows:
>>
>> Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout
>> using credential JenkinsSSHKey
>>  > git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://m 
>> yGitRepo.git # timeout=10
>> Cleaning workspace
>>  > git rev-parse --verify HEAD # timeout=10
>> No valid HEAD. Skipping the resetting
>>  > git clean -fdx # timeout=10
>> Fetching upstream changes from https://m 
>> yGitRepo.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials 
>>
>>
>> So I see it's using the creds.  Then when it tries to do the fetch, it 
>> says:
>>
>>  > git fetch --tags --progress https://m 
>> yGitRepo.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> hudson.plugins.git.GitException: Failed to fetch from https://m 
>> yGitRepo.git
>>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
>>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
>>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
>>  at hudson.scm.SCM.checkout(SCM.java:505)
>>  at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
>>  at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
>>  at hudson.model.Run.execute(Run.java:1907)
>>  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>  at hudson.model.ResourceController.execute(ResourceController.java:97)
>>  at hudson.model.Executor.run(Executor.java:429)
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --progress https://m 
>> yGitRepo.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout: 
>> stderr: remote: Password authentication is not available for Git operations.
>> remote: You must use a personal access token or SSH key.
>>
>>
>>
>> On Mon, Mar 29, 2021 at 8:09 AM Eric Fetzer  wrote:
>>
>>> O, duh, I get it now.  I create the key with the jenkins user and 
>>> add id_rsa.pub to the GitHub account for access.  I was somehow thinking I 
>>> would need a key on the GitHub side.  Feeling kind of foolish now, lol.  
>>> Thanks Dirk!
>>>
>>> On Mon, Mar 29, 2021 at 7:52 AM 'Dirk Heinrichs' via Jenkins Users <
>>> jenkins...@googlegroups.com> wrote:
>>>
 Am Montag, den 29.03.2021, 07:44 -0600 schrieb Eric Fetzer:

 Thanks for your reply Dirk!  I'm a unix guy and that would have been my 
 first choice, however I don't have access to the GitHub OS, only my 
 particular repositories.


 I don't understand. Nobody has this kind of access. But everybody can 
 add SSH keys to their GH account (using the web UI).

 Bye...

 Dirk

 -- 

 *Dirk Heinrichs*
 Senior Systems Engineer, Delivery Pipeline
 OpenText ™ Discovery | Recommind
 *Phone*: +49 2226 15966 18 <+49%202226%201596618>
 *Email*: dhei...@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, 

Re: GitHub Clone to Different Local Directory

[eric....@gmail.com]

Yes Bjorn, that's the thread I used to figure out how to use the access 
token.  Unfortunately, the jenkins plugin isn't smart enough to pass a 
username, it uses the username it runs as.  So my master node is running as 
the user "jenkins" so it tries to authenticate to GitHub Enterprise as 
jenkins: Did you try to use credentials in jenkins to store the token  instead of  
> fiddling  with token on the machine?
> See e.g. 
> https://stackoverflow.com/questions/61105368/how-to-use-github-personal-access-token-in-jenkins
>
>
> Then you could do everything in one job instead of  doing some copy-magic 
> (which would  horribly break once you start to use more nodes).
>
> Björn
> eric@gmail.com schrieb am Samstag, 27. März 2021 um 04:05:44 UTC+1:
>
>> Thanks Mark, I'll check it out.  Has to beat the hokey workaround I 
>> worked up.  :)
>>
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>  Original message 
>> From: Mark Waite  
>> Date: 3/26/21 10:49 PM (GMT-05:00) 
>> To: Jenkins Users  
>> Subject: Re: GitHub Clone to Different Local Directory 
>>
>> Good point.  How about the external workspace plugin from GSoC 2016?  
>> https://plugins.jenkins.io/external-workspace-manager/
>>
>> On Fri, Mar 26, 2021 at 8:00 PM eric.fetzer  wrote:
>>
>>> Thanks for the response Mark..  I'm using freestyle.  Doesn't checkout 
>>> to a subdirectory only take relative paths?
>>>
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>  Original message 
>>> From: Mark Waite  
>>> Date: 3/26/21 6:44 PM (GMT-05:00) 
>>> To: Jenkins Users  
>>> Subject: Re: GitHub Clone to Different Local Directory 
>>>
>>> If you're using pipeline, change to that directory with the 
>>> dir('/users/username/projectname') { } wrapper around the checkout step;
>>>
>>> If you're using a freestyle job, use the git plugin extension 'checkout 
>>> to a subdirectory' 
>>> <https://plugins.jenkins.io/git/#checkout-to-a-sub-directory>
>>>
>>> On Fri, Mar 26, 2021 at 10:54 AM eric@gmail.com  
>>> wrote:
>>>
>>>> OK, so this is kind of complex so hang with me.  We're moving from 
>>>> StarTeam to Github and I'm trying to reproduce what I'm doing in StarTeam 
>>>> with Github.  StarTeam was easy because I owned the repository machine as 
>>>> well as administrated the tool.  With Github, we're hosted.  So I'm admin 
>>>> on the project but can't create an RSA Token on the machine for easy 
>>>> access.  So I had to play around to make a personal access token work.  In 
>>>> order to make that access token work, I had to run the checkout job on a 
>>>> different node so that it was running as a user that lived in Github as 
>>>> well (access token's namesake).  So when this job gets called from the 
>>>> jenkins job, I want it to clone to the calling job's workspace 
>>>> (/opt/jenkins/workspace/).  Well since in order to 
>>>> authenticate, it lives in it's own shell, the workspace for this guy, and 
>>>> where it wants to clone to, is /home//.  All that 
>>>> for my question:  how can I specify what folder to checkout to?  I tried 
>>>> to 
>>>> use "checkout to specific local branch" but it fails saying "is not a 
>>>> valid 
>>>> branch name".  Well, yeah, branch is referring to branch not folder, lol.  
>>>> In StarTeam this is easy, you just specify working folder.  Any help?  
>>>> 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-use...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-users/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Jenkins Users" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.c

GitHub Clone to Different Local Directory

[eric....@gmail.com]

OK, so this is kind of complex so hang with me.  We're moving from StarTeam 
to Github and I'm trying to reproduce what I'm doing in StarTeam with 
Github.  StarTeam was easy because I owned the repository machine as well 
as administrated the tool.  With Github, we're hosted.  So I'm admin on the 
project but can't create an RSA Token on the machine for easy access.  So I 
had to play around to make a personal access token work.  In order to make 
that access token work, I had to run the checkout job on a different node 
so that it was running as a user that lived in Github as well (access 
token's namesake).  So when this job gets called from the jenkins job, I 
want it to clone to the calling job's workspace 
(/opt/jenkins/workspace/).  Well since in order to 
authenticate, it lives in it's own shell, the workspace for this guy, and 
where it wants to clone to, is /home//.  All that 
for my question:  how can I specify what folder to checkout to?  I tried to 
use "checkout to specific local branch" but it fails saying "is not a valid 
branch name".  Well, yeah, branch is referring to branch not folder, lol.  
In StarTeam this is easy, you just specify working folder.  Any help?  
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/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com.

Jenkins 2.277.1 Issue?

[eric....@gmail.com]

Hi!  Last week we took 2.277.1 when patching.  I didn't see any issues 
until this morning when I tried to log on and got 403 No valid crumb was 
included in the request.  I restarted the server a few times trying to fix 
it but never could get logged in.  I did some research and found a thread 
telling me to make a global security setting change to proxy compatibility 
(even though I'm not proxied), but couldn't get to global security to try 
that.  So I backed it out to 2.263.4, where we were before.  It's working 
again, but I'm guessing the same thing will happen next time we apply 
patches.  Is there a change with 277 that will make me have to change some 
setting or another?  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/442af655-e31b-42ef-a083-519e1d5c1c20n%40googlegroups.com.

Re: Security Vulnerability on my Jenkins Server

[eric....@gmail.com]

I'm sorry, I just saw the last comment on here and, once again, this showed 
up on our vulnerability report.  I don't get exactly what I need to do in 
order to fix this.  Can someone lay it out for me please?  Thanks - Eric

On Wednesday, August 26, 2020 at 12:39:40 PM UTC-6 kuisat...@gmail.com 
wrote:

> I was wrong you cannot configure the ciphers for the ssh server on the 
> Java security files. The SSH server on Jenkins uses the 
> https://github.com/apache/mina-sshd , IIRC the Jenkins implementation of 
> the ssh server not read the sshd_config files so it is not posible to 
> configure the ssh server. Apache mina has deprecated and disable those 
> algorithms on 2.6.0 https://issues.apache.org/jira/browse/SSHD-1004, the 
> sshd-module and CLI are using 1.7.0 
> https://github.com/jenkinsci/sshd-module/blob/master/pom.xml#L42 and 
> https://github.com/jenkinsci/jenkins/blob/master/cli/pom.xml#L77 So I 
> guess both should bump the dependency to remove support for weak algorithms 
>
>
> El miércoles, 26 de agosto de 2020 a las 16:06:22 UTC+2, 
> eric@gmail.com escribió:
>
>> I think I found the solution to this:
>>
>>
>> https://www.thegeekdiary.com/how-to-disable-md5-based-hmac-algorithms-for-ssh/
>>   
>>
>> On Tuesday, August 25, 2020 at 1:59:49 PM UTC-6 eric@gmail.com wrote:
>>
>>> I'm confused.  It doesn't look like the ciphers the vulnerability is 
>>> citing are allowed in the java.security file on this system.  We're getting 
>>> flagged for:
>>>
>>>  hmac-md5
>>>   hmac-md5-96
>>>   hmac-sha1-96
>>>
>>> Settings are:
>>>
>>> jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 
>>> 1024, \
>>> EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>>>
>>> Am I missing this, not a java security expert by any means...  Thanks!
>>> On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com 
>>> wrote:
>>>
>>>> Yes, configuring the ciphers accepted by your JDK edit the 
>>>> file lib\security\java.security (the path will vary based on your Java 
>>>> version)
>>>>
>>>> El lunes, 24 de agosto de 2020 a las 16:48:22 UTC+2, eric@gmail.com 
>>>> escribió:
>>>>
>>>>> Hi all!  I'm getting hit by my secuity team for a vulnerability for 
>>>>> the Jenkins CLI via ssh allowing the following weak ciphers:
>>>>>
>>>>>   hmac-md5
>>>>>   hmac-md5-96
>>>>>   hmac-sha1-96
>>>>>
>>>>> Is there a way to configure ciphers accepted for the Jenkins CLI?
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>

-- 
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/07db750a-9c00-40ee-bc68-0a2b051c48fdn%40googlegroups.com.

Vulnerability in JQuery on Jenkins

[eric....@gmail.com]

Hi All,

Just got gigged by our security team for a vulnerability in Jenkins with 
the version of JQuery installed.  How do I go about updating the version of 
JQuery Jenkins runs?  Here's the specifics of the vulnerability:

Plugin Output: 
  URL   : http://myMachine:8081/js/jquery-1.11.1.min.js
  Installed version : 1.11.1
  Fixed version : 3.5.0

I'm running version 2.235.5 of Jenkins.

Thanks,
Eric

-- 
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/13c921b1-02f4-4f00-a474-266fe766ced0n%40googlegroups.com.

Re: Security Vulnerability on my Jenkins Server

[eric....@gmail.com]

I'm confused.  It doesn't look like the ciphers the vulnerability is citing 
are allowed in the java.security file on this system.  We're getting 
flagged for:

 hmac-md5
  hmac-md5-96
  hmac-sha1-96

Settings are:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL

Am I missing this, not a java security expert by any means...  Thanks!
On Monday, August 24, 2020 at 11:09:43 AM UTC-6 kuisat...@gmail.com wrote:

> Yes, configuring the ciphers accepted by your JDK edit the 
> file lib\security\java.security (the path will vary based on your Java 
> version)
>
> El lunes, 24 de agosto de 2020 a las 16:48:22 UTC+2, eric@gmail.com 
> escribió:
>
>> Hi all!  I'm getting hit by my secuity team for a vulnerability for the 
>> Jenkins CLI via ssh allowing the following weak ciphers:
>>
>>   hmac-md5
>>   hmac-md5-96
>>   hmac-sha1-96
>>
>> Is there a way to configure ciphers accepted for the Jenkins CLI?
>>
>> Thanks,
>> Eric
>>
>

-- 
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/cd72f7b2-5aa3-4e6e-96da-579cb50b43e3n%40googlegroups.com.

Security Vulnerability on my Jenkins Server

[eric....@gmail.com]

Hi all!  I'm getting hit by my secuity team for a vulnerability for the 
Jenkins CLI via ssh allowing the following weak ciphers:

  hmac-md5
  hmac-md5-96
  hmac-sha1-96

Is there a way to configure ciphers accepted for the Jenkins CLI?

Thanks,
Eric

-- 
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/392ef479-9516-4f17-9373-8054ef703bb5n%40googlegroups.com.