Re: Issue with master-agent communication over ssh

2021-02-04 Thread Jeff Thompson 
I agree with Ivan. There are differences, sometimes subtle, between how 
different agents behave for various reasons. The basic operations of the 
plugins and the protocol should be the same. There are can be 
differences in resource usage, platforms, etc. Sometimes plugins will 
behave differently on different one.


Try out some of Ivan's suggests or other troubleshooting like that and 
figure out how to isolate the problem.


Jeff Thompson

On 2/2/21 10:20 AM, Ivan Fernandez Calvo wrote:

>I have 2 different kind of jenkins agents.
>1. java web start
>2. ssh
>If the memory was issue then wouldn't it fail on both cases?

Not necessarily, starting by the point that are different ways to 
establish the connection, the JNLP agents could not update the 
remoting jar file (depends on your configurations), so you can be 
running different versions of remoting. I agree with Jeff looks like 
an OOM issue, review my comments 
at https://groups.google.com/g/jenkinsci-users/c/nD3s06hSUXE/m/BQKk5GSYBwAJ 
my recommendation is to fix the mem for the remoting process to 1024M 
(-Xmx1024m -Xms1024m) see if the issue disappear or change, if 
disappear, you would have to adjust the remoting process memory to the 
right one between 256M-1024M, to use 512M usually is safe a not too 
much (but depends on your agents' memory we do not know how much they 
have)


El lunes, 1 de febrero de 2021 a las 23:52:19 UTC+1, 
jigarra...@gmail.com escribió:


On Monday, January 4, 2021 at 12:37:52 PM UTC-5
jtho...@cloudbees.com wrote:

When I saw something like this in the past, it was because the
process was running out of resources. Specifically when
running SpotBugs, I got out-of-memory errors. I had to modify
the pom to allocate more memory.

I have 2 different kind of jenkins agents.
1. java web start
2. ssh
If the memory was issue then wouldn't it fail on both cases?

I do see "Agent went offline during build Connection was broker:
java.io.StreamCorruptedException: invalid stream header:".

I recommend ensuring your build runs normally on the agent
without the additional complexities of the Jenkins
environment. This might show where additional resources are
needed. If that all passes, then continue on to the additional
troubleshooting steps involving the Jenkins controller and agent.

Jeff Thompson

On 12/30/20 3:40 PM, jiga...@gmail.com wrote:

Interestingly, whenever Jenkins agent is executing
PMD/Findbugs task, it runs into " Resource temporarily
unavailable".
I have

  * verified TCP parameters
i.e. tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes
& tcp_fin_timeout ; All of them have higher values then
what cloudbees recommended at

https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected

<https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected>
  * set heap space to 2-4Gb
  * disabled ping thread from Jenkins agent by setting
"-Dhudson.remoting.Launcher.pingIntervalSec=-1"

Please let me know if there is anything else I should consider.
On Friday, December 11, 2020 at 12:11:39 PM UTC-5
kuisat...@gmail.com wrote:

The most common issue is related to disconnections
because there is no traffic between the Jenkins instance
and the agent, for that, you have to tune the TCP stack
of your OS (see

https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected

<https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected>),
or enable the keepalive option in the SSH protocol this
can be configured by setting ClientAliveInterval or
TCPKeepAlive on the SSH server (/etc/ssh/sshd_config),
also by setting ServerAliveInterval or TCPKeepAlive
options for the user connection (/etc/ssh/ssh_config or
~/.ssh/ssh_config)

https://www.freebsd.org/cgi/man.cgi?sshd_config(5
<https://www.freebsd.org/cgi/man.cgi?sshd_config(5>)
https://www.freebsd.org/cgi/man.cgi?ssh_config(5
<https://www.freebsd.org/cgi/man.cgi?ssh_config(5>)

Also, check you follow the best practices to configure
your SSH agents and enable SSH verbose log output in your
service (see

https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/TROUBLESHOOTING.md

<https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/TROUBLESHOOTING.md>)

Re: Confusion with JNLP

2021-01-29 Thread Jeff Thompson 

On 1/29/21 2:21 PM, Jigar R wrote:

Hello Jeff,

Thanks for your response. I am not well-versed with JNLPs.

My only question is that, am I using java web start?


Do you use the the "Launch" button on the controller webUI to start your 
agent?


If you don't, then you're not using Java WebStart and you have no worries.

Jeff Thompson

--
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/df76eac0-a230-0240-3993-3490c4ae4b4c%40cloudbees.com.

Re: Confusion with JNLP

2021-01-25 Thread Jeff Thompson 

On 1/25/21 1:23 PM, Jigar R wrote:

Hello Jenkins community,

I have created jenkins (v2.249.1) agent with launch method "Lauch 
agent by connecting it to the master". This prints a command on 
Jenkins UI i.e. "java -jar agent.jar -jnlpUrl  -secret ". Does 
this method use java web start / JNLP4? Is it going away?



I meant to send the following explanation to the list a few weeks back 
but apparently it didn't work out that way.



On 12/31/20 9:32 AM, jiga...@gmail.com wrote:
I have been running on JNLP for a while. Is it going to be deprecated? 
Should I prepare to move to SSH?


