No response from running Tomcat: does not start, does nothing - apache

I'm using Ansible to spin up a new Amazon EC2 install, and then I install Java and Tomcat (via the yum module). After placing the war for sample project from the Apache website in the webapps directory, I go and run the the command (below), nothing happens. It returns with response, no error. I've checked both the IP and port 8080 and Tomcat is not running.
[centos#sonar-test webapps]$ sudo systemctl start tomcat
[centos#sonar-test webapps]$ sudo systemctl start tomcat
[centos#sonar-test webapps]$
For reference, I was following this tutorial as well:
https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-centos-7-via-yum

From your comment on my question running curl in your ec2 instance
When I curl I get a large html document with various apache-esque things on it
It means Tomcat is installed and running.
If you don't access it, its because of your security group rules
In your ec2 console, select the Security Groups option. Edit the rules that is associated with your ec2 instance (the one running Tomcat) and permits inbound connections to port 8080 (so you can make request to your Tomcat server) and port 80 if you're running Apache (or nginx/another web server). If you're not sure about security, you can restrict the inbound traffic to come only from your IP so you can test but no-one else can make request.

Related

How to tell vsftpd which ssl to use

I already have vsftp set up with an SSL which is working fine. The issue is that the SSL is for the server's host name and not one of my client's. This client has to be PCI compliant, so when the PCI scan takes place it checks the FTP ports and sees that the SSL is not associated with my client's URL. My question is how can I set vsftp up to serve an SSL based off the IP address or the hostname?
vsftpd version 3.0.3
Red Hat 8.2
I finally found the answer to this on Red Hat's site (https://access.redhat.com/solutions/5172631).
Essentially, the default configuration file is located at /etc/vsftpd/vsftpd.conf. You need to update this file to listen to the default IP address for the server using listen_address=.... Then, copy that file to /etc/vsftpd/[site].conf and change the listen_address to the one for the other site. (Obviously, you have to have different IP addresses for different sites for this to work.)
Once done, enable vsftpd.target and start it:
systemctl enable vsftpd.target
systemctl start vsftpd.target
I also had to restart vsftpd to get this to work:
systemctl restart vsftpd
After that, when connecting to FTP for site 1, everything worked as expected. When connecting to site 2 (the one with it's own unique SSL) I got the correct SSL.

Trying to set up SSL/TLS certificate on Debian Apache AWS Lightsail instance by following tutorial, but still not working

By "not working" I mean the page loads with an http:// prefix. If I manually type https:// it times out. I'm hoping that someone who has done this before can glance at the tutorials and see what might be missing.
The tutorials I've tried all tend to be the same:
https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-debian-8
https://wiki.debian.org/Self-Signed_Certificate
If I test the SSL connection with an online utility such as:
https://www.sslshopper.com/ssl-checker.html
I get this error:
No SSL certificates were found on mywebsite.com. Make sure that the name resolves to the correct server and that the SSL port (default is 443) is open on your server's firewall.
Relevant info:
$ sudo uname -a
Linux ip-172-26-14-207 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux
Running in an AWS Lightsail instance with Debian (OS only) and LAMP stack installed.
Solved it! After using nmap, wget, telnet, etc. to verify that port 443 was open locally but not externally, I remembered that my AWS Lightsail instance was a virtual private server and I might need to configure the VPS. Sure enough, in the Lightsail web interface there is a firewall setting.
Lightsail landing page > Manage instance > Networking > Firewall

enable ssl for openstack

I do not know if here where I have to put my question or not. I really need help. it's been three days i'm trying to configure SSL in openstack with httpd but i fail, i've followed redhat documentation Configuring Secured Deployment (HTTPS) with my own setup but when i restart httpd service i get some errors below :
httpd status
openstack-dashboard.conf

How to run Tomcat on Linux (which has glassfish on port 8080)

I am trying to run to tomcat on linux where glassfish is already running on port 8080 ( you can check here - vhost2.cs.rit.edu:8080 . So i changed the tomcat port to 8181 by editing the server.xml file. NOw with the command startup.sh and i get the following output
Using CATALINA_BASE: /home/krs8785/apache-tomcat-7.0.54
Using CATALINA_HOME: /home/krs8785/apache-tomcat-7.0.54
Using CATALINA_TMPDIR: /home/krs8785/apache-tomcat-7.0.54/temp
Using JRE_HOME: /usr
Using CLASSPATH: /home/krs8785/apache-tomcat-7.0.54/bin/bootstrap.jar:/home/krs8785/apache-tomcat-7.0.54/bin/tomcat-juli.jar
Tomcat started.
I am assuming that tomcat is now working. Now when i test the server by - vhost3.cs.rit.edu:8181 I get
No data received on the browser.
What is the problem here and how do i solve it?
The problem may be unrelated to tomcat. I think your first step should be to exclude networking issues.
I have assumed you are accessing vhost3.cs.rit.edu:8181 from another machine. If that is the case, try to access localhost:8181 from vhost3.cs.rit.edu. If this is not possible in a conventional browser, perhaps because it is a headless server with X forwarding disabled then use a terminal based browser. Try typing the following in the terminal on vhost3.cs.rit.edu
lynx localhost:8181
If you are able to see a representation of a tomcat splash page then you can attribute it to networking issues. This could be firewall related (perhaps even an issue with iptables on linux).

HTTP access on GCE instance after firewall rule added

I'm trying to get Apache working on a GCE instance.
Following GCE's Quickstart guide, I did the following:
Created instance "my-instance" in "my-project" (CentOS image)
Installed httpd, verified it's running
Added the following firewall rule:
gcutil addfirewall http2 --description="Incoming http allowed." --allowed="tcp:http"
and did the same for HTTPS and ICMP
Verified through gce gui that these rules were added to default network
I can ping my instance's IP address but I can't get an HTTP response. I've tried through the browser, from a curl command - no dice. And it works fine when on localhost so I know Apache is returning the index.html page.
When I use curl from a remote host, the error is:
curl: (7) Failed connect to (instance ip addr):80; Connection refused
Thoughts?
I did some experiments to replicate this. In short, I believe HTTP port 80 may be blocked by iptables firewall rules on the local Centos instance. This appears to be the default behavior.
I have a GCE firewall rule setup to allow port 80 traffic to all instances. I created a centos based image via the Cloud Console (which is indeed using the v1 API). Logged in via SSH and started a web server on port 80. I was not able to hit the web server from my laptop. However I was also not able to hit it from another instance in my project. This lead me to suspect a firewall local to the instance rather than Compute Engine's firewall.
I ran this command (which drops the default reject of all ports for testing - this is unsafe to do for machines which are directly exposed to the internet):
$ sudo iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
After running that, I was able to hit my webserver from both another instance and my laptop. Note that this change is lost after restarting the instance. I don't know the correct procedure for changing the default firewall rules on Centos.
Please try a similar experiment on your instances, especially try to hit the web server from another Compute Engine instance, since service level firewalls do not block traffic between instances on the same network.