I am running Jenkins 2.89.4 on the official Docker LTS image in an Amazon Linux EC2 instance. I am using the GitHub webhook and when I test it I get this on the docker logs;
Feb 20, 2018 4:48:23 PM io.relution.jenkins.awssqs.logging.Log write
INFO: 000380 Create new SQSTriggerQueue(8d894fcf-becd-449c-a65b-2a404c57b7bc, , )
Feb 20, 2018 4:48:23 PM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet
INFO: Queue of changeset A hudson.scm.SubversionSCM.xml
A jenkins.model.ArtifactManagerConfiguration.xml
A hudson.tasks.Shell.xml
A scm-sync-configuration.xml
A hudson.tasks.Mailer.xml
A config.xml
A jenkins.plugins.awslogspublisher.AWSLogsConfig.xml
A hudson.plugins.jira.JiraProjectProperty.xml
A hudson.plugins.git.GitSCM.xml
A jenkins.metrics.api.MetricsAccessKey.xml
A hudson.plugins.timestamper.TimestamperConfig.xml
A jenkins.model.JenkinsLocationConfiguration.xml
A hudson.plugins.build_timeout.operations.BuildStepOperation.xml
A hudson.triggers.SCMTrigger.xml
A hudson.plugins.emailext.ExtendedEmailPublisher.xml
A hudson.maven.MavenModuleSet.xml
aborted (scm manipulator not settled !)
Feb 20, 2018 4:49:03 PM com.squareup.okhttp.internal.Platform$JdkWithJettyBootPlatform getSelectedProtocol
INFO: ALPN callback dropped: SPDY and HTTP/2 are disabled. Is alpn-boot on the boot class path?
Related
I have an Ubuntu VM 20.04LTS where I installed tsunami-security-scanner and also run the docker example with a vulnerable image.
The example works as expected founding a vulnerability: JUPYTER_NOTEBOOK_EXPOSED_UI
When I tried with a live target I have, I got the following JSON otuput:
{
"scanStatus": "PARTIALLY_SUCCEEDED",
"scanStartTimestamp": "2020-07-09T03:35:32.611Z",
"scanDuration": "45.315s",
"fullDetectionReports": {
},
"statusMessage": "Failed plugins:\n/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/NcrackWeakCredentialDetectorPlugin/0.1\n/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/WordPressInstallPageDetector/0.1"
}
NcrackWeakCredentialDetectorPlugin and WordPressInstallPageDetector have failed but don't know why.
This is the console output:
(...)
Jul 10, 2020 1:00:33 AM com.google.tsunami.workflow.DefaultScanningWorkflow fingerprintNetworkServices
INFO: Port scanning phase done, moving to service fingerprinting phase with '0' fingerprinter(s) selected.
Jul 10, 2020 1:00:34 AM com.google.tsunami.workflow.DefaultScanningWorkflow detectVulnerabilities
INFO: Service fingerprinting phase done, moving to vuln detection phase.
Jul 10, 2020 1:00:34 AM com.google.tsunami.plugins.detectors.credentials.ncrack.NcrackWeakCredentialDetector detect
INFO: Starting weak credential detection using ncrack.
Jul 10, 2020 1:00:34 AM com.google.tsunami.plugins.detectors.exposedui.hadoop.yarn.YarnExposedManagerApiDetector detect
INFO: Starting unauthenticated Apache Yarn ResourceManager API detection
Jul 10, 2020 1:00:34 AM com.google.tsunami.plugins.detectors.exposedui.jenkins.JenkinsExposedUiDetector detect
INFO: Starting exposed ui detection for Jenkins
Jul 10, 2020 1:00:34 AM com.google.tsunami.plugins.detectors.exposedui.jupyter.JupyterExposedUiDetector detect
INFO: Starting exposed ui detection for Jupyter Notebook
Jul 10, 2020 1:00:34 AM com.google.tsunami.plugins.detectors.exposedui.wordpress.WordPressInstallPageDetector detect
INFO: Starting unfinished install page detection for WordPress.
Jul 10, 2020 1:00:34 AM com.google.tsunami.common.net.http.HttpClient send
INFO: Sending HTTP 'GET' request to 'http://xxx.xxx.xxx.xxx/terminals/1'.
Jul 10, 2020 1:00:34 AM com.google.tsunami.common.net.http.HttpClient send
INFO: Sending HTTP 'GET' request to 'http://xxx.xxx.xxx.xxx/cluster/cluster'.
Jul 10, 2020 1:00:34 AM com.google.tsunami.common.net.http.HttpClient send
INFO: Sending HTTP 'GET' request to 'http://xxx.xxx.xxx.xxx/view/all/newJob'.
Jul 10, 2020 1:00:34 AM com.google.tsunami.common.net.http.HttpClient send
INFO: Sending HTTP 'GET' request to 'http://xxx.xxx.xxx.xxx/wp-login.php'.
Jul 10, 2020 1:00:34 AM com.google.tsunami.common.net.http.HttpClient send
INFO: Sending HTTP 'GET' request to 'http://xxx.xxx.xxx.xxx/wp-admin/install.php?step=1'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.net.http.HttpClient parseResponse
INFO: Received HTTP response with code '404' for request to 'http://xxx.xxx.xxx.xxx/view/all/newJob'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.net.http.HttpClient parseResponse
INFO: Received HTTP response with code '404' for request to 'http://xxx.xxx.xxx.xxx/cluster/cluster'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.net.http.HttpClient parseResponse
INFO: Received HTTP response with code '404' for request to 'http://xxx.xxx.xxx.xxx/terminals/1'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.net.http.HttpClient parseResponse
INFO: Received HTTP response with code '200' for request to 'http://xxx.xxx.xxx.xxx/wp-login.php'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.plugin.PluginExecutorImpl buildFailedResult
WARNING: Plugin '/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/NcrackWeakCredentialDetectorPlugin/0.1' failed.
Jul 10, 2020 1:00:35 AM com.google.tsunami.plugins.detectors.exposedui.hadoop.yarn.YarnExposedManagerApiDetector detect
INFO: YarnExposedManagerApiDetector finished, detected '0' vulns.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.net.http.HttpClient parseResponse
INFO: Received HTTP response with code '200' for request to 'http://xxx.xxx.xxx.xxx/wp-admin/install.php?step=1'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.plugin.PluginExecutorImpl buildFailedResult
WARNING: Plugin '/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/WordPressInstallPageDetector/0.1' failed.
Jul 10, 2020 1:00:35 AM com.google.tsunami.workflow.DefaultScanningWorkflow generateScanResults
INFO: Tsunami scanning workflow done. Generating scan results.
Jul 10, 2020 1:00:35 AM com.google.tsunami.workflow.DefaultScanningWorkflow lambda$runAsync$0
INFO: Tsunami scanning workflow traces:
Port scanning phase (28.90 s) with 1 plugin(s):
/Tsunami Team (tsunami-dev#google.com)/PORT_SCAN/NmapPortScanner/0.1
Service fingerprinting phase (759.9 ms) with 0 plugin(s):
Vuln detection phase (694.7 ms) with 5 plugin(s):
/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/NcrackWeakCredentialDetectorPlugin/0.1 was selected for the following services: http (TCP, port 80), ssh (TCP, port 8080)
/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/YarnExposedManagerApiDetector/0.1 was selected for the following services: http (TCP, port 80), ssh (TCP, port 8080)
/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/JenkinsExposedUiDetector/0.1 was selected for the following services: http (TCP, port 80), ssh (TCP, port 8080)
/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/JupyterExposedUiDetector/0.1 was selected for the following services: http (TCP, port 80), ssh (TCP, port 8080)
/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/WordPressInstallPageDetector/0.1 was selected for the following services: http (TCP, port 80), ssh (TCP, port 8080)
# of detected vulnerability: 0.
Jul 10, 2020 1:00:35 AM com.google.tsunami.main.cli.TsunamiCli run
INFO: Tsunami scan finished, saving results.
Jul 10, 2020 1:00:35 AM com.google.tsunami.common.io.archiving.RawFileArchiver archive
INFO: Archiving data to file system with filename '/tmp/tsunami-output.json'.
Jul 10, 2020 1:00:35 AM com.google.tsunami.main.cli.TsunamiCli run
INFO: TsunamiCli finished...
Jul 10, 2020 1:00:35 AM com.google.tsunami.main.cli.TsunamiCli main
INFO: Full Tsunami scan took 38.52 s.
kali#kali:~/tsunami/plugins$ ls -l
total 340
-rw-r--r-- 1 kali kali 7145 Jul 9 15:13 exposed_hadoop_yarn_api-0.0.1-SNAPSHOT.jar
-rw-r--r-- 1 kali kali 6179 Jul 9 15:13 exposed_jenkins_ui-0.0.1-SNAPSHOT.jar
-rw-r--r-- 1 kali kali 5888 Jul 9 15:13 exposed_jupyter_notebook-0.0.1-SNAPSHOT.jar
-rw-r--r-- 1 kali kali 41535 Jul 9 15:13 ncrack_weak_credential_detector-0.0.1-SNAPSHOT.jar
-rw-r--r-- 1 kali kali 267309 Jul 9 15:13 nmap_port_scanner-0.0.1-SNAPSHOT.jar
-rw-r--r-- 1 kali kali 6248 Jul 9 15:13 wordpress_exposed_installation_page-0.0.1-SNAPSHOT.jar
kali#kali:~/tsunami$ nmap -v
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-10 01:02 EDT
Read data files from: /usr/bin/../share/nmap
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.07 seconds
kali#kali:~/tsunami$ ncrack -v
Starting Ncrack 0.7 ( http://ncrack.org ) at 2020-07-10 01:03 EDT
No services specified!
QUITTING!
I made a focus on these two lines:
WARNING: Plugin '/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/NcrackWeakCredentialDetectorPlugin/0.1' failed.
WARNING: Plugin '/Tsunami Team (tsunami-dev#google.com)/VULN_DETECTION/WordPressInstallPageDetector/0.1' failed.
The same plugins worked before against the docker example.
I also set up a Kali 2020.2 VM with tsunami-security-scanner, just to check what happens to have the docker image in a VM and running the Tsunami in another VM.
Again worked as expected.
I can't figure out what is failing.
Thanks in advance!
I'm trying to get Jenkins slave agent running in VM. I have Windows and Ubuntu VMs, Windows one running fine. However getting an error when Slave Agent is starting on Ubuntu:
Start command:
java -jar slave.jar -jnlpUrl
https://SERVER/ci/computer/MACHINE/slave-agent.jnlp -secret XXX
Error:
Skipping HTTPS certificate checks altogether. Note that this is not secure at all.
Sep 22, 2017 12:57:58 PM hudson.remoting.jnlp.Main createEngine
INFO: Setting up slave: MACHINE
Sep 22, 2017 12:57:58 PM hudson.remoting.jnlp.Main$CuiListener <init>
INFO: Jenkins agent is running in headless mode.
Sep 22, 2017 12:57:58 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Locating SERVER among [https://SERVER/ci/]
Sep 22, 2017 12:57:59 PM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
INFO: Remoting SERVER accepts the following protocols: [JNLP4-connect, JNLP-connect, Ping, JNLP2-connect]
Sep 22, 2017 12:57:59 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Agent discovery successful
Agent address: SERVER
Agent port: 51967
Identity: XXX
Sep 22, 2017 12:57:59 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Sep 22, 2017 12:57:59 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to SERVER:51967
Sep 22, 2017 12:57:59 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: port out of range:-1
java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:224)
at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.getResolvedHttpProxyAddress(JnlpAgentEndpointResolver.java:359)
at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:193)
at hudson.remoting.Engine.connect(Engine.java:500)
at hudson.remoting.Engine.innerRun(Engine.java:364)
at hudson.remoting.Engine.run(Engine.java:287)
the error:
SEVERE: port out of range:-1
java.lang.IllegalArgumentException: port out of range:-1
any ideas?
Same for me, it was caused by proxy settings, I solved that adding NO_PROXY environment variable with appropriate hostname
I'm from Linux server background and very new to JBOSS. I'm trying to setup a IoT application server which requires JBOSS service to provide
a web interface for the application server.
But when i check the JBOSS server state it is showing 'starting', i need this to be 'running'.
# /opt/cgms/bin/jboss-cli.sh --connect controller=127.0.0.1 ":read- attribute(name=server-state)"
{
"outcome" => "success",
"result" => "starting"
}
I can see that the deployment is getting failed when i start JBOSS using the script standalone.sh. I've increased the deployment-timeout
up to 6000 seconds in standalone.xml, still the deployment is failing with the following message in /opt/cgms/standalone/deployments/cgms.ear.failed,
""JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [6000 seconds].
Check the server configuration file and the server logs to find more about the status of the deployment."
Here is my JBOSS setup details,
[root#app-server ~]# /opt/cgms/bin/jboss-cli.sh --connect
[standalone#localhost:9999 /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /opt/cgms
JBoss AS release: 7.3.0.Final-redhat-14 "Janus"
JBoss AS product: EAP 6.2.0.GA
JAVA_HOME: null
java.version: 1.8.0_65
java.vm.vendor: Oracle Corporation
java.vm.version: 25.65-b01
os.name: Linux
os.version: 3.10.0-229.el7.x86_64
When i check the server.log, it is stuck at,
# tailf /opt/cgms/server/cgms/log/server.log
624: app-server: Aug 12 2017 05:45:01.506 +0000: %IOTFND-6-UNSPECIFIED: %[ch=StdSchedulerFactory][sev=INFO][tid=MSC service thread 1-1]: Quartz scheduler 'CgnmsQuartz' initialized from an externally provided properties instance.
625: app-server: Aug 12 2017 05:45:01.506 +0000: %IOTFND-6-UNSPECIFIED: %[ch=StdSchedulerFactory][sev=INFO][tid=MSC service thread 1-1]: Quartz scheduler version: 2.2.1
It will not go further from here.
I've tried with java 1.7, but the script standalone.sh failed with a java error,
java.lang.UnsupportedClassVersionError: com/cisco/cgms/loglayout/LogHandler : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
Here are my server details,
OS - Red Hat Enterprise Linux Server release 7.1 (Maipo) - runs on Oracle VM VirtualBox
kernel - app-server 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux
When i check netstat, port 80 and 443 are listening.
Please help to fix this problem.
I installed docker in machine using the guide in https://docs.docker.com/engine/installation/linux/ubuntulinux/ and I also installed Kubernetes in my local machine by using http://kubernetes.io/docs/getting-started-guides/docker/.
But once I run "kubectl get nodes" I get the error error: failed to negotiate an api version; server supports: map[], client supports: map[v1:{} metrics/v1alpha1:{} extensions/v1beta1:{} componentconfig/v1alpha1:{} batch/v1:{} autoscaling/v1:{} authorization.k8s.io/v1beta1:{}].
The docker version on my machine is as follows.
Client:
Version: 1.11.1
API version: 1.23
Go version: go1.5.4
Git commit: 5604cbe
Built: Tue Apr 26 23:30:23 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.1
API version: 1.23
Go version: go1.5.4
Git commit: 5604cbe
Built: Tue Apr 26 23:30:23 2016
OS/Arch: linux/amd64
Looks like the server responded with an empty list of api versions that it supports.
Can you post the output of kubectl version?
That will print the git versions of kubectl and api server and will help us find if there is any incompatibility between the two.
Ive tried using v1.3.0-alpha.3 of kubernetes with the same version of docker as the OP. I`m still having the same issue though. Should this be fixed in alpha.3 or do I need to wait for a new version ?
I've got a pesky issue I hope i can request some assistance from the community on....
I have a Ubuntu 12.04LTS 64 Bit linux server on which I run an instance of JADE (no gui) that creates a container and connects to a Main RMA on my local machine just fine. I see the container pop up and life is good. The problem is when I re-invoke that same instance using an Agent - it hangs. Note: I've recompiled the PingAgent Example on the 64Bit machine with the same vintage of Java (8) as on my workstation (windows). Is it a 32 vs 64 bit thing or are there issues with Jade on Linux?
Any assistance would be greatly appreciated ....
Below are the particulars:
Good instance (no agent, no hanging ):
RUN:
versaggi#drools:/usr/local/jade$ java -classpath lib/jade.jar:classes jade.Boot -container -local-host 50.116.61.17 -host versaggi.game-host.org -port 1099
Result:
Aug 12, 2014 7:35:42 PM jade.core.Runtime beginContainer
INFO: ----------------------------------
This is JADE 4.3.2 - revision 6708 of 2014/03/28 15:19:44
downloaded in Open Source, under LGPL restrictions,
at http://jade.tilab.com/
----------------------------------------
Aug 12, 2014 7:35:42 PM jade.imtp.leap.LEAPIMTPManager initialize
INFO: Listening for intra-platform commands on address:
- jicp://50.116.61.17:1099
Aug 12, 2014 7:35:43 PM jade.core.BaseService init
INFO: Service jade.core.management.AgentManagement initialized
Aug 12, 2014 7:35:43 PM jade.core.BaseService init
INFO: Service jade.core.messaging.Messaging initialized
Aug 12, 2014 7:35:43 PM jade.core.BaseService init
INFO: Service jade.core.resource.ResourceManagement initialized
Aug 12, 2014 7:35:43 PM jade.core.BaseService init
INFO: Service jade.core.mobility.AgentMobility initialized
Aug 12, 2014 7:35:43 PM jade.core.BaseService init
INFO: Service jade.core.event.Notification initialized
Aug 12, 2014 7:35:43 PM jade.core.AgentContainerImpl joinPlatform
INFO: --------------------------------------
Agent container Container-7#50.116.61.17 is ready.
--------------------------------------------
Bad Instance (Agent Included in invocation, hangs ....)
versaggi#drools:/usr/local/jade$ java -classpath lib/jade.jar:classes jade.Boot -container -local-host 50.116.61.17 -host versaggi.game-host.org -port 1099 -**agents** ping1:examples.PingAgent.PingAgent
Aug 12, 2014 7:34:25 PM jade.core.Runtime beginContainer
INFO: ----------------------------------
This is JADE 4.3.2 - revision 6708 of 2014/03/28 15:19:44
downloaded in Open Source, under LGPL restrictions,
at http://jade.tilab.com/
----------------------------------------
Aug 12, 2014 7:34:25 PM jade.imtp.leap.LEAPIMTPManager initialize
INFO: Listening for intra-platform commands on address:
- jicp://50.116.61.17:1099
Aug 12, 2014 7:34:26 PM jade.core.BaseService init
INFO: Service jade.core.management.AgentManagement initialized
Aug 12, 2014 7:34:26 PM jade.core.BaseService init
INFO: Service jade.core.messaging.Messaging initialized
Aug 12, 2014 7:34:26 PM jade.core.BaseService init
INFO: Service jade.core.resource.ResourceManagement initialized
Aug 12, 2014 7:34:26 PM jade.core.BaseService init
INFO: Service jade.core.mobility.AgentMobility initialized
Aug 12, 2014 7:34:26 PM jade.core.BaseService init
INFO: Service jade.core.event.Notification initialized
**< *** HANGS HERE ***>**
**< *** KILLED FROM RAM HERE ***>**
Aug 12, 2014 7:34:36 PM jade.imtp.leap.NodeSkel executeCommand
WARNING: Error serving H-Command jade.core.management.AgentManagement/8: java.lang.NullPointerException
Aug 12, 2014 7:34:36 PM jade.core.messaging.MessageManager shutdown
INFO: MessageManager shutting down ...
Aug 12, 2014 7:34:36 PM jade.core.Runtime$1 run
INFO: JADE is closing down now.
I have determined the source of the problem but not a solution, most likely because a solutions the this problem may not exist.
The JADE container will eventually complete in time (after a timeout period) but the Agent will NOT be instantiated (See bold error msg below).
The problem is that I am instantiating the Main container on a local PC behind a firewall on a private address 10.0.0.12 port 1099. The remote container is instantiated on a public Linux Server that actually correctly connects to my local PC via a port forward of 1099 rule in my local router to the IP of 10.0.0.12.
The real problem arises because the Main Container which controls the remote containers and thusly the agents dictates that the agent communication must go through 10.0.0.12 port 1099 and conveys that to the remote container on the public linux server, which promptly tries to instantiate the agent communication through 10.0.0.12 port 1099....and consequently times out.
In the invoking JAVA call the option "-host 24.228.171.118 -port 1099" actually points to my router which does a port forward - it is NOT the IP of the PC initiating the Main container.
It appears that this particular set up does not work well inherently ....
You see the issue here ....
If there is a configuration option I can employ to change this (that anyone know of) I'd be grateful....
.
versaggi#drools:/usr/local/jade$ java -classpath lib/jade.jar:classes jade.Boot -container -local-host 50.116.61.17 -host 24.228.171.118 -port 1099 -agents ping1:examples.PingAgent.PingAgent
.
Aug 13, 2014 1:08:20 PM jade.core.Runtime beginContainer
INFO: ----------------------------------
This is JADE 4.3.2 - revision 6708 of 2014/03/28 15:19:44
downloaded in Open Source, under LGPL restrictions,
at http://jade.tilab.com/
----------------------------------------
Aug 13, 2014 1:08:21 PM jade.imtp.leap.LEAPIMTPManager initialize
INFO: Listening for intra-platform commands on address:
- jicp://50.116.61.17:1099
Aug 13, 2014 1:08:21 PM jade.core.BaseService init
INFO: Service jade.core.management.AgentManagement initialized
Aug 13, 2014 1:08:21 PM jade.core.BaseService init
INFO: Service jade.core.messaging.Messaging initialized
Aug 13, 2014 1:08:21 PM jade.core.BaseService init
INFO: Service jade.core.resource.ResourceManagement initialized
Aug 13, 2014 1:08:21 PM jade.core.BaseService init
INFO: Service jade.core.mobility.AgentMobility initialized
Aug 13, 2014 1:08:21 PM jade.core.BaseService init
INFO: Service jade.core.event.Notification initialized
.
Aug 13, 2014 1:12:36 PM jade.core.AgentContainerImpl
startBootstrapAgents
SEVERE: Cannot create agent ping1: Remote object unreachable - Caused
by: ICPException delivering command to address
jicp://10.0.0.12:1099. - Caused by: Error creating connection. -
Caused by: Connection timed out
.
Aug 13, 2014 1:12:36 PM jade.core.AgentContainerImpl joinPlatform
INFO: --------------------------------------
Agent container Container-3#50.116.61.17 is ready.
--------------------------------------------
.