Unfortunately, that's a more confusing question than it should be. There 
are three things related to Jenkins agents that are named "JNLP". Only 
one of them actually has anything to do with JNLP.


First, the one that actually has anything to do with JNLP. If you use 
the "Launch" button on the controller to start your agent, that uses 
Java WebStart and JNLP is the launch protocol / mechanism. WebStart is 
going away. Or not. It has been removed from later versions of Java. 
Though, the OpenWebStart project has reimplemented these capabilities, 
which you could add onto later Java installations. However, I don't 
recommend using WebStart in production. It has no restart capabilities. 
It has become increasingly difficult to get it to work on current 
operating systems, etc.


Second, the one in Jenkins that has been renamed. When you configure an 
agent in Jenkins, there used to be an option to have a JNLP agent. This 
was renamed to "Inbound TCP agent" a while back as it has nothing to do 
with JNLP. This one is not going away.


Third, the one(s) in Jenkins that are still misnamed. Jenkins Remoting 
has had a series of network protocols named "JNLP". Currently, the only 
available one is "JNLP4-connect". This name is incorrect, as it has 
nothing to do with JNLP. The misleading name is retained for backwards 
compatibility purposes. The earlier versions of these protocols had a 
variety of problems and have gone away. The current one is not going away.


Jeff Thompson

--
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/efd7c7d9-3591-ff05-9a26-64ba1dbd10f8%40cloudbees.com.

Re: Issue with master-agent communication over ssh

2021-01-04 Thread Jeff Thompson 
When I saw something like this in the past, it was because the process 
was running out of resources. Specifically when running SpotBugs, I got 
out-of-memory errors. I had to modify the pom to allocate more memory.


I recommend ensuring your build runs normally on the agent without the 
additional complexities of the Jenkins environment. This might show 
where additional resources are needed. If that all passes, then continue 
on to the additional troubleshooting steps involving the Jenkins 
controller and agent.


Jeff Thompson

On 12/30/20 3:40 PM, jiga...@gmail.com wrote:
Interestingly, whenever Jenkins agent is executing PMD/Findbugs task, 
it runs into " Resource temporarily unavailable".

I have

  * verified TCP parameters
i.e. tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes
& tcp_fin_timeout ; All of them have higher values then what
cloudbees recommended
at 
https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected
  * set heap space to 2-4Gb
  * disabled ping thread from Jenkins agent by setting
"-Dhudson.remoting.Launcher.pingIntervalSec=-1"

Please let me know if there is anything else I should consider.
On Friday, December 11, 2020 at 12:11:39 PM UTC-5 kuisat...@gmail.com 
wrote:


The most common issue is related to disconnections because there
is no traffic between the Jenkins instance and the agent, for
that, you have to tune the TCP stack of your OS (see

https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected

<https://support.cloudbees.com/hc/en-us/articles/115001369667-dedicated-SSH-agents-formerly-slaves-get-disconnected>),
or enable the keepalive option in the SSH protocol this can be
configured by setting ClientAliveInterval or TCPKeepAlive on the
SSH server (/etc/ssh/sshd_config), also by setting
ServerAliveInterval or TCPKeepAlive options for the user
connection (/etc/ssh/ssh_config or ~/.ssh/ssh_config)

https://www.freebsd.org/cgi/man.cgi?sshd_config(5
<https://www.freebsd.org/cgi/man.cgi?sshd_config(5>)
https://www.freebsd.org/cgi/man.cgi?ssh_config(5
<https://www.freebsd.org/cgi/man.cgi?ssh_config(5>)

Also, check you follow the best practices to configure your SSH
agents and enable SSH verbose log output in your service (see

https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/TROUBLESHOOTING.md

<https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/TROUBLESHOOTING.md>)


El miércoles, 9 de diciembre de 2020 a las 17:53:19 UTC+1,
jiga...@gmail.com escribió:

Hello Jenkins community,

I have setup Jenkins agents over SSH and this agent frequently
goes offline with Resource temporarily unavailable error. I
had to configure my Jenkins agents to communicate over JNLP.
Any advise on how to fix this issue?

Jenkins v2.249.1

[12/04/20 15:23:00] [SSH] Checking java version of java
[12/04/20 15:23:01] [SSH] java -version returned 1.8.0_202.
[12/04/20 15:23:01] [SSH] Starting sftp client.
[12/04/20 15:23:03] [SSH] Remote file system root
$JENKINS_SSH_DATA does not exist. Will try to create it...
[12/04/20 15:23:03] [SSH] Copying latest remoting.jar...
[12/04/20 15:23:03] [SSH] Copied 1,521,553 bytes.
Expanded the channel window size to 4MB
[12/04/20 15:23:03] [SSH] Starting agent process: cd
"$JENKINS_SSH_DATA" && java  -jar remoting.jar -workDir
$JENKINS_SSH_DATA -jar-cache $JENKINS_SSH_DATA/remoting/jarCache
Dec 04, 2020 3:23:29 PM
org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using $JENKINS_SSH_DATA/remoting as a remoting work
directory
Dec 04, 2020 3:23:29 PM
org.jenkinsci.remoting.engine.WorkDirManager setupLogging
INFO: Both error and output logs will be printed to
$JENKINS_SSH_DATA/remoting
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 4.5
This is a Unix agent
Evacuated stdout
Agent successfully connected and online
The Agent is connected, disconnect it before to try to connect
it again.
Dec 04, 2020 3:33:58 PM org.eclipse.jgit.util.FS
discoverGitSystemConfig
WARNING: Exception caught during execution of command '[git,
config, --system, --edit]' in '$GIT_PATH/bin', return code
'128', error message 'fatal: Invalid path '$GIT_PATH/etc': No
such file or directory
'
Dec 04, 2020 3:33:58 PM
org.eclipse.jgit.util.FS$FileStoreAttributes saveToConfig
WARNING: locking
FileBasedConfig[$JENKINS_PATH/.config/jgit/config] failed
after 5 retries
Dec 04, 2020 3:

