Couchbase post-installation blank screen on localhost:8091/index.html - couchdb

I have just installed Couchbase Server v.3.0.1. Right after intallation, I am redirected to localhost:8091/index.html. The page is blank on Firefox (error 500 in console), Chrome. IE says "cannot view the page" (error 500).
According to suggestion from link I have run:
netstat -a -b -p tcp and get:
...
No information is available about the property
TCP 0.0.0.0:8080 my_host_name:0 LISTENING
[httpd.exe]
TCP 0.0.0.0:8091 my_host_name:0 LISTENING
[ismagent.exe]
...
Installation path without whitespaces:
E:\programy\Couchbase\Server\bin>
Testing server...
> cbworkloadgen.exe -n localhost:8091
error: could not access REST API: localhost:8091/pools/default/buckets; please check source URL, server status, username (-u) and password (-p); exception: ''

Output of netstat shows that imsagent.exe is listening on port 8091. IMS (Intel Services Manager) agent is not Windows core service. Killing that process solved the problem.

Related

error in ngrok - failed to complete tunnel connection

So I just wanted to create some phishing websites to try them out but now whenever I try to create one via ngrok or just start ngrok ./ngrok http 80 and then visit the site it shows me this -
Failed to complete tunnel connection
The connection to https://xxx.xxx.ngrok.io was successfully tunneled to your ngrok client, but the client failed to establish a connection to the local address localhost:80.
Make sure that a web service is running on localhost:80 and that it is a valid address
the error encountered was: dial tcp [::1]:80:Connect:connection refused.
and also google shows a warning to these whenever I visit them
any suggestions?
You should create a local server on port 80 . Use php or python to create a local server .
PHP
~$ php -S localhost:80
Python
~$ python -m http.server 80
After starting the local server open a new terminal session and start ngrok
~$ ./ngrok http 80
You can create a link with ssh also .make sure that you have installed ssh.
~$ php -S localhost:80 | ssh -R 80:localhost:80 ssh.localhost.run
or
~$ python -m localhost:80 | ssh -R 80:localhost:80 ssh.localhost.run
By the way chrome will automatically detect the phishing pages.

P4V not connecting to my DigitalOcean Droplet when setting up a Perforce Server

I'm trying to set up a Perforce Server using a Droplet from DigitalOcean and connect to it via P4V.
I was following this tutorial https://allarsblog.com/2014/09/25/setup-perforce-digital/ which I was originally led to by an Unreal Engine official YouTube tutorial. When I got to the part where I was supposed to connect via P4V I got the following error:
Connect to server failed; check $P4PORT.
TCP connect to [Droplet IP Address]:1666 failed.
connect: [Droplet IP Address]:1666: WSAECONNREFUSED
I posted on the DigitalOcean forum and they suggested I try to set the P4PORT then verify it with p4 info, but the p4 info command only yields the following:
Perforce client error:
Connect to server failed; check $P4PORT.
TCP connect to devel:1666 failed.
No such host is known.
Since it said no such host is known, I tried using the direct IP Address in the place of devel, and that only returned the same result but it also said connect: [IP Address]:1666: WSAECONNREFUSED.
I can ping the IP Address just fine. Connecting via puTTY (port 22) does not seem to be an issue. I'm using Windows 10, I heard Firewalls could produce this problem but even if I disable my Firewall I get the same errors.
This is my first time doing this, so I may have made a beginners mistake. Any help would be appreciated.
Found my answer in another Forum: Fire up PuTTY and log in as “root” Type “p4d” from the command line (If you don’t see it, it should be located in “/usr/local/bin”)
I had a similar issue.
To clear the " WSAECONREFUSED " error we put Server:[DigitalOcean ServerIP]:1666 and clicked the "New" button for user.
We were prompted with a new error -> WSAETIMEDOUT
to solve this we had to open the 1666 port on the server so we opened the up and down 1666 using these commands.
iptables -I INPUT -p tcp --dport 1666 --syn -j ACCEPT
&
iptables -I INPUT -p udp --dport 1666 -j ACCEPT

This site can’t be reached localhost refused to connect. deployed using jboss 7.1

I deployed my project using jboss7.1 and also it deployed successfully
but I can't access though browser it says This site can’t be reached localhost refused to connect. how to solve this issue?
As this answer mentions,
1 Log in into server via ssh and do next actions from terminal on this server.
2. Run netstat on the port
3.Check state of 1099 port is LISTEN. Remember program name and pid ( last column output of netstat, should be something like 5812/java)
4. Try investigate, what program used it. Run ps aux | grep xxxx where xxxx - pid from step 3

Solarium gets "Permission Denied" when trying to connect apache solr at local ip

