Re: Why does Jenkins need to read the memory of lsass.exe?

['jn...@cloudbees.com' via Jenkins Users]

Jenkins when it is finished ecexuting things for a job on an agent when it 
finishes like to tidy up (aka kill) any errant processes that have been 
started tht the build scripts failed to terminate (pesky build scripts!).

In order to do this it sets a special environment variable, which is then 
inherited by all processes that it spawns (there are ways to avoid this 
but...)

So when the build has finished it looks for all processes that have this 
special variable set so it can kill them.  In order to get the environment 
variables from a process it needs to be able to read certain portions - and 
this is probably what is being reported as it tries to open the process to 
read its environment.

Either that - or it is the lookig for the parent/child relationship (to 
find the spawned process) that is flagging it.

Or... its not Jenkins at all but somethign that has been launched as 
Jenkins.

https://github.com/jenkinsci/jenkins/blob/fb6a03c2507536d944032dbef337c51e43ceaa5e/core/src/main/java/hudson/util/ProcessTree.java#L544-L664
https://github.com/jenkinsci/winp/blob/master/native/winp.cpp

/James



On Thursday, August 17, 2023 at 8:56:52 AM UTC+1 amedee@gmail.com wrote:

> Hi,
>
> Security question here.
>
> Is there any reason why Jenkins would ever need to request the content of 
> c:\windows\system32\lsass.exe (Local Security Authority Subsystem Service)?
>
> The endpoint protection on the Jenkins device is denying Jenkins access to 
> lsass.exe, and the devs are unable to tell me why their favorite automation 
> tool needs to do an activity that is highly suspicious in terms of 
> security. Adversaries may attempt to access credential material stored in 
> the process memory of the Local Security Authority Subsystem Service.
>
> I was hoping that the community could help me here. I have no direct 
> access to the Jenkins device, I only see suspicious events being reported 
> by the endpoint security software.
>

-- 
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/f08c4f35-8ca6-4a75-8657-58c7eca9e1acn%40googlegroups.com.

Re: Kubernetes Plugin - Running more than one agent of a pod template concurrently

['jn...@cloudbees.com' via Jenkins Users]

we notice that only a single agent pod is active at a time.
- First job is active, and create a pod successfully.
- Once a new parallel job triggers, it tries to use the same agent pod, and 
keep waiting for an executor t become avalable on same pod which first job 
is using
- Once first job completes, and the pod it was using gets terminated, then 
second job spawns a new agent pod


sounds like an issue in your pipeline, did you check / follow the docs esp 
wrt  podTemplate and POD_LABEL [1]

/James

[1] 
https://plugins.jenkins.io/kubernetes/#plugin-content-using-the-pipeline-step

-- 
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/c06c4745-5993-4768-ae21-cd3cb58cn%40googlegroups.com.

Re: ‘Discard Old Items’ not removing all directories for multi-branch pipeline

['jn...@cloudbees.com' via Jenkins Users]