Re: agent not working since 266

2020-11-17 Thread Jeff Thompson 
I did remove that long deprecated alias in Remoting 4.6 as part of the 
Jenkins initiatives for improved terminology and diversity. I looked for 
anything still depending on it, but may have missed something. I suggest 
you see if you can determine which plugin is using the wrong term and 
file a Jira issue against it.


Jeff

On 11/17/20 8:41 AM, David Koenig wrote:

Hi,

i using the docker plugin with cloud configuration. Since Jenkins 
Version 266 i think there is a bug in Jenkins. By default, Jenkins 
tries to start the agent with the parameter "-slaveLog", but since 
version 4.6 of remote.jar just "-agentLog" is accepted as parameter 
(in 4.5 both were allowed).


Is that reproducable? When yes, what can i do to specify the 
parameters for the agent by myself (I am new to Jenkins and didn't 
find some options).


Regards

Dave
--
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/bec431fc-56be-43e9-b8ae-144660396226n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Jenkins 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0bb4e4a6-3a06-8e83-99a8-61e57ee3f78b%40cloudbees.com.

Re: Jenkins master/slave ping timeout settings: disable or increase?

2020-04-14 Thread Jeff Thompson 
Unfortunately, it's really hard to say. Possibilities include resource 
contention, such as CPU or networking, anything in the middle, such as 
load balancers, firewalls, etc., network or system configuration. I 
heard of one a while back that ended up being connected to IP table 
definition. Can't remember if that was related to docker containers or 
full VMs. I've heard that there have been some common problems in some 
VM environments, but I don't know what environments or issues 
specifically. Maybe VMotion. Maybe the network gets overloaded, 
especially between VMs. Or interactions between loads on different VMs. 
I'm not as familiar with the current state, but in the past in other 
environments I have seen more interference between VMs than expected.


It comes down to standard troubleshooting sorts of behavior. Try to 
catch the problem. Gather information about different occurrences. Try 
to isolate any commonalities. Isolate a system for reproduction.


You could try a different type of agent, such as an SSH Agent. The 
behavior might be different. I've heard recently that Microsoft's SSHD 
implementation works well.


Good luck on troubleshooting

Jeff

On 4/14/20 8:31 AM, 'monger_39' via Jenkins Users wrote:

Hi Jeff,
thx. Last week I disabled the ping-thread on master and slaves by 
setting the interval to '-1'.
Unfortunately, over the weekend, again one of the slaves (even though 
the jobs kept on running),
went into 'offline' mode.  It seems indeed that this does not solve 
the issue. Or, iow I think it means

that the disconnect was not caused by the ping-thread(s) timing out.

Which puts me to the challenge to figure out what could be this 
'external someting' that you mention
that would break the remoting. And I honestly have no idea how to 
tackle that yet.
The master, as well as the slave are Windows server VM's running 6 
executor slots each. The

tests we are running heavily use TCP communication.

Any idea how to tackle this ?

thx, M.
On Thursday, April 9, 2020, 10:53:48 PM GMT+2, Jeff Thompson 
 wrote:



On 4/7/20 11:46 PM, 'monger_39' via Jenkins Users wrote:
Hi,
in my Jenkins I am regularly facing master/slave connection drops with a
message like:

hudson.remoting.ChannelClosedException: Channel "unknown": Remote
call on JNLP4-connect connection from IP/IP:58344 failed.
The channel is closing down or has closed down.

Usually these are caused by something external to the Remoting 
communication protocol. Most often by something in the system or 
networking environment. Sometimes by some bad interaction between 
plugins that ends up impacting the channel.


Your best approach is to figure out where these disconnects originate 
and resolve the issue.




I have seen a lot of bug-reports on this. For most, a workaround is
advised by disabling the Ping-Thread through setting:
You should be cautious about changing the ping settings or disabling 
it entirely. It can cause some weird and unexpected behaviors. If you 
do change the settings, I recommend you change one thing at a time and 
evaluate the results. If it doesn't make any difference, restore it to 
its default setting.

And, is there also a slave setting for the timeoutvalue?
It depends on how you launch the agent. Remoting system properties are 
described at 
https://github.com/jenkinsci/remoting/blob/master/docs/configuration.md

(naming for all these settings does not look to be very consistent...)


Unfortunately, that's the case.

Jeff Thompson


--
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 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.