I have a drupal 8 site on the same physical server as apache solr (5.2.1). Drupal 8 uses the search_api_solr contrib module, which uses Solarium (installed by composer) to talk to the solr server using the http api.
I have successfully installed solr and created a core. I can query the core using cUrl on the linux command line, using various linux users.
I can access the solr admin screen in a browser (over vpn with 192.168 ip or domain resolving to such) and view the core I created on the cli.
However, the drupal solr module cannot connect to the solr server core, and if I create an index using the drupal module, it throws a php error:
[error] Uncaught PHP Exception Solarium\Exception\HttpException: "Solr HTTP error: HTTP request failed, Failed to connect to 127.0.0.1: Permission denied" at modules/search_api_solr/vendor/solarium/solarium/library/Solarium/Core/Client/Adapter/Curl.php line 248
My url is like this: http://127.0.0.1:8983/solr/mycore
I get the same error for
http://192.168.254.78:8983/solr/mycore
or
http://127.0.0.1:8080/solr/mycore << different port!
Why should Solarium not be able to send http to a local ip?
Note that nothing is listening on 8080, so I suspect that this http failure has nothing to do with the solr server.
The problem turns out to be that SELinux on this CentOS6 machine is not allowing apache to talk to port 8983.
# setenforce 0
and our error goes away.
# setenforce 1
error is back
Check /var/log/audit.log.
This is what we saw:
type=AVC msg=audit(1457115397.149:224568): avc: denied { name_connect } for pid=4029 comm="httpd" dest=8983 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Notice scontext is httpd_t (apache)
And tcontext is port_t (a port)
Now by default apache can only listen on ports that are http_port_t
SO -- we check to see if our desired port "8983"
But first we need "semanage" which is provided by :
yum install policycoreutils-python
Now check for existing http_port_r's:
# semanage port -l | grep 'http_port_t'
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t tcp 5988
Now let's add 8983
# semanage port -a -t http_port_t -p tcp 8983
And check again -- yup 8983 is there
# semanage port -l | grep 'http_port_t'
http_port_t tcp 8983, 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t tcp 5988
No more error with SELinux enforcing

The controller is not available at localhost JBOSS.7.1.1.FINAL

When i run the jboss-cli.sh,
I get this message.
[root bin]# sh jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect localhost
The controller is not available at localhost:9999
[disconnected /] connect
The controller is not available at localhost:9999
[disconnected /] connect localhost:9999
The controller is not available at localhost:9999
[disconnected /]
Also i have another installation of jboss5 GA. I hope that is not interfering.
Although that is totally shut down for now.
Native management interface is :9999 in standalone.sh
Please throw light on this issue.
#
EDITED
#
When i stop my service with "service jboss stop"
i get this message
[root# bin]# *** JBossAS process (7302) received KILL signal ***
grep: /var/run/jboss-as/jboss-as-standalone.pid: No such file or directory
I Dont know how to check whether server is listening on the port 9999 or not.
Few more details
[root bin]# netstat -anp |grep 9999
tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 7931/java
[root bin]# netstat -anp |grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7931/java
JBoss processs id and the server id acquiring these ports is same.
This question has two issues ,
First, i have provided debuging parameter in the startup script.
If you see 8787 that means you have somewhere provided debuging argument.
Second and the most important one controller not available #localhost or #IPADDRESS .
Please check if you have used port offset, as it increments all the ports by the number with with you have set port offset.
Suppose port offset is 2
Then try to access connect localhost:10001 Port i.e 9999+2
On my production server sometimes it does not works with localhost , but works with IP address.
Then try to access connect IPADDRESS:9999
OR
Then try to access connect 127.0.0.1:9999
Please check in the firewall weather the port 9999 or what ever with port offset, if the port is not open in the firewall it gives error,
I asked this question 6 months back and the above checks has solved
the problem always.
This is probaby because you have changed your binding configuration and jboss does not bind to 127.0.0.1.
In case your jboss instance is not binding to 127.0.0.1, you may use --controller option as follows:
./jboss-cli.sh --controller=YOUR_IP:9999
Use netstat -anp |grep 9999 to find out if port 9999 is in use and by which process id. You could also check the host.xml used by the controller to configure the proper native port.
In the host xml, you should find the default port:
<native-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.native.port:9999}"/>
./jboss-cli.sh --controller=localhost:9999 --connect
You open the debug-port with jboss-cli.sh. Either you activated in jboss-cli.sh:
# Sample JPDA settings for remote socket debugging
# JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
or you set JAVA_OPTS with such an option in you environment. See
echo $JAVA_OPTS
I guess you did this for two jboss-processes, and you get a port-conflict. See
netstat -nap | grep 8787
I recently faced this issue and the root cause that I found was completely different than it is listed above. It is because for some other project I shifted to JDK 1.8 from 1.7. Boom! and error started coming up...I took hell lot of time figuring out why it is coming up before finally realizing I changed my JDK version.
It might be because JBOSS 7 doesn't work with 1.8 of which I have limited knowledge but yes this might prove useful for some cases.

Resources