Looking at the code it appears as though the pipeline was running but when 
Jenkins was restarted it could not find its data. 
(https://github.com/jenkinsci/workflow-cps-plugin/blob/a6ac2775ac1767f68ddabcff14364235a61e8bdf/plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java#L659)

Perhaps you had some dirty shutdown of Jenkins and are using a non 
survivable performace strategy rather than  MAX_SURVIVABILITY  
 ? https://www.jenkins.io/doc/book/pipeline/scaling-pipeline/

/James



On Monday, July 10, 2023 at 3:04:21 PM UTC+1 james@secondmind.ai wrote:

> I have a multi-branch pipeline with ‘Discard old Items’ set up to get rid 
> of old PRs, but I’ve noticed that the directories aren’t all being removed 
> completely from the controller’s filesystem. These directories have no 
> confg.xml and they disappear from the UI but it leads to warning messages 
> in the log saying the config.xml couldn’t be found for the PR job. They all 
> seem to have the remnants of a single build that wasn’t removed correctly, 
> which includes a directory named ‘workflow-fallback’. What remains looks 
> like:
>
>
> $JENKINS_HOME/jobs//branches//builds//
>
> build.xml
>
> workflow-fallback/
>
>  .xml
>
>
> This workflow-fallback directory doesn’t currently exist for any build of 
> a PR that hasn’t been removed, so I’m unsure where it come from. Given the 
> time stamps of these directories this was happening over a wide span of 
> versions up to and including 2.401.2.
>
>
> Can anyone explain what’s happening and is there anything I can do to 
> prevent this?
>

-- 
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/91073651-8d0d-4260-9de2-fac469cbd963n%40googlegroups.com.

Re: Jenkins upgrade from 2.250 to 2.275

[jn...@cloudbees.com]

you can just switch the war.
Make sure you do not go to a lower version though.  in other words if you 
are on 2.275  you could use 2.289.1 but you use 2.292 then you will have to 
wait for the next LTS to be released above that (which will be about 3 
months time).


On Monday, May 31, 2021 at 6:34:52 PM UTC+1 s.p...@gmail.com wrote:

> Thank you Björn . I will look into this. Are there any steps I need to 
> consider before migrating from weekly versions to LTS or just download the 
> war and replace it with the current war file?  Really appreciate your help !
>
> On Monday, May 31, 2021 at 2:51:24 AM UTC-4 ice...@googlemail.com wrote:
>
>> BTW, if you don't want to do too frequent updates (upgrade each week and 
>> check for all changes each time), I would consider switching to the LTS 
>> series (2.277.1 in your case).
>> Then such changes would be easier to find in the LTS changelog. 
>>
>> Björn
>>
>> Björn Pedersen schrieb am Montag, 31. Mai 2021 um 08:47:46 UTC+2:
>>
>>> Hi,
>>>
>>> it seems you  did not upgrade all plugins as well. These effects are 
>>> caused by the tables-to-div migrations.
>>>
>>> See https://www.jenkins.io/doc/developer/views/table-to-div-migration/ 
>>> for more details...
>>>
>>> Björn
>>>
>>> s.p...@gmail.com schrieb am Montag, 31. Mai 2021 um 02:52:14 UTC+2:
>>>
 After I upgraded Jenkins from 2.250 to 2.275, I noticed that the UI for 
 the Jobs configuration looks different. The section for Source Code 
 Management/Build Triggers/Build Environment/build/Post-build actions are 
 missing at the top of the job configuration page and I see a couple of 
 Artifactory configuration sections(tabs). Also, the SSH 
 settings/configuration that we set up for each job are missing. Not sure 
 how to turn off the Artifactory configuration and restore the SSH 
 settings. 
 Please the attached screenshots. Please help. TIA
 Jenkins is running on Windows 2012R2 server.




-- 
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/ce8b7200-4a5b-46d7-909f-fd3453409edbn%40googlegroups.com.

Re: Upgraded Plugins: Jenkins fails to start

[jn...@cloudbees.com]

There is a PR to the jacoco plugin that should fix this.

https://github.com/jenkinsci/jacoco-plugin/pull/151  along with a build of 
that 
https://ci.jenkins.io/job/Plugins/job/jacoco-plugin/job/PR-151/lastStableBuild/artifact/target/jacoco.hpi
 
for people who have been hit and want a fix (or to test it) before it gets 
released.

/James

On Tuesday, June 1, 2021 at 2:30:34 AM UTC+1 raould...@gmail.com wrote:

> We stumbled on the same error after upgrading plugins on Jenkins last week.
> Search in your Jenkins plugin directory for the jar file starting with the 
> name: guice.
> The results should only list one version of the guice jar.
>
> In our case it turned out that the Jacoco plugin came with a newer version 
> of guice than the other plugins did, That caused this problem. We 
> downgraded the Jacoco plugin and it worked again (from jacoco 3.2.0 back to 
> 3.1.1 )
>
> Op zondag 23 mei 2021 om 19:55:03 UTC+2 schreef sverr...@gmail.com:
>
>> I have upgraded all the plugins, then restarted Jenkins.
>> It fails to start properly.
>> Any idea what the problem here is about?
>>
>> The website is loading, but shows the following Stacktrace
>> java.lang.IllegalArgumentException: Unable to inject class 
>> hudson.model.UserIdMapper   at 
>> hudson.init.TaskMethodFinder.lookUp(TaskMethodFinder.java:125)
>>  at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:105) 
>>  at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175) 
>>  at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296) 
>>  at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131) 
>>  at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214) 
>>  at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
>>  at 
>> jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
>>  
>>  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:748) 
>> Caused: org.jvnet.hudson.reactor.ReactorException 
>>  at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282) 
>>  at jenkins.InitReactorRunner.run(InitReactorRunner.java:49) 
>>  at jenkins.model.Jenkins.executeReactor(Jenkins.java:1164)
>>  at jenkins.model.Jenkins.(Jenkins.java:962) 
>>  at hudson.model.Hudson.(Hudson.java:85) 
>>  at hudson.model.Hudson.(Hudson.java:81) 
>>  at hudson.WebAppMain$3.run(WebAppMain.java:295) 
>> Caused: hudson.util.HudsonFailedToLoad at 
>> hudson.WebAppMain$3.run(WebAppMain.java:312)
>>
>> The jenkins log output shows rthe following Exceptions:
>> 2021-05-23 16:50:01.547+ [id=37]INFO
>> jenkins.InitReactorRunner$1#onAttained: Listed all plugins
>> 2021-05-23 16:50:09.041+ [id=36]SEVERE  
>> h.ExtensionFinder$GuiceFinder#: Failed to create Guice container from 
>> all the plugins
>> java.lang.LinkageError: loader constraint violation: loader (instance of 
>> hudson/PluginFirstClassLoader) previously initiated loading for a different 
>> type with name "com/google/inject/Binder"
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>> at 
>> jenkins.util.AntClassLoader.defineClassFromData(AntClassLoader.java:1155)
>> at 
>> jenkins.util.AntClassLoader.getClassFromStream(AntClassLoader.java:1326)
>> at 
>> jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1377)
>> at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1342)
>> at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1095)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at 
>> com.google.inject.multibindings.Multibinder.newSetBinder(Multibinder.java:136)
>> at 
>> com.google.inject.multibindings.Multibinder.newSetBinder(Multibinder.java:99)
>> at 
>> hudson.plugins.depgraph_view.model.graph.DependencyGraphModule.configure(DependencyGraphModule.java:49)
>> at 
>> com.google.inject.AbstractModule.configure(AbstractModule.java:62)
>> at 
>> com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:340)
>> at com.google.inject.spi.Elements.getElements(Elements.java:110)
>> at 
>> com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:138)
>> at 
>> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
>> at com.google.inject.Guice.createInjector(Guice.java:96)
>> at com.google.inject.Guice.createInjector(Guice.java:73)
>> at 
>> hudson.ExtensionFinder$GuiceFinder.(ExtensionFinder.java:285)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
>> Method)
>> at 
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at 
>> 