To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/ab43b555-176c-4834-e125-fb66ff612f4d%40cloudbees.com 
<https://groups.google.com/d/msgid/jenkinsci-users/ab43b555-176c-4834-e125-fb66ff612f4d%40cloudbees.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 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1263552947.287750.1586874699662%40mail.yahoo.com 
<https://groups.google.com/d/msgid/jenkinsci-users/1263552947.287750.1586874699662%40mail.yahoo.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.

Re: Jenkins master/slave ping timeout settings: disable or increase?

2020-04-09 Thread Jeff Thompson 

On 4/7/20 11:46 PM, 'monger_39' via Jenkins Users wrote:

Hi,
in my Jenkins I am regularly facing master/slave connection drops with a
message like:

hudson.remoting.ChannelClosedException: Channel "unknown": Remote
call on JNLP4-connect connection from IP/IP:58344 failed.
The channel is closing down or has closed down.


Usually these are caused by something external to the Remoting 
communication protocol. Most often by something in the system or 
networking environment. Sometimes by some bad interaction between 
plugins that ends up impacting the channel.


Your best approach is to figure out where these disconnects originate 
and resolve the issue.




I have seen a lot of bug-reports on this. For most, a workaround is
advised by disabling the Ping-Thread through setting:
You should be cautious about changing the ping settings or disabling it 
entirely. It can cause some weird and unexpected behaviors. If you do 
change the settings, I recommend you change one thing at a time and 
evaluate the results. If it doesn't make any difference, restore it to 
its default setting.

And, is there also a slave setting for the timeoutvalue?
It depends on how you launch the agent. Remoting system properties are 
described at 
https://github.com/jenkinsci/remoting/blob/master/docs/configuration.md

(naming for all these settings does not look to be very consistent...)


Unfortunately, that's the case.

Jeff Thompson

--
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/ab43b555-176c-4834-e125-fb66ff612f4d%40cloudbees.com.

Re: how to enable useful debugging info for jenkin slave running as a service on windows...

2020-03-23 Thread Jeff Thompson 
Unfortunately, it's a challenging exercise, hunting down why something 
like this is occurring. Typically, it has something to do with local 
system, network, environment, or Jenkins configuration. It may have 
something to do with how the agent is configured.


The best documentation on agent (Remoting) logging I can remember is at 
https://github.com/jenkinsci/remoting/blob/master/docs/logging.md . It 
can be a little hard to understand and configure but I've successfully 
used it before to configure logging in the detail and areas I needed.


It sounds like you will need to examine what is happening on the master 
and the agent during this time. Your issue sounds pretty weird. In my 
experience, agent-initiated connections will keep retrying, so a timeout 
is only a temporary delay.


Jeff Thompson

On 3/21/20 12:53 PM, JP wrote:
I have a jenkins agent / slave running as a windows service,  it is 
observed that once in a while after reboot of the machine, jenkin 
slave service don't come up. I have looked at eventlog and it says 
jenkin service is timing out. I want to debug why timeouts are happening.


Can someone point to me a link which will allow me to enable useful 
logging / debugging info so that next time I can see more info than 
just timeout.


Thanks
JP
--
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 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9513af77-8a40-42cc-9f6d-b183bf63af8f%40googlegroups.com 
<https://groups.google.com/d/msgid/jenkinsci-users/9513af77-8a40-42cc-9f6d-b183bf63af8f%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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5b195930-9f67-4ac0-991d-505108ec22ac%40cloudbees.com.

Re: Slave cannot connect to Jenkins via tcpSlaveAgentListener

2020-02-17 Thread Jeff Thompson 
Did you check the same settings as were mentioned earlier in this 
discussion?


Otherwise, you would need to provide additional details such as 
versions, changes, etc., for anyone to have a chance of helping you.


Jeff

On 2/17/20 7:47 AM, Sat wrote:

I am facing the same issue today.
For Jenkins agent : TCP port for inbound agent. - fixed 8020 port
I used the same like below:

docker run jenkinsci/jnlp-slave -url http://jenkins-master.test:8020 
-workDir=/home/jenkins/agent 
pkRUdAH07VFHhSWb9RAQCRFdWP7j0eIx9jfhRhj5jenkins-agent



but still seeing issue:


Feb 17, 2020 2:45:58 PM hudson.remoting.jnlp.Main$CuiListener error

SEVERE: http://jenkins-master.test:8020/tcpSlaveAgentListener/ is 
invalid: 404 Not Found


java.io.IOException: 
http://jenkins-master.test:8020/tcpSlaveAgentListener/ is invalid: 404 
Not Found




Can you let me know how to fix this, thanks.


On Wednesday, April 11, 2018 at 4:12:23 PM UTC+1, john.peterson wrote:

Legacy systems (3+ years) running 2.111

http://jenkins_1:8080/tcpSlaveAgentListener
 takes us to a page
that simply says Jenkins.  This system works.
http://jenkins_2:8080/tcpSlaveAgentListener
 takes us to a page
that simply says Jenkins.  This system works.
http://jenkins_3:8080/tcpSlaveAgentListener
 takes us to a page
that simply says Jenkins.  This system works.

New system running 2.107
http://jenkins_4:8080/tcpSlaveAgentListener
 says Page Not Found

This is the first time I've had trouble getting a slave to connect.

