Apache solr does not respond only from a specific IP in Digital Ocean - solr

I can not make the Apache Solr installation respond successfully.
I comment quickly, I have a Wordpress droplet in digital ocean, I installed Apache sorl and apparently it is running correctly.
$ service solr status
● solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr; bad; vendor preset: enabled)
Active: active (exited) since Tue 2019-06-18 20:20:55 UTC; 1 day 9h ago
Docs: man:systemd-sysv-generator(8)
Process: 4342 ExecStop=/etc/init.d/solr stop (code=exited, status=0/SUCCESS)
Process: 4458 ExecStart=/etc/init.d/solr start (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B
CPU: 0
The ip xxx.xx.xxx.xxx is my droplet IP, and I only want from this IP queries can be made to apache sorl.
$ ufw status
WARN: / is group writable!
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
8983 ALLOW xxx.xx.xxx.xxx
22 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
If I filter the ips to see if as is configured
$ sudo netstat -lntp | grep 8983
tcp 0 0 127.0.0.1:8983 0.0.0.0:* LISTEN 4507/java
Ping from inside of my droplet server (ssh).
$ ping http://localhost:8983/solr
ping: unknown host http://localhost:8983/solr
How to get an answer from apache solr, what is happening?

First, what you're seeing is caused by Solr only listening to the loopback interface by default. This is to avoid people inadvertently exposing Solr directly to the internet (which it is not meant for). The netstat command shows this:
tcp 0 0 --> 127.0.0.1:8983 <--
To change what interface Solr listens to, you can add -Djetty.host=<ip> to the SOLR_OPTS used when starting Solr. How this is done depends on how you've installed Solr, but usually through solr.in.sh or something similar.
Second: Make sure your firewall is set to disallow connections by default, otherwise the single Allow for the port won't change anything. Test this from outside your host to make sure you're not exposing Solr to the whole internet.
Third: ping does not work like that. ping <ip> is how you'd use the ping utility, and this sends an ICMP packet to the ip (or host which is resolved to an ip) and waits for a response. It'll not work against a http URL, a given port or an endpoint path.

Related

tomcat7 + apache2 port 8081 conflict?

Picking up a test system with apache + tomcat. It was supposed to work but has been not working for a while.
If I start Tomcat first, then when starting apache it will show the following error:
[warn] NameVirtualHost *:8081 has no VirtualHosts
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:8081
no listening sockets available, shutting down
If I start Apache first, then start Tomcat, I will see the java exception saying port 8081 has been used already and Tomcat won't start.
What's the correct way to integrate apache2 and tomcat7? Where do I may be missing in the current setup? thanks.
Since port 8081 is not the standard port for Apache to listen to, it must be configured somewhere explicitly. Go through the configuration, find it, and fix it.
Alternatively, you can go though the tomcat configuration, find the port and fix it.
What the fix may be depends on your server setup: Moving it to another port number, disabling it completly, or something different.
A common configuration hides apache tomcat completly behind apache httpd and connects to it via the AJP connector.
You have the apache configure these listening on port 80 and integrate the Tomcat (default ajp port 8009 or default http port 8080) via mod_jk (AJP) or proxypass (AJP or HTTP) to Apache.
Apache (proxypass)
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
or
ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/

Apache 2.4 virtual host on different port than 80

When reading the articles it all seems easy, but I am unable to get this to work. I run apache 2.4.7
Several virtual hosts are running just fine. I need one virtual host to run at port 8080 only. So I added Listen 8080 to ports.conf
In the virtualhost conf file:
VirtualHost *:8080>
After a restart I am not getting the virtual host. I do see the default server page and I also notice that the Listen 8080 line is working.
What am I forgetting?

Why does Nginx give a 502 error only for mobile devices?

Using Nginx, I'm getting the error:
Error 502 - Bad Request
The server could not resolve your request for uri: http://domain.name/file/path
Oddly, I only get this error when my phone is using data from my cell carrier. The server serves everything just fine when I am using my phone on Wi-Fi or when I'm using a desktop computer. It even works when I am using my iPad conneted to my phone via Wi-Fi with my phone acting as a mobile hotspot.
The 502 error code suggests that there's an issue with reverse proxying or serving requests with php-fpm. I'm doing neither of these.
Because this error is happening only under specific circumstances, I'm thinking it has to be something with the request my phone is sending. (Nexus 5, Chrome, Android Lollipop)
My nginx.conf and other configuration files are passing tests. I used:
sudo nginx -t
and it said "the configuration file syntax is okay" and "configuration file test is successful."
What could be going on?
After tripple-checking my Nginx configuration, I had the idea to look at all tcp activity on port 80 of my server.
I installed tcpdump:
sudo apt-get install tcpdump
Then ran it, looking only for port 80 tcp traffic:
sudo tcpdump 'tcp port 80' -i eth0
I noticed that all other traffic was just 'IP', but when I sent a request from my phone, it was 'IP6'.
My server wasn't ipv6 enabled, but that's an easy fix with an additional listen directive:
listen [::]:80;

App Engine Go SDK web server running in Vagrant guest (with port forwarding) not reachable from host

I'm running GAE dev server within a Vagrant guest precise64 box with the following network setup (in my Vagrantfile):
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.network :forwarded_port, guest: 8080, host: 9090
end
Which does its thing:
[default] Forwarding ports...
[default] -- 8080 => 9090 (adapter 1)
I start my App Engine server with:
goapp serve
or
dev_appserver.py myappfolder
This starts app engine dev server as expected:
INFO 2013-11-22 dispatcher.py] Starting module running at: http://localhost:8080
In all cases, I'm able to ssh in to the Vagrant guest and curl localhost:8080 successfully.
Unfortunately, from the host I'm unable to get a response from localhost:9090 when running GAE dev web server. Additionally, I've made sure that I don't have anything interfering with the port 9090 on the host machine. Also, I'm almost positive this isn't related to Vagrant as I spun up a quick node.js web server on 8080 and was able to reach it from the host. What am I missing?!!!
You must run the Google App Engine Go dev web server on 0.0.0.0 when leveraging Vagrant port forwarding. Like so:
goapp serve -host=0.0.0.0
See the answers here for more info on ensuring the guest web server is not bound to 127.0.0.1 which is loopback. Web servers that bind to 127.0.0.1 (like App Engine Go dev web server does) by default should be overridden to use 0.0.0.0.

How to make Apache2/Httpd trust all client certs

I have an apache2/httpd install on centos fronting a tomcat instance and I want it to trust all client certificates.
How should I go about it?
There is no such thing as 'SSL Passthrough' with Apache since Apache needs to handle the SSL negotiation. Things I may think of are
Do not use Apache but perform TCP forwarding, using a NAT rule for instance (/sbin/iptables -I PREROUTING -t nat -p tcp -d test.server.ip --dport 443 -j DNAT --to :8443). If you have two IP addresses assigned to the machine, your NAT rule can redirect based on the destination IP.
You could configure a virtual host in Apache dedicated to test where you set SSLVerifyClientto none. This Virtual Host has a reverse proxy rule mapping directly to the non SSL http port of your Tomcat instance, or maps to the HTTP/S port and then you set the SSLProxyMachineCertificateFile with certs that Apache can present to authenticate to Tomcat

Resources