I tried to connect slave to jenkins master through java web start but my efforts failed in the end.
I executed java -jar (jar file) (url) to connect and got the following errors.
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.<init>(Socket.java:425)
at java.net.Socket.<init>(Socket.java:208)
at hudson.remoting.Engine.connect(Engine.java:321)
at hudson.remoting.Engine.run(Engine.java:210)
Please help. Both Master and Slave use Ubuntu Linux.
First of all, SO is not bug tracker for Jenkins project nor developers.
The Jenkins JIRA is located here: https://issues.jenkins-ci.org/secure/Dashboard.jspa
Secondly, in the wiki pages:
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
contains pretty sufficient information that might guide you to fix. Probobly not permanent, but at least temporary.
For your comfort, here is the first link that fits the stack trace:
Check that the JNLP port is opened if you are using a firewall on your server. You can configure its value in Jenkins configuration. By default it is set to use a random port.
Cheers and good luck!
Related
I want to add a new slave to Jenkins. When I followed the Jenkins UI, it gives me the command below
java -jar agent.jar -jnlpUrl http://<jenkins_url>/computer/<slave_name>/slave-agent.jnlp -secret 4b59708a20e155c8ccb39f1fb046be09f72c712ed839401195c475d5fdb2b0e5
When I tried to execute that command, its output like below:
Exception in thread "main" java.lang.IllegalArgumentException: IV buffer too short for given offset/length combination
at javax.crypto.spec.IvParameterSpec.<init>(IvParameterSpec.java:80)
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:515)
at hudson.remoting.Launcher.run(Launcher.java:325)
at hudson.remoting.Launcher.main(Launcher.java:283)
Could you please help me about this error? Any help will be appreciated. Thanks in advance.
Best Regards.
I reviewed the setting of the IV length in Jenkins code as well as in the Jenkins agents code (remoting) and it seems to be consistently set to 16 bytes everywhere.
However, by running curl to GET the slave-agent.jnlp URL ($JENKINS_URL/computer/$node_name/slave-agent.jnlp), I found that the http:// URL which I thought I should be using returns just "302 Found" with the "location" header set to the same URL but with https://. curling that, I saw messages about missing permissions in Jenkins (to Read, then to Connect agents). Adding those for anonymous users (at $JENKINS_URL/configureSecurity, using matrix-based security) resolved that issue for me.
Or rather, it turned it into another issue, which was "Connection refused". It took me another while to figure out that -- for our Jenkins master running in a container -- in the Global Security configuration, "TCP port for inbound agents" must be set to the container-internal port, while in the node configuration, "Tunnel connection through" has to be set to the external port.
I hope my debugging exercise will be at least partially applicable in your context, too.
Can't set up an agent on the same machine as the master node in Jenkins. The Jenkins instance is on localhost as is the agent. The main problem I'm getting is:
at
yah de yah.....
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.UnknownHostException: http://192.168.0.1:8080/
Here's what I tried:
1 - Configure agent launched via ssh, Host is http://192.168.0.1:8080/ (also tried 127.0.0.1 and localhost here but the URL in Jenkins config is as shown) with Jenkins admin password. Used 'Known host file Verification Strategy' Advanced setting uses port 22. Tried Jenkins Global Security settings with fixed port 22, 50000 and random port setting.
Also toggled Windows OpenSSH for client and server with the above combinations.
Configure agent by Connecting it to the master; other options as default. Got 'Agent is offline because Jenkins failed to launch the agent process' and got the 'Launch' button for webstart. Clicked on that; nothing happened (that I saw) but the file did appear in my downloads folder.
Copied the file to another directory, opened a command window in that directory and entered the 'headless' command shown in the window with the webstart button. Got:
Error: Unable to access jarfile agent.jar
Seems no matter what I try I can't connect to http://192.168.0.1:8080/
Is this some sort of tunneling issue where I need to expose localhost even though I'm not going over the Internet? I needed to do that to get my localhost Jenkins install to talk to GitHub.
Been reading numerous articles,watched videos - seems most of the material out there is for a 'real' use of creating agents on separate machines.
Any advice would be MOST appreciated.
I am trying to setup a Jenkins server using one of the Chef cookbooks from the supermarket. Unfortunately it is failing with the below error. The plugin recipe requires for the Global security configuration - "Enable CLI with remoting" to be enabled. Can anybody help me to enable it from a Chef recipe so that
java -jar jenkins-cli.jar -s http://localhost:8080 -remoting
installs the plugin.
Thanks
Here is the error log
java.io.IOException: No X-Jenkins-CLI2-Port among [X-Jenkins, null, Server, X-Content-Type-Options, X-You-Are-In-Group-Disabled, X-Hudson, X-Permission-Implied-By, Date, X-Jenkins-Session, X-You-Are-Authenticated-As, X-Required-Permission, Set-Cookie, Expires, Content-Length, Content-Type]
at hudson.cli.CLI.getCliTcpPort(CLI.java:311)
at hudson.cli.CLI.<init>(CLI.java:137)
at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:82)
at hudson.cli.CLI._main(CLI.java:615)
at hudson.cli.CLI.main(CLI.java:426)
Suppressed: java.io.IOException: Server returned HTTP response code: 403 for URL: http://localhost:8080/cli?remoting=true
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at hudson.cli.FullDuplexHttpStream.<init>(FullDuplexHttpStream.java:101)
at hudson.cli.CLI.connectViaHttp(CLI.java:163)
at hudson.cli.CLI.<init>(CLI.java:141)
As per the official documentation, remoting option is disabled by default. you can enable it by going to Configure Global Security. I don't think by programatically we can't enable it. For more details use this official link. Remoting Connection Mode | official Jenkins
This is the solution they are providing for your problem. Hope this helps.
Go to Manage Jenkins > Configure Global Security and choose "Fixed" or "Random" under TCP port for JNLP agents.
You can enable the remoting option by writing a bit of Groovy that gets run when Jenkins starts, but a better option is to configure the proper authentication and use the ssh or http methods.
https://github.com/chef-cookbooks/jenkins#authentication
See also: https://stackoverflow.com/a/51106793/3794873
I have setup a master on Ubuntu machine and want to create a salve on Windows 10. While launching the agent I am facing following issue. Can someone please help.
just before slave javed_pc gets launched ...
executing pre-launch scripts ...
[2017-04-21 10:26:54] [windows-slaves] Connecting to 172.26.152.23
Checking if Java exists
java -version returned 1.8.0.
[2017-04-21 10:26:56] [windows-slaves] Copying jenkins-slave.xml
[2017-04-21 10:26:56] [windows-slaves] Copying slave.jar
[2017-04-21 10:26:56] [windows-slaves] Starting the service
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
org.jinterop.dcom.common.JIException: Service Logon Failure
at org.jvnet.hudson.wmi.Win32Service$Implementation.start(Win32Service.java:149)
Caused: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor206.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.kohsuke.jinterop.JInteropInvocationHandler.invoke(JInteropInvocationHandler.java:140)
Caused: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy64.start(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:342)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:262)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Using the JENKINS Windows Slaves Plugin, check if one of the reason listed in "Windows slaves fail to start via DCOM" would apply in your case.
It lists a wide variety of reasons, from the Windows account used, to network, registry, security reasons.
Make sure you don't have a proxy issue, where Jenkins would try and use said proxy to access a machine (Windows here) on your LAN: the environment variable no_proxy should be used to exclude your local domain.
The OP Javed Ahmed reports having solve it with:
In 'Configure Global security' settings, when you check 'Enable Security' option, then it allows you to connect via java web start.
Otherwise It was not showing the the option to connect through java web start and connecting via windows service is a pain.
I have a really strange problem connecting to a Neo4j instance running in a docker instance. But first things first, here is my set up:
Everything runs on a MacOS. I use boot2docker, so the actual Docker instances run in a VirtualBox. I am able to reproduce this issue with Neo4j 2.1.5 and with Neo4j 2.2.0-M04.
Additionally, I installed Neo4j locally via homebrew and it is version 2.1.7. It is installed to have a neo4j-shell available.
The docker instances are accessible from the outside via 192.168.59.104. The docker instance itself has a 172.17.0.x IP address.
The problem:
I try to connect with neo4j-shell like this: neo4j-shell -v -host 192.168.59.104 -port 1337 -name shell. After a couple of minutes, it fails with:
ERROR (-v for expanded information):
Connection refused
java.rmi.ConnectException: Connection refused to host: 172.17.0.2; nested exception is:
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
at com.sun.proxy.$Proxy1.welcome(Unknown Source)
at org.neo4j.shell.impl.AbstractClient.sayHi(AbstractClient.java:215)
at org.neo4j.shell.impl.RemoteClient.findRemoteServer(RemoteClient.java:63)
at org.neo4j.shell.impl.RemoteClient.<init>(RemoteClient.java:55)
at org.neo4j.shell.impl.RemoteClient.<init>(RemoteClient.java:43)
at org.neo4j.shell.ShellLobby.newClient(ShellLobby.java:165)
at org.neo4j.shell.StartClient.startRemote(StartClient.java:297)
at org.neo4j.shell.StartClient.start(StartClient.java:175)
at org.neo4j.shell.StartClient.main(StartClient.java:120)
Caused by: java.net.ConnectException: Operation timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.<init>(Socket.java:434)
at java.net.Socket.<init>(Socket.java:211)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 14 more
The interesting part is, that it fails by trying to connect 172.17.0.2 instead of the provided IP address.
What I did so far:
Double check neo4j.properties are correct
remote_shell_host=0.0.0.0 is set
remote_shell_port=1337 is set
check the ports are exposed properly with docker ps:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
099cfd1b8018 daneroo/neo4j:latest "/bin/bash -c /launc 3 minutes ago Up 3 minutes 0.0.0.0:1337->1337/tcp, 0.0.0.0:7474->7474/tcp neo4j
Some Google and SO searches, but without any success.
Different neo4j versions and docker images
Basic connection checks with telnet 192.168.59.104 1337. This is successful.
Catch up with Mark Needham at todays neo4j meetup
So, do I miss something? In theory this should happen every time you can access the Neo4j through another IP address than the Neo4j instance can see (e.g. if you run a Neo4j instance at home on a machine with the IP 192.168.x.y and you try to access it via your public IP you have at this time).
Where is the client, running outside the Neo4j environment, getting the internal IP address from? Is there a way to work around this issue?
I think it might be related to the RMI protocol that the shell uses to communicate with Neo4j.
Afaik RMI also uses some additional ports and it might redirect the initial request. there is a system property in Java that you might want to try to set in neo4j-wrapper.conf: -Djava.rmi.server.hostname=192.168.59.104
see:
http://courses.cs.washington.edu/courses/cse341/98au/java/jdk1.2beta4/docs/guide/rmi/rmiNetworkingFAQ.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/javarmiproperties.html