I've checked to make sure all of the plugins are there and the
same as on the other systems.

My VM is a clone from System2.  I updated my "slave launch" batch
file from

javaws
http://jenkins_2:8080/computer/VM01_Win7x64/slave-agent.jnlp

to
javaws
http://jenkins_4:8080/computer/VM01_Win7x64/slave-agent.jnlp


When I run that command on the slave I get:

Apr 11, 2018 10:13:33 AM hudson.remoting.jnlp.GuiListener$2 run
SEVERE: http://jenkins_4:8080/tcpSlaveAgentListener/
 is invalid: 404 Not
Found
java.io.IOException: http://jenkins_4:8080/tcpSlaveAgentListener/
 is invalid: 404 Not
Found
at

org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:204)
at hudson.remoting.Engine.innerRun(Engine.java:518)
at hudson.remoting.Engine.run(Engine.java:469)

I am the one that set up all 4 systems.  Doing side-by-side
comparisons, everything seems the same.  I have entered firewall
exceptions (or turned off).  I have the same JAVA on all.  I have
added exceptions in JAVA as appropriate.

The only diagnostics I can find is from CloudBees and only
semi-applies to what I am trying to diagnose.

--
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/c8dde335-05be-4c94-a365-beea095be132%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Jenkins 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9c2154a9-b49d-4423-8358-baa19fb8469d%40cloudbees.com.

PROPOSAL: Remove network discovery services

2020-01-30 Thread Jeff Thompson 

Hi,

Dating back many years, Jenkins has supported two network discovery 
services (UDP multicast/broadcast and DNS multicast). When this was 
first implemented this may have been a reasonable way to provide useful 
lookup services. With modern Jenkins capabilities, networks, and 
security considerations, this is no longer a good mechanism. There are 
now other ways to better accomplish pretty much everything this does.


With Jenkins Security Advisory 2020-01-29 ( 
https://jenkins.io/security/advisory/2020-01-29/ ) these services were 
disabled by default because 
of<https://issues.jenkins-ci.org/browse/SECURITY-1641> SECURITY-1641 / 
CVE-2020-2100.


The tests for these services have long been problematic because of 
various system issues. They have never passed for me on my development 
machine and others have reported the same. The issues are exacerbated 
with Java 11.


We propose to remove these network discovery services. See 
https://issues.jenkins-ci.org/browse/JENKINS-60913 and 
https://github.com/jenkinsci/jenkins/pull/4460 .


Please respond with any agreement or if you have any important 
implementations that require these capabilities. Perhaps if this is 
still needed, the capabilities could be pulled out of core into a 
plugin, maintained by someone that uses it.


Jeff Thompson

--
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/781cfc3a-3cf6-bfd1-c9ec-759d0db42ecb%40cloudbees.com.

Re: JNLP agent and proxy

2020-01-23 Thread Jeff Thompson 
On the agent (node) configuration page when configuring to "Launch agent 
by connecting it to the master" there is an Advanced button. If you 
click that, one option that becomes visible is "Tunnel connection 
through". This *might* work for you. Read the inline help and try it to 
see if it meets your needs.


Another thing that might work for you soon is the the upcoming WebSocket 
connection mechanism ( 
https://github.com/jenkinsci/jep/blob/master/jep/222/README.adoc ). 
Looks like it's currently targeted towards the next weekly.


Jeff

On 1/23/20 5:59 AM, Simon Richter wrote:

Hi,

I'd expect this to be somewhat obvious, but it doesn't seem to be: I have a
JNLP agent on a Windows VM that should talk to the Jenkins master on
another VM in the same network. The Jenkins master has a standard nginx
proxy before it to allow external requests to come in.

The agent now connects to the proxy, requests connection information,
receives the port number and connects to the proxy's IP address with the
port number it received from the master.

Obviously this fails because the proxy does not forward the internal agent
ports (these are not supposed to be externally visible).

Is there a way to let the Jenkins master hand out not only the port number
but also the correct IP address to agents (after all, being run behind a
proxy seems to be a very common use case to the extent that the public URL
is configurable)?

Simon



--
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/72c7c6fb-3eda-b508-748d-5b110a8bd722%40cloudbees.com.

Re: (Trivial) Startup Message Awkwardness

2020-01-02 Thread Jeff Thompson 
As another native English speaker (USA) I do find the phrasing a little 
odd. But I don't find that the proposals make much improvement. The 
phrase "getting ready to work" is kind of awkward and probably wordier 
than necessary.


Maybe there's a way to re-think it, turn it around or something. Maybe 
something as simple as "Jenkins is starting". I'm not sure that the 
"Please wait while" really provides value. Other possible word choices 
instead of "starting" include "loading" and "launching" but I think 
"starting" is simplest and works best.


Jeff Thompson

On 12/31/19 7:25 PM, Richard Bywater wrote:
From my native (New Zealand) English speaking perspective the way its 
worded currently seems to sound right and the alternate (gets) version 
seems not quite right - the wonders of English :)


Personally, using 
https://conjugator.reverso.net/conjugation-english-verb-get.html and 
https://www.englishgrammar.org/simple-present-present-continuous-tense-differences/ as 
a reference, I think that "is getting" is probably the more correct 
term for its current use.


Having said that though, I'm not overly fussed with which is being used :)

Richard.

On Wed, 1 Jan 2020 at 11:32, Jamie Jackson <mailto:jamieja...@gmail.com>> wrote:


Warning: Opinions Follow! :)