Re: WebSocket Agents and Archiving Artifacts Performance

[jn...@cloudbees.com]

Hi Tim,

it is reasonable to assume that the performance may *change*.

Basically, a lot of this has to do with the chattyness of the channel, the 
latency, and buffer sizes setup etc etc..  
It may well be that the websocket channels are better sized by default in 
the regard (it could also be the inverse).  It also may depend heavily on 
the underlying infrastructure.

I would suggest you perform a quick test as the only way to be sure (and 
report back for others!)

but if you are using large artifacts perhaps you want to look at an 
external artifact manager instead such as s3 / azure etc   (e.g. 
https://www.jenkins.io/blog/2019/07/25/azure-artifact-manager/) ?

/James

On Wednesday, August 26, 2020 at 9:42:03 PM UTC+1 timb...@gmail.com wrote:

> Is there any reason to believe that using the new -webSocket mode for 
> agents would be any less sluggish at archiving artifacts from agent to 
> master than ssh mode? 
>
> Using the ssh-slaves-plugin I'm getting abysmal throughput (~13Mbps) when 
> artifacts are being copied from agent to master, despite their 10GBps link: 
> https://issues.jenkins-ci.org/browse/JENKINS-7921
>
> Reading up on some of the conversations on this long-standing issue over 
> the last decade, I'm not confident that this performance is going to be 
> improved. So, I'm considering alternatives, like using WebSocket agents. I 
> read here 
> that
>  
> the problem might be that "Jenkins archives via its control channel (e.g. 
> ssh slave - using java SSH implementation JSCH). The java ssh just can't 
> get anywhere near 1Gb/s network speed that native SSH can manage easily"
>
> So, I was just wondering if WebSocket Agents might perform better at 
> archiving artifacts bc they are implemented so differently.
>
> Thanks,
> Tim Black  
>

-- 
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/3036fbd2-0169-4a7c-b2d2-2ae2cc84b9e4n%40googlegroups.com.

Re: Windows slave by ssh

[jn...@cloudbees.com]

could this be https://issues.jenkins-ci.org/browse/JENKINS-47510 ?

On Thursday, August 27, 2020 at 3:55:08 PM UTC+1 slide wrote:

> Feel free to open your own PR then. I took the time to try and fix an 
> immediate issue in the short amount of time I had to look at it. This 
> should fix for the majority of people I believe, there will definitely be 
> corner cases that can be addressed in the future.
>
> On Thu, Aug 27, 2020 at 7:20 AM Jérôme Godbout  wrote:
>
>> Why only escape the command when it contains space, you could always do 
>> it, so other characters would also be properly escaped, the if is useless.
>>
>> if(javaCommand.contains(" ")) {
>>
>>  
>>
>> javaCommand = "\"" + javaCommand + "\"";
>>
>> }
>>
>>  
>>
>>  
>>
>> *From:* jenkins...@googlegroups.com  *On 
>> Behalf Of *Slide
>> *Sent:* August 27, 2020 10:11 AM
>> *To:* Jenkins User Mailing List 
>> *Subject:* Re: Windows slave by ssh
>>
>>  
>>
>> I opened this PR against the ssh-agents-plugin  
>> https://github.com/jenkinsci/ssh-slaves-plugin/pull/183
>>
>>  
>>
>> On Thu, Aug 27, 2020 at 6:22 AM Jérôme Godbout  wrote:
>>
>> This is exactly what I’m using now, not more need for Cygwin for ssh 
>> (about time Microsoft ). Remove any space from the JAVA_HOME path 
>> solve the issue, but the default install path for Java is inside the 
>> Program Files folders, so by default it has a space. Not supporting spaces 
>> (and probably other character) is a bug. It’s not a big issue, but this 
>> should be fix. As for the \ or /, this should be handle by the  source code 
>> and perform the right conversion to node native format. In my script I 
>> always use *nix / path and convert them to native before running the actual 
>> command in a shell. I even made some Groovy pipeline functions to be 
>> platform agnostic as much as possible, the default implementation force us 
>> to put if(isUnix()) everywhere and it’s annoying. Having a function to 
>> manipulate the files and folders (create, remove, touch, move, rename) 
>> should be there by default for CI pipelines and be platform agnostic. This 
>> is pretty basic stuff.
>>
>>  
>>
>> This is where you realize Qt, C# and Python are way ahead into path 
>> manipulation.  Do a little as possible into Groovy-ish language and use 
>> Ansible or Python scripts to do the actual work lifting, made my life so 
>> much less painful.
>>
>>  
>>
>> *From:* jenkins...@googlegroups.com  *On 
>> Behalf Of *Slide
>> *Sent:* August 26, 2020 6:03 PM
>> *To:* Jenkins User Mailing List 
>> *Subject:* Re: Windows slave by ssh
>>
>>  
>>
>> Well, running on Cygwin is almost like running on a *NIX platform. Not 
>> exactly, but almost. I am referring to the OpenSSH-Win64 port that is now 
>> supported by MS. 
>>
>>  
>>
>> On Wed, Aug 26, 2020 at 2:50 PM Jason Pyeron  wrote:
>>
>> Sorry to be a Johnny come lately – but we have only used SSH launch of 
>> windows for quite a long time now.
>>
>>  
>>
>> We use Cygwin to do so. You can use any SSH server though.
>>
>>  
>>
>> The most important thing is to ensure Java’s home has no spaces in the 
>> path.
>>
>>  
>>
>> The second most important thing is to use mixed pathing constructs. E.g. 
>> javaPath='C:/programs.x64/Java/jdk-14/bin/java note the forward slashes. It 
>> is a happy middle ground for bash and java.
>>
>>  
>>
>> *From:* jenkins...@googlegroups.com  *On 
>> Behalf Of *Slide
>> *Sent:* Wednesday, August 26, 2020 5:18 PM
>> *To:* Jenkins User Mailing List 
>> *Subject:* Re: Windows slave by ssh
>>
>>  
>>
>> Historically, Windows agents couldn't really be run using this plugin, it 
>> is only somewhat recently that Windows had good SSH support. So, there are 
>> probably some leftovers from the plugin only being used on *NIX systems. 
>>
>>  
>>
>> On Wed, Aug 26, 2020 at 2:07 PM Jérôme Godbout  wrote:
>>
>> Hi,
>>
>> Reinstalling Java into a path like c:\Java work just fine now. Wonder why 
>> the Linux and the Windows master doesn’t show the same behavior on this? Is 
>> this code part only for *nix platform?
>>
>>  
>>
>> Anyway, thanks for the pointer,
>>
>> Jerome
>>
>>  
>>
>> *From:* jenkins...@googlegroups.com  *On 
>> Behalf Of *Slide
>> *Sent:* August 26, 2020 4:23 PM
>> *To:* Jenkins User Mailing List 
>> *Subject:* Re: Windows slave by ssh
>>
>>  
>>
>> It looks like this code would need to be updated to handle when there are 
>> spaces:  
>> https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/src/main/java/hudson/plugins/sshslaves/JavaVersionChecker.java#L91.
>>  
>> I have the reverse, a Windows controller and Linux agents. I specify the 
>> JAVA_HOME environment variable in my agent configuration and that works. 
>> Can you try that?
>>
>>  
>>
>>  
>>
>>  
>>
>> On Wed, Aug 26, 2020 at 12:38 PM Jérôme Godbout  
>> wrote:
>>
>> Hi,
>>
>> I’m trying to access a Windows slave with SSH using Linux master Jenkins 
>> 2.235.5.
>>
>> [08/26/20 15:24:48] [SSH] Checking java version of 
>>