I wouldn't bring this up if the message were anywhere else but I
find myself staring at the Jenkins startup screen more than I
would like. It is also probably the first thing any new Jenkins
user sees.

Currently, the message <#m_-7620564545364750833_L54]> reads:

Please wait while Jenkins is getting ready to work

It's hard to explain why, but from my perspective as a native
(American) English speaker, that strikes me as incorrect at worst,
or slightly awkward at best. The word, "while," makes the
present-continuous form, "is getting," seem strange.

This works better (present-simple form):

Please wait while Jenkins gets ready to work

The following may be even better (albeit only slightly) than the
above, since it's less redundant. (Note: I care less about this
change.)

Please wait while Jenkins gets ready

I'm interested to know what others think.

Thanks,
Jamie


-- 
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
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-users/CA%2BonWPcX5JkD%2BOoJHTaeko81Ode0uL5oN_EGhphxCODi_SoMTg%40mail.gmail.com

<https://groups.google.com/d/msgid/jenkinsci-users/CA%2BonWPcX5JkD%2BOoJHTaeko81Ode0uL5oN_EGhphxCODi_SoMTg%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 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAAy0hwcBN5F6dHfS8ZR7WXjTYBrxcPv03ZzUFsUa3VoexLGiHw%40mail.gmail.com 
<https://groups.google.com/d/msgid/jenkinsci-users/CAAy0hwcBN5F6dHfS8ZR7WXjTYBrxcPv03ZzUFsUa3VoexLGiHw%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/2ad9f1a4-f631-8016-8234-f3109eb37fab%40cloudbees.com.

Re: Remove old agent protocols?

2019-12-10 Thread Jeff Thompson 
I haven't seen any other responses here than this one from Slide so I'm 
going to assume lack of response means there are no objections. I also 
haven't received any concerns about use case or configuration, so I'm 
not planning on tying this work as a dependency with Jesse's work with 
WebSockets. Both efforts can proceed independently.


I'm still working on a timeline for when these changes will go in. 
Currently I'm leaning towards waiting a little before making this change.


Jeff

On 12/3/19 11:58 AM, Slide wrote:

I'm a big +1 on this.

On Tue, Dec 3, 2019 at 11:05 AM Jeff Thompson <mailto:jthomp...@cloudbees.com>> wrote:


For historical reasons, Jenkins still ships with old, deprecated
protocols, JNLP1-connect, JNLP2-connect, and JNLP3-connect. These all
have fundamental issues and known bugs. They were all superseded
by the
JNLP4-connect protocol released in Jenkins 2.27 over three years ago
(October 2016). They have all been deprecated and unsupported since
Jenkins 2.75 over two years ago. Since then there have been UI
messages
and an administrative monitor strongly discouraging their use.
(See more
information about the protocols at
https://github.com/jenkinsci/remoting/blob/master/docs/protocols.md )

As part of cleaning up technical debt I propose to remove these
protocols. Does anyone have any concerns? If you do, please share use
case or configuration details.

There is a proposal to add WebSockets as another agent connection
mechanism. (See

https://github.com/jenkinsci/jep/blob/2c137aa7884fd6360f133964422fd997351a7ebb/jep//README.adoc

) This may cover use cases where someone still uses the older
protocols.
We could make the removal of the old protocols dependent on
completion
of WebSocket support.

Jeff Thompson


-- 
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
<mailto:jenkinsci-users%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-users/0d38edaf-2cc2-d390-2332-aaa3105d9972%40cloudbees.com.



--
Website: http://earl-of-code.com
--
You received this message because you are subscribed to the Google 
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-users+unsubscr...@googlegroups.com 
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVeptB-Vo5fnft6d08ar-X20BHxGByN5AoCnz%2BO%2B-tcr4A%40mail.gmail.com 
<https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVeptB-Vo5fnft6d08ar-X20BHxGByN5AoCnz%2BO%2B-tcr4A%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/00e706c8-923b-bf13-cf57-732dba27ad91%40cloudbees.com.

Remove old agent protocols?

2019-12-03 Thread Jeff Thompson 
For historical reasons, Jenkins still ships with old, deprecated 
protocols, JNLP1-connect, JNLP2-connect, and JNLP3-connect. These all 
have fundamental issues and known bugs. They were all superseded by the 
JNLP4-connect protocol released in Jenkins 2.27 over three years ago 
(October 2016). They have all been deprecated and unsupported since 
Jenkins 2.75 over two years ago. Since then there have been UI messages 
and an administrative monitor strongly discouraging their use. (See more 
information about the protocols at 
https://github.com/jenkinsci/remoting/blob/master/docs/protocols.md )


As part of cleaning up technical debt I propose to remove these 
protocols. Does anyone have any concerns? If you do, please share use 
case or configuration details.


There is a proposal to add WebSockets as another agent connection 
mechanism. (See 
https://github.com/jenkinsci/jep/blob/2c137aa7884fd6360f133964422fd997351a7ebb/jep//README.adoc 
) This may cover use cases where someone still uses the older protocols. 
We could make the removal of the old protocols dependent on completion 
of WebSocket support.


Jeff Thompson


--
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/0d38edaf-2cc2-d390-2332-aaa3105d9972%40cloudbees.com.

Re: Error upgrading from 2.121.3 to 2.138.4... jenkins bricked

2019-03-25 Thread Jeff Thompson 
I’m glad you were able to figure something out and move forward. It does appear 
to be the same issue in those reports in those other projects. In the 
elasticsearch one they identified it as a bug in the interaction between aufs 
and the JDK. As we suspected earlier it seems to involve a filesystem issue and 
not be related specifically to the userid migration. I wonder if the bug exists 
in more current versions of Java.

Jeff Thompson

> On Mar 22, 2019, at 6:45 PM, Marc Esher  wrote:
> 
> Hi all, thanks for the advice. Apologies for not posting back to the group 
> earlier with my resolution.
> 
> It turns out, I am nearly certain this is a problem with running the upgrade 
> on Docker. This is docker-for-mac.
> 
> I found several other instances in non-Jenkins software of Java errorring due 
> to NIO UnixCopyFile.move(), on docker. 
> https://github.com/elastic/elasticsearch/issues/24231 and  
> https://github.com/tuub/kitodo-mediaserver/issues/108 are examples.
> 
> When I ran the upgrade on one of our jenkins test servers -- these are ec2 
> linux instances, no docker in play -- from 2.121.3 to the latest LTS version, 
> the upgrade and User migration happened as expected.
> 
> Best,
> 
> Marc
> 
> 
> -- 
> 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 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/f25f759c-5a90-4040-9490-3df2b591e96f%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/f25f759c-5a90-4040-9490-3df2b591e96f%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/D4BDACA4-9375-49BA-92DB-1E8F60260AF8%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logins (CAS plugin) not working after upgrading to 2.160 (security)

2019-01-17 Thread Jeff Thompson 
You could try disabling the new, more secure capabilities by setting the 
DISABLE_USER_SEED system property to true. That might allow you to get 2.160 
working for you, in a less secure fashion.

There is no indication that logins are generally broken, but you’ve apparently 
hit some unusual configuration.

Please file a report on the Jenkins issue tracker, probably against core and  
cas-plugin. Hopefully you can provide good isolation and reproduction 
information.

Jeff

> On Jan 17, 2019, at 8:32 AM, matthew.web...@diamond.ac.uk 
>  wrote:
> 
> I just upgraded Jenkins from 2.159 to 2.160, and then found that I could not 
> log on to the web interface.
> 
> Clicking "login" prompted me for my credentials as expected, and then 
> returned me to the Jenkins web page, but not logged in.
> Clearing cookies and cache, and using a different browser, did not fix the 
> problem.
> Our Jenkins is using the CAS plugin for user authentication.
> 
> I _was_ able to successfully authenticate to Jenkins using the 
> jenkins-cli.jar with an API token that I have previously set up.
> 
> Has anyone else seen this? I presume that if logons were generally broken in 
> that release, someone would have reported it by now.
> 
> I immediately rolled back to 2.159, and logon then started working.
> 
> Matthew
> 
> 
> -- 
> This e-mail and any attachments may contain confidential, copyright and or 
> privileged material, and are for the use of the intended addressee only. If 
> you are not the intended addressee or an authorised recipient of the 
> addressee please notify us of receipt by returning the e-mail and do not use, 
> copy, retain, distribute or disclose the information in or attached to the 
> e-mail.
> Any opinions expressed within this e-mail are those of the individual and not 
> necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
> attachments are free from viruses and we cannot accept liability for any 
> damage which you may sustain as a result of software viruses which may be 
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and 
> Wales with its registered office at Diamond House, Harwell Science and 
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> 
> -- 
> 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/47b4e75b07734e298b5de5d91a07b124%40Diamond.ac.uk.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5C65A5CA-5357-41AA-96BB-BA6A76289E9C%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: NoRouteToHostException when trying to connect to a Jenkins URL API from a pipeline

2019-01-09 Thread Jeff Thompson 
Usually it’s best to verify connectivity and behavior from outside Jenkins but 
on the same machines as the first troubleshooting step. If those are fine, then 
start troubleshooting from inside. Break complex jobs or operations down into 
small steps to speed attempts and to isolate issues.

Good luck on troubleshooting your system configuration.

Jeff Thompson

> On Jan 9, 2019, at 6:37 AM, SysInt  wrote:
> 
> Does somebody need further piece of information to help me figure this out ?
> 
> -- 
> 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 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/86763e5a-74e7-4e04-964b-dcf1ebe12719%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/86763e5a-74e7-4e04-964b-dcf1ebe12719%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Re: Standard way to configure Linux Slave

2018-12-05 Thread Jeff Thompson 
For situations where it is reasonable, I agree with Slide’s recommendation: #1 
Launch agents via ssh

It’s a good implementation, fairly straightforward,  and I think it leads to 
better reliability and fewer broken connections. I don’t have any data on that, 
though, so I’d also love to hear from others with experience using the 
different mechanisms.

Jeff Thompson

> On Dec 4, 2018, at 1:48 PM, Slide  wrote:
> 
> FYI, even though the term is used in some places in the docs and code 
> (because it's hard to change everything), "agent" is the requested term 
> instead of "slave". That being said, I prefer the "Launch agents via ssh", 
> I've never had a problem with reconnection after a reboot of the agent 
> computer.
> 
> On Tue, Dec 4, 2018 at 1:44 PM  <mailto:gotviser...@gmail.com>> wrote:
> Any inputs on this please?
> 
> On Tuesday, December 4, 2018 at 9:03:37 AM UTC-5, gotvi...@gmail.com 
> <mailto:gotvi...@gmail.com> wrote:
> What is the best or standard way to configure a Linux slave to the Master?  
> These are the options that comes while we try to do the configuration
> 
> 1. Launch agent agents via ssh
> 2. Launch agent via Java Web Start
> 3. Launch agent via execution of command on master
> 4. Let Jenkins control this Windows slave as a Windows machine
> 
> Our requirement is if the Slave VM reboots, we want the Jenkins service to 
> start automatically and the slave to connect to master without any 
> interruption.  Please suggest.
> 
> -- 
> 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 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/415b5e85-89ca-4461-8bd9-b8450aacfeeb%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/415b5e85-89ca-4461-8bd9-b8450aacfeeb%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> Website: http://earl-of-code.com <http://earl-of-code.com/>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVf3jygh7vmqSrBbf079FmKnCOFgO7H1W3xR%3DeLoSE4bnw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVf3jygh7vmqSrBbf079FmKnCOFgO7H1W3xR%3DeLoSE4bnw%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Re: Increase Java heap size of Windows Slave

2018-11-27 Thread Jeff Thompson 
I suggest you try configuring it at the configuration page for the node in 
Jenkins. Look under the Advanced button for JVM options.

Jeff Thompson

> On Nov 27, 2018, at 7:32 AM, gotviser...@gmail.com wrote:
> 
> We have a Windows 2016 Slave.  The slave gets disconnected due to heap memory 
> maxing out.  How to increase the heap size to tackle this issue?  This is a 
> bit urgent please.
> 
> -- 
> 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 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/c1393ce1-03c2-43f4-b7df-58a14bb80ebc%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/c1393ce1-03c2-43f4-b7df-58a14bb80ebc%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/978DF48F-1E34-49DA-8908-FF099846D9BA%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revoke user tokens warning

2018-09-24 Thread Jeff Thompson 
Yes, the API tokens are typically used by processes to connect to Jenkins APIs 
and perform scheduled or responsive operations. These are usually separate from 
regular users who login using the login page. The prior behavior involved 
automatic creation of API tokens for users, whether there was any need for them 
or not. Better practice is to only create them as needed.

If you haven’t set up any processes or agents to connect via API tokens, then 
you should be safe to just revoke all legacy ones. If you have some API tokens 
in use, then you should re-configure them for the new-style tokens as Matthew 
mentions. If you revoke all tokens and then discover some processes or agents 
can no longer connect and authenticate, then you’ll need to perform that 
re-configuration after the fact.

Jeff Thompson

> On Sep 21, 2018, at 10:56 AM, matthew.web...@diamond.ac.uk wrote:
> 
> You might want to wait for someone else to confirm this, but for us at least:
> You’re correct, that the front page login is unrelated to the tokens.
> We revoked all legacy tokens without problems. We had a couple of 
> infrastructure accounts using tokens, which we knew about (and set up 
> new-style tokens for them first).
> Matthew
>  
> From: jenkinsci-users@googlegroups.com 
> <mailto:jenkinsci-users@googlegroups.com>  <mailto:jenkinsci-users@googlegroups.com>> On Behalf Of Jonathan Bergh
> Sent: 21 September 2018 10:15
> To: Jenkins Users  <mailto:jenkinsci-users@googlegroups.com>>
> Subject: Revoke user tokens warning
>  
> Hi all,
>  
> thanks in advance for any assistance.
>  
> we have recently received the Jenkins security warning about users using a 
> Legacy token. This is a production installation so before i hit the "revoke" 
> button for all users, i just wanted to check what this actually does?
>  
> all our users log in via front page using user credentials (username / 
> password). I dont think anyone is using a token for anything?
>  
> is it safe to just revoke all legacy tokens?
>  
> thanks in advance
> regards
> jb
> -- 
> 
>  
> -- 
> 
> This e-mail and any attachments may contain confidential, copyright and or 
> privileged material, and are for the use of the intended addressee only. If 
> you are not the intended addressee or an authorised recipient of the 
> addressee please notify us of receipt by returning the e-mail and do not use, 
> copy, retain, distribute or disclose the information in or attached to the 
> e-mail.
> Any opinions expressed within this e-mail are those of the individual and not 
> necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
> attachments are free from viruses and we cannot accept liability for any 
> damage which you may sustain as a result of software viruses which may be 
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and 
> Wales with its registered office at Diamond House, Harwell Science and 
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>  
> 
> 
> -- 
> 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 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/1c51b80c52914fde9f6c06930da64e5c%40Diamond.ac.uk
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/1c51b80c52914fde9f6c06930da64e5c%40Diamond.ac.uk?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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